Детальне пояснення архітектури zkSync та її подібності та відмінності з OP-Stack

Автор: xpara, Чотири стовпи; переклад: Jinse Finance xiaozou

Ключові моменти:

Matterlabs, компанія-розробник zkSync, працювала над розробкою свого унікального zkEVM і створенням чудових продуктів.

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

Ми можемо зрозуміти архітектуру zkSync через три ключові рівні zkSync: рівень виконання, рівень розрахунків і рівень доступності даних.

ZK-Stack (основна кодова база zkSync) і OP-Stack можуть мати схожу філософію. Тим не менш, існують чіткі відмінності, які можна побачити з точки зору розробників dapp, основних розробників і бізнес-операторів.

1**, історія розвитку zkSync******

1.1 Коротка історія zkSync

Розробка zkSync почалася в EthCC у 2019 році. На той час це ще була невелика команда, яка займалася спільною розробкою та розгортанням Rollup із zkSNARK. У січні 2019 року вони запустили перевірку концепції, використовуючи zkSNARK для роботи сайдчейну в Ethereum. Відтоді вони зробили децентралізацію основним принципом. Вони зосередилися на зберіганні всіх даних транзакцій в Ethereum і розробили модель з декількома операторами для обробки моделі децентралізації сортувальника.

У червні 2020 року команда досягла значного прогресу, запустивши основну мережу zkSync v1. zkSync v1 є ключовою віхою в розвитку zkSync, що представляє реальну реалізацію його оригінальної концепції в більшому масштабі. Через рік, у червні 2021 року, вони зробили ще один прорив і випустили тестову мережу zkSync 2.0, також відому як Era.

До березня 2023 року повну мережу zkSync було успішно випущено, що стало великим досягненням для команди. Цей розвиток свідчить про те, що платформа досягла високого рівня зрілості та готова до ширшого впровадження. Це випуск першої основної мережі zkEVM, розгорнутої в екосистемі Ethereum Rollup.

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

*** **** *' *** **

Matterlabs, команда розробників, що стоїть за zkSync, залучила значні кошти для просування своєї місії. З останнім раундом серії C у листопаді 2022 року їх загальне фінансування склало 458 мільйонів доларів, що включало кілька раундів і виділені екосистемні кошти, включаючи, наприклад, окремий спеціальний екосистемний фонд на 200 мільйонів доларів, серію C на 200 мільйонів доларів, серію B на 50 мільйонів доларів. на чолі з a16z, а також серії A та посівного раунду за 8 мільйонів доларів.

· Початковий раунд: у початковому раунді Matterlabs отримала 2 мільйони доларів США від PlaceholderVC, Hashed та інших інвесторів. Цей ранній фінансовий стимул забезпечив необхідну основу для їх роботи, щоб почати проект zkSync.

Серія A: після початкового раунду Matterlabs залучила додаткові 6 мільйонів доларів США в рамках фінансування серії A. Цей новий приплив капіталу дає поштовх для просування їхніх досліджень і розробок і наближає zkSync до кінцевої мети.

Серія B: Matterlabs набирає обертів, оскільки їм вдалося зібрати 50 мільйонів доларів у раунді серії B, головним чином під керівництвом a16z.

· Серія C: Раунд фінансування Matterlabs C становить 200 мільйонів доларів.

Нарешті, на додаток до вищевказаних інвестиційних раундів, Matterlabs запустила спеціальний екосистемний фонд на 200 мільйонів доларів. Цей фонд спрямований на сприяння зростанню та розвитку ширшої екосистеми zkSync.

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

2**、Поточний статус екосистеми zkSync**

2.1 Загальний стан

Протягом багатьох років zkSync досяг значного прогресу в розвитку. У грудні 2020 року zkSync v1, тепер zkSync Lite, досяг рубежу в розробці, перевищивши 1 мільйон доларів у загальній заблокованій вартості (TVL). Відтоді TVL екосистеми zkSync зріс експоненціально. На даний момент TVL zkSync перевищив 650 мільйонів доларів, що робить його третім за величиною зведеним пакетом L2 в екосистемі Ethereum.

До червня цього року zkSync мав кілька вражаючих ключових показників. Хоча zkSync трохи поступався Arbitrum у червні, він посів перше місце в TPS. Він має найшвидший темп зростання TVL і лідирує за загальними виплатами комісій на рівні 1.

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

2.2 Основні елементи

2.2.1 Гроші

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

Argent має унікальний дизайн режиму безпеки, навіть якщо мобільний телефон користувача втрачено або вкрадено, він також може захистити активи користувача. Модель безпеки включає такі функції, як біометрична автентифікація, соціальне відновлення та гаманці смарт-контрактів у мережі. V God, засновник Ethereum, також сказав, що Argent — це гаманець із мультипідписною безпекою та функціями соціального відновлення.

2.2.2 SyncSwap

SyncSwap — це найбільший протокол DeFi в епоху zkSync. Це DEX на основі AMM, який надає різні важливі функції в дизайні AMM. Він надає пул AMM для різних токенів, важливі властивості яких наведені нижче.

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

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

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

2.2.3 Tevaera

Ігрова екосистема Tevaera привносить у світ ігор унікальне поєднання пригод і технологій. Teva Games пропонує ігри різних жанрів, дії яких відбуваються в природному середовищі та пов’язані центральною сюжетною лінією персонажів Guardian. Перша багатокористувацька гра дебютує з випуском Tevaera 2.0, пропонуючи захоплюючий ігровий процес, включаючи оновлення на крипто-тематику та кілька режимів гри.

Ігрова інфраструктура мережі, що складається з Teva Core, Teva Chain, Teva Dex і Teva Market, ще більше покращує екосистему.

· Teva Core — це розширений ігровий фреймворк для кількох гравців.

· Teva Chain — це ігровий гіперланцюг третього рівня, який полегшує перехід до ігор із повним ланцюгом.

· Teva DEX робить внесок у стабільну економію гри завдяки автоматичному dex ігор.

· Teva Market дозволяє карбувати та торгувати унікальними персонажами NFT.

3**, архітектура zkSync**

zkSync Era — це протокол рівня 2, призначений для вирішення проблеми масштабованості Ethereum за допомогою структури зведення без знань (ZK). Розроблена Matter Labs, це платформа zk-rollup, орієнтована на потреби користувачів. Платформа розроблена таким чином, щоб бути широко сумісною з віртуальною машиною Ethereum (EVM) у користувальницькій віртуальній машині, оптимізованій для доказів із нульовим знанням.

Роботу зведеного пакета zkSync можна підсумувати в такі етапи:

(1) Спочатку транзакції або пріоритетні дії генеруються користувачами.

(2) Згодом оператор бере на себе відповідальність за обробку запиту користувача. Після успішної обробки оператор створює операцію зведення та включає її в блок.

(3) Після того, як блок завершено, оператор надсилає його до смарт-контракту zkSync у формі подання блоку. Варто зазначити, що смарт-контракт перевіряє частину логіки виконання певних зведених пакетів.

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

У цьому розділі ми розглянемо, як працює zkSync, зосереджуючись на трьох основних рівнях:

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

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

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

3.1 Рівень виконання

3.1.1 Рівень виконання віртуальної машини

Він працює на type4 zkEVM, що означає, що він бере код смарт-контракту, написаний мовою високого рівня (наприклад, Solidity, Vyper), а потім компілює його в мову, зручну для zk-SNARK.

Крім того, унікальною особливістю zkSync Era є те, що він використовує компілятор на основі LLVM, який з часом дозволить розробникам писати смарт-контракти на C++, Rust та інших популярних мовах.

Фреймворк LLVM — це компілятор для побудови інструментальних ланцюжків мови смарт-контрактів. Його високорівневе проміжне представлення (IR) дозволяє розробникам проектувати, розгортати та вдосконалювати ефективні функції, специфічні для мови, одночасно використовуючи переваги широкої екосистеми LLVM.

У встановленому інструментальному ланцюжку LLVM обробляє LLVM IR, запроваджує повну оптимізацію та, нарешті, передає оптимізоване IR генератору коду серверної частини zkEVM.

3.1.2 Огляд рівня виконання

У zkSync Core App (основна програма) відіграє ключову роль в управлінні рівнем виконання.

Його основним обов’язком є відстеження депозитів або пріоритетних операцій смарт-контрактів L1. Цей механізм має вирішальне значення для забезпечення бездоганної інтеграції zkSync з мережею Ethereum, оскільки всі зміни, ініційовані мережею Ethereum, необхідно відстежувати та відображати в середовищі zkSync Layer 2 (L2).

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

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

Після виконання транзакції Core App генерує блок ланцюжка. Ці блоки складаються з виконаних і перевірених пакетів транзакцій. Потім Core App надсилає ці блоки та докази до смарт-контракту L1. Цей процес забезпечує синхронізацію стану ланцюга L1 Ethereum із ланцюгом zkSync L2.

Для підтримки безперебійної взаємодії між додатками на основі Ethereum він надає сумісний з Ethereum web3 API. Це робить zkSync більш доступним і зручним для розробників і користувачів, які мають досвід роботи з екосистемою Ethereum.

3.2 Розрахунковий рівень

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

(1) Контракт виконавця: цей контракт отримує блокові дані від валідаторів і zk-докази переходів станів у zkSync.

(2) Контракт перевірки: це логічний контракт, який дозволяє системі перевіряти блокові дані та докази zk, надані контрактом виконавця.

3.2.1 Договір виконавця

Функція proveBlocks відіграє центральну роль у забезпеченні цілісності та безпеки системи zkSync. Його основним завданням є перевірка доказів zk-SNARK надісланих блоків. Ось короткий опис того, як це працює:

По-перше, proveBlocks гарантує, що блоки перевіряються в правильному порядку. Він робить це, перевіряючи, чи є попередній отриманий блок наступним блоком у послідовності блокчейну, який потрібно перевірити.

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

Потім функція починає створення масиву proofPublicInput, який стає загальнодоступним вхідним значенням для процесу перевірки доказу zk-SNARK. Номер блоку для кожного зафіксованого блоку міститься в цьому масиві.

Потім, використовуючи масив proofPublicInput і деякі збережені параметри, функція перевірить доказ zk-SNARK. Це схоже на вирішення головоломки, всі деталі повинні ідеально з’єднуватися.

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

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

У двох словах, функція proveBlocks діє як пильний привратник, забезпечуючи перевірку блоків у правильному порядку, забезпечуючи точність доказів zk-SNARK і відповідно оновлюючи стан системи. Його мета — запобігти виконанню недійсних блоків, забезпечуючи загальну безпеку та цілісність системи zkSync.

3.2.2****Договір верифікатора

Контракт верифікатора є місцем для реалізації наведеної вище логіки перевірки. Він діє як охоронець для zkSync, перевіряючи докази zk-SNARK для перевірки надісланих даних. Договір валідатора використовується для перевірки дійсності даних, надісланих до zkSync.

Контракт верифікатора зберігає «ключ перевірки», який використовується для перевірки доказів zk-SNARK. Щоразу, коли zkSync хоче зафіксувати оновлення, він генерує підтвердження zk-SNARK і передає його в контракт валідатора через контракт виконавця.

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

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

3.3 Рівень доступності даних

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

3.3.1 zkPorter

zkSync запустив рішення доступності даних поза мережею під назвою "zkPorter". Інструмент призначений для інтеграції з системою зведення zkSync, полегшуючи взаємодію між зведеннями та обліковими записами zkPorter. Щоб забезпечити безпеку даних у zkPorter, увімкнено «опікунів» — осіб, які розміщують токени zkSync і перевіряють доступність даних, підписуючи блоки.

zkPorter працює як внутрішній консенсус-протокол, що сприяє значній пропускній здатності транзакцій. Для порівняння, стандартний режим ZK Rollup у zkSync 2.0 здатний обробляти приблизно від 1000 до 5000 транзакцій на секунду (TPS). zkPorter може керувати від 20 000 до 100 000 TPS залежно від складності транзакції.

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

Крім того, zkSync 2.0 полегшує взаємодію, дозволяючи плавно перемикатися між обліковими записами ZK-rollup і zkPorter. Фундаментальна відмінність між zkPorter і Starkware Volition полягає у визначенні доступності даних: у zkPorter це рішення приймається на основі облікового запису, тоді як у Volition це рішення приймається на основі індивідуальної транзакції в межах облікового запису, створеного на.

4**、стек ZK і стек OP**

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

Загальні особливості OP-Stack і ZK-Stack такі:

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

Взаємодія: концепцію гіперланцюга Hyperchain від ZK Stack можна легко підключити до надійної мережі з низькою затримкою та спільною ліквідністю. Крім того, OP-Stack передбачає концепцію Superchain для з’єднання всіх ланцюжків на основі OP-Stack.

· Децентралізація: щоб досягти більш децентралізованої мережі та спільноти, як OP-Stack, так і ZK-Stack чітко запропонували план децентралізації в нещодавній дорожній карті. Цей крок не тільки підвищує стійкість мережі, але й забезпечує більш справедливий розподіл влади та контролю.

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

(1) Розробники Dapp

(2) Основні розробники

(3) Бізнес

4.1****Перспектива розробника Dapp

4.1.1 Еквівалентність EVM

Розгортання EVM OP-Stack: EVM OP-Stack реалізовано шляхом внесення незначних змін у geth Ethereum, що робить систему майже повністю сумісною з EVM. З іншого боку, ZK-Stack містить деякі зміни в кодах операцій EVM, і деякі коди операцій ще не підтримуються. Незважаючи на ці зміни, вплив був мінімальним, і проекти були ретельно протестовані та підтверджені в реальному світі.

Однак траплялися інциденти через еквівалентність ZK-Stack не-EVM. Яскравим прикладом є 921 ETH, які потрапили в смарт-контракт, оскільки контракт використовує функцію передачі. Ця проблема була ефективно вирішена.

4.1.2 Абстракція рідного облікового запису

На відміну від ERC-4337, архітектура ZK-Stack включає функцію нативної абстракції облікового запису (AA). У такій системі, як ERC-4337, необхідно мати окремий пул UserOps, щоб дозволити абстракцію облікових записів у мережі.

4.1.3 Підтримка конфіденційності

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

4.2 Основна точка зору розробника

4.2.1 Робота з інфраструктурою: OP-Stack більш інтуїтивно зрозумілий

Робота: і zkSync, і OP-Stack використовують секвенсор для координації транзакцій і зберігання даних в Ethereum. Однак для роботи zkSync потрібен прівер. Ця програма перевірки обробляє згенеровані сервером блоки та пов’язані метадані для створення доказів дійсності з нульовим знанням. На відміну від цього, OP-Stack не вимагає окремої складної інфраструктури для участі в випробувальній грі.

4.2.2 Альтернативи ВМ: ZK-Stack має більше можливостей для надання різноманітних опцій

zkSync працює з компілятором LLVM, який перекладається на байт-код zkEVM, демонструючи потенціал для створення середовищ виконання з використанням інших мов, таких як C++.

4.2.3 Доступність даних: ZK-Stack пропонує кілька варіантів

Рівень доступності даних OP-Stack в основному покладається на Ethereum, де зберігається вся інформація про транзакції та вихідні корені стану. Це призводить до високої вартості експлуатації ланцюга OP-Stack. Однак були спроби компенсувати цю вартість шляхом зберігання даних транзакцій у Celestia DA.

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

4.3 Бізнес-перспектива: витрати та вигоди

Сьогодні запуск незалежних зведених пакетів є життєздатним варіантом, особливо тому, що програмне забезпечення з відкритим кодом, таке як ZK-Stack і OP-Stack, розробляється та підтримується публічно. Крім того, платформи Rollup-as-a-Service (RaaS), такі як Caldera та Conduit, значно спрощують процес.

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

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

Нижче наведено деякі з основних витрат і переваг:

4.3.1 Вартість

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

· Вартість роботи сортувальника L2.

Вартість доказів: для zk це вартість створення та перевірки доказів; для доказів шахрайства це вартість перевірки доказів.

4.3.2 Переваги

· Комісії за транзакцію L2

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

5 Висновок

Matterlabs працювала над розробкою zkEVM і досягла в цьому значного прогресу. Незважаючи на неповну сумісність з EVM (Type4 EVM), використання LLVM, здається, має великий потенціал. Наступним етапом планів Matterlabs є випуск ZK-Stack, кодової бази, яка дозволить розробникам використовувати надійну кодову базу для створення власних зведених пакетів. Інструмент обіцяє явні переваги перед OP-Stack, особливо щодо захисту конфіденційності та масштабованості.

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

Я сподіваюся, що обидва проекти процвітатимуть і що створення з відкритим кодом і спільні дорожні карти стануть нормою у просторі web3.