In part 2 of the series we will build on the foundation from the first post. We’ll look at the protocol timing and start exploring the block creation.

Protocol Timing

To really understand how the protocol works, we need to understand timing of different parts of the protocol.

There are things that happen predictably on a strictly timed schedule (deterministic and synchronous) and things that are driven by events and their timing is unpredictable (non-deterministic and asynchronous).

The non-deterministic, asynchronous part of the protocol is execution and verification, because the transactions in the collections vary in their demands on the computation.

The deterministic, synchronous part of the protocol is the collection and block creation, which happens on a schedule driven by views.

To simplify things, let’s think of a view as a period of time for which one of the consensus nodes is predetermined to be a leader (this node is often called ‘primary’).

💡 Note that in reality a consensus node decides on the length of the view, because it is doing it’s best to be in sync with other nodes — we can’t rely on centralized time server in decentralized network, so the nodes use an algorithm called “pacemaker” to stay in sync.

The consensus leader for a view builds the block from the asynchronous events that have accumulated since the last block was built.

Now that we understand how the data which flows through the network makes it to a block, we can start exploring how a block is formed and what determines if it will be accepted by the consensus committee.

Block creation

Let’s start with explaining what is a Quorum Certificate (QC) and what role it plays in the process.

Quorum Certificate is a proof that consensus nodes with sufficient “voting power” (weight) voted on the proposed block — they agree that the block is valid and should be added to the chain.

Take a look at the diagram below — here are few rules which help to understand what is happening there:

1. Each view has a pre-determined consensus node which is the consensus leader.
2. Block is always proposed by the consensus leader.
3. Consensus leader can only propose a block based on a parent block for which a Quorum Certificate exists.

Let’s walk through the diagram.

1. Consensus leader A takes the messages that it received (messages accumulated in its “mempool”) and proposes block 0 (B0).
2. Consensus nodes receive B0, verify it is a valid block and send their vote to the consensus leader of the next view. The verification of the proposed block is complex topic beyond the scope of this post, but at high-level it includes:
   - Checking that the block satisfies consensus rules, such as: It comes from an authorized consensus node, the consensus node is a leader for the respective view, block contains valid QC.
   - Checking that the block payload satisfies the protocol rules, such as: no duplicate collection guarantees or execution results exist in the block and it’s preceding blocks, the collection guarantees are signed by supermajority of the respective collection cluster, execution results are sent by authorized execution nodes.
3. Assuming it received votes with sufficient weights from the consensus committee, consensus leader B builds the QC for B0 and adds it to proposed block 1 (B1).

As this process repeats in each view, the blockchain grows, the transactions in each block get executed and the user accounts holding different resources (tokens, NFTs, …) get updated.

I hope the block formation is clear now, in the next post we will look into blockchain forks and explain the concept of block finalization.

part 3

‍