Автор: Chloe, ChainCatcher
За останні два тижні засновник Ethereum Vitalik Buterin інтенсивно публікував у X кілька технічних статей, що охоплюють ключові теми: шляхи масштабування, захист від квантових атак, абстрагування облікових записів, реконструкція рівня виконання та прискорення розробки за допомогою ШІ, що було названо зовнішнім середовищем «великим оновленням Ethereum 2026». За цією серією публікацій стоїть одночасно опублікований фреймворк Strawmap від Фонду Ethereum — документ, що планує підвищити пропускну здатність L1 Ethereum до рівня 10 000 TPS до 2029 року.
Однак чим амбіційнішим є план, тим більше сумнівів виникає щодо його здатності виконати завдання, адже, якщо розглянути історію, темпи реалізації Ethereum завжди відставали від очікувань. Чи справді Ethereum тепер готове позбутися «поступовизму» й перейти до радикальної реконструкції?
Strawmap: Ефір досягне 10000 TPS у 2029 році
Дослідник Фонду Ефіріум Джастін Дрейк 25 лютого опублікував документ під назвою Strawmap, який розкриває візію та розклад майбутніх оновлень Ефіріум L1. Цей план визначає 5 основних «полярних зірок»: надшвидка продуктивність L1, пропускна здатність L1 у гігагази, масштабування L2 до терагазів, постквантова безпека L1 та нативна приватність транзакцій L1. Кінцевими кількісними цілями є 10 000 транзакцій на секунду для L1 та 10 мільйонів транзакцій на секунду для L2.
Цей план передбачає продовження через 7 розгалужень з циклом оновлення кожні 6 місяців, охоплюючи зміни на рівні консенсусу, даних та виконання. За цим підтримав засновник Ethereum Vitalik Buterin, який протягом останніх двох тижнів інтенсивно публікував технічні статті в X, розбираючи ключові аспекти дорожньої карти.
Стратегічний пріоритет: зосередження на масштабуванні Ethereum L1 та перебудові рівня виконання
Віталікааргументи показують: на відміну від стратегії минулих років, що зосереджувалася на L2 Rollup і зменшувала значення L1, поточна ідея полягає у збереженні довгострокового напрямку, одночасно значно підвищуючи масштабованість L1 у короткостроковій перспективі.
1. Короткостроковий процес: оновлення Glamsterdam
У короткостроковому плані майбутнє оновлення Glamsterdam введе «списки доступу на рівні блоків (Block-Level Access Lists, BALs)» для підтримки паралельної перевірки, подолавши ефективнісні обмеження послідовної обробки, а також просуне вбудоване розділення пропонувача та побудовника (Enshrined Proposer-Builder Separation, ePBS), оптимізуючи використання нодами слотів у 12 секунд.
2. Довгостроковий процес: ZK-EVM та розвиток Blob
Довгострокове масштабування ґрунтується на двох основних стовпах: ZK-EVM та Blob. На шляху ZK-EVM очікується, що наприкінці 2026 року невелика кількість валідаторів починатиме використання клієнтів ZK-EVM, а з 2027 року частка їх використання зростатиме, а безпека підсилюватиметься. Кінцевою метою є досягнення «обов’язкового механізму мультипідписів 3 з 5», за яким блок може бути підтверджений лише тоді, коли його перевірять принаймні три з п’яти систем підтвердження.
На шляху розвитку Blob, PeerDAS (вибіркова зразкова перевірка доступності даних) буде постійно удосконалюватися з метою підвищення потужності обробки даних до приблизно 8 МБ/с. Суть цієї технології полягає в тому, що вузли можуть проводити перевірку, завантажуючи лише невеликі фрагменти даних, що значно збільшує пропускну здатність і одночасно знижує апаратні вимоги до вузлів. З іншого боку, для задоволення майбутніх потреб масового впровадження, основна мережа Ethereum перейде на зберігання даних блоків безпосередньо в просторі Blob, замінивши минулу, дорогу та постійну модель calldata. Ця зміна спрямована на оптимізацію структури зберігання даних і перебудову шляху масштабування Ethereum на рівні даних.
3. Реконструкція рівня виконання: перехід на двійкове дерево станів замість EVM
Vitalik вказав, що поточний обмеження ефективності доведення Ethereum на 80% пов’язане з застарілою архітектурою. Згідно з EIP-7864, після переходу від поточної «шістнадцяткової Keccak MPT дерева стану» до «бінарного дерева стану», довжина гілок скоротиться в 4 рази. Ця зміна призведе до значного підвищення ефективності даних:
Пропускна здатність даних: витрати зменшено приблизно в 4 рази, що є стрімким стрибком для легких клієнтів, таких як Helios.
Швидкість доказу: при використанні BLAKE3 — прискорення приблизно в 3 рази; при використанні варіанту Poseidon — потенційне прискорення до 100 разів.
Оптимізація зберігання: дизайн слотів «сторінки» (64–256 слотів) дозволяє dapp економити понад 10 000 газу на транзакцію під час читання та запису сусідніх даних.
Більш амбітнимпропозицією є міграція ВМ (віртуальної машини), оскільки наразі ZK-доказові системи в основному написані мовою RISC-V, якщо EVM зможе працювати безпосередньо на RISC-V, виключивши витрати на переклад між двома рівнями віртуальних машин, загальна доказова здатність системи значно зросте. Поточний план реалізації передбачає три етапи:
1. Спочатку дозвольте новій ВМ прийняти існуючі попередньо скомпільовані контракти
2. Знову відкрити можливість для користувачів розгортати нові VM-контракти
3. У кінцевому підсумку переписати сам EVM як смарт-контракт, що працює на новій VM.
Це забезпечує зворотну сумісність, а загальні витрати на перехід зводяться лише до перерахунку газу.
Дорожня карта проти квантових загроз: усунення 4 основних технічних слабких місць Ethereum
Щодо ключового питання післяквантової безпеки L1, Vitalik у технічній статті чітко зазначив, що наразі Ethereum має чотири квантово-вразливі точки, які наведено нижче:
1. Рівень консенсусу: підписи BLS
Шлях заміни шару консенсусу вже починає формуватися: Vitalik запропонував рішення «Lean consensus» (спрощений консенсус), яке вводить варіант підписів на основі хешу (Hash-based), поєднаний із STARKs для агрегації та стиснення, щоб забезпечити стійкість до квантових атак. Однак Vitalik додав, що до повного запуску «спрощеного консенсусу» спочатку буде запущена версія «спрощеної працездатної ланцюжка», яка для кожного слота повинна обробляти лише 256–1024 підписів і може працювати без агрегації STARK, значно знижуючи інженерні бар’єри.
2. Доступність даних: Комути KZG та докази
Щодо доступності даних, Віталік пропонує замінити існуючі «KZG-зобов’язання» на «STARKs з квантовою стійкістю», але це супроводжується двома компромісами:
Спочатку, STARKs не мають лінійної властивості KZG, що ускладнює ефективне 2D-вибіркове зчитування даних, тому Ethereum вибрав більш консервативний шлях 1D DAS (наприклад, PeerDAS), пріоритетом якого є забезпечення стійкості мережі, а не досягнення максимальної масштабованості.
Друге, оскільки докази STARK мають великий розмір, розробникам потрібно вирішити інженерну проблему «доказ більший за дані» за допомогою складних методів, таких як рекурсивні докази. Коротко кажучи, Віталік вважає, що цей квантово-стійкий шлях залишається інженерно досяжним завдяки спрощенню технічних цілей та поетапній оптимізації, але вимагає значних інженерних зусиль.
3. Зовнішній обліковий запис (EOA): підпис ECDSA
Щодо захисту зовнішніх облікових записів (EOA), оскільки поточні підписи ECDSA дуже вразливі перед квантовими комп’ютерами, Vitalik схильний перейти до «натуральної абстракції облікових записів (native AA)», щоб перетворити всі облікові записи на контракти, дозволяючи користувачам гнучко змінювати квантово-стійкі алгоритми підпису, не відмовляючись від своїх існуючих адрес гаманців.
4. Шар застосунку: залежить від ZK-доказів KZG або Groth16
Нарешті, з точки зору шару застосунків, основним викликом є надзвичайно висока вартість газу для квантово-стійких STARK-доказів — приблизно в 20 разів вища, ніж у сучасних SNARK-доказів, що робить їх надто дорогими для приватних протоколів та L2. Vitalik пропонує ввести «рамку перевірки (Validation Frame)» за допомогою EIP-8141, щоб дозволити масове агрегування складних підписів і доказів поза ланцюгом.
За допомогою технології рекурсивного доведення, первісні дані для перевірки, що сягали сотень МБ, можуть бути стиснені до надзвичайно малого STARK-доведення, що розміщується в ланцюжку. Це не лише економить простір у блоках, а й значно знижує витрати на використання, дозволяючи навіть миттєво перевіряти транзакції на етапі Mempool, що дозволяє користувачам у вік квантових загроз продовжувати ефективно та з низькими витратами використовувати різноманітні децентралізовані застосунки.
AI як прискорювач: завершення доріжної карти Ethereum 2030 за кілька тижнів
Крім модернізації технічної архітектури, недавні твіти Віталіка підкреслюють, що ШІ прискорює розробку Ethereum. Він перепостував експеримент розробника, який за дві тижні створив прототип дорожньої карти Ethereum 2030 за допомогою vibe-coding, і прокоментував: «Шість місяців тому це навіть не входило в можливості, а зараз це вже стає трендом».
Навіть Віталік сам протестував це: він за одну годину написав бекенд-код для блогу, використовуючи модель gpt-oss:20b, запущену на ноутбуці; якщо використовувати потужніший kimi-2.5, він очікує, що зможе “зробити це за один раз”. Можна сказати, що підвищення ефективності завдяки ШІ вже не є лінійним — він змінює швидкість реалізації дорожньої карти Ethereum.
Для цього він закликає розподілити переваги, що надає ШІ, «пополам між швидкістю та безпекою»: використовувати ШІ для генерації масштабних тестових випадків, проводити формальну верифікацію ключових модулів та створювати кілька незалежних реалізацій однієї й тієї ж логіки для взаємного порівняння. Віталік вважає, що у передбачуваному майбутньому ви не зможете отримати код програми з високою безпекою лише за допомогою одного запиту — боротьба з багами та невідповідністю реалізацій все ще існує, але цей процес може бути прискорений у 5 разів.
Нарешті, він також згадав можливість того, що дорожня карта Ethereum буде завершена швидше, ніж очікувалося ззовні, і стандарти безпеки будуть вищими, ніж очікувалося ззовні. «Програмний код без помилок, який довгий час вважався ідеалістичною фантазією, зараз, можливо, стане можливим». Цей вислів, якщо б його сказали п’ять років тому в контексті розробки Ethereum, майже був би неможливим.
Повільний темп виконання та реальні виклики
Однак, оголошення таких складних технічних деталей на ринку означає, що дорожня карта Ethereum завжди буде залежати від можливості виконання цих обіцянок вчасно.
З історичних даних видно, що темпи впровадження Ефіреуму завжди були повільнішими, ніж передбачалося. The Merge був перенесений з початкового терміну «кінець року» на початку 2020 року до вересня 2022 року; реалізація EIP-4844 (Proto-Danksharding) також тривала кілька років. Такі затримки зазвичай пов’язані з факторами, такими як безпекові аудити, координація між кількома клієнтами та децентралізований управлінський процес.
Але на цей раз у Етеріуму залишилося мало часу на плавне розвиток. Поступове наближення конкурентів, реальні виклики з боку квантових загроз та революція продуктивності, спричинена ШІ, змушують Етеріум повністю позбутися «поступовизму»; стоячи на історичному переломі «або рухаєшся вперед, або відступаєш», минулий помірний, кроковий підхід, можливо, вже не зможе підтримати мрію Етеріуму стати глобальним рівнем розрахунків.
А Віталікнедавні закликитакож підкреслюють, що ця зміна — це не просто технічна реконструкція; він закликає спільноту повністю відмовитися від залежності від шляхів на рівні застосунків, зберігаючи основні принципи: опір цензурі, відкритий код, приватність, безпека (CROPS), і починати проектування застосунків з перших принципів.
Технології можуть мати дорожню карту, але оновлення мислення не має розгалуженого графіку — це, можливо, найскладніший крок у прощанні з «поступовістю».