From c00154bc83b441856f2ce69ccb035d8867340713 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Thu, 25 Mar 2021 22:19:27 -0600 Subject: [PATCH 1/5] Clique Block Choice Rule Signed-off-by: Danno Ferrin --- EIPS/eip-cliquechoice.md | 117 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 EIPS/eip-cliquechoice.md diff --git a/EIPS/eip-cliquechoice.md b/EIPS/eip-cliquechoice.md new file mode 100644 index 0000000000000..4c12359997e72 --- /dev/null +++ b/EIPS/eip-cliquechoice.md @@ -0,0 +1,117 @@ +--- +eip: +title: Expanded Clique Block Choice Rule +author: Danno Ferrin (@shemnon) +discussions-to: +status: Draft +type: Standards Track +category: Networking +created: 2021-03-25 +requires (*optional): 225 +--- + +## Simple Summary + +Add a four step block rule to Clique that should reduce block production deadlocks + +## Abstract + +The current specification of Clique allows for multiple competing blocks from producers but does not +provide any strategies to pick blocks aside from the current "highest total difficulty" rule. This +EIP proposes a four step choice rule of highest total difficulty, shortest chain, most recently +in-turn, and lowest hash. This would prevent deadlocks that have occurred in production systems. + +## Motivation + +Recently (5 March 2021) there were a couple of deadlocks in the Goerli multi-client Clique network. +The number of active validators was greater than 1/2 of the available validators so a chain halt +should not have ocurred. The halt was resolved by an inactive validator coming back on line. The +state of the chain was in one of two configurations of 8 validators that can result in a chain halt. +Three of the four clients observed a choice sequence of lowest total difficulty followed by first +observed block. Geth added one extra rule of preferring the shortest chain before preferring the +first observed block. This fork would have resolved itself with Geth's rule, but there is still a +configuration where the chain can halt with a shortest chain rule. + +## Specification + +When a Click validator is choosing between two different chain head blocks to build a nre proposed +block they should chose the blocks from the following priority list. + +1. Choose the block with the most total difficulty. +2. Then choose the block with the lowest block number. +3. Then choose the block that has had the most recent in-turn slot. +4. Then choose the block with the lowest hash. + +When resolving rule 3 clients should use the following formula, where `Vi` is the integer index of +the validator that signed the block, `Hn` is the number of the header, and `Vt` is the total size of +the current validator pool. Clients should choose the block with the **largest** value. + +``` +(Hn - Vi) % Vt +``` + +When resolving rule 4 the hash should be converted into an unsigned 256 bit integer. + +## Rationale + +Two scenarios of a halted chain are known based on the current total difficulty then first observed +rule. One of the scenarios is also resistant to the shortest chain rule. + +For the first scenario where chains of different lengths can halt consider a block with 8 +validators, whose addresses sort to the same order as their designation in this example. A fully +in-order chain exists and validator number 8 has just produced an in-turn block and then validators +5, 7 and 8 go offline, leaving validators 1 to 6 to produce blocks. Two forks form, one with an +in-order block from validator 1 and then an out of order block from validator 3. The second fork +forms from validators 2, 4, and 6 in order. Both have a net total difficulty of 3 more than the +common ancestor. So in this case if both forks become aware of the other fork then both are +considered equally viable and neither set of validators should switch to the newly observed fork. In +this case, adding a shortest chain rule would break the deadlock as the even numbered validators +would adopt the shorter chain. + +For the second scenario with the same validator set and in-order chain with validator 7 having just +produced an in order block, then validators 7 and 8 go offline. Two forks form, 1,3,5 on one side +and 2,4,6 on the other. Both forks become aware of the other fork after producing their third block. +In this case both forks have equal total difficulty and equal length. So Geth's rule would not break +the tie and only the arrival of one of the missing validators fix the chain. In a worst case +scenario the odd and even chains would produce a block for 7 and 8 respectively, and chain halt +would result with no validators that have not chosen a fork. Only a manual rollback would fix this. + +One consideration when formulating the rules is that the block choice should be chosen so that it +would encourage the maximum amount of in-order blocks. Selecting a chain based on shortest chain +implicitly prefers the chain with more in-order blocks. When selecting between competing out of +order chains the validator who is closest to producing an in-order block in the future should have +their chain declined so that they are available to produce an in-order block sooner. + +Finally an arbitrary rule to pick a block would be preferable to picking a first observed block. In +networks where the block production is entirely competitive and winner-take-all, such as Proof of +Work networks, such a choice preserves the nature of the consensus algorithm. However clique chains +tend to be more collaborative than competitive so a fully deterministic rule is preferable. + +## Backwards Compatibility + +The current block choice rules are a mix of most total difficulty and most total difficulty plus +shortest chain. + +As long as the majority of the active validators implement the block choice rules then a client who +only implements the existing difficulty based rule will eventually align with the chain preferred by +these rules. If less than a majority implement these rules then deadlocks can still occur, and +depend on the first observation of problematic blocks, which is no worse than the current situation. + +## Reference Implementation + +Implementation in Hyperledger Besu: https://github.com/shemnon/besu/commits/cliqueBlockChoice + +## Security Considerations + +Malicious and motivated attackers who are participating in the network can force the chain to halt +with well crafted block production. With a fully deterministic choice rule the opportunity to halt +is diminished. Attackers still have the same opportunities to flood the network with multiple blocks +at the same height. A deterministic rule based on the lowest hash reduces the impact of such a +flooding attack. A malicious validator could exploit this deterministic rule to produce a +replacement block. Such an attack exists in current implementations but a deterministic hash rule +makes such replacements more likely. However the impact of such an attack seems low to trivial at +this time. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 04df178822bba98e839878ee02bb764818a60f6b Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Thu, 25 Mar 2021 22:27:49 -0600 Subject: [PATCH 2/5] add EIP #, and discussion link Signed-off-by: Danno Ferrin --- EIPS/eip-cliquechoice.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-cliquechoice.md b/EIPS/eip-cliquechoice.md index 4c12359997e72..e4f828fb96aa0 100644 --- a/EIPS/eip-cliquechoice.md +++ b/EIPS/eip-cliquechoice.md @@ -1,8 +1,8 @@ --- -eip: +eip: 3436 title: Expanded Clique Block Choice Rule author: Danno Ferrin (@shemnon) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-3436-expanded-clique-block-choice-rule/5809 status: Draft type: Standards Track category: Networking @@ -19,7 +19,7 @@ Add a four step block rule to Clique that should reduce block production deadloc The current specification of Clique allows for multiple competing blocks from producers but does not provide any strategies to pick blocks aside from the current "highest total difficulty" rule. This EIP proposes a four step choice rule of highest total difficulty, shortest chain, most recently -in-turn, and lowest hash. This would prevent deadlocks that have occurred in production systems. +in-turn, and lowest hash. This would prevent deadlocks that have ocurred in production systems. ## Motivation From 8f10c224fcfb5a9a19445a3dd58ebdde5f898635 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Thu, 25 Mar 2021 22:33:15 -0600 Subject: [PATCH 3/5] tpyos Signed-off-by: Danno Ferrin --- EIPS/{eip-cliquechoice.md => eip-3436.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename EIPS/{eip-cliquechoice.md => eip-3436.md} (97%) diff --git a/EIPS/eip-cliquechoice.md b/EIPS/eip-3436.md similarity index 97% rename from EIPS/eip-cliquechoice.md rename to EIPS/eip-3436.md index e4f828fb96aa0..ef86050e16e31 100644 --- a/EIPS/eip-cliquechoice.md +++ b/EIPS/eip-3436.md @@ -7,7 +7,7 @@ status: Draft type: Standards Track category: Networking created: 2021-03-25 -requires (*optional): 225 +requires: 225 --- ## Simple Summary @@ -19,13 +19,13 @@ Add a four step block rule to Clique that should reduce block production deadloc The current specification of Clique allows for multiple competing blocks from producers but does not provide any strategies to pick blocks aside from the current "highest total difficulty" rule. This EIP proposes a four step choice rule of highest total difficulty, shortest chain, most recently -in-turn, and lowest hash. This would prevent deadlocks that have ocurred in production systems. +in-turn, and lowest hash. This would prevent deadlocks that have occurred in production systems. ## Motivation Recently (5 March 2021) there were a couple of deadlocks in the Goerli multi-client Clique network. The number of active validators was greater than 1/2 of the available validators so a chain halt -should not have ocurred. The halt was resolved by an inactive validator coming back on line. The +should not have occurred. The halt was resolved by an inactive validator coming back on line. The state of the chain was in one of two configurations of 8 validators that can result in a chain halt. Three of the four clients observed a choice sequence of lowest total difficulty followed by first observed block. Geth added one extra rule of preferring the shortest chain before preferring the From 2562ae7decc208613146897cc089025b7a2b9220 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Fri, 26 Mar 2021 14:19:15 -0600 Subject: [PATCH 4/5] tweak in-turn slot rule, some verbiage Signed-off-by: Danno Ferrin --- EIPS/eip-3436.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-3436.md b/EIPS/eip-3436.md index ef86050e16e31..67955acdbdc42 100644 --- a/EIPS/eip-3436.md +++ b/EIPS/eip-3436.md @@ -39,12 +39,13 @@ block they should chose the blocks from the following priority list. 1. Choose the block with the most total difficulty. 2. Then choose the block with the lowest block number. -3. Then choose the block that has had the most recent in-turn slot. +3. Then choose the block that has had the least recent in-turn slot. 4. Then choose the block with the lowest hash. When resolving rule 3 clients should use the following formula, where `Vi` is the integer index of -the validator that signed the block, `Hn` is the number of the header, and `Vt` is the total size of -the current validator pool. Clients should choose the block with the **largest** value. +the validator that signed the block when sorted as per epoch checkpointing, `Hn` is the number of +the header, and `Vt` is the count of the current validators. Clients should choose the block with +the **smallest** value. ``` (Hn - Vi) % Vt @@ -82,10 +83,8 @@ implicitly prefers the chain with more in-order blocks. When selecting between c order chains the validator who is closest to producing an in-order block in the future should have their chain declined so that they are available to produce an in-order block sooner. -Finally an arbitrary rule to pick a block would be preferable to picking a first observed block. In -networks where the block production is entirely competitive and winner-take-all, such as Proof of -Work networks, such a choice preserves the nature of the consensus algorithm. However clique chains -tend to be more collaborative than competitive so a fully deterministic rule is preferable. +At least one client has been observed producing multiple blocks at the same height with the same +difficulty, so a final catch-all standard of lowest block hash should break any remaining ties. ## Backwards Compatibility @@ -97,6 +96,9 @@ only implements the existing difficulty based rule will eventually align with th these rules. If less than a majority implement these rules then deadlocks can still occur, and depend on the first observation of problematic blocks, which is no worse than the current situation. +If clients only partially implement the rule as long as every higher ranked rule is also implemented +then the situation will be no worse than today. + ## Reference Implementation Implementation in Hyperledger Besu: https://github.com/shemnon/besu/commits/cliqueBlockChoice From 677661067fc5714f63f386e3d8aca2606b0ca54b Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Fri, 26 Mar 2021 15:31:24 -0600 Subject: [PATCH 5/5] update reference impl Signed-off-by: Danno Ferrin --- EIPS/eip-3436.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-3436.md b/EIPS/eip-3436.md index 67955acdbdc42..bcccbb475d50d 100644 --- a/EIPS/eip-3436.md +++ b/EIPS/eip-3436.md @@ -101,7 +101,7 @@ then the situation will be no worse than today. ## Reference Implementation -Implementation in Hyperledger Besu: https://github.com/shemnon/besu/commits/cliqueBlockChoice +Implementation in Hyperledger Besu: https://github.com/hyperledger/besu/pull/2084 ## Security Considerations