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.
  • settlement_layer_confirmation_depth (unsigned number): Block height needed to reach in order to consider the blob finalized. A value less or equal to 0 means that the disperser will not wait for finalization.
  • eigenda_eth_rpc (optional string): URL of the Ethereum RPC server. If the value is not set, the client will use the same rpc as the rest of the zk server.
  • eigenda_svc_manager_address (string): Address of the service manager contract.
  • wait_for_finalization (boolean): Wait for the blob to be finalized before returning the response.
  • authenticated (boolean): Authenticated dispersal. If true, the client will use the authentication mechanism, using a whitelisted account. Using non authenticated dispersal is not recommended, as to many requests to the EigenDA disperser leeds to timeouts. (the following two fields are mutually exclusive)
  • points_source_path (string): Path to the local points source files.
  • points_source_url (string): URLs of the points source files.
  • custom_quorum_numbers (optional list of numbers): quorums to be used beside the default ones.

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

eigen:
  disperser_rpc: https://disperser-holesky.eigenda.xyz:443
  settlement_layer_confirmation_depth: 0
  eigenda_eth_rpc: https://ethereum-holesky-rpc.publicnode.com
  eigenda_svc_manager_address: 0xD4A7E1Bd8015057293f0D0A557088c286942e84b
  wait_for_finalization: false
  authenticated: false
  points_source_url:
    g1_url: https://github.com/Layr-Labs/eigenda-proxy/raw/2fd70b99ef5bf137d7bbca3461cf9e1f2c899451/resources/g1.point
    g2_url: https://github.com/Layr-Labs/eigenda-proxy/raw/2fd70b99ef5bf137d7bbca3461cf9e1f2c899451/resources/g2.point.powerOf2
  # custom_quorum_numbers: 2,3 # uncomment to use other quorums besides defaults

If using authenticated dispersal, you also need to modify etc/env/file_based/secrets.yaml to include the private key of the account that will be used. You need to add the following field:

da:
  eigen:
    private_key: <PRIVATE_KEY>

Note: the private key should be in hex format, without the 0x prefix.