Параллельный EVM простыми словами: как многопоточность...

Традиционный Ethereum выполняет транзакции строго по очереди в один поток, что создает фундаментальное узкое горлышко производительности.
Параллельный EVM обрабатывает независимые транзакции одновременно, задействуя современные многоядерные процессоры и оптимистичный контроль конкурентности.
Если две транзакции обращаются к одному счету или пулу ликвидности, система автоматически фиксирует конфликт, отменяет операцию и пересчитывает ее по очереди.
Проекты вроде Monad, Sei v2 и MegaETH выводят смарт-контракты на скорость современного интернета, сохраняя привычные инструменты разработки на Solidity.

Виртуальная машина Ethereum (EVM) заслуженно считается фундаментальной операционной системой децентрализованных финансов. За последнее десятилетие программисты написали сотни тысяч смарт-контрактов на языке Solidity, создав стандарты, библиотеки аудита и финансовые протоколы, которые сегодня защищают десятки миллиардов долларов пользовательского капитала. Однако классическая архитектура EVM содержит в себе жесткое программное ограничение: она строго однопоточная. Узлы стандартной сети Ethereum обрабатывают входящие операции последовательно, строго по очереди, напоминая покупателей в гигантском супермаркете, стоящих в одну-единственную работающую кассу.

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

Почему классический блокчейн работает в одну очередь

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

Такой последовательный алгоритм был осознанно выбран создателями сети Ethereum в 2015 году ради максимальной надежности, простоты и предсказуемости. Тысячи независимых компьютеров валидаторов по всей планете должны приходить к абсолютно одинаковому итоговому результату расчетов. Строгий порядок полностью исключает программные ошибки и путаницу с деньгами. Если пользователь А переводит 100 долларов пользователю Б, а пользователь Б в ту же секунду решает обменять эти деньги на бирже, последовательная обработка гарантирует, что система не позволит совершить обмен до тех пор, пока перевод действительно не поступит на счет в его кошельке.

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

1. Парадокс 64 ядер.png

Как устроен параллельный расчет: Оптимистичный контроль конкурентности

Главная инженерная сложность параллельных расчетов в блокчейне заключается в управлении зависимостями данных. Если транзакция №1 отправляет депозит в протокол кредитования, а транзакция №2 переводит токены между двумя личными кошельками на другом континенте, эти операции затрагивают совершенно разные ячейки памяти. Между ними нет абсолютно никакой связи. Нет ни единой разумной причины заставлять транзакцию №2 ждать завершения первой операции. Их можно рассчитать в одну и ту же миллисекунду на разных ядрах процессора.

Чтобы реализовать такой подход безопасно, современные параллельные сети используют архитектурный принцип, известный как Оптимистичный контроль конкурентности (Optimistic Concurrency Control, или OCC), построенный на алгоритмах вроде Block-STM. Вместо того чтобы тратить драгоценное время на предварительный анализ сложных связей между транзакциями, система оптимистично предполагает, что операции не будут мешать друг другу в процессе расчета.

2, Механика параллелизма.png

Поток входящих транзакций в блоке
      |
      +---> Ядро 1: Считает перевод кошелька А (Успех) ---------> Данные записаны в блок
      +---> Ядро 2: Считает сделку на бирже (Конфликт памяти) -> Откат и пересчет по очереди
      +---> Ядро 3: Считает выпуск NFT (Успех) -----------------> Данные записаны в блок

Жизненный цикл операции при оптимистичном параллельном расчете состоит из четырех четких этапов:

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

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

Настоящее узкое место: Дисковые накопители против процессора

Среди участников рынка распространено заблуждение, будто смарт-контракты тормозят из-за сложных математических формул. На самом деле выполнение арифметических команд в регистрах процессора занимает миллионные доли секунды. Настоящим тормозом распределенных сетей являются операции чтения и записи информации на физический накопитель (операции ввода-вывода I/O). Каждый раз, когда смарт-контракт проверяет баланс или обновляет пул ликвидности, ему требуется обратиться к жесткому диску сервера.

В классических клиентах Ethereum информация хранится в базах данных LevelDB или RocksDB, организованных в виде сложных многоуровневых деревьев Меркла. Чтобы отыскать одну запись о балансе, программе приходится совершать несколько последовательных обращений к диску. Если десять ядер процессора работают параллельно, но все десять застревают в ожидании ответа от медленного накопителя, вся польза от многопоточности полностью теряется.

Чтобы снять этот невидимый барьер, разработчики параллельных сетей создают специализированные хранилища данных. Например, команда проекта Monad с нуля написала кастомную базу данных MonadDb, оптимизированную под асинхронное чтение информации с быстрых SSD-накопителей. Синхронизируя структуру базы данных с многопоточным планировщиком процессора, система считывает данные параллельно, гарантируя, что вычислительные ядра никогда не простаивают без работы в ожидании нужных байтов из памяти.

3, Скрытый барьер.png

Сравнение ключевых реализаций параллельного EVM

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

| :---------- | :------------------------------------- | :--------------------------------------------- | :----------------------------------------------------------- |

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

Сохранение привычной среды для разработчиков

Решающее преимущество параллельного EVM перед альтернативными скоростными сетями (вроде Solana или блокчейнов на языке Move) заключается в полной преемственности экосистемы. Раньше для достижения высокой скорости разработчикам приходилось полностью бросать знакомый мир EVM, переписывать смарт-контракты на язык Rust, заново проходить дорогостоящие аудиты безопасности и переучивать сотрудников с нуля.

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

4, Формула масштаба WEB2 в экосистеме web3.png

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

Заключительный вывод

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