Спікер: Віталік Бутерін
Упорядкувала: Yuliya, PANews
Привіт усім! Ласкаво просимо на ETHShanghai 2026. Сьогодні я хочу обговорити з вами досить складну технічну тему, яка має вирішальне значення для майбутнього Ethereum — вона може дозволити Ethereum досягти надзвичайно високої масштабованості, а також збалансувати приватність і децентралізацію, і всі три можуть бути досягнуті одночасно. Ця пропозиція з великою ймовірністю справді змінить операційну архітектуру багатьох компонентів у блокчейні. Вона може змінити багато речей, але, несподівано, насправді впровадити її в існуючий Ethereum не надто складно. Це EIP-8288: Рекурсивний підпис і агрегація.
Основна проблема: Нездоланність безпеки, приватності та масштабованості
Сьогодні я хочу зосередитися на кількох головних питаннях, які всіх дуже хвилюють: квантова безпека, приватність і масштабованість. Наразі велика проблема полягає в тому, що як квантова безпека, так і приватність наразі сильно конфліктують з масштабованістю:
Звичайна транзакція Ethereum наразі споживає близько 21 000 газу; незалежна перевірка підпису ECDSA (близько 65 байтів) займає близько 4 000 газу.
Якщо замінити на квантово-безпечні підписи (незалежно від того, який тип постквантової схеми підпису), споживання газу буде приблизно від 100 000 до 300 000 газу, залежно від обраного розміру параметрів (наприклад, чи потрібно бути сумісним зі сценаріями блокчейн-гаманців). Але як не вибирай, вартість буде в кілька разів вищою за сьогоднішні транзакції — квантово-безпечні підписи великі та дорогі.
Друга проблема: докази для протоколів приватності також великі та дорогі. Якщо хтось користувався будь-яким протоколом приватності на основі технології нульового розголошення (ZK), він знає, що на Ethereum такі операції коштують щонайменше близько 350 000 газу. Оскільки багато таких протоколів розроблені не дуже ефективно, іноді фактична вартість може сягати навіть близько 1 мільйона газу — це дуже дорого. Сьогодні звичайна транзакція може коштувати лише кілька центів, тоді як такі транзакції можуть коштувати 20 центів або навіть два долари.
Ще серйозніша проблема: якщо ви хочете і квантову безпеку, і приватність, вам потрібно використовувати докази STARK, щоб замінити попередні схеми. Однак доказ STARK споживає близько 8 мільйонів газу, і, ймовірно, більше. Тобто, якщо ми зараз дозволимо всім почати використовувати транзакції «квантово-безпечні + приватність», початкова пропускна здатність Ethereum близько 25 TPS різко впаде до приблизно 0,25 TPS, майже втративши придатність для використання.
Ще одна проблема: люди також можуть захотіти підтримувати власні криптографічні схеми. Наприклад, перехід від сьогоднішніх еліптичних кривих до майбутньої криптографії на ґратках. Проблема в тому, що кожного разу, коли ви хочете підтримувати такі нові схеми, це збільшує розмір самого протоколу та вимагає більше файлів попередніх обчислень (великих за розміром, дорогих). І якщо ви не підтримуєте ці схеми нативно в EVM або не маєте відповідних файлів попередніх обчислень, то перевірка будь-якого такого підпису в ланцюзі споживатиме дуже велику кількість газу.
Іншими словами, всі наші цілі в безпеці та приватності насправді перешкоджають масштабованості, принаймні за поточної архітектури.
Основне рішення: Перенесення обчислень агрегації вперед у мемпул
Отже, як ми вирішимо цю проблему? Це основний механізм, реалізований EIP-8288.
Основна ідея полягає в тому, щоб не розміщувати всі ці підписи та всі ці докази STARK (ці величезні, структурно складні об’єкти) безпосередньо в ланцюзі, а тримати їх поза ланцюгом і завершувати агрегацію всередині мемпулу.
Конкретно: коли користувач надсилає транзакцію, у мемпулі є група вузлів, і ці вузли вже працюють до того, як транзакція буде включена в блок. Те, що роблять ці вузли, називається «агрегацією» — вони замінюють велику кількість підписів і доказів одним доказом, який може підтвердити, що всі ці підписи та докази справді існують і є дійсними.
Отже, з погляду користувача: користувач надсилає транзакцію, і разом із транзакцією він також надсилає цей величезний об'єкт (підпис/доказ), але сам цей величезний об'єкт ніколи насправді не потрапляє в ланцюг. У ланцюг насправді потрапляє лише один STARK-доказ, який використовується для перевірки того, що всі підписи та всі докази, що містяться в усіх користувацьких транзакціях, справді існують і є дійсними.
Цей механізм побудований на основі EIP-8141 (нативна абстракція акаунтів), який буде впроваджено в наступному хардфорку. EIP-8141 узагальнює майже десятиліття досліджень спільноти Ethereum у сфері абстракції акаунтів. Він дозволяє кожній транзакції безпосередньо й точно явно оголошувати свої складові компоненти, специфікації підписів і алгоритми перевірки, надаючи транзакціям потужнішу програмованість і типізовану структуру.
У EIP-8288 ми додали новий тип фрейму, який можна розуміти як «залежність». Загалом є два види залежностей: одна відповідає підписам, а одна — доказам (STARK). На відміну від поточної моделі, де підписи безпосередньо вбудовані в тіло транзакції, за нового механізму сама транзакція містить лише абстрактне оголошення, яке вказує, від якого типу підпису та доказу залежить транзакція. Коли транзакція транслюється, хоча повні дані надсилаються разом із нею, у блок зрештою записується лише мікрофреймова структура, що несе залежності. Дані, які займає кожна залежність, становлять лише 96 байтів, а більшість — навіть лише 65 байтів. Решта величезних криптографічних сутностей поглинається й агрегується всередині мемпулу, і зрештою з'являється в реєстрі блокчейну лише у формі одного доказу.
За цієї архітектури кожен вузол у мемпулі безперервно прослуховує носій даних, який називається «конвертом». Один конверт може інкапсулювати кілька транзакцій та їхні супровідні докази.
Вузли використовують фіксований проміжок часу як вікно, безперервно збирають усі об'єкти-конверти, спостережені протягом цього періоду, виконують локальне агрегаційне обчислення, а потім транслюють його назовні. Під час трансляції всі початково дискретні незалежні докази були замінені одним глобальним агрегованим доказом, який математично строго охоплює правильність усіх базових підписів у цьому пакеті.
Це показує, що перш ніж вузли пакування блоків формально виконають оновлення стану, мережа Ethereum вже завершила переважну більшість високоінтенсивних обчислень перевірки на етапі мемпулу в неконсенсусному шарі.
Архітектурна сутність: «спеціалізований шардинг»
Один зі способів зрозуміти цей механізм — розглядати його як різновид спеціалізованого шардингу. Його ідея така: ми можемо виокремити ті надзвичайно дорогі частини обчислень, які включають надзвичайно великі обсяги даних, і дозволити всій розподіленій мережі обробляти цю частину обчислень паралельно в дуже вільний, неструктурований спосіб.
Цей підхід не є крихким; навпаки, він дуже надійний — будь-який вузол може взяти на себе будь-яку частину цієї роботи. По суті, ми робимо те, що розділяємо кожну транзакцію на дві частини:
Одна частина пояснює, «що робить ця транзакція, як вона взаємодіє зі станом і як вона взаємодіє з іншими транзакціями»;
Інша частина — це величезна, дороговартісна частина цієї транзакції, тобто чисто робота з перевірки.
Шляхом спеціалізованого шардингу та відокремлення навантаження з перевірки, обсяг даних, який консенсусний шар основного ланцюга зрештою вимагає, щоб усі вузли перевірки мережі спільно несли, строго стискається до надзвичайно малого діапазону від 100 до 300 КБ на блок. Ці накладні витрати становлять лише приблизно вдвічі більше за поточний обсяг даних блоку Ethereum, і в міру того, як загальна пропускна здатність мережі розширюється лінійно, частка цих постійних накладних витрат у загальному навантаженні мережі продовжуватиме розмиватися.
По суті, ми робимо таке: переносимо роботу геть від валідаторів і навіть геть від вузлів, які пакують блоки, штовхаючи цю частину роботи до тих позаланцюгових вузлів, що розташовані між «користувач надсилає транзакцію» та «вузол, який пакує блок, фактично включає транзакцію в блок».
Що це означає для Ethereum?
З технічного погляду це означає, що Ethereum гіпермасштабує конкретний клас обчислень. Я думаю, що це також тенденція, яку ми бачитимемо дедалі частіше в міру подальшого розвитку Ethereum.
Ethereum, народжений десять років тому, був зосереджений на повністю загальних обчисленнях, але також повністю бракував масштабованості. Тож те, що ми робимо зараз, — це розділяємо обчислення на різні типи, а потім спеціально робимо ті типи обчислень, які «природно більш придатні до масштабування», надзвичайно масштабованими — ми створюємо ці більш спеціалізовані «маленькі інструменти», щоб досягти цього.
Водночас ми також робимо ті обчислення, які мають виконуватися менш ефективним чином, меншими та простішими для обробки. EIP-8288 — це саме гіпермасштабування двох типів об'єктів: «перевірка підпису» та «перевірка доказів з нульовим розголошенням».
Ще один цікавий момент: я знаю, що багато людей давно цікавляться, коли Ethereum перейде на RISC-V — адже порівняно з поточним підходом RISC-V або якийсь інший сучасніший набір інструкцій є набагато ефективнішим, а також значно простішим. І EIP-8288, цілком імовірно, стане першим сценарієм на Ethereum, який справді запровадить RISC-V (або подібний набір інструкцій). Причина в тому, що EIP-8288 дозволяє користувачам подавати докази, а коли користувачі подають докази, їм потрібно використовувати певну мову для вираження тверджень, які вони перевіряють — RISC-V і є саме цією мовою.
Тобто логіка перевірки, виражена мовою RISC-V, потребує виконання лише як одного фізичного обчислення локально на клієнті користувача: користувач генерує відповідний доказ (у сценаріях приватності це ZK-STARK), а потім негайно надсилає його до mempool; перший релейний вузол, який його отримає, негайно рекурсивно стискає його разом із сотнями чи тисячами подібних доказів по всій мережі в єдину сутність.
Це також еквівалентно поділу всього обчислення на дві великі категорії:
Одна категорія — це «залежності», тобто частини, які мають бути гарантовано правильними, щоб транзакція була дійсною;
Інша категорія — це «бізнес-логіка», тобто те, що транзакція фактично робить.
Бізнес-логіка, отже, може стати легшою та чистішою, що також означає, що частина логіки побудови блоків, яка залежить від впорядкування транзакцій, також стане простішою. А частину «залежностей» можна обробляти паралельно в надзвичайно великому масштабі, майже без потреби в будь-яких суттєвих змінах у досвіді розробки для розробників Ethereum.
Практична цінність для розробників, користувачів і Layer 2
Для будь-кого, хто створює застосунки он-чейн, основне значення всього цього полягає в тому, що найдорожчі сьогодні операції стануть набагато дешевшими.
Витрати на виконання квантово-безпечних транзакцій будуть стиснуті до майже незначного низького рівня;
Застосунки, що зберігають приватність, побудовані на zk-SNARK/STARK, вийдуть за межі обмежень високих комісій за Gas, стануть поширеними за прийнятною ціною та від природи матимуть квантову стійкість.
Поза сценаріями приватності, ефективність застосування zk-SNARK у масштабуванні (особливо Layer 2) зазнає якісного стрибка. Наразі багато ZK-Rollup, щоб розподілити високі витрати Gas на публікацію доказів стану в мейннет, часто змушені подовжувати цикл подання, розраховуючись пакетами з частотою десять хвилин або навіть година. Це серйозно обмежує швидкість остаточного підтвердження в періоди низької активності транзакцій у мережі.
Наразі багато ZK-Rollup, щоб розподілити високі витрати Gas на публікацію доказів стану в мейннет, часто змушені подовжувати цикл подання, розраховуючись пакетами з частотою десять хвилин або навіть година. Це серйозно обмежує швидкість остаточного підтвердження в періоди низької активності транзакцій у мережі.
Еволюція кінцевої стадії: повне винесення обчислень на периферію
Нарешті, якщо є інші обчислення, які ви хочете виконати, але вони занадто дорогі для виконання всередині EVM, я сподіваюся, що ми зможемо справді почати змінювати напрямок — більше не покладати на сам протокол Ethereum прямий тягар усіх обчислень, які всі хочуть виконати, а натомість заохочувати користувачів виконувати цю частину обчислень локально на своїх клієнтах, а потім публікувати доказ, щоб цей доказ перевірявся на Ethereum.
По суті, це масштабування Ethereum шляхом переміщення обчислень із «центру» ланцюга та винесення їх на «периферію». Результат: речі, які сьогодні є найдорожчими на Ethereum (різні форми безпеки, різні форми приватності та різні форми сумісності із зовнішніми застосунками), не робляться людьми сьогодні, тому що вони занадто дорогі, а в майбутньому всі вони стануть набагато дешевшими й справді доступними для всіх.
Сподіваюся, це лише перший крок у перетворенні Ethereum з архітектури, яку він майже використовував від свого народження, у цілком іншу й навіть потужнішу нову архітектуру — нову архітектуру, яка справді поєднує дві речі: одна — це дуже проста рання ідея блокчейну від Сатоші Накамото; інша — це надзвичайно потужна й надзвичайно сучасна криптографічна технологія, яку ми безперервно накопичували відтоді.
Участь екосистеми та прогрес впровадження
Наразі інтенсивно проводяться ранні дослідження та інженерна валідація цього підходу, і технічна спільнота вже може долучатися до розбудови з кількох точок входу:
Моделі симуляції на рівні мережі: відкрито ранні інструменти симуляції для топології mempool та механізмів агрегаційного поширення;
Робота тестової мережі: тестову мережу EIP-8141, що підтримує форму фреймових транзакцій, уже запущено в тестування;
Конкурси з оптимізації алгоритмів: просуваються спеціальні конкурси алгоритмів для спільноти розробників, зосереджені на ефективній реалізації базової системи доведень;
Реалізація коду та верифікація: базовий репозиторій прототипу вже набув форми, щоб розробники екосистеми могли виконувати незалежні клієнтські реалізації та формальну верифікацію.
Велика кількість базових технічних елементів швидко заповнюється. Запрошуємо розробників глибоко долучатися до цього технічного процесу та допомогти цій революційній архітектурі якнайшвидше стати реальним стандартом у головній мережі Ethereum.
