This article was translated by Flow Technology Ambassador FOU.
Original title: Introduction to Flow blockchain
Original link: https://jan-bernatik.medium.com/introduction-to-flow-blockchain-part-2-ce78ed244c9e
We will continue our discussion on the basis of the previous article, this time we will focus on protocol timing and start to explore the content related to block creation.
Protocol Timing
In order to really understand how the protocol works, we need to understand the point in time of the different components in the protocol.
There are situations that can be expected to occur on a strict schedule (deterministic, synchronous), but there are also situations that are triggered by events and their timing is unpredictable (deterministic, asynchronous)
The non-deterministic, asynchronous part of the protocol is execution and validation, since transactions in the set have different computational requirements.
The deterministically synchronized parts of the protocol are collection and block creation, as they are created on the View's schedule.
In short, View refers to a period of time when a certain consensus node is preset as the leader (Leader, which is usually called the primary main node).
Note that in practice, a consensus node will determine the length of a View as it tries to keep in sync with other nodes - we cannot expect to use a centralized time server in a decentralized network, so nodes will use a An algorithm called a "pacemaker" is used to keep things in sync.
The consensus leader during this View time will create a block containing asynchronous events accumulated since the creation of the previous block.
Now that we understand how the data circulating in the network is made into a block, we can now start to understand how a block is constructed, and what the consensus committee determines whether the block is accepted or not.
block creation
We first explain what a Quorum Certificate (QC, Quorum Certificate) is and what role it plays in this process.
The quorum certificate QC is a proof that the proposed block has enough "voting rights" (weight) from enough consensus nodes - they agree that the block is valid and should be added to the chain.
Take a look at the table below - these are some rules that help us better understand what's going on:
1. In each View, there is a pre-designated consensus node as the consensus leader
2. Blocks are always proposed by the consensus leader
3. The consensus leader can only propose blocks based on the parent block with the QC certificate.
Let's take a look at the picture above:
1. Consensus leader A puts the collected information (accumulated information in its "mempool") and proposes block 0 (B0).
2. The consensus node receives B0, verifies whether it is a valid block, and sends their vote to the consensus leader in the next View period. The verification process for proposed blocks is a complex topic that will not be discussed in this article, but roughly includes:
As this process is repeated in View after View, the blockchain grows, transactions in each block are executed, and different assets (tokens, NFTs) in user accounts are updated.
I hope the part about block creation is clear now, in the next article we will discuss blockchain forks and explain the concept of block finality.