Параллельный EVM-гамбит Sei Network: как 200 000 TPS и финализация менее 400 мс могут изменить ончейн-финансы
Что, если бы исполняемый движок Ethereum мог обрабатывать транзакции так же, как современный процессор обрабатывает потоки — не по одной, а десятками одновременно? Именно на это делает ставку сеть Sei в своем обновлении Giga — масштабной переработке, нацеленной на 200 000 транзакций в секунду и финальность менее 400 миллисекунд на полностью EVM-совместимом Layer 1. Если эти показатели подтвердятся в реальной работе, Sei обеспечит пропускную способность, сопоставимую с централизованными биржами, сохраняя при этом компонуемость, которая делает возможной работу DeFi.
Узкое место последовательной EVM
Виртуальная машина Ethereum была разработана для обеспечения корректности, а не скорости. Каждая транзакция выполняется в строгом порядке: транзакция N должна завершиться до начала транзакции N + 1. Эта последовательная модель упрощает управление состоянием — здесь нет состояний гонки и конфликтов чтения-записи — но она ограничивает пропускную способность скоростью одного потока выполнения.
Для глобального расчетного слоя, обрабатывающего 53 миллиарда долларов TVL в DeFi, это узкое место становится все более болезненным. Газовые аукционы резко возрастают в моменты высокого спроса. Трейдеры DEX наблюдают, как возможности испаряются в 12-секундном интервале между блоками. А протоколы деривативов, которым требуются субсекундные ценовые потоки, вынуждены использовать централизованные бэкенды, что подрывает те самые принципы доверия, которые они декларируют.
Тезис параллельной EVM прост: если большинство транзакций затрагивают разные части состояния (обмен Алисы на Uniswap никак не связан с минтом NFT Бобом), они могут выполняться одновременно. Инженерная задача заключается в обнаружении конфликтов и повторном выполнении при коллизиях — и все это без ущерба для детерминизма.
Архитектура Sei: Оптимистичная параллелизация с самого основания
Sei v2, запущенный как первый параллельный EVM-блокчейн, представил миру EVM оптимистичное параллельное выполнение. Этот подход заимствован из управления параллелизмом в базах данных: все транзакции выполняются параллельно в оптимистичном режиме, затем обнаруживаются конфликты, и повторно выполняется только подмножество конфликтующих транзакций.
Как это работает
- Параллельная диспетчеризация: Входящие транзакции распределяются по нескольким потокам выполнения. Каждый поток обрабатывает назначенные ему транзакции на основе локального снимка состояния.
- Обнаружение конфликтов: После завершения параллельного выполнения этап валидации проверяет, не читали ли и не записывали ли две транзакции данные в одни и те же слоты хранения. Если это произошло, конфликтующая транзакция выполняется повторно с обновленным состоянием.
- Детерминированный порядок: Несмотря на параллельное выполнение, окончательная фиксация состояния следует исходному порядку транзакций, сохраняя семантику EVM. Блокчейн выдает тот же результат, что и при последовательном выполнении транзакций — просто он достигает его быстрее.
Это применимо ко всем типам транзакций в Sei: нативным транзакциям, контракта м CosmWasm (до их предстоящего вывода из эксплуатации) и вызовам EVM.
Реархитектура хранилища
Традиционные узлы EVM хранят состояние в едином дереве Merkle Patricia Trie (или его эквиваленте IAVL в блокчейнах Cosmos). Sei разделила это на два уровня:
- Хранилище состояния (State store): Плоский слой «ключ-значение», оптимизированный для чтений с низкой задержкой и обслуживания RPC-запросов.
- Фиксация состояния (State commitment): Отдельная структура для криптографических доказательств, использующая фиксации на основе аккумуляторов вместо традиционных древовидных структур.
Такое разделение на порядок сокращает операции ввода-вывода (disk I/O) и устраняет избыточные метаданные, которые раздувают обычные деревья Меркла. Для валидаторов это означает более быструю синхронизацию. Для RPC-провайдеров — возможность обрабатывать запросы без задержек, связанных с обходом глубоких древовидных структур.
Sei Giga: Прыжок в 40 раз
Если Sei v2 была доказательством концепции, то Sei Giga — поэтапное внедрение которой запланировано на 2026 год — является системой промышленного уровня. Обновление представляет три основные инновации.
Консенсус Autobahn
Названный в честь знаменитой немецкой безлимитной автомагистрали, Autobahn представляет собой протокол консенсуса BFT, который объединяет параллельное распространение данных, вдохновленное DAG, с частично синхронным консенсусом.
Ключевая идея: в традиционных BFT-протоколах один лидер предлагает блоки, пока другие валидаторы ждут. Autobahn предоставляет каждому валидатору его собственную «полосу» — независимую последовательность пакетов блоков, публикуемых одновременно. Представьте это как многополосное шоссе, где каждая машина (валидатор) едет на полной скорости, а не стоит в очереди за одним головным автомобилем.
Проверка доступности данных происходит вне критического пути консенсуса через механизм Proof-of-Availability. К тому времени, когда блок попадает в консенсус, его данные уже проверены, что устраняет одно из крупнейших узких мест задержки в обычных BFT-системах.
Кастомный клиент исполнения EVM
Вместо форка Geth (как поступает большинство EVM-цепочек), инженерная команда Sei создала новый клиент исполнения EVM с нуля. Результат: примерно в 40 раз более высокая эффективность исполнения по сравнению со стандартными средами на базе Geth.
Кастомный клиент специально разработан для параллельного выполнения с нативной поддержкой параллельных шаблонов доступа к состоянию и оптимизированным управлением памятью для высокопроизводительных рабочих нагрузок. Это принципиально иная инженерная филос офия по сравнению с блокчейнами, которые «прикручивают» параллелизацию к последовательной архитектуре Geth.
Асинхронное выполнение
Sei Giga полностью отделяет консенсус от выполнения. Валидаторы достигают консенсуса исключительно по упорядочиванию транзакций — а не по результирующему состоянию. Затем выполнение происходит асинхронно, параллельно с тем, как уровень консенсуса продолжает финализировать последующие блоки.
Эта архитектура означает, что уровень консенсуса никогда не ждет завершения выполнения, а уровень выполнения никогда не ждет продвижения консенсуса. Две системы работают как независимые конвейеры, каждая из которых функционирует с максимальной пропускной способностью.
Совокупные цели: пропускная способность 5 гигагаз, более 200 000 TPS и финализация менее 400 мс — это уже продемонстрировано в devnet.