Consensus Mechanisms

AELF DPoS

aelf delegates $2N+1$ production nodes. $N$ starts with 8 and increases by 1 every year. These nodes in the aelf system enforce all of consensus rules of aelf.

The purpose of these delegated production nodes is to enable transaction relay, transaction confirmation, packaging blocks and data transfer. As aelf adopts multi-SideChain architecture, production nodes have to work as miners for some SideChains.

The $2N+1$ nodes will go through a randomized order calculation each week. The randomization process is illustrated as follows:

1. aelf is running along the timeline within processing units we call a “round” (horizontal arrow in Figure 7.0 and Figure 7.1). In a round, one production node will produce one block each time, while one node will have one extra transaction at the end of the round (vertical arrow in Fig 7.1).

Each production node ($node$) has three main properties in a specific round ($t$):

1. Private Key ($in_{node(t)}$): a value inputted from the production node and kept privately by the production node itself in round $t$. It will become public after all block generations in round $t$ are completed.

2. Public Key ($out_{node(t)}$): the hash value of $in_{node(t)}$. Every node in the aelf network can look up this value at any time.

3. Signature ($sig_{node(t)}$): a value generated by the production node itself in the first round. After the first round, it can only be calculated once the previous round is completed. It is used as the signature of this production node in this round and it is also opened to public at all times like the $out_{node(t)}$.

The Concensus Process

There are two main processes in DPoS: (1) Pre-verification; and (2) order calculation within each round.

Pre-verification

Before a node starts its block generation in round $t+1$, it has to have its status verified in round $t$. In round $t+1$, $in_{node(t)}$ is already published as public, and $out_{node(t)}$ can be queried at any time. So to verify the status of $node$ in round $t$, other nodes can check $hash(in_{node(t)}) \equiv out_{node(t)}$.

Figure 7.0. Pre-verification

Order calculation

In Fig 7.1, we used 4 production nodes as an example to explain our order calculation strategy. In each round $N$, production nodes have $N+1$ block generation. In the first round (Round 1 in Fig 7.1), the ordering of block generations as well as the signature $sig$ for each node are totally arbitrary. In the second round (Round 2 in Fig 7.1), the block generations are again arbitrarily ordered.

However, from the second round, the signature will be calculated by

$sig_{node(t+1)} = hash(in_{node(t)} + all_t)$ where $all_t = \sum_{i=1}^{n+1} sig_{node[i](t)}$ here, $node[i](t)$ means the node is processing the $i^{th}$ transaction in round $t$. From round 3, the ordering within a round is generated from the ordering and the node signature from the previous round. In round $t+1$we traverse the signature of nodes at round $t$ in order. The ordering of a node in is calculated by

$$sig_{node(t)} mod(N) = \begin{cases} 0, & first \space place \\ 1, & second \space place \\ 2, & third \space place \\ \ldots \\ n-1, & n^{th} \space place \end{cases}$$

For cases of conflict, i.e. results pointed to places which are not empty, we point the node to the next available place. If the node conflict is at the $n^{th}$ place, we will find the available place from the first place.

$$sig_{node[0](t)} mod(N) = \begin{cases} 0, & A \\ 1, & B \\ 2, & C \\ \ldots \end{cases}$$

Figure 7.1. Order Calculation Details for First Three Rounds

The node that processes the one extra transaction is calculated from the signature of the node in first place of the previous round.

$sig_{node[0](t)}$ is decided by: (1) all the signatures from previous round $t-1$; (1) the value $in$ of itself in round $t-1$; (3) which node generate the extra block. So it can only be calculated after the previous round $t-1$ completed. Moreover, as it needs all the signatures from the previous round and the value $in$ is input by each node independently, there is no way to control the ordering. The extra block generation is used to increase the randomness. In general, we create a random system that relies on extra inputs from outside. Based on the assumption that no node can know all other nodes’ inputs in a specific round, no one node could control the ordering.

If one node cannot generate a block in round $t$, it also cannot input its $in$ for this round. In such a case, the previous $in$ will be used. Since all production nodes are voted to be reliable nodes, such a situation should not happen often. Even if this situation does happen, the above-mentioned strategy is more than sufficient at dealing with it.

Every node only has a certain time $T$ seconds to process transactions. Under the present network condition, $T=4$ is a reasonable time consideration, meaning that every node only has 4 seconds to process transactions and submit the result to the network. Any delegate who fails to submit within 4 seconds is considered to be abandoning the block. If a delegate failed two times consecutively, there will be a window period calculated as $W$ hours ($W=2N$, $N$ stands for the number of failure) for that node.

In the systematic design, aelf defines that only one node generates blocks within a certain period. Therefore, it is unlikely for a fork to happen in an environment where production nodes are working under good connectivity. If multiple orphan node groups occur due to network problems, the system will adopt the longest chain since that is the chain that most likely comes from the orphan node group with largest number of production nodes. If a malicious node mines in two forked Blockchains simultaneously to attack the network, that node would be voted out of the entire network.

DPoS production nodes are elected in a way that resembles representative democracy. The elected nodes decide how to hand out bonuses to the other production nodes and stakeholders.