Skip to content

Design unified consensus interface #426

@guidanoli

Description

@guidanoli

📚 Context

Currently, all consensus modules implement the IOutputsMerkleRootValidator interface.
This interface serves one purpose: for application contracts to validate and execute outputs.
However, several other purposes are not contemplated by it:

  1. Delimit epoch boundaries
  2. Submit post-epoch state commitments
  3. Resolve disputes over post-epoch states

Both Authority and Quorum also implement the IConsensus interface, which serves the purposes (1) and (2), but not (3) since disputes are not implemented. Purpose (1) is implemented through fixed-length epochs delimited by base layer block numbers. Epochs are sealed automatically without on-chain intervention. Purpose (2) is implemented through a claim submission function. The claim acceptance criterion varies: Authority accepts every claim from its owner, and Quorum accepts every claim submitted by a majority of the fixed validator set.

Meanwhile, DaveConsensus implements all purposes (1), (2), and (3). Purpose (1) is implemented through variable-length epochs delimited by input indices. Epochs are sealed manually through on-chain intervention. Purpose (2) is implemented through tournament contracts that accept sparse vector commitments over the computation that took place in the epoch. Tournaments are nested, with increasing granularity over state commitments, culminating in a state-transition function performed on-chain. If no disagreeing post-epoch state commitment is submitted, the only dangling commitment can claim victory by timeout (about 1 week on Ethereum Mainnet). Purpose (3) is implemented through this same tournament-style interactive fraud-proof system. Disputes between two conflicting claims are settled either by timeout or by the state-transition function.

These two approaches are quite different and require special handling by the node. It would be beneficial if we could at least tackle purpose (1) and, if possible, purpose (2). Since Authority and Quorum don't implement disputes, purpose (3) could favor what is implemented on DaveConsensus.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    📋 Backlog

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions