Оригінальний заголовок: «Можливі майбутність протоколу Ethereum, частина 4: The Verge»

Автор оригіналу: Віталік Бутерін

Переклад оригіналу: Mensh, ChainCatcher

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

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

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

The Verge 2023 Шляхова карта

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

На додаток до довгострокової перевірки всього ланцюжка SNARK, ще одне нове питання пов'язане з тим, чи є дерево Веркла найкращою технікою. Дерево Веркле вразливе до Квантового комп'ютера, тому, якщо ми візьмемо дерево Веркла в нинішньому дереві KECCAK Merkle Patricia, нам доведеться замінити його знову в майбутньому. Самоальтернатива дереву Меркла полягає в тому, щоб просто пропустити STARK, який використовує гілку Меркла, і помістити його в бінарне дерево. Історично склалося так, що такий підхід вважався нездійсненним через накладні витрати та технічну складність. Однак нещодавно ми бачили, як Starkware доводить 1,7 мільйона Poseidon хеш в секунду, використовуючи ckcle STARK на одному ноутбуці, і час доказу для більш «традиційних» значень хеш також швидко зменшується через такі технології, як GKB. Так, за останній рік «Межа» стала більш відкритою, у неї є кілька можливостей.

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

• Безстатевий клієнт: повна перевірка клієнта та позначок Нода не повинна перевищувати кількох гігабайтів потрібного простору для зберігання.
• (Довгостроково) повністю перевіряти ланцюг (Консенсус? і виконання) на розумних годинниках. Завантажте деякі дані, перевірте SNARK, завершено.

У цій главі

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

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

З якою проблемою ми маємо справу?

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

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

Як він працює?

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

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

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

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

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

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

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

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

Дерево Verkle

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

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

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

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

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

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

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

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

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

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

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

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

• Пул пам'яті: коли угода транслюється, Нода в мережі P2P повинна перевірити, чи є угода дійсною, перш ніж транслювати її знову. Сьогодні ця перевірка включає перевірку підпису, а також перевірку достатнього балансу та правильного префіксу. У майбутньому (наприклад, за допомогою абстракції рахунку рахунку, такої як EIP-7701), це може знадобитися виконати деякий код EVM, який здійснюватиме доступ до стану. Якщо Нода є безстатусною, то угода повинна мати підтвердження станових об'єктів.
• Список включає: це пропозиція функції, що дозволяє (можливо, невелика і нескладна) атестація валідаторів примусово включати у наступний Блок транзакції, незалежно від бажання Блокбілдера (можливо, великого і складного). Це послабить здатність володарів влади маніпулювати Блокчейном шляхом затримки транзакцій. Однак для цього валідаторам потрібно мати засіб перевірки дійсності транзакцій, які включені в список.
• легкий клієнт: Якщо ми хочемо, щоб користувачі могли отримати доступ до ланцюжка через гаманець (наприклад, Metamask, Rainbow, Rabby тощо), для цього їм потрібно запустити легкий клієнт (наприклад, Helios). Ядро Helios надає користувачам перевірені кореневі стани. Щоб мати повноцінний довірливий досвід, користувачам потрібно надавати докази для кожного виклику RPC, який вони роблять (наприклад, для запитів до мережі ETH (користувачі повинні доводити доступ до всіх станів, до яких вони звертаються під час виклику)).

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

З якими дослідженнями він пов'язаний:

• Дерева Веркле
• Оригінальна стаття Джона Кузмаула про дерево Веркле
• У порівн.
• Папір Poseidon 2
• Ajtai (альтернативна швидка хеш-функція, заснована на твердості гратки)
• Verkle.info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

З якою проблемою ми маємо справу?

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

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

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

З формальної точки зору, в специфікації Ethereum, EVM визначено як функція переходу стану: у вас є попередній стан S, блок Б, ви обчислюєте новий стан 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 '.

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

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

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

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

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

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

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

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

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

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

• Оптимізація системи доказів - нова система доказів, така як Оріон, Бініус, ГРК та інші, ймовірно, ще раз значно скоротить час перевірки загального обчислення.
• Інші зміни вартості газу EVM - багато речей в EVM можна оптимізувати, щоб зробити його більш вигідним для перевіряючих, особливо в найгіршому випадку. Якщо атакувач може побудувати Блок, який затримає перевіряючого на 10 хвилин, тоді лише 4 секунди недостатньо для підтвердження звичайного Блоку ETH блокчейну. Зміни, необхідні для EVM, можна умовно розділити на наступні категорії:

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

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

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

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

У цих галузях ще багато роботи, яку потрібно зробити:

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

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

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

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

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

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

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

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

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

З якою проблемою ми маємо справу?

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

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

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

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

• ECADD（для перевірки підпису BLS）
• Пара (для перевірки BLS-підпису)
• SHA 256 хеш-значення (використовується для зчитування та оновлення стану)

У кожному блоку ми повинні довести, що кожен валідатор підтвердив від 1 до 16 BLS 12-381 ECADD (можливо, більше ніж один, оскільки підпис може міститися у декількох колекціях). Це можна скомпенсувати за допомогою технології попереднього обчислення підмножини, тому ми можемо сказати, що кожен валідатор повинен підтвердити лише один BLS 12-381 ECADD. Наразі в кожному слоті є 30000 підписів валідатора. У майбутньому з реалізацією однослотової остаточності це може змінюватися в двох напрямках: якщо ми йдемо шляхом "brute-force", кількість валідаторів на кожен слот може збільшитися до 1000000. В той же час, якщо використовувати Orbit SSF, кількість валідаторів залишиться на рівні 32768 або навіть зменшиться до 8192.

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

Щодо пари, наразі в кожному слоті може бути максимум 128 доказів, що означає потребу в перевірці 128 пар. Завдяки ElP-7549 і подальшим модифікаціям це число можна зменшити до 16. Кількість пар невелика, але витрати дуже великі: час виконання (або доказ) для кожної пари довший, ніж у ECADD в кілька разів.

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

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

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

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

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

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

• Простий доказ Етеру Ethereum (тільки для комітету зі співставлення)
• Helios в SP 1 вітрині
• Коротко BLS 12-381 попередньо скомпільований
• Перевірка підпису BLS на основі збору Halo 2

Які ще завдання потрібно виконати та як їх вибрати:

Фактично, нам знадобиться кілька років, щоб отримати доказ дійсності Етеруму з Ethereum. Це приблизно той самий час, що й для досягнення однослотової остаточності, орбіти, змін Алгоритму підпису та проведення безпекового аналізу, для якого необхідно достатньо впевненості, щоб використовувати такі «радикальні» хеш-функції, як Позейдон. Тому найрозумніше рішення - вирішити ці інші проблеми і при цьому враховувати дружність STARK.

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

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

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