Summary of Changes

This section summarizes the changes from the generalized ZK-rollup architecture that are required to integrate a ZK rollup with Espresso. Though the changes are presented in terms of an abstracted architecture, if you can map this abstraction onto your specific ZK rollup, you can derive a very concrete to-do list for integrating your rollup with Espresso.

  1. Modify JSON-RPC or analogous server to forward transactions from users to Espresso. Choose a numeric ID for your rollup and attach it to the forwarded transactions.

  2. Modify executor to stream notifications of new blocks from either:

    • The streaming availability API

    • Events emitted by the sequencer contract

  3. Modify the executor to download full blocks, or rollup-specific subsets of blocks, from the sequencer availability API.

  4. Change the interface of the state transition proof, replacing the rollup block or block commitment input with a HotShot block commitment.

  5. Extend the proof to encode a proof of completeness and inclusion of the rollup block relative to the block commitment. For a ZK proof system formalized the usual way, in terms of constraints on an arithmetic circuit, this means adding more wires and constraints so that the circuit checks the inclusion/completeness proof, which becomes a witness to the circuit. Once released, the Espresso SDK can help define these additional constraints.

  6. (Optional) Extend the proof to encode a deterministic reordering of the transactions provided by Espresso.

  7. Update the prover to generate the new type of proof.

  8. (If applicable) Update the on-chain proof verifier to check the new kind of proof. This generally involves replacing the preprocessed representation of the circuit. The contract will also need to accept a Merkle proof showing that the new block commitment input to the proof matches the corresponding block commitment in the Merkle tree maintained by the sequencer contract. Alternatively, the verification of this Merkle proof can be embedded in the circuit.

  9. (If applicable) Update off-chain proof verifiers (validators or light clients) in the analogous way.

Last updated