Битва 2029: Найтерміновіший біг на довгу дистанцію в історії Ethereum проти квантових технологій

Це не оновлення проти квантових загроз, але воно визначає успіх або невдачу в цій боротьбі: зрозумійте Hegotá.

Автор: KarenZ, Foresight News

Квантові комп'ютери ще не постукали у двері блокчейну, але Фонд Ethereum вже позначив дату в календарі: грудень 2029 року.

Це термін, встановлений командою протоколу Фонду Ethereum для завершення проекту: підготуватися до можливих загроз з боку квантових комп'ютерів, щоб до моменту, коли ризик стане реальним, завершити перетворення основної мережі Ethereum на квантово-стійку.

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

Фонд Ethereum встановив термін 2029 року для «Q-day»

«Q-day» зазвичай використовується для позначення уявної точки часу: моменту, коли з'являються квантові комп'ютери з реальними можливостями атаки, і існуюча система публічних ключів стикається з суттєвою загрозою.

Коли це станеться, ніхто не може точно передбачити. Фонд Ethereum також чітко визнає, що більшість надійних прогнозів вважає, що Q-day настане пізніше 2030 року, і навіть може затриматися на тривалий час, або ж може і не настати зовсім.

Команда протоколу Фонду Ethereum використовує консервативну інженерну гіпотезу: основна мережа Ethereum повинна бути підготовлена до можливого настання Q-day, яке може статися найраніше у 2030 році.

Для цього команда протоколу поставила мету — до грудня 2029 року забезпечити повну квантову стійкість трьох частин основної мережі Ethereum: виконання, консенсусу та даних.

Ця мета не є незмінною. Команда протоколу планує в січні 2027 року переглянути розвиток квантових обчислень, враховуючи думки зовнішніх експертів. До цього моменту термін 2029 року буде вважатися важливою метою, яку не можна легко зрушити.

Необхідність підготовки до квантової стійкості за кілька років до настання загрози пояснюється тим, що Ethereum не використовує лише одну криптографічну технологію, і не можна просто змінити алгоритм підпису, щоб завершити міграцію. Як користувачі підтверджують авторизацію транзакцій, як валідатори беруть участь у консенсусі, як дані перевіряються — все це стосується різних криптографічних структур. Будь-які зміни повинні пройти через проектування, реалізацію клієнта, перевірку безпеки, тестування в розробницькій мережі та координацію з основною мережею, тому не можна починати обробку, коли загроза вже з'явилася.

Hegotá не є «оновленням проти квантових загроз», але це перший тест у всьому плані

Згідно з поточним базовим маршрутом, опублікованим командою протоколу Фонду Ethereum, оновлення мережі Glamsterdam планується на грудень 2026 року, а повна квантова стійкість запланована на п'яте жорстке розгалуження L*, яке має відбутися в грудні 2029 року. Від Glamsterdam до L* всього три роки, якщо потрібно послідовно завершити Hegotá, I*, J*, K* та L*, середній час між оновленнями становитиме приблизно 7,2 місяця.

Це досить агресивний графік. Наразі Фонд Ethereum не оголосив точні дати запуску 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á включає занадто багато взаємопов'язаних функцій, це може не лише затримати його запуск, але й зайняти команди, необхідні для подальшої роботи проти квантових загроз.

Тому команда протоколу Фонду Ethereum розділила кандидатури 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) означає «Списки включення, що контролюються правилами вибору розгалуження». Його мета — покращити гарантії включення транзакцій в Ethereum.

Наразі професійні будівельники блоків керують створенням блоків. Така спеціалізація допомагає підвищити ефективність створення блоків, але якщо виробництво блоків тривалий час зосереджене в руках небагатьох будівельників, вони також можуть отримати значну можливість відбору транзакцій. Тому FOCIL додає ще один рівень обмежень включення з боку валідаторів у звичайний процес створення блоків.

Згідно з дизайном FOCIL, кожен слот вибирає групу валідаторів для формування «комітету списку включення» (IL committee). Члени комітету створюють та транслюють списки включення на основі транзакцій, які вони бачать у черзі. Наступний будівельник блоку збирає ці списки та включає відповідні транзакції під час створення блоку. Валідатори, відповідальні за підтвердження нового блоку, також зберігають отримані списки включення та перевіряють, чи відповідає блок відповідним вимогам.

Якщо блок без поважної причини пропускає транзакції зі списку, збереженого валідаторами, то підтверджувач не голосуватиме за цей блок. Такий блок, навіть якщо він все ще є дійсним на рівні виконання, не зможе отримати підтримку консенсусу, необхідну для входження в стандартний ланцюг. Це і є сенс FOCIL: він не дозволяє членам комітету безпосередньо змінювати блок, а обмежує вибір будівельників блоків через голосування валідаторів.

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

Простими словами, FOCIL не забирає роботу у будівельників блоків, а додає ще одне правило на рівні консенсусу: ви все ще можете організовувати більшість транзакцій у блоці, але не можете без поважної причини постійно ігнорувати кваліфіковані транзакції, зазначені комітетом.

Frame Transactions (EIP-8141) вирішують питання на рівні облікових записів. Він планує зробити перевірку транзакцій, виконання транзакцій та оплату Gas більш програмованими на рівні протоколу, закладаючи основу для абстракції облікових записів. Віталік є одним з співавторів 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 планує повністю видалити механізм повернення Gas, зменшуючи особливі випадки в обліку, реалізації та тестуванні; EIP-5920 (PAY Opcode) дозволяє контрактам передавати ETH без виконання коду отримувача, чітко розділяючи «передачу вартості» та «виклик контракту».

У той же час деякі пропозиції, які викликають інтерес, все ще залишаються на B-рівні.

Наприклад, EIP-8198 (Швидкі слоти) прагне скоротити час слота, але команда протоколу вимагає, щоб спочатку були завершені специфікації, що охоплюють зміни основного протоколу, повні прототипи, оцінка впливу на наступні етапи, і доведено, що це не заважає подальшому розділенню консенсусу. Причина в тому, що час слота впливає не лише на швидкість створення блоків, але й на поширення в мережі, оцінку консенсусу та припущення додатків щодо часу.

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

Кількість EIP, які в кінцевому підсумку будуть включені в Hegotá, не є єдиним критерієм для оцінки успіху цього оновлення.

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

Згідно з поточними цілями, Glamsterdam розпочне цей компактний цикл оновлень у грудні 2026 року, а L* у базовому маршруті досягне фінішу в грудні 2029 року. Кожне оновлення не може зосереджуватися лише на виконанні своїх функцій, але також повинно забезпечити можливість подальшого просування на наступному етапі.

Чи стане квантова загроза реальністю до 2030 року, ніхто не може дати точну відповідь. Але вибір Ethereum вже дуже чіткий: спочатку встановити терміни для ризиків, а потім дати кожній пропозиції можливість довести свою готовність до основної мережі через специфікації, прототипи та тестування.

Джерела статті: 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