> 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/run-a-rollup.md).

# ロールアップを実行する

v0.3.0ロールアップランナーを使って、Solana devnet上に自分のRome ZK EVMチェーンを登録し、実行します。

その `./rollup` runner は Rome の共有 Solana devnet プログラムに対して 1 つのチェーンを開始します。ノードを運用し、Solana の費用を負担します。清算プログラムを自分でデプロイする必要はありません。登録は許可不要ですが、証明済みルートには Rome に登録されたチェーン固有の検証キーが必要です。

このページでは **v0.3.0**。 [完全な devnet ガイド](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) は、すべての設定、障害、復旧手順をカバーします。

## 開始する前に

bash 4 以上、Git、Compose 付きの Docker Engine 28 以上、curl、jq、openssl、Solana CLI、Python 3.11 以上を備えた x86-64 Linux マシンを使用してください。Solana devnet の RPC エンドポイント、資金供給済みの Solana payer キーペア（これはチェーンの権限でもあります）、およびシーケンサー署名キーが必要です。両方のファイルは秘密にし、コンテナユーザー 999 から読み取り可能にしておいてください。作成方法はこのガイドで説明します。

おおよそ **devnet 上で 7 SOL** を payer 用に用意してください。登録で 5 SOL がロックされます。 `./rollup check` 投稿と家賃のために少なくとも 1 SOL が残っていることを想定しています。最初の最終ルート、または 10 個の投稿済みルートの後に、そのデポジットは返金可能になります。その前にチェーンが回収されると、デポジットは treasury に渡ります。チェーンには、あなたが管理する EVM の fee-recipient アドレスも必要です。

ルートを確定するには、30 GB を超えるメモリを持つ NVIDIA GPU を 1 枚備えた prover ホストが必要です。24 GB のカードでは最終証明ステップには小さすぎます。 [Prover ホスト](/ja/rome-zk-evm/prover-host.md) は RAM とディスクの予算を定義します。ノードは prover の準備ができる前でも実行してバッチを公開できますが、そのルートはいずれも最終化されません。

## ノードを起動する

リリースをクローンし、その rollup ディレクトリから作業します。

```sh
git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git
cd solana-zk-evm/deploy/rollup
cp .env.example .env
cp chain.toml.example chain.toml
```

Solana RPC、署名者の場所、および `ROME_ZK_TAG=v0.3.0` で `.env`を設定します。 `PROGRAMS_JSON=programs.devnet.json`を保持してください。 `ROME_ZK_GUEST_TAG=v0.3.0` および `ZISK_RELEASE=1.3.1-alpha` は後の guest ビルド用です。最初のローカル実行では RPC をループバックにバインドしたままにしてください。 `PROVER` は、guest とそのキーが準備できるまで未設定のままにしてください。

設定して `genesis.fee_recipient` で `chain.toml` をあなたの EVM アドレスに設定します。チェーン ID は選ばないでください。清算では payer とその登録回数から ID が導出されます。 `init` は何かを送信する前にそれを読み取ります。全 ID の約半分は MetaMask には大きすぎます。もし自分の ID がその1つなら、 `init` で停止します `ChainIdNotWalletSafe`。新しい payer キーを作成し、 `PAYER_KEYPAIR_PATH` をそれに向けて設定し、 `init` を再実行してください。

新しいチェーンは残高ゼロで開始します。デポジットが開く前にガスを得るために backed balance を 1 つ宣言する場合は、検証キーを要求する前に同じ量の wrapped SOL をチェーンの vault にロックしてください。

```sh
./rollup init
./rollup register --dry-run
./rollup register --confirm
./rollup up
./rollup check
```

`init` は genesis とサービス設定をレンダリングします。 `register --confirm` は 5 SOL のデポジットをロックし、バッチカーソルを作成します。 `起動` すると、sequencer、batcher、derive、verifier ノードが起動します。 `確認` は不足しているサービス名を挙げ、その後チェーン ID、ヘッド、batcher の進捗、inbox、ルートを比較します。バッチが閉じるのを待った後で再度実行してください。最初のバッチ進捗チェックはサンプルを記録するだけです。

prover がない場合、sequencer は RPC を提供し、batcher はトランザクションデータを inbox に送信し、derive はチェーンを再構築します。inbox のバッチは最終的な清算ルートではありません。genesis ルートでさえ証明を待ちます。

## バッチから最終ルートへ移行する

チェーンの genesis 用に guest をビルドします。

```sh
./rollup guest-build
```

このビルドでは v0.3.0 の guest と ZisK 1.3.1-alpha を使用します。チェーンの guest プログラムと検証キーのメタデータを生成します。 `programVK` の計算には ZisK の proving keys と約 36 GB の RAM が必要です。チェーンを登録しても検証キーは登録されません。 [検証キー要求](/ja/rome-zk-evm/verification-key.md) をビルド後に送信してください。Rome はあなたの genesis と guest をチェックし、その後アクティベーションスロット付きでキーを登録します。

prover ホスト上で、 `PROVER=on` および完全な runbook に記載された guest、検証メタデータ、ZisK 設定を行ってください。キーが有効化された後：

```sh
./rollup init
./rollup up
./rollup check
```

確認してください `サービス prover` および `検証キー` の項目が合格することを。prover は inbox バッチを順番に処理します。各有効な証明は、Solana トランザクションが着地するとすぐに最終化されるルートを投稿します。

## 最初のブロックを作る

backed genesis balance がない場合、デポジットが開くまでチェーンにはトランザクション用の gas がありません。デポジットには最初の証明済みルートが必要です。デフォルトの `empty_block_interval_secs = 0` では、アイドル状態のチェーンはブロックを作らないため、 `60` 未満 `[profile]` で `chain.toml` に設定してください。キーが有効で prover が動作している後にレンダリングして再起動します。

```sh
./rollup init
./rollup up
./rollup check
```

最初のルートが最終化されたら、間隔を `0` に戻し、 `init` および `起動` を再実行してください。定期的な空ブロックを望まない場合を除きます。Rome がキーを登録するのを待っている間にそれらを有効にすると、バックログが発生します。すべてのバッチは順番に証明されなければなりません。

60 秒の空ブロック間隔と 60 秒のバッチクローズでは、チェーンは 1 分あたり約 1 バッチ、つまり 1 日あたり約 1,440 バッチを作ります。devnet では、証明済みルート 1 つのコストは payer にとって約 **0.003 SOL**でした。内訳は、保留アカウントの家賃約 0.002 SOL、清算手数料 0.001 SOL、さらにその上にトランザクション手数料です。この頻度では、inbox 投稿コストの前に 1 日あたり約 4.4 SOL です。デフォルト設定では、保留アカウントの家賃はロックされたままです。空ブロックをオフにすると、アイドル状態のチェーンはバッチを確定せず、投稿コストも発生しません。

デポジットを受け付けるには、次に vault を作成し、その遅延後に exit 設定を有効化し、デポジットキューを開きます。これらのコマンドと確認手順は [デポジットと出金](/ja/rome-zk-evm/deposits-and-withdrawals.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/run-a-rollup.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.
