Докладчик: Виталик Бутерин
Составитель: Yuliya, PANews
Всем привет! Добро пожаловать на ETHShanghai 2026. Сегодня я хочу обсудить с вами довольно сложную техническую тему, которая имеет решающее значение для будущего Ethereum — она может позволить Ethereum достичь чрезвычайно высокой масштабируемости, одновременно обеспечивая баланс между конфиденциальностью и децентрализацией, причём все три цели могут быть достигнуты одновременно. Это предложение с большой вероятностью действительно изменит операционную архитектуру многих компонентов в блокчейне. Оно может изменить многое, но, как ни странно, его фактическая реализация в существующем Ethereum не так уж сложна. Это EIP-8288: Рекурсивная подпись и агрегация.
Ключевая проблема: несовместимость безопасности, конфиденциальности и масштабируемости
Сегодня я хочу сосредоточиться на нескольких основных вопросах, которые всех очень волнуют: квантовая безопасность, конфиденциальность и масштабируемость. В настоящее время большая проблема заключается в том, что как квантовая безопасность, так и конфиденциальность в настоящее время сильно конфликтуют с масштабируемостью:
Обычная транзакция Ethereum в настоящее время потребляет около 21 000 газа; независимая проверка подписи ECDSA (около 65 байт) занимает около 4 000 газа.
Если заменить их на квантово-безопасные подписи (независимо от того, какая схема постквантовой подписи выбрана), потребление газа составит примерно от 100 000 до 300 000 газа, в зависимости от выбранного размера параметров (например, нужна ли совместимость со сценариями блокчейн-кошельков). Но как бы вы ни выбирали, стоимость будет в несколько раз выше, чем у сегодняшних транзакций — квантово-безопасные подписи большие и дорогие.
Вторая проблема: доказательства для протоколов конфиденциальности также большие и дорогие. Если кто-то использовал какой-либо протокол конфиденциальности на основе технологии с нулевым разглашением (ZK), он знает, что в Ethereum такие операции стоят как минимум около 350 000 газа. Поскольку многие такие протоколы спроектированы не очень эффективно, иногда фактическая стоимость может достигать даже около 1 миллиона газа — это очень дорого. Сегодня обычная транзакция может стоить всего несколько центов, а такие транзакции могут стоить 20 центов или даже два доллара.
Более серьёзная проблема: если вы хотите одновременно квантовую безопасность и конфиденциальность, вам нужно использовать доказательства STARK вместо предыдущих схем. Однако доказательство STARK потребляет около 8 миллионов газа, и вполне вероятно, что больше. То есть, если мы сейчас позволим всем начать использовать транзакции «квантово-безопасные + конфиденциальные», первоначальная пропускная способность Ethereum около 25 TPS резко упадёт примерно до 0,25 TPS, почти потеряв пригодность для использования.
Ещё одна проблема: люди могут также захотеть поддержать пользовательские криптографические схемы. Например, переход от сегодняшних эллиптических кривых к будущей криптографии на решётках. Проблема в том, что каждый раз, когда вы хотите поддержать такую новую схему, это увеличивает размер самого протокола и требует больше файлов предварительных вычислений (больших по размеру, дорогих). И если вы не поддерживаете эти схемы нативно в EVM или не имеете соответствующих файлов предварительных вычислений, то проверка любой такой подписи в сети будет потреблять очень большое количество газа.
Иными словами, все наши цели в области безопасности и конфиденциальности фактически препятствуют масштабируемости, по крайней мере, в рамках текущей архитектуры.
Ключевое решение: перенести вычисления агрегации в мемпул
Итак, как мы решаем эту проблему? Это основной механизм, реализуемый EIP-8288.
Основная идея такова: вместо того чтобы напрямую помещать все эти подписи и все эти доказательства STARK (эти огромные, структурно сложные объекты) в сеть, мы держим их вне сети и выполняем агрегацию внутри мемпула.
Конкретно: когда пользователь отправляет транзакцию, в мемпуле есть группа узлов, и эти узлы уже работают до того, как транзакция будет упакована в блок. То, что делают эти узлы, называется «агрегацией» — они заменяют большое количество подписей и доказательств одним доказательством, которое может подтвердить, что все эти подписи и доказательства действительно существуют и действительны.
Итак, с точки зрения пользователя: пользователь отправляет транзакцию, и вместе с транзакцией он также отправляет этот огромный объект (подпись/доказательство), но сам этот огромный объект на самом деле никогда не попадает в блокчейн. В блокчейн фактически попадает только одно доказательство STARK, используемое для проверки того, что все подписи и все доказательства, содержащиеся во всех пользовательских транзакциях, действительно существуют и являются действительными.
Этот механизм построен поверх EIP-8141 (нативная абстракция аккаунта), который будет представлен в следующем хардфорке. EIP-8141 конденсирует почти десятилетие исследований сообщества Ethereum в области абстракции аккаунта. Он позволяет каждой транзакции напрямую и точно явно объявлять свои составные компоненты, спецификации подписи и алгоритмы проверки, придавая транзакциям более сильную программируемость и типизированную структуру.
В EIP-8288 мы добавили новый тип фрейма, который можно понимать как «зависимость». Всего существует два вида зависимостей: одна соответствует подписям, а одна соответствует доказательствам (STARK). В отличие от текущей модели, где подписи напрямую встроены в тело транзакции, в новом механизме сама транзакция содержит только абстрактное объявление, указывающее, от какого типа подписи и доказательства зависит транзакция. Когда транзакция транслируется, хотя полные данные отправляются вместе с ней, в конечном итоге в блок записывается только микроструктура фрейма, несущая зависимости. Данные, занимаемые каждой зависимостью, составляют всего 96 байт, а большинство — даже всего 65 байт. Остальные огромные криптографические сущности поглощаются и агрегируются внутри мемпула и в конечном итоге появляются в реестре блокчейна только в виде одного доказательства.
В рамках этой архитектуры каждый узел в мемпуле непрерывно прослушивает носитель данных, называемый «конвертом». Один конверт может инкапсулировать несколько транзакций и сопровождающие их доказательства.
Узлы используют фиксированный период времени в качестве окна, непрерывно собирают все объекты-конверты, наблюдаемые в течение этого периода, выполняют локальное агрегационное вычисление, а затем транслируют его. Во время трансляции все изначально дискретные независимые доказательства заменяются одним глобальным агрегированным доказательством, которое математически строго покрывает корректность всех базовых подписей в этом пакете.
Это показывает, что до того, как узлы упаковки блоков формально выполнят обновления состояния, сеть Ethereum уже завершила подавляющее большинство высокоинтенсивных проверочных вычислений на этапе мемпула в неконсенсусном слое.
Архитектурная сущность: «специализированный шардинг»
Один из способов понять этот механизм — рассматривать его как своего рода специализированный шардинг. Его идея такова: мы можем выделить те чрезвычайно дорогостоящие части вычислений, связанные с чрезвычайно большими объёмами данных, и позволить всей распределённой сети обрабатывать эту часть вычислений параллельно очень свободным, неструктурированным способом.
Этот подход не хрупок; напротив, он очень устойчив — любой узел может взять на себя любую часть этой работы. По сути, мы делаем следующее: разделяем каждую транзакцию на две части:
Одна часть объясняет «что делает эта транзакция, как она взаимодействует с состоянием и как она взаимодействует с другими транзакциями»;
Другая часть — это огромная, дорогостоящая часть этой транзакции, то есть чисто проверочная работа.
Путём специализированного шардирования и отделения проверочной нагрузки полезная нагрузка данных, которую консенсусный слой основной цепи в конечном итоге требует от всех сетевых проверяющих узлов совместно нести, строго сжимается до чрезвычайно малого диапазона в 100–300 КБ на блок. Эти накладные расходы составляют лишь примерно вдвое больше текущего объёма данных блока Ethereum, и по мере линейного расширения общей пропускной способности сети доля этих постоянных накладных расходов в общей сетевой нагрузке будет продолжать размываться.
По сути, мы делаем следующее: переносим работу от валидаторов и даже от узлов, упаковывающих блоки, продвигая эту часть работы к тем внецепочечным узлам, которые находятся между «пользователь отправляет транзакцию» и «узел, упаковывающий блок, фактически включает транзакцию в блок».
Что это значит для Ethereum?
С технической точки зрения это означает, что Ethereum гипермасштабирует определённый класс вычислений. Я думаю, это также тенденция, которую мы будем видеть всё чаще по мере дальнейшего развития Ethereum.
Ethereum, родившийся десять лет назад, был сосредоточен на полностью общих вычислениях, но также полностью лишён масштабируемости. Поэтому сейчас мы делаем следующее: разделяем вычисления на разные типы, а затем специально делаем те типы вычислений, которые «естественно более пригодны для масштабирования», чрезвычайно масштабируемыми — мы создаём эти более специализированные «маленькие инструменты», чтобы accomplish это.
В то же время мы также делаем те вычисления, которые должны обрабатываться менее эффективным способом, меньше и проще в обработке. 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, чтобы распределить высокую стоимость газа за публикацию доказательств состояния в основную сеть, часто вынуждены удлинять цикл отправки, рассчитываясь пакетами с частотой в десять минут или даже час. Это серьёзно ограничивает скорость окончательного подтверждения в периоды низкой активности транзакций в сети.
В настоящее время многие ZK-Rollup, чтобы распределить высокую стоимость газа за публикацию доказательств состояния в основную сеть, часто вынуждены удлинять цикл отправки, рассчитываясь пакетами с частотой в десять минут или даже час. Это серьёзно ограничивает скорость окончательного подтверждения в периоды низкой активности транзакций в сети.
Эволюция эндшпиля: полное вытеснение вычислений на периферию
Наконец, если есть другие вычисления, которые вы хотите выполнить, но их слишком дорого исполнять внутри EVM, я надеюсь, что мы действительно сможем начать менять направление — больше не заставляя сам протокол Ethereum напрямую нести все вычисления, которые все хотят выполнять, а вместо этого побуждая пользователей завершать эту часть вычислений локально на своих клиентах, а затем публиковать доказательство, чтобы это доказательство проверялось в Ethereum.
По сути, это масштабирование Ethereum путём вынесения вычислений из «центра» цепи и выталкивания их на «периферию». Результат таков: то, что сегодня на Ethereum является самым дорогим (различные формы безопасности, различные формы приватности и различные формы совместимости с внешними приложениями), сегодня не делается людьми, потому что это слишком дорого, а в будущем всё это станет намного дешевле и действительно доступным для всех.
Я надеюсь, что это лишь первый шаг в преобразовании Ethereum из архитектуры, которую он использовал почти с самого своего рождения, в совершенно иную и ещё более мощную новую архитектуру — новую архитектуру, которая по-настоящему объединяет две вещи: одну — очень простую раннюю идею блокчейна от Сатоши Накамото; другую — чрезвычайно мощную и чрезвычайно современную криптографическую технологию, которую мы непрерывно накапливали с тех пор.
Участие экосистемы и прогресс внедрения
В настоящее время интенсивно ведутся ранние исследования и инженерная валидация вокруг этого подхода, и техническое сообщество уже может участвовать в построении через несколько точек входа:
Сетевые имитационные модели: открыты ранние инструменты моделирования для топологии мемпула и механизмов агрегации и распространения;
Работа тестовой сети: тестовая сеть EIP-8141, поддерживающая форму фреймовых транзакций, уже введена в тестирование;
Конкурсы по оптимизации алгоритмов: продвигаются специальные конкурсы алгоритмов для сообщества разработчиков, сосредоточенные на эффективной реализации базовой системы доказательств;
Реализация и верификация кода: базовая кодовая база прототипа уже сформировалась, чтобы разработчики экосистемы могли выполнять независимые реализации клиентов и формальную верификацию.
Огромное количество базовых технических компонентов быстро заполняется. Разработчики приглашаются к глубокому участию в этом техническом процессе и к тому, чтобы помочь этой революционной архитектуре как можно скорее стать реальным стандартом в основной сети Ethereum.
