> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/canton-zk-evm/prover-host.md).

# Prover host

The prover's host requirements, persistent worker and pinned guest build.

The prover runs ZisK with one GPU worker. The coordinator and worker remain running between requests, with the PLONK key already loaded. For each block, the builder sends input and receives a wrapped proof.

This page describes commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Read the full [prover README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) and [measurements](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## Host requirements

The installer targets Linux x86-64 with `apt`, `sudo`, an installed NVIDIA driver and about 100 GB of free disk. It installs system packages and changes memory-lock limits.

The 2026-10-03 benchmark used one NVIDIA RTX PRO 6000 Blackwell Server Edition with 96 GB of GPU memory, 48 vCPUs on an AMD EPYC 9B45, and 176 GiB of host RAM. It ran Ubuntu 22.04.5 with driver 580.178.04. These specifications describe the tested machine; they do not establish the minimum hardware needed to run the prover.

The benchmark recorded 22.9 GiB of emulator shared memory. The PLONK wrap alone reported a GPU requirement of 30,054,767,337 bytes, about 28.0 GiB. Peak GPU memory use was 93.2 GiB, but the prover sizes a large buffer to the card. That peak reflects the buffer allocation and does not show how much GPU memory the whole prover needs at minimum. See [Measurements](/canton-zk-evm/measurements.md) for the scope of each number.

## Build and run

The scripts use the versions in [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). The prover uses ZisK 1.3.1-alpha, Node 20.20.2 and snarkjs 0.7.6. The explorer's Node version is separate.

| Script                  | What it does                                                                                    |
| ----------------------- | ----------------------------------------------------------------------------------------------- |
| `prover/install.sh`     | Check the installer's pinned checksum, then install the GPU build, proving key and PLONK setup. |
| `prover/build-guest.sh` | Build the guest ELF and print its SHA-256, programVK, rootC and rules hash.                     |
| `prover/start.sh`       | Start the coordinator and one GPU worker with the PLONK key loaded.                             |
| `prover/make-input.sh`  | Turn a saved block, execution witness and genesis into prover input.                            |
| `prover/prove-one.sh`   | Prove one input, check the proof with `cargo-zisk`, and write the wrapped proof as hex.         |

`ZISK_COORDINATOR_URL` selects the coordinator. Its default is the coordinator on the same machine. `network/up.sh` builds the guest and starts the prover as part of the local network; follow [Run it locally](/canton-zk-evm/run-it-locally.md) for that sequence.

The builder defaults to `prover/prove-one.sh` through `CZE_PROVE_CMD`. That command receives an input file and output folder and must leave `wrapped-proof.hex`. Its local `cargo-zisk` check does not enforce the chain's pinned programVK and rootC. The confirmers' sidecars enforce those pins. See the [builder settings](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## Reproduce the guest key

The build script uses one fixed build folder and refuses an ELF that still contains a build path. Run one guest build at a time because each build empties that shared folder.

On 2026-10-04, two fresh checkouts built sequentially by one user on one machine produced the same ELF and programVK. The builds took 133 s and 126 s. To reproduce the build as another user or on another machine, check that the resulting programVK matches the recorded value. `network/up.sh` stops if the build's pins differ. The [guest README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) describes the build and its limits.

## Proof output

The wire format is 1,344 bytes: 768 bytes of PLONK proof, 32 bytes of programVK, 32 bytes of rootC and 512 bytes of public values. `prove-one.sh` writes the hex form and the JSON produced by `cargo-zisk-dev export-solidity-calldata`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/canton-zk-evm/prover-host.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.