Шлях до перевірки

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

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

Сьогодні ми дослідимо “The Verge”, розділ з недавно опублікованого Віталікомшестисерійний серіал про майбутнє Ethereum, щоб проаналізувати кроки, які Ethereum робить для досягнення перевірки, стійкості та масштабованості у майбутньому. Під заголовком «The Verge» ми обговоримо, як можна зробити блокчейн-архітектури більш перевірними, інновації, які ці зміни приносять на рівні протоколу, і як вони забезпечують користувачам більш безпечну екосистему. Почнемо!

Що означає «перевірність»?

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

“Децентралізуйте те, що можете, перевірте решту.”

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

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

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

Оскільки порядок транзакцій має важливе значення, мережі блокчейн використовують спеціалізовані методи, які називаються “алгоритми консенсусу” для того, щоб забезпечити синхронізацію вузлів та обробку послідовностей транзакцій в одному і тому самому порядку. Хоча вузли не можуть визначити глобальний порядок транзакцій, механізми консенсусу дозволяють всім вузлам погоджуватися з однією й тією самою послідовністю, що дозволяє мережі працювати як один, єдиної комп’ютер.

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

Після успішного впорядкування транзакцій за згодою, кожну транзакцію необхідно застосувати до поточного стану на рівні виконання. Якщо ви цікавитеся, “Що таке стан?”, ймовірно, ви бачили порівняння блокчейнів з базами даних — або, конкретніше, з банківською базою даних, оскільки блокчейни, подібно до банків, зберігають запис про баланси всіх.

Якщо у вас є $100 у стані, який ми називаємо “S”, і ви хочете відправити $10 комусь іншому, ваш баланс у наступному стані, “S+1”, буде $90. Цей процес застосування транзакцій для переходу від одного стану до іншого - це те, що ми називаємо функцією переходу стану (STF).

У Bitcoin STF переважно обмежується змінами балансу, що робить його досить простим. Однак, на відміну від Bitcoin, STF Ethereum набагато складніший, оскільки Ethereum є повністю програмованим блокчейном з рівнем виконання здатним запускати код.

У блокчейні є три основні компоненти, які ви повинні перевірити або можете перевірити:

1. Стан: Ви могли би бажати прочитати дані на блокчейні, але не маєте доступу до стану, оскільки не виконуєте повний вузол. Тому ви запитуєте дані через постачальника RPC (віддалений виклик процедури), такий як Alchemy або Infura. Однак ви повинні перевірити, що дані не були підроблені постачальником RPC.
2. Виконання: Як згадувалося раніше, блокчейни використовують STF. Ви повинні переконатися, що перехід стану було виконано правильно — не на основі кожної транзакції, а на основі блоку за блоком.
3. Консенсус: Сторонні сутності, такі як RPC, можуть надати вам дійсні блоки, які ще не були включені в блокчейн. Таким чином, вам потрібно перевірити, що ці блоки були прийняті шляхом консенсусу та додані до блокчейну.

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

Як перевірити стан блокчейну?

«Стан» Ethereum відноситься до набору даних, збережених в блокчейні в будь-який момент часу. Це включає баланси рахунків (контрактних рахунків та рахунків, що належать зовнішнім особам або EOAs), код розумних контрактів, зберігання контрактів та інше. Ethereum є машиною, заснованою на стані, тому що транзакції, оброблені в Ethereum Virtual Machine (EVM), змінюють попередній стан і створюють новий стан.

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

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

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

1. Детермінізм: той самий вхід завжди буде виробляти той самий вихід.
2. Фіксована довжина виводу: Незалежно від довжини вводу, довжина виводу завжди фіксована.
3. Одностороння властивість: Практично неможливо вивести початковий ввід з виходу.
4. Унікальність: Навіть невелика зміна вхідних даних призводить до зовсім іншого виходу. Таким чином, конкретні вхідні дані відображаються у практично унікальний вихід.

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

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

Оскільки стан Ethereum має розмір у терабайтах, непрактично зберігати весь стан на повсякденних пристроях, таких як телефони або персональні комп’ютери. З цієї причини Ethereum використовує структуру дерева Меркла для обчислення stateRoot, зберігаючи можливість перевірки стану настільки, наскільки це можливо.

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

1. Листкові вузли: Ці вузли містять хеші окремих частин даних і розташовані на нижньому рівні дерева. Кожен листковий вузол представляє хеш певної частини даних в дереві Меркла.
2. Гілкові вузли: Ці вузли містять комбіновані хеші своїх дочірніх вузлів. Наприклад, у бінарному дереві Меркля (де N=2) хеші двох дочірніх вузлів конкатенуються і знову хешуються, щоб отримати хеш гілкового вузла на вищому рівні.
3. Кореневий вузол: Кореневий вузол знаходиться на найвищому рівні дерева Меркля і представляє криптографічну підсумкову інформацію про ціле дерево. Цей вузол використовується для перевірки цілісності та правильності всіх даних в межах дерева.

Якщо ви цікавитеся, як побудувати таке дерево, це включає всього лише два простих кроки:

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

• Об’єднайте та хешуйте: Хеші листових вузлів групуються (наприклад, парами) та об’єднуються, а потім хешуються. Цей процес створює гілкові вузли на наступному рівні. Той самий процес повторюється для гілкових вузлів, доки не залишиться лише один хеш.

Останній хеш, отриманий у верхній частині дерева, називається коренем Меркла. Корінь Меркла представляє криптографічний підсумок усього дерева та дозволяє забезпечити безпечну перевірку цілісності даних.

Як ми використовуємо корені Меркла для перевірки стану Ethereum?

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

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

Приклад: Перевірка точки даних з допомогою доказу Меркла

Скажімо, ми отримали дані №4 від RPC і хочемо перевірити його автентичність за допомогою доказу Меркля. Для цього RPC надав би набір хеш-значень вздовж шляху, необхідного для досягнення кореня Меркля. Для даних 4 ці рідні хеші будуть містити Hash #3, Hash #12 і Hash #5678.

1. Почніть з даних 4: спочатку ми хешуємо дані №4, щоб отримати Хеш №4.
2. Об’єднайте з сусідніми: Потім об’єднайте Хеш №4 з Хеш №3 (його сусідом на рівні листя) і об’єднайте їх разом, щоб отримати Хеш №34.
3. Підніміться вгору по дереву: наступно, ми беремо Хеш №34 і поєднуємо його з Хеш №12 (його рідного брата на наступному рівні вгорі) і хешуємо їх, щоб отримати Хеш №1234.
4. Останній крок: Нарешті ми поєднаємо Hash #1234 з Hash #5678 (останній наданий sibling) і обчислимо їх хеш разом. Отриманий хеш повинен співпадати з Merkle Root (Hash #12345678), збереженим в заголовку блоку.

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

Водночас Мерклівські дерева безсумнівно ефективні у забезпеченні безпечної та ефективної перевірки даних у великих блокчейн-системах, таких як Ethereum, але чи вони дійсно достатньо ефективні? Щоб відповісти на це, ми повинні проаналізувати, як продуктивність та розмір Мерклівського дерева впливають на відносини Доведувача-Перевірника.

Два ключові фактори, що впливають на продуктивність дерева Меркла: ⌛

1. Фактор розгалуження: Кількість дочірніх вузлів на гілці.
2. Загальний розмір даних: Розмір набору даних, який представлений в дереві.

Вплив фактору розгалуження:

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

• Малий коефіцієнт розгалуження (наприклад, Бінарне Дерево Меркла):
  Якщо використовується двійкове дерево Меркля (фактор розгалуження 2), розмір доказу дуже малий, що робить процес перевірки більш ефективним для верифікатора. Завдяки лише двом гілкам на кожному вузлі, верифікатору потрібно обробити лише один хеш братового вузла на кожному рівні. Це прискорює перевірку та зменшує обчислювальне навантаження. Однак зменшений фактор розгалуження збільшує висоту дерева, що потребує більше операцій хешування під час побудови дерева, що може бути важким для валідаторів.
• Більший коефіцієнт розгалуження (наприклад, 4):
  Більший коефіцієнт розгалуження (наприклад, 4) зменшує висоту дерева, створюючи коротшу і ширшу структуру. Це дозволяє повним вузлам швидше конструювати дерево, оскільки потрібно менше хеш-операцій. Однак для перевірника це збільшує кількість хешей сестриць, які вони повинні обробляти на кожному рівні, що призводить до збільшення розміру доказу. Більше хешів на кожному кроці верифікації також означає вищі обчислювальні та пропускні витрати для верифікатора, що фактично переносить тягар з валідаторів на верифікаторів.

Вплив загального обсягу даних:

З поширенням блокчейну Ethereum з кожною новою транзакцією, контрактом або взаємодією користувача, які додаються до набору даних, також розширюється Merkle Tree. Цей ріст не тільки збільшує розмір дерева, але також впливає на розмір підтвердження та час перевірки.

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

У підсумку, хоча Дерева Меркла пропонують певний рівень ефективності, вони не є оптимальним рішенням для постійно зростаючого набору даних Ethereum. З цієї причини під час фази The Verge Ethereum планує замінити Дерева Меркла більш ефективною структурою, відомою як Дерева Веркле. Дерева Веркла мають потенціал для забезпечення менших розмірів доказів, зберігаючи при цьому той самий рівень безпеки, що робить процес перевірки більш стійким і масштабованим як для доказів, так і для верифікаторів.

Розділ 2: Революціонізація перевірки в Ethereum - The Verge

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

З моменту переходу на модель консенсусу Proof-of-Stake за допомогою The Merge валідатори Ethereum мали два основні обов’язки:

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

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

Перший крок перевірки: стан

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

Згідно з розрахунками Віталіка, середній розмір доказу становить близько 4 КБ, що звучить цілком прийнятно. Однак у найгіршому випадку розмір доказу може зрости до 330 МБ. Так, ви правильно прочитали — 330 МБ.

Надмірна неефективність Merkle Trees Ethereum в найгірших сценаріях походить з двох основних причин:

1. Використання шестизначних дерев: Ethereum наразі використовує дерева Меркля з гілковим коефіцієнтом 16. Це означає, що для перевірки одного вузла потрібно надати залишні 15 хешів у гілці. З урахуванням розміру стану Ethereum та кількості гілок це створює значні труднощі в найгіршому випадку.

1. Немеркелізація коду: Замість включення коду контракту в деревоподібну структуру, Ethereum просто хешує код і використовує отримане значення як вузол. Враховуючи, що максимальний розмір контракту становить 24 КБ, такий підхід створює значні труднощі для досягнення повної перевірки.

Розмір доказу прямо пропорційний коефіцієнту розгалуження. Зменшення коефіцієнта розгалуження зменшує розмір доказу. Щоб вирішити ці проблеми та покращити найгірші сценарії, Ethereum може перейти з гексарних дерев на двійкові дерева Меркла та почати мерклізувати коди контрактів. Якщо коефіцієнт розгалуження в Ethereum зменшити з 16 до 2, а коди контрактів також мерклізувати, максимальний розмір доказу може скоротитися до 10 МБ. Хоча це значне покращення, важливо зазначити, що ця вартість стосується перевірки лише однієї частини даних. Навіть проста транзакція з доступом до кількох фрагментів даних вимагатиме більших доказів. З огляду на кількість транзакцій на блок і постійно зростаючий стан Ethereum, це рішення хоч і краще, але все ще не зовсім здійсненне.

З цих причин спільнота Ethereum запропонувала два різних рішення для вирішення проблеми:

1. Дерева Verkle
2. Докази STARK + Бінарні дерева Меркла

Дерева Веркле та векторні зобов’язання

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

На противагу цьому, дерева Веркла використовують спеціалізовану структуру, відому як «Векторні зобов’язання на основі еліптичної кривої», точніше, векторне зобов’язання на основі внутрішнього добутку (IPA). Вектор - це, по суті, список елементів даних, організованих в певній послідовності. Стан Ethereum можна розглядати як вектор: структуру, де численні фрагменти даних зберігаються в певному порядку, причому кожен елемент має вирішальне значення. Цей стан включає різні компоненти даних, такі як адреси, коди контрактів та інформація про зберігання, де порядок цих елементів відіграє вирішальну роль у доступі та перевірці.

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

У відміну від дерев Меркла, дерева Веркл використовують векторні зобов’язання на основі еліптичних кривих, що надають дві ключові переваги:

• Векторні зобов’язання на основі еліптичних кривих усувають необхідність в деталях елементів, крім перевіряємих даних. У деревах Меркля з коефіцієнтом розгалуження 16 перевірка однієї гілки потребує надання інших 15 хешів. Зважаючи на величезний розмір стану Ethereum, який включає багато гілок, це створює значну неефективність. Векторні зобов’язання на основі еліптичних кривих, однак, усувають цю складність, дозволяючи перевірку з меншими даними та обчислювальними зусиллями.
• За допомогою багатопідтверджень, докази, що генеруються векторними зобов’язаннями на основі еліптичної кривої, можуть бути стиснуті в один постійний розмір доказу. Стан Ethereum не лише великий, але й постійно зростає, що означає, що кількість гілок, які потребують верифікації для доступу до кореня Меркла, з часом збільшується. Однак за допомогою Verkle Trees ми можемо «стиснути» докази для кожної гілки в один постійний розмір доказу за допомогою методу, детально описаного вСтаття Данкрада Фейста. Це дозволяє перевірителям перевірити всю дерево за допомогою одного невеликого доказу, а не перевіряти кожну гілку окремо. Це також означає, що дерева Веркле не піддаються впливу зростання стану Ethereum.

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

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

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

Пруфи STARK + бінарні дерева Меркла

Verkle Trees пропонують менші розміри доказів і ефективні процеси верифікації порівняно з Merkle Trees, що полегшує керування постійно зростаючим станом Ethereum. Завдяки векторним зобов’язанням на основі еліптичної кривої можна створювати великомасштабні докази зі значно меншою кількістю даних. Однак, незважаючи на вражаючі переваги, вразливість Verkle Trees до квантових комп’ютерів робить їх лише тимчасовим рішенням. У той час як спільнота Ethereum розглядає Verkle Trees як короткостроковий інструмент для вигравання часу, довгострокова увага зосереджена на переході до квантово-стійких рішень. Саме тут STARK Proofs і Binary Merkle Trees представляють сильну альтернативу для створення більш надійної інфраструктури перевірки в майбутньому.

У процесі перевірки стану Ethereum коефіцієнт розгалуження дерев Меркля може бути зменшений (від 16 до 2) за допомогою бінарних дерев Меркля. Ця зміна є критичним кроком для зменшення розмірів доказів і зроблення процесів перевірки більш ефективними. Однак, навіть у найгіршому випадку розміри доказів все ще можуть досягати 10 МБ, що є значним. І тут на сцену вступають STARK докази, стискаючи ці великі бінарні докази Меркля до всього 100-300 кБ.

Ця оптимізація особливо важлива, коли розглядаються обмеження роботи перевіряючих вузлів на легких клієнтах або пристроях з обмеженим обладнанням, особливо якщо врахувати, що середня глобальна швидкість завантаження та вивантаження мобільних пристроїв становить приблизно 7,625 МБ/с та 1,5 МБ/с відповідно. Користувачі можуть перевіряти транзакції за допомогою невеликих портативних доказів без необхідності доступу до повного стану, а перевіряючі вузли можуть виконувати завдання перевірки блоків без зберігання повного стану.

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

Ключові виклики для STARK-доказів:

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

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

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

Доказ Меркла блоку може включати приблизно 330 000 хешів, а в гіршому випадку це число може зрости до 660 000. У таких випадках доказ STARK повинен обробляти близько 200 000 хешів в секунду.

Ось де дружні до zk хеш-функцій, таких як Poseidon, входять в гру, спеціально оптимізовані для STARK доказів з метою зменшення цього навантаження. Poseidon призначений працювати більш безшовно з ZK-доказами порівняно з традиційними алгоритмами хешування, такими як SHA256 та Keccak. Основна причина цієї сумісності полягає в тому, як працюють традиційні алгоритми хешування: вони обробляють вхідні дані як двійкові дані (0 та 1). З іншого боку, ZK-докази працюють з простими полями, математичними структурами, які фундаментально відрізняються. Ця ситуація аналогічна тому, як комп’ютери працюють у двійковій системі, тоді як люди використовують десяткову систему в повсякденному житті. Переклад бітових даних у формати, сумісні з ZK, потребує значних обчислювальних витрат. Poseidon вирішує цю проблему, нативно працюючи у простих полях, драматично прискорюючи свою інтеграцію з ZK-доказами.

Однак, оскільки Посейдон є відносно новою хеш-функцією, для встановлення такого ж рівня впевненості, що й у традиційних хеш-функцій, таких як SHA256 і Keccak, потрібен більш широкий аналіз безпеки. З цією метою, ініціативи, такі як Ініціатива з криптоаналізу Посейдона, запущений Фондом Ethereum, запрошує експертів на ретельне тестування та аналіз безпеки Посейдона, забезпечуючи, що він може витримати ворожий контроль та стати надійним стандартом для криптографічних застосувань. З іншого боку, старі функції, такі як SHA256 та Keccak, вже були широко протестовані та мають підтверджений запис безпеки, але не є ZK-дружніми, що призводить до зниження продуктивності при використанні з доказами STARK.

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

Неефективність STARKs у доведенні невеликих даних

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

1. Валідація транзакції після АА: \
   З використанням абстракції облікового запису (AA) гаманці можуть посилатися на код контракту, обходячи або налаштовуючи такі етапи, як перевірка nonce та підпису, які на сьогоднішній день є обов’язковими в Ethereum. Однак, ця гнучкість у перевірці вимагає перевірки коду контракту або інших пов’язаних даних в стані для підтвердження дійсності транзакції.
2. Виклики RPC для легкого клієнта: \
   Легкі клієнти запитують дані стану з мережі (наприклад, під час запиту eth_call) без запуску повного вузла. Щоб гарантувати вірність цього стану, докази повинні підтримувати запитані дані та підтверджувати, що вони відповідають поточному стану мережі.
3. Списки включення: \
   Менші валідатори можуть використовувати механізми списку включення, щоб забезпечити включення транзакцій у наступний блок, обмежуючи вплив потужних виробників блоків. Однак перевірка включення цих транзакцій вимагає перевірки їх правильності.

У таких випадках використання докази STARK дають мало переваг. STARK, наголошуючи на масштабованості (як підкреслюється літерою «S» у їхній назві), добре працюють для великих наборів даних, але мають проблеми зі сценаріями малих даних. На противагу цьому, SNARK, розроблені для лаконічності (як підкреслює літера «S» у їхній назві), зосереджені на мінімізації розміру доказу, пропонуючи явні переваги в середовищах з обмеженнями пропускної здатності або сховища.

Доведення STARK зазвичай мають розмір 40–50 КБ, що приблизно в 175 разів більше, ніж докази SNARK, які становлять лише 288 байт. Ця різниця в розмірах збільшує як час перевірки, так і витрати на мережу. Основною причиною більших доказів STARK є їхня залежність від прозорості та поліноміальних зобов’язань для забезпечення масштабованості, що призводить до витрат на продуктивність у сценаріях з малими даними. У таких випадках більш швидкі та компактні методи, такі як докази Меркла, можуть бути більш практичними. Докази Меркла пропонують низькі обчислювальні витрати та швидкі оновлення, що робить їх придатними для таких ситуацій.

Тим не менш, докази STARK залишаються важливими для безстатевого майбутнього Ethereum через їх квантову безпеку.

Як підсумовано в таблиці, Ethereum має чотири потенційні шляхи для вибору:

• Verkle дерева
  1. Verkle Trees отримали широку підтримку спільноти Ethereum, проводячи зустрічі раз на два тижні, щоб полегшити їх розробку. Завдяки цій послідовній роботі та тестуванню Verkle Trees виділяється як найбільш зріле та добре досліджене рішення серед поточних альтернатив. Більше того, їх адитивно гомоморфні властивості усувають необхідність переобчислювати кожну гілку для оновлення кореня стану, на відміну від дерев Меркла, що робить дерева Веркла більш ефективним варіантом. У порівнянні з іншими рішеннями, Verkle Trees наголошують на простоті, дотримуючись інженерних принципів, таких як «будь простим» або «просте — найкраще». Ця простота полегшує як інтеграцію в Ethereum, так і аналіз безпеки.
  2. Однак дерева Веркле не є квантово безпечними, що не дозволяє їм бути довгостроковим рішенням. У разі інтеграції в Ethereum цю технологію, ймовірно, доведеться замінити в майбутньому, коли знадобляться квантово-стійкі рішення. Навіть Віталік розглядає дерева Веркле як тимчасовий захід, щоб виграти час для дозрівання STARK та інших технологій. Крім того, векторні зобов’язання на основі еліптичної кривої, що використовуються в деревах Веркла, накладають більш високе обчислювальне навантаження в порівнянні з простими хеш-функціями. Підходи, засновані на хешуванні, можуть запропонувати швидший час синхронізації для повних вузлів. Крім того, залежність від численних 256-бітних операцій ускладнює доведення дерев Веркла за допомогою SNARK у сучасних системах доведення, що ускладнює майбутні зусилля щодо зменшення розмірів доказів.

Проте важливо зазначити, що дерева Веркле, завдяки відсутності залежності від хешування, значно більш підтверджувані, ніж дерева Меркле.

• STARKs + Консервативні Хеш-функції
  1. Поєднання STARKs з вже встановленими консервативними хеш-функціями, такими як SHA256 або BLAKE, забезпечує надійне рішення, яке посилює інфраструктуру безпеки Ethereum. Ці хеш-функції широко використовувалися і були широко протестовані як у науковій, так і у практичній сферах. Крім того, їх квантова стійкість підвищує стійкість Ethereum проти майбутніх загроз, які створюють квантові комп’ютери. Для сценаріїв, де безпека має вирішальне значення, це поєднання пропонує надійну основу.
  2. Однак використання консервативних хеш-функцій в системах STARK вносить значні обмеження продуктивності. Обчислювальні вимоги цих хеш-функцій призводять до високої затримки, при цьому генерація доказів займає понад 10 секунд. Це серйозний недолік, особливо в таких сценаріях, як перевірка блоків, які вимагають низької затримки. У той час як такі зусилля, як багатовимірні пропозиції щодо газу, намагаються узгодити найгіршу та середню затримку, результати обмежені. Крім того, хоча підходи, засновані на хеші, можуть сприяти швидшому часу синхронізації, їхня ефективність може не узгоджуватися з більш широкими цілями масштабованості STARK. Тривалий час обчислень традиційних хеш-функцій знижує практичну ефективність і обмежує їх застосовність.
• STARKs + Досить нові хеш-функції
  1. STARKs в поєднанні з генерацією нового покоління хеш-функцій, дружніх до STARK (наприклад, Poseidon), значно покращують продуктивність цієї технології. Ці хеш-функції розроблені для безшовної інтеграції з STARK-системами і драстично зменшують час простою при підтвердженні. На відміну від традиційних хеш-функцій, вони дозволяють генерацію доказу всього за 1-2 секунди. Їх ефективність і низька обчислювальна ​​навантаженість покращують потенціал масштабованості STARKs, що робить їх дуже ефективними для роботи з великими наборами даних. Ця можливість особливо приваблива для застосувань, що потребують високої продуктивності.
  2. Однак, відносна новизна цих хеш-функцій потребує обширного аналізу безпеки та тестування. Відсутність комплексного тестування вносить ризики при розгляді їх впровадження в критичні екосистеми, такі як Ethereum. Крім того, оскільки ці хеш-функції ще не широко використовуються, необхідні процеси тестування та валідації можуть затримати досягнення цілей з перевірки Ethereum. Час, необхідний для повного забезпечення їх безпеки, може зробити цей варіант менш привабливим у короткостроковій перспективі, що потенційно відкладе масштабованість і амбіції щодо перевірки Ethereum.
• Дерева Меркла на ґратчастій основі
  1. Merkle Trees на основі решітки пропонують перспективне рішення, яке поєднує квантову безпеку з ефективністю оновлення Verkle Trees. Ці структури усувають слабкі сторони як Verkle Trees, так і STARKs і вважаються перспективним довгостроковим варіантом. Завдяки своїй конструкції на основі решітки вони забезпечують сильну стійкість до загроз квантових обчислень, що узгоджується з фокусом Ethereum на перспективі своєї екосистеми. Крім того, зберігаючи переваги модернізації Verkle Trees, вони прагнуть забезпечити підвищену безпеку без шкоди для ефективності.
  2. Проте дослідження латиського дерева Меркля все ще знаходиться на початкових етапах і переважно теоретичне. Це створює значну невизначеність щодо їх практичної реалізації та продуктивності. Інтеграція такого рішення до Ефіріуму потребувала би значних досліджень та розробки, а також ретельного тестування для підтвердження його потенційних переваг. Ці невизначеності та інфраструктурні складнощі роблять латиські дерева Меркля малоймовірним вибором для Ефіріуму в найближчому майбутньому, що може сповільнити прогрес у досягненні мережевих цілей щодо перевірки.

Що з виконанням: Докази валідності виконання EVM

Все, що ми обговорювали досі, обертається навколо усунення необхідності для валідаторів зберігати попередній стан, який вони використовують для переходу з одного стану в інший. Мета полягає в тому, щоб створити більш децентралізоване середовище, де валідатори зможуть виконувати свої обов’язки, не підтримуючи терабайти державних даних. Навіть з рішеннями, про які ми згадували, валідаторам не потрібно було б зберігати весь стан, оскільки вони отримували б усі дані, необхідні для виконання, через свідків, включених до блоку. Однак, щоб перейти до наступного стану — і тим самим перевірити stateRoot у верхній частині блоку — валідатори все одно повинні виконати STF самостійно. Ця вимога, у свою чергу, створює ще один виклик інклюзивній природі та децентралізації Ethereum.

Спочатку The Verge замислювався як віха, яка зосереджувалася виключно на переході дерева станів Ethereum від Merkle Trees до Verkle Trees для покращення перевірюваності стану. З часом, однак, вона перетворилася на ширшу ініціативу, спрямовану на підвищення перевірюваності державних переходів і консенсусу. У світі, де тріо стану, виконання та консенсусу повністю піддається перевірці, валідатори Ethereum можуть працювати практично на будь-якому пристрої з підключенням до Інтернету, який можна віднести до категорії легких клієнтів. Це наблизить Ethereum до досягнення свого бачення «справжньої децентралізації».

У чому полягає визначення проблеми?

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

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

Якщо ви хочете перетворити розумний холодильник - так, навіть холодильник - у валідатор Ethereum за допомогою встановленого програмного забезпечення, ви стикаєтесь з двома основними перешкодами:

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

Щоб вирішити проблеми, які виникають у Light-клієнтів через відсутність доступу до попереднього стану або повного останнього блоку, The Verge пропонує, щоб пропонувальник виконував виконання, а потім долучав довідку до блоку. Цей доказ би містив перехід від кореня попереднього стану до наступного кореня стану, а також хеш блоку. З цим Light-клієнти можуть перевірити перехід стану, використовуючи лише три 32-байтових хеші, без необхідності у zk-доказі.

Однак, оскільки цей доказ працює через хеші, було б неправильно стверджувати, що він лише підтверджує перехід стану. Навпаки, доказ, прикріплений до блоку, повинен підтверджувати кілька речей одночасно:

Корінь стану в попередньому блоці = S, Корінь стану в наступному блоці = S + 1, Хеш блоку = H

1. Сам блок повинен бути дійсним, а доказ стану всередині нього — чи то Verkle Proof, чи STARKs — повинен точно перевіряти дані, які супроводжують блок.
   Коротко кажучи: перевірка блоку та супроводжуючого доказу стану.
2. Коли STF виконується з використанням даних, необхідних для виконання та включених у блок, відповідний H, дані, які повинні змінюватися у стані, повинні бути оновлені правильно.
   Коротко кажучи: перевірка переходу стану.
3. Коли нове дерево станів перебудовується з правильно оновленими даними, його кореневе значення має відповідати S + 1.
   Якщо коротко: Валідація процесу побудови дерева.

В аналогії Prover-Verifier, про яку ми згадували раніше, загалом справедливо сказати, що між двома акторами зазвичай існує обчислювальний баланс. У той час як здатність доказів, необхідних для того, щоб зробити STF перевіреним для перевірки декількох речей одночасно, дає значні переваги для верифікатора, це також вказує на те, що генерація таких доказів для забезпечення правильності виконання буде відносно складним завданням для Перевіряючого. З поточною швидкістю Ethereum блок Ethereum потрібно перевірити менш ніж за 4 секунди. Однак навіть найшвидший EVM Prover, який ми маємо сьогодні, може довести середній блок лише приблизно за 15 секунд. [1]

З огляду на це, є три різні шляхи, якими ми можемо піти, щоб подолати цю серйозну проблему:

1. Паралельне виконання в доведенні та агрегації: однією з головних переваг ZK-доказів є їх здатність до агрегації. Можливість об’єднати кілька доказів в один компактний доказ забезпечує значну ефективність у відношенні часу обробки. Це не тільки зменшує навантаження на мережу, але й прискорює процеси верифікації в децентралізований спосіб. Для великої мережі, такої як Ethereum, це дозволяє більш ефективну генерацію доказів для кожного блоку.

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

1. Використання оптимізованих систем доказів: Системи доказів нового покоління мають потенціал зробити обчислювальні процеси Ethereum швидшими та ефективнішими. Просунуті системи, такі як Оріон, Binius, і ГКРможуть значно зменшити час доведення для загальних обчислень. Ці системи мають на меті подолати обмеження поточних технологій, збільшуючи швидкість обробки при використанні менше ресурсів. Для масштабованої та ефективно орієнтованої мережі, такі оптимізації надають значну перевагу. Проте повна реалізація цих нових систем потребує всебічного тестування та зусиль у сфері сумісності всередині екосистеми.
2. Зміни вартості газу: Історично вартість газу для операцій на віртуальній машині Ethereum (EVM) зазвичай визначалася на основі їх обчислювальних витрат. Однак сьогодні важливішою стала ще одна метрика: складність перевірки. Хоча деякі операції відносно легко підтверджувати, інші мають складну структуру і потребують більш тривалого підтвердження. Налаштування вартості газу не лише на основі обчислювальних зусиль, а й на складності підтвердження операцій є важливим для підвищення безпеки та ефективності мережі.

Цей підхід може зменшити розрив між найгіршими і середніми сценаріями, забезпечуючи більш стійку продуктивність. Наприклад, операції, які важко підтвердити, можуть мати вищі витрати на газ, тоді як ті, які легше підтвердити, можуть мати нижчі витрати. Крім того, заміна структур даних Ethereum (таких як дерево стану або список транзакцій) альтернативами, сприятливими для STARK, може ще більше прискорити процеси підтвердження. Такі зміни допоможуть Ethereum досягти поставлених цілей щодо масштабованості та безпеки, роблячи її бачення щодо перевірки більш реалістичним.

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

З іншого боку, спеціалізовані схеми (наприклад, ASIC, FPGA, GPU), розроблені спеціально для певних завдань, мають значний потенціал для прискорення процесу генерації доказів. Ці рішення забезпечують набагато вищу ефективність у порівнянні з традиційним обладнанням і можуть прискорити процеси виконання. Однак цілі децентралізації Ethereum на рівні рівня 1 не дозволяють такому обладнанню бути доступним лише для обраної групи суб’єктів. Як наслідок, очікується, що ці рішення отримають більш широке використання в системах рівня 2. Тим не менш, спільнота також повинна досягти консенсусу щодо вимог до апаратного забезпечення для генерації доказів. Постає ключове питання дизайну: чи повинна генерація доказів працювати на апаратному забезпеченні споживчого класу, такому як ноутбуки високого класу, чи потрібна промислова інфраструктура? Відповідь формує всю архітектуру Ethereum, дозволяючи агресивну оптимізацію для рішень рівня 2, вимагаючи більш консервативних підходів для рівня 1.

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

Останній крок для справжньої повної перевірки: консенсус

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

Імовірнісний консенсус будується на моделі комунікації з плітками. У цій моделі, замість того, щоб безпосередньо спілкуватися з усіма вузлами, що представляють мережу, вузол обмінюється інформацією з випадково обраним набором з 64 або 128 вузлів. Вибір ланцюжка вузла базується на цій обмеженій інформації, що вводить можливість помилки. Однак з часом, у міру розвитку блокчейну, очікується, що ці вибори зійдуться до правильного ланцюга з похибкою 0%.

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

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

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

Протокол легкого клієнта Altair: Комітет синхронізації

Комітет синхронізації – це механізм, запроваджений разом з оновленням Altair для подолання обмежень імовірнісного консенсусу Ethereum і покращення перевірюваності ланцюжка для легких клієнтів. Комітет складається з 512 випадково обраних валідаторів, які працюють протягом 256 епох (~27 годин). Ці валідатори створюють підпис, що представляє голову ланцюга, дозволяючи легким клієнтам перевіряти валідність ланцюга без необхідності завантажувати історичні дані ланцюга. Роботу Синхронного комітету можна узагальнити таким чином:

1. Утворення комітету:
   512 валідаторів вибираються випадковим чином з усіх валідаторів мережі. Цей вибір регулярно оновлюється, щоб зберегти децентралізацію та запобігти залежності від певної групи.
2. Генерація підписів:
   Члени комітету пред’являють підпис, який відображає останній стан ланцюжка. Цей підпис є колективним підписом BLS, створеним учасниками та використовується для перевірки валідності ланцюга.
3. Верифікація клієнта Light:
   Легкі клієнти можуть перевірити правильність ланцюга, просто перевіривши підпис від комітету синхронізації. Це дозволяє їм безпечно відстежувати ланцюг, не завантажуючи минулі дані ланцюга.

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

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

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

У зв’язку з цими обмеженнями в екосистемі Ethereum тривають зусилля з перепроектування механізму консенсусу та впровадження рішень, які забезпечують детерміновану остаточність за коротші періоди. Пропозиції на кшталт Орбіта-SSFі3SFмета полягає в перетворенні структури консенсусу Ethereum з нуля, створюючи більш ефективну систему для заміни ймовірного консенсусу. Такі підходи спрямовані не лише на скорочення часу остаточності ланцюжка, але й на створення більш ефективної та перевіреної мережевої структури. Спільнота Ethereum продовжує активно розробляти та готувати ці пропозиції для майбутньої реалізації.

Снаркифікація згоди

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

• ECADDs:
  • Мета: Ця операція використовується для агрегування відкритих ключів валідаторів і важлива для забезпечення точності та ефективності ланцюга. Завдяки агрегованій природі підписів BLS, декілька підписів можуть бути об’єднані в одну структуру. Це зменшує накладні витрати на зв’язок та робить процеси верифікації на ланцюгу більш ефективними. Забезпечення більш ефективної синхронізації серед великих груп валідаторів робить цю операцію критичною.
  • Виклики: Як згадувалося раніше, валідатори Ethereum голосують за порядок ланцюжка протягом епох. Сьогодні Ethereum – це мережа, яка налічує приблизно 1,1 мільйона валідаторів. Якби всі валідатори намагалися поширювати свої голоси одночасно, це створило б значне навантаження на мережу. Щоб уникнути цього, Ethereum дозволяє валідаторам голосувати на основі слотів протягом епохи, коли лише 1/32 усіх валідаторів голосують на слот. Хоча цей механізм зменшує накладні витрати на мережевий зв’язок і робить консенсус більш ефективним, враховуючи сьогоднішню кількість валідаторів, близько 34 000 валідаторів голосують у кожному слоті. Це означає приблизно 34 000 операцій ECADD на слот.
• Пари:
  • Мета: Операції парування використовуються для перевірки BLS підписів, забезпечуючи дійсність епох на ланцюжку. Ця операція дозволяє пакетну перевірку підписів. Однак вона не є дружньою до zk, що робить дуже дорогим доведення за допомогою технології zk-proof. Це становить велике виклик при створенні інтегрованого процесу верифікації з технологіями нульового знання.
  • Виклики: Операції парування в Ethereum обмежені максимум 128 свідоцтв (агреговані підписи) на слот, що призводить до меншої кількості операцій парування порівняно з ECADDs. Однак відсутність дружелюбності до zk в цих операціях становить значний виклик. Доведення операції парування з zk-доказами коштує тисячі разів дорожче, ніж доведення операції ECADD [2]. Це робить адаптацію операцій парування для технологій з нульовими знаннями однією з найбільших перешкод в процесах підтвердження згоди Ethereum.
• SHA256 Хеші:
  • Призначення: хеш-функції SHA256 використовуються для зчитування та оновлення стану ланцюга, забезпечуючи цілісність даних ланцюга. Однак відсутність дружності до zk призводить до неефективності процесів верифікації на основі zk-proof, що створює серйозну перешкоду для майбутніх цілей Ethereum щодо перевірюваності.
  • Проблеми: хеш-функції SHA256 часто використовуються для зчитування та оновлення стану ланцюга. Однак їхня недружелюбність zk суперечить цілям перевірки Ethereum на основі zk-proof. Наприклад, між двома епохами кожен валідатор запускає STF рівня консенсусу Ethereum, щоб оновити стан винагородами та штрафами на основі продуктивності валідатора протягом епохи. Цей процес значною мірою покладається на хеш-функції SHA256, що значно збільшує витрати в системах на основі zk-proof. Це створює значний бар’єр для узгодження механізму консенсусу Ethereum з технологіями zk.

Операції ECADD, Pairing та SHA256, що використовуються в поточному рівні консенсусу, відіграють важливу роль у досягненні цілей Ethereum щодо перевірки. Однак їх нездатність до zk-дружності ставить значні виклики на шляху до досягнення цих цілей. Операції ECADD створюють велике навантаження через велику кількість голосів валідатора, тоді як операції Pairing, незважаючи на меншу кількість, коштують тисячі разів дорожче для доведення за допомогою zk-доказів. Крім того, нездатність до zk-дружності хеш-функцій SHA256 робить дуже складним доведення переходу стану ланцюжка бікону. Ці проблеми підкреслюють необхідність комплексного перетворення, щоб привести існуючу інфраструктуру Ethereum у відповідність до технологій з нульовими знаннями.

Рішення “Beam Chain”: переосмислення рівня консенсусу Ethereum

12 листопада 2024 року під час своєї презентації на Devcon Джастін Дрейк представив пропозицію під назвою «Beam Chain», спрямовану на фундаментальну та всебічну трансформацію рівня консенсусу Ethereum. Beacon Chain лежить в основі мережі Ethereum вже майже п’ять років. Однак за цей період не відбулося серйозних структурних змін у Beacon Chain. На противагу цьому, технологічний прогрес швидко прогресує, набагато перевершуючи статичну природу Beacon Chain.

У своїй презентації Джастін Дрейк підкреслив, що за ці п’ять років Ethereum засвоїв значні уроки в таких критичних областях, як розуміння MEV, прориви в технологіях SNARK і ретроспективне усвідомлення технологічних помилок. Проекти, засновані на цих нових знаннях, поділяються на три основні стовпи: виробництво блоків, стейкінг і криптографія. Наступне зображення узагальнює ці проекти та запропоновану дорожню карту:

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

У цьому розділі ми детально розглянули кроки консенсусу, стану та виконання The Verge, і однією з найважливіших проблем, висвітлених під час цього процесу, є використання функції хешування SHA256 у Beacon Chain Ethereum. Хоча SHA256 відіграє центральну роль у забезпеченні безпеки мережі та обробці транзакцій, його відсутність зручності для zk є значною перешкодою для досягнення цілей Ethereum щодо перевірюваності. Його висока обчислювальна вартість і несумісність з технологіями zk роблять його критичною проблемою, яку необхідно вирішити в майбутніх розробках Ethereum.

Дорожня карта Джастіна Дрейка, представлена під час його виступу на Devcon, передбачає заміну SHA256 у Beacon Chain на дружні до zk хеш-функції, такі як Poseidon. Ця пропозиція спрямована на модернізацію рівня консенсусу Ethereum, зробивши його більш перевіреним, ефективним і узгодженим із технологіями zk-proof.

У цьому контексті ми бачимо, що Ethereum стикається не лише з проблемами незручних для zk-функцій хешування, але й потребує переоцінки цифрових підписів, які використовуються в його рівні консенсусу для довгострокової безпеки. З розвитком квантових обчислень, цифрові алгоритми підпису, такі як ECDSA, які використовуються в даний час, можуть стати об’єктом серйозних загроз. Як зазначено в рекомендаціях, опублікованих NIST, варіанти ECDSA з рівнем безпеки 112 біт будуть застарілі до 2030 року і повністю заборонені до 2035 року. Це настаєво вимагає переходу для Ethereum та подібних мереж на більш стійкі альтернативи, такі як квантово-стійкі підписи у майбутньому.

На даний момент сигнатури на основі хешу з’являються як квантово-стійкі рішення, які можуть відігравати вирішальну роль у підтримці цілей безпеки та перевірюваності мережі. Вирішення цієї потреби також усуває другу важливу перешкоду для того, щоб зробити Beacon Chain перевіреним: підписи BLS. Одним із найважливіших кроків, які Ethereum може зробити для забезпечення квантової безпеки, є впровадження постквантових рішень, таких як сигнатури на основі хешу та SNARK на основі хешу.

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

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

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

Заключні думки та висновки

Шлях Ethereum до перевірки представляє собою фундаментальний зсув у технології блокчейну. Ініціатива Verge вирішує основні недоліки за допомогою дерев Verkle для перевірки стану та доказів STARK для масштабованих переходів.

Однією з найамбітніших пропозицій є Beam Chain, комплексний редизайн рівня консенсусу Ethereum. Усуваючи обмеження Beacon Chain і включаючи альтернативи, дружні до zk, цей підхід спрямований на підвищення масштабованості Ethereum, зберігаючи при цьому його основні принципи децентралізації та доступності. Однак перехід також підкреслює проблеми, з якими стикається Ethereum, збалансовуючи обчислювальні вимоги з метою підтримки інклюзивної мережі без дозволів.

З тим, що Національний інститут стандартів і технологій США планує відмовитися від поточної криптографії еліптичної кривої до 2035 року, Ethereum повинна використовувати квантово-стійкі рішення, такі як хеш-підписи та Poseidon. Ці рішення мають свої власні компроміси ефективності.

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

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

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

Еволюція Ethereum підкреслює його роль як важливого гравця у формуванні ери Web3. Розв’язуючи сьогоденні виклики практичними рішеннями, Ethereum наближається до майбутнього, де перевірка, квантова стійкість та масштабованість стануть стандартом, а не винятком.

Застереження:

1. Цю статтю перепродуковано з [[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 Дослідження](https://research.2077.xyz/)\]. Усі авторські права належать оригінальному автору [Корай Акпінарр]. Якщо є зауваження до цього видання, будь ласка, зв’яжіться з Вивчайте Gateкоманда, і вони оперативно вирішать це.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклад статті на інші мови виконує команда gate Learn. Крім випадків, коли зазначено, заборонено копіювання, поширення або плагіат перекладених статей.