Governed by Genesis, Part I: Clique Reconsidered

In 2017, Péter Szilágyi published EIP-225, defining the Clique proof-of-authority consensus protocol for Ethereum-compatible networks. The proposal addressed a concrete operational problem: Ethereum's public testnets ran on proof-of-work consensus, which requires real computational cost to deter bad actors.

On testnets, where test ether carries no economic value, that deterrence is absent, and the networks had experienced repeated disruption. Clique replaced proof-of-work on those networks with a governance model anchored in a known set of authorized signers.

Its defining technical choice was that signer governance, including votes to add or remove signers over time, would be recorded in block headers rather than in smart contract state. The choice to keep signer governance in block headers rather than contract state followed directly from a constraint in how Ethereum clients sync.

By version 1.14, Geth, the most widely used Ethereum execution client, had deprecated support for sealing Clique blocks. The change accompanied Ethereum's post-Merge restructuring, in which execution clients were separated from consensus logic and simplified accordingly.

Geth's current documentation for private networks marks the old Clique-based guide as outdated and directs operators toward proof-of-stake-compatible configurations. The deprecation settled a practical question about which consensus mechanisms Geth would support.

The design questions it left open are different.

The scope of Clique's original deployment extended beyond Ethereum's public testnets. Private network operators building Ethereum-compatible networks for enterprise applications, development environments, and research deployments adopted Clique as a straightforward way to stand up a governed chain.

This avoided the infrastructure overhead of proof-of-work mining or the complexity of BFT voting protocols. Those operators benefited from the low setup cost and the legible governance model, and Geth's deprecation of Clique sealing forced Geth-based operators to either move to a PoS-style configuration with a consensus client or shift to another client strategy.

How Clique Resolves Forks

EIP-225 specifies the difficulty weights that Clique assigns to in-turn and out-of-turn blocks, which serves a purpose beyond simple block production order. In-turn blocks, produced by the signer whose position in the rotation corresponds to the current block number, carry a higher difficulty than out-of-turn blocks produced by other authorized signers.

In the event of competing chains, the chain whose signers have predominantly produced in-turn blocks will accumulate higher total difficulty faster. This provides a natural fork-resolution mechanism that favors the canonical rotation order without requiring any explicit finality vote.

The vote counting rules in EIP-225 also include provisions that prevent minority groups of signers from blocking governance changes indefinitely. A vote to add or remove a signer passes when more than half of the current authorized signer set has voted for it within a single epoch.

Because pending votes are reset at epoch checkpoints, a campaign to change signer membership must achieve majority support within the epoch window. That constraint bounds the duration of contested governance decisions and prevents accumulated but stale votes from producing unexpected signer set changes after a long delay.

What EIP-225 Was Built to Solve

Ethereum's early testnets operated under proof-of-work consensus, and that consensus depended on miners investing real resources to produce valid blocks. On networks where the underlying asset has no market value, those resources are not forthcoming, and the resulting low-cost attacks made testnet operation unreliable.

EIP-225 proposed replacing that mechanism with a model in which a predefined set of addresses, established at genesis, takes turns producing and signing blocks, with any address outside that set being rejected by the network.

Why Governance Had to Live in Headers

The specification's central architectural requirement was that signer set changes, specifically votes to add or remove authorized addresses, be carried in block header fields rather than stored in smart contract state. The EIP states the reason directly: clients running fast sync or light sync do not have access to EVM-executed contract state during the sync process itself.

Any authorization protocol that depended on contract state would be unavailable to syncing nodes. By keeping governance in headers, Clique made the authorization protocol accessible to clients at any sync level.

The mechanics of how that header-embedded governance works involve a small number of repurposed standard fields. Votes to add or remove a signer are encoded in the coinbase and nonce fields of blocks produced by existing authorized signers.

What Epoch Checkpoints Actually Do

Epoch checkpoints occur at a fixed block interval defined in the genesis configuration. At each checkpoint, the full current signer list is written into the extra-data field of that block's header, and any pending votes that have not yet reached a majority are discarded.

Between checkpoints, the valid signer set at any given block is determined by processing the vote tally since the last epoch.

That structure produces a governance record with a specific and valuable property: the authorized signer set at any past block height is a deterministic function of the header sequence from genesis to that point, or from the nearest preceding epoch checkpoint. No query to an external system is required.

No contract state needs to be replayed. No governance registry or side channel needs to be consulted. The entire authority history is contained within and recoverable from the block headers themselves.

What Clique does not provide is Byzantine fault tolerance or deterministic finality. A malicious majority of the current signer set can produce conflicting blocks, and the protocol resolves forks by the heaviest-chain rule rather than by a deterministic agreement protocol.

Those properties were acceptable in Clique's target deployment context, where all signers were known to and vetted by the operator. In adversarial multi-party settings with unknown or potentially hostile participants, these are material limitations.

How the Client Ecosystem Responded

Geth's deprecation of Clique sealing reflects the structural changes to Ethereum execution clients following the Merge, not a comprehensive finding about Clique's design properties. In Ethereum's current architecture, execution clients handle transaction processing and state management while consensus clients manage block finalization under proof-of-stake rules on the beacon chain.

Private networks using Geth now configure it to operate with a consensus client rather than relying on Clique's standalone signing mechanism. That is a client-scope decision with a clear engineering rationale.

The response from other Ethereum-family clients has not been uniform. The Besu documentation for private networks explicitly recommends QBFT and describes Clique as no longer supported, directing operators to QBFT for any network requiring production-grade consensus.

QBFT, which stands for Quorum Byzantine Fault Tolerant consensus, provides immediate finality and tolerates up to one-third of validators behaving arbitrarily rather than simply failing. ConsenSys GoQuorum continues to document Clique configuration while noting it is unsuitable for production use and recommending migration to QBFT for deployments that require stronger fault tolerance guarantees.

That divergence across clients matters for reading the deprecation accurately. As a signal that Geth-based operators should move on, the deprecation is clear. As a broader statement about the utility or exhaustion of Clique's design choices, it is a narrower finding.

One major execution client exited the Clique path for reasons tied to its post-Merge architecture. Other clients in the same family continue to document the protocol, if only to direct operators away from it in production contexts.

QBFT and its predecessor IBFT 2.0 were adopted by enterprise operators for principled engineering reasons. Both protocols provide immediate, deterministic finality: once a block is added to the chain, it cannot be reverted under normal operating conditions.

Both tolerate a minority of Byzantine validators, meaning nodes that behave arbitrarily or maliciously rather than simply going offline. For multi-organization financial infrastructure where finality is a regulatory and operational requirement, these properties reflect genuine engineering judgment about what the deployment context demands.

Clique and QBFT were not designed for the same operating regime. Clique was built for developer-controlled environments, small signer sets, and cases where the transparent, replayable history of signing authority mattered as much as block production performance.

QBFT was built for multi-party production networks where finality, throughput, and Byzantine tolerance are primary requirements. Treating the transition from Clique to QBFT as a story about one protocol being better than another obscures the more precise observation that they solve different problems.

The Authority Record as a Structural Property

The structural property that Clique's header-based governance produces is that the chain functions as its own complete, self-validating authority log. Every governance action, whether adding or removing a signer, is recorded in the same append-only data structure as every transaction.

The authority record and the action record share a medium and cannot be separated without breaking the chain's integrity.

The genesis block in a Clique chain carries the initial signer list in the extra-data field, encoded in a specific format EIP-225 defines. Because the genesis configuration is agreed upon by all participants before the chain starts, and because subsequent governance changes are voted into the header record, the full signer history from genesis to any given block is a verifiable chain.

In this chain, each transition follows from the prior state by applying the EIP-225 rules. There is no point in the chain at which the governance history requires appeal to an authority or record outside the chain itself.

One operational consequence of header-embedded governance is that the valid signer list can be recovered by any participant who has access to the block headers, without any other privileged information. This matters in disaster-recovery and migration scenarios: a new node joining a Clique network can reconstruct the current signer set by syncing headers from genesis or by processing headers forward from the most recent available epoch checkpoint.

The governance state is not held by any administrator or stored in any external database; it is a derivable property of the chain's public header data.

Auditability Versus Finality

QBFT supports two validator management configurations: block header voting, in which governance transitions are recorded in headers similarly to Clique, and smart contract-based management, in which the validator set is governed through a dedicated contract.

Under the contract-based configuration, the authority history and the block history are maintained in different data structures. Reconstructing who was authorized to validate at a given past block height requires processing both the block history and the contract's event log, and the accuracy of that reconstruction depends on both being available and intact.

That architectural difference has practical implications for auditability over long time horizons. A chain where governance history is intrinsic to the block record is auditable from the chain itself, without reference to any external system.

A chain where governance history is held separately requires that the external record be available, correctly attributed to the relevant time period, and consistent with the block record. For systems where historical authorization claims need to hold up over years rather than days, that difference in architecture affects the robustness of the audit path.

The verification requirements also differ. A verifier who holds a Clique chain's genesis block configuration, or the most recent epoch checkpoint, can determine the valid signer set at any subsequent block height by processing the intervening headers according to the EIP-225 rules.

That processing is local to the chain's own data. The verification does not require any trusted third party, external oracle, or governance registry. It is a closed computation over the consensus-adjacent data.

Whether that property is useful or exploitable in protocol contexts beyond Ethereum private networks is the question the deprecation did not address. The self-contained, deterministically recomputable nature of Clique's authority record is a necessary condition for compact external verification.

Whether it is a sufficient condition, and what engineering work would be required to produce such verification, is the subject of a later installment in this series. The observation here is structural: Clique encodes authority history in a form that supports self-contained verification, and that is a design property worth examining separately from the deployment question.

What Geth Deprecated, and What It Did Not

Geth's deprecation closed a chapter for operators running Ethereum-compatible private networks. It did not close the question of whether header-embedded authority governance has lasting relevance as a design pattern in other contexts.

The remaining installments in this series examine that question directly, first by identifying where the authority-history problem recurs across other protocol classes, then by asking what it would take to prove a Clique-style authority record succinctly, and finally by surveying the specific domains where those design properties may have the clearest application.

Sources

• Szilágyi, Péter. "EIP-225: Clique Proof-of-Authority Consensus Protocol." Ethereum Improvement Proposals, 2017.
• go-ethereum contributors. "Private Networks." Geth Documentation, 2024.
• Hyperledger Besu contributors. "QBFT." Besu Documentation, 2024.
• ConsenSys GoQuorum contributors. "Clique consensus." GoQuorum Documentation, 2023.