> 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/prover-host.md).

# Prover ホスト

プローバーのホスト要件、永続ワーカー、固定されたゲストビルド。

prover は GPU ワーカー 1 台で ZisK を実行します。コーディネータとワーカーは、PLONK キーを読み込んだまま、リクエスト間も実行し続けます。各ブロックごとに、builder は入力を送り、ラップされた証明を受け取ります。

このページではコミットを説明します `a84e84e439a5cc669c0ae61facf7c8c995d9d564`。完全版を読む [prover README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) および [測定値](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## ホスト要件

インストーラは Linux x86-64 を対象としており、 `apt`, `sudo`、インストール済みの NVIDIA ドライバーと約 100 GB の空きディスク容量が必要です。システムパッケージをインストールし、メモリロック制限を変更します。

2026-10-03 のベンチマークでは、96 GB の GPU メモリを搭載した NVIDIA RTX PRO 6000 Blackwell Server Edition 1 台、AMD EPYC 9B45 上の 48 vCPU、そして 176 GiB のホスト RAM を使用しました。Ubuntu 22.04.5 とドライバー 580.178.04 で実行しました。これらの仕様はテスト対象マシンを示すものであり、prover を実行するのに必要な最小ハードウェアを示すものではありません。

ベンチマークでは、エミュレータ共有メモリ 22.9 GiB が記録されました。PLONK wrap だけで GPU 要件は 30,054,767,337 バイト、約 28.0 GiB と報告されました。GPU メモリ使用量のピークは 93.2 GiB でしたが、prover はカードに対して大きなバッファを確保します。そのピークはバッファ割り当てを反映したものであり、prover 全体に最低限どれだけの GPU メモリが必要かを示すものではありません。詳細は [測定](/ja/canton-zk-evm/measurements.md) 各数値の対象範囲について。

## ビルドして実行

スクリプトは次のバージョンを使用します: [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS)。prover は ZisK 1.3.1-alpha、Node 20.20.2、snarkjs 0.7.6 を使用します。explorer の Node バージョンは別です。

| スクリプト                   | 何をするか                                                        |
| ----------------------- | ------------------------------------------------------------ |
| `prover/install.sh`     | インストーラの固定チェックサムを確認し、その後 GPU ビルド、証明鍵、PLONK 設定をインストールします。      |
| `prover/build-guest.sh` | ゲスト ELF をビルドし、その SHA-256、programVK、rootC、rules ハッシュを出力します。   |
| `prover/start.sh`       | PLONK キーを読み込んだ状態で、コーディネータと GPU ワーカー 1 台を起動します。               |
| `prover/make-input.sh`  | 保存済みブロック、実行ウィットネス、genesis を prover 入力に変換します。                 |
| `prover/prove-one.sh`   | 1 つの入力を証明し、次で証明をチェックし、 `cargo-zisk`、ラップされた証明を hex として書き込みます。 |

`ZISK_COORDINATOR_URL` コーディネータを選択します。既定値は同一マシン上のコーディネータです。 `network/up.sh` ゲストをビルドし、ローカルネットワークの一部として prover を起動します。以下に従って [ローカルで実行する](/ja/canton-zk-evm/run-it-locally.md) その手順について。

builder の既定値は `prover/prove-one.sh` を通って `CZE_PROVE_CMD`。そのコマンドは入力ファイルと出力フォルダを受け取り、次を残さなければなりません `wrapped-proof.hex`。ローカルの `cargo-zisk` チェックでは、チェーンの固定 programVK と rootC は強制されません。confirmers のサイドカーがそれらの固定値を強制します。次を参照してください: [builder 設定](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## ゲスト鍵を再現する

build スクリプトは固定のビルドフォルダ 1 つを使用し、build パスが残っている ELF は拒否します。各ビルドでその共有フォルダが空になるため、guest ビルドは一度に 1 つだけ実行してください。

2026-10-04 に、1 人のユーザーが 1 台のマシンで新規チェックアウト 2 件を順番にビルドしたところ、同じ ELF と programVK が生成されました。ビルド時間は 133 秒と 126 秒でした。別のユーザーとして、または別のマシンでビルドを再現するには、生成された programVK が記録値と一致することを確認してください。 `network/up.sh` ビルドの固定値が異なる場合は停止します。 [guest README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) ビルドとその制約を説明します。

## 証明出力

ワイヤ形式は 1,344 バイトです: PLONK 証明 768 バイト、programVK 32 バイト、rootC 32 バイト、公開値 512 バイト。 `prove-one.sh` hex 形式と、次によって生成された JSON を書き込みます: `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/ja/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.