Фонд Ethereum переорієнтовується на безпеку замість швидкості – встановлює суворе правило 128-біт для 2026 року
Екосистема zkEVM протягом року зосереджувалася на зниженні затримки. Час доведення блоку Ethereum скоротився з 16 хвилин до 16 секунд, витрати знизилися у 45 разів, і зараз zkVM, що беруть участь, доводять 99% блоків mainnet менш ніж за 10 секунд на цільовому обладнанні.
Ethereum Foundation (EF) оголосила про перемогу 18 грудня: доведення в реальному часі працює. Вузькі місця продуктивності усунені. Тепер починається справжня робота, адже швидкість без надійності — це ризик, а не перевага, і математика багатьох STARK-базованих zkEVM вже кілька місяців тихо ламається.
У липні EF встановила формальну ціль для “доведення в реальному часі”, яка охоплює затримку, обладнання, енергоспоживання, відкритість і безпеку: доводити щонайменше 99% блоків mainnet за 10 секунд на обладнанні вартістю близько $100,000 і споживанням до 10 кіловат, з повністю відкритим кодом, на рівні безпеки 128 біт і розміром доказу не більше 300 кілобайт.
Публікація від 18 грудня стверджує, що екосистема досягла цільових показників продуктивності, виміряних на сайті EthProofs.
Тут “реальний час” визначається відносно 12-секундного слоту і приблизно 1,5 секунд на поширення блоку. Стандарт по суті такий: “докази готові досить швидко, щоб валідатори могли їх перевірити, не порушуючи живучість мережі.”
Тепер EF переходить від пропускної здатності до надійності, і цей перехід є жорстким. Багато STARK-базованих zkEVM покладалися на недоведені математичні припущення для досягнення заявленого рівня безпеки.
За останні місяці деякі з цих припущень, особливо “proximity gap” у хеш-базованих SNARK та STARK тестах на низький ступінь, були математично спростовані, що знизило ефективну бітову безпеку параметрів, які на них спиралися.
EF заявляє, що єдиний прийнятний фінал для використання на L1 — це “доведена безпека”, а не “безпека за умови, що припущення X вірне.”
Вони встановили ціль у 128-бітову безпеку, узгоджуючи її з основними криптостандартами та академічною літературою щодо довготривалих систем, а також з реальними обчисленнями, які показують, що 128 біт — це недосяжно для атакуючих.
Акцент на надійності, а не на швидкості, відображає якісну різницю.
Якщо хтось може підробити доказ zkEVM, він може створити довільні токени або переписати стан L1 і змусити систему брехати, а не просто вивести кошти з одного контракту.
Це виправдовує те, що EF називає “недискутованим” запасом безпеки для будь-якого L1 zkEVM.
Дорожня карта з трьома етапами
У публікації викладено чітку дорожню карту з трьома жорсткими зупинками. По-перше, до кінця лютого 2026 року кожна команда zkEVM підключає свою систему доказів і схеми до “soundcalc” — інструменту, який підтримує EF і який обчислює оцінки безпеки на основі поточних криптоаналітичних меж і параметрів схеми.
Суть тут — “спільна лінійка”. Замість того, щоб кожна команда оголошувала власну бітову безпеку на основі унікальних припущень, soundcalc стає канонічним калькулятором і може оновлюватися у разі появи нових атак.
Друге, “Glamsterdam” до кінця травня 2026 року вимагає щонайменше 100-бітової доведеної безпеки через soundcalc, фінальних доказів розміром не більше 600 кілобайт і компактного публічного пояснення архітектури рекурсії кожної команди з коротким обґрунтуванням її надійності.
Це тихо відступає від початкової вимоги у 128 біт для раннього впровадження і розглядає 100 біт як проміжну ціль.
Третє, “H-star” до кінця 2026 року — це повна планка: 128-бітова доведена безпека через soundcalc, докази розміром не більше 300 кілобайт, плюс формальний аргумент безпеки для топології рекурсії. Тут справа переходить від інженерії до формальних методів і криптографічних доказів.
Технічні важелі
EF вказує на кілька конкретних інструментів, покликаних зробити ціль у 128 біт і менше 300 кілобайт досяжною. Вони виділяють WHIR — новий тест на близькість Reed-Solomon, який також є схемою зобов’язання багатолінійного многочлена.
WHIR забезпечує прозору, постквантову безпеку і створює докази, які менші за розміром і швидше перевіряються, ніж у старих схем FRI на тому ж рівні безпеки.
Тести на 128-бітовій безпеці показують, що докази приблизно в 1,95 рази менші, а перевірка у кілька разів швидша, ніж у базових конструкцій.
Вони згадують “JaggedPCS” — набір технік для уникнення надмірного заповнення при кодуванні трас як многочленів, що дозволяє доводникам уникати зайвої роботи, водночас створюючи лаконічні зобов’язання.
Вони згадують “grinding” — грубу силу пошуку по випадковості протоколу для знаходження дешевших або менших доказів, залишаючись у межах надійності, і “добре структуровану топологію рекурсії”, тобто багаторівневі схеми, в яких багато менших доказів агрегуються в один фінальний доказ із ретельно обґрунтованою надійністю.
Використовуються екзотичні многочленні методи і рекурсивні трюки для зменшення розміру доказів після підвищення безпеки до 128 біт.
Незалежні розробки, такі як Whirlaway, використовують WHIR для побудови багатолінійних STARK з підвищеною ефективністю, а також створюються більш експериментальні конструкції зобов’язань на многочленах на основі схем доступності даних.
Математика розвивається швидко, але також відходить від припущень, які ще півроку тому здавалися безпечними.
Що змінюється і відкриті питання
Якщо докази стабільно готові менш ніж за 10 секунд і залишаються менше 300 кілобайт, Ethereum може збільшити ліміт gas без необхідності для валідаторів повторно виконувати кожну транзакцію.
Валідатори замість цього перевірятимуть невеликий доказ, дозволяючи збільшити пропускну здатність блоку, зберігаючи реалістичність домашнього стейкінгу. Саме тому попередня публікація EF про реальний час прямо пов’язувала затримку і потужність із бюджетами “домашнього доведення”, такими як 10 кіловат і обладнання до $100,000.
Поєднання великих запасів безпеки і малих доказів робить “L1 zkEVM” надійним шаром розрахунків. Якщо ці докази і швидкі, і доведено 128-бітові, L2 і zk-rollups можуть використовувати ті ж механізми через precompiles, і різниця між “rollup” і “L1 execution” стає радше питанням конфігурації, ніж жорсткою межею.
Доведення в реальному часі наразі є позаланцюговим еталоном, а не реальністю на ланцюгу. Показники затримки і вартості отримані з налаштованих апаратних рішень і робочих навантажень EthProofs.
Все ще існує розрив між цим і тисячами незалежних валідаторів, які реально запускають ці доводники вдома. Історія безпеки перебуває у стані змін. Вся причина існування soundcalc у тому, що параметри безпеки STARK і хеш-базованих SNARK постійно змінюються у міру спростування припущень.
Останні результати перекреслили межу між “безумовно безпечними”, “гіпотетично безпечними” і “безумовно небезпечними” режимами параметрів, тобто сьогоднішні налаштування “100 біт” можуть бути знову переглянуті у разі появи нових атак.
Незрозуміло, чи всі основні команди zkEVM дійсно досягнуть 100-бітової доведеної безпеки до травня 2026 року і 128-бітової до грудня 2026 року, залишаючись у межах обмежень розміру доказу, чи деякі тихо погодяться на менші запаси, покладатимуться на важчі припущення або довше залишатимуть перевірку поза ланцюгом.
Найскладніше може бути не математика чи GPU, а формалізація і аудит повних архітектур рекурсії.
EF визнає, що різні zkEVM часто складаються з багатьох схем із суттєвим “клейовим кодом” між ними, і що документування та доведення надійності для цих індивідуальних стеків є необхідним.
Це відкриває довгий хвіст роботи для проєктів на кшталт Verified-zkEVM і формальних фреймворків верифікації, які ще перебувають на ранній стадії і нерівномірно розвинені в різних екосистемах.
Рік тому питанням було, чи можуть zkEVM доводити досить швидко. На це питання вже є відповідь.
Нове питання — чи можуть вони доводити досить надійно, на рівні безпеки, який не залежить від припущень, що можуть зламатися завтра, з доказами, достатньо малими для поширення мережею P2P Ethereum, і з архітектурами рекурсії, формально верифікованими для забезпечення сотень мільярдів доларів.
Гонка за продуктивністю завершена. Гонка за безпекою тільки почалася.
Публікація Ethereum Foundation refocuses to security over speed – sets strict 128-bit rule for 2026 вперше з’явилася на CryptoSlate.
Відмова від відповідальності: зміст цієї статті відображає виключно думку автора і не представляє платформу в будь-якій якості. Ця стаття не повинна бути орієнтиром під час прийняття інвестиційних рішень.
Вас також може зацікавити
Досліджуйте динамічний шлях ASTER та ONDO на крипторинку

Нереалізовані збитки короткострокових власників Bitcoin виявляються слабким місцем ринку: Glassnode
