CipherLabs
/
besu
mirror of https://github.com/hyperledger/besu
2
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
An enterprise-grade Java-based, Apache 2.0 licensed Ethereum client https://wiki.hyperledger.org/display/besu
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1427 Commits
44 Branches
214 Tags
191 MiB
 
 
Tag: Branch: Tree: d31dc58a4d
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'd31dc58a4d'
${ noResults }
besu/docs/Consensus-Protocols/Comparing-PoA.md

2.5 KiB
Raw Blame History

*[Byzantine fault tolerant]: Ability to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.

Comparing Proof of Authority Consensus Protocols

Pantheon implements the Clique and IBFT 2.0 Proof of Authority consensus protocols. Proof of Authority consensus protocols are used when participants are known to each other and there is a level of trust between them. For example, in a permissioned consortium network.

Proof of Authority consensus protocols allow faster block times and have a much greater throughput of transactions than the Ethash Proof of Work consensus protocol used on the Ethereum MainNet.

In Clique and IBFT 2.0, a group of nodes in the network act as signers (Clique) or validators (IBFT 2.0). These nodes propose, validate, and add blocks to the blockchain. Nodes are added to or removed from the signer/validator pool by the existing group of nodes voting.

!!! note For the rest of this page, the term validator is used to refer to signers and validators.

Properties

Properties to consider when comparing Clique and IBFT 2.0 are:

  • Immediate finality
  • Minimum number of validators
  • Liveness
  • Speed

Immediate Finality

IBFT 2.0 has immediate finality. When using IBFT 2.0 there are no forks and all valid blocks are included in the main chain.

Clique does not have immediate finality. Implementations using Clique must be aware of forks and chain reorganizations occurring.

Minimum Number of Validators

IBFT 2.0 requires 4 validators to be Byzantine fault tolerant.

Clique can operate with a single validator but operating with a single validator offers no redundancy if the validator fails.

Liveness

Clique is more fault tolerant than IBFT 2.0. Clique tolerates up to half to the validators failing. IBFT 2.0 networks require greater than or equal to 2/3 of validators to be operating to create blocks. For example, in an IBFT 2.0 network of:

  • 4-5, 1 unresponsive node is tolerated
  • 6-8, 2 unresponsive nodes are tolerated

Networks with 3 or less validators are able to produce blocks but do not guarantee finality when operating in adversarial environments.

!!! important We recommend not using IBFT 2.0 networks with 3 nodes for production purposes.

Speed

Reaching consensus and adding blocks is faster in Clique networks. For Clique, the probability of a fork increases number as the of validators increases.

For IBFT 2.0, the time to add new blocks increases as the number of validators increases.