Виталик Последнее выступление о EIP-8288: масштабирование Ethereum встречает "конечное решение", будущие транзакции будут быстрыми и дешевыми

Докладчик: Vitalik Buterin

Скомпилировано: Yuliya, PANews

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

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

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

• Обычная транзакция Ethereum в настоящее время потребляет около 21,000 gas; независимая проверка ECDSA подписи (около 65 байт) требует около 4,000 gas.

• Если использовать квантово-устойчивую подпись (независимо от типа квантово-устойчивого решения), потребление gas составит от 100,000 до 300,000 gas, в зависимости от выбранного размера параметров (например, требуется ли совместимость с кошельками блокчейна). Но как бы вы ни выбрали, стоимость будет в несколько раз выше, чем у сегодняшних транзакций — квантово-устойчивая подпись большая и дорогая.

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

Более серьезная проблема заключается в том, что если вы хотите и квантовую безопасность, и конфиденциальность, вам нужно использовать доказательства STARK вместо предыдущих решений. Однако одно доказательство STARK требует около 8,000,000 gas, и, вероятно, даже больше. Это означает, что если мы сейчас заставим всех начать использовать "квантовую безопасность + конфиденциальность" в транзакциях, способность Ethereum обрабатывать около 25 TPS упадет до примерно 0.25 TPS, что практически лишит его возможности использования.

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

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

Основное решение: предварительная агрегация вычислений в мемпуле (mempool)

Итак, как мы можем решить эту проблему? Это и есть основная механика реализации EIP-8288.

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

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

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

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

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

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

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

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

Суть архитектуры: "специализированные шардирования"

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

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

• Одна часть объясняет "что делает эта транзакция, как она взаимодействует с состоянием, как она взаимодействует с другими транзакциями";

• Другая часть — это та большая, тяжелая часть транзакции — то есть чисто проверочная работа.

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

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

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

С технической точки зрения это означает, что Ethereum осуществляет супермасштабирование (hyper-scaling) для определенного типа вычислений. Я считаю, что это также тенденция, которую мы будем все чаще наблюдать по мере развития 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 для защиты конфиденциальности, избавятся от высоких затрат на gas, что позволит им стать доступными по цене и изначально обеспечит квантовую устойчивость.

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

В настоящее время многие ZK-Rollup вынуждены удлинять циклы подачи, чтобы размыть высокие затраты на gas при публикации доказательств состояния в основной сети, часто выполняя пакетные расчеты с интервалами в десять минут или даже час. Это серьезно ограничивает скорость окончательного подтверждения в периоды низкой активности сети.

Эволюция финала: полностью вынести вычисления на крайние границы

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

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

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

Участие в экосистеме и прогресс реализации

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

• Модели сетевого уровня: ранние инструменты моделирования для топологии пула памяти и механизмов агрегированной передачи уже открыты;

• Запуск тестовой сети: тестовая сеть EIP-8141, поддерживающая формы транзакций с кадрами, уже запущена в тестирование;

• Конкурсы по оптимизации алгоритмов: специальные алгоритмические соревнования для сообщества разработчиков продвигаются, сосредоточенные на эффективной реализации базовой системы доказательств;

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

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