> 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/rome-zk-evm/prover-host.md). # Prover ホスト ZisK 1.3.1-alphaでRome ZK EVMバッチを証明するGPUホストのサイズを決め、準備します。 ノードは GPU なしでトランザクションを順序付けし、バッチを投稿できます。Solana で任意のルートを最終確定させるには prover が必要です。v0.3.0 では prover は ZisK 1.3.1-alpha を、チェーンのジェネシス用にビルドされた guest とともに実行します。inbox バッチを 1 つずつ証明し、各証明をローカルで検証してから、settlement に投稿します。 その [完全な prover-host ガイド](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) にはセットアップと復旧手順があります。次と併せて使用してください。 [devnet 実行手順書](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## ホストのサイズを見積もる x86-64 Ubuntu 22.04 以降と、30 GB 超のメモリを持つ NVIDIA GPU 1 枚を使用してください。セットアップスクリプトは約 32.2 GB 以上の GPU を受け入れます。最終的な証明ステップでは約 30 GB を要求するため、24 GB カードでは小さすぎます。NVIDIA ドライバは 525.60.13 以上である必要があります。 少なくとも次を確保してください **128 GB の RAM** および **125 GB の空きディスク** ZisK のインストール先で。1.3.1-alpha の proving-key アーカイブは 5.1 GB、PLONK-key アーカイブは 21.9 GB です。セットアップで定数ファイルが生成された後、2 つのキー ディレクトリは 21 GiB と 26 GiB でした。最初の証明でキャッシュファイルが追加されます。CPU ホストでは 1 回の証明後に合計 102.1 GB になりましたが、GPU キャッシュの増加は測定されていません。 1.3.1-alpha の証明ライブラリは、約 300 万ステップのバッチで、主作業バッファに 24.7 GB、再帰に 5.6 GB を要すると報告しました。このリリースでのプロセス全体のピークは記録されていません。devnet の GPU 実行では 176 GB の RAM を持つホストを使用しましたが、その RAM 使用量のピークも記録されていません。サイズ見積もりには 128 GB を使ってください。測定されたピークではありません。 ## 測定された内容 ほぼ空のバッチ 1 件には約 **17 秒**かかりました。PLONK ラップを含み、ホストは **96 GB の RTX PRO 6000**を 1 枚、CPU コア 48、RAM 176 GB を備えていました。約 95 GB の GPU メモリが使用中として表示されました。これはこの実行での使用量であり、すべてのバッチに対する GPU メモリの最小値ではありません。大きなバッチは GPU で計測されていません。 Rome はその GPU 上で、ほぼ空の devnet バッチ 116 件を約 35 分で処理しました。これは、チェーンが検証キーを待っている間に空ブロックを生成していた場合に重要です。prover はより新しい状態に到達する前に、それらを順番に処理しなければなりません。 ## セットアップスクリプトを実行する NVIDIA ドライバをインストールし、必要なら再起動してください。リポジトリのルートから、リリースのスクリプトを root で実行します。次を設定します。 `ZISK_HOME` を、ZisK とそのキーを置くディレクトリに設定します。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 ``` このスクリプトは、ZisK の GPU ビルド、その proving キーと PLONK キー、必要なシステムライブラリ、および Docker の NVIDIA runtime をインストールします。locked-memory の制限を無制限に設定します。この制限をシェルに反映させるには、いったんログアウトして再ログインしてください。その後、GPU とドライバ、インストール済みバイナリ、キー、メモリ制限、およびコンテナ runtime を確認します。 インストーラーを実行する前に、その SHA-256 を確認します。どちらかを展開する前に両方のキーアーカイブを確認し、さらにインストール済みの `cargo-zisk` および `cargo-zisk-dev` GPU バイナリをスクリプトが実行する前に確認します。集約と PLONK proving に必要な定数ファイルを生成します。実行が失敗した場合は、もう一度スクリプトを実行してください。インストール済みキーが固定された manifest とすでに一致している場合は、キーのダウンロードをスキップします。 このスクリプトは ZisK インストール全体のすべてをチェックするわけではありません。インストーラーはバイナリバンドルを取得し、スクリプトが 2 つのインストール済み GPU バイナリを確認する前に、そのツールチェーンインストーラーを実行します。そのバンドル内の他の実行可能ファイルやソースファイルは、このスクリプトではハッシュ検証されません。完全ガイドにはこの制限が記載されており、各ダウンロードを個別に確認するコマンドがあります。 ## チェーンに接続する prover には、対応する guest ELF、その検証メタデータ、および同じ 1.3.1-alpha proving keys が必要です。次を設定します。 `PROVER=on` および rollup 設定内の guest と ZisK の設定を行い、その後 `./rollup init` および `./rollup up`。最初の実行では v0.3.0 ソースから prover イメージをビルドします。node イメージだけには prover は含まれていません。 開始する前に、prover はインストール済みの proving keys を固定された SHA-256 manifest と照合します。そのチェックはファイル名と内容を対象にします。ホストごとに異なるため、生成された constant-tree と GPU 定数ファイルは除外されます。不一致があると prover は `KeysShaMismatch`で停止します。チェーンの guest と登録済みキーに合うリリースを入れずに、食い違ったインストールを動かすためだけに manifest を変更しないでください。 実行します： `./rollup check` 開始後に。prover サービス、アクティブな検証キー、および settlement と prover の遅延を確認します。 [監視ガイド](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) には、ローカルメトリクスと有用なアラート条件が一覧されています。 --- # 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/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.