> 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/klyuchevye-ponyatiya/execution-model.md).

# Модель исполнения

Как Rome EVM обрабатывает транзакции Ethereum в Solana — эмуляция через proxy, атомарный (VmAt) и итеративный (VmIt) режимы, а также полный жизненный цикл транзакции.

Rome EVM исполняет байткод Solidity внутри ончейн-программы Solana. На этой странице объясняется, как обрабатываются транзакции EVM.

## Жизненный цикл транзакции

```
1. Пользователь подписывает транзакцию EVM (MetaMask / ethers.js)
                    ↓
2. Rome Proxy получает её через eth_sendRawTransaction
                    ↓
3. Proxy эмулирует транзакцию вне цепочки (эмулятор Mollusk SVM)
   → Оценивает gas, проверяет атомарность, определяет необходимые аккаунты
                    ↓
4. Proxy упаковывает EVM-транзакцию как инструкции Solana
   → Если транзакция помещается в одну транзакцию Solana → Атомарный режим (VmAt)
   → Если транзакция превышает бюджет CU → Итеративный режим (VmIt)
                    ↓
5. Валидатор Solana выполняет инструкции
   → Программа Rome EVM интерпретирует байткод EVM
   → Вызовы CPI к другим программам Solana (если есть)
                    ↓
6. Изменения состояния фиксируются в аккаунтах Solana
                    ↓
7. Hercules индексирует событие → формирует блок EVM
```

## Атомарное выполнение (VmAt)

Режим по умолчанию. Вся EVM-транзакция выполняется внутри одной транзакции Solana.

**Состояние автомата:** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**Свойства:**

* Выполнение по принципу «всё или ничего» — если любой шаг завершается неудачей, вся транзакция откатывается
* \~1,4 млн compute units доступны на одну транзакцию Solana
* Подходит для переводов, простых вызовов контрактов, свопов, большинства операций DeFi
* Финальность менее секунды (время блока Solana)

**Когда используется:** Автоматически выбирается, когда эмулятор определяет, что транзакция укладывается в compute budget одной транзакции Solana.

## Итеративное выполнение (VmIt)

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

**Как это работает:**

1. Каждый шаг (транзакция Solana) выполняет **столько EVM-опкодов, сколько помещается в его compute budget** — адаптивный размер шага, а не фиксированное количество
2. После каждого шага состояние VM сериализуется (формат Borsh) в `StateHolder` аккаунт
3. Следующий шаг десериализует состояние и продолжает выполнение
4. Задействованные аккаунты блокируются по TTL на **3–4 секунды** во время многошагового выполнения; сеанс ограничен **160 шагами**; после этого следующий шаг снимает блокировки сеанса и завершает его без фиксации каких-либо изменений

**Состояние автомата:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**Блокировка аккаунтов:**

* Одна **исключительная блокировка** на каждый управляемый аккаунт (аккаунты баланса и хранилища) — только один итеративный сеанс может владеть аккаунтом одновременно; атомарная транзакция, которая пытается записать в заблокированный аккаунт, отклоняется с `AccountLocked` до истечения блокировки, после чего клиент отправляет запрос повторно
* **TTL:** 3 секунды, продлевается на каждом шаге (4 секунды, если сеанс затрагивает более 28 аккаунтов)
* **CPI в legacy-потоке отклоняются** внутри итеративной транзакции (`CpiProhibitedInIterativeTx`); эффекты cached-track откладываются и фиксируются в конце

**Когда используется:** крупные развёртывания контрактов, глубокие стеки вызовов, любая операция, превышающая \~1,4 млн CU. Проверка сопряжения BN254 сама по себе этого не требует; см. [Бюджет вычислений](/ru/klyuchevye-ponyatiya/compute-budget.md).

## Эмуляция

Перед отправкой транзакции в Solana Proxy эмулирует её вне цепочки с помощью **эмулятора Mollusk SVM**. Это:

1. оценивает потребление gas
2. определяет, нужен ли атомарный или итеративный режим
3. выявляет все аккаунты Solana, к которым транзакция будет обращаться
4. проверяет, что транзакция не завершится ошибкой на цепочке

Эмулятор выполняет ту же EVM-логику, что и ончейн-программа — макрос `entrypoint!` обеспечивает идентичные таблицы диспетчеризации в кодовых базах программы и эмулятора.

**Mollusk SVM** также может выполнять произвольные BPF-программы Solana во время эмуляции, что означает `eth_call` и `eth_estimateGas` корректно обрабатывает CPI-вызовы к SPL Token, Jupiter, Kamino и т. д.

## Сопоставление аккаунтов

Каждый адрес Ethereum сопоставляется с PDA Solana:

```
Адрес 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 КБ)    |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | Сериализованное состояние VM между итерациями |

## Аккаунты-холдеры

Rome отправляет транзакции Solana **v1**транзакции, которые ограничены 4 КБ (4 096 байт) и 64 адресами. EVM-транзакции — особенно развёртывания контрактов — могут быть значительно больше.

**Механизм разбиения:**

1. SDK разбивает транзакцию в формате RLP на части
2. Каждая часть записывается в `TxHolder` аккаунт через `TransmitTx` инструкции
3. После того как все части подготовлены, инструкция `DoTxHolder` собирает и выполняет всю транзакцию
4. Максимальный размер holder: **80 КБ** на один TxHolder

Для разработчика это полностью прозрачно — SDK Rome автоматически выполняет разбиение и повторную сборку.

## Поддерживаемые типы транзакций

| Тип               | EIP      | Описание                                                                                                                                                                                                                 |
| ----------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Legacy            | —        | Традиционные транзакции Ethereum                                                                                                                                                                                         |
| Access List       | EIP-2930 | Оптимизированные шаблоны доступа к состоянию                                                                                                                                                                             |
| Dynamic Fee       | EIP-1559 | Базовая комиссия + приоритетная комиссия                                                                                                                                                                                 |
| Unsigned EIP-1559 | —        | A `0x02`—-типизированное тело без подписи secp256k1, вместо этого авторизованное подписью Ed25519 кошелька Solana (канал Solana; см. [Вызов EVM из Solana](/ru/rukovodstva-dlya-razrabotchikov/call-evm-from-solana.md)) |
| Deposit           | Тип 0x7E | Транзакции deposit, например входящее урегулирование через мост                                                                                                                                                          |

## Журналируемое состояние

Rome EVM использует модель журналируемого состояния для управления изменениями состояния во время выполнения:

* Все изменения (nonce, баланс, хранилище, код) отслеживаются в `журнале`
* Вложенные операции CALL/CREATE добавляют кадры снимков состояния
* При revert: записи журнала откатываются к снимку
* При успехе: изменения фиксируются в аккаунтах Solana
* Инструкции CPI вне EVM выполняются немедленно (собственные гарантии атомарности Solana обеспечивают корректность)

## Что дальше

* [Бюджет вычислений](/ru/klyuchevye-ponyatiya/compute-budget.md) — затраты CU и стратегии оптимизации
* [Ограничения](/ru/klyuchevye-ponyatiya/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/ru/klyuchevye-ponyatiya/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.