> 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/hajimeni/architecture.md).

# アーキテクチャ

Romeの各コンポーネントがどう噛み合うか — Solanaプログラム内でのEVM実行。

Romeは、EVMバイトコードインタプリタをSolanaのオンチェーンプログラム内に埋め込んでいます。ユーザーは標準のEthereum JSON-RPCを通じてRome Proxyとやり取りし、プロキシは彼らのトランザクションをSolana上のRome EVMプログラムへ直接送信します。同期を取る別の実行レイヤーはありません — EVM状態 *は* Solanaの状態。

## システム概要

<figure><img src="https://3990464069-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-12ba59ef1fa43d6d8b5565a98efca4375a4d79c0%2Farchitecture.svg?alt=media" alt="User to Rome Proxy to the Rome EVM program on Solana, with Hercules indexing back"><figcaption></figcaption></figure>

## コンポーネント

### Rome EVMプログラム（オンチェーン）

Romeの中核である、完全なEVMバイトコードインタプリタ（SputnikVMのフォーク）を含むSolana BPFプログラムです。以下を行います：

* シリアライズされたEVMトランザクションをSolanaインストラクションとして受け取る
* SolidityバイトコードをSolanaランタイム内で実行する
* 各Ethereumアドレス（H160）をSolana PDAにマッピングする
* 標準のEthereumプリコンパイルに加えて、Solanaへ呼び出すためのプリコンパイル（CPI、System、Helper、Withdraw）を公開する
* EVM状態（残高、nonce、コード、ストレージ）をSolanaアカウントデータとして保存する

### Rome Proxy（JSON-RPCサーバー）

ポート9090上の標準Ethereum JSON-RPCサーバー。公開チェーンへの入口です。Ethereum API呼び出しをSolana上の処理へ変換します：

* `eth_sendRawTransaction` → EVMトランザクションをシリアライズ → Solanaインストラクションを送信
* `eth_call` → Mollusk SVMエミュレータを使ってオフチェーンで実行をエミュレート
* `eth_estimateGas` → ガス見積もりのためにシミュレート
* `eth_getBalance`, `eth_getCode`, `eth_getBlockByNumber`、レシート、ログ → インデックス化された状態から提供

また、Rome拡張も公開します： `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo`, `rome_getResources`、その他。

### Hercules（インデクサー）

Solana上のRome EVMプログラムを監視し、PostgreSQLをバックエンドとして、Ethereum互換のブロック（トランザクション、レシート、ログ、状態変化）を再構築します。公開チェーンではスロット整列モードで動作するため、ブロック番号はSolanaのスロットに対応し、同じスロットならどのインデクサーでも同じブロックになります。プロキシはこれらのブロックをウォレットやエクスプローラに提供します。

### プリコンパイル

Romeは、標準のEthereumプリコンパイル（ecrecover、SHA-256、RIPEMD-160、identity、modexp、BN254曲線演算、blake2f）をメインネット相当のセマンティクスで実装し、さらにSolanaへ到達する非EVMプリコンパイルも備えています： **CpiProgram** (`0xFF…08`、任意のCPI）、 **System** (`0xFF…07`、PDA導出およびbase58ヘルパー）、 **HelperProgram** (`0xFF…09`、ATA/PDA作成、SPL転送、gas↔lamports）、および **Withdraw** (`0x42…16`）。詳細は [Contract Addresses](/ja/rifarensu/contract-addresses.md) 完全な表については、リファレンスを参照してください。

## 実行モード

RomeはEVMトランザクションを次の2つの方法のいずれかで実行します：

### アトミック（VmAt）

単一のSolanaトランザクション。EVMトランザクション全体が、1つのSolanaトランザクションの計算予算（約140万compute units）内で実行されます。ほとんどの操作—送金、通常のコントラクト呼び出し、スワップ—で使用されます。

### 反復的（VmIt）

単一トランザクションの予算を超える処理向け。実行は複数のSolanaトランザクションに分割されます：

1. 各ステップ（1つのSolanaトランザクション）は、その計算予算に収まるだけのEVMオペコードを実行します — ステップサイズは固定ではなく適応的です
2. VMの状態はBorshでシリアライズされて `StateHolder` ステップ間のアカウントに
3. 実行中、アカウントは数秒間TTLロックされます
4. BN254ペアリングのような重い処理に使用されます

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

各Ethereumアドレスは、Rome EVMプログラムの下でチェーンIDとアドレスから導出されるSolana PDAに決定論的にマッピングされます。そのPDAがアカウントの残高（SPLトークンアカウントとして）、コントラクトコード、ストレージスロット、nonceを所有します — すべてSolanaアカウントデータとして。

## ホルダーアカウント

Solana（v1）トランザクションは4 KBに制限されていますが、EVMトランザクション（特にコントラクトデプロイ）ははるかに大きくなることがあります。Romeは大きなトランザクションを **ホルダーアカウント**に段階的に配置します：トランザクションは最大80 KBのホルダーへ順次書き込まれるチャンクに分割され、その後オンチェーンで組み立てられて実行されます。Rome SDKがこれを透過的に管理します。

## ガスと価格設定

各チェーンには独自のガストークンがあります — 任意のSPLトークンです。ガス価格はMeteora DAMMプール（v1またはv2、設定可能）を読み取り、基盤となるSolanaトランザクション手数料についてガストークンとSOLの間を変換します。

## 次に何をするか

* [ネットワーク](/ja/nettowku/networks.md) — Hadrianに接続
* [クイックスタート](/ja/hajimeni/quickstart.md) — 最初のコントラクトをデプロイする
* [実行モデル](/ja/ji-ben-gai-nian/execution-model.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/hajimeni/architecture.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.
