Криптографические доказательства как основа Ethereum к 2030 году: кто проверяет результат?

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

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

Эссе Бутерина от 27 сентября «Криптографический мировой компьютер» описывает конечную цель как комбинацию блокчейна, криптографической приватности и верификации, а также децентрализованных внесетевых компонентов. Он противопоставляет старую модель скачивания и повторного выполнения модели, в которой узлы выборочно проверяют данные и верифицируют доказательства. Он описывает другие возможные изменения в консенсусе и построении блоков. Это личное техническое видение, а не окончательная спецификация обновления, ратифицированная всеми командами клиентов Ethereum.

Различие между тем, что существует, и тем, что задумано, важно. PeerDAS появился вместе с Fusaka в декабре 2025 года, согласно обновлению протокольных приоритетов Ethereum Foundation за февраль 2026 года. Фонд заявляет, что валидаторы теперь выборочно проверяют данные blob вместо загрузки всех данных. Общесетевой переход к верификации кратких доказательств исполнения для блоков базового уровня не описывается как уже развёрнутый. Читатель, услышавший, что Ethereum «будет верифицировать доказательства в 2030 году», должен спросить, какое доказательство, какие вычисления оно охватывает и какие участники могут независимо его проверить.

PeerDAS проверяет доступ к данным, а не каждое вычисление

Уже развёрнутый компонент — это PeerDAS, или одноранговая выборка доступности данных. Rollup-ы помещают данные транзакций в пространство blob Ethereum, чтобы другие участники могли получить достаточно информации для восстановления состояния и привлечения оператора к соблюдению правил. Старый подход, при котором каждый узел загружает каждый blob, сделал бы большие объёмы данных дорогостоящими для обычных валидаторов. Выборка просит узлы проверять небольшие фрагменты на соответствие криптографическим обязательствам, в то время как сеть распространяет достаточно закодированных фрагментов для восстановления.

Объяснение Ethereum гласит, что расширенные данные blob разделены на 128 столбцов. Обычный узел присоединяется как минимум к 8 случайно выбранным подсестям столбцов. Восемь, делённое на 128, составляет одну шестнадцатую расширенных данных. Кодирование добавляет избыточность, так что это количество соответствует примерно одной восьмой исходного объёма данных согласно описанию в документации. Эти числа относятся к рабочей нагрузке данных узла по умолчанию, а не к утверждению, что один узел может лично хранить всю историю каждого rollup-а за одну восьмую стоимости.

Кодирование в стиле Рида-Соломона создаёт избыточные фрагменты данных, а криптографические обязательства помогают узлу проверить, что выбранный фрагмент принадлежит тому, что было объявлено. Выборка обеспечивает вероятностную гарантию доступности среди участвующих узлов. Она не заменяет проверку исполнения. Идеально доступный пакет транзакций может содержать недопустимый переход состояния. Точно так же действительного доказательства о переходе состояния недостаточно, чтобы пользователь мог восстановить состояние счёта, если необходимые для этого данные удерживаются вне гарантий доступности.

Ethereum Foundation заявил, что Fusaka обеспечил восьмикратное увеличение теоретической пропускной способности блобов. Слово «теоретической» имеет значение: фактическая устойчивая пропускная способность зависит от запланированных увеличений параметров, условий сети и использования роллапов. Crypto.news объяснил, как роллапы используют уровень данных Ethereum. Новое эссе Бутерина рассматривает PeerDAS как первый видимый шаг к системе, которая проверяет больше и повторяет меньше; его не следует переиначивать как окончательное обновление доказательства исполнения.

Доказывающий выполняет тяжёлую работу; независимые узлы проверяют её

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

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

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

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

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

Три обещания часто вкладываются в слово «доказательство»

Возьмём пользователя, отправляющего платёж через роллап. Транзакция должна быть включена в упорядоченный пакет. Данные пакета должны быть сделаны доступными в рамках выбранной роллапом модели. Наконец, результирующее изменение состояния должно следовать его правилам. Упорядочение, доступность и корректность — это отдельные обещания. Доказательство корректности касается последнего для заданного вычисления. PeerDAS касается доступности данных блобов Ethereum. Механизм секвенсора или построения блоков влияет на то, какие транзакции включаются и в каком порядке.

Crypto.news рассмотрел секвенсоры как отдельную точку контроля. Идеально validное доказательство может подтвердить, что пакет был обработан по правилам, даже если его оператор исключил транзакцию конкретного клиента. У пользователя может быть маршрут выхода или принудительного включения в зависимости от дизайна этого rollup, но само доказательство не обеспечивает справедливый доступ. Секвенсор также может переупорядочивать транзакции, всё ещё создавая validный переход состояния. Утверждение, которое доказывается, не должно быть ошибочно принято за все свойства, которые пользователи хотят получить от рынка.

Сторона данных так же легко размывается. Документация Ethereum по validium описывает системы, которые используют доказательства валидности, но не публикуют данные транзакций в основную сеть Ethereum. Их выполнение может быть корректным с точки зрения верификатора, однако сбой доступности данных может помешать пользователям восстановить состояние или вывести средства, как ожидалось. Ethereum rollup, публикующий достаточные данные в Ethereum, имеет другую модель доступности. Называть оба просто «ZK» скрывает критическую разницу в способности пользователя восстановить состояние счёта без оператора.

Простейший тест — это мысленный чек-лист из трёх колонок. Спросите, кто включает транзакцию в пакет. Спросите, где можно получить данные, необходимые для восстановления балансов. Спросите, какой контракт или узел проверяет доказательство корректности состояния. Если проект отвечает только на третий вопрос, он не ответил на первые два. Вот почему эссе Бутерина говорит о построении блоков и распределении сетевых данных наряду с криптографией, а не о замене всей системы одним магическим доказательством.

Базовый слой не может заимствовать все свойства у существующих rollup

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

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

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

Есть кажущееся противоречие, которое стоит разрешить. Если узлы перестают повторно выполнять вычисления, как кто-либо найдёт ошибку в доказываемом вычислении? Один из ответов: разработчики могут запускать независимое полное выполнение и сравнивать его с результатами доказательства во время разработки и после развёртывания. Другой — множественные реализации доказательств и формальные проверки схем. Точный дизайн Ethereum ещё не финализирован. Протокол, который уменьшает требуемое повторное выполнение, не запрещает людям выполнять дополнительные проверки; он меняет то, что каждый обычный валидирующий узел должен делать для консенсуса.

В сентябрьском обновлении приоритетов протокола Фонд рассматривает L1 zkEVM и формальную верификацию как основные рабочие направления. Это свидетельство активной инженерной работы, а не установленная дата запуска. Стандарт безопасности высок, потому что ошибка в системе доказательств базового слоя повлияла бы на фундамент, от которого зависят другие приложения.

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

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

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

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

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

Независимость можно измерить до финального форка

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

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

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

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

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

Hegota — это маркер, а не гарантия релиза в 2030 году

Бутерин называет Hegota, форк, запланированный на 2027 год, возможно, последним обновлением, компоненты которого были бы знакомы наблюдателю Ethereum 2015 года. Последующая работа в его описании будет включать рекурсивные STARK, формальную верификацию, оптимизированный консенсус и квантовую безопасность. Crypto.news сообщал об отдельной квантовой цели на 2029 год как о плановой цели. Ни эссе, ни целевая дата не доказывают, что каждый предложенный компонент будет готов и принят в срок.

Обновления Ethereum требуют спецификаций, реализаций клиентов, тестовых сетей, проверок безопасности и координации между участниками. Strawmap — это карта исследований и возможных этапов, а не ончейн-внедрение. Можно проверить, что PeerDAS развёрнут, посмотрев на релиз Fusaka и текущие правила узлов. Нельзя проверить будущий общий базовый zkEVM, посмотрев на синюю колонку 2030 года в эссе. Доказательства появятся сначала в публичных спецификациях и тестах, затем в конкретном плане форка и производственной активации.

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

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

На что обратить внимание

• Спецификации L1 zkEVM. Ищите конкретный верификатор, формат публичных входных данных и правила исполнения, принятые всеми клиентами.
• Разнообразие пруверов. Множество независимых реализаций и измеренные потребности в оборудовании проверят, имеет ли производство доказательств единую точку отказа.
• Измерения PeerDAS. Проверяйте пропускную способность блобов и пропускную способность узлов по мере увеличения параметров после запуска в декабре 2025 года.
• Решения по Hegota. Окончательный объём форка важнее, чем кандидатные функции в черновой дорожной карте.
• Гарантии данных и порядка. Изучите, сохраняют ли роллапы и будущие проекты базового уровня независимую реконструкцию и включение транзакций.

Часто задаваемые вопросы