Параллельный EVM: что это такое и почему он важен для Web3

При пиковом спросе средний газ на своп в Uniswap выходил за пределы комфортной для розничного пользователя зоны, mempool переполнялся, время включения в блок измерялось минутами. Узкое место — не сеть валидаторов и не консенсус, а именно исполнительный слой. Параллельный EVM — это архитектурный ответ на это узкое место: переход от последовательного исполнения к параллельному с сохранением байткод-совместимости с Ethereum.

Последовательный EVM — это процессор с одним ядром. Параллельный EVM — это многоядерный процессор, который ещё умеет договариваться сам с собой.

Почему традиционный EVM стал узким местом для масштабируемости

Базовый цикл работы EVM: загрузка состояния, последовательное применение транзакций, фиксация нового состояния. Архитектура детерминированная, воспроизводимая, удобная для верификации. Побочный эффект — отсутствие параллелизма на уровне исполнения. Любые две транзакции, даже не взаимодействующие между собой, выполняются строго одна за другой.

Последствия этого ограничения:

1. Пропускная способность ограничена временем выполнения одной транзакции, умноженным на их число в блоке.

2. Газ растёт нелинейно при конкуренции за блок — пользователи перебивают ставку друг друга через priority fee.

3. Сеть деградирует при нагрузке на один популярный контракт — состояние монополизирует очередь.

4. Layer 2 решения снимают часть нагрузки, но наследуют последовательный исполнитель от L1.

Решения класса «сверни в zk» или «вынеси в rollup» не меняют природу исполнителя. Они уменьшают объём данных, попадающих в основную цепочку, но внутри каждого отдельного вычислительного окружения транзакции всё равно идут в один поток.

Механика параллельного выполнения: как система распределяет нагрузку

Параллельный EVM не отказывается от EVM. Он меняет режим исполнения. Идея: транзакции, которые не задевают одни и те же ячейки состояния, можно выполнять одновременно в разных потоках. Для этого исполнитель должен заранее знать, к каким слотам состояния обращается каждая транзакция.

Базовый конвейер выглядит так:

1. На вход подаётся пакет транзакций блока.

2. Каждая транзакция проходит фазу преисполнения (pre-execution) или статического анализа: определяется множество адресов состояния, которые она прочитает или изменит — это так называемый access list.

3. Транзакции группируются по непересекающимся access list'ам.

4. Каждая группа запускается в отдельном потоке.

5. Результаты потоков объединяются в новый корень состояния.

Ключевое отличие от многопоточного CPU в обычных программах: здесь нельзя произвольно гонять потоки и надеяться на блокировки. Состояние блокчейна детерминировано, и любой узел должен прийти к идентичному результату при идентичном наборе транзакций. Поэтому параллелизм в EVM реализован через строго контролируемое планирование, а не через свободную гонку потоков.

Оптимистическая параллелизация и решение конфликтов доступа к данным

Главная проблема параллельного EVM — конфликты состояния. Две транзакции хотят изменить одну и ту же переменную. Запускать их параллельно нельзя: результат станет недетерминированным.

Базовый подход — оптимистическая параллелизация:

1. Все транзакции блока запускаются параллельно без предварительной проверки.

2. После выполнения каждая транзакция возвращает свой access list с указанием прочитанных и записанных слотов состояния.

3. Система проверяет пересечения между access list'ами транзакций, выполнявшихся в одном блоке.

4. При обнаружении конфликта — общий слот был прочитан одной транзакцией и записан другой — конфликтующие транзакции отбрасываются.

5. Отброшенные транзакции повторно выполняются последовательно в обновлённом состоянии.

Альтернативный подход — пейджинг состояния. Состояние разбивается на сегменты (shards of state), каждый сегмент обрабатывается своим потоком. Конфликты локализуются внутри сегмента. Пример — архитектура, где контракт размещается в определённом сегменте, а все вызовы к нему идут через соответствующий поток. Это снижает вероятность коллизий ценой ограничений на размещение контрактов.

Конфликт состояния — это гонка данных. В последовательном EVM её нет, потому что нет параллелизма. В параллельном EVM она появляется и решается повторным исполнением.

На практике конфликты возникают нечасто: большинство пользовательских транзакций не задевают общие слоты. Swap на Uniswap трогает конкретные пулы, перевод USDC трогает балансы отправителя и получателя — это узкие, локальные изменения. Конкуренция за один и тот же слот появляется в моменты ажиотажа: запуск популярного NFT-минта, ликвидации на кредитном протоколе, sniper-боты на новых токенах. В эти моменты параллельный исполнитель деградирует до последовательного — выигрыш по TPS исчезает, но система остаётся консистентной.

Кейсы Sei V2 и Monad: реальные показатели скорости и финализации

Два проекта определяют текущее состояние параллельного EVM: Sei и Monad.

Sei V2 интегрировал клиент Geth в собственный исполнитель. Это дало полную байткод-совместимость с Ethereum. На стороне параллелизации применена оптимистическая схема: транзакции исполняются параллельно, при конфликтах перезапускаются последовательно. Заявленная пропускная способность — до 20 000 TPS. Время финализации — 380–400 мс. Источник — спецификации Sei Network.

Monad строит параллельный EVM с нуля. Архитектура включает:

• механизм консенсуса MonadBFT — вариант HotStuff с оптимизациями под параллельное исполнение;
• асинхронное выполнение — блоки создаются параллельно с их исполнением;
• база данных MonadDB — собственное хранилище состояния, оптимизированное под параллельный доступ;
• заявленный целевой показатель — до 10 000+ TPS.

Источник — техническая документация проекта.

Сравнение ключевых параметров:

Оба проекта заявляют ускорение обработки до 100x относительно базового последовательного EVM. Цифра зависит от нагрузки: при отсутствии конфликтов выигрыш максимален, при высокой конкуренции за состояние — сокращается.

Сохранение совместимости: почему разработчики выбирают параллельные сети

Главное свойство параллельного EVM, которое отличает его от альтернатив типа Solana VM или Move VM, — обратная совместимость с байткодом Ethereum. Контракт на Solidity, развёрнутый в основной сети Ethereum, переносится в параллельную сеть без изменения исходного кода. Инструментарий тоже наследуется: MetaMask, Hardhat, Foundry, Tenderly, Etherscan-совместимые обозреватели.

Для разработчика это означает:

1. Отсутствие затрат на переписывание контрактов.

2. Использование знакомых библиотек — OpenZeppelin, Uniswap v2/v3 форки, Chainlink.

3. Совместимость с существующими аудитами — аудит Ethereum-контракта применим к его двойнику в параллельной сети.

4. Привычные модели газа и адресации — EIP-1559 работает, адреса 20-байтные, сигнатуры событий — keccak256.

Для пользователя это означает:

1. Те же кошельки, тот же UX.

2. Снижение комиссий за счёт роста пропускной способности.

3. Те же риски — уязвимости контрактов не исчезают от смены исполнителя.

Экосистемный эффект: проекты, которые ранее отказывались от размещения вне Ethereum из-за стоимости миграции, получают среду исполнения с совместимым интерфейсом и более высокой производительностью. Это расширяет зону, в которой Solidity остаётся рабочим языком.

Итог: безопасность и применимость

Параллельный EVM — рабочая технология с подтверждёнными показателями. Sei V2 и Monad демонстрируют ускорение обработки на порядок относительно последовательного исполнителя, сохраняя полную совместимость с инструментарием Ethereum. Конфликты состояния решаются оптимистической схемой с повторным исполнением — деградация до последовательного режима происходит только при экстремальной конкуренции за один слот.

Вердикт: технология безопасна для развёртывания существующих контрактов и инструментов, при условии стандартного аудита. Узкое место параллельного EVM — конкуренция за состояние в моменты пиковой нагрузки. Это ограничение не устраняется полностью и остаётся зоной наблюдения.