Візія Ethereum на 2030 рік: роботу переносять на криптографічні докази. Хто перевірятиме результат?

Бачення Віталіка Бутеріна від 27 вересня описує перехід Ethereum від системи, у якій кожен верифікатор повторює значну частину роботи, до такої, де дані можна вибірково перевіряти, а виконання — перевіряти за допомогою компактних доказів. Одна частина, PeerDAS, вже впроваджена. Більший зсув у виконанні залишається в розробці. Доказ може підтвердити, що обчислення відбувалося за визначеними правилами, але користувачам усе ще потрібні дані, спосіб подавати транзакції та протокол, який вирішує, чий результат стає остаточним.

Головне питання має дві відповіді. Доводжувач створює криптографічний доказ; верифікатор, потенційно будь-який вузол валідації, що запускає відповідне програмне забезпечення, перевіряє цей доказ на відповідність правилам і публічним вхідним даним. Дорожня карта Ethereum для zkEVM базового рівня стверджує, що верифікація має бути значно дешевшою, ніж повторне виконання кожної транзакції. Але визначення того, чи є доказ надійним, саме по собі не вирішує, чи доступні дані транзакцій або чи може оператор утримати транзакцію користувача.

Есе Бутеріна від 27 вересня, «Криптографічний світовий комп’ютер», окреслює кінцеву мету як поєднання блокчейну, криптографічної приватності та верифікації, а також децентралізованих позаланцюгових компонентів. Він протиставляє старій моделі завантаження та повторного виконання модель, у якій вузли вибірково перевіряють дані та верифікують докази. Він описує інші можливі зміни до консенсусу та побудови блоків. Це особисте технічне бачення, а не остаточна специфікація оновлення, ратифікована всіма командами клієнтів Ethereum.

Різниця між тим, що існує, і тим, що задумано, є важливою. PeerDAS з’явився разом з Fusaka у грудні 2025 року, згідно з оновленням пріоритетів протоколу Ethereum Foundation від лютого 2026 року. Фонд заявляє, що валідатори тепер вибірково перевіряють дані blob замість завантаження всіх їх. Загальномережевий перехід до верифікації стислих доказів виконання для блоків базового рівня не описується як уже впроваджений. Читач, який чує, що Ethereum «верифікуватиме докази у 2030 році», має запитати, який саме доказ, чиї обчислення він охоплює і які учасники можуть незалежно його перевірити.

PeerDAS перевіряє доступ до даних, а не кожне обчислення

Уже впровадженою частиною є PeerDAS, або однорангова вибіркова перевірка доступності даних. Rollup-и розміщують дані транзакцій у просторі blob Ethereum, щоб інші учасники могли отримати достатньо інформації для відтворення стану та притягнення оператора до відповідальності за правилами. Старий підхід, за якого кожен вузол завантажує кожен blob, зробив би більші обсяги даних дорогими для звичайних валідаторів. Вибіркова перевірка вимагає від вузлів перевіряти невеликі фрагменти на відповідність криптографічним зобов’язанням, тоді як мережа розподіляє достатньо закодованих фрагментів для відтворення.

Пояснення Ethereum говорить, що розширені дані blob поділяються на 128 стовпців. Звичайний вузол приєднується щонайменше до 8 випадково вибраних підмереж стовпців. Вісім поділити на 128 — це одна шістнадцята розширених даних. Кодування додає надлишковість, тож ця кількість відповідає приблизно одній восьмій початкового обсягу даних згідно з описом у документації. Ці числа стосуються навантаження на дані вузла за замовчуванням, а не твердження, що один вузол може особисто зберігати всю історію кожного rollup-у за одну восьму вартості.

Кодування у стилі Ріда-Соломона створює надлишкові фрагменти даних, а криптографічні зобов’язання допомагають вузлу перевірити, що вибраний фрагмент належить до оголошеного набору. Вибірка забезпечує ймовірнісну гарантію доступності серед вузлів-учасників. Вона не замінює перевірку виконання. Цілком доступний пакет транзакцій може містити недійсний перехід стану. Так само дійсний доказ про перехід стану не є достатнім, щоб дозволити користувачеві відтворити стан облікового запису, якщо потрібні для цього дані утримуються поза межами гарантій доступності.

Ethereum Foundation заявила, що Fusaka забезпечив восьмикратне збільшення теоретичної пропускної здатності blob-даних. Слово «теоретичної» має значення: фактична стійка пропускна здатність залежить від запланованого збільшення параметрів, стану мережі та використання rollup-ів. Crypto.news пояснив, як rollup-и використовують рівень даних Ethereum. Новий есей Бутеріна розглядає PeerDAS як перший видимий крок до системи, яка перевіряє більше й повторює менше; його не слід перетворювати на остаточне оновлення доказу виконання.

Доводжувач виконує важку роботу; незалежні вузли перевіряють її

У моделі виконання на основі доказів хтось усе одно має виконувати транзакції та формувати докази щодо результату. Ця сторона може використовувати дороге спеціалізоване апаратне та програмне забезпечення. Стислий доказ дозволяє верифікатору перевірити з набагато меншими витратами, що заявлена зміна стану відповідає програмі та вхідним даним, зафіксованим згідно з правилами протоколу. Математична перевірка не вимагає від верифікатора довіряти компанії-доводжувачу лише тому, що вона згенерувала доказ.

До цього твердження додаються умови. Верифікатор повинен запускати коректну систему доказів із правильним ключем перевірки, публічними вхідними даними та узгодженими правилами виконання. Дефектна схема могла б бездоганно довести неправильне твердження. Помилка в реалізації клієнта могла б прийняти доказ, який слід відхилити. Ключ оновлення, який може змінювати код верифікатора без надійних засобів контролю, міг би послабити гарантію. У живому протоколі незалежні реалізації та перевірка мають значення поряд із швидкою генерацією доказів.

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

Crypto.news повідомив про апаратну конкуренцію навколо доведення. Корисне розрізнення полягає в тому, хто може згенерувати доказ вчасно для ланцюга, а хто може дешево його перевірити. Генерація доказів могла б зосередитися серед фірм із спеціалізованим апаратним забезпеченням, не дозволяючи цим фірмам автоматично підробляти дійсний перехід стану. Це все одно могло б створити залежність від живучості: якщо занадто мало сторін можуть виробляти докази достатньо швидко, блоки або фінальність можуть сповільнитися, навіть коли система доказів залишається математично коректною. Це інший ризик, ніж прийняття недійсного доказу.

Таким чином, питання перевірки має як людську відповідь, так і математичну. Розробники задають схему, дослідники її аудитують, команди клієнтів її реалізують, оператори вузлів запускають верифікатори, а учасники вирішують, чи приймати оновлення протоколу. Бутерін може запропонувати напрям. Він не може самотужки зробити майбутній верифікатор безпечним або обов’язковим для мережі.

Три обіцянки часто вкладають у слово «доказ»

Візьмімо користувача, який надсилає платіж через rollup. Транзакція має бути включена до впорядкованого пакета. Дані пакета мають бути доступними згідно з обраною моделлю rollup-у. Нарешті, отримана зміна стану має відповідати його правилам. Впорядкування, доступність і правильність — це окремі обіцянки. Доказ правильності стосується останньої з них для визначеного обчислення. PeerDAS стосується доступності blob-даних Ethereum. Механізм секвенсора або побудови блоків впливає на те, які транзакції включено і в якому порядку.

Crypto.news розглянув секвенсери як окрему точку контролю. Цілком дійсний доказ може засвідчити, що пакет було оброблено згідно з правилами, навіть якщо його оператор виключив транзакцію конкретного користувача. Користувач може мати шлях виходу або примусового включення залежно від дизайну цього rollup, але сам доказ не зобов’язує до справедливого доступу. Секвенсер також може змінювати порядок транзакцій, все ще створюючи дійсний перехід стану. Твердження, яке доводиться, не можна плутати з усіма властивостями, які користувачі очікують від ринку.

Сторона даних так само легко розмивається. Документація Ethereum щодо validium описує системи, які використовують докази дійсності, але не публікують дані транзакцій у головній мережі Ethereum. Їхнє виконання може бути правильним згідно з верифікатором, проте збій доступності даних може завадити користувачам відтворити стан або вивести кошти, як очікувалося. Ethereum rollup, що публікує достатньо даних в Ethereum, має іншу модель доступності. Називати обидва просто «ZK» приховує критичну різницю у здатності користувача відновити стан рахунку без оператора.

Найпростіший тест — це ментальний контрольний список із трьох колонок. Запитайте, хто включає транзакцію до пакета. Запитайте, де можна отримати дані, потрібні для відтворення балансів. Запитайте, який контракт або вузол перевіряє доказ правильності стану. Якщо проєкт відповідає лише на третє запитання, він не відповів на перші два. Ось чому есей Бутеріна говорить про побудову блоків і розподіл даних мережі поряд із криптографією, а не про заміну всієї системи одним магічним доказом.

Базовий шар не може запозичити всі властивості з наявних rollup

ZK rollup уже подають докази дійсності до Ethereum за власними контрактами та правилами. Документація Ethereum щодо ZK rollup описує оператора, який створює доказ для пакета, та контракт-верифікатор, який приймає новий корінь стану лише після перевірки. Це корисний прецедент для доведення обчислень. Це не означає, що базовий шар Ethereum уже перевів усе підтвердження виконання на такі докази.

Обсяг відрізняється. Rollup доводить власний перехід стану у власній віртуальній машині та контракті, тоді як верифікатор базового шару Ethereum мав би перевіряти виконання блоків протоколу в спосіб, прийнятний для команд клієнтів. Невідповідність між кастомною логікою rollup і правилами виконання головної мережі Ethereum не є деталлю, яку швидший доводжувач може просто відкинути. Системи доказів також повинні залишатися надійними під час оновлень протоколу, нових типів транзакцій і зловмисних вхідних даних.

Застосунок може передати свою арифметику копроцесору й надати результат із доказом, але базовий ланцюг усе одно вирішує, чи приймати публічні вхідні дані, зберігати зобов’язання та фіксувати результуючий стан. Застосунок може мати змогу обрати власний дизайн доводжувача; правило базового шару вимагає широкої координації між клієнтами та валідаторами. Фраза Бутеріна «криптографічний світовий комп’ютер» корисна як архітектурний напрям, а не як обіцянка, що єдина служба доведення запускатиме весь Ethereum.

Є очевидна суперечність, яку варто розв’язати. Якщо вузли перестають повторно виконувати, як хтось знайде помилку в обчисленні, яке доводиться? Одна відповідь полягає в тому, що розробники можуть запускати незалежне повне виконання й порівнювати його з результатами доказів під час розробки та після розгортання. Інша — кілька реалізацій доказів і формальні перевірки схем. Точний дизайн Ethereum ще не остаточно визначено. Протокол, який зменшує обов’язкове повторне виконання, не забороняє людям виконувати додаткові перевірки; він змінює те, що кожен звичайний валідувальний вузол повинен робити для консенсусу.

Фундація у оновленні пріоритетів протоколу за вересень розглядає zkEVM для L1 і формальну верифікацію як основні напрями роботи. Це свідчення активної інженерної роботи, а не визначеної дати запуску. Стандарт безпеки високий, оскільки помилка в системі доказів базового шару вплинула б на фундамент, від якого залежать інші застосунки.

Докази можуть покращити верифікацію, тоді як проблема стану зростає

Бутерін називає доступ до дуже великого спільного стану особливо складною невирішеною проблемою. Crypto.news розглянув його окрему пропозицію щодо масштабування mempool на основі доказів, яка націлена на інше вузьке місце, ніж фінальне виконання стану. Доказ може засвідчити обчислення, але доводжувач повинен отримати інформацію, від якої залежить це обчислення: баланси, сховище контрактів та інший стан рахунків. Якщо багато транзакцій одночасно торкаються того самого стану, розподіл обчислень між машинами стає складнішим. Платіж з одного рахунку та своп, що торкається пулу ліквідності, не можуть бути обидва фіналізовані з неузгоджених знімків.

В есеї припускається, що застосунки можуть розміщувати впорядкування та некомутативні зміни стану ончейн, водночас агрегуючи інші обчислення перед включенням. Це архітектурний стимул, а не обов’язкове правило для розробників сьогодні. «Некомутативний» означає, що зміна порядку змінює результат. Двоє людей, які купують з одного й того самого тонкого пулу, можуть отримати різні ціни залежно від того, який ордер оброблено першим. Жоден доказ не робить ці два ордери економічно еквівалентними.

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

На думку Бутеріна, сильніший децентралізований середній шар міг би обробляти роботу паралельно і в деяких випадках захищати метадані про те, звідки надходять запити. Така інфраструктура могла б покращити продуктивність або приватність, але їй довелося б уточнити, як розподіляються дані, хто може приєднатися і які збої мають шлях до відступу. Приватність платежу користувача не є автоматичним наслідком використання доказу валідності. Публічні вхідні дані, активність гаманця та мережеві метадані все ще можуть розкривати інформацію, якщо система не захищає й ці частини.

Незалежність можна виміряти до фінального форку

«Будь-хто може перевірити» має практичні умови. Звичайному вузлу потрібні код верифікатора, відповідні публічні вхідні дані, з’єднання з прийнятим станом ланцюга та достатня обчислювальна потужність, щоб завершити перевірку в межах протокольних часових лімітів. Якщо перевірка доказу займає секунди на скромній машині, але години на виробництво на дорогому обладнанні, система може досягти широкої верифікації за вузького виробництва. Це може бути прийнятним інженерним компромісом заради коректності, за умови що збій виробника не стане постійною перешкодою для розрахунків.

Експеримент у загальних рисах простий. Запустіть програмне забезпечення верифікатора від більш ніж однієї клієнтської команди проти того самого доказу валідного блоку й підтвердіть, що вони його приймають. Надайте змінені публічні вхідні дані й підтвердіть відхилення. Запитайте, чи можуть окремі команди пруверів створювати прийняті докази для тих самих правил, як швидко вони можуть це робити і яке обладнання кожній із них потрібне. Повторення цього в публічній тестовій мережі під великим навантаженням сказало б більше про готовність, ніж лабораторна демонстрація одного швидкого доказу. Точні критерії прийняття Ethereum залишаються предметом протокольної роботи; це спостережувані питання, а не офіційні пороги проходження.

Генерація доказів має ще один режим відмови, який перевірка валідності сама по собі не може виявити. Прувер може відмовитися створювати доказ для запропонованого блоку. Верифікатор не може прийняти доказ, який не надійшов. Дизайн може вирішити це, дозволивши кількох незалежних пруверів, резервний шлях виконання, скоригований таймінг або інші механізми. Вибір вплине на складність, вартість і час до фінальності. Поточні правила базового шару Ethereum не слід описувати як такі, що вже обрали одне з цих майбутніх рішень лише тому, що дорожня карта каже, що перевірка доказів є метою.

Незалежність також означає, що користувач може отримати інформацію, потрібну для перевірки власного права на активи. Доказ того, що корінь стану відповідав коду, є потужним, але користувач, який не може відтворити шлях від даних свого облікового запису до цього кореня, все одно покладається на посередника для практичної перевірки балансу. PeerDAS робить доступність даних блобів менш вимогливою для кожного вузла, покладаючись на розподіл і семплювання по всій мережі. Дані застосунків, що зберігаються деінде, потребують власних гарантій доступності. Верифікатор доказів ланцюга не може змусити зовнішнього оператора опублікувати приховані записи.

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

Hegota — це маркер, а не гарантія випуску у 2030 році

Бутерін посилається на Hegota, форк, запланований на 2027 рік, як можливо останнє оновлення, компоненти якого були б знайомі спостерігачеві Ethereum 2015 року. Подальша робота в його описі включала б рекурсивні STARK, формальну верифікацію, оптимізований консенсус і квантову безпеку. Crypto.news повідомляв про окрему квантову ціль на 2029 рік як про планову мету. Ані есе, ані цільова дата не доводять, що кожен запропонований компонент буде готовий і впроваджений за графіком.

Оновлення Ethereum вимагають специфікацій, реалізацій клієнтів, тестових мереж, перевірок безпеки та координації між учасниками. Strawmap — це карта досліджень і кандидатних етапів, а не ончейн-впровадження. Можна перевірити, що PeerDAS розгорнуто, подивившись на реліз Fusaka та поточні правила вузлів. Не можна перевірити майбутній загальний базовий zkEVM, дивлячись на синю колонку 2030 року в есе. Докази з’являться спочатку в публічних специфікаціях і тестах, потім у конкретному плані форку та активації у продакшені.

Аргумент на користь підходу Бутеріна сильний. Якщо верифікація стане дешевою, а дані можна буде безпечно семплювати, більше користувачів зможуть незалежно перевіряти більшу систему, не купуючи машини, пропорційні всім її обчисленням і даним. Виклик так само реальний: стек доведення має бути безпечним, конкурентно виробленим і достатньо швидким, щоб підтримувати систему живою, тоді як дані та впорядкування залишаються доступними. Мережа з дешевою верифікацією, але єдиним незамінним доказувачем або секвенсором, усе ще може бути крихкою.

Есе не вирішує, хто будуватиме кожен доказ або яка система доведення переможе. Воно визначає тест, який має значення для користувачів: чи може звичайний незалежний учасник відхилити поганий результат, відновити дані, потрібні для знання власного стану, і надіслати транзакцію попри будь-якого одного оператора? Кожна відповідь вимагає окремого механізму. Криптографічна перевірка є потужною саме тому, що її можуть повторити люди, які не виконували важку роботу.

На що звернути увагу

• Специфікації L1 zkEVM. Шукайте конкретний верифікатор, публічний формат вхідних даних і правила виконання, прийняті всіма клієнтами.
• Різноманітність пруверів. Кілька незалежних реалізацій і виміряні потреби в апаратному забезпеченні перевірять, чи має виробництво доказів єдине вузьке місце.
• Вимірювання PeerDAS. Перевіряйте пропускну здатність blob-даних і пропускну здатність вузлів у міру збільшення параметрів після запуску в грудні 2025 року.
• Рішення щодо Hegota. Остаточний обсяг форку важливіший за кандидатні функції в чернетці дорожньої карти.
• Гарантії щодо даних і впорядкування. Перевірте, чи зберігають rollup-и та майбутні дизайни базового рівня незалежну реконструкцію та включення транзакцій.

Часті запитання