Skip to main content

ZK Stack and EigenDA

ZK Stack is ZKsync's rollup framework. We have implemented an EigenDA Client following ZK Stack's validium architecture. Our integration is currently in Stage 1 and we are working towards Stage 2.

Overview​

Unlike most other rollup stacks, ZK Stack posts compressed state diffs to EigenDA, as opposed to batches of transactions. For more information as to the motivation for this, as well as technical details, see ZK Stack's Data Availability documentation.

Overall, the transaction lifecycle remains unaffected, other than the data (compressed state diffs) being submitted to EigenDA, and a DACert submitted to L1.

Stage 1​

a Validium that only sends the data to the DA layer, but doesn’t verify its inclusion

ZK Stack prefers to have their sequencer run as a single binary without sidecars. Therefore, our ZK Stack integration does not use the EigenDA Proxy. Rather, we use our Rust eigenda-client. And the EigenDA Client wrapper inside the ZKSync-Era repo implements the 2 required trait methods dispatch_blob and get_inclusion_data.

Stage 2​

a Validium that sends the data to the DA layer, and also verifies its inclusion on L1 either by using the verification bridges or zk-proofs directly.

In the stage 2 model, in order for ZK Stack's prover to remain AltDA agnostic, their Validium architecture mandates that a sidecar prover is used to prove the inclusion of the compressed state diffs on EigenDA, to the L1. We use Risc0 for this sidecar prover.

Deployment​

Local Deployment​

Follow the steps in the Validium FAQ:

  1. Install zkstack following this guide
  2. zkstack dev clean all - to make sure you have an empty setup
  3. zkstack containers - this creates the necessary docker containers
  4. zkstack ecosystem init - init a default ecosystem (go with default options everywhere)
  5. zkstack chain create - create a new chain, stick to the default options, but select Validium when prompted, use this chain as default (the last question there)
  6. zkstack chain init - init the new chain
  7. configure the client, see section below
  8. zkstack server --chain YOUR_CHAIN_NAME - run the server

Production Deployment​

The production deployment should be similar to the local deployment. It will require setting up the eigenda client. See ZK Stack's production deployment docs for more information.

Client configuration​

Note: The docs below might be outdated. Please refer to the ZKSync Era EigenDA Client and its Config as the source of truth.

First you need to set the use_dummy_inclusion_data field in the file etc/env/file_based/general.yaml to true. This is a pending solution until our Stage 2 integration is complete.

da_dispatcher:
  use_dummy_inclusion_data: true

The client can be set up by modifying the field da_client of the file etc/env/file_based/overrides/validium.yaml. These are the fields that can be modified:

  • disperser_rpc (string): URL of the EigenDA Disperser RPC server. Available per network in our docs
  • operator_state_retriever_addr: Address of the OperatorStateRetriever contract. This address can be found by reading from the EigenDA Directory.
  • registry_coordinator_addr: Address of the Registry Coordinator contract. This address can be found by reading from the EigenDA Directory.
  • cert_verifier_router_addr: Address of the CertVerifierRouter contract. We deploy a default CertVerifier whose address can be found by reading from the EigenDA Directory, but any team desiring custom quorums and/or custom thresholds should read our Custom Security page.
  • eigenda_svc_manager_address (string): Address of the service manager contract.
  • blob_version: Specifies the BlobParams version to use. Currently only 0 is available. BlobVersions are defined in the ThresholdRegistry contract, whose address can be found by reading the from EigenDA Directory.

So, for example, a client setup that uses the sepolia EigenDA client would look like this:

da_client:
  client: Eigen
  disperser_rpc: https://disperser-testnet-sepolia.eigenda.xyz:443
  operator_state_retriever_addr: 0x22478d082E9edaDc2baE8443E4aC9473F6E047Ff
  registry_coordinator_addr: 0xAF21d3811B5d23D5466AC83BA7a9c34c261A8D81
  cert_verifier_router_addr: 0x17ec4112c4BbD540E2c1fE0A49D264a280176F0D
  blob_version: 0
note

When configuring your batching parameters, consult this batch sizing reference to understand encoding overhead and cost implications.

You also need to modify etc/env/file_based/secrets.yaml to include the private key of the account that will be used to pay for dispersals. You need to add the following field:

da:
  client: Eigen
  private_key: <PRIVATE_KEY> # without the `0x` prefix