Квантовая гонка Ethereum: дедлайн 2029 года и старт с Hegotá

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

Квантовые компьютеры ещё не представляют реальной угрозы для блокчейна, а Ethereum Foundation уже обвела дату в календаре: декабрь 2029 года.

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

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

EF заранее установила срок 2029 года для «Q-day»

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

Никто не может точно предсказать, когда он наступит. Ethereum Foundation признаёт, что, по большинству надёжных прогнозов, Q-day наступит после 2030 года, возможно, значительно позже, а может и не наступить вовсе.

Команда протокола Ethereum Foundation исходит из консервативного предположения, что Q-day может наступить уже в 2030 году, и поэтому первый уровень Ethereum нужно готовить заранее.

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

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

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

Hegotá — не «квантово-устойчивое обновление», но первое испытание всего плана

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

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

Согласно текущей дорожной карте, основные задачи этапов следующие:

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

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

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

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

Два уровня S Hegotá: FOCIL и Frames

В опубликованной командой протокола классификации 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-транзакции (EIP-8141) решают проблему уровня счетов. Они планируют сделать проверку транзакций, исполнение транзакций и оплату газа более программируемыми на уровне протокола, создавая основу для встроенной абстракции учётных записей. Виталик является одним из соавторов EIP-8141.

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

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

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

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

Помимо уровня S, на какие ещё EIP стоит обратить внимание?

Предложения уровня 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» (ожидают решения). Оба предложения касаются лимита газа и ценообразования ресурсов состояния; команда протокола решила дождаться данных mainnet после запуска Glamsterdam в декабре 2026 года, чтобы определить, нужна ли перекалибровка.

Сколько EIP в итоге будет включено в Hegotá — не единственный критерий успеха этого обновления.

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

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

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

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

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