forked from DecentralizedClimateFoundation/DCIPs
117 lines
6.3 KiB
Markdown
117 lines
6.3 KiB
Markdown
---
|
|
eip: 3436
|
|
title: Expanded Clique Block Choice Rule
|
|
author: Danno Ferrin (@shemnon)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-3436-expanded-clique-block-choice-rule/5809
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2021-03-25
|
|
requires: 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
|
|
|
|
There has been more than one deadlock 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
|
|
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 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 Clique validator is arbitrating the canonical status between two different chain head blocks,
|
|
they should choose the canonical block with the following ordered priorities.
|
|
|
|
1. Choose the block with the most total difficulty.
|
|
2. Then choose the block with the lowest block number.
|
|
3. Then choose the block whose validator had the least recent in-turn block assignment.
|
|
4. Then choose the block with the lowest hash.
|
|
|
|
When resolving rule 3 clients should use the following formula, where `validator_index` is the integer
|
|
index of the validator that signed the block when sorted as per epoch checkpointing,
|
|
`header_number` is the number of the header, and `validator_count` is the count of the current
|
|
validators. Clients should choose the block with the **largest** value. Note that an in-turn block
|
|
is considered to be the most recent in-turn block.
|
|
|
|
```
|
|
(header_number - validator_index) % validator_count
|
|
```
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
## 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](../LICENSE.md).
|