Vitalik объясняет EIP-8288: «окончательное решение» масштабирования Ethereum — транзакции станут быстрыми и дешёвыми

Докладчик: Виталик Бутерин

Перевод: Yuliya, PANews

Всем привет! Добро пожаловать на ETHShanghai 2026. Сегодня я хочу обсудить довольно сложную, но крайне важную для будущего Ethereum техническую тему — она позволяет Ethereum достичь чрезвычайно высокой масштабируемости, одновременно сохраняя конфиденциальность и децентрализацию, причём все три свойства могут быть реализованы одновременно. Это предложение, вероятно, действительно изменит архитектуру работы многих компонентов блокчейна. Оно способно изменить многое, но, что удивительно, внедрить его в существующий Ethereum не так уж сложно. Речь идёт о EIP-8288: рекурсивные подписи и агрегация (Recursive Signature and Aggregation).

Ключевая проблема: непримиримость безопасности, конфиденциальности и масштабируемости

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

• Обычная транзакция Ethereum сегодня потребляет около 21 000 газа; независимая проверка подписи ECDSA (около 65 байт) требует примерно 4 000 газа.
• Если перейти на квантово-безопасные подписи (независимо от конкретной постквантовой схемы), потребление газа составит примерно от 100 000 до 300 000 газа, в зависимости от выбранных параметров (например, от необходимости совместимости с блокчейн-кошельками). Но в любом случае стоимость будет в разы выше, чем у сегодняшних транзакций. Квантово-безопасные подписи велики и дороги.

Вторая проблема: доказательства в протоколах конфиденциальности также велики и дороги. Если кто-то пользовался любым протоколом конфиденциальности на основе технологии нулевого разглашения (ZK), он знает, что в Ethereum такие операции требуют минимум около 350 000 газа. Поскольку многие из этих протоколов спроектированы неэффективно, иногда фактическая стоимость достигает около 1 000 000 газа — это очень дорого. Сегодня обычная транзакция может стоить несколько центов, а такая — 20 центов или даже два доллара.

Более серьёзная проблема: если вы хотите одновременно квантовую безопасность и конфиденциальность, вам придётся заменить вышеуказанные схемы доказательствами STARK. Однако одно доказательство STARK требует около 8 000 000 газа, а скорее всего, и больше. То есть, если бы мы сейчас заставили всех использовать транзакции «квантовая безопасность + конфиденциальность», пропускная способность Ethereum с нынешних ~25 TPS упала бы примерно до 0,25 TPS, что сделало бы сеть практически непригодной.

Ещё одна проблема: люди, возможно, захотят поддерживать собственные криптографические схемы. Например, перейти от сегодняшних эллиптических кривых к криптографии на решётках (lattice-based cryptography). Проблема в том, что каждый раз, когда вы хотите поддержать такую новую схему, увеличивается объём самого протокола, требуются дополнительные файлы предварительных вычислений (большие и дорогие). А если не поддерживать эти схемы нативно в EVM или не иметь соответствующих файлов предварительных вычислений, то проверка любой такой подписи в цепочке будет потреблять огромное количество газа.

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

Ключевое решение: перенос агрегации в мемпул

Итак, как решить эту проблему? Именно это и реализует EIP-8288.

Основная идея: мы не помещаем все эти подписи и доказательства STARK (эти огромные и сложные объекты) непосредственно в цепочку, а оставляем их вне цепочки и выполняем агрегацию внутри мемпула.

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

С точки зрения пользователя: пользователь отправляет транзакцию, вместе с которой передаётся этот огромный объект (подпись/доказательство), но сам этот огромный объект никогда не попадает в цепочку. В цепочку попадает только одно доказательство STARK, которое проверяет, что все подписи и доказательства из всех пользовательских транзакций действительно существуют и действительны.

Этот механизм основан на EIP-8141 (нативная абстракция учётных записей), который будет представлен в следующем хардфорке. EIP-8141 объединяет результаты почти десятилетних исследований сообщества Ethereum в области абстракции учётных записей и позволяет каждой транзакции явно и точно декларировать свои составные части, спецификации подписей и алгоритмы проверки, придавая транзакциям большую программируемость и типизированную структуру.

В EIP-8288 мы добавили новый тип фрейма, который можно понимать как «зависимость». Всего существует два типа зависимостей: один для подписей, другой для доказательств (STARK). В отличие от текущей модели, где подпись непосредственно встроена в транзакцию, в новом механизме сама транзакция содержит лишь абстрактное объявление, указывающее, от какого типа подписи и доказательства она зависит. При трансляции транзакции полные данные отправляются вместе с ней, но в блок записывается только микрофрейм, несущий зависимости. Каждая зависимость занимает всего 96 байт, а большинство — даже 65 байт. Остальные громоздкие криптографические сущности поглощаются и агрегируются внутри мемпула и в конечном итоге предстают в реестре блокчейна в виде единственного доказательства.

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

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

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

Суть архитектуры: «специализированный шардинг»

Один из способов понять этот механизм — рассматривать его как специализированный шардинг. Идея в том, чтобы выделить чрезвычайно дорогие части вычислений, связанные с огромными объёмами данных, и позволить всей распределённой сети обрабатывать их параллельно очень свободным, неструктурированным образом.

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

• одна часть описывает, «что делает эта транзакция, как она взаимодействует с состоянием и с другими транзакциями»;
• другая часть — это тот громоздкий и дорогостоящий компонент транзакции, то есть чисто проверочная работа.

Благодаря целенаправленному выносу проверочной нагрузки в отдельный шард, объём данных, который консенсусный уровень основной цепи должен обрабатывать всеми узлами-валидаторами, строго сжимается до крайне малого диапазона 100–300 КБ на блок. Эти накладные расходы лишь примерно вдвое превышают текущий объём данных блока Ethereum, и по мере линейного роста общей пропускной способности сети доля этих постоянных расходов в общей нагрузке будет непрерывно снижаться.

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

Что это значит для Ethereum?

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

Ethereum, родившийся десять лет назад, делал ставку на полностью универсальные вычисления, но при этом был совершенно немасштабируемым. Поэтому сейчас мы разделяем вычисления на разные типы и целенаправленно делаем чрезвычайно масштабируемыми те типы, которые «по своей природе лучше поддаются масштабированию», — мы создаём для этого более специализированные «инструменты».

В то же время мы делаем вычисления, которые приходится обрабатывать менее эффективно, меньше по объёму и проще в обработке. EIP-8288 — это как раз гипермасштабирование двух типов объектов: «проверки подписей» и «проверки доказательств с нулевым разглашением».

Ещё один интересный момент: я знаю, что многие давно интересуются, когда Ethereum перейдёт на RISC-V, потому что по сравнению с текущими решениями RISC-V или другие более современные наборы инструкций гораздо эффективнее и одновременно проще. И EIP-8288, вероятно, станет первым сценарием в Ethereum, где действительно будет внедрён RISC-V (или аналогичный набор инструкций). Причина в том, что EIP-8288 позволяет пользователям отправлять доказательства, а при отправке доказательства пользователю нужно на каком-то языке выразить те утверждения, которые он проверяет, — и RISC-V как раз является таким языком.

То есть логика проверки, выраженная на RISC-V, должна быть физически выполнена лишь один раз локально на клиенте пользователя: пользователь генерирует соответствующее доказательство (в сценарии конфиденциальности это ZK-STARK) и сразу же отправляет его в мемпул; первый же ретранслирующий узел рекурсивно сжимает его вместе с сотнями или тысячами аналогичных доказательств со всей сети в единую сущность.

Это также равносильно разделению всех вычислений на две большие категории:

• «зависимости» — то есть те части, которые должны быть гарантированно корректными, чтобы транзакция была действительной;
• «бизнес-логика» — то, что транзакция фактически делает.

Бизнес-логика, таким образом, может стать легче и чище, а это значит, что и логика построения блоков, зависящая от порядка транзакций, тоже станет проще. А часть, связанная с «зависимостями», может обрабатываться параллельно в огромных масштабах, практически без серьёзных изменений в опыте разработки для разработчиков Ethereum.

Практическая ценность для разработчиков, пользователей и Layer 2

Для всех, кто строит приложения в цепочке, главный смысл всего этого в том, что самые дорогие сегодня операции станут значительно дешевле.

• Накладные расходы на выполнение квантово-безопасных транзакций сожмутся до почти пренебрежимо малого уровня;
• Приложения для защиты конфиденциальности, построенные на zk-SNARK/STARK, избавятся от оков высоких комиссий за газ, станут доступны по доступным ценам и при этом будут изначально обладать квантовой стойкостью.

Помимо сценариев конфиденциальности, эффективность применения zk-SNARK для масштабирования (особенно в Layer 2) качественно возрастёт. Сейчас многие ZK-Rollup, чтобы распределить высокие затраты на газ при публикации доказательств состояния в основную сеть, вынуждены удлинять периоды отправки и проводить пакетные расчёты с частотой раз в десять минут или даже раз в час. Это серьёзно ограничивает скорость окончательного подтверждения в периоды низкой сетевой активности.

Финальная эволюция: полный перенос вычислений на периферию

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

По сути, это масштабирование Ethereum за счёт перемещения вычислений из «центра» цепочки на «периферию». В результате то, что сегодня в Ethereum является самым дорогим (различные формы безопасности, различные формы конфиденциальности и совместимость с внешними приложениями), — то, что сегодня люди просто не делают из-за высокой стоимости, — в будущем станет значительно дешевле и по-настоящему доступно каждому.

Я надеюсь, что это лишь первый шаг на пути превращения Ethereum из той архитектуры, которая используется практически с момента его рождения, в совершенно иную и гораздо более мощную архитектуру — архитектуру, которая по-настоящему объединит две вещи: самую раннюю и очень простую идею блокчейна от Сатоши Накамото и чрезвычайно мощные, чрезвычайно современные криптографические технологии, которые мы накопили с тех пор.

Участие экосистемы и прогресс внедрения

В настоящее время активно ведутся ранние исследования и инженерная проверка этого решения, и техническое сообщество уже может участвовать в разработке с нескольких точек входа:

• Сетевые имитационные модели: уже открыты ранние инструменты моделирования топологии мемпула и механизмов агрегации и распространения;
• Работа тестовой сети: запущена тестовая сеть EIP-8141, поддерживающая фреймовые транзакции;
• Соревнования по оптимизации алгоритмов: продвигается специализированный конкурс алгоритмов для сообщества разработчиков, сосредоточенный на эффективной реализации базовых систем доказательств;
• Реализация и верификация кода: базовый прототип кодовой базы уже имеет начальную форму и доступен разработчикам экосистемы для независимых клиентских реализаций и формальной верификации.

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