Екосистема zkEVM пройшла рік всебічного прискорення затримки. Час створення доказу для одного блоку Ethereum зменшився з 16 хвилин до лише 16 секунд; витрати зменшилися в 45 разів; а zkVM, що беруть участь, тепер можуть створювати докази для 99% блоків на основному мережі менш ніж за 10 секунд при роботі на цільовому апаратному забезпеченні.
18 грудня Фонд Ethereum (EF) офіційно оголосив про перемогу: створення доказу в реальному часі стало можливим. Основні вузлові проблеми продуктивності були вирішені. Однак, складніша стадія справді тільки починається, оскільки швидкість, якщо вона не супроводжується математичною стійкістю, стане ризиком, а не перевагою. Ще більш тривожно, математична основа багатьох zkEVM, що базуються на STARK, непомітно виявила проблеми протягом останніх кількох місяців.
Мета “real-time proving” та переломний момент у безпеці
У липні EF встановив офіційну мету для “реального доказу”, яка не лише зосереджена на затримці, але й включає апаратне забезпечення, енергію, відкритість і безпеку. Конкретно, система повинна доводити щонайменше 99% блоків основної мережі протягом 10 секунд, на апаратному забезпеченні вартістю близько 100.000 USD, споживаючи не більше 10 kW електроенергії, використовуючи повністю відкритий код, досягаючи рівня безпеки 128-біт та розміру доказу не більше 300 кілобайт.
Пост від 18/12 підтверджує, що екосистема досягла цієї мети ефективності, спираючись на дані з сайту benchmark EthProofs.
Концепція «реального часу» тут визначається відносно 12-секундного слота Ethereum та приблизно 1,5 секунди, що витрачається на передачу блоку. Іншими словами, доказ має бути готовим достатньо швидко, щоб валідатор міг його перевірити, не перериваючи (liveness) мережі.
Однак, EF швидко змістила акцент з пропускної здатності на стійкість (soundness), і цей перенаправлення є жорстким. Багато zkEVM на базі STARK досягли рекламованого рівня безпеки, спираючись на ще не доведені математичні гіпотези.
У останні місяці деякі з цих гіпотез, особливо припущення «proximity gap» у низьких ступенях (low-degree tests) SNARK та STARK на основі хеш-функцій, були математично спростовані. Це значно знижує реальний рівень безпеки наборів параметрів, які раніше покладалися на них.
EF підкреслює, що з L1 єдина прийнятна мета може бути “доказова безпека”, а не “безпека, якщо гіпотеза X вірна”.
Вибрано стандартний рівень 128-біт, що відповідає традиційним організаціям стандартів криптографії та академічним документам про системи тривалого існування, а також рекордам обчислень у реальному світі, які показують, що 128-біт виходить за межі можливостей реальних атак.
Пріоритет стабільності над швидкістю відображає суттєву різницю. Якщо зловмисник може підробити докази zkEVM, він не лише висмокче контракт, а й може створити будь-який токен, переписати стан L1 і змусити всю систему “брехати”. Тому EF вважає високий рівень безпеки непереговорним для будь-якого zkEVM, що використовується на L1.
Дорожня карта трьох етапів
EF надає чіткий план з трьох обов'язкових етапів.
По-перше, до кінця лютого 2026 року всі команди zkEVM повинні інтегрувати свої системи доказів та схем в «soundcalc», інструмент, що підтримується EF для розрахунку рівня безпеки на основі поточних обмежень криптоаналізу та параметрів кожної схеми.
Метою є встановлення «загальної міри». Замість того, щоб кожна команда самостійно оголошувала рівень bit-security на основі власних припущень, soundcalc стане стандартним інструментом, який можна оновлювати, коли з'являються нові методи атак.
По-перше, етап “Glamsterdam” наприкінці травня 2026 року вимагає досягнення щонайменше 100-бітної безпеки, що може бути підтверджена через soundcalc, розмір доказу не перевищує 600 кілобайт, а також публічне, стисле пояснення рекурсивної архітектури та основних аргументів її стійкості.
Це неявно коригує початкову ціль 128-біт для ранньої фази впровадження, вважаючи 100-біт проміжним рівнем.
Вівторок, “H-star” в кінці 2026 року є повним стандартом: 128-бітна безпека, що може бути доведена через soundcalc, максимальний розмір доказу 300 кілобайт, і офіційна аргументація безпеки для всієї рекурсивної структури. На цьому етапі виклик вже не є чисто технічним, а сильно схиляється до формальних методів і криптографічних доказів.
Технічні важелі
EF вказує на ряд інструментів, спрямованих на реалізацію цілі 128-біт з доказом менше 300 кілобайт. Виділяється WHIR, новий тест близькості Reed–Solomon, який також виконує роль багатолінійної схеми зобов'язань (multilinear polynomial commitment).
WHIR забезпечує прозору безпеку, пост-квантову, генеруючи менші докази та швидшу перевірку в порівнянні з традиційними схемами FRI на тому ж рівні безпеки. Бенчмарк на рівні 128 біт показує, що розмір доказу зменшується приблизно в 1,95 рази, в той час як швидкість перевірки значно перевищує структуру бази.
EF також згадує про JaggedPCS, набір технік, що допомагає уникнути надмірного (padding) при кодуванні trace в многочлен, що дозволяє prover зменшити витрати обчислень, зберігаючи при цьому коротку комітмент.
Крім того, є “grinding”, тобто пошук brute-force у випадковому просторі протоколу для досягнення дешевшого або меншого доказу, який все ще залишається в межах безпеки, разом із ретельно спроектованими рекурсивними архітектурами, де багато маленьких доказів об'єднуються в одне остаточне доказ з міцним обґрунтуванням.
Все більш складні методи багаторазових і рекурсивних обчислень використовуються для зменшення доказів після підвищення рівня безпеки до 128-біт.
Незалежні дослідження, такі як Whirlaway, використовують WHIR для створення більш ефективного багатолінійного STARK, в той час як інші експериментальні структури багаторазових зобов'язань розробляються на основі схем доступності даних.
Математика розвивається дуже швидко, але в той же час віддаляється від тих припущень, які ще кілька місяців тому вважалися безпечними.
Що змінилося та які питання залишилися відкритими
Якщо доказ завжди готовий протягом 10 секунд і має розмір менше 300 кілобайт, Ethereum може збільшити газовий ліміт, не змушуючи валідаторів повторно виконувати всю транзакцію. Натомість їм потрібно лише підтвердити невеликий доказ, що дозволяє розширити обсяг блоку, зберігаючи можливість стейкінгу вдома.
Це причина, чому EF у попередніх статтях тісно пов'язував затримку та енергоспоживання з бюджетом “home proving” на рівні 10 кВт та апаратним забезпеченням до 100 000 USD.
Комбінація великої безпекової межі та малих доказів робить “L1 zkEVM” надійним платіжним шаром. Якщо ці докази є швидкими та досягають 128-бітної безпеки, яка може бути доведена, L2 і zk-rollup можуть повторно використовувати той же механізм через precompile, що робить межу між “rollup” та “виконанням L1” більш гнучкою, конфігурованою, а не жорстко розділеною.
Наразі реальний доказ в режимі реального часу існує лише у вигляді бенчмарків поза ланцюгом. Дані про затримки та витрати походять з обраних конфігурацій апаратного забезпечення та навантаження на EthProofs. Відстань між цим і тим, що тисячі незалежних валідаторів фактично запускають провайдер вдома, все ще значна.
Історія безпеки ще не вирішена. Причина створення soundcalc полягає в тому, що параметри безпеки STARK і SNARK базуються на функціях хешування, які постійно змінюються, коли гіпотези спростовуються. Недавні результати переосмислили межі між “безумовно безпечним”, “гіпотетично безпечним” і “безумовно небезпечним”, що означає, що конфігурації “100-біт” сьогодні можуть потребувати коригування в майбутньому.
Ще не ясно, чи всі великі команди zkEVM зможуть досягти 100-біт у травні 2026 року та 128-біт до кінця 2026 року, дотримуючись при цьому обмеження на розмір доказів, чи деякі приймуть нижчий рівень безпеки, спираючись на більш тяжкі припущення, або відтягнуть верифікацію оффчейн.
Найбільший виклик може не полягати в математиці чи GPU, а в формалізації та аудиті всієї рекурсивної архітектури. EF визнає, що zkEVM часто поєднують багато схем з значною кількістю “коду клей” і документація, а також підтвердження надійності цих налаштованих стеків є життєво важливими.
Це відкриває довгий шлях для проектів, таких як Verified-zkEVM та фреймворків перевірки форм, які все ще перебувають на ранніх стадіях і не є рівномірними між екосистемами.
Рік тому велике питання полягало в тому, чи може zkEVM довести свою швидкість. Це питання отримало відповідь.
Тепер питання в тому, чи можуть вони довести свою достатню стійкість на рівні безпеки, що не залежить від гіпотез, які можуть впасти завтра, з доказами, достатньо малими, щоб поширюватися по P2P мережі Ethereum, і з перевіреною рекурсивною архітектурою, достатньо міцною, щоб закріпити сотні мільярдів доларів вартості.
Змагання з продуктивності закінчилося.
Гонка безпеки тільки розпочалася.
Вương Тієн
