Skip to main content

Custom Quorums And Thresholds

EigenDA allows users to tailor their data availability solution while maintaining security guarantees.

This is done by lettings users define their own custom quorum and security thresholds. Rollups that do so must enforce that the DA Certificate they receive from the disperser meets the thresholds they have set for each quorum, including their custom quorum.

Dispersing to a custom quorum effectively additionally replicates the data to the set of operators which hold the custom token that defines the custom quorum. This means a rollup's token holders can decide, by delegating their tokens, which operators they trust to ensure the data availability of their rollup.

Overview​

Custom quorums and thresholds enable rollups and other users to:

  • Define specific operator sets for data verification via delegation of their own token
  • Enforce verification of the custom quorum's signature, starting at a specific activation block number
  • Set custom confirmation thresholds for data availability confirmation
  • Securely upgrade these thresholds as security needs evolve

Economic Utility for Native Tokens​

A key benefit of custom quorums is the ability for users to provide economic utility to their native ERC20 tokens. Rollups can:

  • Create dedicated quorums that require re-staking of their native token
  • Establish economic security backed by their own token ecosystem
  • Enable token holders to participate in securing the rollup's data availability

This creates a powerful economic flywheel where the rollup's success directly enhances the utility and value of its native token, while leveraging that token to strengthen the rollup's security.

Securely Upgradeable Cert Verification​

Backward-compatible secure updates to custom quorums and thresholds are implemented using the exact same mechanism that is used for seamlessly (and securely) updating EigenDA Cert verification logic. This allows cert verification to be securely added to rollup stacks without requiring major changes to the rollup's architecture, nor hard forks.

For more information, see the secure integration contracts spec.

EigenDACertVerifier​

Each EigenDACertVerifier is meant to be deployed immutably (not behind a proxy) and defines/contains:

  • A versioned EigenDACert struct (which needs to be constructed from a BlobStatusReply from a dispersing client)
  • Threshold requirements (i.e, adversarial and liveness signing stake thresholds)
  • A checkDACert function to verify the validity of an EigenDACert of the correct version
  • A CertVersion to return the version (single digit "major" version) of the Cert, which is used by dispersing clients to know which version of the cert to build.

The verification logic works uniformly for every quorum, meaning that custom quorums don't have any custom verification logic: they are verified exactly like the ETH and EIGEN quorums. Dispersals specify in the BlobHeader the quorum_numbers that are required to sign, and each quorum is then verified to have reached the required threshold.

EigenDACertVerifierRouter​

Given the immutable nature of the EigenDACertVerifier, changing its logic or thresholds requires deploying a new contract. Secure rollup stacks then need to securely point their derivation pipeline to the new contract, which would require a hard fork. To solve this problem, we introduce the EigenDACertVerifierRouter, which is a custom proxy contract which "reifies implementation update history" by maintaining a mapping of activation block numbers to CertVerifier contracts. This enabled onchain verification of historical certs, as well as offchain verification without requiring an archive node (since the entire mapping is stored in storage). It overall:

  • Maintains a mapping of activation block number (ABN) → EigenDACertVerifier address: new verifiers can be added at any future block
  • Routes checkDACert requests to the appropriate EigenDACertVerifier contract based on reference block number (RBN) in the abi.encoded cert

Note that the Router is only compatible with EigenDACertVerifiers versions >= 3.

Each rollup stack will need to integrate the Router in different ways to maintain a secure integration. We refer users to their respective rollup stack docs:

Quick Start​

The flow to get setup with a CertVerifierRouter and enabling custom quorums would typically look like:

  1. Rollup integrates with EigenDA via the proxy, using the network-default EigenDACertVerifier deployed by EigenDA.
  2. Rollup decides it wants a custom quorum, or to change its security thresholds.
  3. Rollup deploys its own EigenDACertVerifierRouter contract, initializing it with the same EigenDACertVerifier address it's been using as its ABN=0 verifier. The following deployment script can be used for this.
  4. Rollup operators restart their eigenda-proxy instance, changing the --eigenda.v2.cert-verifier-router-or-immutable-verifier-addr flag to point to the router.
  5. Rollup deploys a new EigenDACertVerifier contract with _quorumNumbersRequired including its custom quorum number.
  6. Rollup calls addCertVerifier on the router, activating the new cert verifier at any future activation block number of its choice.
  7. Any cert whose reference block number is >= activation block number will now be verified against the new cert verifier, which will enforce that the custom quorum signatures meets the required thresholds.
  8. Rollup sings Kumbaya