Як L1 zkEVM переписує специфікацію Ethereum: еволюція від Rollup до верифікуємих обчислень

Від 2025 року спільнота розробників Ethereum демонструє небачену інтенсивність оновлень та переосмислення своєї ролі в криптоекосистемі. На фоні дискусій щодо цінової динаміки ETH, Ethereum Foundation презентувала амбітний дорожний план (Strawmap), який описує технічну еволюцію протоколу на наступні роки. Специфікація це не просто технічні посилення — це якісна трансформація самого Ethereum: від розрахункового шару для L2 до верифікуємої основи довіри для всієї децентралізованої економіки.

Ця трансформація означає, що кожен крок виконання стану L1 можна буде стиснути та перевірити за допомогою нульових знань. Це не копіювання L2 zkEVM проектів (zkSync, Starknet, Scroll), а принципово інша мета: перетворення самого виконавчого шару Ethereum на систему, сумісну з ZK. Якщо L2 zkEVM — це побудова ZK-світу поверх Ethereum, то L1 zkEVM — це трансформація самого Ethereum на цей рівень.

Три напрями трансформації: від програмованого реєстру до верифікуємої інфраструктури

Розвиток Ethereum протягом останнього десятиліття супроводжувався поступовою еволюцією своєї концептуальної основи та технічних пріоритетів. Перший період (2015–2020) фокусувався на тому, що Ethereum — це програмований реєстр, спроможний на більше, ніж Bitcoin. Смарт-контракти, DeFi, NFT, DAO — усе це виросло з цієї базової історії про універсальність обчислень на блокчейні.

Другий період (2021–2023) переніс акцент на масштабування через Layer 2 рішення. Зі зростанням вартості газу звичайні користувачі не могли дозволити собі транзакції на L1, і Rollup-рішення почали домінувати. Ethereum поступово переосмислив себе як рівень даних та фінальності, надаючи безпечну базу для L2. The Merge та EIP-4844 служили саме цій меті.

Третій період (2024–2025 роки) знаменує глибшу рефлексію. Парадокс полягав у тому, що розквіт L2 привів до демонтажу цінності L1: користувачі мігрували на Arbitrum, Base, Optimism і рідко взаємодіяли безпосередньо з L1. Це спричинило критичне питання в спільноті: де брати цінність L1, якщо L2 забирають усіх користувачів?

Аналіз ключових технологічних напрямків Strawmap дає відповідь. Verkle Tree, Stateless Client, формальна верифікація EVM, нативна підтримка ZK — усі ці вектори вказують в один напрямок: наділити Ethereum L1 власною верифікуємістю. Це якісна зміна, яка буде кульмінацією L1 zkEVM.

Специфікація це фундамент: чому 8 робочих ліній змінюютьArchitecture Ethereum

Пев’язаність технічних змін у Strawmap найкраще зрозуміти, розглянувши 8 робочих ліній як єдину архітектурну систему, де кожна компонента підтримує інші.

Робоча лінія 1: Формальна специфікація EVM як основа

Специфікація це не абстрактна концепція — це математичне визначення кожної інструкції та правила трансформації стану. Нині поведінка EVM визначається реалізаціями клієнтів (Geth, Nethermind), не формальною специфікацією. Це означає, що поведінка може відрізнятися у граничних випадках. Для написання ZK-кіл неможливо працювати з нечіткою системою. Тому перша й найважливіша робоча лінія — формалізувати кожен аспект EVM так, щоб його можна було математично верифікувати.

Робоча лінія 2: Заміна хеш-функцій на ZK-сумісні

Ethereum активно використовує Keccak-256, який є вельми витратним для ZK-кіл. Основне завдання — поступово замінити Keccak на ZK-дружні функції (Poseidon, Blake серія) у внутрішніх компонентах, особливо в деревах стану та Merkle-доказах. Це системна зміна, оскільки хеш-функції пронизують весь протокол.

Робоча лінія 3: Verkle Tree замість Merkle Patricia Tree

Verkle Tree замінює хеш-ланцюги векторними компромітами, зменшуючи розмір свідчень у десятки разів. Для L1 zkEVM це означає: менше даних для підтвердження блоку, швидша генерація доказів, а також що Verkle Tree — ключова передумова реалізованості L1 zkEVM взагалі.

Робоча лінія 4: Безстанові клієнти (Stateless Clients)

Безстанові клієнти можуть верифікувати блоки без локального зберігання повної бази даних стану — потрібні лише дані witness. Це щільно пов’язано з Verkle Tree, оскільки практична реалізованість залежить від розміру свідчень. Для L1 zkEVM це має подвійний ефект: зменшує апаратні вимоги до вузлів та надає чіткі межі вхідних даних для доказів.

Робоча лінія 5: Стандартизація ZK-доказів

L1 zkEVM потребує зрілої системи генерації доказів, але поле ZK дуже фрагментоване. Мета цієї лінії — визначити стандартизований інтерфейс на рівні протоколу, дозволяючи різним системам конкурувати. Команда PSE (Privacy and Scaling Explorations) має великий досвід у цьому.

Робоча лінія 6: Роз’єднання виконавчого та консенсусного рівнів

Нині виконавчий рівень (EL) та консенсусний рівень (CL) взаємодіють через Engine API. У L1 zkEVM кожна зміна стану потребує генерування ZK-доказу, а це може перевищити інтервал між блоками. Потрібно роз’єднати виконання та генерацію доказів без порушення консенсусу — виконання швидке, докази генеруються асинхронно.

Робоча лінія 7: Рекурсивні та агреговані докази

Генерація доказу для одного блоку витратна, але рекурсивна агрегація кількох блоків в один доказ значно зменшить витрати верифікації. Прогрес тут безпосередньо визначить вартість роботи L1 zkEVM.

Робоча лінія 8: Інструменти розробника та EVM-сумісність

Усі нижчорівневі модернізації мають бути прозорими для розробників смарт-контрактів: десятки тисяч контрактів не повинні стати непрацездатними. Ця лінія найбільш недооцінена, але часто найбільш витратна за часом. Кожне оновлення EVM вимагало масивних тестів на зворотну сумісність. Зміни L1 zkEVM перевищують попередні, і обсяг роботи з інструментарієм зросте в рази.

Чому саме тепер: переоцінка Ethereum як верифікуємої інфраструктури

Випуск Strawmap припадає на період сумнівів щодо цінової динаміки ETH, але справжня цінність полягає в переосмисленні Ethereum як довгострокової інфраструктури.

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

Об’єктивно кажучи, L1 zkEVM не з’явиться швидко — повна реалізація очікується у 2028–2029 роках або пізніше. Однак це переосмислює цінневу пропозицію Ethereum фундаментально. Якщо L1 zkEVM буде успішним, Ethereum перестане бути лише рівнем розрахунків для L2 і стане верифікуємою основою довіри для всього Web3 світу, дозволяючи будь-якому ланцюжку стану математично відстежуватися до ланцюжка Ethereum ZK-доказів.

Це також впливає на довгострокову позицію L2 екосистеми. Коли L1 матиме власні ZK-можливості, роль L2 еволюціонує — від «рішення для безпечного масштабування» до «спеціалізованого середовища виконання». Які L2 знайдуть своє місце в цій новій архітектурі, стане найцікавішим еволюційним процесом наступних років.

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

Еволюція через специфікацію: од орієнтованості на Rollup до верифікуємих обчислень

Еволюція нарративу Ethereum — від «Rollup-центричної» моделі 2021 року до Strawmap 2026 року — відображає чітку траєкторію: масштабування не може залежати від L2 самостійно, L1 та L2 мають розвиватися спільно та синергійно.

Вісім робочих ліній L1 zkEVM є технічним перекладом цього зміщення розумління. Кожна лінія спрямована на одну мету: забезпечити експоненційний пририст продуктивності основної мережі без втрати децентралізації. Це не заперечення шляху L2, а його удосконалення та органічне доповнення.

Протягом наступних трьох років екосистема зазнає сім розгалужень протоколу, замінивши безліч компонентів своєї архітектури. Коли у 2029 році буде досягнута наступна фаза, ми, можливо, побачимо справжній «глобальний верифікуємий рівень розрахунків» — швидкий, безпечний, приватний і, як завжди, відкритий для всіх. Специфікація це не просто механізм — це обіцянка Ethereum залишатися інфраструктурою для децентралізованого майбутнього.