> 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/how-it-works.md).

# 仕組み

EVMブロックを、Solanaへのデータ投稿、ZisKによる証明、最終的な確定まで追います。

あなたの sequencer は JSON-RPC 経由で EVM トランザクションを受け付けます。署名、nonce、資金、gas を確認し、受け付けたトランザクションを到着順に実行します。署名済みのサブブロックとそのトランザクションを、プレコンファメーションを返す前に、永続的な順序付きログへ書き込みます。sequencer は reth を組み込んでチェーンのブロックを生成します。

プレコンファメーションは、sequencer が何を受け付け、どの順に並べたかを知らせます。これは最終的な Solana root ではありません。残りの経路がデータを公開し、それを実行すると主張された状態が得られることを証明します。

```
EVMトランザクション -> sequencer -> 順序付きログ -> batcher -> Solana inbox
Solana inbox -> derive -> reth-verifier -> ブロック + ウィットネス
ブロック + ウィットネス -> prover (ZisK batch guest) -> 証明 + root
証明 + root -> Solana settlement (PostRootProved) -> 最終 root
```

## ブロックからインボックスバッチへ

batcher は順序付きログから連続したブロックを読み取ります。例では `chain.toml` 60 ブロック、または最初のブロックから 60 秒のどちらか早い方でバッチを閉じます。バッチをフレームに圧縮し、そのフレームを Solana 上の inbox チャンクとして投稿し、その後バッチの Merkle コミットメントを確定します。

インボックス・コミットメントは、チェーン ID とバッチ ID、開始スロット、チャンク数、チャンクの Merkle ルート、およびバッチのデポジット範囲を含みます。インボックスバッチを確定するということは、そのデータが投稿済みであることを意味します。これは状態 root を最終確定にするものではありません。チェーンの権限者がバッチの確定に署名します。

バッチャーはブロック番号を飛ばせません。決済も次のバッチを順番に取り込みます。そのため、停止したままの、または放棄されたバッチは後続の root をブロックします。バッチャーは、再起動後に復元できる場合、同じ番号の部分的に書き込まれたバッチを再開します。

## 抽出、検証、証明

`抽出` Solana から最終確定済みのインボックスバッチを読み取ります。ブロックを再構成し、別の `reth-verifier` ノードを起動して、それらを再実行します。このノードは、バッチ prover が必要とする実行ウィットネスと、exit prover が必要とする状態証明を提供します。これは reth のテスト用 API を実行するため、公開ネットワークから切り離しておく必要があります。

prover は各最終確定済みインボックスバッチを読み取り、verifier ノードからブロックとウィットネスを取得し、チェーンの batch guest を ZisK で実行します。guest は、ブロックが inbox データと一致し、正しく実行されることを確認します。結果の状態 root を含むバッチの公開値をコミットします。あなたの genesis と fee recipient はこの guest にコンパイルされているため、各チェーンには独自の guest があり、 `programVK`.

prover はローカルで証明を検証し、その後 `PostRootProved`。決済プログラムは、このチェーンに登録された有効な検証キーと、そのキーが指す ZisK リリースをチェックします。また、証明の公開値を chain ID、ブロック範囲、前任者、inbox コミットメント、および主張された root と照合します。

Veritas は Rome の ZisK PLONK 証明用 verifier です。決済はその verifier コードをリンクし、内部で実行します `PostRootProved`；別途デプロイされた Veritas プログラムは呼び出しません。有効な証明は、 `最終` root を書き込み、同じ Solana トランザクション内で finality head を進めます。permissionless チェーンの genesis root は、それだけでは最終ではありません。最初の最終 root には証明済みバッチが必要です。

## 資金が境界を越える

入金は Solana 上で始まります。ブリッジプログラムが、預けられたトークンを預け主からそのチェーンの vault に移し、番号付きの入金記録を追加します。sequencer は最終確定済みの Solana 入金を読み取り、指定された EVM アドレスに順番に入金を反映します。batcher はそのバッチに deposit 範囲をコミットします。残高はそのブロックが確定するとチェーン上に現れますが、そのクレジットが最終となるのは、そのバッチの root が Solana 上で証明されたときだけです。

出金はチェーン上の exit portal で始まります。portal はメッセージを記録し、ネイティブ資産を焼却します。exit prover はそのメッセージを監視し、最終 root に対する verifier ノードから Ethereum ストレージ証明を取得します。証明をローカルで検証し、その後 `ProveExit` を Solana 決済へ送信します。

決済は portal、メッセージ、最終 root、exit cap を確認し、同じ exit が二度証明されるのを防ぎます。exit prover はその後、ブリッジの解放トランザクションを送信します。ブリッジは証明済みの exit を消費し、そのチェーンの vault から受取人に 1 回の原子的トランザクションで支払います。受取人は証明済みレコードから取得されるため、解放を送る人はそれを変更できません。

全文を読む [v0.3.0 アーキテクチャ](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.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/how-it-works.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.