zkEVM Rollup: розрив між технологічним баченням і проектом

Щоб вирішити проблему розширення мережі блокчейну рівня 1, з’явилося рішення Rollup. У поєднанні з технологією ZK, ZK Rollup став новим улюбленцем доріжки Layer 2. Однак для більшості людей пов’язані поняття, такі як ZK, Rollup і EVM, можуть мати певний поріг розуміння. Таким чином, мета цього дослідницького звіту полягає в тому, щоб систематично відсортувати серію концепцій zkEVM Rollup для вас короткою та легкою для розуміння мовою, глибоко проаналізувати еволюцію та стан розвитку технології zkEVM Rollup та інтерпретувати основні екологічні Він розроблений, щоб допомогти вам повністю зрозуміти та оцінити тенденцію розвитку зведеної версії zkEVM.

ЧАСТИНА 1 Розуміння ZK

ZK (або ZKP), повна назва — Zero-Knowledge Proof, тобто підтвердження з нульовим знанням. У криптографії підтвердження з нульовим знанням або протокол з нульовим знанням — це метод, за допомогою якого одна сторона (доказник) може підкорятися інша сторона (сертифікатор верифікації) для доведення факту без розкриття конкретної інформації про факт, тобто одна сторона (підтверджувач) може повідомити іншій стороні, чи вірний факт, без розкриття будь-якої «конкретної інформації» факт, тому технологію ZK можна використовувати в конфіденційності Сфера захисту дає нам великий простір для фантазії.

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

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

01 Генерація ключів, підтвердження та перевірка

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

Малюнок 1. Приклад електричної схеми, можна помітити, що всі операції в схемі розділені на найпростіші основні операції | Джерело

Використовуючи цю схему та деякі випадкові числа як вхідні дані, ми можемо створити ключ перевірки (pk, ключ перевірки) і ключ перевірки (vk, ключ перевірки) для подальшого процесу перевірки, схематична діаграма показана на малюнку 2.

Рисунок 2 Генерація «загальнодоступних параметрів»

Для нашої системи підтвердження також потрібні два типи вхідних даних — приватні та публічні, а також ключ підтвердження для створення підтвердження. Серед них приватний внесок (свідок) – це таємниця, яку ми хочемо приховати, а публічний – це інформація, яку можна оприлюднити. Наприклад, у рівнянні X+Y*Z=OUT, X і OUT є загальнодоступними входами, тоді як Y і Z мають значення, які ми не хочемо, щоб вони були відкритими для валідатора. Незважаючи на те, що значення Y*Z можна вивести на основі вхідних даних громадськості, конкретні значення Y і Z все ще невідомі.

Рисунок 3 Процес перевірки та процес перевірки ZK-SNARK

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

Зрозумівши наведений вище процес, ми можемо застосувати цю технологію для перевірки блоку для реалізації невеликого ZK-SNARK, як показано на малюнку 3. Існує багато протоколів і методів для реалізації доказу з нульовим знанням. SNARK відносно легко зрозуміти, і це також вибір більшості проектів на даному етапі. У параграфі «Від ZK-SNARK до ZK-STARK» ми розповімо про переваги та недоліки SNARK.

02 Спробуйте трохи SNARK

Давайте візьмемо підтвердження з нульовим знанням дерева Merkle, яке записує статус облікового запису, як приклад для практики. Дерево Merkle записує адресу та баланс рахунку. Коли є нова транзакція, яка потребує оновлення дерева Merkle, нам потрібно виконати наступні операції:

1. Переконайтеся, що відправник і одержувач транзакції знаходяться на листових вузлах дерева.

2. Перевірити підпис відправника.

3. Оновіть баланси відправника та одержувача.

4. Оновіть кореневий вузол дерева Merkle (тобто Merkle Root) і використовуйте його як кінцевий результат.

За відсутності підтверджень нульового знання верифікатор повинен повторити ці кроки, щоб переконатися в точності обчислення. Але після використання доказу нульового знання ситуація інша. По-перше, нам потрібно визначити два типи вхідних даних:

Під час цього процесу лише нова інформація про транзакції, оригінальний корінь Merkle та оновлений корінь Merkle є загальнодоступними.

Саме Дерево Merkle діє як свідок (свідок) і не потребує зчитування чи обробки верифікатором.

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

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

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

03 Від ZK-SNARK до ZK-STARK

Протокол перевірки, згаданий вище, це ZK-SNARKs. SNARK означає стислі неінтерактивні аргументи знань, де стислий означає стислість цього методу, а неінтерактивний – це порівняння з іншими методами доказів, SNARK є неінтерактивними доказами, тобто верифікатору потрібно лише використовувати доказ, наданий перевірником. Згенерований доказ може отримати результат перевірки. Однак із ЗК-СНАРКами є певні проблеми. На етапі генерації ключа схема та випадкове число еквівалентні набору початкових загальнодоступних параметрів, і існує неминуча проблема централізації в процесі генерації цього загальнодоступного параметра.

ZK-STARK має інший підхід, заснований на SNARK, де «s» означає масштабованість, яка доводить, що час генерації та вихідний час обчислення є квазілінійними, тоді як час перевірки є логарифмічним у вихідному обчисленні, що означає у випадку великого набору даних як даних час перевірки, необхідний верифікатору, значно скорочується.

У той же час, будучи оновленою версією ZK-SNARKs, ZK-STARKs може не тільки підвищити ефективність верифікації (теоретична ефективність у 10 разів), але також не покладається на еліптичні криві чи надійні налаштування та не вимагає процесу генерації початкових загальнодоступних параметрів (літера «T» означає прозорість), що усуває необхідність централізованого довіреного налаштування. Деякі розробники вважають, що хеш-функція в ZK-STARK може допомогти протистояти квантовим атакам.

Однак ZK-STARKs був представлений пізно, поточна технологія недостатньо зріла, і вона покладається на хеш-функції, що обмежує її універсальність.ZK-SNARKs все ще є загальним алгоритмом доказу. Деякі приклади алгоритмів на основі STARK включають Fractal, SuperSonic тощо, а пов’язані проекти включають StarkWare, Polygon Miden тощо.

ЧАСТИНА 2 Розуміння зведення

На додаток до ZK, ще одна концепція, яку ми повинні зрозуміти, це Rollup.Значення Rollup полягає у вирішенні проблеми перевантаження мережі рівня 1.

Візьмемо Ethereum як приклад, зараз у нього є проблема перевантаження транзакцій. Є два шляхи вирішення цієї проблеми: один полягає у збільшенні пропускної здатності самого блокчейну, наприклад, розширення пропускної здатності блокчейну за допомогою таких технологій, як шардинг. Інший підхід полягає у зміні способу використання блокчейну, тобто у виконанні більшості дій на другому рівні (рівні 2, надалі – L2), а не безпосередньо в ланцюжку. У цьому випадку в ланцюжку часто розгортається смарт-контракт, який відповідає лише за обробку депозитів і зняття коштів і використовує різні методи для читання даних поза ланцюгом, щоб перевірити, чи все, що відбувається поза ланцюгом, відповідає правилам. Це еквівалентно будівництву шосе поруч із невеликою дорогою, тобто шляхом розширення L2 для вирішення проблеми заторів.

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

Зведення та доступність даних

Порівняно з іншими рішеннями для розширення Rollup має певні переваги. Одна з більш інтуїтивно зрозумілих переваг полягає в тому, що він вирішує проблему доступності даних Плазми (згадану в розділі «Доступність даних» статті пана Даррена), і тут я також зроблю деякі додаток.

Той факт, що дані знаходяться в ланцюжку, дуже важливий (примітка: розміщення даних «на IPFS» не працюватиме, оскільки IPFS не забезпечує перевірку рівня консенсусу, що немає гарантії, що ці дані доступні, тобто дані повинні бути зберігається в блоках). У двох схемах розширення Плазми та попереднього каналу дані та обчислення повністю розміщуються в мережі другого рівня. Коли мережа другого рівня взаємодіє з Ethereum, усі дані транзакцій у ланцюжку другого рівня не включаються. стан З точки зору машини, тобто кожна зміна стану ланцюга Plasma не включена. Це призведе до того, що якщо Ethereum буде відокремлено від мережі другого рівня, такої як Plasma, він не зможе відновити попередні зміни стану.Тому доступність даних Ethereum дуже залежить від захисту даних Plasma.

Механізм зведення

Щоб забезпечити доступність даних, ринок вибирає Rollup, тож як працює Rollup?

Рисунок 4 Корінь стану в контракті L1 | Джерело

У дизайні Rollup у головному ланцюзі є контракт Rollup, який зберігає корінь стану. Цей корінь стану можна розглядати як оновлену версію кореня Merkle дерева Merkle, який зберігає баланс рахунку (тобто свого роду стан), код контракту та іншу інформацію. На малюнку 4 показано корінь стану, що зберігається в контракті Rollup. .

Вузол L2 виконує три основні функції: по-перше, визначає, які транзакції слід запакувати першими (зазвичай цей тип вузла або клієнта називають секвенсором секвенсора), по-друге, він повинен надати підтвердження для кожного запакованого даних і, нарешті, надіслати його до контракт L1 The Rollup підтверджується цим контрактом. На малюнку 5 показано роль секвенсора в L2.

Малюнок 5 Секвенування, перевірка та подання партії є основними функціями фази L2 | Джерело

Зокрема, L2 може передавати пакет даних (пакет) на L1. Ці дані можуть бути дуже стиснутими колекціями транзакцій або змінами стану після виконання контракту, а також включати корінь стану, що зберігається в контракті L1, і новий корінь після стану ( post-state root), отримані після обробки L2 даних. Договір за цими даними перевіряє правильність післядержавного корінця. Після проходження перевірки пакет даних буде підтверджено на рівні L1, завершуючи процес у ланцюжку від L2 до L1.

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

ZK Rollup і Optimistic Rollup

ZK Rollup використовує докази криптографічного протоколу, такі як ZK-SNARK або ZK-STARK, щоб перевірити правильність кореня пост-стану після виконання пакета. Незалежно від обсягу розрахунку в L2, ZK Rollup може швидко перевірити в ланцюжку L1.

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

На малюнку 6 узагальнено порівняння переваг і недоліків Optimistic Rollup і ZK Rollup. Тут важливо зазначити, що ZK Rollup є кращим у TPS і має значну перевагу в циклах відшкодування. Однак його недоліками є сумісність з EVM і споживання обчислень на рівні L2:

1. Проекти Optimistic Rollup, такі як Optimism і Arbitrum, використовують OVM і AVM відповідно, і їх віртуальні середовища в основному такі ж, як EVM, тому вони можуть безпосередньо перенести контракти L1 на L2 для розгортання. Однак у ZK Rollup досить складно використовувати ZK-SNARK для підтвердження загального виконання EVM, оскільки EVM не розроблено відповідно до математичних вимог розрахунку підтвердження ZK, тому необхідно трансформувати певний тип клієнта EVM для використання Технологія ZK для перевірки транзакцій і контрактних операцій.

2. У той же час, навіть після відповідного перетворення, робота ZK все ще потребує значної обчислювальної потужності, тому ZK Rollup не є таким ефективним, як Optimistic Rollup у ефективності рівня L2.

3. ZK Rollup забезпечує краще стиснення даних, ніж Optimistic Rollup, тому він може надсилати менші дані на L1.

4. Оскільки процес перевірки доказів у ZK є швидшим і має вищу щільність партії, ZK Rollup є нижчим у споживанні розрахунків шару L1. Можна зрозуміти, що оплата вузлів на L2 значно знижує вимоги до вузлів L1, тим самим значно покращуючи масштабованість рівня L1.

Рисунок 6 Порівняння двох методів зведення | Джерело:

**ZK Rollup чи zkEVM Rollup? **

Хоча ZK Rollup виглядає привабливо, у фактичному розгортанні є багато труднощів. Наразі ZK Rollup все ще має значні обмеження, тоді як Optimistic Rollup все ще залишається основним рішенням. Більшість реалізованих ZK Rollups також створені на замовлення для деяких конкретних програм.

Як розуміти налаштований ZK Rollup? Розробники створюють схеми для окремих програм (ASIC) для різних програм DApps, таких як Loopring, StarkEx rollup і zkSync 1.0, які підтримують певні типи платежів, обмін токенів або трансляцію NFT. Проте конструкція їхніх схем вимагає високого рівня технічні знання, які Це призводить до поганого досвіду розробника. Взявши як приклад певний тип платіжних даних, вузол надсилає дані транзакції секвенсору, а секвенсор пакує їх у пакет і надсилає вузлу, який подає підтвердження як загальнодоступний вхід, процес підтвердження та договір. процес виконання на віртуальній машині Це не має жодного відношення, ZK відповідає лише за підтвердження зведеного обчислення та процесу стиснення конкретного результату виконання.

А zkEVM Rollup представляє можливість зведення результатів роботи віртуальної машини. Під час виконання смарт-контракту загального призначення на рівні L2 необхідно довести дійсність переходу стану до та після виконання контракту, а також необхідне віртуальне середовище для підтримки роботи алгоритму ZK. Таким чином, значення zkEVM полягає в тому, щоб запустити контракт, вивести остаточний стан, підтвердити дійсність процесу виконання контракту та подати записи транзакцій, записи облікового запису та дані запису зміни стану разом у зведеному вигляді. Рівню L1 потрібно лише швидко перевірити доказ, накладні витрати невеликі, і немає необхідності запускати контракт знову.Рис.7 яскраво ілюструє роль zkVM. Слід зазначити, що zkEVM насправді є віртуальною машиною, схожою на EVM, яка працює на рівні L2, тож точнішим терміном є віртуальна машина з нульовим знанням, zkVM, але всі підкреслюють, що вона сумісна з Ethereum, і називають її zkEVM.

Рисунок 7 Діаграма, що ілюструє zkVM | Джерело

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

ЧАСТИНА 4 Огляд зведеного проекту zkEVM

У першій половині 2023 року стрімко з’являться різноманітні проекти zkEVM, звертаючи увагу на які автор в основному акцентує увагу на таких аспектах:

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

2. Фактична взаємодія проекту: через взаємодію з тестовою (основною) мережею тощо суб’єктивно відчуйте мережевий TPS, час підтвердження однієї транзакції тощо та мати інтуїтивне відчуття продуктивності мережі.

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

4. Архітектура zkEVM Rollup: порівняно з zkEVM, загальні проекти розкриватимуть свою архітектуру Rollup у офіційних документах та інших технічних документах, і загальна різниця менша, але слід звернути увагу на загальний ступінь децентралізації.

5. Екологічність роботи: кількість користувачів проекту, ступінь активності, функціонування та інкубація екології програми в ланцюжку, а також підтримка спільноти розробників є показниками, які м’яко відображають роботу проекту.

6. Інвестиційно-фінансова ситуація.

У цій статті проект розглядається більше з точки зору перших чотирьох пунктів і приділяється більше уваги загальній архітектурі zkEVM Rollup з технічного рівня.

Прокручування

Команда Scroll, заснована в 2021 році, прагне розробити еквівалент EVM ZK Rollup для масштабування Ethereum. Майже два роки Scroll працює з командою Privacy and Scaling Explorations та іншими учасниками відкритого коду над публічним створенням зведеного пакета, сумісного з байт-кодом. .zkEVM. Наприкінці лютого компанія Scroll оголосила, що її тестова мережа Alpha тепер працює на Goerli. Будь-який користувач може брати участь у технічному тестуванні без дозволу. Середній час блокування тестової мережі становить 3 секунди. Уже є понад 20 мільйонів транзакцій і більше 1,5 млн блоків і більше 4 млн інтерактивних адрес. У той же час Scroll також відкрив інтерфейс екосистеми веб-сайту 11 квітня.

Судячи з нещодавнього оприлюднення інформації, Scroll постійно рухається вперед на шляху еквівалентності Type 2 EVM. Нещодавно Scroll завершив сумісну розробку всіх кодів операцій EVM і перебуває в процесі аудиту.У той же час, наступною метою є забезпечення сумісності з транзакціями EIP2718.

З точки зору технічної архітектури, архітектура Scroll є відносно традиційною, тому тут буде представлено її детально. Як показано на малюнку 8, він в основному розділений на дві частини: основною частиною є zkEVM, який використовується для підтвердження правильності виконання EVM у L2; але щоб перетворити zkEVM на повний ZK Rollup на Ethereum, повний L2 має бути побудований навколо архітектури zkEVM. Зокрема, існуюча тестова мережа Scroll Alpha складається з Scroll Node, Bridge Contract і Rollup Contract:

Рисунок 8. Загальна архітектура згортання прокрутки | Джерело

1. Вузол прокрутки: складається з секвенсора, ретранслятора та координатора.

a) Секвенсор, так званий секвенсор, відкриває JSON-RPC для користувачів і програм, читає транзакції в пулі транзакцій і генерує блоки L2 і корені стану. На цьому етапі вузли Sequencer Scroll централізовані, і вони будуть поступово децентралізовані в майбутніх оновленнях.

b) Координатор відповідає за зв’язок між Roller і Scroll Node Коли новий блок генерується в Sequencer, Roller у пулі випадковим чином вибирається для генерації доказів.

c) Ретранслятор відстежує контракт Bridge і Rollup Contract у ланцюгах Ethereum і Scroll. Зведений контракт гарантує доступність даних L2 на рівні L1 і гарантує, що блок L2 може бути відновлений на рівні L1.Після того, як блок, надісланий рівнем L2, буде перевірено зведеним контрактом на рівні L1, блок досягне завершеності на рівні L2. Незмінний стан . Містовий контракт відповідає за обмін даними між дволанцюжковими контрактами під час перетину ланцюжків, надсилання довільних повідомлень в обох напрямках або виконання операцій застави активів і виведення коштів під час перетину ланцюжків.

Рисунок 9 2. Роликова мережа | Джерело

1. Мережа Roller: Roller має вбудований zkEVM, який діє як перевірка в мережі та відповідає за генерацію доказів дійсності для ZK Rollup, як показано на малюнку 9.

a) Roller спочатку перетворює трасування дії, отримане від координатора (тобто, які конкретні операції було виконано контрактом і які адреси задіяно) у свідків ланцюга.

b) Він генерує докази для кожної схеми zkEVM і, нарешті, об’єднує ці докази з кількох схем ZK.

StarkWare

StarkWare надає рішення для масштабування на основі STARK для забезпечення безпеки L2, швидкості та бездоганної взаємодії з користувачем. Вони підтримують кілька режимів доступності даних. StarkNet є їхньою мережею L2, тоді як StarkEx є зведеною службою перевірки для корпоративних користувачів, а DApps можна створювати на основі служб StarkEx. Однак наразі для конкретних програм DApp можна писати лише налаштовані схеми, а не загальний зведений пакет zkEVM. StarkEx підтримує низку сервісів plug-and-play, зокрема карбування й торгівлю NFT, торгівлю деривативами тощо. З точки зору екології, децентралізована торгова платформа ф'ючерсних контрактів DYDX є лояльним користувачем StarkWare.

StarkNet, строго кажучи, є zkVM. Замість того, щоб створювати схеми ZK для кодів операцій Ethereum, він створив набір більш зручної мови асемблера, AIR (Algebraic Intermediate Representation) і мови високого рівня Cairo. Хоча StarkNet сам по собі несумісний з EVM, він усе ще може бути сумісний з Ethereum за допомогою інших методів, включаючи Kakarot (Kakarot — це zkEVM, написаний Cairo, який є zkEVM, байт-код якого еквівалентний EVM). Наскільки я розумію, StarkNet є відносно централізованим проектом, одна з яких полягає в тому, що він не може бути синхронізований з оновленням безпеки Ethereum. Тому необхідно зосередити науково-дослідний персонал, щоб компенсувати недоліки в безпеці та стежити за розвитком і адаптація ETH нова угода.

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

Однак, з точки зору архітектури, на даний момент в системі є лише один Sequencer (секвенсор), яким керує StarkWare, і є лише один Prover (тобто перевірець, який генерує ZK Proof), який не тільки генерує докази для StarkNet, але також працюють самостійно. Доказ генерації для всіх інших програм у зведеному пакеті StarkEx.

Варіанти ZK Rollup: Validiums і Volitions

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

Але в очах автора Validium не можна вважати суворим ZK Rollup. Це рішення схоже на Плазму, і воно не забезпечує доступність даних на рівні L1, тому його не можна вважати зведеним. Різниця з Plasma полягає в тому, що Plasma встановила «механізм семиденного виходу», подібний до OP Rollup на рівні L2, тоді як Validium використовує засоби ZK для скорочення часу перевірки даних на рівні L2 і не синхронізує даних до L1.

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

zkSync

Подібно до StarkNet, zkSync завжди наполягав на виборі zkVM, який є еквівалентом мови високого рівня, і привернув велику увагу завдяки дуже високій популярності та об’єму блокування. zkSync 1.0 (zkSync Lite) було запущено в основній мережі Ethereum 15 червня 2020 року, досягаючи пропускної здатності транзакцій близько 300 TPS, але він несумісний з EVM. А zkSync 2.0 (zkSync Era) буде запущено 24 березня 2023 року.

Мета zkSync Era — швидше генерувати докази, використовуючи для оптимізації власну віртуальну машину, а не шукати еквівалентність EVM. Він підтримує Solidity, Vyper, Yul і Zinc (внутрішню мову програмування rollup) через потужний компілятор LLVM для реалізації більшості функцій смарт-контрактів. Завдяки власно розробленій віртуальній машині zkSync Era підтримує власну абстракцію облікового запису, тому будь-який обліковий запис може використовувати будь-який токен для оплати.

Крім того, завдяки застосуванню протоколу zkPorter у поєднанні з ZK Rollups і технологією фрагментації пропускна здатність мережі була експоненціально збільшена, досягнувши 20 000+ TPS (подібно до перемикання доступності даних у Volitions).

Загалом zkSync — це екологічно багатий проект рівня 2, який привернув увагу розробників та інвесторів. Незважаючи на те, що нещодавно було кілька випадків повністю невдалих проектів на zkSync, все ще залишається питання, чи зможуть розробники отримати хороший досвід розробки та міграції на еквіваленті мови високого рівня zkVM. Зараз бракує точних звітів про використання на рівні розробника. Якщо розробники мають гарний досвід, який сенс від інших типів zkVM, які прагнуть бути близькими до EVM? Нам ще потрібно більше часу для спостереження.

Полігон zkEVM

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

З точки зору дизайну Rollup, Polygon відрізняється від Scroll тим, що він використовує модель підтвердження ефективності (PoE), щоб мотивувати секвенсор і агрегатор вирішити деякі проблеми децентралізації та валідаторів без дозволу. У двоступеневій моделі сортувальника-агрегатора без дозволу будь-який сортувальник може подати заявку на пакувальні партії, щоб отримати комісію за пакування, але йому потрібно сплатити комісію за газ рівня L1 і внести певну кількість токенів. ; у той же час токени агрегації повинні встановити власні цілі, щоб максимізувати гарантований прибуток для кожного покоління доказів. Крім того, режими Polygon і Volition (ZK Rollup і Validium) також мають глибоко сумісні моделі доступності даних, щоб надавати користувачам різні рівні послуг.

Крім того, Polygon також інвестував значний обсяг роботи в протокол ZK, і ефект також чудовий.У документі вони підсумовують свої технічні переваги, головним чином включаючи такі моменти:

1. Більша сумісність: Polygon завжди наполягав на використанні zkVM, який є еквівалентом EVM, щоб зменшити витрати розробників на міграцію dApps. У той же час, хоча Polygon Miden використовує протокол ZK-STARK, він все ще підтримує виконання контрактів Solidity.

2. Простіша перевірка. Причина, чому ZK Rollup часто критикують, полягає в тому, що для створення доказів дійсності потрібне дороге спеціалізоване обладнання, яке реалізують постачальники та перекладають вартість на користувачів. Polygon ZK Rollup (наприклад, Polygon Zero) має на меті спростити схеми перевірки, щоб пристрої нижчого рівня могли брати участь, наприклад, у тестах створення доказів Plonky2 на ПК споживчого класу.

3. Швидший процес створення та перевірки доказів: Polygon Zero може створити доказ розміром 45 Кб за 170 мілісекунд.

ЧАСТИНА 5 Розрив між теоретичними технологіями та практичними проектами

У цьому дослідницькому звіті головним чином була спрямована наукова популяризація технології ZK і впровадження механізму Rollup, наголошуючи на важливості доступності даних, а також було зроблено певну відмінність у питанні ZK або zkEVM Rollup. Крім того, на основі розрізнення zkVM і zkEVM він також детально сортує відмінності між трьома типами zkEVM і різними типами та пов’язаними доріжками ZK. Нарешті, у поєднанні з кількома вигідними проектами, вони переглянули свої відповідні технічні рамки та існуючу екологію.

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

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

Цінність блокчейна легко побачити, хто б не хотів мати вічний комп’ютер? Але головна проблема полягає в тому, що коли продуктивність цього комп’ютера набагато нижча, ніж у будь-якого сервера навколо нас, і вимагає великих інвестицій ресурсів, навіть якщо споживча вартість набагато нижча за наші вхідні витрати, як «суспільний продукт» , все ще Чи можуть усі взяти участь?

Коли ми вже маємо продукти з багатьох країн, товариств і навіть окремих осіб, за яких обставин ми готові ігнорувати високу вартість використання та прагнути до результату «завжди онлайн, завжди правильно»? Я вважаю, що індустрія блокчейнів має подумати про це сьогодні. Технологія Rollup може технічно покращити цю проблему, але все ще існує велика кількість проблем, які потрібно залишити для вирішення бурхливому ринку.