Видение Ethereum на 2030 год зависит от доказательств. Сложность в том, кто их проверяет

Последняя дорожная карта Виталика Бутерина указывает на сеть иного типа.

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

Одна часть этого видения уже реализована. PeerDAS был запущен вместе с обновлением Ethereum Fusaka в декабре 2025 года. Он позволяет валидаторам делать выборку данных блобов, а не загружать их целиком.

Более масштабный сдвиг — использование доказательств для более широкой проверки исполнения на базовом уровне — остаётся делом будущего.

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

Вопрос не только в том, может ли Ethereum генерировать доказательства. Вопрос в том, могут ли обычные участники независимо проверять результаты.

Что уже существует

Развёрнутая часть — это PeerDAS, сокращение от peer-to-peer data availability sampling (одноранговая выборка доступности данных).

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

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

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

Это не означает, что один узел лично хранит или проверяет всю историю роллапов за одну восьмую стоимости. Это означает, что сеть распределяет и делает выборку достаточного объёма закодированных данных, чтобы создать вероятностную гарантию доступности.

PeerDAS проверяет доступность данных. Он не проверяет каждое вычисление.

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

Доказательства переносят тяжёлую работу в другое место

В модели исполнения на основе доказательств кто-то всё равно должен исполнять транзакции.

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

Это основное обещание L1 zkEVM: снизить стоимость проверки блоков Ethereum, не требуя от каждого валидирующего узла повторять всё исполнение.

Но должны выполняться несколько условий.

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

Быстрая генерация доказательств — не то же самое, что безопасная верификация. Ethereum по-прежнему будут нужны независимые реализации, аудиты, формальная проверка и разнообразие клиентов.

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

Бутерин может предложить направление. Он не может сам сделать будущий верификатор безопасным или обязательным.

Верификация и производство доказательств — разные рынки

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

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

Риск — в живучести.

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

Это иной риск, чем принятие недействительного доказательства. Но он всё равно реален.

Надёжная конструкция потребовала бы нескольких независимых пруверов, резервных механизмов, правил тайминга или других способов поддерживать цепь живой при сбое одной системы доказательств.

Ethereum ещё не финализировал эту конструкцию.

Доказательства не решают всех проблем

Слово «доказательство» часто сжимает три отдельные гарантии в одну.

Пользователю, отправляющему транзакцию через роллап, нужны три вещи.

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

Доказательство действительности относится к третьему пункту. PeerDAS отвечает за доступность данных блобов Ethereum. Секвенсоры, строители блоков и механизмы включения влияют на первый пункт.

Это разные проблемы.

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

То же различие относится к данным.

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

Роллап, публикующий достаточные данные в Ethereum, имеет другую модель доверия.

Называть обе системы «ZK» может скрывать самое важное различие: могут ли пользователи восстановить состояние своего счёта, не полагаясь на оператора.

Базовый уровень — это не просто ещё один роллап

ZK-роллапы уже отправляют доказательства действительности в Ethereum. Их операторы генерируют доказательства для пакетов, а контракты-верификаторы принимают новые корни состояния только после проверки этих доказательств.

Это полезный прецедент. Но это не означает, что базовый уровень Ethereum уже перевёл проверку исполнения на доказательства.

Масштаб другой.

Роллап доказывает свой собственный переход состояния в рамках собственной виртуальной машины и контрактов. Базовому уровню Ethereum потребовалось бы проверять исполнение блоков на уровне протокола способом, который принимают все команды клиентов.

Верификатор базового уровня должен обрабатывать правила исполнения Ethereum, обновления протокола, типы транзакций и враждебные входные данные. Он не может просто заимствовать предположения безопасности одной схемы роллапа.

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

Фраза Бутерина «криптографический мировой компьютер» — это направление движения, а не утверждение, что один сервис доказательств будет управлять Ethereum.

Состояние остаётся сложной проблемой

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

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

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

Поэтому масштабирование — это не только проблема генерации доказательств.

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

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

Приватность тоже не автоматична

Видение Бутерина включает децентрализованные офчейн-компоненты и лучшую криптографическую приватность.

Это не означает, что доказательства действительности автоматически делают Ethereum приватным.

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

Приватность требует отдельных механизмов. Система должна указать, какие данные скрыты, кто может получить к ним доступ, как строятся доказательства и какие метаданные остаются видимыми.

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

Криптография может уменьшить доверие. Она не устраняет проектные решения.

Как можно проверить независимость

Утверждение «проверить может каждый» имеет практические требования.

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

Перед любым финальным форком важны несколько тестов.

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

Затем повторите процесс в публичных тестовых сетях под нагрузкой.

Это не официальные критерии запуска. Это наблюдаемые признаки того, готова ли валидация на основе доказательств.

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

Доказываемая программа должна быть правильной

Доказательство полезно настолько, насколько полезно утверждение, которое оно доказывает.

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

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

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

Финальное утверждение — не «криптография решила доверие». Более сильное утверждение уже и полезнее: заданный результат можно независимо отклонить, когда доказательства недействительны, без того чтобы каждый узел платил цену производства этого результата.

Hegota — это маркер, а не гарантия

Бутерин называет Hegota, форк, запланированный на 2027 год, возможно, последним обновлением, компоненты которого показались бы знакомыми наблюдателю Ethereum 2015 года.

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

Ничто из этого не гарантирует реализацию к 2030 году.

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

PeerDAS можно проверить сегодня через Fusaka и текущие правила узлов. Общий zkEVM базового уровня нельзя проверить, прочитав эссе. Доказательства появятся через спецификации, реализации, публичные тесты и конкретный план форка.

Направление ясно, но проверка практическая

Аргумент в пользу будущего Ethereum с активным использованием доказательств силён.

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

Это плюс.

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

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

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

Каждый ответ требует отдельного механизма. Доказательство — лишь одна часть системы. Его сила в том, что оно позволяет людям, не выполнявшим тяжёлую работу, всё равно проверять, действителен ли результат.