Proof-of-Authority Consensus

• Proof-of-Authority Consensus

  • What is Proof-of-Authority consensus

  • Advantages of PoA consensus

  • PoA consensus and common attack vectors

    • Denial-of-service attack

    • 51 percent attack

  • How PoA consensus works in the IBAX Network

    • Honor node

    • Leader node

    • Generating new blocks

    • Forks

• What is Proof-of-Authority consensus

• Advantages of PoA consensus

• PoA consensus and common means of attack

• Implementation of PoA consensus in IBAX

In this section, we will describe the Proof-of-Authority consensus and its implementation in IBAX.

What is Proof-of-Authority consensus

Consensus mechanisms in a blockchain platform may fall into two types, i.e. permissionless (Bitcoin, Etherium) and permissioned (Etherium Private).

However, IBAX adopts a novel consensus mechanism between the two, i.e. honor nodes use the "permissioned consensus" enabled by a voting mechanism, while blockchain ecosystems and child nodes use the "permissionless consensus". However, IBAX is generally considered as a permissioned one.

All nodes in a blockchain are subject to preliminary authentication. In addition to other benefits, such consensus mechanism is also advantageous to improve the transaction rate. One of these consensus mechanisms is Proof-of-Authority (PoA).

Proof-of-Authority (PoA) is one kind of novel consensus algorithms that provide high performance and fault tolerance. In PoA, rights to generate new blocks are awarded to nodes with proven authority, which must subject to preliminary authentication.

Advantages of PoA consensus

Compared to Proof-of-Work (PoW) or Proof-of-Stake (PoS) consensus, PoA consensus has the following advantages:

• No need of high-performance hardware. Compared to PoW consensus, nodes implementing the PoA consensus does not spend computational resources for solving complex mathematical logic tasks;

• The interval of time to generate new blocks is predictable, but that for PoW and PoS consensuses are different;

• High transaction rate. Blocks are generated in a sequence at specified time interval by authorized network nodes, which increases the speed of transaction verification.

• Tolerance to compromised and malicious nodes, as long as 51% of nodes are not compromised. IBAX implements a mechanism of banning nodes and revoking block generation rights.

PoA consensus and common means of attack

DoS

An attacker may send large amount of transactions and blocks to a targeted node in the network, making an attempt to disrupt its operation and make its services unavailable.

The PoA mechanism is possible to defend against DoS attacks:

• Because network nodes are pre-authenticated, block generation rights can be granted only to nodes that can withstand DoS attacks.

• If a honor node is unavailable for a certain period, it can be excluded from the list of honor nodes.

51 percent attack

As to the scenario with the PoA consensus, the 51% attack requires an attacker to obtain control over 51% of network nodes. But the scenario for the PoW consensus is different, which an attacker needs to obtain 51% of network computational power. Obtaining the control over nodes in a permissioned blockchain network is much harder than obtaining the computational power.

For example, in a network implementing the PoW consensus, an attacker can increase computation power (performance) of the controlled network segment thus increasing the percentage of controlled nodes. This makes no sense for PoA consensus, because the computational power of the node has no impact on the blockchain network decisions.

Implementation of PoA consensus in IBAX

Honor node

In IBAX, only honor nodes can generate new blocks, which maintain the blockchain network and the distributed ledger.

The list of honor nodes is kept in the blockchain registry. The order of nodes determines the sequence in which nodes generate new blocks.

Leader node

The following formula determines the current leader node, i.e. a node that must generate a new block at the current time.

leader = ((time - first) / step) % nodes

leader

Current leader node.

time

Current time (UNIX).

first

First block generation time (UNIX).

step

Number of seconds in the block generation interval.

nodes

Total number of honor nodes.

Generation of new blocks

New blocks are generated by a leader node of the current time interval. At each time interval, the leader role is passed to the next honor node from the list of honor nodes.

../_images/block-generation.png

a) Steps for Generation of new blocks

Main steps for generating a new block are as follows:

1. Collects all new transactions from the transaction queue of the node;

2. Executes transactions one by one. Invalid or inexecutable transactions are rejected;

3. Checks if the block generation limits is in compliance;

4. Generates a block with valid transactions and signs it with the private key of the honor node through the ECDSA algorithm;

5. Sends this block to other honor nodes.

b) Verification of new blocks

Steps for verifying new blocks on other honor nodes:

1.Receive a new block and verify:

– whether the new block was generated by the leader node of a current interval;

– whether there are no other blocks generated by the leader node of a current interval;

– whether the new block is properly signed. 

1. Execute transactions from the block one by one. Check whether the transactions are executed successfully and within the block generation limits .

2. Add or reject the block, depending on the previous step:

   – If block validation is successful, add the new block to the blockchain of the current node;

   – If block validation failed, reject the block and send a bad block transaction;

   – If the honor node that created this invalid block continues to generate bad blocks, it can be banned or excluded from the list of honor nodes.

Forks

A fork is an alternative version of the blockchain, which 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 are probably result in 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 blockchain versions are detected, honor nodes rollback the shorter one and accept the longer one.

../_images/block-fork-resolution.png