mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-23 12:18:16 +00:00
Automatically merged updates to draft EIP(s) 3436 (#3502)
Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft, Review, or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing
This commit is contained in:
parent
74f39ab127
commit
68a974f7bf
@ -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 occurred in production systems.
|
||||
|
||||
## Motivation
|
||||
|
||||
@ -34,17 +34,17 @@ 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.
|
||||
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 `header_number` is the integer
|
||||
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,
|
||||
`validator_index` is the number of the header, and `validator_count` is the count of the current
|
||||
`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.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user