Нова стаття від Vitalik: Можливе майбутнє протоколу Ethereum The Verge

Насправді, нам знадобляться роки, щоб отримати доказ дійсності консенсусу Ethereum.

Оригінальна назва: 《Possible futures of the Ethereum protocol, part 4: The Verge》

Автор: Vitalik Buterin

Переклад: Mensh, ChainCatcher

 

Особлива подяка Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams та Uma Roy за відгуки та рецензії.

Однією з найпотужніших функцій блокчейну є те, що будь-хто може запустити вузол на своєму комп'ютері та перевірити правильність блокчейну. Навіть якщо 9596 вузлів, що виконують консенсус ланцюга (PoW, PoS), одразу погодяться змінити правила та почнуть створювати блоки за новими правилами, кожен, хто запускає повністю верифікований вузол, відмовиться приймати цей ланцюг. Ті, хто не входить до цієї змовницької групи, автоматично об'єднаються навколо ланцюга, який продовжує дотримуватися старих правил, і продовжать його розвивати, а користувачі, які повністю перевіряють, будуть слідувати саме цьому ланцюгу.

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

Дорожня карта The Verge 2023

Спочатку "Verge" означав перенесення зберігання стану Ethereum до Verkle-дерева — структури дерева, яка дозволяє створювати компактніші докази та забезпечує безстанову верифікацію блоків Ethereum. Вузол може перевірити блок Ethereum, не зберігаючи на своєму жорсткому диску жодного стану Ethereum (баланси акаунтів, код контрактів, сховище...), ціною кількох сотень КБ доказових даних і кількох сотень мілісекунд додаткового часу на перевірку доказу. Сьогодні Verge означає ширше бачення, зосереджене на досягненні максимальної ефективності верифікації ланцюга Ethereum, що включає не лише безстанові технології, а й використання SNARK для перевірки всієї виконуваної частини Ethereum.

Окрім довгострокового фокусу на SNARK-доказах для всього ланцюга, ще одне нове питання стосується того, чи є Verkle-дерева найкращою технологією. Verkle-дерева вразливі до атак квантових комп'ютерів, тому якщо ми замінимо поточне KECCAK Merkle Patricia дерево на Verkle-дерево, нам, можливо, доведеться знову замінювати дерево в майбутньому. Самозамінна альтернатива Merkle-дереву — це пропустити використання Merkle-гілок і одразу застосувати STARK до бінарного дерева. Історично ця ідея вважалася нездійсненною через накладні витрати та технічну складність. Але нещодавно ми побачили, як Starkware на ноутбуці за допомогою ckcle STARKs довів 1,7 мільйона хешів Poseidon за секунду, і завдяки таким технологіям, як GKB, час доведення для більш "традиційних" хешів також швидко скорочується. Тому за останній рік "Verge" став більш відкритим і має кілька можливих напрямків.

The Verge: ключові цілі

• Безстанові клієнти: обсяг сховища, необхідний для повністю верифікованого клієнта та маркованого вузла, не повинен перевищувати кількох ГБ.
• (Довгостроково) Повна верифікація ланцюга (консенсус і виконання) на смарт-годиннику. Завантажити деякі дані, перевірити SNARK — готово.

У цьому розділі

• Безстанові клієнти: Verkle чи STARKs
• Докази дійсності виконання EVM
• Докази дійсності консенсусу

Безстанова верифікація: Verkle чи STARKs

Яку проблему ми вирішуємо?

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

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

Як це працює?

Безстанова верифікація — це технологія, яка дозволяє вузлам перевіряти блоки без повного володіння всім станом. Натомість кожен блок супроводжується свідченням, яке містить: (i) значення, код, баланс, сховище у певних місцях стану, до яких звертається блок; (ii) криптографічний доказ правильності цих значень.

Насправді, для впровадження безстанової верифікації потрібно змінити структуру дерева стану Ethereum. Це тому, що поточне Merkle Patricia дерево надзвичайно незручне для будь-якої криптографічної схеми доказів, особливо у найгіршому випадку. Це стосується як "оригінальних" Merkle-гілок, так і можливості "обгортання" їх у STARK. Основна складність полягає у деяких слабких місцях MPT:

1. Це шістнадцяткове дерево (кожен вузол має 16 дочірніх вузлів). Це означає, що у дереві розміру N доказ у середньому займає 32*(16-1)*log16(N) = 120*log2(N) байт, або приблизно 3840 байт для дерева з 2^32 елементів. Для бінарного дерева потрібно лише 32*(2-1)*log2(N) = 32*log2(N) байт, або близько 1024 байт.

2. Код не є частиною Merkle-структури. Це означає, що для доведення доступу до коду акаунта потрібно надати весь код, максимум 24000 байт.

 

Можемо підрахувати найгірший випадок так:

30000000 gas / 2400 (вартість читання холодного акаунта) * (5 * 488 + 24000) = 330000000 байт

Вартість гілки трохи менша (замість 8*480 використовуємо 5*480), оскільки при більшій кількості гілок їх верхні частини повторюються. Але навіть так обсяг даних, які потрібно завантажити за один слот, абсолютно нереальний. Якщо ми спробуємо обгорнути це у STARK, виникнуть дві проблеми: (i) KECCAK не дуже дружній до STARK; (ii) 330 МБ даних означає, що потрібно довести 5 мільйонів викликів функції KECCAK round, що неможливо для більшості споживчих пристроїв, навіть якщо ми оптимізуємо STARK для KECCAK.

Якщо ми просто замінимо шістнадцяткове дерево на бінарне і додатково Merkle-ізуємо код, то найгірший випадок стане приблизно 30000000/2400*32*(32-14+8) = 10400000 байт (14 — це зменшення для надлишкових бітів 2^14 гілок, а 8 — довжина доказу для входу в лист коду). Зверніть увагу, що це потребує зміни вартості gas, стягуючи плату за доступ до кожного блоку коду окремо; саме це робить EIP-4762. 10,4 МБ — це набагато краще, але для багатьох вузлів це все ще забагато для завантаження за один слот. Тому нам потрібні потужніші технології. У цьому напрямку є два провідних рішення: Verkle-дерева та STARKed бінарні хеш-дерева.

Verkle-дерева

Verkle-дерева використовують векторні зобов'язання на основі еліптичних кривих для коротших доказів. Ключ у тому, що незалежно від ширини дерева, кожна частина доказу для відносин батько-дитина має лише 32 байти. Єдине обмеження ширини дерева — якщо дерево занадто широке, ефективність обчислення доказу знижується. Запропонована для Ethereum реалізація має ширину 256.

Тому розмір однієї гілки доказу стає 32 - log256(N) = 4*log2(N) байт. Теоретично максимальний розмір доказу приблизно 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 байт (через нерівномірний розподіл стану фактичний результат трохи відрізняється, але як перше наближення це підходить).

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

Ми також використали цю особливість для іншого: зробили вартість доступу до "сусіднього" сховища дуже низькою — чи то багато блоків коду одного контракту, чи сусідні слоти сховища. EIP-4762 дає визначення сусідності, і за сусідній доступ стягується лише 200 gas. У цьому випадку максимальний розмір доказу стає 30000000 / 200*32 - 4800800 байт, що все ще в межах допустимого. Якщо для безпеки потрібно зменшити це значення, можна трохи підвищити вартість сусіднього доступу.

STARKed бінарні хеш-дерева

Суть цієї технології проста: будуємо бінарне дерево, отримуємо максимум 10,4 МБ доказу, доводимо значення у блоці, а потім замінюємо доказ на STARK-доказ. Таким чином, сам доказ містить лише доведені дані плюс 100-300 кБ фіксованих накладних витрат від STARK.

Головний виклик тут — час перевірки. Можемо провести такий самий розрахунок, як вище, але рахуємо не байти, а хеші. 10,4 МБ блоку — це 330000 хешів. Якщо врахувати можливість "добування" адрес з довгим спільним префіксом, у найгіршому випадку це близько 660000 хешів. Якщо ми можемо довести 200000 хешів за секунду, це не проблема.

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

1. Швидко провести масштабний аналіз безпеки Poseidon і достатньо з ним ознайомитися для розгортання на L1
2. Використовувати більш "консервативні" хеш-функції, такі як SHA256 або BLAKE

Для доведення консервативних хеш-функцій STARK-коло Starkware на момент написання цієї статті може доводити лише 10-30 тис. хешів за секунду на споживчому ноутбуці. Але технологія STARK швидко розвивається. Навіть сьогодні технології на основі GKR показують, що цю швидкість можна підвищити до 100-200 тис.

Використання свідчень поза перевіркою блоків

Окрім перевірки блоків, є ще три ключові випадки використання, які потребують ефективнішої безстанової верифікації:

• Мемпул: коли транзакція транслюється, вузли в P2P-мережі мають перевірити її дійсність перед повторною трансляцією. Сьогодні це включає перевірку підпису, а також перевірку балансу та правильності nonce. У майбутньому (наприклад, із нативною абстракцією акаунтів, як у EIP-7701) це може включати виконання EVM-коду з доступом до стану. Якщо вузол безстановий, транзакція має містити доказ для відповідних об'єктів стану.
• Списки включення: це запропонована функція, яка дозволяє (можливо, менш масштабним і складним) валідаторам proof-of-stake змушувати наступний блок включати транзакцію, незалежно від бажання (можливо, більш масштабних і складних) виробників блоків. Це послаблює можливість впливових осіб маніпулювати блокчейном шляхом затримки транзакцій. Але для цього валідатори мають мати спосіб перевірити дійсність транзакцій у списку включення.
• Легкі клієнти: якщо ми хочемо, щоб користувачі отримували доступ до ланцюга через гаманці (наприклад, Metamask, Rainbow, Rabby тощо), їм потрібно запускати легкий клієнт (наприклад, Helios). Ядро Helios надає користувачам перевірений корінь стану. Для повністю довіреної роботи користувачам потрібно отримувати докази для кожного RPC-виклику (наприклад, для запитів call у Ethereum потрібно довести всі стани, до яких звертається виклик).

Усі ці випадки мають спільне: вони потребують досить багато доказів, але кожен доказ малий. Тому STARK-докази для них не мають сенсу; найреалістичніше — використовувати Merkle-гілки напряму. Ще одна перевага Merkle-гілок — оновлюваність: маючи доказ для об'єкта стану з коренем у блоці B, якщо отримати підблок B2 і його свідчення, можна оновити доказ для кореня B2. Докази Verkle також нативно оновлювані.

Які є зв'язки з існуючими дослідженнями:

• Verkle trees
• Оригінальна робота John Kuszmaul про Verkle tree
• Starkware
• Poseidon2 paper
• Ajtai (альтернативна швидка хеш-функція на основі складності решіток)
• Verkle.info

Що ще можна зробити?

Основна робота, що залишилася:

1. Більше аналізу наслідків EIP-4762 (зміни безстанової вартості gas)

2. Більше роботи над завершенням і тестуванням програми переходу, яка є основною складністю будь-якої безстанової реалізації

3. Більше аналізу безпеки для Poseidon, Ajtai та інших "STARK-friendly" хеш-функцій

4. Подальша розробка надзвичайно ефективних протоколів STARK для "консервативних" (або "традиційних") хешів, наприклад, на основі Binius або GKR.

Крім того, незабаром нам потрібно буде вибрати один із трьох варіантів: (i) Verkle-дерева, (ii) STARK-friendly хеш-функції та (iii) консервативні хеш-функції. Їхні характеристики можна узагальнити у таблиці нижче:

Окрім цих "заголовкових цифр", є ще кілька важливих міркувань:

• Сьогодні код Verkle-дерев вже досить зрілий. Використання будь-якого іншого коду, окрім Verkle, відкладе розгортання, ймовірно, навіть відкладе хардфорк. Це не проблема, особливо якщо нам потрібен додатковий час для аналізу хеш-функцій чи реалізації верифікаторів, або якщо ми маємо інші важливі функції, які хочемо раніше додати до Ethereum.
• Оновлення кореня стану за допомогою хешів швидше, ніж із Verkle-деревом. Це означає, що підхід на основі хешів може скоротити час синхронізації повного вузла.
• Verkle-дерева мають цікаву властивість оновлення свідчень — свідчення Verkle-дерева оновлювані. Це корисно для mempool, списків включення та інших випадків, а також може підвищити ефективність реалізації: якщо об'єкт стану оновлено, можна оновити свідчення передостаннього рівня без читання останнього рівня.
• Verkle-дерева складніше доводити через SNARK. Якщо ми хочемо зменшити розмір доказу до кількох тисяч байт, Verkle-докази створюють певні труднощі. Це тому, що перевірка Verkle-доказу вимагає багато 256-бітних операцій, що змушує систему доказів або мати великі накладні витрати, або мати спеціальну внутрішню структуру з 256-бітними частинами Verkle-доказу. Для безстанової верифікації це не проблема, але це ускладнює інші речі.

Якщо ми хочемо отримати оновлюваність свідчень Verkle у квантово-безпечний і досить ефективний спосіб, ще один можливий шлях — Merkle-дерева на основі решіток.

Якщо у найгіршому випадку ефективність системи доказів недостатня, ми можемо використати неочікуваний інструмент — багатовимірний gas: встановити окремі ліміти gas для (i) calldata; (ii) обчислень; (iii) доступу до стану та, можливо, інших ресурсів. Багатовимірний gas додає складності, але натомість суворіше обмежує співвідношення між середнім і найгіршим випадком. З багатовимірним gas максимальна кількість гілок, які потрібно довести, може зменшитися з 12500 до, наприклад, 3000. Це дозволить навіть BLAKE3 бути (ледве) достатнім вже сьогодні.

Багатовимірний gas дозволяє обмеження ресурсів блоку наблизити до обмежень апаратного забезпечення

Ще один неочікуваний інструмент — відкласти обчислення кореня стану до слоту після блоку. Це дає нам цілих 12 секунд на обчислення кореня стану, тобто навіть у найекстремальнішому випадку 60000 хешів за секунду достатньо, і знову ж таки BLAKE3 ледве відповідає вимогам.

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

Як це взаємодіє з іншими частинами дорожньої карти?

Вирішення безстанової проблеми значно підвищує складність соло-стейкінгу. Якщо є технології, які знижують мінімальний баланс для соло-стейкінгу, як Orbit SSF або політики на рівні застосунків, як squad staking, це стане більш реалістичним.

Якщо одночасно впровадити EOF, аналіз багатовимірного gas стане простішим. Це тому, що основна складність виконання багатовимірного gas — обробка дочірніх викликів, які не передають весь gas від батьківського виклику, а EOF просто робить такі виклики незаконними, що спрощує проблему (а нативна абстракція акаунтів забезпечить протокольну альтернативу для поточного основного використання часткового gas).

Між безстановою верифікацією та історичним видаленням є ще одна важлива синергія. Сьогодні клієнти мають зберігати майже 1 ТБ історичних даних; це в кілька разів більше, ніж дані стану. Навіть якщо клієнт безстановий, якщо ми не знімемо з нього відповідальність за зберігання історичних даних, мрія про майже безсховищний клієнт залишиться недосяжною. Перший крок у цьому напрямку — EIP-4444, що означає зберігання історичних даних у torrents або Portal Network.

Докази дійсності виконання EVM

Яку проблему ми вирішуємо?

Довгострокова мета перевірки блоків Ethereum очевидна — має бути можливо перевірити блок Ethereum так: (i) завантажити блок або навіть лише невелику частину даних для перевірки доступності; (ii) перевірити невеликий доказ дійсності блоку. Це має бути надзвичайно легка операція, яку можна виконати на мобільному клієнті, у браузерному гаманці або навіть на іншому ланцюгу (без частини про доступність даних).

Щоб цього досягти, потрібно мати SNARK або STARK-докази для (i) консенсусного шару (тобто proof-of-stake) і (ii) виконуваного шару (тобто EVM). Перше саме по собі є викликом і має вирішуватися у процесі подальшого вдосконалення консенсусного шару (наприклад, для однослотової фінальності). Друге потребує доказів виконання EVM.

Що це таке і як працює?

Формально у специфікації Ethereum EVM визначено як функцію перетворення стану: маємо початковий стан S, блок B, обчислюємо кінцевий стан S' = STF(S, B). Якщо користувач використовує легкий клієнт, він не має повного S і S', навіть E; натомість має початковий корінь стану R, кінцевий корінь стану R' і хеш блоку H.

• Публічний вхід: початковий корінь стану R, кінцевий корінь стану R', хеш блоку H
• Приватний вхід: тіло блоку B, об'єкти стану, до яких звертається блок Q, ті ж об'єкти після виконання Q', докази стану (наприклад, Merkle-гілки) P
• Твердження 1: P — дійсний доказ, що Q містить певні частини стану, представленого R
• Твердження 2: Якщо виконати STF на Q, (i) процес звертається лише до об'єктів у Q, (ii) блок дійсний, (iii) результат — Q'
• Твердження 3: Якщо повторно обчислити новий корінь стану з Q' і P, отримаємо R'

Якщо це можливо, можна мати легкий клієнт, який повністю перевіряє виконання EVM у Ethereum. Це робить ресурси клієнта дуже низькими. Для повністю перевіреного клієнта Ethereum потрібно зробити те саме і для консенсусу.

Докази дійсності виконання EVM вже існують і широко використовуються на L2. Але для того, щоб докази дійсності EVM стали можливими на L1, потрібно ще багато роботи.

Які є зв'язки з існуючими дослідженнями?

• EFPSE ZK-EVM (знято з експлуатації через наявність кращих альтернатив)
• Zeth, який компілює EVM у RISC-0 ZK-VM
• Проект формальної верифікації ZK-EVM

Що ще можна зробити?

Сьогодні докази дійсності електронних систем обліку мають два недоліки: безпека та час перевірки.

Безпечний доказ дійсності має гарантувати, що SNARK дійсно перевіряє обчислення EVM і не має вразливостей. Два основних підходи до підвищення безпеки — мультиверифікатори та формальна верифікація. Мультиверифікатори — це кілька незалежно реалізованих доказів дійсності, як кілька клієнтів; якщо блок доведено достатньо великою підмножиною цих реалізацій, клієнт приймає блок. Формальна верифікація — це використання інструментів, які зазвичай застосовуються для доведення математичних теорем, таких як Lean4, для доведення, що доказ дійсності приймає лише правильне виконання специфікації EVM (наприклад, EVM K semantics або написаної на python специфікації виконуваного шару Ethereum (EELS)).

Достатньо швидкий час перевірки означає, що будь-який блок Ethereum можна перевірити менш ніж за 4 секунди. Сьогодні ми ще далеко від цієї мети, хоча вже ближче, ніж уявляли два роки тому. Щоб цього досягти, потрібно прогресувати у трьох напрямках:

• Паралелізація — сьогодні найшвидший верифікатор EVM може довести блок Ethereum у середньому за 15 секунд. Це досягається шляхом паралелізації між сотнями GPU, а потім об'єднання їхньої роботи. Теоретично ми знаємо, як зробити верифікатор EVM, який доводить обчислення за O(log(N)) часу: кожен крок виконує окремий GPU, а потім створюється "дерево агрегації":

Реалізація цього має виклики. Навіть у найгіршому випадку, коли одна велика транзакція займає весь блок, розподіл обчислень має відбуватися не по транзакціях, а по опкодах (EVM чи RISC-V тощо). Забезпечення узгодженості "пам'яті" віртуальної машини між різними частинами доказу — ключовий виклик реалізації. Але якщо ми зможемо реалізувати таке рекурсивне доведення, то навіть без інших покращень проблема затримки доказу буде вирішена.

• Оптимізація систем доказів — нові системи доказів, такі як Orion, Binius, GRK та інші, ймовірно, призведуть до ще більшого скорочення часу перевірки універсальних обчислень.
• Інші зміни вартості gas у EVM — багато чого в EVM можна оптимізувати для зручності доказу, особливо у найгіршому випадку. Якщо атакуючий може створити блок, який блокує доказувача на 10 хвилин, то доведення звичайного блоку Ethereum за 4 секунди недостатньо. Необхідні зміни EVM можна поділити на такі категорії:
• Зміни вартості gas — якщо операція довго доводиться, навіть якщо вона швидко виконується, вона має мати високу вартість gas. EIP-7667 пропонує вирішити найгірші з цих проблем: він значно підвищує вартість gas для (традиційних) хеш-функцій, оскільки їхні опкоди та прекомпіляції відносно дешеві. Щоб компенсувати це, можна знизити вартість gas для опкодів EVM, які мають низьку вартість доказу, зберігаючи середню пропускну здатність.
• Заміна структур даних — окрім заміни дерева стану на більш дружню до STARK структуру, потрібно замінити список транзакцій, дерево квитанцій та інші дорогі для доказу структури. EIP від Etan Kissling щодо переходу транзакцій і квитанцій до SSZ — це крок у цьому напрямку.

Крім того, два інструменти, згадані у попередньому розділі (багатовимірний gas і відкладений корінь стану), також можуть допомогти тут. Але варто зазначити, що на відміну від безстанової верифікації, використання цих інструментів означає, що у нас вже є достатньо технологій для виконання поточної роботи, а для повної перевірки ZK-EVM потрібно ще більше роботи — просто менше, ніж інакше.

Ще один аспект, не згаданий вище, — апаратне забезпечення для доказувачів: використання GPU, FPGA та ASIC для швидшої генерації доказів. Fabric Cryptography, Cysic та Accseal — три компанії, які досягли прогресу у цій сфері. Це дуже цінно для L2, але навряд чи стане вирішальним для L1, оскільки є сильне бажання, щоб L1 залишався максимально децентралізованим, тобто генерація доказів має бути у межах можливостей користувачів Ethereum, а не залежати від обладнання однієї компанії. L2 може робити більш агресивні компроміси.

У цих сферах ще багато роботи:

• Паралелізація доказу вимагає, щоб різні частини системи доказів могли "ділитися пам'яттю" (наприклад, таблиці пошуку). Ми знаємо, як це зробити, але потрібно реалізувати.
• Потрібно більше аналізу для визначення ідеального набору змін вартості gas, щоб мінімізувати найгірший час перевірки.
• Потрібно більше роботи над системами доказів

Можливі компроміси:

• Безпека проти часу перевірки: вибір більш агресивних хеш-функцій, складніших систем доказів, агресивніших припущень безпеки чи інших рішень може скоротити час перевірки.
• Децентралізація проти часу перевірки: спільнота має погодити "специфікацію" апаратного забезпечення для доказувачів. Чи прийнятно, щоб доказувачі були великими організаціями? Чи хочемо, щоб топові споживчі ноутбуки доводили блок Ethereum за 4 секунди? Або щось середнє?
• Ступінь порушення зворотної сумісності: інші недоліки можна компенсувати більш агресивними змінами вартості gas, але це, ймовірно, непропорційно підвищить вартість для деяких застосунків, змусивши розробників переписувати і повторно розгортати код для збереження економічної доцільності. Ці інструменти також мають власну складність і недоліки.

Як це взаємодіє з іншими частинами дорожньої карти?

Ключові технології, необхідні для реалізації доказів дійсності EVM на L1, значною мірою спільні з двома іншими сферами:

• Докази дійсності для L2 (тобто "ZK rollup")
• Безстанова "STARK бінарна хеш-доказова" методика

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

Крім того, докази дійсності EVM на L1 можуть значно підвищити ліміт gas на L1.

Докази дійсності консенсусу

Яку проблему ми вирішуємо?

Якщо ми хочемо повністю перевірити блок Ethereum за допомогою SNARK, виконання EVM — не єдина частина, яку потрібно довести. Потрібно також довести консенсус, тобто частину системи, яка обробляє депозити, зняття, підписи, оновлення балансів валідаторів та інші елементи proof-of-stake Ethereum.

Консенсус набагато простіший за EVM, але має виклик: у нас немає L2 EVM rollup, тому більшість роботи все одно потрібно виконати. Тому будь-яка реалізація доказу консенсусу Ethereum має бути "з нуля", хоча саму систему доказів можна будувати на спільній основі.

Що це таке і як працює?

Beacon chain визначено як функцію перетворення стану, як і EVM. Функція перетворення стану складається з трьох основних частин:

• ECADD (для перевірки BLS-підписів)
• Парування (для перевірки BLS-підписів)
• SHA256-хеші (для читання та оновлення стану)

У кожному блоці потрібно довести 1-16 BLS12-381 ECADD для кожного валідатора (можливо, більше одного, оскільки підпис може бути у кількох наборах). Це можна компенсувати технікою попереднього обчислення підмножин, тому можна вважати, що для кожного валідатора потрібно довести лише один BLS12-381 ECADD. Сьогодні у кожному слоті 30000 підписів валідаторів. У майбутньому, з однослотовою фінальністю, це може змінитися у два боки: якщо піти "грубо", кількість валідаторів на слот може зрости до 1 мільйона. Якщо ж використовувати Orbit SSF, кількість валідаторів залишиться 32768 або навіть зменшиться до 8192.

Як працює BLS-агрегація: перевірка загального підпису потребує лише одного ECADD для кожного учасника, а не одного ECMUL. Але 30000 ECADD — це все одно дуже багато для доказу.

Щодо парування, сьогодні у кожному слоті максимум 128 доказів, тобто потрібно перевірити 128 парувань. Завдяки EIP-7549 та подальшим змінам це можна зменшити до 16 на слот. Парувань мало, але вони дуже дорогі: кожне парування займає у тисячі разів більше часу, ніж ECADD.

Головний виклик у доведенні операцій BLS12-381 — відсутність зручної кривої з порядком, рівним розміру поля BLS12-381, що додає значних накладних витрат для будь-якої системи доказів. З іншого боку, запропоновані для Ethereum Verkle-дерева побудовані на кривій Bandersnatch, що робить BLS12-381 самою кривою SNARK для доведення гілок Verkle. Проста реалізація може довести 100 додавань G1 за секунду; для достатньо швидкого доведення майже напевно потрібні такі хитрі технології, як GKR.

Щодо SHA256-хешів, найгірший випадок сьогодні — блок переходу епохи, коли оновлюється все коротке дерево балансів валідаторів і багато балансів. Коротке дерево балансів для кожного валідатора — лише 1 байт, тому 1 МБ даних буде перехешовано. Це 32768 викликів SHA256. Якщо у тисячі валідаторів баланс перевищує або опускається нижче порогу, потрібно оновити записи валідаторів, що означає тисячу Merkle-гілок, тобто до 10000 хешів. Механізм перемішування потребує 90 біт на валідатора (тобто 11 МБ даних), але це можна обчислити у будь-який момент епохи. У випадку однослотової фінальності ці цифри можуть змінитися. Перемішування стане непотрібним, хоча Orbit може частково повернути цю потребу.

Ще один виклик — потрібно повторно отримати всі стани валідаторів, включаючи публічні ключі, щоб перевірити блок. Для 1 мільйона валідаторів лише читання публічних ключів потребує 48 мільйонів байт плюс Merkle-гілки. Це означає мільйони хешів на епоху. Якщо потрібно довести дійсність PoS, реалістичний підхід — якась форма інкрементальної верифікованої обробки: зберігати у системі доказів окрему структуру даних, оптимізовану для ефективного пошуку та доведення оновлень.

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

• Зміна хеш-функції: зараз використовується "повна" SHA256, тому через паддінг кожен виклик — це два виклики базової компресійної функції. Якщо перейти на SHA256-компресію, можна отримати щонайменше 2-кратний виграш. Якщо перейти на Poseidon, можна отримати 100-кратний виграш, повністю вирішивши проблему з хешами: при 1,7 мільйона хешів за секунду (54 МБ) навіть 1 мільйон записів валідаторів можна "прочитати" у доказі за кілька секунд.
• Якщо Orbit, то пряме зберігання перемішаних записів валідаторів: якщо обирається певна кількість валідаторів (наприклад, 8192 або 32768) для комітету слота, їх можна розмістити поруч у стані, щоб з мінімальною кількістю хешів зчитати всі публічні ключі у доказ. Це також дозволяє ефективно оновлювати всі баланси.
• Агрегація підписів: будь-яка високопродуктивна схема агрегації підписів включає рекурсивне доведення, коли різні вузли мережі доводять підмножини підписів. Це природно розподіляє роботу доказу між багатьма вузлами, значно зменшуючи навантаження на "остаточного доказувача".
• Інші схеми підписів: для Lamport+ Merkle підписів потрібно 256 + 32 хеші для перевірки підпису; помноживши на 32768 підписантів, отримаємо 9437184 хеші. Оптимізувавши схему підпису, можна ще трохи покращити цей результат. Якщо використати Poseidon, це можна довести за один слот. Але на практиці рекурсивна агрегація буде ще швидшою.

Які є зв'язки з існуючими дослідженнями?

• Succinct Ethereum consensus proofs (лише для sync committee)
• Succinct Helios у SP1
• Succinct BLS12-381 precompile
• Halo2-based BLS aggregate signature verification

Яка ще робота потрібна, які компроміси:

Насправді, нам знадобляться роки, щоб отримати доказ дійсності консенсусу Ethereum. Це співпадає за часом із впровадженням однослотової фінальності, Orbit, зміною схеми підпису та необхідним аналізом безпеки, щоб мати достатню впевненість для використання таких "агресивних" хеш-функцій, як Poseidon. Тому найрозумніше — вирішувати ці інші питання, паралельно враховуючи дружність до STARK.

Головний компроміс, ймовірно, буде у порядку дій — між поступовим реформуванням консенсусного шару Ethereum і більш радикальним підходом "змінити багато одразу". Для EVM поступовий підхід розумний, бо мінімізує порушення зворотної сумісності. Для консенсусного шару вплив на зворотну сумісність менший, і є сенс "повністю" переосмислити деталі побудови beacon chain для оптимізації під SNARK.

Як це взаємодіє з іншими частинами дорожньої карти?

Під час довгострокового редизайну PoS Ethereum дружність до STARK має бути головним пріоритетом, особливо для однослотової фінальності, Orbit, зміни схеми підпису та агрегації підписів.