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

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

Виртуальная машина Ethereum (EVM) исполняет транзакции однопоточно: в каждый момент состояние сети меняет ровно один контракт. Сделано это ради безопасности и предсказуемости — при последовательном порядке результат всегда детерминирован. Но у такого подхода есть скрытое ограничение: сеть не знает заранее, к какому состоянию обратится транзакция. Какие ячейки хранилища она прочитает и перезапишет, становится известно только в момент исполнения. Эту модель называют «слепой к чтению и записи»: планировать параллельность попросту не на чем, потому что зависимости выясняются постфактум.

Результат предсказуем: базовый слой Ethereum обрабатывает порядка 15–30 транзакций в секунду. Даже когда две сделки полностью независимы — Алиса переводит токены Бобу, Кэрол обновляет свой контракт, — сеть всё равно ставит их в одну очередь. Обновления Dencun и Pectra и вынос нагрузки на роллапы сгладили проблему, но саму архитектуру исполнения на базовом слое они не переписали.

Три пути к параллельности: Solana, Sui и Ethereum

Сети, которые уже исполняют транзакции параллельно, решают одну и ту же задачу — заранее понять, какие транзакции независимы, — но разными способами. Solana идёт декларативным путём: каждая транзакция обязана заранее объявить, какие аккаунты она будет читать, а какие — записывать. Её движок Sealevel строит по этим объявлениям карту зависимостей, и все транзакции, которые не пересекаются по записи, исполняются одновременно на множестве ядер. Модель называют «осведомлённой о чтении и записи» — противоположность подходу EVM.

Sui заходит с другой стороны — через объектную модель на языке Move. Здесь нет единого глобального состояния, за которое дерутся все подряд: каждый актив — это отдельный объект со своим владельцем. Транзакции с «личными» объектами (перевод токена, минт NFT) вообще обходят полный консенсус и финализируются за 250–400 миллисекунд по быстрому пути. И только транзакции, затрагивающие «общие» объекты — например, пул на DEX, против которого торгуют все, — проходят через DAG-консенсус Mysticeti. О том, чем архитектура направленного графа отличается от классической цепочки, мы разбирали в материале про DAG и блокчейн как две архитектуры доверия.

Ethereum же движется к параллельности эволюционно. Базовый слой остаётся последовательным, но параллельные EVM-среды (Sei, Monad и другие) применяют оптимистичное исполнение: транзакции запускаются одновременно «на удачу», а если система обнаруживает конфликт по состоянию, спорные откатываются и переисполняются. Так выигрыш достигается без переписывания контрактов. Три подхода — декларативный, объектный и оптимистичный — удобно сравнить в таблице.

Насколько часто транзакции реально конфликтуют на практике — вопрос не праздный. Как показано в эмпирическом разборе конфликтов транзакций, минимальное число «проходов» для блока задаёт самая длинная цепочка зависимых операций: если много сделок обращаются к одному горячему состоянию, параллелить их не выйдет, сколько ядер ни добавь.

Где параллельность ломается: конфликты состояния

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

• Чтение и чтение — параллельно. Если обе транзакции только читают одно и то же состояние, они не мешают друг другу и исполняются одновременно.
• Чтение и запись — последовательно. Одна читает то, что другая меняет, — порядок начинает влиять на результат, значит, их нужно упорядочить.
• Запись и запись — только по очереди. Две транзакции пишут в один аккаунт или объект — классический конфликт, который параллелить нельзя в принципе.

Отсюда понятие «горячего» состояния — точки, к которой одновременно рвётся множество транзакций. Популярный пул ликвидности на бирже, массовый минт нового токена, единый счётчик в контракте: всё это узкие места, где параллельность вырождается в очередь. Именно поэтому реальная пропускная способность Solana держится в районе 2000–4000 транзакций в секунду, хотя проектная цель — 65 000: в моменты ажиотажа конкуренция за горячие аккаунты возвращает часть нагрузки к последовательной обработке.

Что это меняет для разработчиков смарт-контрактов

Параллельность — это не только свойство сети, но и новый набор требований к тому, кто пишет контракты. Модель исполнения диктует стиль проектирования.

Общий сдвиг мышления один: раньше разработчик думал о логике контракта, теперь — ещё и о том, как его состояние разложено по независимым «ячейкам». Чем меньше транзакций дерётся за общий ресурс, тем ближе сеть к своему теоретическому пределу. Детальное сопоставление цифр и сценариев двух флагманов мы приводили в разборе Ethereum против Solana: цифры, архитектура и реальные сценарии.

Авторское мнение

Вопрос — ответ