Introduction to Flow Blockchain — part 4

Part 3 of this series explains blockchain forks and the concept of block finalization. In this post we will finally look at block sealing, which is the last step in the block lifecycle. Before we go into block sealing, we need to explain data storage in Flow because it is the key to understanding what the block seal is good for and why it matters.

Data Storage in Flow

There are 2 data stores in which flow network stores data.

The Protocol State is the main blockchain itself, which stores data about the state of the network such as who is allowed to participate in the protocol, Collection Guarantees, Execution receipts, Result Approvals, and more.

The Execution State is a data structure called Memory-trie (MTrie), containing all data that is manipulated via Cadence smart contracts (account token balances, NFTs, smart contracts deployed …). Whenever a collection is executed an updated MTrie is generated. The new state of the MTrie data can be referenced via single hash (root-node hash). This hash is the Execution Result that the execution node commits to (Execution commitment) which gets added to a block by the consensus leader so that it can be validated.

💡 Flow is not informationally self-contained, which means that account information isn’t stored on the chain, but rather in the execution state.

Block Sealing

Block sealing is the last step in the block lifecycle. For the client that submitted a transaction, block seal is a guarantee that the execution result (state of their account after the execution) has been successfully verified. Note that the block containing the seal still needs to be finalized before it can be considered as committed to the chain.

Block Seal is added to the blockchain when sufficient Result Approvals has been collected for executed block.

Let’s go through this final diagram.

1. In View 1 Consensus leader A proposes block 0 (B0) to the network.
2. Execution nodes receive and execute B0 and sent Execution Receipts to the network.
3. In ideal scenario, Consensus Leader C receives an execution receipt to add the B0 execution result to block 2 (B2). This means that the Consensus leader C incorporated the execution result into B2, effectively committing the result of the execution of B0 (MTrie root hash) to the blockchain.
4. When block 3 (B3) is proposed by Consensus leader D, verification nodes can determine their chunk assignments using the source of randomness added to B3. Then the VNs request transactions for their chunks from collection nodes and start the verification of their assigned chunks. Note that the verification nodes wait until B3 is finalized, to avoid doing unnecessary work in the case when the chain forks and B3 ends up on a branch that will be discarded.
5. Verification nodes send their result approvals to the network when they are done with verifying their assigned chunks. Assuming consensus Leader H receives sufficient result approvals in view 8 it will create seal for B0 and add it to block 7 (B7).
6. Once B7 is finalized in block 10 (B10), block B0 is sealed and the seal is finalized.

At this point, the user that submitted the transaction which was added to a collection included in block B0 can be certain that their transaction was executed and the result of the transaction execution is committed to the chain.

Simply said, this means that the result of the transaction will not change. If you were transferring the ownership of your car to a new owner, you can now hand them the keys, the car is theirs!

This is the end of the series, I hope this was fun!

If you have any questions, you can ask me on Discord or DM me on Twitter.

There are also Flow forums and Discord channels, which are great way to get in touch with the community, ask question and learn more about Flow.