Параллельный EVM — это новый язык смарт-контрактов?

Нет. Цель обычно состоит в том, чтобы исполнять существующий байт-код EVM и поддерживать инструменты Solidity, меняя при этом то, как программное обеспечение узла планирует и проверяет транзакции внутри себя на ядрах процессора.

Могут ли две транзакции, затрагивающие один и тот же контракт, выполняться параллельно?

Возможно, если они обращаются к разным участкам хранения и движок может доказать или подтвердить их независимость. Один лишь общий адрес контракта не всегда создаёт конфликт, но общие ключи состояния — часто.

Что происходит, когда параллельные транзакции конфликтуют?

Движок обнаруживает недопустимую зависимость, отбрасывает или откладывает затронутый предварительный результат и выполняет его заново относительно корректного предыдущего состояния. Некоторые системы переходят к последовательной обработке при высокой конкуренции.

Гарантирует ли совместимость с параллельным EVM безопасность уровня Ethereum?

Нет. Совместимость касается поведения при исполнении. Консенсус, распределение валидаторов, хранение состояния, мосты, управление, права на обновление, финальность и доступность данных определяют отдельные части модели безопасности сети.

Что такое параллельный EVM и как работает параллельное исполнение?

Параллельный EVM — это реализация Ethereum Virtual Machine или совместимый с EVM движок исполнения, который обрабатывает независимые транзакции одновременно на нескольких ядрах CPU. Транзакции по-прежнему имеют детерминированный порядок и должны приводить к тому же итоговому состоянию, что и корректное последовательное исполнение EVM. Параллелизация меняет то, как узлы вычисляют результаты внутри, а не смысл контрактов на Solidity или наблюдаемое пользователями упорядоченное состояние реестра.

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

Что такое параллельный EVM?

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

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

Как работает параллельный EVM?

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

Если последующая транзакция прочитала устаревшие данные или её запись конфликтует, её предварительный результат отклоняется, и транзакция выполняется заново, когда необходимое более раннее состояние становится доступным. Некоторые движки могут повторно использовать подписи, декодированный байт-код, кэшированное состояние или другие результаты при повторном исполнении. Последовательный резервный режим обеспечивает продвижение при высокой конкуренции. Каждый валидатор должен применять детерминированные правила конфликтов и фиксации, чтобы параллельное планирование не могло привести к разным корням состояния.

Каковы основные преимущества и сценарии применения параллельного EVM?

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

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

2. Приложения EVM сохраняют привычные инструменты. Совместимые сети могут поддерживать контракты на Solidity, кошельки в стиле Ethereum, интерфейсы JSON-RPC и фреймворки разработки, меняя при этом исполнение под уровнем приложений.

3. Высоконагруженные приложения получают больше запаса по исполнению. Платёжные сервисы, игры, биржи и социальные приложения с распределённым состоянием могут обрабатывать более крупные блоки, когда их транзакции создают сравнительно немного конфликтов за общее состояние.

4. Оптимизация может оставаться прозрачной для контрактов. Оптимистичные движки, такие как Monad, фиксируют результаты так, как если бы транзакции выполнялись последовательно, поэтому разработчикам не нужно вручную разделять обычные контракты только ради включения параллелизма.

Какие есть примеры движков параллельного исполнения?

Проекты применяют параллельное исполнение с разными виртуальными машинами и моделями состояния. Системы вне EVM остаются полезными ориентирами, поскольку некоторые приёмы оптимистичного параллелизма были впервые разработаны или внедрены за пределами EVM.

Monad — оптимистичный параллельный EVM. Monad выполняет совместимые с Ethereum транзакции параллельно, отслеживает их входные данные и повторно выполняет транзакцию, если ранее зафиксированный результат изменил использованные ею данные.
Sei — движок параллелизации. Sei использует оптимистичный контроль параллелизма, оценку наборов доступа, исполнение на основе исполнителей, обнаружение конфликтов, детерминированную повторную обработку и последовательный резервный режим в своей среде EVM.
Aptos Block-STM. Block-STM — это движок параллельного исполнения на основе программной транзакционной памяти и многоверсионного состояния, демонстрирующий прозрачное оптимистичное исполнение для упорядоченных блокчейн-транзакций.
Solana Sealevel. Solana — не EVM, но её среда исполнения демонстрирует иную модель, в которой транзакции объявляют доступ к аккаунтам, так что не конфликтующую работу можно планировать параллельно.

Каковы ограничения и риски параллельного EVM?

Параллельное исполнение не может устранить зависимости, присущие состоянию приложений. Оно также добавляет сложность планирования, проверки, кэширования, работы с базой данных и повторного исполнения, которую необходимо согласованно реализовать на всех узлах.

1. Конкуренция за состояние снижает выигрыш в скорости. Транзакции, взаимодействующие с одним и тем же пулом ликвидности, глобальным счётчиком, значением оракула или популярным слотом контракта, могут конфликтовать и требовать сериализации или повторного исполнения.

2. Спекуляция может расходовать вычисления впустую. Оптимистичный исполнитель может довести транзакцию до конца на устаревших входных данных, чтобы затем отбросить результат, увеличивая нагрузку на CPU и память при высокой частоте конфликтов.

3. Сложность реализации расширяет поверхность для ошибок. Планировщики, многоверсионное хранилище, обнаружение конфликтов, кэширование и логика фиксации должны точно воспроизводить семантику EVM при откатах, учёте газа, вызовах и граничных случаях.

4. Бенчмарки могут не отражать реальные нагрузки. Заявленная пропускная способность на независимых переводах может преувеличивать производительность для приложений, где множество пользователей конкурируют за изменение небольшого набора общих ячеек хранения.

5. Более высокая мощность может повышать требования к узлам. Сети должны балансировать CPU, память, пропускную способность хранилища, дизайн базы данных и рост состояния, чтобы целевые показатели производительности не делали независимую проверку непрактичной.

Меняет ли параллельный EVM результаты смарт-контрактов?

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