За останній рік екосистема zkEVM боролася головним чином із затримками. Прогрес був вражаючим: генерація доказів для блоків Ethereum скоротилася з 16 хвилин до 16 секунд, витрати знизилися у 45 разів, а zkVM-и, що беруть участь, наразі виробляють докази для 99% блоків мейннету за менше ніж 10 секунд на цільовому обладнанні.
18 грудня Ethereum Foundation оголосила проривний результат: генерація доказів у реальному часі дійсно працює. Однак ця мить тріумфу виявилася поворотним пунктом. Вузькі місця у продуктивності були усунені, але це породило нові, глибші питання. Швидкість без коректності — не технічна перевага, а системна загроза. Водночас, математика, що стоїть за багатьма zkEVM, побудованими на STARKах, місяцями мовчки руйнується — саме це робить перехід акцентів із продуктивності на безпеку не лише рекомендаційним, а й неминучим.
Математична різниця і проблема з припущеннями
Багато zkEVM, побудованих на STARKах, раніше базувалися на непідтверджених математичних припущеннях для досягнення заявленого рівня безпеки. За останні місяці, особливо під час науково-дослідних робіт, такі припущення, як «proximity gap», що використовуються у тестах низького ступеня SNARK і STARK, побудованих на хешах, були математично спростовані. Це має важливі наслідки: ефективна бітова безпека параметрів, що ґрунтувалися на цих припущеннях, значно знизилася.
Ethereum Foundation чітко визначила свою позицію: єдиним прийнятним рішенням для додатків L1 є «задокументована безпека», а не «умовна безпека, яка базується на тому, що припущення X є істинним». Ця математична різниця між специфікацією і фактичним доказом є кардинальною для систем, що обробляють сотні мільярдів доларів.
Визначена мета — 128-бітова безпека — стандарт, відповідний основним криптографічним рекомендаціям і науковій літературі, що займається довговічністю криптографічних систем. Реалістично, 128 бітів виходять за межі практичного зламу, згідно з реальними обчислювальними рекордами.
Триетапна дорожня карта: від впровадження до формальної верифікації
Ethereum Foundation представила прозору дорожню карту із трьома жорсткими зупинками:
Фаза перша — кінець лютого 2026:
Кожна команда zkEVM об’єднує свою систему доведень і схеми у «soundcalc» — інструмент, підтримуваний EF, що обчислює орієнтовну безпеку на основі сучасних меж криптоаналізу та параметрів схеми. Це стає спільною мірою безпеки, замінюючи ситуацію, коли кожна команда подавала власні цифри бітової безпеки. Soundcalc стає канонічним калькулятором, оновлюваним у міру відкриття нових атак.
Фаза друга — «Glamsterdam» до кінця травня 2026:
Вимагає щонайменше 100-бітної підтвердженої безпеки через soundcalc, доказів розміром не більше 600 кілобайтів і публічного пояснення архітектури рекурсії кожної команди із кресленням її коректності. Ця фаза є перехідною, відходячи від первинного варіанту 128-бітної для раннього впровадження.
Фаза третя — «H-star» до кінця 2026:
Повний поріг: 128-бітова підтверджена безпека, докази не більше 300 кілобайтів і формальний аргумент безпеки для топології рекурсії. На цьому етапі йдеться вже не про інженерію, а про формальні методи і тверді криптографічні докази.
Технічний арсенал: від WHIR до топології рекурсії
Ethereum Foundation вказує на конкретні інструменти, що дозволяють досягти цілі 128-бітної безпеки із збереженням компактності доказів менше 300 кілобайтів.
WHIR — новий тест близькості Reed-Solomon — одночасно виконує функцію схеми зобов’язання до багатовимірних многочленів. Забезпечує прозорість, стійкість до квантових обчислень і генерує докази менше і швидше у верифікації, ніж старі схеми типу FRI при однаковому рівні безпеки. Бенчмарки при 128-бітовій безпеці показують докази приблизно у 1,95 рази менші і верифікацію у кілька разів швидшу за базові конструкції.
„JaggedPCS" — набір технік, що дозволяють уникати надмірного заповнення під час кодування слідів у вигляді многочленів — генератори доказів економлять зайву роботу, зберігаючи стислі зобов’язання.
„Grinding" — брутфорсне пошук випадковості протоколу — дозволяє знаходити дешевші або менші докази при збереженні меж коректності.
„Добре організована топологія рекурсії" — багатошарові схеми, де багато менших доказів агрегуються у один кінцевий доказ із обґрунтованою коректністю. Незалежні проєкти, такі як Whirlaway, використовують WHIR для побудови багатовимірних STARKів із підвищеною продуктивністю.
Практичні наслідки і відкриті питання
Якщо докази будуть послідовно готові за 10 секунд і матимуть розмір менше 300 кілобайтів, Ethereum отримає здатність збільшити ліміт газу без примусу валідаторів до повного повторного виконання кожної транзакції. Валідатори натомість зможуть перевіряти мініатюрні докази, що дозволить збільшити пропускну здатність блоків при збереженні реалістичного стейкінгу в домашніх умовах — звідси бюджет «home proving» — 10 кіловат енергії і обладнання менше ніж за 100 000 доларів.
Ця комбінація високих запасів безпеки і компактних доказів перетворює «L1 zkEVM» у надійний рівень розрахунків. Якщо вони будуть швидкими і підтверджуватимуться на рівні 128 біт, L2 і zk-rollup-и зможуть використовувати цю саму інфраструктуру через пре-компіляції — межа між «rollupом» і «виконанням L1» стає більш питанням конфігурації, ніж жорстким архітектурним обмеженням.
Водночас залишаються важливі невизначеності. Генерація доказів у реальному часі сьогодні — це бенчмарк off-chain, а не реальність on-chain. Числа щодо затримок і витрат походять із вибіркових конфігурацій обладнання EthProofs. Прірва між цим і тисячами незалежних валідаторів, що фактично запускають генератори доказів у домашніх умовах, залишається реальною.
Історія безпеки — це фаза змін. Soundcalc існує саме тому, що параметри STARK і SNARK, побудованих на хешах, постійно еволюціонують у міру спростування припущень. Останні результати знову визначили межу між режимами «рішуче безпечного», «за замовчуванням безпечного» і «рішуче небезпечного», що означає, що сьогоднішні налаштування на 100 біт можуть бути повторно переглянуті разом із новими атаками.
Неясно, чи всі основні команди zkEVM дійсно до травня 2026 досягнуть 100-бітної підтвердженої безпеки і 128-бітної до грудня 2026, залишаючись у межах розмірних лімітів, чи деякі приймуть нижчі запаси, покладатимуться на більш жорсткі припущення або подовжать верифікацію off-chain.
Найраніша перешкода — не математика і не потужності GPU, а формалізація і аудит повних рекурсивних архітектур. EF визнає, що різні zkEVM поєднують багато схем із значним «з’єднувальним кодом», і документування коректності цих нестандартних стеків є ключовим. Це відкриває широкий простір для роботи для таких проєктів, як Verified-zkEVM і рамки формальної верифікації, що наразі перебувають на ранніх етапах і нерівномірно розвинуті в різних екосистемах.
Висновки: кінець однієї гонки — початок іншої
Рік тому питання звучало так: чи можуть zkEVM генерувати докази достатньо швидко? Відповідь відома. Нове питання: чи зможуть вони генерувати їх достатньо коректно, на рівні безпеки, що не руйнується завтра припущеннями, з доказами достатньо малими, щоб поширюватися через P2P-мережу Ethereum, і з формально верифікованими рекурсивними архітектурами, щоб захистити сотні мільярдів вартості?
Гонка за продуктивністю завершилася. Гонка за математичною коректністю і безпекою щойно починається серйозно.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Фонд Ethereum встановлює 128-бітний стандарт безпеки: від гонки за швидкістю до гонки за правильністю
Від часу до коректності: зміна парадигми
За останній рік екосистема zkEVM боролася головним чином із затримками. Прогрес був вражаючим: генерація доказів для блоків Ethereum скоротилася з 16 хвилин до 16 секунд, витрати знизилися у 45 разів, а zkVM-и, що беруть участь, наразі виробляють докази для 99% блоків мейннету за менше ніж 10 секунд на цільовому обладнанні.
18 грудня Ethereum Foundation оголосила проривний результат: генерація доказів у реальному часі дійсно працює. Однак ця мить тріумфу виявилася поворотним пунктом. Вузькі місця у продуктивності були усунені, але це породило нові, глибші питання. Швидкість без коректності — не технічна перевага, а системна загроза. Водночас, математика, що стоїть за багатьма zkEVM, побудованими на STARKах, місяцями мовчки руйнується — саме це робить перехід акцентів із продуктивності на безпеку не лише рекомендаційним, а й неминучим.
Математична різниця і проблема з припущеннями
Багато zkEVM, побудованих на STARKах, раніше базувалися на непідтверджених математичних припущеннях для досягнення заявленого рівня безпеки. За останні місяці, особливо під час науково-дослідних робіт, такі припущення, як «proximity gap», що використовуються у тестах низького ступеня SNARK і STARK, побудованих на хешах, були математично спростовані. Це має важливі наслідки: ефективна бітова безпека параметрів, що ґрунтувалися на цих припущеннях, значно знизилася.
Ethereum Foundation чітко визначила свою позицію: єдиним прийнятним рішенням для додатків L1 є «задокументована безпека», а не «умовна безпека, яка базується на тому, що припущення X є істинним». Ця математична різниця між специфікацією і фактичним доказом є кардинальною для систем, що обробляють сотні мільярдів доларів.
Визначена мета — 128-бітова безпека — стандарт, відповідний основним криптографічним рекомендаціям і науковій літературі, що займається довговічністю криптографічних систем. Реалістично, 128 бітів виходять за межі практичного зламу, згідно з реальними обчислювальними рекордами.
Триетапна дорожня карта: від впровадження до формальної верифікації
Ethereum Foundation представила прозору дорожню карту із трьома жорсткими зупинками:
Фаза перша — кінець лютого 2026:
Кожна команда zkEVM об’єднує свою систему доведень і схеми у «soundcalc» — інструмент, підтримуваний EF, що обчислює орієнтовну безпеку на основі сучасних меж криптоаналізу та параметрів схеми. Це стає спільною мірою безпеки, замінюючи ситуацію, коли кожна команда подавала власні цифри бітової безпеки. Soundcalc стає канонічним калькулятором, оновлюваним у міру відкриття нових атак.
Фаза друга — «Glamsterdam» до кінця травня 2026:
Вимагає щонайменше 100-бітної підтвердженої безпеки через soundcalc, доказів розміром не більше 600 кілобайтів і публічного пояснення архітектури рекурсії кожної команди із кресленням її коректності. Ця фаза є перехідною, відходячи від первинного варіанту 128-бітної для раннього впровадження.
Фаза третя — «H-star» до кінця 2026:
Повний поріг: 128-бітова підтверджена безпека, докази не більше 300 кілобайтів і формальний аргумент безпеки для топології рекурсії. На цьому етапі йдеться вже не про інженерію, а про формальні методи і тверді криптографічні докази.
Технічний арсенал: від WHIR до топології рекурсії
Ethereum Foundation вказує на конкретні інструменти, що дозволяють досягти цілі 128-бітної безпеки із збереженням компактності доказів менше 300 кілобайтів.
WHIR — новий тест близькості Reed-Solomon — одночасно виконує функцію схеми зобов’язання до багатовимірних многочленів. Забезпечує прозорість, стійкість до квантових обчислень і генерує докази менше і швидше у верифікації, ніж старі схеми типу FRI при однаковому рівні безпеки. Бенчмарки при 128-бітовій безпеці показують докази приблизно у 1,95 рази менші і верифікацію у кілька разів швидшу за базові конструкції.
„JaggedPCS" — набір технік, що дозволяють уникати надмірного заповнення під час кодування слідів у вигляді многочленів — генератори доказів економлять зайву роботу, зберігаючи стислі зобов’язання.
„Grinding" — брутфорсне пошук випадковості протоколу — дозволяє знаходити дешевші або менші докази при збереженні меж коректності.
„Добре організована топологія рекурсії" — багатошарові схеми, де багато менших доказів агрегуються у один кінцевий доказ із обґрунтованою коректністю. Незалежні проєкти, такі як Whirlaway, використовують WHIR для побудови багатовимірних STARKів із підвищеною продуктивністю.
Практичні наслідки і відкриті питання
Якщо докази будуть послідовно готові за 10 секунд і матимуть розмір менше 300 кілобайтів, Ethereum отримає здатність збільшити ліміт газу без примусу валідаторів до повного повторного виконання кожної транзакції. Валідатори натомість зможуть перевіряти мініатюрні докази, що дозволить збільшити пропускну здатність блоків при збереженні реалістичного стейкінгу в домашніх умовах — звідси бюджет «home proving» — 10 кіловат енергії і обладнання менше ніж за 100 000 доларів.
Ця комбінація високих запасів безпеки і компактних доказів перетворює «L1 zkEVM» у надійний рівень розрахунків. Якщо вони будуть швидкими і підтверджуватимуться на рівні 128 біт, L2 і zk-rollup-и зможуть використовувати цю саму інфраструктуру через пре-компіляції — межа між «rollupом» і «виконанням L1» стає більш питанням конфігурації, ніж жорстким архітектурним обмеженням.
Водночас залишаються важливі невизначеності. Генерація доказів у реальному часі сьогодні — це бенчмарк off-chain, а не реальність on-chain. Числа щодо затримок і витрат походять із вибіркових конфігурацій обладнання EthProofs. Прірва між цим і тисячами незалежних валідаторів, що фактично запускають генератори доказів у домашніх умовах, залишається реальною.
Історія безпеки — це фаза змін. Soundcalc існує саме тому, що параметри STARK і SNARK, побудованих на хешах, постійно еволюціонують у міру спростування припущень. Останні результати знову визначили межу між режимами «рішуче безпечного», «за замовчуванням безпечного» і «рішуче небезпечного», що означає, що сьогоднішні налаштування на 100 біт можуть бути повторно переглянуті разом із новими атаками.
Неясно, чи всі основні команди zkEVM дійсно до травня 2026 досягнуть 100-бітної підтвердженої безпеки і 128-бітної до грудня 2026, залишаючись у межах розмірних лімітів, чи деякі приймуть нижчі запаси, покладатимуться на більш жорсткі припущення або подовжать верифікацію off-chain.
Найраніша перешкода — не математика і не потужності GPU, а формалізація і аудит повних рекурсивних архітектур. EF визнає, що різні zkEVM поєднують багато схем із значним «з’єднувальним кодом», і документування коректності цих нестандартних стеків є ключовим. Це відкриває широкий простір для роботи для таких проєктів, як Verified-zkEVM і рамки формальної верифікації, що наразі перебувають на ранніх етапах і нерівномірно розвинуті в різних екосистемах.
Висновки: кінець однієї гонки — початок іншої
Рік тому питання звучало так: чи можуть zkEVM генерувати докази достатньо швидко? Відповідь відома. Нове питання: чи зможуть вони генерувати їх достатньо коректно, на рівні безпеки, що не руйнується завтра припущеннями, з доказами достатньо малими, щоб поширюватися через P2P-мережу Ethereum, і з формально верифікованими рекурсивними архітектурами, щоб захистити сотні мільярдів вартості?
Гонка за продуктивністю завершилася. Гонка за математичною коректністю і безпекою щойно починається серйозно.