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

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

```
1. Пользователь подписывает транзакцию EVM (MetaMask / ethers.js)
                    ↓
2. Rome Proxy получает её через eth_sendRawTransaction
                    ↓
3. Proxy эмулирует транзакцию офчейн (эмулятор Mollusk SVM)
   → Оценивает gas, проверяет атомарность, определяет необходимые аккаунты
                    ↓
4. Proxy оборачивает EVM tx в инструкцию(и) Solana
   → Если tx помещается в одну Solana tx → Атомарно (VmAt)
   → Если tx превышает бюджет 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 млн вычислительных единиц доступны на одну транзакцию Solana
* Подходит для переводов, простых вызовов контрактов, свопов, большинства операций DeFi
* Финализация менее секунды (время блока Solana)

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

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

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

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

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

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

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

* **RoLock (разделяемый только для чтения)** — несколько итеративных транзакций могут удерживаться одновременно
* **RwLock (исключительная запись)** — только одна транзакция может изменять аккаунт одновременно
* **TTL:** 3 секунды (стандартно), 4 секунды (при использовании Address Lookup Tables)

**Когда используется:** Проверка паринга BN254, крупные развёртывания контрактов, глубокие стеки вызовов, любая операция, превышающая \~1,4 млн CU.

## Эмуляция

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

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

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

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

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

Каждый адрес 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, баланс, код контракта                   |
| Storage     | `[chain, "STORAGE", H160, slot_index, bump]` | Хранилище контракта (256 слотов на аккаунт)    |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | Подготовленные данные транзакции (макс. 80 КБ) |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | Сериализованное состояние VM между итерациями  |

## Аккаунты-хранилища

Транзакции Solana ограничены 1 232 байтами. Транзакции EVM — особенно развёртывания контрактов — могут быть значительно больше.

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

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

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

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

| Тип         | EIP      | Описание                                                           |
| ----------- | -------- | ------------------------------------------------------------------ |
| Legacy      | —        | Традиционные транзакции Ethereum                                   |
| Access List | EIP-2930 | Оптимизированные шаблоны доступа к состоянию                       |
| Dynamic Fee | EIP-1559 | Базовая комиссия + комиссия за приоритет                           |
| Депозит     | Тип 0x7E | Депозитные транзакции, например входящее урегулирование через мост |

## Состояние с журналированием

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

* Все изменения (nonce, баланс, storage, код) отслеживаются в `Журнале`
* Вложенные операции CALL/CREATE добавляют кадры снимков состояния
* При откате: записи журнала возвращаются к снимку
* При успешном выполнении: изменения фиксируются в аккаунтах 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/ru/klyuchevye-ponyatiya/execution-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.