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

# 仕組み

rethから証明を経てCantonへのコミットに至るまで、1つのOstiaブロックを追います。

各ビルダー実行は1つのブロックを生成し、証明し、送信します。Cantonがそのブロックをチェーンの次のヘッドにするかどうかを決定します。EVMブロックと、それに記録されたCantonのレッグは同じトランザクションでコミットされます。

このページではコミットを説明します `a84e84e439a5cc669c0ae61facf7c8c995d9d564`。完全版を読む [設計](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
flowchart TD
    W["EVMトランザクション"] --> R["rethが要求に応じてビルドする"]
    R --> B["ビルダーはゲートウェイのレッグを読み取り、それらのCantonコントラクトを見つける"]
    B -->|"1つのレッグは決済できない: そのトランザクションを除外して再ビルドする"| R
    B -->|"すべてのレッグを決済できる"| P["ZisKがブロックを証明する"]
    P --> A["進行: ブロック、証明、レッグを1つのCantonトランザクションに"]
    A --> S["外部呼び出し: サイドカーが証明とゲートウェイ状態を確認する"]
    S --> D["Damlがヘッドを確認し、レッグを決済する"]
    D --> C["Cantonがブロックとそのレッグをまとめてコミットする"]
    C --> F["rethがブロックをファイナライズ済みとしてマークする"]
```

## Cantonのヘッド上でビルドする

ウォレットはEVMトランザクションをrethに送信します。提供されたランチャーはピア探索を無効にしたままにします。ビルダーが求めると、rethはブロックを作成します。

ビルダーはまず有効な `ZkChain` Canton上のコントラクトを読み取ります。rethのhead、safeブロック、finalizedブロックをそのコミット済みヘッドに移動します。価格順に保留中のトランザクションを選び、各送信者のnonce順を維持し、ガス上限内に収めます。その明示的なトランザクション一覧でビルドするようrethに依頼します。

Cantonでのアクションを必要とするEVMトランザクションはゲートウェイを呼び出します。ゲートウェイはレッグを記録し、ブロック用の累積ハッシュに取り込みます。ビルダーはゲートウェイのイベントをログ順に読み取り、各レッグに必要なCantonコントラクトを見つけます。

割り当てがなくなっている場合、受取人が出金を承認していない場合、または必要な別のコントラクトが欠けている場合、ビルダーはそのトランザクションとその送信者の後続トランザクションを除外します。rethをCantonのヘッドに戻して、もう一度ビルドします。これらのチェックは証明の前に行われます。その [builder README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) 各レッグごとのチェックを一覧表示します。

## ブロックを証明する

ビルダーはブロックとrethの実行ウィットネスを保存します。入力ツールはブロック、ウィットネス、genesisをプローバー入力にまとめます。ZisKはゲストを実行し、チェーンの固定ルールの下でブロックを検証します。

プローバーは、ブロックハッシュにコミットする1,344バイトのラップ済み証明を返します。ビルダーは送信します `進行` ヘッダー、トランザクション、証明、レッグ、そしてブロックのステートルートにあるゲートウェイのアカウント証明とストレージ証明とともに。

## 1つのトランザクションで確認し、決済する

各確認参加者はサイドカーを実行します。Cantonの外部呼び出しは、その参加者のサイドカーにブロックを送信し、 `検証`。証明、固定されたプログラムキーとZisKリリース、ヘッダーのハッシュ、およびトランザクションリストのルートを確認します。

Damlはその答えを `ZkChain`: 親は現在のヘッドでなければならず、番号は次のものでなければならず、ガスリミットと使用ガスは上限内に収まらなければなりません。Damlはサイドカーの回答を比較し、ゼロ知識証明そのものは検証しません。

その後Damlは、名前を挙げたCantonコントラクトから各レッグごとに1行を書き込みます。出金のID、burner、金額はビルダーから取得されます。証明済みのハッシュが、それらをブロックに記録された内容に結び付けます。サイドカーの `レッグ` 関数はゲートウェイのアカウント証明とストレージ証明を確認し、それらの行を順番にハッシュ化して、証明済み状態におけるゲートウェイの値と照合します。レッグのないブロックも、空のリストで同じチェックに合格しなければなりません。

Damlはレッグを順番に決済し、 `BlockRecord` および次の `ZkChain`。Cantonはこれらの変更をまとめてコミットします。チェックまたは決済が失敗すると、何もコミットされません。チェーンの単一の状態コントラクトを消費することで、Cantonはブロック順序の権威となります。全文を参照してください [Daml インターフェース](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) および [サイドカーチェック](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Cantonが拒否したとき

Cantonがブロックをコミットした後、ビルダーはrethでそれを最終確定済みとしてマークします。Cantonが拒否した場合、ビルダーはrethをCantonの最後のコミット済みブロックに戻し、拒否されたブロックのトランザクションをプールに戻します。次の実行では、それらのレッグを再度確認します。割り当てが取り消された支払いは除外されます。

ビルダーが送信応答を失った場合、ブロックがコミットされたかどうかを判断するためにCantonのヘッドを再度読み取ります。その読み取りも失敗した場合、結果不明として報告し、rethはそのままにします。次の実行はCantonのヘッドから始まります。これらの復旧ルールは [builder README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#what-one-run-does).


---

# 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/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.