> 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/ru/nachalo-raboty/architecture.md).

# Архитектура

Как компоненты Rome работают вместе — выполнение EVM внутри программы Solana.

Rome встраивает интерпретатор байткода EVM в ончейн-программу Solana. В канале EVM-ключа пользователи отправляют подписанные транзакции EVM в Rome Proxy через стандартный Ethereum JSON-RPC. Прокси передает их в программу Rome EVM в Solana. Для одной транзакции EVM может потребоваться несколько транзакций Solana, чтобы записать фрагменты в учетные записи holder или выполнить итеративное выполнение. В канале v1 с ключом Solana прокси формирует транзакцию. Кошелек Solana подписывает ее и отправляет напрямую в Solana RPC. Отдельного слоя исполнения, который нужно синхронизировать, нет — состояние EVM *является* состояние Solana.

## Общий обзор системы

<figure><img src="https://1351373662-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-12ba59ef1fa43d6d8b5565a98efca4375a4d79c0%2Farchitecture.svg?alt=media" alt="EVM wallet and Solana wallet connected to Rome Proxy with its emulator. The Solana cluster holds the Rome EVM program, per-chain state, external-authority PDA, token accounts, Solana programs and holder accounts. Hercules feeds blocks, receipts and logs back to the proxy."><figcaption></figcaption></figure>

## Компоненты

### Программа Rome EVM (ончейн)

Ядро Rome — программа Solana BPF, содержащая полноценный интерпретатор байткода EVM (форк SputnikVM). Она:

* Получает подписанные транзакции EVM и неподписанные тела EIP-1559 как инструкции Solana. Ключ Solana авторизует неподписанное тело через подпись плательщика комиссии Solana или инструкцию-верификатор Ed25519
* Выполняет байткод Solidity внутри среды выполнения Solana
* Сопоставляет каждый адрес Ethereum (H160) с PDA баланса для каждой цепочки, содержащим его nonce, нативный баланс и код. С PDA баланса связаны отдельные PDA хранилища. Каждый адрес также имеет программно-выведенный адрес для управления вызовами Solana, называемый его **PDA внешнего полномочия**. Этот PDA используется всеми цепочками в программе. Он владеет SPL-учетными записями токенов адреса и подписывает его межпрограммные вызовы (CPI)
* Предоставляет предкомпилированные контракты для вызовов в Solana (CPI, System, Helper, Withdraw) наряду с Ethereum precompiles. Семейство cached добавляет SystemCached (`0xff…04`), SplCached (`0xff…05`), ASplCached (`0xff…06`) и WithdrawCached (`0xff…0b`). Фабрика разворачивает обертки на этом кэшированном канале
* Хранит состояние EVM (балансы, nonce, код, хранилище) в данных учетной записи Solana
* Одна программа Rome EVM обслуживает множество chain ID. Chain ID является частью адресов PDA баланса и хранилища, а не PDA внешней авторизации

### Rome Proxy (сервер JSON-RPC)

Rome Proxy — это стандартный сервер Ethereum JSON-RPC. Пользователи подключаются к `https://hadrian.testnet.romeprotocol.xyz/` к Hadrian (тестнет) и `https://rubicon.mainnet.romeprotocol.xyz/` к Rubicon (мейннет). Он преобразует вызовы API Ethereum в действия Solana:

* `eth_sendRawTransaction` → отправляет одну или несколько транзакций Solana v1: атомарные `DoTx`, фрагменты holder (`TransmitTx`) плюс `DoTxHolder`, либо итеративные этапы. Общий плательщик подписывает и оплачивает SOL. Общий получатель комиссии собирает газ пользователя
* `eth_call` → нативно запускает интерпретатор EVM в эмуляторе на живых учетных записях Solana, считываемых через RPC. Mollusk выполняет программы Solana, до которых достигает CPI. Он также запускает программу Rome EVM, когда прокси измеряет вычислительные единицы
* `eth_estimateGas` → симулирует для оценки газа. Одна единица газа равна одному лампорту стоимости Solana. Оценка никогда не бывает ниже 21 000
* `eth_getBalance`, `eth_getCode`, `eth_getTransactionCount`, `eth_getStorageAt` → считывать живые учетные записи Solana через эмулятор. `eth_getBlockByNumber`, квитанции и журналы поступают из Hercules

Он также предоставляет расширения Rome: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo` и `rome_getResources`. Методы кошелька Solana включают `rome_emulateCallAccounts`, `rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1`, `rome_submitSignedV1Plan`, `rome_relayUnsignedV1`, `rome_composeExternalDepositV1` и `rome_sendUnsignedTransaction`. Прокси также предоставляет `rome_solanaTxForEvmTx`.

### Hercules (индексатор)

Hercules отслеживает программу Rome EVM в Solana и восстанавливает совместимые с Ethereum блоки в PostgreSQL. Они содержат транзакции, квитанции, журналы и изменения состояния. В публичных цепочках он работает в режиме выравнивания по слотам, поэтому номер блока сопоставляется со слотом Solana, а один и тот же слот дает один и тот же блок в любом индексаторе. Прокси предоставляет эти блоки кошелькам и обозревателям.

Hercules индексирует подтвержденные блоки. Он повторно проверяет каждый блок при финализации и перезагружает его, если blockhash изменился.  [Через обозреватель](/ru/prilozheniya-v-rome/via.md) читает данные Hercules.

### Прекомпиляции

Rome реализует ecrecover, SHA-256, RIPEMD-160, identity, операции кривой BN254 и blake2f с семантикой Ethereum, за исключением данных об ошибке для BN254 и blake2f. Неудачный вызов BN254 или blake2f возвращает Rome `Error(string)` данные revert вместо пустого буфера. Modexp (`0x05`) отключен и завершает выполнение с `"вызов big_mod_exp отключен"`. blake2f отклоняет более 1 000 000 раундов, хотя Ethereum это допускает.

Предкомпилированные контракты вне EVM обращаются к Solana: **CpiProgram** (`0xFF…08`, произвольный CPI), **System** (`0xFF…07`, derivation PDA и вспомогательные функции base58), **HelperProgram** (`0xFF…09`, создание ATA/PDA, переводы SPL, gas↔lamports), и **Withdraw** (`0x42…16`). Семейство cached — это **SystemCached** (`0xff…04`), **SplCached** (`0xff…05`), **ASplCached** (`0xff…06`и **WithdrawCached** (`0xff…0b`). Legacy CPI выполняются немедленно и только в атомарных транзакциях. Cached CPI записываются во время выполнения и отправляются при коммите. Они откатываются вместе с EVM. Они могут выполняться в итеративных транзакциях. См.  [справочнике Contract Addresses](/ru/spravochnik/contract-addresses.md) справочник для полной таблицы.

## Режимы выполнения

Rome выполняет транзакцию EVM одним из двух способов:

### Атомарный (VmAt)

Одна транзакция Solana. Вся транзакция EVM выполняется в пределах вычислительного бюджета одной транзакции Solana (\~1,4 млн вычислительных единиц). Используется для большинства операций — переводов, обычных вызовов контрактов, свопов.

### Итеративный (VmIt)

Для задач, превышающих бюджет одной транзакции. Выполнение разделяется на несколько транзакций Solana:

1. Каждый шаг (транзакция Solana) выполняет столько opcode EVM, сколько помещается в его вычислительный бюджет — размер шага адаптивный, а не фиксированный
2. Состояние VM сериализуется Borsh в `StateHolder` учетную запись между шагами
3. Учетные записи блокируются по TTL на несколько секунд во время выполнения

Прокси переходит к итеративному выполнению, когда вычислительные единицы, heap или количество инструкций не помещаются в одну транзакцию Solana. Сеанс ограничен 160 итерациями. Legacy-track CPI отклоняется в итеративной транзакции, поскольку его нельзя разделить на этапы. Cached-track CPI разрешены.

## Сопоставление учетных записей

Каждый адрес Ethereum детерминированно сопоставляется с PDA баланса Solana, производным от chain ID и адреса в рамках программы Rome EVM. Его нативный баланс газа является полем в этом PDA, наряду с nonce и кодом контракта. Слоты хранилища находятся в отдельных PDA хранилища. Балансы SPL хранятся в токенных учетных записях, принадлежащих отдельному PDA внешней авторизации. Эта авторизация общая для всех цепочек в одной и той же программе.

## Два способа подключения

* **Канал EVM-ключа:** кошелек отправляет подписанную secp256k1 транзакцию EVM в Rome Proxy. Прокси отправляет транзакции Solana.
* **Канал Solana-ключа:** кошелек авторизует неподписанное тело EIP-1559 своим ключом Solana. Для прямого маршрута v1 прокси формирует транзакцию Solana. Кошелек подписывает ее и отправляет напрямую в Solana RPC. Маршрут через ретранслятор использует для отправки прокси. В более старом legacy-маршруте кошелек формирует, подписывает и оплачивает `DoTxUnsigned` транзакцию Solana, а программа выводит отправителя из подписанта Solana.

Открытый ключ Solana сопоставляется с синтетическим адресом `keccak256(pubkey)[12:]`, последние 20 байт хеша. См. [Как Solana и EVM встречаются в Rome](broken://pages/6d5752686c28351d88f0c43af7db8dfdbfa07851).

## Кто подписывает вызов в Solana

Программа Rome EVM подписывает CPI с использованием PDA внешней авторизации непосредственного вызывающего предкомпилята. Контракт подписывает от своего имени. Чтобы расходовать SPL-токены пользователя, контракту требуется делегирование SPL от этого пользователя. Пользователь предоставляет его с помощью `HelperProgram.approve_spl(spender, amount, mint)`. Прямой вызов предкомпилята с адреса EVM или синтетического адреса пользователя использует PDA внешней авторизации пользователя.

## Учетные записи holder

Транзакции Solana (v1) ограничены 4 КБ, но транзакции EVM (особенно развертывания контрактов) могут быть значительно больше. Rome разбивает крупные транзакции на фрагменты по 3 600 байт и последовательно записывает их в **учетные записи holder** (до 80 КБ). Затем он собирает каждую транзакцию и выполняет ее ончейн. Rome SDK управляет этим прозрачно. Комиссия за подпись каждого фрагмента списывается из газа отправителя.

## Газ и ценообразование

У каждой цепочки есть собственный газовый токен: SOL или SPL-токен. Источником цены служит Hermes API, пул Meteora DAMM v1, пул Meteora DAMM v2 или фиксированная цена. Он обеспечивает конвертацию между газовым токеном и SOL для базовых комиссий транзакций Solana.

* Одна единица газа — это один лампорт стоимости Solana
* `eth_gasPrice` — это wei газового токена за лампорт
* Отправитель оплачивает получателю комиссии из своего нативного баланса газа. Плательщик прокси оплачивает SOL
* При отсутствии получателя комиссии, как в атомарном канале кошелька Solana, газ EVM не взимается. Кошелек оплачивает SOL напрямую
* Нативный баланс имеет 18 знаков после запятой. Он обеспечен SPL газового токена, хранящимся в программном кошельке для каждой цепочки

## Финальность

Rome использует финальность Solana. SDK ожидает `подтверждения`. Hercules повторно проверяет каждый индексированный блок на этапе `финализированный` и перезагружает его, если blockhash изменился.

## Что дальше

* [Сети](/ru/seti/networks.md) — подключение к Hadrian (тестнет) и Rubicon (мейннет)
* [Быстрый старт](/ru/nachalo-raboty/quickstart.md) — разверните свой первый контракт
* [Модель выполнения](/ru/klyuchevye-ponyatiya/execution-model.md) — атомарное и итеративное выполнение в подробностях
* [Совместимость токенов](/ru/klyuchevye-ponyatiya/token-interop.md)
* [Ограничения](/ru/klyuchevye-ponyatiya/constraints.md)
* [Вызов Solana из EVM](/ru/rukovodstva-dlya-razrabotchikov/call-solana-from-evm.md)
* [Вызов EVM из Solana](/ru/rukovodstva-dlya-razrabotchikov/call-evm-from-solana.md)
* [Справочник precompile](/ru/spravochnik/precompiles.md)
* [Как Solana и EVM встречаются в Rome](broken://pages/6d5752686c28351d88f0c43af7db8dfdbfa07851)


---

# 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/ru/nachalo-raboty/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.
