Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a Clique MIN_WAIT for out-of-turn blocks #16

Open
soc1c opened this issue Jul 8, 2019 · 1 comment
Open

Introduce a Clique MIN_WAIT for out-of-turn blocks #16

soc1c opened this issue Jul 8, 2019 · 1 comment

Comments

@soc1c
Copy link

soc1c commented Jul 8, 2019

From EIP-1955: ethereum#1955

  • Cliquey introduces a MIN_WAIT period for out-of-turn block to be published which is not present for Clique. This addresses the issue of out-of-turn blocks often getting pushed into the network too fast causing a lot of short reorganizations and in some rare cases causing the network to come to a halt. By holding back out-of-turn blocks, Cliquey allows in-turn validators to seal blocks even under non-optimal network conditions, such as high network latency or validators with unsynchronized clocks.

Using this as discussion-to: tracker. See also ref #6

@soc1c
Copy link
Author

soc1c commented Jul 8, 2019

  • I feel there has not really been much time put into investigating the effect of MIN_WAIT. The spec suggests MIN_WAIT to be BLOCK_PERIOD/2, but that means that for each missing signer, the network will actually hiccup. If I have 2 out of 4 signers live on a 15s network, every second block will be delayed by 7-8 seconds. That was explicitly a feature Clique was meant to solve compared to Parity's Aura protocol: to ensure that as long as the network is healthy, blocks have reliable times and don't do weird hiccups.
  • I am also not really convinced about the reason of existence for this. The spec states "out-of-turn blocks often getting pushed into the network too fast causing a lot of short reorganizations". Why is this a problem? Frequent mini reorgs force DApp developers to cater for mainnet conditions where blocks can get reorged (every uncle is a reorg). If anything, this is actually a desired behavior.
  • I am also not convinced by catering for network propagation issues and block clock drift. The point of a PoA network, is that you have semi-reliable trusted authorities. If an authority does not have an acceptable network connection or cannot be bothered to sync its clock, imho the solution is to replace that validator, not to change the protocol. If you network is unstable due to badly implemented clients, fix the clients (or run an alternative one), not change the protocol to support unstable implementations.

ethereum#1955 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant