diff --git a/docs/Concepts/Consensus-Protocols/Comparing-PoA.md b/docs/Concepts/Consensus-Protocols/Comparing-PoA.md index 0ed0ddc5598..d746c5d3fee 100644 --- a/docs/Concepts/Consensus-Protocols/Comparing-PoA.md +++ b/docs/Concepts/Consensus-Protocols/Comparing-PoA.md @@ -1,67 +1,66 @@ -*[Byzantine fault tolerant]: Ability to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers. +*[Byzantine fault tolerant]: The ability to function correctly and reach consensus despite nodes +failing or propagating incorrect information to peers. -# Comparing Proof of Authority Consensus Protocols +# Comparing Proof of Authority consensus protocols -Besu 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. +Besu implements the Clique and IBFT 2.0 Proof of Authority consensus protocols. Proof of Authority +consensus protocols work when participants know 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. +Proof of Authority consensus protocols have faster block times and a much greater transaction +throughput 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. +In Clique and IBFT 2.0, a group of nodes in the network act as signers (Clique) or validators +(IBFT 2.0). The existing nodes in the signer/validator pool vote to add nodes to or remove nodes +from the pool. !!! 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. + For the rest of this page, the term validator is used to refer to signers and validators. -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. +## Properties + +Properties to consider when comparing Clique and IBFT 2.0 are: -### Liveness +* Immediate finality +* Minimum number of validators +* Liveness +* Speed. -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: +### Immediate finality -* 4-5, 1 unresponsive node is tolerated -* 6-8, 2 unresponsive nodes are tolerated +IBFT 2.0 has immediate finality. When using IBFT 2.0 there are no forks and all valid blocks get +included in the main chain. -Networks with 3 or less validators are able to produce blocks but do not guarantee finality when operating -in adversarial environments. +Clique does not have immediate finality. Implementations using Clique must be aware of forks and +chain reorganizations occurring. -!!! important - We recommend not using IBFT 2.0 networks with 3 nodes for production purposes. +### Minimum number of validators -### Speed +To be Byzantine fault tolerant, IBFT 2.0 requires a minimum of four validators. -Reaching consensus and adding blocks is faster in Clique networks. For Clique, the probability of a fork -increases number as the of validators increases. +Clique can operate with a single validator but operating with a single validator offers no +redundancy if the validator fails. -For IBFT 2.0, the time to add new blocks increases as the number of validators increases. +### Liveness +Clique is more fault tolerant than IBFT 2.0. Clique tolerates up to half of the validators failing. +IBFT 2.0 networks require greater than or equal to two-thirds of validators to be operating to +create blocks. For example, an IBFT 2.0 network of: +* Four to five validators tolerates one unresponsive validator +* Six to eight validators tolerates two unresponsive validators. +Networks with three or less validators can produce blocks but do not guarantee finality when +operating in adversarial environments. +!!! important + Using IBFT 2.0 networks with three nodes for production purposes is not recommended. +### 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. diff --git a/docs/Concepts/Consensus-Protocols/Overview-Consensus.md b/docs/Concepts/Consensus-Protocols/Overview-Consensus.md index c14d3512304..c6c492d5fd3 100644 --- a/docs/Concepts/Consensus-Protocols/Overview-Consensus.md +++ b/docs/Concepts/Consensus-Protocols/Overview-Consensus.md @@ -1,50 +1,48 @@ description: Besu consensus protocols -# Consensus Protocols +# Consensus protocols -Besu implements a number of consensus protocols: +Besu implements the following consensus protocols: * Ethash (Proof of Work) - * [Clique](../../HowTo/Configure/Consensus-Protocols/Clique.md) (Proof of Authority) - -* [IBFT 2.0](../../HowTo/Configure/Consensus-Protocols/IBFT.md) (Proof of Authority) +* [IBFT 2.0](../../HowTo/Configure/Consensus-Protocols/IBFT.md) (Proof of Authority) +* [Quorum IBFT 1.0](../../HowTo/Configure/Consensus-Protocols/QuorumIBFT.md) (Proof of Authority). -* [Quorum IBFT 1.0](../../HowTo/Configure/Consensus-Protocols/QuorumIBFT.md) (Proof of Authority) - -The genesis file specifies the consensus protocol for a chain in the `config` property: +The `config` property in the genesis file specifies the consensus protocol for a chain. For +example: ```json tab="Ethash" { "config": { - ... + ... "ethash": { - + ... } }, ... } ``` - + ```json tab="Clique" { "config": { - .... + ... "clique": { - ... + ... } }, ... } ``` - + ```json tab="IBFT 2.0" { "config": { - .... + ... "ibft2": { - ... + ... } }, ... @@ -54,12 +52,11 @@ The genesis file specifies the consensus protocol for a chain in the `config` pr ```json tab="IBFT 1.0" { "config": { - .... + ... "ibft": { - ... + ... } }, ... } ``` -