Редакция не дает инвестиционных советов, материал опубликован исключительно в ознакомительных целях. Криптовалюта — это волатильный актив, который может привести к финансовым убыткам.
Кажется, что блокчейн не может исполнять операции параллельно, ведь это нарушает логику работы такой сети. Однако ограничение может возникнуть только там, где пользователи одновременно пытаются изменить одно и то же действие, пишет РБК Крипто.
Основная сеть эфириума пока исполняет транзакции блока последовательно. Первая меняет состояние сети, вторая работает уже с новым состоянием, затем выполняется третья. Полный список адресов и ячеек хранилища, к которым обратится произвольный контракт, заранее неизвестен.
Это должно измениться с обновлением Glamsterdam. EIP-7928 добавляет Block-Level Access Lists — списки обращений к состоянию на уровне блока. Получив такой список, клиент сможет заранее определить зависимости и параллельно читать данные, проверять транзакции и рассчитывать новое состояние. На 10 августа 2026 года обновление еще не активировано в Mainnet.
Solana: список данных известен до запуска
В Solana программа хранит логику, а изменяемое состояние находится в отдельных аккаунтах. Транзакция заранее перечисляет аккаунты, которые ее инструкции будут читать и изменять.
Sealevel получает эту информацию до исполнения. Если наборы данных не конфликтуют, операции можно отправить на разные ядра. Несколько транзакций могут одновременно читать один аккаунт. Но если хотя бы одна из них собирается его изменить, остальные обращения к этим данным приходится согласовывать.
Например, два перевода между независимыми парами пользователей не мешают друг другу. Но тысячи операций, которым требуется запись в один аккаунт, конкурируют за него.
Отсюда практическое требование к разработчикам Solana: состояние выгодно разносить по отдельным аккаунтам. В июле 2026 года разработчики торговых приложений на Solana обсуждали дробление книг заявок именно как способ уйти от конкуренции за блокировку одного аккаунта.
Sui: вместо единого состояния — объекты
Sui строит сеть вокруг объектов. Монета, NFT или состояние приложения существуют как отдельные объекты со своими идентификаторами и версиями.
Для объектов, принадлежащих одному адресу, возможен быстрый путь — fastpath. Такие операции обходят консенсус и получают меньшую задержку. Общие объекты, которыми могут пользоваться несколько участников, проходят через консенсус и получают определенный порядок изменений.
Поэтому две операции с независимыми объектами не обязаны ждать друг друга. Если же пользователи массово обращаются к одному общему объекту — например, состоянию одного рынка, — возникает конкуренция именно вокруг него.
Современная модель Sui стала сложнее первоначальной. Сейчас сеть поддерживает так называемые party objects: объект сохраняет ограниченное владение, но его операции упорядочиваются консенсусом. Документация рекомендует такой вариант вместо fastpath, когда одному объекту нужны несколько одновременно находящихся в обработке транзакций.
Aptos: сначала выполнить, потом проверить
Aptos использует Block-STM. Здесь разработчику не требуется заранее объявлять полный набор зависимостей.
Транзакции уже имеют определенный порядок в блоке, но несколько операций запускаются одновременно. Движок отслеживает чтения и записи. Если выясняется, что одна транзакция использовала устаревшее значение, ее результат отменяется и вычисление повторяется.
Финальное состояние остается таким же, каким оно было бы при последовательном выполнении. Параллельность существует внутри узла и не меняет порядок операций, который видит блокчейн.
Block-STM разработала команда Aptos Labs. В актуальной документации Aptos указано, что после публикации этот подход приняли или адаптировали Polygon, Sei, Starknet и другие проекты.
Как параллельность работает с EVM
У Ethereum Virtual Machine (EVM — виртуальная машина эфириума) контракт может во время исполнения обращаться к другому контракту и произвольным ячейкам хранилища. Зависимости часто становятся понятны только после запуска операции.
Monad решает задачу оптимистично. Транзакции сохраняют обычный линейный порядок, но первый проход выполняется параллельно. Затем результаты подтверждаются по порядку.
Если операция прочитала данные, которые изменила более ранняя транзакция, она выполняется повторно. По документации Monad, одна транзакция исполняется максимум два раза: первоначально и, если обнаружилась зависимость, при повторном проходе.
При этом конфликт определяется не по адресу контракта, а по конкретным данным. В документации Monad есть пример: Алиса переводит USDC Бобу, а Чарли — Дэвиду. Обе транзакции вызывают один контракт USDC, но работают с разными ячейками балансов и могут считаться параллельно.
Если же первая операция переводит USDC Алисы Бобу, а следующая сразу отправляет часть баланса Боба Чарли, появляется зависимость. Вторая сначала увидит старый баланс Боба, поэтому ее придется пересчитать.
Что показывает Sei
Sei использует оптимистичный контроль конкурентного доступа. До исполнения система оценивает, какие ключи состояния может затронуть транзакция, распределяет операции между рабочими потоками, а затем проверяет результат на конфликты. Зависимые операции выполняются повторно.
Документация Sei приводит результаты внутренних испытаний. Простые переводы выросли примерно с 3 тыс. до более 15 тыс. операций в секунду, переводы ERC-20 — с 2,2 тыс. до более 9,5 тыс., обмены на децентрализованной бирже — с 800 до более 2,8 тыс.
Это не заявленная постоянная скорость сети. Чем больше независимых операций, тем лучше загружены ядра. При большом числе конфликтов часть выигрыша съедают проверки и повторное исполнение.
Для готовящегося Sei Giga разработчикам отдельно рекомендуют хранить состояние пользователей раздельно. В документации приведен пример токена, где балансы лежат в отдельных элементах mapping. Добавление общего счетчика переводов, напротив, заставляет все операции менять одну ячейку и создает искусственную очередь.
Узкое место — данные, а не контракт
Сам по себе популярный контракт не означает последовательное исполнение. Важнее, какие именно данные меняют его пользователи.
Десять тысяч переводов одного ERC-20 могут затрагивать тысячи независимых балансов и хорошо распределяться между ядрами. Если те же десять тысяч операций каждый раз увеличивают один глобальный счетчик, все они конкурируют за одну ячейку.
Именно поэтому архитектура приложения начинает влиять на пропускную способность блокчейна. Solana позволяет разделять состояние между аккаунтами, Sui — между объектами, а параллельные EVM находят зависимости на уровне отдельных ячеек хранилища.
Почему больше ядер не означает больше TPS
Параллельное исполнение не отменяет единого результата. Все валидаторы должны получить одно состояние после одного набора транзакций.
Solana старается определить конфликты до исполнения. Sui использует свойства объектов и консенсус. Aptos, Monad и Sei допускают оптимистичный запуск и затем проверяют зависимости. Разные архитектуры решают одну задачу: использовать несколько ядер, не меняя результат вычислений.
Поэтому показатель TPS (transactions per second — транзакций в секунду) без описания нагрузки мало что говорит. Тысяча независимых переводов и тысяча операций вокруг одного общего состояния предъявляют к сети совершенно разные требования.
Не равна параллельность и простому увеличению блока. Большой блок разрешает включить больше вычислений. Параллельное исполнение пытается быстрее обработать имеющуюся работу. После процессора ограничениями становятся память, база состояния, скорость накопителей и передача данных между узлами.
Ethereum сейчас готовит собственный вариант этой оптимизации. Block-Level Access Lists в Glamsterdam должны дать клиентам карту зависимостей, которой сегодняшнему последовательному исполнению не хватает. Актуальная дорожная карта ожидает активацию Glamsterdam во второй половине 2026 года.
Будь в курсе! Подписывайся на Телеграм.
Подписывайтесь на страницы новостей криптовалют -
