Governed by Genesis, Part II: Authority as History

The question of who was authorized to act at a given past moment appears across a wide range of technical systems. It arises in oracle networks when a downstream application needs to verify that a data submission came from a valid reporter under the rules in force at the time of submission.

It arises in cross-chain communication systems when a destination chain needs to confirm that an attestation was produced by the valid relayer committee at the moment of attestation. It also arises in enterprise approval workflows when a regulator or auditor needs to reconstruct, potentially years after the fact, whether a decision was made by the committee authorized to make it.

The challenge is sharpest when the source and destination chains have no shared state and no synchronous communication channel. A message-passing system that relies on an off-chain relayer committee to attest to source-chain events before they are accepted on the destination chain must establish, for each individual message, that the relayers who signed the attestation were within the valid committee at the moment of signing.

If committee membership on the source chain is governed by a smart contract, the destination chain's verification logic either needs a live query path to that contract or needs to receive a representation of the contract's historical state along with the message. Neither option is fully self-contained.

These are not identical problems, but they share a common structure. In each case, a recipient or auditor needs to answer a historical authorization question: given an action or attestation from time T, was the actor or committee that produced it within the valid authorized set at time T?

The answer to that question depends on two things: knowing who was in the authorized set at time T, and knowing that the action was produced by a member of that set. Both pieces of information need to be available and verifiable.

Most current designs handle the first piece, the historical membership question, by storing governance records externally: in smart contracts, key registries, access control lists, or administrative dashboards. Those external stores are updated over time as committee membership changes.

Reconstructing who was in the authorized set at a past moment requires querying or replaying the history of those external stores. The action record and the authority record are maintained in separate systems and must be cross-referenced to answer historical authorization questions.

Authority in Committee-Based Systems

Oracle networks that aggregate data from multiple sources typically rely on a committee of authorized reporters or validators whose outputs are accepted by the network. The composition of that committee changes over time: reporters may be added as they meet credentialing requirements, removed for underperformance or misconduct, or rotated on schedule.

The governance process that determines those changes is often managed through a combination of on-chain smart contracts and off-chain operational processes. The history of those changes is distributed across multiple systems.

A downstream application consuming data from such a network and needing to verify the authorization status of a historical data point faces a reconstruction problem. The application needs to determine which reporters were in the valid committee at the time the data was submitted, then confirm the data bears signatures from members of that committee.

If the committee membership records are held in a contract whose state changes with each governance action, that reconstruction requires replaying the contract's state history to the relevant point in time. If records are held off-chain, they depend on the availability and integrity of systems outside the protocol itself.

Cross-chain communication systems that rely on a committee of relayers or validators to attest to events or state on a source chain before a destination chain accepts a message encounter the same structure. The destination chain needs to verify that the message was attested by the valid relayer committee at the time of attestation, not by a committee that was in force at some other point.

If committee membership on the source chain is governed by a contract, the destination chain either needs access to that contract's historical state or needs to trust a third party to represent it correctly.

In both cases, the practical workaround is to accept the current committee state as a proxy for historical committee state, or to trust operator-provided representations of governance history. Those workarounds introduce dependencies on liveness, availability, and trust that a self-contained authority record would eliminate.

The EIP-225 specification arrived at its header-embedded governance design precisely because it needed to eliminate an analogous external dependency, the need for syncing clients to access contract state. The resulting design has properties that apply beyond that specific context.

Clique's header-embedded governance produces a record where any client with access to the chain's headers, from genesis or from a known epoch checkpoint, can determine the valid signer set at any subsequent block height without querying any external system. The governance rules are fixed and specified in the EIP. The inputs are the header fields. The computation is deterministic.

That closed-loop verification structure is what distinguishes intrinsic governance history from externalized governance history. It is the structural property that the next installment of this series examines as a basis for succinct proof.

Enterprise and Institutional Contexts

The authority history problem also appears in non-blockchain institutional contexts that rarely frame it in those terms. A procurement approval chain requires that a purchase order be traceable to an authorized approver acting within their delegated authority at the time of approval.

A clinical data release process requires that data be traceable to a principal investigator or data access committee authorized to release it under the applicable data governance rules. A regulatory filing requires that the certifying signatories held the authority to certify at the time of filing. In each case, the authorization claim is a historical claim, not a current one.

Current institutional solutions to this problem typically involve a combination of digital signatures, audit logs, access control records, and governance documentation held in separate systems. The digital signature on a document proves that the signer's key produced it. The audit log records who held the relevant permission at approximately the relevant time.

The access control records document the authorization grants and revocations. To reconstruct the full authorization chain, an auditor needs to assemble information from all of these sources. The integrity of the reconstruction depends on all of them being available, consistent, and attributable to the correct time periods.

That architecture is fragile in specific and predictable ways. Separate systems have separate maintenance histories. Access control records may be overwritten rather than append-only. Audit logs may be retained for different periods in different systems. Governance documentation may be held by a department that no longer exists.

For low-stakes decisions with short review horizons, these limitations are manageable. For high-stakes decisions whose authorization may be questioned years or decades later, the dispersed architecture creates real reconstruction risk.

The reconstruction problem is compounded by organizational change over time. The team that managed the access control system may have changed. The vendor that hosted the audit log may have been replaced. The schema for the governance documentation may have been revised.

Each of these changes introduces a potential break in the audit chain that, under a dispersed architecture, requires additional investigation to bridge. Under an intrinsic architecture, the governance record is part of the same immutable structure as the action record, and organizational changes downstream of the chain's construction cannot alter it.

A design in which the governance history is intrinsic to the action record eliminates several of these risks. If the authorized committee at the time of each action is encoded in the same append-only structure as the action itself, there is no separate governance record to lose or corrupt. The authority chain and the action chain are the same chain.

Reconstruction is a matter of replaying the chain from genesis or from a checkpoint, rather than reassembling information from multiple external sources whose consistency cannot be guaranteed.

Supply chain certification systems present a similar requirement. A certificate that a product met a standard at a particular facility under a particular auditor is a historical authorization claim: the auditor was within the valid certification body at the time of inspection.

If the certification body's membership records are held externally, the certificate's provenance depends on the long-term availability of those records. If membership changes were embedded in the certification record itself, the certificate would carry its own provenance.

Settlement vs. Provenance

There are two distinct use cases for authority records, and most current protocol design conflates them. The first is settlement: determining who is currently authorized so that the next action can be accepted or rejected in real time. The second is provenance: determining who was authorized at a past moment so that a historical action can be verified as legitimate.

Settlement requires low latency, deterministic finality, and current state. Provenance requires completeness, append-only integrity, and replayability from historical data.

Byzantine fault-tolerant protocols like QBFT are optimized for settlement. Their finality guarantees and Byzantine tolerance properties are designed around the requirement to accept or reject the next block quickly and definitively. When configured with smart contract-based validator management, the authority history and block history are maintained in different data structures, and reconstructing the valid validator set at a past block height requires processing both.

The Besu documentation recommends QBFT for production private networks precisely because those networks typically need settlement properties. They are processing financial transactions or operational records that require immediate, irrevocable confirmation.

Clique's design is not optimized for settlement in adversarial multi-party settings. It does not provide immediate finality, and it is vulnerable to a malicious majority. But the design is well-suited to the provenance use case, because the governance history it embeds in headers is replayable from any point in the chain's history.

It does not require external state, and produces a deterministic answer to historical authorization questions. Those are provenance properties, not settlement properties, and they are largely absent from the protocols that replaced Clique in production contexts.

The settlement-versus-provenance distinction also explains why adding a Clique-like authority log on top of a settlement-optimized protocol does not fully address the provenance requirement. If the authority log is a separate component, it reintroduces the external dependency that the intrinsic architecture eliminates.

The value of Clique's design is precisely that governance transitions and block production share a single medium, so the authority record cannot be altered without altering the block record. Layering an authority log onto a system where governance is primarily stored in contract state produces a hybrid with partial provenance properties rather than the full intrinsic guarantee.

The gap matters when the systems that need provenance guarantees, such as audit trails, cross-system verification, and long-horizon institutional records, attempt to use settlement-optimized protocols for historical verification purposes. Settlement protocols answer the question of what the current state is.

Provenance systems need to answer the question of what the state was at a past moment and whether the actions taken at that moment were authorized. These are different computations, and architectures optimized for the first are not necessarily well-suited to the second.

Treating authority history as a design primitive, rather than as a byproduct of governance processes that are primarily oriented toward settlement, changes the architectural decisions that follow. An append-only, self-contained authority log produces different long-term verification properties than a mutable governance contract whose current state is authoritative but whose history requires replay.

For systems where the provenance requirement is primary, the design choices EIP-225 made in order to support syncing clients may serve as a useful reference even in contexts far removed from Ethereum private networks.

There is also a verification-cost dimension that the provenance framing makes visible. Settlement verification is typically performed in real time by a party with access to the current chain state. Provenance verification may be performed long after the fact, by a party with limited access to current infrastructure, potentially in a different legal or regulatory jurisdiction.

A provenance record that requires access to live infrastructure to verify is less durable than one that can be verified from static historical data. Clique's self-contained authority record, verifiable from genesis or checkpoint without any live system query, is designed for exactly the latter case.

The next installment examines what it would take to prove a Clique-style authority history succinctly, and whether the infrastructure that has emerged around zero-knowledge proof systems and light client verification makes that proving problem tractable. The argument there depends on the structural analysis developed here: that Clique's authority record is self-contained, deterministically recomputable, and governed by rules that are fixed in the specification rather than implemented in mutable contract code.

Sources

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