You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
From EIP-1955: ethereum#1955
Using this as
discussion-to:
tracker. See also ref #6The text was updated successfully, but these errors were encountered: