Skip to main content

Overview

Defined below is a technical breakdown of the key changes we've made to securely enable fraud proofs and high throughput for Arbitrum with EigenDA. This also goes over some key caveats and features.

Runbook​

Core Arbitrum is a highly complicated composition of many software repositories and programming languages. To better demystify key system flows, we've developed an operational developer runbook which describes core testing and system procedures.

ETH L2 vs L3 deployments​

L2s using Arbitrum with EigenDA are a M0 integration unlike L3s which are M1. This means both degraded security and throughput when currently using L3s with EigenDA. Please advise our Integrations Overview for a more comprehensive overview of different EigenDA rollup stages.

EigenDA bridging is currently only supported on Ethereum, meaning that L3s settling to a L2 can't:

  • Rely on cert verification within the Sequencer Inbox contract
  • Await disperser confirmations via eigenda proxy for accrediting batches

Currently for L3 deployments, we recommend ensuring that:

  • EIGENDA_PROXY_EIGENDA_ETH_CONFIRMATION_DEPTH is set closer to ETH finalization (i.e, 64 blocks or two consensus epochs) since a reorg'd EigenDA bridge confirmation tx wouldn't be detectable by the rollup itself. This risk is nonexistent for L2s settling to Ethereum since the inbox's EigenDA certificate tx would read storage states on the EigenDAServiceManger which are set by the EigenDA bridge confirmation tx; meaning that a reorg of the EigenDA bridge confirmation tx would result in a reorg of the inbox's EigenDA certificate tx.

  • If you wish to support higher throughput L3s with reduced risk, you can configure your EigenDA proxy instance with secondary storage fallbacks. This would at least ensure that if the blob certificate were to be invalidated the data would still be partially available. This would compromise the trust model of the rollup given an honest verifier node could when syncing from a confirmed chain head could halt in the event of a reorg'd since it wouldn't have access to the sequencer's secondary store.

System Testing​

We've extended many of Arbitrum Nitro's core system tests to ensure E2E correctness when using EigenDA; i.e:

  • Added batch posting and derivation test
  • Added programmatic failover tests to ensure EigenDA successfully rollovers to native Arbitrum DA destinations in the event of ServiceUnavailable status codes
  • Extended E2E fraud proof tests to assert correctness of OSP dispute for READINBOXMESSAGE when using an EigenDA batch destination type.

For replicating EigenDA interactions in a local testing environment, we utilize a local proxy instance configured using a memstore backend to provide rapid iteration cycles. We've also added full compatibility with Github Actions CI to ensure best practice node development.

EigenDA Proxy​

EigenDA Proxy is used for secure and optimized communication between the rollup and the EigenDA disperser. Arbitrum uses the Simple Commitment Mode for client/server interaction and representing DA certificates. Read more about EigenDA Proxy and its respective security features here.

Posting batches to EigenDA​

Please ensure that changes made to batch poster configs are globally applied across all your batch poster instances. If not, there could be inconsistencies that arise due to deviations in collective processing logic. To learn more about the Arbitrum batch poster please advise our following overview spec.

Adjusting maximum batch size

Currently, the batch poster defaults to a maximum of 16mib when dispersing batches to EigenDA. This can be adjusted to a lower threshold directly within the batch poster section of your node config:

    "node": {
        ...
        "batch-poster": {
            "enable": true,
            ...
            "max-eigenda-batch-size": 12_000_000, // 12 MB
        }
    }

Enabling Failover

To remove a trust assumption on the liveness of EigenDA for the liveness of the rollup, we've extended the Arbitrum Nitro batch poster's logic to support opt-in failover to other DA destinations (e.g, AnyTrust, EIP-4844, calldata) in the event of indicated service unavailability from EigenDA. This logic is disabled by default but can be enabled by making the following update to your batch poster config with the following field:

    "node": {
        ...
        "batch-poster": {
            "enable": true,
            ...
            "enable-eigenda-failover": true, 
        }
    }

NOTE: 4844 failover is implemented and audited but untested via E2E system tests since there are no existing tests in vanilla Arbitrum that programmatically assert the end-to-end correctness of 4844. Please use at your own risk, if you'd like to disable 4844 in-favor of calldata DA, add the following field to your dangerous sub-config via node config:

    "dangerous": {
        "disable-blob-reader": true,
    },

To learn more about our Arbitrum failover design methodology, please advise the following spec.

Diff Overview

Many core Arbitrum repositories were forked to securely enable EigenDA. Please advise the following overviews for a more technical breakdown of exact changesets: