> 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/measurements.md). # Measurements Recorded proof and settlement measurements with their dates, hardware and limits. The prover benchmark and the runs on Ostia measured different guests and workloads. The benchmark used the unmodified upstream reth guest. The Ostia runs used this repository's guest with its chain-rules check and the gateway. This page describes commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Read the full [metrics report](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md) and [demo results](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results). ## Hardware Both sets used one NVIDIA RTX PRO 6000 Blackwell Server Edition GPU. Only the GPU and driver were recorded for the Ostia demo. | Item | Prover benchmark, 2026-10-03 | Ostia runs, 2026-10-05 | | ------------------------- | -------------------------------------------------------------------------- | ---------------------- | | CPU | AMD EPYC 9B45, 48 vCPUs; one socket, two threads per core | Not recorded | | Host RAM | 176 GiB as reported by the host | Not recorded | | GPU memory | 97,887 MiB, described as 96 GB; PCIe gen 5 x16 | Capacity not recorded | | Driver | 580.178.04 | 580.178.04 | | CUDA | 13.0 at the driver level; prebuilt GPU binaries, no CUDA toolkit installed | Not recorded | | Operating system and disk | Ubuntu 22.04.5, 500 GB boot disk | Not recorded | | Node and snarkjs | 20.18.0 and 0.7.6 | Not recorded | ## Pinned versions These are the repository's versions, as listed in the metrics report and [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). The benchmark host's Node version above differs from the prover's pin. | Component | Version | | ------------------------------ | ---------------------------------------------------------------- | | ZisK | 1.3.1-alpha | | Upstream guest source | 0.13.1 | | reth | 2.5.2 | | Canton | 3.6.0-snapshot.20260930.20337.0.ve610bc8f | | Daml SDK for the external call | 3.5.13-snapshot.20261001.145.0.v852bdd82 | | Daml compiler | 3.6.0-snapshot.20260915.14804.0.v53478765, targeting Daml-LF 2.4 | | Daml SDK for Script tests | 3.5.12, targeting Daml-LF 2.1 | | Java | 21 | | Rust | 1.94.1 | | Builder and demo Python | 3.12 or newer | | Prover Node and snarkjs | 20.20.2 and 0.7.6 | | Explorer Node | 22.18 or newer locally; 24 in the container and CI | | Test-token Solidity compiler | 0.8.28 | ## Prover benchmark: 2026-10-03 The table gives median times in seconds from three warm runs for each block size. Each block contained plain transfers. Every proof passed `cargo-zisk verify`. The raw benchmark logs are not in the repository. | Block | Proof without wrap, fresh process | Wrap alone, fresh process | Proof with wrap, fresh process | Whole fresh process | Running prover: input to wrapped proof | Running prover: input to verified proof | | ------------------------- | --------------------------------- | ------------------------- | ------------------------------ | ------------------- | -------------------------------------- | --------------------------------------- | | 1 transfer, 21 kgas | 4.6 | 2.4 | 7.4 | 21.1 | 6.7 | 7.0 | | 1,000 transfers, 21 Mgas | 6.9 | 2.4 | 9.6 | 24.5 | 9.0 | 9.3 | | 5,000 transfers, 105 Mgas | 17.9 | 2.4 | 20.8 | 34.9 | 21.2 | 21.5 | The running prover kept the coordinator, worker and keys loaded. The fresh-process totals include starting and stopping the prover. Input-to-proof times start with an existing witness file; they do not measure building the witness. The 105 Mgas case was a benchmark of the upstream guest, not an Ostia block. Ostia's pinned block gas cap is 30,000,000. | Proof measurement | Wrapped PLONK | Unwrapped STARK | | ------------------------ | -------------------- | ------------------------ | | Proof file size | 2,942 to 2,944 bytes | 415,232 to 415,234 bytes | | `cargo-zisk verify` time | 0.29 to 0.30 s | 0.03 s | | Wire size | 1,344 bytes | Not measured | Verifying the wrapped proof includes starting Node to run snarkjs. It is not a measurement of the sidecar's native verifier. The 1,344-byte wire form contains 768 bytes of proof, 32 bytes of program key, 32 bytes of recursion root and 512 bytes of public values. ## Startup and memory These measurements are from the same 2026-10-03 benchmark with ZisK 1.3.1-alpha. | Measurement | Result | | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | First 1-transfer run after deleting ZisK's cache and dropping the page cache, with the proving key still on disk | 123 s wall time; proof work took 14.5 s | | Running prover startup with the guest's compiled cache already present | Keys loaded in 7.0 s, then 9.5 s to register the program | | First proof request after that startup | 6.56 s | | Peak GPU memory reported by `nvidia-smi` | 93.2 GiB | | Host RAM rise during a fresh-process proof | 27 to 29 GiB, plus 22.9 GiB of shared memory | | Host RAM rise while the running prover served requests | 3 GiB, plus 22.9 GiB of shared memory | | GPU memory reported for the PLONK wrap alone | 30,054,767,337 bytes, about 28.0 GiB | The prover sizes a large GPU buffer to the card. Peak use was about the same for the smallest and largest benchmark blocks. It does not establish the minimum GPU memory needed for the whole prover. ## Ostia demo: 2026-10-05 Each case ran once on the local Canton network, with the prover already running, from commit `6b445073163832e9023850f53678617d90dfc808`. These are individual test results. The [results folder](https://github.com/rome-protocol/canton-zk-evm/tree/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/results) holds the records. [Overview](/canton-zk-evm/canton-zk-evm.md#what-the-demo-showed) describes the five outcomes. | Case | Block and gas used | Proof | Finished proof file to builder exit | Whole builder run | | --------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------- | -------------------------------- | | Smoke | Block 1, empty; 0 gas | 6.31 s | 0.49 s | 155.20 s | | Setup | Block 2, two transactions; gas not recorded | 6.71 s | Not recorded | 8.00 s | | Deposit | Block 3, one transaction; 122,308 gas | 6.72 s | 0.66 s | 8.14 s | | Payment | Block 4, three transactions; 185,307 gas | 6.72 s | 0.42 s | 7.87 s | | Withdrawal | Block 5, one transaction; 90,345 gas | 6.72 s | 0.58 s | 8.02 s | | Allocation taken back | Block 6 refused, then rebuilt with one transaction and no legs; gas not recorded | 6.75 s for the refused build; second proof not timed separately | Refused submission not timed | 8.09 s refused; 8.04 s committed | | Tampered proof | Block 7 refused; gas not recorded | 6.74 s before tampering | Refused submission not timed | 7.57 s | Each proof was 1,344 bytes. The interval from the finished proof file to builder exit includes fetching the gateway's account and storage proofs, `Advance`, commit on both confirming participants and reth marking the block final. It is longer than Canton's commit alone. Matching legs to Canton contracts happens before proving and is outside that interval. The smoke test's whole run includes witness and input preparation and the prover's initial setup of the guest program. It may also include building the input tool. Separate times for those steps were not recorded. ## Other recorded checks On 2026-10-04, the first transfer proof covered block 1 on a temporary copy of the genesis, not a running chain: one 21,000-gas transfer and 385,277 guest steps. Three proofs took 6.33, 6.75 and 6.69 s. ZisK's verifier and the repository's verifier crate checked the proof. Changing the input's chain id to 1 made the guest refuse it without a proof. Building the guest from an empty build folder took 125 s, including dependency download. Two fresh checkouts took 133 s and 126 s and produced the same ELF and programVK as each other. The prover's first program setup took 43 s. These figures come from the 2026-10-04 records described in the metrics report and [guest README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md). After the 2026-10-05 demo, the explorer's browser check of block 3 passed in 13 ms. About 0.35 s elapsed from the click to the answer. This was one browser check, not a benchmark, and is not recorded in `demo/results/`. The WebAssembly check took 8 to 32 ms in Node on CI runners. That test verified a proof and then rejected a mismatched header. It was neither a successful full-block check nor a browser measurement; see the [verifier README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/verify/README.md). ## What these measurements do not establish There is no systematic benchmark of contract calls or precompiles, blocks above 105 Mgas, or the benchmark's block sizes with Ostia's guest. There are no measurements with multiple GPUs or multiple blocks in flight. Witness construction on a warm host, native sidecar verification and Canton's commit of a large block have not been timed separately. The demo committed blocks with at most three transactions and one leg. Each case ran once, so the results do not show how much timings vary between runs. --- # 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/measurements.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.