Фонд Ethereum встановлює термін 2029 року для оновлень, стійких до квантових атак

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

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

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

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

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

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

Команда протоколу Фонду Ефіру використовує консервативні інженерні припущення: шар 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*: За поточними базовими показниками додайте повідомлення про постквантові підтвердження — post-quantum attestations — для досягнення повної постквантової стійкості консенсусу та досягніть повної постквантової стійкості на рівні виконання, консенсусу та даних до грудня 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) стосується проблем на рівні облікових записів. Він має на меті зробити перевірку транзакцій, виконання транзакцій та оплату Gas більш програмованними на рівні протоколу, щоб забезпечити основу для нативного абстрагування облікових записів. Vitalik є одним із співавторів 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» (підтверджується). Обидва пропозиції стосуються обмежень Gas та оцінки ресурсів стану; команда протоколу вирішила чекати на дані з головної мережі після запуску 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