> 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/ji-ben-gai-nian/execution-model.md).

# 実行モデル

Rome EVMがSolana上でEthereumトランザクションを処理する方法 — プロキシエミュレーション、アトミック（VmAt）モードとイテレーティブ（VmIt）モード、そして完全なトランザクションライフサイクル。

Rome EVM は、Solana のオンチェーンプログラム内で Solidity バイトコードを実行します。このページでは、EVM トランザクションがどのように処理されるかを説明します。

## トランザクションのライフサイクル

```
1. ユーザーが EVM トランザクションに署名します（MetaMask / ethers.js）
                    ↓
2. Rome Proxy が eth_sendRawTransaction 経由で受信します
                    ↓
3. Proxy がオフチェーンでトランザクションをエミュレートします（Mollusk SVM エミュレータ）
   → ガスを見積もり、原子性を確認し、必要なアカウントを特定します
                    ↓
4. Proxy が EVM tx を Solana の instruction(s) としてラップします
   → tx が 1 つの Solana tx に収まる場合 → 原子的（VmAt）
   → tx が CU 予算を超える場合 → 反復的（VmIt）
                    ↓
5. Solana バリデータが instruction(s) を実行します
   → Rome EVM プログラムが EVM バイトコードを解釈します
   → 他の Solana プログラムへの CPI 呼び出し（ある場合）
                    ↓
6. ステート変更が Solana アカウントにコミットされます
                    ↓
7. Hercules がイベントをインデックス化し → EVM ブロックを生成します
```

## 原子的実行（VmAt）

デフォルトモードです。EVM トランザクション全体が 1 つの Solana トランザクション内で実行されます。

**状態マシン：** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**特性：**

* 全か無かの実行 — いずれかのステップが失敗すると、トランザクション全体がロールバックされます
* Solana トランザクションごとに利用可能な compute unit は約 140 万
* 送金、単純なコントラクト呼び出し、スワップ、ほとんどの DeFi 操作に適しています
* 1 秒未満のファイナリティ（Solana のブロック時間）

**使用される場合：** エミュレータが、そのトランザクションが 1 つの Solana トランザクションの compute budget に収まると判断した場合に自動的に選択されます。

## 反復実行（VmIt）

1 回のトランザクションの予算を超える計算集約的な操作向けです。EVM の実行は複数の Solana トランザクションに分割されます。

**仕組み：**

1. 各ステップ（1 つの Solana トランザクション）が実行されます **その compute budget に収まるだけの EVM opcode を** — 固定数ではなく、適応的なステップサイズです
2. 各ステップの後、VM 状態はシリアライズ（Borsh 形式）されて `StateHolder` アカウントに
3. 次のステップで状態をデシリアライズし、実行を続行します
4. 関与するアカウントは TTL ロックされます **3〜4 秒間** マルチステップ実行中。セッションの上限は **160 ステップ**；それを過ぎると、次のステップがセッションのロックを解除し、何もコミットせずに終了します

**状態マシン：** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**アカウントロック：**

* 1 つの **排他ロック** 管理対象アカウント（残高アカウントとストレージアカウント）ごとに — 同時に保持できる反復セッションは 1 つだけです。ロックされたアカウントに書き込む原子的トランザクションは、次で拒否されます `AccountLocked` ロックが失効するまで、クライアントは再送します
* **TTL：** 3 秒。各ステップごとに更新されます（セッションが 28 件を超えるアカウントに触れる場合は 4 秒）
* **Legacy-track の CPI は拒否されます** 反復トランザクション内では（`CpiProhibitedInIterativeTx`）；cached-track の効果は最後にステージされ、コミットされます

**使用される場合：** 大規模なコントラクトデプロイ、深いコールスタック、約 140 万 CU を超えるあらゆる操作。BN254 ペアリングチェック単体では不要です。参照： [Compute Budget](/ja/ji-ben-gai-nian/compute-budget.md).

## エミュレーション

Solana にトランザクションを送信する前に、Proxy はオフチェーンで次を使ってそれをエミュレートします **Mollusk SVM エミュレータ**。これにより：

1. ガス消費量を見積もります
2. 原子的モードか反復モードが必要かを判断します
3. トランザクションが触れるすべての Solana アカウントを特定します
4. トランザクションがオンチェーンで失敗しないことを検証します

エミュレータはオンチェーンプログラムと同じ EVM ロジックを実行します — `entrypoint!` マクロにより、プログラムとエミュレータの両方のコードベースで同一のディスパッチテーブルが保証されます。

**Mollusk SVM** は、エミュレーション中に任意の Solana BPF プログラムも実行できるため、 `eth_call` および `eth_estimateGas` SPL Token、Jupiter、Kamino などへの CPI 呼び出しを正しく処理できます。

## アカウントマッピング

すべての Ethereum アドレスは Solana PDA にマッピングされます：

```
Ethereum アドレス（H160、20 バイト）
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Solana アカウント（Pubkey、32 バイト）
```

**オンチェーンに保存されるアカウント型：**

| タイプ         | シード                                          | 目的                             |
| ----------- | -------------------------------------------- | ------------------------------ |
| 残高          | `[chain, "ACCOUN_SEED", H160, bump]`         | nonce、残高、コントラクトコード             |
| ストレージ       | `[chain, "STORAGE", H160, slot_index, bump]` | コントラクトストレージ（アカウントごとに 256 スロット） |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | ステージ済みトランザクションデータ（最大 80 KB）    |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | 反復間でシリアライズされた VM 状態            |

## ホルダーアカウント

Rome は Solana に **v1 トランザクションを送信します**、4 KB（4,096 バイト）と 64 アドレスに制限されています。EVM トランザクション — 特にコントラクトデプロイ — は、はるかに大きくなることがあります。

**分割メカニズム：**

1. SDK は RLP エンコードされたトランザクションをチャンクに分割します
2. 各チャンクは次の `TxHolder` アカウントへ `TransmitTx` 命令
3. すべてのチャンクがステージされると、 `DoTxHolder` 命令が完全なトランザクションを組み立てて実行します
4. ホルダーの最大サイズ： **80 KB** TxHolder ごと

これは開発者にとって完全に透過的です — Rome SDK が分割と再構成を自動的に処理します。

## 対応トランザクションの種類

| タイプ           | EIP       | 説明                                                                                                                                             |
| ------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| レガシー          | —         | 従来の Ethereum トランザクション                                                                                                                          |
| アクセスリスト       | EIP-2930  | 最適化されたステートアクセスパターン                                                                                                                             |
| 動的手数料         | EIP-1559  | 基本手数料 + 優先手数料                                                                                                                                  |
| 署名なし EIP-1559 | —         | ひとつの `0x02`型のボディで、secp256k1 署名はなく、代わりに Solana ウォレットの Ed25519 署名によって認可されます（Solana lane；参照： [SolanaからEVMを呼ぶ](/ja/gaido/call-evm-from-solana.md)) |
| 預け入れ          | Type 0x7E | 入金トランザクション。例：ブリッジの入金側決済                                                                                                                        |

## ジャーナル化されたステート

Rome EVM は、実行中のステート変更を管理するためにジャーナル化されたステートモデルを使用します：

* すべての変更（nonce、残高、ストレージ、コード）は次に記録されます `ジャーナル`
* ネストされた CALL/CREATE 操作はスナップショットフレームを積みます
* revert 時：ジャーナルエントリはスナップショットへロールバックされます
* 成功時：変更は Solana アカウントにコミットされます
* 非 EVM の CPI 命令は即座に実行されます（Solana 自身の原子性が正しさを保証します）

## 次は

* [Compute Budget](/ja/ji-ben-gai-nian/compute-budget.md) — CU コストと最適化戦略
* [制約](/ja/ji-ben-gai-nian/constraints.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/ji-ben-gai-nian/execution-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.
