aelf Tech Talks — AEDPoS Contract Implementation Interpretation Pt 1

aelf Developer

Published in

aelf

6 min readMar 10, 2020

In the aelf consensus contract standard, its five interfaces can be divided into three groups:

For any node, the consensus command can be requested from the contract at any time;
After the end of the scheduler countdown, the node that gets the effective block time obtains consensus data from the contract and produces the block based on this data.
When a node adds a block to the local blockchain, it submits the block information to the consensus contract for a series of verification on consensus data.

Get Consensus Command

The general logic of this method is as follows:

In this implementation, after the code has received the timestamp for the blockchain to start running, the get consensus command is divided into two steps:

Based on the Round information and whether the chain is a main chain or a side chain, it will determine what type of block the public key should produce next. This is described here as the Consensus Behaviour.
If you can get a valid Consensus Behavior, you also can further assemble the Consensus Command and return it as the result.

Get Consensus Behaviour

The difference between the aelf side chain and the main chain lies in that there is no such transactions as production nodes elections in the side chains (i.e. Consensus Behavior). In the Merged Mining design mode, the side chain shares the production nodes of the main chain. Therefore, contracts related to production node elections and other affairs only need to be deployed on the main chain.

The Consensus Behaviour Provider Base shares the implementation logic of Consensus Behaviour for the main chain and side chains.

First, we will briefly introduce the AEDPoS consensus design mechanism and block production sequences. It is well known that under the DPOS consensus, blocks are produced by a series of elected proxy nodes, while AEDPoS block production cycle is based on Rounds. In each round, each production node is randomly assigned a Time Slot. Only in the allocated time slot can the production block be considered legal. The allocation order of production nodes is determined by the random numbers generated in the previous round. In order to verify the random number of the last round, the production node needs to publish the hash value of a random number in the last round, and then publish the random number of the last round in the current round to verify whether the hash value of the random number is equal to the hash value published in the last round. This verification mechanism is also used to verify the random number of the AEDPoS Consensus Commitment Scheme. After the last production node Time Slot of each round, there is an additional Time Slot to produce additional blocks, which are used to initialize the next round of information.

Therefore, the implementation logic for the production node to get Consensus Behavior is relatively clear:

If the node has not produced a block in this round:
If the current time has passed the allocated Time Slot, don’t have to determine the Consensus Behavior first, just return Nothing.
If the current time has not reached the allocated Time Slot, return Consensus Behavior, which is called UpdateValue. Actually, Consensus Behavior is used to update consensus data.
If the node has already produced blocks in this round, judge whether it can produce small blocks (each Time Slot can produce 8 blocks in succession):
If it can, Consensus Behaviour will execute TinyBlock;
If not, assign a Time Slot to the current node to terminate the current round:
If the current node happens to be the pre-designated Extra Block Production Node for this current round, then a time slot which behind the last time slot in the round is assigned to that node.
If the current node is not the specified Extra Block Production Node, after the last time slot of the current round, the time slot with corresponding order will be allocated based on its order in the current round. If the specified extra block producer fails to get out of the block on time due to bifurcation or disconnection, then the current node has the opportunity to end the round by the current node.

The method to determine if you missed the time slot is in the Round:

For the side chain, if you want to terminate the round, just return to NextRound directly:

The transition period for a production node is designed to be 7 days, so it is necessary to judge whether to enter the next round of campaign according to the time. At this time, Consensus Behavior executes NextTerm:

Among them, the NeedToChangeTerm decision rule is: If more than two-thirds of the nodes’ latest block timestamp is more than 7 days different from the last timestamp, it returns true.

Assemble Consensus Command

After getting Consensus Behavior, you can assemble the Consensus Command based on this:

Before assembling the Consensus Command, we need to make a judgment: if there is only one current production node generating blocks in the last three rounds, it means there must be something wrong with the network or the whole chain, then the blocks will be suspended immediately, and we need to wait for other blocks on the synced network to trigger the Consensus Service again.

Next, you can select the corresponding policy according to the incoming Consensus Behavior:

FirstRoundCommandStrategy (Special Processing Strategy for the first round)
NormalBlockCommandStrategy (Corresponding to UpdateValue)
TerminateRoundCommandStrategy (Corresponding to NextRound and NextTerm)
TinyBlockCommandStrategy (Corresponding to TinyBlock)

We use the strategy of NormalBlockCommandStrategy (Corresponding to UpdateValue) to see its implementation logic:

This strategy assembles and executes a ConsensusCommand instance by getting the estimated block time. The rest of the strategy implementation logic is roughly the same.

aelf Tech Talks — AEDPoS Contract Implementation Interpretation Pt 1

Get Consensus Command

Get Consensus Behaviour

Assemble Consensus Command

Other Topics in aelf Tech Talks:

Written by aelf Developer