Discussion-to: Cliquey PoA engine (a.k.a. "Clique v2")

[soc1c]

Simple Summary

This document proposes a new proof-of-authority consensus engine that could be used by Ethereum testing and development networks in the future.

Abstract

Cliquey is the second iteration of the Clique proof-of-authority consensus protocol, previously discussed as "Clique v2". It comes with some usability and stability optimizations gained from creating the Görli and Kotti Classic cross-client proof-of-authority networks that were implemented in Geth, Parity Ethereum, Pantheon, Nethermind, and various other clients.

Motivation

The Kotti Classic and Görli testnets running different implementations of the Clique engine got stuck multiple times due to minor issues discovered. These issues were partially addressed on the mono-client Rinkeby network by optimizing the Geth code.

However, optimizations across multiple clients should be adequately specified and discussed. This working document is a result of a couple of months testing and running cross-client Clique networks, especially with the feedback gathered by several Pantheon, Nethermind, Parity Ethereum, and Geth engineers on different channels.

The overall goal is to simplify the setup and configuration of proof-of-authority networks, ensure testnets avoid getting stuck and mimicking mainnet conditions.

Rationale

The following changes were introduced over Clique EIP-225 and should be discussed briefly.

• 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.
• To further strengthen the role of in-turn blocks, an authority should continue to publish in-turn blocks even if an out-of-turn block was already received on the network. This prevents in-turn validators being hindered from publishing their block and potential network problems, such as reorganizations or the network getting stuck.
• Additionally, the DIFF_INTURN was increased from 2 to 3 to avoid situations where two different chain heads have the same total difficulty. This prevents the network from getting stuck by making in-turn blocks significantly more heavy than out-of-turn blocks.
• The SIGNER_LIMIT was removed from block sealing logic and is only required for voting. This allows the network to continue sealing blocks even if all but one of the validators are offline. The voting governance is not affected and still requires signer majority.
• The block period should be less strict and slightly randomized to mimic mainnet conditions. Therefore, it is slightly randomized in the uniform range of [-BLOCK_PERIOD/4, BLOCK_PERIOD/4]. With this, the average block time will still hover around BLOCK_PERIOD.
• The block time-stamp no longer requires to be greater than the parent block time plus the BLOCK_PERIOD. We propose a simple sanity check on the time-stamp to be greater than the parent time stamp to be sufficient here.

Finally, without changing any consensus logic, we propose the ability to specify an initial list of validators at genesis configuration without tampering with the extraData.

[soc1c]

Needs some work. ⏳