Виталик Бутерин заявил, что больше не согласен со своим твитом 2017 года, в котором преуменьшалась необходимость для пользователей лично верифицировать Ethereum от начала до конца.
На этой неделе он утверждал, что сеть должна рассматривать самостоятельную верификацию как безусловный запасной выход по мере того, как её архитектура становится легче и более модульной.
Первоначальная позиция Бутерина возникла из дизайнерской дискуссии о том, должен ли блокчейн фиксировать состояние в цепочке или рассматривать состояние как "подразумеваемое", восстанавливаемое только путём повторного воспроизведения упорядоченных транзакций.
Подход Ethereum, помещающий корень состояния в каждый заголовок блока и поддерживающий доказательства в стиле Меркла, позволяет пользователю доказать конкретный баланс, код контракта или значение хранилища без повторного выполнения всей истории, при условии что пользователь принимает валидность консенсуса цепочки при допущении честного большинства.
В своём новом посте Бутерин переформулировал этот компромисс как неполный на практике, поскольку он всё равно может загнать пользователей в угол, заставляя выбирать между повторным воспроизведением всей цепочки или доверием посреднику, такому как оператор RPC, хост архивных данных или сервис доказательств.
Он обосновал изменение двумя сдвигами: осуществимостью и хрупкостью.
Что касается осуществимости, Бутерин написал, что доказательства с нулевым разглашением теперь предлагают путь для проверки корректности без "буквального повторного выполнения каждой транзакции".
В 2017 году он утверждал, что это подтолкнуло бы Ethereum к более низкой ёмкости, чтобы держать верификацию в пределах досягаемости.
Этот сдвиг имеет значение, потому что публичная дорожная карта Ethereum всё больше рассматривает ZK как примитив верифицируемости, при этом ethereum.org представляет доказательства с нулевым разглашением как способ сохранить свойства безопасности при одновременном сокращении того, что должен вычислять верификатор.
Работа над направлениями "ZK-light-client" также указывает на модель, где устройство может синхронизироваться с использованием компактных доказательств, а не доверять постоянно онлайн-шлюзу.
Что касается хрупкости, Бутерин перечислил режимы отказа, которые находятся за пределами чистых моделей угроз: деградировавшие p2p-сети, закрывающиеся долгоживущие сервисы, концентрация валидаторов, изменяющая практическое значение "честного большинства", и неформальное давление управления, превращающее "позвони разработчикам" в страховку.
Он привёл давление цензуры вокруг Tornado Cash в качестве примера того, как посредники могут ограничивать доступ, утверждая, что последним средством пользователя должно быть "прямое использование цепочки".
Эта формулировка соответствует более широкому обсуждению укрепления базового уровня Ethereum и ограничения изменений на фоне стремления к "окостенению" протокола.
По словам Бутерина, "горная хижина" - это не образ жизни по умолчанию.
Это надёжный запасной вариант, который меняет стимулы, поскольку знание того, что пользователи могут выйти, снижает влияние любого отдельного уровня сервиса.
Этот аргумент актуален, поскольку Ethereum сокращает то, что обычные ноды должны хранить, в то время как история верификации сети должна не отставать.
Исполнительные клиенты движутся к частичному истечению истории, и Ethereum Foundation заявил, что пользователи могут сократить использование диска примерно на 300–500 ГБ, удалив данные блоков до слияния, делая ноду доступной на диске 2 ТБ.
В то же время лёгкие клиенты уже отражают формализованную модель доверия, оптимизированную для устройств с низкими ресурсами, опираясь на комитет синхронизации из 512 валидаторов, выбираемых примерно каждые 1,1 дня.
Эти параметры делают верификацию лёгкого клиента работоспособной в масштабе.
Однако они также концентрируют пользовательский опыт вокруг доступности корректных данных и хорошо ведущих себя ретрансляторов, когда условия ухудшаются.
Долгосрочная работа Ethereum над "отсутствием состояния" нацелена на снижение потребности нод хранить большое состояние при сохранении валидации блоков нетронутой.
Ethereum.org предупреждает, что "отсутствие состояния" - это неверное название, отличая более слабые формы от более сильных дизайнов, которые остаются исследованием, включая истечение состояния.
Деревья Verkle находятся внутри этого плана, поскольку они уменьшают размеры доказательств и позиционируются как ключевой шаг к валидации без локального хранения большого состояния.
По мере того как всё больше нагрузки по хранению смещается наружу, либо к специализированным хостам истории, либо к другим сетям данных, история безопасности становится меньше о том, кто может хранить всё, и больше о том, кто может независимо проверять корректность и извлекать то, что им нужно, когда путь по умолчанию не работает.
| Что меняется | Почему это важно для верификации | Конкретный параметр или цифра |
|---|---|---|
| Поддержка частичного истечения истории в исполнительных клиентах | Меньше локального хранилища может повысить зависимость от внешней доступности истории, если пути извлечения и верификации не останутся открытыми | ~300–500 ГБ сокращения диска, "комфортно" на диске 2 ТБ |
| Модель доверия лёгкого клиента PoS | Верификация с низкими ресурсами полагается на подписи комитета и доступность данных через пиры или сервисы | Комитет синхронизации из 512 валидаторов, ротация примерно каждые 1,1 дня |
| Деревья Verkle как активатор клиента без состояния | Меньшие доказательства могут сделать валидацию с меньшим хранимым состоянием более практичной | Формулировка дорожной карты связывает деревья Verkle с целями валидации без состояния |
| Различия дорожной карты отсутствия состояния | Отделяет краткосрочные подходы от исследовательских элементов, таких как истечение состояния | Терминология слабого и сильного отсутствия состояния |
| Работа EF над основами безопасности L1 zkEVM | Строгость системы доказательств и стабильность становится частью базовой истории безопасности Ethereum | Акцент на стабилизацию и готовность к формальной верификации |
В течение следующих 12–36 месяцев практический вопрос заключается в том, распространяется ли верификация наружу, поскольку Ethereum экстернализирует больше нагрузки по хранению, или доверие группируется вокруг новых узких мест сервиса.
Один путь состоит в том, что кошельки и инфраструктура переходят от "доверяй RPC" к "верифицируй доказательство", в то время как производство доказательств консолидируется в небольшой набор оптимизированных стеков, которые сложно воспроизвести, перемещая зависимость от одного класса провайдера к другому.
Другой путь состоит в том, что верификация на основе доказательств становится обычной, с избыточными реализациями доказательств и инструментами, которые позволяют пользователям переключать провайдеров или верифицировать локально, когда конечная точка цензурирует, деградирует или исчезает, согласуясь с усилиями, направленными на облегчённые потоки верификации.
Третий путь состоит в том, что обрезка и модульность прогрессируют быстрее, чем UX верификации, оставляя пользователям меньше работоспособных вариантов во время сбоев или событий цензуры.
Это сделало бы "горную хижину" операционно реальной только для узкого среза сети.
Бутерин сформулировал хижину как BATNA Ethereum, редко используемую, но всегда доступную, потому что существование самостоятельного варианта ограничивает условия, налагаемые посредниками.
Он завершил, утверждая, что поддержание этого запасного варианта является частью поддержания самого Ethereum.
Пост "Виталик Бутерин признаёт свою самую большую ошибку проектирования с 2017 года – находится ли ваш Ethereum под угрозой?" впервые появился на CryptoSlate.


