The name of the world’s largest blockchain, we all know that it is the blockchain of bitcoin but do you know about the world’s lightest and better blockchain? Its name is MINA, with 22 KB size i.e. equal to only 2 tweets or equal to a picture taken on your phone.

Read and understand these points carefully

Other networks such as bitcoin or Ethereum have to store all the transaction information on the network (by arranging the blockchain) in order to validate any new transactions. This is necessary for both networks based on UTXO. Any new node (or a node that was offline for a long period) would have to be incredibly synced to the network by downloading all the blocks they had discarded.

Networks like bitcoin and ether have a picket of Lightning clients. You know, they build lightning clients for efficient environments that help blockchain users to verify information on the new blockchain without syncing in less space and less time.

They do this by reading the header from the block and verifying that the balance is correct w.r.t. (math is fun, isn’t it?) for the block they received, thereby trusting that the full node that sends them the data. As we defined above, these Lightning nodes are “blockchains unable to represent.

MINAs completely transform a blockchain from a genesis block to the current block, with an easily verifiable constant-sized cryptographic proof. Verifying this proof of conformity to a block allows all transactions up to a few blocks behind the current block. Verify.

Note that the use of the term “usable” because of the definition of “blockchain” above means that in a concise protocol like MENA, we need more than just a proof object with a state filled with opaque hashes. Needed. This definition means that in a concise protocol like Mina, we need more than just a Proof object with a state filled with opaque hashes.

This process of verification is applied to all the nodes of Meena’s network. Some roles in the network require additional information to perform their duties, but this goes beyond the definition above.

Data required for a usable representation of the blockchain

We want (1) to be able to check the balance of a specific account and (2) to be able to submit transactions over the network. For this node, which we call a “non-consent node”, stored in its memory requires only the following: a protocol state, account, a Merkle path to this account, and a verification key. Importantly, these are not the powerful Node Lighting clients. They have the same security as full nodes.

This client software for a node that only wants to act as a “non-consent node” has not yet been implemented. This roadmap is on post-mainnet.

protocol state

The protocol state is a clear representation of the current state of the network. It contains hashes of various data structures, including ledgers. The nodes that form the block gossip around the block in which the protocol is located.

A block in the MINA also contains other information; A proof also included, including new transactions and SNARKs for the transactions included in the previous block. Recursive zk-SNARKs (ZERO KNOWLEDGE), a verification function, and a verification key enable us to verify the entire sequence of blocks via proof and protocol state from just a new block.

After verifying the new state is valid, the node can also independently test whether the new block is better than the existing one, without relying on the source, by comparing it to the last known best protocol state - so we can use this information You can choose to forget if it is no better than existing or replaces the information we have stored. To be exact, we only need to maintain a protocol state as we are listening for new states.

account

Mina uses an account-based model (similar to Ethereum). The balance corresponding to the public key is an account record. A node that does not store the entire account-based ledger may request a particular account record from a node that stores it.

An account from Merkel Path

Additionally, the node will also request the Merkel path to the account to confirm the account record is valid without trusting any node. The resulting Merkle root must match the ledger position that was verified by the blockchain snark.

size measurement

So a non-consensual node in Mina can verify the entire blockchain and accounts from a blockchain SNARK-certified ledger, just as any larger, more expensive (in syncing time and space) full node would be on the other network. (like bitcoin or ethereum). Let’s see how big this data is:

The size of each of these pieces of data can be measured empirically, we have determined them (the actual binary data that is stored) using this code. When executed, we get an accurate information.

A node also needs a key to verify the blockchain SNARKS and it has a size of 2039 bytes on disk and the result is about 11kB.

Mina’s cryptography has evolved since we initially crunched the numbers and reached 22kB - the protocol has now become a bit more efficient.

Snarked-ledger

Note that ledger transactions proven by the SNARK blockchain are a few blocks behind the latest ledger because of SNARKS being processed. We call this a snark ledger, which is proven by SNARKS transactions created by SNARK worker nodes. The latest ledger relating to a block (stage-ledger) is explicitly verified by block producers by applying transactions to the ledger and not guaranteed by blockchain proof-of-stake.

Conclusion

Our aim was to show that the entire blockchain can represent and verified using just 11 KB of data. We claim that the entire Mina blockchain is around 22kb, in fact; we should know about it and it could be smaller.