> 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/trust-model.md).

# 信頼モデル

devnet上のRome ZK EVMチェーンを誰が変更できるのか、そして入金者・出金者が何を信頼する必要があるのか。

Solana devnet 上の共有 v0.3.0 プログラムはアップグレード可能です。証明済みルートは、投稿時にそれらのプログラムが適用するルールの下で最終確定します。オペレーターとユーザーは、誰がそれらのルールを変更できるのか、誰が各チェーンを管理しているのか、そして誰がデータの公開を停止できるのかについても考慮する必要があります。

次をお読みください [v0.3.0 devnet の完全な信頼モデル](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) 各権限の正確な権限と、現在のプログラムにあるチェックの詳細について。

## Rome のプログラムおよびレジストリの権限

Rome は共有 inbox、settlement、Veritas、bridge プログラムのアップグレード権限を保持しています。devnet では単一署名の権限です。アップグレードは通知期間なしで有効になり、現在のプログラムのルールを任意に変更できます。資金を預け入れる際は、これを devnet の信頼前提として扱ってください。

Rome は settlement レジストリ権限も保持しています。現在のプログラムでは、パーミッションレス登録の有効／無効を切り替えたり、新しいチェーンの登録デポジットを変更したり、プロトコル上限なしで既存チェーンの settlement 手数料を変更したり、トレジャリーを選択したり、許容タイムスタンプずれを変更したり、グローバルな回収ウィンドウを変更したりできます。回収ウィンドウは登録済みチェーンについて短縮できますが、現在のプログラムでは 216,000 スロット未満にはできません。

レジストリ権限は、チェーンの検証キーを登録し、廃止し、アクティベーションスロットを変更します。証明は、そのチェーンのアクティブなキーに対してのみ有効と見なされます。したがって、この権限は、どのゲストの証明で新しいルートを最終確定できるかを変えたり、チェーンに使用可能なキーがない状態にしたりできます。新しいエントリは、登録トランザクションがチェーンに取り込まれた時点でアクティブになれます。キーが廃止されても、すでに最終確定したルートは最終確定のままです。

プログラムをアップグレードしない限り、Rome のキーは、Rome が権限を持たないチェーン向けの vault を作成したり、その vault のミントを変更したり、支払い先を選んだり、証明済みの exit なしにそこから引き出したりはできません。プログラムのアップグレード権限はそれらのルールを変更できるため、ユーザーは Rome が devnet でそのようなアップグレードを行わないことを信頼しなければなりません。

## あなたのチェーン権限

その `./rollup` セットアップでは、Solana の payer はチェーン権限でもあります。これは inbox バッチの公開と最終確定、証明済みルートの投稿、そしてチェーン設定に署名します。対象となる batch、chunk、pending-root アカウントをクローズして、そこにある rent を回収できます。この権限をローテーションする指示はないため、これを失うとそれらの署名付き操作はできなくなります。

登録によって、チェーンの ID、genesis、inbox プログラム、チャレンジウィンドウの長さが固定されます。権限は登録済みの genesis を編集できません。その genesis で手数料受取先を選びます。新しいチェーンは通常、残高ゼロで開始します。宣言された開始残高がある場合、Rome がその検証キーを登録する前に、対応する vault の裏付けが必要です。settlement 自体はその裏付けを確認しません。

権限は、別の exit portal、bridge プログラム、出金上限、投稿者ボンドを提案できます。提案は、少なくとも 1 チェーン分のチャレンジウィンドウが経過するまで有効になりません。そのスロット以降は誰でも有効化できます。ユーザーは出金前に有効な exit 設定を確認すべきです。

最初の証明済みバッチの後、権限は入金キューを作成し、その取り込み期限、バッチごとおよびブロックごとの上限、最低入金額、手数料、手数料受取先を選択できます。変更にも遅延アクティベーションスロットがあります。現在のプログラムは、どの待機中の入金を **最終確定済み** バッチが除外できるものです。オペレーターにそのバッチの生成を強制するものではありません。

## ユーザーが依拠するもの

預け手は、オペレーターがシーケンサーを動かし続け、キューに入ったクレジットをバッチに含め、そのバッチを投稿してルートを証明することを信頼します。オペレーターは EVM トランザクションの順序を選べ、トランザクションを拒否できます。EVM トランザクションに対する一般的な強制取り込みレーンはありません。入金残高は、そのルートが Solana 上で最終確定する前にチェーン RPC に表示されることがあります。

出金者には、exit メッセージを含む最終ルート、有効な exit 設定、そしてチェーン vault に十分な wrapped SOL が必要です。オペレーターは、バッチや証明を止めることでそのルートを遅らせられます。また、exit プローバーを止めたり、vault または exit payer に資金を入れないままにしたりすることで、支払いを遅らせられます。データと最終ルートが利用可能になれば、誰でも有効な exit 証明と release を送信できるため、オペレーターの exit プローバーだけが唯一の経路ではありません。

現在のプログラムでは、settlement は exit 証明を設定済みの portal と最終ルートに結び付けます。チャレンジウィンドウごとの exit 数を制限し、リプレイを防ぎます。bridge は、証明済みレコードから受取人を読み取り、その受取人の関連トークン口座を確認します。release を送る者が、その支払い先を変更することはできません。exit 証明が有効でも、資金が十分でない vault は支払えません。

5 SOL の登録デポジットはチェーン登録ボンドであり、ユーザー残高の裏付けではありません。最初の最終ルートまたは 10 個の投稿済みルートの後で、チェーン権限に返金可能になります。回収ウィンドウが終了する前にルートが投稿されなければ、誰でもチェーンを回収でき、返金されていないデポジットはトレジャリーに送られます。v0.3.0 の devnet ウィンドウは 6,480,000 スロットで、登録時点から数えて約 30 日です。


---

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