Proof Generation

Generating ZK Proofs is a key component for any ZK Rollup, and it can often be the most painful part of operating a zk rollup.

Scroll SDK supports being run in two modes — one using mock finalization, the other requiring valid zk proofs to finalize. Mock finalization is useful for devnets and testnets, where the zk proof generation is an unnecessary cost beyond brief testing periods.

In its default configuration, testnets are without a ZK provers and simulate finalization. The L1 contract allows finalizing a batch without a valid proof, and the rollup-relay is configured to call the finalize method after 1 hour without a proof in the default configuration.

To change this mock finalization delay, adjust config.toml to change rollup.TEST_ENV_MOCK_FINALIZE_TIMEOUT from 3600 to the number of seconds you want to delay.

To disable mock finalization entirely, adjust config.toml to change TEST_ENV_MOCK_FINALIZE_ENABLED to false.

Outsourcing Proof Generation to External Service Providers

Teams shouldn’t need to become ZK infrastructure experts (or professional GPU sourcers) to run a chain. We’ve partnered with proof generation specialists to make outsoucing proof generation as easy as deploying one more chart.

Using a proof generation service offers the following benefits:

Generate proofs on-demand through API-based services
Choose between enterprise solutions or proof marketplaces
Scale proof generation elastically based on your actual usage instead of reserving a specific capacity
Maintain flexibility to switch between providers, distribute load between them, or run your own GPUs

The following providers already support generating Scroll SDK proofs:

Sindri
- Chart Repo
- Docs
Snarkify
- Chart Repo
- Docs

See the Enable Proof Generation using External Providers section of the Digital Ocean guide for an example of how to enable chunk, batch and bundle proofs using external providers.

Self-host a Prover

Our automation code for deploying a prover differs from the rest of the stack. Because Kubernetes is designed to automatically manage resources, it doesn’t fit as well as Ansible for larger clusters of machines needing specific machine requirements.

The Ansible playbook for running a prover is available in the GitHub repo here.

Prequisities

One ubuntu server with at least 256GB memory, 32 cores, and a GPU with at least 20GB memory.
One user with sudo access, no password, and all permissions — or you can change the shared-vars.yaml to add the ansible_become_password variable in your file.

Configuration

Change the values of rpc for mainnet or sepolia in shared-vars.yaml to your own.
Set the values of release_version and docker_tag — this is determined by the coordinator service.
Set the values in inventory for your `sepolia|mainnet’ and ‘chunk|batch’ provers.
Optionally, set the values of pj_path in shared-vars.yaml — the default is /prover/go-prover-docker, but can be changed to the value you want to customize.

How to deploy your prover

Be sure to set the correct value for the export statements below when setting environmental variables. Do not include brackets.

export env=[mainnet|sepolia]
export type=[chunk|batch]
export user=[your_ssh_user]

ansible-playbook  --ssh-extra-args='-o StrictHostKeyChecking=no' --private-key $your_key  prover-bootstrap.yaml  -u $user -e env=$env -e type=$type -i inventory/provers

# Reboot your prover manually, and finally launch this playbook
ansible-playbook  --ssh-extra-args='-o StrictHostKeyChecking=no' --private-key $your_key  prover-deploy.yaml  -u $user -e env=$env -e type=$type -i inventory/provers

Proof Generation