Private transactions on the blockchain with Iron Fish. Overview and technical features

We are now in a world with an unbelievable lack of privacy. Companies are irresponsible about the storage of personal information — they sell it, or they care little about its security, which is why so many thefts happen. On this note, Bitcoin began to gain popularity.

In 2017, when many came to the crypto market, people mistakenly believed that bitcoin was private when in reality it could be called pseudo-privacy. Now there are fewer such misunderstandings, but there is also no proper solution to the problem — the complete openness of the entire network, moreover, for everyone. Here Iron Fish comes to help us with its blockchain and cryptocurrency.

Iron Fish itself uses Layer 1 when transactions are protected by the zk-SNARKs protocol. In two words, this is today’s standard, but there is also an improvement in the form of using the developments of the Zcash’ Sapling protocol. Here is the question you might have by now: “Why do we need another blockchain when we already have Zcash, Monero, and DASH?” If everything was fine with them, then yes, there would be no point. But they all have weaknesses in terms of privacy and/or accessibility. They are obsolete and do not meet current requirements.

Among other things, Iron Fish supports WebRTC and Websockets. We ourselves use them very often, without even knowing it. Twitch probably uses them for implementing the chat. Iron FIsh, in turn, uses them for similar purposes — creating and maintaining a P2P (peer-to-peer) connection. The ultimate goal is to allow general users to run nodes, building true decentralization.

Also, here is a couple of points during the execution and validation of the transaction, which I would like to highlight. Let’s leave behind what happens in a regular blockchain (Bitcoin), now we are interested in some features.

When creating a transaction, there is a so-called Spend Description and Output Description. The first describes the initial data (how many coins are on the wallet), the Output Description, in turn, consists of two parameters — how much and where assets are sent, and how much will remain after the transaction.

Only the main parameters remain encrypted, leaving a note that the transaction was created correctly. No details of the transaction can be seen — neither the account information nor the transaction itself, unless the owner himself grants read permissions using view keys.

The validity of the transaction is verified by consensus, which forces the nodes to build blocks in accordance with their rules, otherwise, the block with this transaction will not be accepted by other nodes.
Note: a block is an entity that includes a certain number of transactions. Miners, on the other hand, mine these blocks, thus processing transactions, allowing the system to function with a sufficiently high degree of security.

The validation process looks like this:

Check that there is no public information;
Check that the number of sent tokens from one wallet is equal to the number received on the other, minus the commission;
Verify that each signature in the Spend Description signed the transaction hash;
Check key fields in a transaction;
Check that there are no malicious validators.

The project can become one of those cores of Web 3, being responsible for the privacy of data/transactions (I talked about this in more detail in the podcast about Web 3). Compare this to the invention and adoption of SSL certificates, which completely changed the current Web 2 and paved the way for a more secure internet.
Note: An SSL certificate is a security certificate required to transfer data securely using an encryption protocol.

Website | Github | Telegram | Twitter | Discord

My media: Telegram | Youtube | Podcast | Articles | All links