EigenDA OP Secure integration

This document presents an overview on how EigenDA plugs into Optimism (OP) Stack.

• write and read path in a L2 rollup
• Why the read path must stay live (even with a misbehaving op-batcher)
• Adding an EigenDA stage to the OP derivation pipeline
• Hokulea, Rust library that defines and implements the Eigenda derivation rule
• How Hokulea works in both interactive fault-proof VMs and zkVMs

Write and Read path in L2 consensus

A rollup system can be split into two parts: write path to L1 and read path from L1

• The write path ensures the liveness of the L2 consensus. It consists of L2 batches produced by op-batcher and L1 deposit transactions.
• The read path controls the safety of the L2 consensus. It ensures that all L2 consensus nodes see an identical list of L2 batches and L1 sytem and deposits transactions, such that an EVM can produce identical L2 state

If the read path stalls, honest nodes can’t reach the block height needed to dispute a bad state root.

L2 Write path (happy-flow)

• op-batcher bundles user txs.
• Sends compressed batches to EigenDA proxy, which converts them into an Eigenda blob. Proxy sends blob to EigenDA, and forwards the returned certificate to op-batcher
• EigenDA certificates are posted to the L1 Rollup Inbox.

L2 Read path

The read path from L1 determines L2 consensus. OP has defined a derivation pipeline in OP spec. Both op-program in Golang and Kona in Rust implement the derivation pipeline. Like the diagram above, the derivation pipeline consists of stages that bring L1 transactions down to Payload Attributes which are L2 blocks.

To support secure integration, we have defined and inserted a Eigenda section in the OP derivation pipeline. In the diagram above, we have sketched where and what rules EigenDA inserts in the OP derivation pipeline. Both Eigenda proxy and Hokulea implement the eigenda blob derivation.

L2 Read path with EigenDA

As in the diagram, op-nodes use the read-path on the eigenda-proxy to fetch EigenDA blob. The proxy checks

• certificate has sufficient stake and is valid
• certificate is not stale
• retrieve & KZG-checked blob from EigenDA
• Decode and pass the data onward

More information can be found in the page secure integration. The key properties which EigenDA derivation strives to keep are

• Determinism – one unique blob per DA certificate.
• Liveness – discard anything that could halt the chain.

Both eigenda-proxy and hokulea hold those properties.

Proving correctness on L1

The security of rollup is determined by if there are provable ways to challenge incorrect L2 state posted on L1. In this section, we discuss our OP secure integration library Hokulea.

Short intro to OP FPVM

The correctness of a L2 state is determined by the derivation rules, which are implemented in both Go op-program and Rust Kona.

With interactive fault proof, the derivation logics are packaged into a binary ELF file, which can be run inside a FPVM (Cannon, Asterisc, etc.).

The FPVM requires both the ELF binary and data (L2 batches and L1 deposits) to be able to rerun the derivation pipeline. The idea is to repeat what op-node has done to reach consensus, except that in FPVM, every execution is traceable and challengeable.

Data is provided to FPVM in the form of preimage oracle. OP spec has defined rules such that all data in the preimage oracle are verifiable on L1.

Hokulea

Hokulea uses traits exposed by Kona derivation pipeline to integrate EigenDA as a Data Availability Source. Hokulea provides traits, implementation for EigenDA part of derivation pipeline, such that those logics can be compiled into ELF together with Kona.

Hokulea also extends preimage oracle for EigenDA, which is able to provide the verifiable interface for answering

• whether a DA cert is correct
• what is the current recency window to determine if a cert is stale

More information about the communication spec is at Hokulea. Both extension to preimage oracle and derivation logics allows for

• deterministically deriving a rollup payload from an EigenDA certificate
• discarding DA Certs that can stall the derivation pipeline

Canoe

We developed a rust library called Canoe that uses zk validity proof to efficiently verify the cert validity on L1 or inside a zkVM.

Hokulea integration with zkVM

Unlike interactive challenge game with fault proof, a zk proof has a property that only the honest party can create a valid zk proof with respect to the correct derivation rule. Hence, a malicious party can raise a challenge but is unable to defend its position.

• The Hokulea+Kona derivation is compiled into ELF for the needed environment (RiscV zkVM or one of the FPVMs)
• The Hokulea+Kona preimage oracle are prepared, where the validity of DA cert is provided by Canoe
• zkVM takes preimage and verifies it, then feeds the data into the ELF containing the derivation logics
• zkVM produces a proof about the execution

Hokulea is currently integrating with OP-succinct and OP-Kailua. For an integration guide, please refer to the preloader example for zk integration.

Rust Kzg Bn254 library

The constraint also requires all eigenda blob with respect to the kzg commitment in the DA cert. We developed a similar library to c-kzg called rust-kzg-bn254 that offers similar functionalities as 4844 spec.