上QQ阅读APP看书，第一时间看更新

Raft consensus

Let's see how the Raft consensus protocol works at a level which will make us comfortable enough to build DApps. We won't go in depth into Raft as it's not necessary.

Raft is used in a semi-trusted network, and there is a desire for faster blocktimes (on the order of milliseconds instead of seconds) and single confirmation (the absence of regular forks).

Every node in the network keeps a list of all other nodes in the network regardless of whether they are up and running or not. A server in a Raft cluster is either a leader or a follower, and can be a candidate in the case of an election, which happens when the leader is unavailable. There can be only one leader at a time. The leader is responsible for creating and sending blocks to the followers. It regularly informs the followers of its existence by sending a heartbeat message. Each follower has a timeout (typically between 150 and 300 ms) called the election timeout, in which it expects the heartbeat from the leader. Every node uses a randomized election timeout in the range of 120-300 ms. The election timeout is reset on receiving the heartbeat. If no heartbeat is received, the follower changes its status to candidate and starts the leader election to elect a new leader in the network. When a candidate starts the leader election, it basically purposes itself as the new leader and becomes the leader if more than 50% of nodes vote for it. If a leader is not elected in a certain timeout, then a new leader election process is started. It's not necessary to understand the leader election process in depth.

Raft is designed in such a way that a Raft network requires more than 50% of the nodes to be available for new transactions to get committed to the blockchain; if the cluster has 2 * F + 1 nodes it can tolerate F failures and still function correctly. If more than F nodes fail, then the application will fail and it will again resume working properly once the cluster again has more than F nodes working properly. Even leader election will fail if more than 50% nodes are not available in the network.

Every transaction from every node is sent to every other node in the network. The leader is responsible for creating and broadcasting blocks. When a leader creates a block, it will first send the block to all the followers, and once more than 50% of the followers receive the block, the leader will commit the block to its blockchain and then send a commit message to the followers so that the followers also commit the block to their blockchain. In the case of unavailability of the followers, the leader retries the requests indefinitely until the block is eventually committed by all of the followers. This process makes sure that once a block is committed to blockchain, it can never be reversed. Even the leader election process makes sure that whoever is selected as a leader has its blockchain up to date.

In Quorum, the default block time is 50 ms, and you can change that according to your needs. So, every 50 ms, a block is created, but remember that if there are no transactions then blocks are not created; empty blocks are not created in Raft. The leader can create new blocks and send them to followers before the previous block is committed, and block creation is asynchronous. But of course, they are committed serially. When a node starts up, it retrieves the missed blocks from the leader only, not from other nodes in the network.

For the Raft cluster to function properly, it's very important that the average time it takes a server to send a heartbeat request to every server in the cluster and receive responses is less than the election timeout. Also, there is no way for the leader to delete or modify committed blocks; a leader can only append new blocks to the blockchain.