Repository files navigation

ForkDiff

This is repo contains our fork ofoptimism to support EigenDA.

• EigenDA powered Optimism-Fork
  • EigenDA Proxy
  • Fork Features
    • 1. High Throughput (large parallel blobs)
    • 2. Failover (for Liveness)
    • 3. Security (for Safety)
  • Testing
    • CI
    • Unit Tests
    • op-e2e Tests
    • Kurtosis Devnet Tests
  • Releases and Branching Strategy

OP's altda spec has both op-batcher and op-nodes interface with AltDA layers via ada-server. EigenDA's implementation of the da-server is called theEigenDA Proxy. The proxy hides EigenDA's async grpc API behind a simple POST/GET sync (blocking) REST API.

There are 3 important features for any rollup:

1. Performance
2. Liveness
3. Safety

The upstream code in optimism's repo currently does not support these features for altda rollups. The goal of our fork is to provide these for downstream altda rollups. We will try to upstream as many changes as possible, but the op-team has stopped being receptive to our PRs since the pectra upgrade.

We describe below the current feature-set of the upstream altda code. See release notes for the latest features.

Because POSTs to the EigenDA Proxy are blocking (seeEigenDA Proxy section), the throughput which a rollup can achieve is limited by the number and size of parallel blobs it can submit. The upstream code supportsparallel blobs submissions pre-holocene, but theHolocene strict ordering rules have broken that implementation.

We will implement a new parallel blobs submission mechanism which is compatible with the Holocene strict ordering rules, and also enable submitting large blobs (EigenDA allows blobs up to 16MiB currently).

The upstream altda code does not support failover. If the EigenDA network goes down, the rollup will be stuck.

We will implement a failover mechanism to allow the rollup to continue processing transactions even if the EigenDA network is down.

The upstream derivation pipeline and challenger code does not currently support the EigenDA security model.

Because making altda fraud proofs secure is very involved, we have opted to first secure zk integrations likeop-succinct andrisc0-kailua by usingop-rs's stack. See ourHokulea repo for the latest on this.

OP uses circleci for CI, but we migrated to github actions for this fork. The unit and op-e2e tests are purely golang and so run as part of thetest-golang.yml github workflow, whereas the kurtosis tests are run as part of thetest-kurtosis.yml workflow.

For each feature we add simple unit tests where applicable.

We also add integration tests using op-e2e's framework. These tests are very useful as they are run purely in golang in a single process with very fast block times, but they are limited in that proxy is not spun up and the batcher available there is only a fake.

For full e2e tests we leverage optimism'skurtosis devnet. See the config file to spin up a devnet with eigenda-proxy inmemstore mode andholesky mode, as well as the available eigenda group commands in thejustfile:

$ just --listAvailable recipes:    ...    [eigenda]    eigenda-holesky-devnet-clean    eigenda-holesky-devnet-start# EigenDA devnet that uses eigenda-proxy connected to eigenda holesky testnet network    eigenda-memstore-devnet-clean    eigenda-memstore-devnet-configs    eigenda-memstore-devnet-failback    eigenda-memstore-devnet-failover# to failover to ethDA. Use `eigenda-memstore-devnet-failback` to revert.    eigenda-memstore-devnet-grafana    eigenda-memstore-devnet-restart-batcher# Restart batcher with new flags or image.    eigenda-memstore-devnet-start# EigenDA devnet that uses the eigenda-proxy in memstore mode (simulates an eigenda network but generates random certs)    eigenda-memstore-devnet-sync-status    eigenda-memstore-devnet-test

Our main development branch,eigenda-develop, contains a linear history with new feature work and fixes, as well as upstream merges. We maintain this branch to be able to track the entire history of our fork changes. It might also be useful for some teams who want to use our fork directly as their upstream, so that they can just merge/rebase our latest changes (which will incorporate the OP changes as well).

For teams that want/need more flexibility in how they manage their own fork, we also create release-specific branches which contain cleaned up history of commits on top of a specific upstream release. For example, the second eigenda-fork release in the picture below would be namedop-batcher/v1.11.2-eigenda.2, and will consist of a cleaned-up history of commits (one per feature/service pair) on top of the upstreamop-batcher/v1.11.2 release. We will strive to make our releases on top of opproduction releases, unless an urgent fix is needed.

Fork developers should consult theFork Release Runbook for more details on how to make a new release.