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:
meowsbits 2021-04-20 21:11:38 -05:00 committed by GitHub
parent 74f39ab127
commit 68a974f7bf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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.