Deterministic Consensus In Distributed System Networks
Networks that use a deterministic consensus mechanism has finality in ordering and validation. This means that once a transaction is verified by the nodes, it becomes the version of truth propagated on the network. Let’s take an example using Hyperledger Fabric.
RAFT Consensus Algorithm
The consensus is based on RAFT on the Fabric layer, which is a CFT (Crash Fault-Tolerant) algorithm. It uses an election round to determine a leader node that propagates the version of truth it knows to the rest of the network.
A node can either be a leader, follower or candidate. A candidate can become a leader during an election conducted by the nodes. The rest of the nodes will then become followers during this term. After timeout value, the next round of elections takes place to elect a new leader (and so on and so forth).
RAFT Consensus Algorithm can be described in the following:
1. A leader node is elected on the network (usually the first installed node to join the network)
2. The leader, when it receives a change in the state of the blockchain due to ledger updates, propagates a message to all other nodes.
3. Nodes copy the message and reply back to the leader.
4. When the leader receives replies from a majority of the nodes, it then commits the change in state to the blockchain. Consensus is thus achieved.
Network Architecture
The network consists of N nodes > 1. At minimum we have a total of 2 nodes. Orderer Node responsible for ordering the transactions correctly chronologically and packaging them into blocks. Peer Node that validates the blocks to add to the blockchain. When the leader node from the election propagates a block, all other nodes will pass this information on to other nodes using a gossip protocol.
Consensus is achieved by an agreement of all the nodes that are active on the network. Any node that encounters problems will not participate during the current round, but must wait until the next round to participate again and then update any entry to the ledger it has missed.
If S = 5, the CFT system requires at least a majority of active nodes to propagate changes on the blockchain or N > 1 . This is done with a block time in seconds (s) or milliseconds (ms) (per default setting) which can be changed as needed. All nodes must agree to the state of the ledger or blockchain based on information from the elected leader. The more nodes in the consensus, the more fault-tolerant the system will be.
In an N = 5 node network, an elected leader node S1 will propagate changes to all nodes. In this case S1 will update all the nodes about changes in the state of the ledger. If a node S3 was down, it would not receive updates. Once it is back online, its copy of the ledger will be updated via a gossip protocol. Nodes S4 and S2 can provide the most recent information to S3.
Further Explanation Of Node Elections
According to the rules, if the leader node crashes, the rest of the network automatically elects a new leader determined by a set period with a timeout. Upon recovery (if recovered) a crashed node will return to a follower and also replicate the blocks missed during downtime.
The consensus works through a membership consortium, which is our Federation that consists of merchants and businesses who are a part of the ecosystem. Each member of this consortium provides 2 nodes to participate, an Orderer Node and Peer Node.
Depending on the number of members in the consortium, a policy is in place to guarantee that each member becomes an elected leader using rounds. If we have a membership n of 5, then we would issue 5 rounds with a different member validating blocks each round. Each round has a new leader. If each block is generated at time t = 15 seconds per round, the total cycle C of 5 rounds lasts 75 seconds or 1.25 minutes.
C = (t / round) * n
Transaction Velocity
Each block will have an x number of transactions inside them. There are no fixed or determined values that you can put in a block since it depends on how busy the network is. If there is only 1 transaction coming in, the nodes do not need to wait for others to come so they can process it immediately into a block.
When you have multiple transactions coming at once, then the settings for the number of transactions that can be put into a block is used. To improve throughput, more transactions can be packaged into a block. This gives us the efficiency rate in Transactions Per Second (TPS) which is the total number of transactions tx per block by the block time t.
TPS = tx / t
As we increase the number of nodes, either through membership or contribution from existing members, the process of determining the leader becomes important. For example, if a member provides 10 nodes it does not mean that each node becomes an elected leader. The RAFT algorithm will elect the leader based on which node has not recently had that role.
To keep the block time more in line with enterprise operations, the number of nodes can be limited on a per channel basis. We can dedicate a channel to just 10 members maximum which are merchants and businesses who closely work within a white label partnership (for example).
For other members we can create a different channel with a different set of nodes so that their time is not affected. That way, members who do not have related business processes can be isolated so their operations can still function within the ecosystem but will not affect each other.
Cooperation Vs. Incentivization
There is no incentivization process in the consensus mechanism. It is rather based on the specific goal of minimizing costs by becoming a part of the ecosystem, for a consortium of companies. The participating business that joins the Federation will be able to onboard their customers much faster and more efficiently.
To ensure fairness, the nodes all perform an equal task of ordering or validating blocks. It becomes more optimal for consortiums to cooperate and work together in a Coordination Game Theory model.
In our theoretical consensus mechanism called FastConsensus, all nodes meet a common interest in which the nodes are all coordinated to determine an outcome that benefits all members of the consortium. A node that cooperates will serve their best interest as illustrated in the quadrants in the diagram.
If we put a value on the tasks, a 1 indicates a benefit and 0 indicates a drawback in the context of our network. When the nodes perform validate and order, it is a benefit to the network (1,1). That is the optimal condition for the nodes to cooperate to benefit everyone.
If the nodes only do 1 benefit while the other is a drawback, that is not optimal. The most drawback to the network is when nodes do not cooperate when being neutral (not providing any contribution) and attacking the network (0,0).
Synopsis
Compared to other consensus mechanisms, deterministic is more centralized but it arrives at an agreement among nodes at a faster convergence time. The ordering of the transactions and the validation by nodes is more likely with a guaranteed result. This is ideal for federated network systems that use consortiums, where faster consensus is vital.
There are no incentives or rewards given in a deterministic consensus compared to probabilistic consensus systems like proof-of-work (PoW). Nodes are programmed to cooperate in validating the truth and are trusted across the network. There is no need to reward a node to be honest, as the system already consists of a trusted network of nodes. The nodes do not compete with each other, so there is no reason for malice in theory. This achieves the desired optimal result of cooperation and trust in a distributed system.
