Детальне пояснення валідатора блоків Ethereum Zeth: перший тип 0 zkEVM

Оригінальна назва: Announcing Zeth: the first Type Zero zkEVM

Актори: Тім Картенс, Віктор Граф, Рамі Халіл, Стівен Лі, Паркер Томпсон, Вольфганг Велц, Zeth Collaboration

Збірка: bayemon.eth, ChainCatcher

25 серпня Zeth, валідатор блоків ZK з відкритим вихідним кодом Ethereum на основі RISC Zero zkVM, був випущений публічно. Zeth виконує всю роботу, необхідну для створення нових блоків у zkVM, не покладаючись на валідатори чи комітети синхронізації. Zeth був перевірений на кількох реальних блоках основної мережі Ethereum і пройшов усі відповідні тести офіційного набору тестів Ethereum. Zeth зміг реалізувати підтримку Rust на основі zkVM і потужні плати, включаючи revm, ethers і alloy протягом 4 тижнів. Завдяки підтримці zkVM для безперервності та сервісів перевірки Bonsai Zeth може створити ці перевірки за лічені хвилини. Завдяки підтримці Zeth для перевірки в мережі будь-хто може перевірити ці докази в мережі за низькою ціною. У цій публікації ми розглянемо докладніше, але якщо ви хочете покопатися в коді, перегляньте вихідний код і відвідайте портал розробників RISC Zero.

Резюме

Приблизно рік тому Віталік детально розповів про різні типи zkEVM:

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

Хоча в історії Ethereum були випадки, коли це було можливо, сьогодні ми раді повідомити, що докази блокування Ethereum за допомогою zkVM і сервісів Bonsai RISC Zero займають хвилини, а не години.

Zeth: верифікована генерація блоків Ethereum

Сьогодні ми випустили Zeth, валідатор блоків ZK з відкритим кодом для Ethereum на RISC Zero zkVM.

Zeth може довести, що певний блок Ethereum дійсний, не покладаючись на валідатори чи комітети синхронізації. Це тому, що Zeth виконує всю роботу, необхідну для створення нових блоків у zkVM, зокрема:

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

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

Використовуючи zkVM RISC Zero та популярні ящики Rust, такі як revm, ether і alloy, ми написали першу версію Zeth менш ніж за 4 тижні. Завдяки підтримці безперервності в zkVM і службі перевірки Bonsai можна створити перевірку за лічені хвилини. Завдяки підтримці перевірки в мережі ми можемо перевірити ці докази в мережі за низькою ціною.

Zeth був перевірений на кількох реальних блоках основної мережі Ethereum і пройшов усі відповідні тести офіційного набору тестів Ethereum.

Оскільки Zeth створює стандартні блоки Ethereum, його можна розглядати як zkEVM типу 1. Але це набагато більше: оскільки Zeth створено з використанням стандартних кодових панелей Rust (тих самих кодових панелей, що використовуються популярними повними вузлами, як-от Reth), ми вважаємо за краще думати про неї як про zkEVM класу 0: повна сумісність з протоколом і багато повторного використання коду. . **

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

RISC Zero полегшує створення зведених zk, zkEVM, легких клієнтів і мостів

Ми написали Zeth з двох причин:

1. Спростіть іншим командам створення власної інфраструктури на основі ZK: ZK rollup, zkEVM, ZK light client, ZK bridge тощо. Zeth надає все необхідне для створення доказів ZK для блоків на основі EVM. Це критичний компонент будь-якого zkEVM або мосту. Zeth є відкритим вихідним кодом на основі revm, тому розробники проектів можуть легко змінювати або використовувати його. Докази можна перевірити в мережі (чудово для мостів і L2) або в локальній програмі (чудово для повних вузлів і легких клієнтів).
2. Проведіть відповідне дослідження продуктивності EVM у zkVM Zeth, особливо завдань, пов’язаних з Ethereum. (Аналіз результатів опитування див. нижче).

зведення zk і zkEVM

Будучи zkEVM типу 0, Zeth дає змогу розробникам створювати зведені пакети zk із повністю вбудованою сумісністю EVM та Ethereum. У поєднанні з підтримкою Zeth перевірки доказів у ланцюзі створення рішення розширення L2 на основі ZK стане надзвичайно простим.

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

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

Ми сподіваємося, що зусилля Zeth демократизують zk rollup і zkEVM, знаючи, що рішення L2, керовані zk, раніше вимагали років досліджень і розробок і понад 100 мільйонів доларів США фінансування, що є витратою, яку більшість проектів не можуть собі дозволити.

Легкий клієнт і міст

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

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

З такими інструментами, як Zeth, ризик того, що вузли чинять зло, значно зменшується. Легкі клієнти можуть інтегруватися з Zeth, просто додавши кілька виносок до zkVM; додатки в ланцюжку, такі як мости, можуть інтегруватися з Zeth за допомогою нашого контракту про підтвердження перевірки в ланцюзі.

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

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

Хороший фундамент спрощує процес розробки проекту

На основі RISC Zero zkVM і архітектури набору інструкцій RISC-V Zeth може надати розробникам знайомий досвід програмування. Але наша zkVM — це більше, ніж просто ядро RISC-V. У нас також є схеми прискорення для типових криптографічних завдань, таких як хешування та перевірка підпису.

Цей гібридний підхід (поєднання процесорних ядер загального призначення зі схемами прискорення) дає нам найкраще з обох світів:

• Підтримка основних мов програмування.
• Продуктивність критичних криптографічних операцій не порушується.

У результаті ми змогли швидко створити Zeth, використовуючи існуючі пакети коду Rust із revm, ether і alloy. Повторно використовуючи існуючі плати, ми завершили першу версію Zeth менш ніж за 4 тижні. Така швидкість неможлива в менш зрілих екосистемах.

З точки зору продуктивності, Zeth використовує наші схеми прискорювача для перевірки підпису ECDSA, а також безперервність – нову функцію нашої ZK-платформи, яка полегшує використання кластерів графічних процесорів, що працюють паралельно (за допомогою nVidia CUDA або Apple Metal), щоб швидко підтвердити великі розрахунки. Продовження прості у використанні: ця функціональність надається прозоро для всіх гостьових програм, що працюють у zkVM, тобто для належної роботи не потрібно змінювати код.

За допомогою нашої zkVM ми можемо швидко генерувати ZK-докази дійсності блоку Ethereum за хвилини, а не за години.

Продуктивність

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

Що стосується ефективності, слід враховувати кілька факторів:

• Обчислювальні ресурси, необхідні для створення доказів.
• «Час стіни», необхідний для створення доказу (тобто скільки часу користувач має чекати, поки доказ стане доступним).
• Загальна вартість створення доказів (дол. США).

Безперервність

ZkVM Zeth можна налаштувати на продуктивність за допомогою безперервної роботи. Тож нам потрібно на мить зупинитись і обговорити, як працює «безперервна робота».

Наша zkVM реалізує стандартні процесори RISC-V. Тому виконання вимірюється циклами. (У нашій схемі більшість інструкцій RISC-V виконуються за 1 цикл, хоча є винятки). Для виконання простих програм зазвичай потрібно лише кілька сотень тисяч циклів, але для більш складних програм можуть знадобитися мільярди циклів.

У типовій системі ZK ці цикли виконання об’єднуються в доказ; зі збільшенням кількості циклів зростає час і пам’ять, необхідні для створення доказу. Але наша zkVM не дотримується цих стереотипів, і на початку цього року ми запровадили нову функцію безперервності, яка покращує недоліки традиційної генерації схеми перевірки.

З точки зору безперервності процес перевірки поділяється на три фази:

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

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

Коли генеруються докази сегментів, вони з часом згортаються. Кожна операція «зведення» бере пару послідовних сегментованих доказів і створює новий доказ для комбінації цих сегментів. Наприклад, якщо сегмент 1 доводить, що програма перейшла зі стану A у стан B, а сегмент 2 доводить, що програма перейшла зі стану B у стан C, тоді зведення доводить, що програма перейшла зі стану A у стан C. За наявності достатньої кількості працівників це можна зробити за log(N) часу, де N — кількість фрагментів.

Ми побачимо ці етапи в дії, коли заглибимося в цифри.

**Наскільки складно створити блок Ethereum? **

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

Наприклад, блок 17606771 створює 2131 екстент. Кожен сегмент представляє щонайбільше 2^20 циклів виконання, тому все обчислення займає щонайбільше 2 234 515 456 циклів виконання.

Загалом ми бачимо, що для створення типового блоку Ethereum потрібно від 2 до 400 мільйонів циклів, але іноді до 9,5 мільярдів циклів. (Спочатку ми були здивовані, побачивши, що ці відмінності не відображені в газі транзакції. Але, подумавши над цим, це стало сенсом: газова система була розроблена з урахуванням регулярного виконання, а не доказів ZK).

З безперервністю цією шкалою легко керувати. Згідно з цими цифрами, однорангової мережі з 10 000 вузлів, на яких працюють валідатори zkVM, достатньо для досягнення найвищої продуктивності паралельної валідації для найбільших блоків, що становить невелику частину від 700 000 валідаторів, які зараз є в Ethereum.

**Скільки часу потрібно, щоб створити доказ? **

Щоб зібрати основні дані про продуктивність, ми запустили тестовий екземпляр Bonsai із 64 GPU Workers. Потім ми попросили його підтвердити блокування 17735424 (182 транзакції, 3242 сегменти або приблизно 3,4 млрд циклів) за допомогою Zeth.

Щоб створити докази, zkVM має спочатку розділити виконання на сегменти. На скріншоті нижче цей процес було зафіксовано завданням utor, яке виконувалося 10 хвилин. (Більшість цього часу припадає на роботу з AWS, як-от запис до мережевого сховища). На локальній машині виконання того самого завдання займає менше 6 хвилин. Ми сподіваємося значно скоротити цей час протягом наступного року).

Нарешті виконавець ділить страту на 3242 частини. Це велика фрагментація лише для 64 GPU. Тому кожен робочий вузол повинен створити 50 доказів сегментів. Як показано на малюнку нижче, це займає 35 хвилин. Якщо у нас у 50 разів більше робочих вузлів, це займе лише 42 секунди.

Після завершення перевірки сегмента починається зведення. Оскільки існує 3242 сегменти, нам потрібно виконати процес зведення log_2(3242) = 12 раундів. На ранніх етапах згортання робітників більше, ніж робочих; тому перший етап займає 1 хвилину, другий етап займає 35 секунд, третій етап займає 25 секунд і так далі. До сьомого етапу час стабілізувався на рівні трохи більше 5 секунд. Так само, якби у нас було більше робітників, кожен етап займав би лише 5 секунд.

Після завершення зведення результати завершуються, що займає ще хвилину.

У результаті ми змогли згенерувати докази приблизно за 50 хвилин (ефективна швидкість 1,1 МГц) із недостатнім розміром кластера. Якщо розмір кластера правильний, ми оцінюємо, що генерація доказів буде швидшою:

У повністю розпаралеленому випадку етап перевірки можна завершити за 42 + 12 * 5 + 60 секунд або 2 хвилини 42 секунди.

Якщо округлити консервативно і включити час виконавця, то час буде десь між 9 і 12 хвилинами (ефективна швидкість 4,7 МГц - 6,3 МГц).

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

Витрата ресурсів на створення доказів

Наведений вище тестовий кластер було розгорнуто в AWS. Він складається з 64 перевірочних вузлів g5.xlarge і 1 вузла виконання m5zn.xlarge. За даними Amazon, кожен вузол g5.xlarge має

• 1 GPU з 24 ГБ пам'яті GPU
• 4 vCPU з об'ємом пам'яті 16 ГБ

На момент написання цієї статті ціна на вимогу для цих екземплярів становить 1,006 доларів США за годину, а зарезервовані екземпляри – 0,402 доларів США за годину. Тим часом специфікація Amazon показує, що наш вузол m5zn.xlarge має

• 4 vCPU, 16 ГБ оперативної пам’яті

На момент написання цієї статті ціна On-Demand для цього екземпляра становить $0,3303/год.

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

Нагадаємо, що ми розгорнули 64 вузли перевірки, і в цьому розгортанні знадобилося 50 хвилин (від кінця до кінця), щоб створити доказ. Ігноруючи час простою, 64 вузли перевірки плюс один вузол виконання коштують 50/60 * (64 * 0,402 + 0,3303) = $21,72 за 50 хвилин. Це завищена оцінка, оскільки передбачається, що ми платимо непрацюючим працівникам. Якщо ми не беремо до уваги вартість простою працівників (наприклад, їх закриття або переведення на іншу роботу), вартість становить близько $19,61.

• Цей блок містить 182 транзакції, або 0,11 дол. США за транзакцію.
• Загальна вартість транзакції становить 1,125045057 Eth, або близько $2137,59. Таким чином, кожен 1 долар доказу приносить 109,01 дол. США коштів користувача.
• Винагорода, сплачена за той самий блок, становить 0,117623263003047027 Eth (без урахування комісії за транзакції). На момент написання статті це становило близько $223,48. Таким чином, наші докази коштують приблизно 8,7% винагороди за блок.
• Комісія за трансакцію становить 0,03277635 Eth, або $62,28, що втричі перевищує вартість нашого підтвердження.

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

Існує кілька способів подальшого зниження витрат. Окрім продовження покращення продуктивності zkVM, можливо, додавання прискорювача Keccak, ми також можемо шукати дешевші екземпляри. Важливо, що враховуючи машини з низькими характеристиками, які ми використовуємо (а наша zkVM підтримує nVidia Cuda та Apple Metal), цю роботу можна легко виконати через p2p-мережу звичайних споживчих ПК і Mac.

Перевірка в мережі

Як згадувалося вище, ми перевірили докази Zeth на Sepolia за допомогою валідатора RISC Zero Groth16. Це відносно нова частина стеку протоколів RISC Zero, випущена на початку цього місяця. Він працює за допомогою Bonsai для перетворення рідного доказу STARK zkVM на еквівалентний доказ SNARK і надсилання цього доказу до валідатора SNARK у мережі.

Якщо ми розглядаємо вхідні дані транзакції як дані UTF-8, ми бачимо, що підтвердження відповідає блоці 17735424.

За допомогою Bonsai перетворення зі STARK на SNARK займає приблизно 40 секунд. Перевірка SNARK у мережі коштувала 245 129 газу (~5,90 доларів США на момент написання).

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

Що це означає для Ethereum

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

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

Додаток: Як працює Zeth

Цей розділ для розробників.

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

Але на відміну від повних вузлів, ми робимо це в zkVM. Це означає, що ми отримуємо ZK-доказ того, що блок із заданим хешем дійсний.

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

Криптографія

Першим викликом є криптографія. Створення блоку Ethereum вимагає багато роботи, найважливішою з яких є хешування (Keccak-256) і перевірка підпису (ECDSA і secp256k1).

Наша zkVM має прискорену підтримку еліптичних кривих, тому перевірка підпису ECDSA не становить труднощів.

Але коли справа доходить до хешування, нам не так пощастило. Наша zkVM має прискорену підтримку Sha2-256, але не (на момент написання) Keccak-256. Тому наразі ми використовуємо лише реалізацію Keccak у ящику sha3 Rust. Завдяки профілюванню ми знаємо, що для цього потрібно багато циклів. Це не оптимально, але наша zkVM може це впоратися, і ми можемо переробити та додати прискорювачі Keccak пізніше.

Облікові записи та сховище: продуктивність і безпека

В Ethereum облікові записи та сховище відстежує глобальний Merkle Patricia Trie (MPT).

За даними Etherscan, на момент написання статті дерево містило стан майже 250 000 000 унікальних адрес Ethereum. Загалом це невеликий обсяг даних, але цього достатньо, щоб змусити нас бути обережними щодо того, як ми їх зберігаємо та використовуємо. Зокрема, продуктивність MPT є критичною.

Але продуктивність — це не єдиний фактор, ми також повинні враховувати безпеку.

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

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

Для генераторів блоків Zeth це означає перевірку стану всіх відповідних облікових записів і сховища (тобто облікових записів і сховища, необхідних для виконання певного списку транзакцій).

На щастя, такий механізм передбачено EIP-1186, який визначає стандартний спосіб підтвердження стану даного облікового запису (та його сховища) за допомогою включення Merkle.

В принципі, генератори блоків Zeth можуть перевіряти стан облікового запису та сховища, перевіряючи набір доказів включення EIP-1186. Але такий підхід не ідеальний.

Замість цього краще використовувати дані в доказі включення EIP-1186 для побудови часткового MPT. Це тип MPT, який включає лише вузли, які мають відношення до певного списку транзакцій; непов’язані гілки просто представлені відповідними хешами. Ви можете розглядати часткові MPT як свого роду «об’єднання» доказів включення Меркла або, якщо хочете, як докази підмножини Меркла.

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

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

1. Перед запуском генератора блоків Zeth ми запускаємо список транзакцій у пісочниці, щоб визначити, які облікові записи та сховище є актуальними. (Цей процес також дозволяє нам визначити найстаріший пов’язаний блок-попередник, який потрібен для підтримки запитів blockhash().
2. Ми отримуємо підтвердження EIP-1186 для кожного відповідного облікового запису та сховища. (Ми також отримуємо відповідні блоки-попередники).
3. Ми використовуємо ці докази включення, щоб побудувати частковий MPT, який включає всі відповідні дані.
4. Ми запускаємо zkVM, даємо йому запустити генератор блоків Zeth і надаємо деякі MPT та інші вхідні дані (батьківський блок, список транзакцій тощо).

У zkVM, генератор блоків Zeth:

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

Після завершення роботи генератора блоків Zeth він виведе хеш-значення нового блоку.

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

Іншими словами: якщо батьківський блок дійсний, то новий блок, створений Zeth, також дійсний.

Отже, якщо хтось надасть вам новий блок і ZK-доказ, згенерований Zeth, ви можете перевірити дійсність блоку, перевіривши такі три речі:

1. Переконайтеся, що доказ ZK дійсний і від Zeth. Для додатків поза ланцюгом для перевірки можна використовувати функції, надані ящиком zkVM Rust. Для додатків у ланцюзі це можна перевірити за допомогою нашого валідатора доказів у ланцюзі.
2. Переконайтеся, що ZK доводить, що хеш нового блоку був зафіксований.
3. Переконайтеся, що батьківський блок має очікуваний хеш.

Якщо вони перевіряються, новий блок дійсний.

Обмеження та майбутні вдосконалення

Метою нашого проекту є вивчення продуктивності блокової конструкції. З цієї причини ми вирішили обмежити область дії об’єднаними блоками.

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

Нарешті, Zeth — це нове програмне забезпечення. Хоча ми провели певне тестування (зокрема набір тестів Ethereum і різні реальні блоки), Zeth все ще може містити деякі помилки. На момент написання цієї статті це програмне забезпечення слід вважати експериментальним.