Попереднє читання: «Vitalik про можливе майбутнє ETH (частина 1): The Merge», «Vitalik про можливе майбутнє ETH (частина 2): The Surge», «Vitalik про можливе майбутнє ETH (частина 3): The Scourge»

Особлива подяка Джастіну Дрейку, Хся-вей Ванпу, Гійому Балету, Іцинасіо, Рошу Рудольфу, Леву Соуханой, Райану Шону Адамсу та Умі Рой за відгуки та рецензії.

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

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

The Verge 2023 план шляхів

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

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

The Verge: Ключова мета

· Безстатевий клієнт: обсяг сховища, необхідного для повної перевірки клієнтського комп'ютера та мітки Нода, не повинен перевищувати кількох гігабайтів.

· (Тривалий термін) Повна перевірка ланцюга (Консенсус і виконання) на розумному годиннику. Завантаження деяких даних, перевірка SNARK, завершення.

У цій главі

· Безстатевий клієнт: Verkle або STARKs

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

· Консенсус 的доказ дійсності

Безстатева перевірка: Веркле або STARKs

Що ми повинні вирішити?

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

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

Як це працює?

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

Фактично для реалізації безстатевої перевірки необхідно змінити структуру дерева стану Ethereum. Це через те, що поточне дерево Меркла-Патріції є надзвичайно неприязне до будь-якої схеми доказу шифрування, особливо в найгіршому випадку. Це стосується як "початкових" гілок 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 газ / 2400 (рахунок холодного читання) * (5 * 488 + 24000) = 330000000 байт

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

Якщо ми просто замінимо шістнадцяткове дерево на бінарне дерево і здійснимо додаткову обробку коду Меркля, то у найгіршому випадку це призведе до приблизно 30000000/240032(32-14+8) = 10400000 байтів (14 віднімання від резервних бітів для 2^14 гілок, а 8 - це довжина доведення, що потрапляє в блок коду). Слід зауважити, що це потребує зміни вартості газу, щоб стягувати плату за доступ до кожного окремого блоку коду; EIP-4762 саме це робить. Об'єм 10,4 МБ виглядає краще, але для багатьох Нод це все ще занадто багато даних для завантаження за один інтервал. Тому нам потрібно ввести більш потужні технології. У цьому відношенні є два провідних рішення: дерево Веркле та STARKed бінарне дерево хешування.

Дерево Verkle

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

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

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

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

STARKed бінарне дерево хешування

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

Основним викликом тут є перевірка часу. Ми можемо виконати обчислення, подібні до вищезазначених, за винятком того, що ми обчислюємо хеш-значення замість кількості байтів. Блок розміром 10,4 МБ означає 330 000 хеш-значень. Якщо додати ймовірність того, що атакувальник "видобуває" Адреса дерева з довшим спільним префіксом, то в найгіршому випадку хеш-значення досягне приблизно 660 000 хеш-значень. Тому, якщо ми зможемо довести, що кількість хеш-значень на секунду становить 200 000, то проблем немає.

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

1. Швидкий аналіз безпеки Poseidon великою кількістю та достатньою обізнаністю, щоб розгорнути його на рівні L1

2. Використовуйте більш "консервативну" хеш-функцію, таку як SHA256 або BLAKE

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

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

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

· Пул пам'яті: коли угоду транслюють, Нода в P2P мережі повинна перевірити, чи є угода дійсною, перед тим як транслювати її знову. Сьогодні ця перевірка включає перевірку підпису, а також перевірку достатності балансу та правильності префіксу. У майбутньому (наприклад, з використанням абстрагування рахунку, такого як EIP-7701), це може включати виконання деякого коду EVM, який здійснює доступ до деяких станів. Якщо Нода є безстанційною, то угода повинна містити доказ про об'єкт стану.

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

· легкий клієнт: якщо ми хочемо, щоб користувачі могли отримати доступ до ланцюжка через гаманець (наприклад, Metamask, Rainbow, Rabby тощо), для цього їм потрібно запустити легкий клієнт (наприклад, Helios). Основний модуль Helios надає користувачам підтверджений кореневий стан. Щоб отримати повністю безпечний досвід без довіри, користувачам потрібно надавати підтвердження для кожного свого запиту RPC (наприклад, для запиту до мережі ETH (користувач повинен підтвердити доступ до всіх станів, до яких він звертається під час виклику)).

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

Які контакти існують з наявними дослідженнями:

· Дерева Веркле

· Джон Кузмал про оригінальну статтю про дерево Веркле

· Starkware (Старк)

· Документація Poseidon2

· Ajtai (альтернативна швидка функція хешування на основі твердості решітки)

· Verkle.info

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

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

1. Додатковий аналіз наслідків EIP-4762 (зміни вартості газу без стану)

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

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

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

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

Крім цих "цифр заголовків", є й інші важливі фактори, які потрібно врахувати:

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

· Використання хеш-значення для оновлення кореня стану є швидшим, ніж використання дерева Веркле. Це означає, що метод на основі хеш-значення може скоротити час синхронізації повного вузла.

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

· Verkle дерево ускладнює SNARK-підтвердження. Якщо ми хочемо постійно зменшувати розмір підтвердження до кількох тисяч байтів, то Verkle-підтвердження стане дещо складним. Це тому, що перевірка Verkle-підтвердження включає велику кількість операцій з 256 бітами, що вимагає, щоб система підтвердження мала або значні витрати, або власну спеціалізовану внутрішню структуру з 256-бітовою частиною підтвердження Verkle. Це не є проблемою для безстанційного самого по собі, але це ускладнює ситуацію.

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

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

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

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

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

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

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

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

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

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

Що ми повинні вирішити?

Ціль блокування ETH є довгостроковою дуже чіткою - має бути можливість перевірити блок ETH шляхом (i) завантаження Блоку або навіть лише невеликої частини доступності даних Блоку; (ii) перевірки блоку за допомогою невеликого доказу. Це буде операцією з дуже низьким споживанням ресурсів, яку можна виконати в мобільному клієнті, браузері Гаманець, а навіть у іншому ланцюжку (без частини доступності даних).

Для досягнення цієї мети необхідно здійснювати докази SNARK або STARK для (i) шару консенсусу (тобто підтвердження власності акцій) та (ii) шару виконання (тобто EVM). Перше само по собі є викликом і повинно вирішуватися в процесі постійного вдосконалення шару консенсусу (наприклад, щодо однослотової фінальності). Друге потребує підтвердження виконання EVM.

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

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

· Громадський ввід: попередній кореневий стан R, наступний кореневий стан R', блокхеш H

· Приватний вхід: об'єкти в стані, до яких звертаються блоки програми B та програми Q, той самий об'єкт після виконання блоку програми Q', доказ стану (наприклад, гілка Меркла) P

· Твердження 1: P є дійсним доказом, що Q містить деякі частини стану, які представляють R.

· Претензія 2: Якщо STF працює на Q, (i) процес виконання доступу до об'єктів в середині Q, (ii) блоки даних є дійсними, (iii) результат - Q'

· Теза 3: Якщо використовувати інформацію про Q та P для повторного обчислення нового кореня стану, отримаємо R'

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

Реалізація доказу дійсності для обчислень EVM вже існує і широко використовується на L2. Проте для забезпечення можливості використання доказу дійсності EVM на L1 є ще багато роботи.

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

· EFPSE ZK-EVM (вже відключено через наявність кращих альтернатив)

· Zeth, його робочі принципи полягають в тому, що EVM компілюється до RISC-0 ZK-VM

· ZK-EVM проект Формальна верифікація

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

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

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

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

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

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

· Оптимізація системи підтвердження - нові системи підтвердження, такі як Orion, Binius, GRK та багато інших, ймовірно, значно зменшать час перевірки загального обчислення.

· Зміни вартості газу в EVM - Багато речей в EVM можна оптимізувати, щоб зробити їх більш вигідними для підтверджувачів, особливо в найгіршому випадку. Якщо зловмисник може побудувати Блок, який блокує підтверджувачів протягом десяти хвилин, то для підтвердження звичайного блоку ETH Blockchain Блок буде потрібно не менше 4 секунд. Потрібні зміни EVM можуть бути приблизно класифіковані наступним чином:

• зміна вартості газу - якщо операція потребує довгого часу для підтвердження, то навіть якщо її обчислювальна швидкість відносно висока, вона повинна мати високу вартість газу. EIP-7667 - це EIP, який був запропонований для вирішення найбільш серйозної проблеми в цьому аспекті: він значно збільшує вартість газу (традиційних) хеш-функцій, оскільки опкоди та попередньо скомпільований код для цих функцій відносно дешеві. Щоб компенсувати збільшення вартості газу, ми можемо зменшити вартість газу для операційних кодів EVM, вартість підтвердження яких відносно низька, щоб зберегти середню пропускну здатність на тому ж рівні.

• Заміна структури даних - окрім заміни дерева стану більш дружнім до STARK методом, нам також потрібно замінити список транзакцій, дерево квитанцій та інші високовитратні структури доказів. Переміщення структури транзакцій та квитанцій до EIP SSZ - це крок у цьому напрямку, який зробив Етан Кіслінг.

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

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

У цих сферах ще більше роботи, щоб зробити:

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

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

· Нам потрібно більше працювати у сфері доказів

Можлива вартість:

· Безпека та час перевірки валідатора: якщо вибрати більш рішучу хеш-функцію, складнішу систему доказів або більш рішучі припущення щодо безпеки або інші концепції проектування, можна скоротити час перевірки валідатора.

· Децентралізація та час перевірки: спільнота повинна узгодити «специфікації» апаратного забезпечення, на яке спрямовано перевірку. Чи можуть перевіряти великі сутності? Ми хочемо, щоб високопродуктивний ноутбук міг підтверджувати блок у мережі ETH протягом 4 секунд? Чи є щось посередині?

· Рівень порушення сумісності назад: інші недоліки можна скоригувати зміною вартості газу, але це, ймовірно, надмірно збільшить витрати деяких додатків, змусивши розробників переписувати і перевиживати код, щоб зберегти економічну доцільність. Так само, ці два інструменти мають свою складність та недоліки.

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

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

· L2 доказ дійсності (тобто «ZK rollup»)

· Метод без стану "Двійковий доказ хешу STARK"

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

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

Консенсус 的доказ дійсності

Що ми повинні вирішити?

Якщо ми хочемо повністю перевірити блок ETH за допомогою SNARK, то виконання EVM - не єдине, що нам потрібно підтвердити. Ми також повинні підтвердити Консенсус, тобто обробку депозитів, вилучень, підписів, оновлення балансу валідатора та інші елементи стейкінгу блоку ETH.

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

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

сигнальна мережа визначається функцією переходу стану, так само, як 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 пар. За допомогою ElP-7549 і подальших змін кількість підтверджень в кожному слоті може бути зменшена до 16. Кількість пар невелика, але витрати дуже великі: час роботи (або підтвердження) кожної пари в кілька тисяч разів довше, ніж ECADD.

Одним із основних викликів обчислення BLS12-381 є відсутність зручної кривої з порядком, що дорівнює розміру поля BLS12-381, що додає значні витрати для будь-якої системи доказів. З іншого боку, дерево Verkle, запропоноване для ETH, побудоване на кривій Bandersnatch, що робить BLS12-381 саму по собі криву, яка використовується в SNARK системі для доведення Verkle гілок. Для досить швидкої швидкості доказу, майже безумовно потрібні винахідливі техніки, такі як GKR.

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

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

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

· зміна хеш-функції: зараз використовується "повний" хеш-функції SHA256, тому, внаслідок заповнення, для кожного виклику потрібно дві виклики функції стиснення нижнього рівня. Якщо використовується функція стиснення SHA256, ми принаймні зможемо отримати вдвічі більше прибутку. Якщо використовується Poseidon, ми можемо отримати прибуток у 100 разів більше, що повністю вирішить всі наші проблеми (принаймні щодо значення хеш-функції): 1,7 мільйона хеш-значень на секунду (54 МБ), навіть мільйон записів перевірки можна "зчитати" в доказівці всього за кілька секунд.

· Якщо це Орбіт, то просто зберігайте записи перевірників після перемішування: якщо ви вибрали певну кількість перевірників (наприклад, 8192 або 32768), щоб створити комітет для певного слоту, то вони будуть безпосередньо розміщені поруч у стані, що дозволяє зчитати Відкритий ключ усіх перевірників за допомогою мінімального хешу в доказі. Це також дозволить ефективно завершити всі балансові оновлення.

· Агрегація підписів: будь-яка високопродуктивна схема агрегації підписів включатиме деяке рекурсивне підтвердження, різні Нода в мережі будуть проводити проміжні підтвердження підмножини підписів. Це природно розподілить роботу з підтвердження між кількома Нода в мережі, що значно зменшить навантаження на "остаточного підтверджувача".

· Інші схеми підписів: для підпису Лампорта + Меркля нам потрібно 256 + 32 хеш-значення для перевірки підпису; помножте на 32768 підписувачів і отримаєте 9437184 хеш-значення. Після оптимізації схеми підпису можна подальшим чином покращити цей результат за допомогою невеликого сталого множника. Якщо ми використовуємо Poseidon, це можна довести в одному слоті. Але насправді використання рекурсивної агрегаційної схеми буде швидше.

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

· Простий Етер фонд Консенсус підтвердження (лише для синхронного комітету)

· Простий Helios в SP1

· Компіляція BLS12-381 упрощена

· Перевірка підпису зібрання BLS на основі Halo2

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

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

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

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

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

Посилання на оригінал тексту