Web3.com Ventures Оригінальний аналіз досліджень
0xFishylosopher
вступ
«zk-Rollups», мабуть, був найпопулярнішим модним словом Web 3 року. Із запуском основної мережі zk-Sync v2.0 «baby alpha» лише за останні кілька днів це захоплення досягло свого зеніту [1]. Але що насправді означає «zk-Rollups» за всіма цими модними словами? І де працює zk-Sync? У цій статті я спробую глибоко зануритися в принципи та практику zk-Rollups, пояснити ключові технічні ознаки zk-Sync v2.0 як проекту та дослідити потенційні майбутні наслідки для цієї довгоочікуваної технології.
Принципи zk-зведення
Навіщо нам взагалі потрібні zk-Rollups? Звичайно, Ethereum чудовий. Але в своєму нинішньому стані мережа принципово є неекономією масштабу. У міру зростання активності мережі ціни на газ стають непомірно дорогими, особливо якщо відбувається сплеск активності мережі одразу. Оскільки за останні кілька років Ethereum набирає популярність у використанні та тязі, його поточна обмежена масштабованість стала ахіллесовою п’ятою мережі.
Ось тут і з’являються «зведені пакети» — зведені пакети Ethereum — це, по суті, «плагін», який надає Ethereum додаткові масштаби масштабованості та таким чином виправляє притаманну йому неекономію від масштабу. Інтуїція, що лежить в основі цієї ідеї, проста. Уявіть, що у вас є 5 речей, які вам потрібно перенести з точки А в точку Б. «Звичайний» спосіб зробити це: переносити річ 1, переносити річ 2 тощо один за одним. Але це, очевидно, повільно та громіздко. «Згортання» — це, по суті, «згортання» всіх 5 предметів в одну сумку, що дозволяє вам здійснити одну поїздку замість 5.
Але є два застереження:
Як переконатися, що зведений пакет може «вмістити» все?
Як переконатися, що зведення не підроблено?
zk-Rollups є одним із провідних типів зведених технологій (іншою є Optimistic Rollups), які використовують «докази з нульовим знанням» для вирішення цих двох проблем. Щоб вирішити ці проблеми, zk-Rollup об’єднує певну кількість транзакцій, виконує обчислення на рівні L2 і надсилає як зміни стану, так і «підтвердження дійсності» верифікатору на рівні L1, який показує, що обчислення виконано з цілісністю. . Цей «доказ дійсності» відбувається у формі «доказу нульового знання», математичного способу сказати комусь, що ви щось знаєте, не кажучи їм, що знаєте ви.
Простим прикладом підтвердження з нульовим знанням є програма для автоматичного оцінювання коду (для домашніх завдань CS). Autograder — це «верифікатор», який надає вам купу випадково згенерованих тестів, а ви — «перевірник», який повинен мати можливість пройти всі тести, щоб довести, що у вас правильний код. При цьому ви не надаєте свій код безпосередньо програмі автогрейдингу. І вуаля, ви щойно провели «Доказ нульового знання», довівши, що ви щось знаєте, не кажучи того, що знаєте. [2]
Наведений вище засіб автоматичної оцінки коду використовує «інтерактивне підтвердження нульового знання», де засіб автоматичного оцінювання та постачальник коду безпосередньо «взаємодіють» один з одним. На відміну від цього, більшість zk-зведених версій використовують математично складніші неінтерактивні докази (такі як zk-SNARK або стислий неінтерактивний аргумент знань із нульовим знанням), що економить час і місце порівняно з інтерактивним доказом. Хоча технічні деталі zk-SNARK виходять за рамки цієї статті, основний принцип проходження тестів залишається тим самим.
Святий Грааль zk-Rollups — це віртуальна машина Ethereum без знань (zk-EVM), яка дозволяє розробникам переносити будь-який смарт-контракт Ethereum без змін у ланцюг zk-Rollup. Але це важко. Оскільки кожна «проблема» потребує різних наборів «тестових прикладів», розробка «алгоритму доказів», який може розв’язати будь-який тестовий приклад, який можна уявити, є технічним вузьким місцем перевірок із нульовим знанням і zk-rollups.
Як стверджує сам Віталік Бутерін:
Загалом, на мою власну думку, у короткостроковій перспективі оптимістичні зведені пакети, ймовірно, переможуть для обчислень EVM загального призначення, а зведені ZK, ймовірно, переможуть для простих платежів, обміну та інших прикладних випадків використання, але в З удосконаленням технології ZK-SNARK середньострокові та довгострокові зведені ZK переможуть у всіх випадках використання. [3]
Таким чином, історично zk-Rollups були лише встановленими технологіями для конкретних випадків використання програми, де «тестові випадки» чітко визначені та обмежені за обсягом. Проте кілька проектів швидко просуваються до «замку на горі» — загального EVM-сумісного алгоритму zk-Rollup. [4]
zk-Sync v2.0
zk-Sync v2.0 — це лише один із багатьох проектів, які зараз ведуться для розробки zk-EVM (інші включають StarkNet, Polygon Hermez і Scroll). На відміну від zk-Sync v1.0, який вимагав від користувачів перебудувати великі розділи своїх кодових баз для перенесення з EVM на zk-Sync, у zk-Sync v2.0 програмісти можуть розгортати свої додатки з незначними змінами або без змін — або як може стверджувати zk-Sync.
На практиці не всі zk-EVM однакові. Існує чіткий компроміс між можливістю компонування (наскільки це близько до оригінальних контрактів EVM) і продуктивністю (як швидко працюватимуть zk-Rollups) [6]. У рамках цього компромісу zk-Sync вирішив повністю оптимізувати продуктивність, таким чином жертвуючи можливістю компонування.
З точки зору Віталіка Бутеріна, існує чотири різні типи zk-EVM, узагальнені в наступній таблиці:
Як стверджує Віталік, у своєму поточному стані zk-Sync v2.0 є типом 4 zk-EVM, який може компілювати контракти, написані Solidity та мовами високого рівня, використовуючи власний компілятор, який відрізняється від EVM. Оскільки zk-Sync має повний контроль над дизайном свого компілятора, вони можуть агресивно оптимізувати швидкість і пропускну здатність. Ціна цього полягає в тому, що деякі ланцюжки інструментів налагодження DApps і EVM можуть бути несумісні з zk-Sync v2.0. По суті, zk-Sync — це та сама автомобільна оболонка, що й Ethereum, але зі зміненим механізмом [5].
Дійсно, у своїй документації для розробників Matter Labs стверджує, що в той час як операції «читання» смарт-контрактів можна інтегрувати без будь-яких змін у коді, операції «запису» смарт-контрактів потребують «додаткового коду» через «фундаментальні відмінності між L1 і L2» [6] . Насправді це трохи вводить в оману. Це не стільки через «фундаментальну різницю» між L1 і L2, скільки через тип zk-зведення, який Matter Labs вирішила використовувати — зведення типу 4. Оскільки zk-Sync — це принципово зведення типу 4, яке використовує інший компілятор і байт-код, це означає, що смарт-контракти мають різні адреси, а інфраструктура налагоджувача, яка покладається на аналіз байт-коду, може не працювати на zk-Sync v2. 0 [7].
У майбутньому zk-Sync може додати більш нативну підтримку байт-коду EVM, що дозволить системі повільно переходити до зведеного типу 3, який підтримує ширший діапазон цих «граничних випадків». Але щоб zk-Rollup Type 4 або Type 3 був успішним у порівнянні з Polygon Hermez і Scroll Labs Type 2, який, по суті, замінює швидкість на ширшу сумісність, мають бути дві важливі передумови. По-перше, існує лише крихітна частка неважливих проектів, несумісних із спеціальним компілятором zk-Sync. По-друге, існує якісна різниця у швидкості виконання zk-Sync порівняно з Type 2 zk-EVM.
На жаль, я особисто вважаю, що це навряд чи так. Будь-яка вдосконалена екосистема розробки спирається на зрілу інфраструктуру «шаффолдингу», включаючи зручні, модульні інструменти для налагодження та тестування. Якщо, як постулює Віталік, значна частина інструментів налагодження, які використовують EVM, не зможе перенести на zk-Sync через відмінності в байт-коді, тоді zk-Sync доведеться розробити власний набір інструментів для тестування та налагодження. Це додаткові накладні витрати, які в кінцевому підсумку можуть перешкодити швидкості впровадження zk-Sync як рішення L2 порівняно з його конкурентами zk-EVM типу 2 з більшою складністю, такими як Polygon Hermez і Scroll.
Майбутнє для zk-Rollups
З багатьма конкурентоспроможними гравцями у боротьбі за zk-EVM, можливо, це лише питання часу, коли ми побачимо повнофункціональну zk-EVM. Але що далі? Дорога корисна лише до тих пір, поки на ній є будівлі; Довгострокова міцність zk-Rollup походить від проектів, які використовують це рішення.
Наразі DeFi, GameFi та мобільні додатки є основними бенефіціарами інфраструктури zk-Rollup. І DeFi, і GameFi — це принципово економія на масштабі, оскільки вони процвітають у середовищі, де ними користується багато людей. Мобільні програми, такі як мобільні гаманці, також відкривають шлюзи для масового споживача, який занадто ледачий (або не може дозволити собі) настільний ПК. Тому використання zk-Rollups для таких ситуацій має великий сенс.
Але це далеко не межа корисності zk-Rollups. Якщо що, це лише початок. zk-Rollups для Ethereum те ж саме, що 5G для Інтернету. Подібно до того, як 5G може створити новий світ додатків і систем Інтернету речей, zk-Rollups також може відкрити шлюзи для «блокчейну речей», дозволяючи цифровим приладам нашого фізичного світу — холодильникам, годинникам, світлофорам тощо — бути доступними. інтегровано зі смарт-контрактами, захищеними на Ethereum.
Одним із найбільших аргументів проти IoT є те, що він дозволить великим технологіям проникнути в наше повсякденне життя. Але з «Blockchain of Things» ми можемо насолоджуватися зручностями IoT, не турбуючись про те, що наші розумні пристрої будуть скомпрометовані в централізованій базі даних. Замість зручності АБО конфіденційності ми можемо мати зручність І конфіденційність. Це світ, який може пообіцяти нам zk-Rollups.
🐦 @0xfishylosopher
📅 31 жовтня 2022 р
Ця інформація є суто освітньою і не повинна розглядатися як фінансова порада. Усі висловлені погляди є поглядами автора і не обов’язково схвалені Web3.com Ventures.
Список літератури
[1] https://blog.matter-labs.io/baby-alpha-has-arrived-5b10798bc623
[2] Адаптовано з https://pages.cs.wisc.edu/~mkowalcz/628.pdf
[3] https://vitalik.ca/general/2021/01/05/rollup.html
[4] https://www.coindesk.com/tech/2022/07/20/the-sudden-rise-of-evm-compatible-zk-rollups/
[5] https://cryptobriefing.com/the-race-scale-ethereum-zkevm-rollups/
[6] https://docs.zksync.io/dev/contracts/#porting-smart-contracts
[7] https://vitalik.ca/general/2022/08/04/zkevm.html