Orchestrating ZKsync proofs generation with Kalypso

# Orchestrating ZKsync proofs generation with Kalypso This blog outlines how Kalypso integrates with the ZKsync prover system in order to decentralize proof generation. We will cover the architectural components, data flow, and necessary modifications to enable seamless interaction between Kalypso and zkSync. ## Components 1. **Master Node**: Acts as the gateway and witness generator. 2. **Slave Node (Kalypso Generators)**: Generates witness vectors and includes a GPU/circuit prover. 3. **Compressor Node**: Runs the zkSync GPU compressor. 4. **Verifier**: Uses `boojum_verifier` for proof verification. 5. **Object Store**: A simple key-value store for storing proofs, witness inputs, and circuit binaries. ## Flow 1. The gateway polls the external prover API endpoint (`/proof_generation_data`) to fetch new `witness_input.bin` files, stores them in the object store, and simultaneously makes a smart contract call to store the witness input key on-chain. 2. The witness generator listens for smart contract events. Upon detecting a new witness input, it starts the witness generation process. 3. The witness generator retrieves the witness input from the object store, generates batches of jobs (each batch may contain 30+ jobs), uploads the generated circuits to the object store, and creates a new Kalypso ASK for the entire batch (e.g., a basic circuit round has ~15k jobs). 4. The matching engine assigns jobs to available slave nodes (provers). 5. Upon receiving a new ASK, the slave node generates witness vectors and forwards them to the GPU prover running on the same slave node to generate proofs. 6. Once the slave node generates proofs for all jobs in the batch, it sends the proof batch to the external verifier (`boojum_verifier`) via an API call. 7. The [boojum_verifier](https://github.com/KalypsoProver/boojum-verifier) verifies the proofs, generates an attestation for the batch, uploads the proofs to the object store, and returns the attestation along with the batch ID to the slave node that generated the proofs. 8. The slave node, upon receiving the attestation from the verification node, submits the batch ID and attestation via a smart contract call. 9. In the next round, the master node fetches the proofs from the object store and uses them for further job generation. 10. This process repeats for all rounds. At the end, the compressor node generates the final proof, forwards it to the verifier for attestation, and the verifiers uploads it to the object store. The verifier sends the attestation back to the compressor node, which submits the proof with attestation. 11. Once the proof is submitted by the compressor, the gateway on the master node listens for the `proof_submitted` event, fetches the final proof from the object store, and submits it to the zkSync network using the external prover API endpoint (`/submit_proof`). ## Required Modifications for Integrating Kalypso with the zkSync Prover System ### Gateway - Modify the gateway to submit smart contract calls for witness input submission. - Enable it to listen for `proof_submitted` transactions and submit proofs to the zkSync external prover API. ### Witness Generator - The current witness generator uses SQL queries and GCS as the object store to generate jobs and artifacts for the slave nodes. - Modify it to batch jobs for a round and generate Kalypso ASKs accordingly. ### Object Store - Implement a new object store to save and fetch witness inputs, circuits, and proofs. - This is required since we are not using GCS as the object store. ### Slave Node - Currently relies on database connections and GCS for artifacts. - Modify it to fetch proof generation data by listening to ASKs created by the master node. - Enable it to fetch artifacts from the object store and forward generated proofs to the verifier node. - Implement logic for submitting attestations on-chain to mark jobs as complete. ### Compressor Node - Modify it to interact with the object store, smart contracts, and the verifier node. ### Verifier Node - The `boojum_verifier` is currently a command-line tool. - Wrap it into an HTTP API server that: - Receives proofs. - Uploads valid proofs to the object store. - Returns attestations to the slave node.