Модель выполнения

Как Rome EVM обрабатывает транзакции Ethereum на Solana — эмуляция через прокси, атомарный (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 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 обеспечивают корректность)

Что дальше

• Лимит вычислений — стоимость CU и стратегии оптимизации

• Ограничения — важные ограничения и границы