> 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/ja/canton-zk-evm/measurements.md).

# 測定

記録された証明と決済の計測結果、その日付、ハードウェア、制限。

prover ベンチマークと Ostia 上での実行では、異なる guest とワークロードを測定した。ベンチマークでは改変していない upstream の reth guest を使用した。Ostia の実行では、このリポジトリの guest を chain-rules チェックと gateway 付きで使用した。

このページではコミットを説明します `a84e84e439a5cc669c0ae61facf7c8c995d9d564`。完全版を読む [メトリクスレポート](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md) および [デモ結果](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results).

## ハードウェア

どちらのセットも NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を 1 枚使用した。Ostia デモでは GPU とドライバのみを記録した。

| 項目             | Prover ベンチマーク、2026-10-03                              | Ostia の実行、2026-10-05 |
| -------------- | ----------------------------------------------------- | -------------------- |
| CPU            | AMD EPYC 9B45、48 vCPU。1 ソケット、コアあたり 2 スレッド             | 未記録                  |
| ホスト RAM        | ホスト報告では 176 GiB                                       | 未記録                  |
| GPU メモリ        | 97,887 MiB、96 GB と表記；PCIe 第5世代 x16                    | 容量は未記録               |
| ドライバ           | 580.178.04                                            | 580.178.04           |
| CUDA           | ドライバレベルで 13.0；GPU バイナリは事前ビルド済みで、CUDA Toolkit は未インストール | 未記録                  |
| OS とディスク       | Ubuntu 22.04.5、500 GB のブートディスク                        | 未記録                  |
| Node と snarkjs | 20.18.0 と 0.7.6                                       | 未記録                  |

## 固定バージョン

これらはリポジトリのバージョンであり、メトリクスレポートおよび [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). 上記のベンチマークホストの Node バージョンは、prover の固定値とは異なる。

| コンポーネント                 | バージョン                                                            |
| ----------------------- | ---------------------------------------------------------------- |
| ZisK                    | 1.3.1-alpha                                                      |
| 上流の guest ソース           | 0.13.1                                                           |
| reth                    | 2.5.2                                                            |
| Canton                  | 3.6.0-snapshot.20260930.20337.0.ve610bc8f                        |
| 外部呼び出し用の Daml SDK       | 3.5.13-snapshot.20261001.145.0.v852bdd82                         |
| Daml コンパイラ              | 3.6.0-snapshot.20260915.14804.0.v53478765, targeting Daml-LF 2.4 |
| Script テスト用の Daml SDK   | 3.5.12, targeting Daml-LF 2.1                                    |
| Java                    | 21                                                               |
| Rust                    | 1.94.1                                                           |
| ビルダーとデモ用 Python         | 3.12 以降                                                          |
| Prover Node と snarkjs   | 20.20.2 と 0.7.6                                                  |
| Explorer Node           | ローカルでは 22.18 以降；コンテナと CI では 24                                   |
| テストトークン用 Solidity コンパイラ | 0.8.28                                                           |

## Prover ベンチマーク：2026-10-03

この表は、各ブロックサイズについて 3 回のウォームランの中央値を秒単位で示す。各ブロックには単純な送金のみが含まれていた。すべての証明は cargo-zisk verify を通過した `cargo-zisk verify`. 生のベンチマークログはリポジトリに含まれていない。

| ブロック                | wrap なしの証明、新規プロセス | wrap のみ、新規プロセス | wrap ありの証明、新規プロセス | 新規プロセス全体 | 実行中の prover：wrap された証明への入力 | 実行中の prover：検証済み証明への入力 |
| ------------------- | ----------------- | -------------- | ----------------- | -------- | -------------------------- | ---------------------- |
| 1 件の送金、21 kgas      | 4.6               | 2.4            | 7.4               | 21.1     | 6.7                        | 7.0                    |
| 1,000 件の送金、21 Mgas  | 6.9               | 2.4            | 9.6               | 24.5     | 9.0                        | 9.3                    |
| 5,000 件の送金、105 Mgas | 17.9              | 2.4            | 20.8              | 34.9     | 21.2                       | 21.5                   |

実行中の prover では、coordinator、worker、keys を読み込んだままにした。新規プロセスの合計には prover の起動と停止が含まれる。入力から証明までの時間は、既存の witness ファイルから開始しており、witness の生成は測定していない。105 Mgas のケースは upstream guest のベンチマークであり、Ostia のブロックではない。Ostia の固定ブロック gas 上限は 30,000,000 である。

| 証明の測定                  | wrap された PLONK  | wrap なし STARK       |
| ---------------------- | --------------- | ------------------- |
| 証明ファイルサイズ              | 2,942～2,944 バイト | 415,232～415,234 バイト |
| `cargo-zisk verify` 時間 | 0.29～0.30 秒     | 0.03 秒              |
| ワイヤサイズ                 | 1,344 バイト       | 未測定                 |

wrap された証明の検証には、snarkjs を実行するための Node の起動も含まれる。これは sidecar のネイティブ verifier の測定ではない。1,344 バイトの wire 形式には、768 バイトの証明、32 バイトの program key、32 バイトの recursion root、512 バイトの公開値が含まれる。

## 起動とメモリ

これらの測定は、ZisK 1.3.1-alpha を用いた同じ 2026-10-03 ベンチマークからのものだ。

| 測定                                                                  | 結果                               |
| ------------------------------------------------------------------- | -------------------------------- |
| ZisK のキャッシュを削除しページキャッシュを解放した後、proving key をディスク上に残したまま行った最初の 1 送金実行 | 壁時計時間 123 秒；証明処理は 14.5 秒         |
| guest のコンパイル済みキャッシュがすでに存在する状態での running prover 起動                   | キーの読み込みに 7.0 秒、その後プログラム登録に 9.5 秒 |
| その起動後の最初の証明リクエスト                                                    | 6.56 秒                           |
| によって報告された GPU メモリのピーク `nvidia-smi`                                  | 93.2 GiB                         |
| 新規プロセスの証明中のホスト RAM 増加                                               | 27～29 GiB、加えて 22.9 GiB の共有メモリ    |
| running prover がリクエストを処理している間のホスト RAM 増加                            | 3 GiB、加えて 22.9 GiB の共有メモリ        |
| PLONK wrap のみで報告された GPU メモリ                                         | 30,054,767,337 バイト、約 28.0 GiB    |

prover はカード上に大きな GPU バッファを割り当てる。ピーク使用量は、最小ブロックでも最大ブロックでもほぼ同じだった。これは prover 全体に必要な最小 GPU メモリを示すものではない。

## Ostia デモ：2026-10-05

各ケースは、prover をすでに起動した状態で、ローカルの Canton ネットワーク上で 1 回ずつ実行された。コミット `6b445073163832e9023850f53678617d90dfc808`. これらは個別のテスト結果である。その [results フォルダ](https://github.com/rome-protocol/canton-zk-evm/tree/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/results) が記録を保持している。 [概要](/ja/canton-zk-evm/canton-zk-evm.md#what-the-demo-showed) は 5 つの結果を説明している。

| ケース      | ブロックと使用 gas                                           | 証明                                  | 完了した証明ファイルから builder 終了まで | builder 実行全体            |
| -------- | ----------------------------------------------------- | ----------------------------------- | ------------------------- | ----------------------- |
| スモーク     | ブロック 1、空；0 gas                                        | 6.31 秒                              | 0.49 秒                    | 155.20 秒                |
| セットアップ   | ブロック 2、2 件のトランザクション；gas は未記録                          | 6.71 秒                              | 未記録                       | 8.00 秒                  |
| 預け入れ     | ブロック 3、1 件のトランザクション；122,308 gas                       | 6.72 秒                              | 0.66 秒                    | 8.14 秒                  |
| 支払い      | ブロック 4、3 件のトランザクション；185,307 gas                       | 6.72 秒                              | 0.42 秒                    | 7.87 秒                  |
| 引き出し     | ブロック 5、1 件のトランザクション；90,345 gas                        | 6.72 秒                              | 0.58 秒                    | 8.02 秒                  |
| 割り当て返却   | ブロック 6 は拒否され、その後 1 件のトランザクションと leg なしで再構築された；gas は未記録 | 拒否されたビルドは 6.75 秒；2 回目の証明は個別に計測していない | 拒否された送信は計測せず              | 拒否時 8.09 秒；コミット時 8.04 秒 |
| 改ざんされた証明 | ブロック 7 は拒否された；gas は未記録                                | 改ざん前は 6.74 秒                        | 拒否された送信は計測せず              | 7.57 秒                  |

各証明は 1,344 バイトだった。完了した証明ファイルから builder 終了までの区間には、gateway のアカウント証明とストレージ証明の取得が含まれる、 `進行`両方の確認参加者による commit と、reth によるブロック final 化も含まれる。これは Canton の commit のみより長い。legs を Canton のコントラクトに対応付ける処理は proving 前に行われ、この区間の外である。

スモークテストの実行全体には、witness と入力の準備、および prover による guest プログラムの初期セットアップが含まれる。入力ツールのビルドも含まれる場合がある。これらの手順の個別時間は記録されていない。

## その他の記録済みチェック

2026-10-04 には、最初の送金証明が稼働中のチェーンではなく genesis の一時コピー上のブロック 1 を対象とした：21,000 gas の送金 1 件と 385,277 guest ステップ。3 つの証明は 6.33、6.75、6.69 秒だった。ZisK の verifier とリポジトリの verifier crate が証明を検証した。入力の chain id を 1 にすると、guest は証明なしでそれを拒否した。

空の build フォルダから guest をビルドするのに 125 秒かかり、依存関係のダウンロードも含まれる。2 つの新規 checkout は 133 秒と 126 秒かかり、互いに同一の ELF と programVK を生成した。prover の最初のプログラムセットアップには 43 秒かかった。これらの数値は、メトリクスレポートおよび [guest README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md).

2026-10-05 のデモ後、explorer のブラウザによるブロック 3 のチェックは 13 ms で成功した。クリックから応答まで約 0.35 秒かかった。これは 1 回のブラウザチェックであり、ベンチマークではなく、 `demo/results/`.

CI ランナー上の Node での WebAssembly チェックには 8～32 ms かかった。このテストは証明を検証し、その後に不一致のヘッダーを拒否した。これは成功したフルブロックチェックでもブラウザ測定でもない； [verifier README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/verify/README.md).

## これらの測定が示さないこと

Ostia の guest を用いた、コントラクト呼び出しや precompile、105 Mgas を超えるブロック、あるいはベンチマークのブロックサイズについての体系的なベンチマークはない。複数 GPU や複数ブロックを同時に処理する測定もない。

ウォームなホスト上での witness 構築、ネイティブ sidecar の検証、および Canton による大きなブロックの commit は個別には計測していない。デモでは最大 3 件のトランザクションと 1 つの leg を含むブロックを commit した。各ケースは 1 回ずつしか実行していないため、結果は実行ごとの時間のばらつきを示していない。


---

# 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/ja/canton-zk-evm/measurements.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.