Фонд Ethereum устанавливает срок до 2029 года для внедрения обновлений, устойчивых к квантовым вычислениям

Автор оригинала: KarenZ, Foresight News

Квантовые компьютеры еще не постучались в дверь блокчейна, но Фонд Эфириума уже отметил дату в календаре: 12 декабря 2029 года.

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

Запланированный Hegotá, хотя и не превратит Ethereum напрямую в полностью квантово-устойчивую блокчейн-сеть, определит, удастся ли своевременно реализовать последующие планы.

«Q-day» обычно обозначает гипотетический момент появления квантового компьютера с реальной атакующей способностью, что ставит под угрозу существующие системы публичного ключевого шифрования.

Когда он наступит, никто не может точно предсказать. Фонд Эфириума также открыто признает, что большинство надежных прогнозов указывают на то, что Q-day наступит позже 2030 года, возможно, даже значительно позже, и существует вероятность, что он вообще не наступит.

Команда протокола Фонда Эфириума использует консервативные инженерные допущения: сеть Ethereum Layer 1 должна быть подготовлена к тому, что Q-day может наступить не раньше 2030 года.

Для этого команда протокола поставила цель — обеспечить полную квантовую устойчивость трех компонентов Ethereum Layer 1: исполнения, консенсуса и данных до декабря 2029 года.

Эта цель также не является неизменной. Команда протокола планирует в январе 2027 года переоценить развитие квантовых вычислений с учетом мнений внешних экспертов. До этого срока в 2029 году будет рассматриваться как непреклонная рабочая цель.

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

Согласно текущему официальному маршруту, опубликованному командой Фонда Эфириума, сетевое обновление Glamsterdam запланировано на запуск в основной сети в декабре 2026 года, а полная квантовая устойчивость назначена на пятый хардфорк после Glamsterdam — L*, с целевой датой в декабре 2029 года. Между Glamsterdam и L* проходит всего три года; если необходимо последовательно выполнить обновления Hegotá, I*, J*, K* и L*, то средний интервал между каждым обновлением составит около 7,2 месяца.

Это довольно амбициозный график. На данный момент Фонд Эфириума не опубликовал конкретные даты запуска главной сети для Hegotá, I*, J* и K*. Можно с уверенностью сказать, что команды клиентов ожидают начало внедрения Hegotá не ранее позднего четвертого квартала 2026 года, при этом исследования, спецификации и тестирование нескольких последующих версий должны проводиться параллельно.

В соответствии с текущим планом, основные этапы распределены следующим образом:

• Hegotá: находится в начале этого маршрута. Официальная позиция по нему очень ясна: Hegotá сам по себе не является квантово-устойчивым обновлением, но определит, сможем ли мы своевременно реализовать последующее квантово-устойчивое обновление.
• I*: Развернуть квантово-устойчивый реестр открытых ключей для создания протокольной основы регистрации аккаунтов и использования квантово-устойчивых открытых ключей; одновременно декомпозиция консенсуса является текущим ведущим направлением этой версии, а масштабная работа по проектированию и миграции структуры состояния также начнется с I*.
• J*: Создать минимально жизнеспособный квантово-устойчивый уровень — MV-PQ. Его ключевые компоненты включают квантово-устойчивый механизм heartbeat на уровне консенсуса, постквантовую выборку leanDA на уровне данных и постквантовые транзакции leanSPHINCS на уровне исполнения.
• K*: В соответствии с текущим базовым порядком вводится доказательство выполнения. В этот момент направление развития валидаторов будет заключаться в проверке кратких доказательств выполнения, а не в повторном выполнении полных блоков каждым валидатором.
• L*: На основе текущего базового порядка добавьте сообщения с постквантовыми аттестациями, необходимые для полной квантовой устойчивости консенсуса, и достигните полной квантовой устойчивости на уровнях исполнения, консенсуса и данных к декабрю 2029 года.

Однако порядок задач K* и L* еще не окончательно определен. Команда протокола оценивает вариант обмена: перемещение квантово-устойчивых сообщений из L* в K*, чтобы обеспечить полную квантовую устойчивость раньше, и перенос обязательного доказательства из K* в L*. Если будет принята эта схема, конкретные обязанности K* и L*, а также темпы обновлений соответственно изменятся. Поэтому на текущем этапе наиболее точной информацией является следующая: декабрь 2026 года — текущая целевая дата запуска основной сети Glamsterdam, декабрь 2029 года — целевая дата для L* и полной квантовой устойчивости в базовом плане; внутренний порядок K и L* по-прежнему может быть изменен.

Исследователи, разработчики клиентов, сотрудники по безопасности и тестовые команды должны завершить Hegotá, а также заранее подготовить спецификации и прототипы для I*, J*, K* и L*. Если в Hegotá будет включено слишком много взаимосвязанных функций, это не только может задержать её запуск, но и занять команды, необходимые для последующих квантово-устойчивых работ.

Таким образом, команда протокола Фонда Эфириума классифицировала 62 кандидатских предложения на уровни: S (2), A (15), B (8), C (7), DFI (28) и TBD (2). Уровень S означает обязательную реализацию; уровень A — высокий приоритет и ожидаемая реализация; уровень B требует выполнения дополнительных условий, таких как спецификация, прототип или подтверждение ответственного; уровень C временно ниже порога включения; DFI означает, что предложение не рекомендуется включать в эту версию обновления; TBD — решение отложено.

В классификации Hegotá, опубликованной командой протокола, только два EIP попали в класс S: EIP-7805 FOCIL на уровне консенсуса и EIP-8141 Frame-транзакции на уровне исполнения.

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

FOCIL (EIP-7805) расшифровывается как «списки включения, обеспечиваемые правилами выбора форка» (Fork-choice enforced Inclusion Lists). Его цель — улучшить гарантии включения транзакций в Ethereum.

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

Согласно дизайну FOCIL, каждый слот выбирает группу валидаторов, образующих «комитет списка включения» (IL committee). Члены комитета на основе просмотренных ожидающих транзакций составляют и транслируют собственные списки включения. Строитель блока следующего слота собирает эти списки и включает в блок транзакции, соответствующие условиям выполнения. Валидаторы, ответственные за подтверждение нового блока, также сохраняют полученные вовремя списки включения и проверяют, удовлетворяет ли блок соответствующим требованиям.

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

Сопутствующий EIP-8369 дополнительно описывает, какие транзакции подходят для получения гарантии принудительного включения FOCIL. Причины пропуска обычных транзакций относительно легко проверить; транзакции Frames позволяют программную проверку, стоимость которой выше, поэтому необходимо дополнительно ограничить диапазон читаемого состояния и бюджет проверки.

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

Frame Transactions (EIP-8141) решает проблемы на уровне аккаунтов. Он планирует сделать проверку транзакций, выполнение транзакций и оплату газа более программируемыми на уровне протокола, обеспечив основу для нативной абстракции аккаунтов. Виталик является одним из соавторов EIP-8141.

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

Однако Frames сами по себе не являются полной квантово-устойчивой схемой подписи и не заменят существующие ключи сразу после запуска Hegotá. Они обеспечивают «криптографическую гибкость»: в будущем, если потребуется сменить схему подписи, аккаунты смогут перейти на новую схему с помощью программируемой проверки, а не останутся навсегда привязанными к одной системе ключей.

Frames требует еще двух предложений уровня A в качестве основных компонентов. EIP-8250 Keyed Nonces позволяет одному отправителю использовать независимые каналы nonce, чтобы различные транзакции не блокировали друг друга из-за необходимости соблюдения строгого порядка; EIP-8272 позволяет транзакциям использовать недавнее состояние цепочки, проверяемое валидаторами, обеспечивая таким образом гарантию включения и для связанных конфиденциальных транзакций, предоставляемую FOCIL.

Следовательно, FOCIL и Frames — это не две независимые функции. Первая изменяет, какие подходящие транзакции должны быть включены в блок, а вторая изменяет структуру проверки самих транзакций. Возможность безопасного взаимодействия обоих — одна из ключевых задач тестирования Hegotá.

S-уровневое предложение определяет основную линию Hegotá, но несколько A-уровневых предложений также повлияют на безопасность аккаунтов Ethereum, миграцию против квантовых угроз, доказательство выполнения и оценку ресурсов в будущем.

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

В плане безопасности аккаунта EIP-7906, EIP-8298 и EIP-8151 рассматриваются как расширения Frames.

EIP-7906 вводит механизм транзакционных утверждений (Transaction Assertions), позволяющий проверять, произошли ли указанные результаты до окончательной отправки транзакции. Этот механизм направлен на снижение потерь, вызванных злонамеренными смарт-контрактами, извлекающими активы из кошельков, и некоторыми видами MEV. Однако диапазон чтения данного предложения все еще находится в стадии исследования и уточнения, поэтому текущий дизайн нельзя считать окончательно зафиксированным стандартом.

EIP-8298 позволяет аккаунтам повторно использовать существующий код контракта, превращая делегированные аккаунты в смарт-контрактные аккаунты с полным кодом. EIP-8151 ограничивает использование традиционной аутентификации ecRecover для адресов с существующим кодом аккаунта.

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

EIP-8025 (опциональное доказательство выполнения) связан с будущей дорожной картой zkEVM. Он планирует включить изменения, необходимые для опционального доказательства выполнения, в единый стандарт выполнения, чтобы снизить проблемы долгосрочного поддержания различных форков проектами zkVM.

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

EIP-3298 планирует полностью устранить механизм возврата газа, чтобы уменьшить специальные случаи в измерении, реализации и тестировании; EIP-5920 (PAY Opcode) позволяет контрактам переводить ETH без выполнения кода получателя, четко разделяя «передачу стоимости» и «вызов контракта».

В то же время некоторые интересные предложения остаются на уровне B.

Например, EIP-8198 (Quick Slots) стремится сократить время слота, но команда протокола требует, чтобы сначала были завершены спецификация, полный прототип и оценка влияния на системы нижнего уровня, а также доказано, что это не будет мешать будущему дизайну децентрализованного консенсуса. Причина в том, что время слота влияет не только на скорость создания блоков, но и на распространение сети, принятие консенсуса, а также на предположения приложений о времени.

Кроме того, EIP-8368 и EIP-8372 классифицированы как «TBD» (ожидается). Оба предложения касаются лимитов газа и оценки ресурсов состояния; команда протокола решила подождать данные основной сети после запуска Glamsterdam в декабре 2026 года, чтобы определить, требуется ли повторная калибровка.

Количество включенных EIP, которые получил Hegotá, не является единственным критерием успеха этой версии.

Более важно, сможет ли он доставить FOCIL, Frames и их основные сопутствующие компоненты, не жертвуя безопасностью и качеством тестирования, при этом оставив достаточные ресурсы для разработки публичного ключа I*, децентрализованного консенсуса, минимально жизнеспособной квантовой устойчивости J*, а также доказательств выполнения K*, L* и полного квантово-устойчивого консенсуса.

Согласно текущему плану, Glamsterdam запустит этот сжатый цикл обновлений в декабре 2026 года, а L* в базовом маршруте достигнет своей конечной точки в декабре 2029 года. Каждое промежуточное обновление должно не только выполнять свои собственные функции, но и обеспечивать возможность продолжения следующего этапа.

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

Ссылка на статью:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446