This section describes Proof-of-Authority consensus and its implementation in Apla.
What is Proof-of-Authority consensus¶
In blockchain platforms, consensus mechanisms can be divided into permissionless (Bitcoin, Etherium) and permissioned (Apla, Etherium Private).
In a permissioned blockchain, all nodes are pre-authenticated. This advantage allows to use consensus types that provide high transaction rate in addition to other benefits. One of these consensus types is Proof-of-Authority (PoA) consensus.
Proof-of-Authority (PoA) is a new consensus algorithms family that provides high performance and fault tolerance. In PoA, rights to generate new blocks are awarded to nodes that have proven their authority to do so. To gain this authority and a right to generate new blocks, a node must pass a preliminary authentication.
Advantages of PoA consensus¶
Compared to other consensus types that require a proof of spent computational resources (Proof-of-Work) or an existing “share” (Proof-of-Stake), PoA consensus has several notable advantages:
- High-performance hardware is not required. Compared to PoW consensus, PoA consensus does not require nodes to spend computational resources for solving complex mathematical tasks.
- The interval of time at which new blocks are generated is predictable. For PoW and PoS consensuses, this time varies.
- High transaction rate. Blocks are generated in a sequence at appointed time interval by authorized network nodes. This increases the speed at which transactions are validated.
- Tolerance to compromised and malicious nodes, as long as 51% of nodes are not compromised. Apla implements a ban mechanism for nodes and means of revoking block generation rights.
PoA consensus and common attack vectors¶
An attacker sends a large number of transactions and blocks to a targeted network node in an attempt to disrupt its operation and make it unavailable.
The PoA mechanism makes it possible to defend against this attack:
- Because network nodes are pre-authenticated, block generation rights can be granted only to nodes that can withstand DoS attacks.
- If a node is unavailable for a certain period, it can be excluded from the list of validating nodes.
In PoA consensus, the 51% attack requires an attacker to obtain control over 51% of network nodes. This is different from the 51% attack for the Proof-of-Work consensus types where an attacker needs to obtain 51% of network computational power. Obtaining control of the nodes in a permissioned blockchain network is much harder than obtaining computational power.
For example, in a PoW consensus type network, an attacker can increase computation power (performance) of the controlled network segment thus increasing the controlled percentage. This makes no sense for PoA consensus, because the computational power of the node has no effect on the blockchain network decisions.
How PoA consensus works in Apla¶
In Apla, only selected nodes called validating nodes can generate new blocks. These nodes maintain the blockchain network and the distributed ledger.
The list of validating nodes is kept in the blockchain registry. The order of nodes in this list determines the sequence in which nodes generate new blocks.
The leader node¶
The following formula determines the current leader node, a node that must generate a new block at the current time.
leader = ((time - first) / step) % nodes
Current leader node.
Current time (UNIX).
First block generation time (UNIX).
Number of seconds in the block generation interval.
Number of nodes at the current block generation interval.
Generation of new blocks¶
A new block is created¶
The leader node generates the new block as follows:
- Collects all new transactions from its transaction queue.
- Executes transactions one by one. Transactions that are invalid or cannot be executed are rejected.
- Checks compliance to block generation limits.
- Creates a block with valid transactions and signs it with node’s private key (ECDSA algorithm).
- Sends this block to other validating nodes.
The new block is validated¶
Other validating nodes:
Receive the new block and validate that:
- The new block was generated by the leader node of a current interval.
- There are no other blocks generated by the leader node of a current interval.
- The block is generated and signed correctly.
Execute transactions from the block one by one. Check that transactions are executed successfully and within block generation limits.
Add or reject the block, depending on the previous step:
- If block validation is successful, add the new block to the node’s blockchain.
- If block validation failed, reject the block and send a bad block transaction. If the validating node that created this invalid block continues to generate such blocks, it can be banned or excluded from the list of validating nodes.
A fork is an alternate version of the blockchain. A fork contains one or more blocks that were generated independently from the rest of the blockchain.
Forks usually occur when a part of the network becomes desynchronized. Factors that influence the probability of forks are high network latency, intentional or unintentional time limits violation, time desynchronization at nodes. If network nodes have a significant geographic distribution, block generation interval must be increased.
Forks are resolved by following the longest blockchain rule. When two versions of the blockchain are detected, validating nodes rollback the shorter version and accept the longer one.