This section summarizes the changes from the generalized ZK-rollup architecture that are required to integrate a ZK rollup with the Espresso Sequencer. 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 the Espresso Sequencer.
Modify JSON-RPC or analogous server to forward transactions from users to the Espresso Sequencer. Choose a numeric ID for your rollup and attach it to the forwarded transactions.
Modify executor to stream notifications of new blocks from either:
Change the interface of the state transition proof, replacing the rollup block or block commitment input with an Espresso Sequencer block commitment.
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 Sequencer SDK can help define these additional constraints.
(Optional) Extend the proof to encode a deterministic reordering of the transactions provided by the Espresso Sequencer.
Update the prover to generate the new type of proof.
(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.
(If applicable) Update off-chain proof verifiers (validators or light clients) in the analogous way.