> 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/rome-zk-evm/prover-host.md). # Prover host Size and prepare the GPU host that proves Rome ZK EVM batches with ZisK 1.3.1-alpha. The node can sequence transactions and post batches without a GPU. It needs a prover to make any root final on Solana. In v0.3.0 the prover runs ZisK 1.3.1-alpha with the guest built for your chain's genesis. It proves inbox batches one at a time, checks each proof locally, then posts it to settlement. The [full prover-host guide](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) has the setup and recovery steps. Use it with the [devnet runbook](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Size the host Use x86-64 Ubuntu 22.04 or later and one NVIDIA GPU with more than 30 GB of memory. The setup script accepts a GPU with about 32.2 GB or more. The final proof step asks for about 30 GB, so a 24 GB card is too small. The NVIDIA driver must be at least 525.60.13. Allow at least **128 GB of RAM** and **125 GB free disk** at the ZisK install location. The 1.3.1-alpha proving-key archive is 5.1 GB and the PLONK-key archive is 21.9 GB. After setup generated its constant files, the two key directories measured 21 GiB and 26 GiB. The first proof adds cache files. A CPU host measured 102.1 GB total after one proof, and GPU cache growth has not been measured. The 1.3.1-alpha proving library reported 24.7 GB for its main working buffer and 5.6 GB for recursion on a batch of about 3 million steps. The whole-process peak on this release was not recorded. The devnet GPU run used a host with 176 GB of RAM; its peak RAM use was not recorded either. Use 128 GB as a sizing estimate, not a measured peak. ## What was measured One nearly empty batch took about **17 seconds**, including the PLONK wrap, on a host with one **96 GB RTX PRO 6000**, 48 CPU cores and 176 GB of RAM. About 95 GB of GPU memory showed as in use. That is what this run held, not the minimum GPU memory for every batch. Larger batches have not been timed on a GPU. Rome cleared 116 nearly empty devnet batches in about 35 minutes on that GPU. That matters when a chain has produced empty blocks while waiting for its verification key: the prover must work through them in order before it can reach newer state. ## Run the setup script Install the NVIDIA driver and reboot if needed. From the repository root, run the release's script as root. Set `ZISK_HOME` to the directory where ZisK and its keys will live. Use the same value in your rollup `.env`: ```sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh --check ``` The script installs the ZisK GPU build, its proving and PLONK keys, the system libraries it needs, and Docker's NVIDIA runtime. It sets the locked-memory limit to unlimited. Log out and back in so that limit applies to your shell. It then checks the GPU and driver, installed binaries, keys, memory limit and container runtime. Before running the installer, it checks the installer's SHA-256. It checks both key archives before unpacking either one, and checks the installed `cargo-zisk` and `cargo-zisk-dev` GPU binaries before the script runs them. It generates the constant files needed for aggregation and PLONK proving. If a run fails, run the script again. It skips the key download when the installed keys already match the pinned manifest. The script does not check every part of the ZisK install. The installer fetches a binary bundle and runs its toolchain installer before the script checks the two installed GPU binaries. Other executables and source files in that bundle are not hash-checked by this script. The full guide states this limit and has the commands for checking each download separately. ## Connect it to your chain The prover needs the matching guest ELF, its verification metadata, and the same 1.3.1-alpha proving keys. Set `PROVER=on` and the guest and ZisK settings in the rollup configuration, then run `./rollup init` and `./rollup up`. The first run builds the prover image from the v0.3.0 source. The node image alone does not contain the prover. Before every start, the prover checks the installed proving keys against the pinned SHA-256 manifest. That check covers file names and contents. Generated constant-tree and GPU constant files are excluded because they differ by host. A mismatch stops the prover with `KeysShaMismatch`. Do not change the manifest just to make a mismatched install start; install the release that matches the chain's guest and registered key. Run `./rollup check` after starting. It checks the prover service, the active verification key, and settlement and prover lag. The [monitoring guide](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) lists the local metrics and useful alert conditions. --- # 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/rome-zk-evm/prover-host.md?ask=&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.