Огляд Rollup

Rollup - це категорія рішень масштабування у другому рівні блокчейну. У схемах Rollup оператори проекту запускають відносно незалежну платформу другого рівня під розширеним головним ланцюгом (тобто рівень 1). Користувачі можуть виконувати контракти або передавати токени на платформі другого рівня.

Безпека платформи рівня 2 гарантується блокчейном рівня 1, на який вона покладається. Коли новий блок генерується на рівні 2, інформація про транзакцію з блоку рівня 2, а також корінь стану після транзакції рівня 2 об'єднуються як зведена транзакція та публікуються в ланцюжку рівня 1. Фактичне виконання транзакцій і зміни стану обробляються на платформі рівня 2 під основним ланцюгом, і рівню 1 потрібно лише перевірити правильність переходів станів рівня 2. Оскільки вартість перевірки правильності переходу стану набагато нижча, ніж виконання цих транзакцій на рівні 1, рівень 2 може досягти розширення платформи рівня 1. Платформа рівня 2 може запропонувати вищу пропускну здатність транзакцій і нижчі транзакційні витрати порівняно з рівнем 1, зберігаючи при цьому еквівалентну безпеку.

У порівнянні з іншими схемами позаштучних транзакцій, Rollups мають дві характеристики:

• Доступність даних держави для другого рівня вирішується шляхом їх збереження на основному ланцюгу. Платформа другого рівня записує всю інформацію про транзакції або повні зміни стану другого рівня в блоках на основному ланцюжку. Якщо стан другого рівня буде втрачено, будь-хто може відновити втрачений стан з інформації, збереженої на основному ланцюжку.
• У схемі Rollup зміни кореня стану Layer 2, які упаковуються та зберігаються на головному ланцюжку, потрібно перевірити якимось чином на головному ланцюжку. Після підтвердження стан Layer 2 буде заблокований на головному ланцюжку Layer 1. Таким чином, за умови безпечної схеми верифікації Layer 2 може насолоджуватися таким же рівнем безпеки, як Layer 1.

На основі методів верифікації оновлень стану Layer 2 головний ланцюг наразі існують два основних типи технологічних рішень Rollup. Один з них - це Оптимістичний Rollup. У цьому типі схеми контракт головного ланцюга не перевіряє безпосередньо новий стан, наданий Layer 2. Замість цього для кожного нового стану підготовлюється період виклику. Оскільки Rollup подає всю інформацію про транзакції на головний ланцюг та робить її загальнодоступною, будь-хто може перевірити оновлення стану (особливо, коли оновлення стосується їх власного гаманця). Якщо новий стан є неправильним, перевірник може згенерувати доказ про шахрайство проти цього неправильного стану та подати його протягом періоду виклику, тим самим анулюючи неправильне оновлення стану.

Іншим типом рішення Rollup є zk Rollup. У цьому типі схеми після виконання оновлення стану Layer 2 оператор Layer 2 повинен надати доказ нульового знання правильності оновлення стану та подати його до головного ланцюга разом з оновленням стану. Контракт на головному ланцюгу перевірить доказ, щоб визначити правильність оновлення стану.

У порівнянні зі схемою Оптимістичного Rollup, zk Rollup не вимагає тривалого періоду викликів для підтвердження транзакцій на 2-му рівні та може бути підтверджений швидше. Крім того, zk Rollup не ґрунтується на припущенні, що завжди будуть чесні перевіряючі в мережі, які своєчасно будуть надсилати докази шахрайства, коли воно станеться. Однак в той же час zk Rollup також стикається з проблемами, такими як високі обчислювальні витрати технології доказів з нульовим відомості, складність і складність в розробці, що заважають практичному впровадженню технології zk Rollup в Rollups. Зі зростанням розвитку технології доказів з нульовим відомості протягом останніх двох років ці перешкоди поступово подолуються. Технологія zk Rollup починає займати все більшу частку ринку 2-го рівня.

Як показано на малюнку нижче, в масштабуванні у рівні 2 шару Rollup zkRollup вже займає більше половини території і швидко розвивається.

Джерело зображення

Дані отримано: 18 січня 2024 року

Від спеціалізованого zkRollup до загального zkRollup

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

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

У непризначених для загального використання проектах zkRollup (наприклад, у zkSync Lite, який посідає 8-е місце на зазначеній вище діаграмі), користувачі можуть виконувати лише декілька видів операцій з транзакціями, таких як перекази FT (фунгібельних токенів), платежі, обміни та перекази NFT (нефунгібельних токенів). Логіка транзакцій для цих операцій може бути визначена та реалізована лише власниками проекту.

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

Чому спеціалізовані zkRollups не дозволяють користувачам розгортати та використовувати власні смарт-контракти? Це повертає нас до архітектури доведення самого zkRollup.

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

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

Принципи впровадження zkVM

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

Вступ до доказів нульового знання

Докази з нульовим знанням у zkRollup служать для того, щоб довести, що транзакції на рівні 2 були виконані правильно, і що стан рівня 2 був оновлений правильно.

Для досягнення цієї мети схемі zkVM потрібно довести, що будь-який смарт-контракт, розгорнутий на рівні 2, був виконаний правильно. Перед введенням принципів zkVM нам потрібно обговорити роль доказів у нульовому знанні та їх роботу.

Чому потрібні докази з нульовими знаннями

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

Zero-knowledge proofs have three core properties:

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

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

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

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

Процес доказів з нульовими знаннями

Далі ця стаття використає простий розрахунок нижче як приклад для пояснення процесу доказів нульового знання.

c=a²+b+5

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

Під час доведення доказувач спочатку вибирає значення для a та b відповідно як вхідні дані та обчислює значення c. Тут ми встановлюємо a = 3, b = 2, тоді c = 16. Після завершення всіх обчислень доказувач може згенерувати доказ нульового знання для цих значень та операцій.

Після завершення доказу доводчик надасть перевірнику відкриті вхідні дані доказу (тобто значення a та c), а також доказ нульового відома.

Отримавши доказ, верифікатор може, підтвердивши доказ нульового знання, переконатися, що доведувач використовував секретний ввід b, який робить вищезазначену формулу вірною, коли a = 3 і c = 16 (тобто відкриті значення вводу), і не може отримати жодної інформації поза відкритими вводами (a = 3, c = 16).

Наступна частина статті розповість про конкретний процес доведення. Коли нам потрібно довести обчислення за допомогою методу доказу у нульовому знанні, спочатку нам потрібно представити обчислення у вигляді арифметичної схеми, яку може прийняти алгоритм доказу у нульовому знанні. Арифметичні схеми є представленнями обчислення, що є завершеними з точки зору Тьюрінга. Як із назви, арифметична схема - це обчислювальна схема, яка складається з воріт, які виконують арифметичні операції. У нашому прикладі результат перетворення показаний на малюнку. Ви можете помітити, що крім відкритих введених a і c та секретного введення b, про яке ми згадували, є ще два додаткові значення, d і e. Це проміжні змінні, які використовуються у процесі обчислення.

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

Ми можемо розглядати арифметичне коло як дві частини: одна частина - це всі числові значення, які зустрічаються в колі, а інша частина - це взаємозв'язки (обмеження) між цими значеннями. Зазвичай ми називаємо загальнодоступні вхідні дані в колі як твердження (у нашому прикладі, a та c), а всі інші значення, включаючи секретні вхідні дані (b) та проміжні змінні (d та e), як свідчення.

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

Таким чином, логічне входило арифметичної схеми також може бути представлено у наступній формі:

заява:

a,c

свідок:

b,d,e

обмеження:

d = a * a

e = b + 5

c = d + e

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

У фактичних застосуваннях користувачам доказів з нульовим розголошенням потрібно написати логіку, яку вони потребують, до джерела коду zk схеми та згенерувати відповідний VK через перевірку. Цей VK передається верифікатору. Загальнодоступні вхідні дані, доведені доведенням, разом із згенерованим доказом, надсилаються, і верифікатор може перевірити, чи відповідають ці загальнодоступні вхідні дані обмеженням. У цьому прикладі доведучий може згенерувати доказ зі значеннями a, b та c. Верифікатор може перевірити, чи a2 + b дорівнює C без виконання цієї операції.

Обмеження циркулів доказу нульового знання

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

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

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

Візьмемо для прикладу наступну операцію:

якщо (прапорець) {

c = x + x

} else {

c = x * x

}

Коли ця операція перетворюється на арифметичну схему, вона буде перетворена в обмеження, показані нижче. Очевидно, до схеми будуть додані два нових свідки, temp1 та temp2. Крім того, буде обчислено як значення x+x, так і значення x*x.

Тобто в zk-схемі всі гілки та логіка будуть обчислені, чи вони виконуються, чи ні.

temp1 = x + x

temp2 = x * x

c = прапор temp1 + (1-flag)temp2

Через ці обмеження підтримка умовного вибору в ланцюгах доказів з нульовим рівнем доведення є досить складною. Як довести шлях виконання логіки розумного договору з численними варіаціями у доказі з нульовим рівнем доведення є одним із основних викликів віртуальної машини zk.

Доведення виконання будь-якої програми — Доведення універсальної машини стану в схемі

Джерело зображення

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

Ми припускаємо, що ця універсальна машина стану має реєстри загального призначення (A та B) і, додатково, регістр лічильника програм, який зберігає поточний номер інструкції.

Стан реєстрів перед виконанням інструкції

На малюнку нижче показана основна робоча процедура доказу віртуальної машини ZK:

Стан 0 можна вважати початковим станом цієї віртуальної машини перед запуском. Початковий стан, після загальної кількості m інструкцій, досягає кінцевого стану m. Крім початкового стану, у цієї віртуальної машини є дві звичайні вхідні таблиці:

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

На малюнку абстрагується та показується виконавчий процес n-ї інструкції зліва. Стан машини стану, Стан n, переходить до Стану n+1 після виконання n-ї інструкції. Та ж сама схема, після m ітерацій, досягає виконання m інструкцій у vm.

Тут є дві проблеми.

Одне - як виконати різні інструкції в межах фіксованого кола? При виконанні байткоду контракту неможливо визначити, яка n-та інструкція виконується, тому фактична логіка кола тут не може бути визначена.

Друге - як довести, що кількість інструкцій, що виконуються, не є m?

Для першого питання рішенням є впровадження логіки для всіх можливих інструкцій в схемі. Потім використовуйте селектор, заснований на інструкції, щоб вибрати одну з них як наступний стан, схожий на if-else в спеціалізованій схемі, згаданій раніше.

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

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

Доведення основної інструкції

Ось деякі базові обчислювальні інструкції як приклад того, як базові інструкції в схемі доведені:

Джерело зображення

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

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

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

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

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

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

Доведення умовних суджень та стрибки управління потоком

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

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

Спочатку ми вводимо доказ умовного судження:

Беручи оцінку того, чи дорівнює операнд в i-й інструкції нулю як приклад. Ми додаємо допоміжний стан isZero для результату оцінки. Якщо оцінюване значення дорівнює 0, тоді значення допоміжного стану isZero дорівнює 1; якщо оцінюване значення будь-яке інше значення, крім 0, тоді isZero дорівнює 0.

Цей процес обмежений двома формулами на діаграмі.

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

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

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

I/O та складні операції

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

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

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

Джерело зображення: 1 2

Діаграма зліва - це схема архітектури проекту Scroll, а діаграма в нижньому правому куті - це схема архітектури Polygon. Вони обидва використовують схожий підхід, як показано на діаграмі у верхньому кутку.

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

Більше фіксованих складних обчислень, таких як хеш, операції дерева MPT, зовнішні вхідні дані тощо, доведені спеціалізованими схемами.

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

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

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

Контракт L1 повинен лише перевірити цей загальний доказ, щоб підтвердити правильність усього процесу виконання віртуальної машини.

Висновок

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

Однак з розвитком та удосконаленням zk віртуальних машин стало можливим підтримувати виконання довільних смарт-контрактів з повною підтримкою машини Тьюрінга. Потенціал zkRollup буде дійсно реалізований, здійснюючи свою візію розриву трилеми блокчейну.

Відмова:

1. Ця стаття перепечатана з [ZAN], Усі авторські права належать оригінальному авторові [ZAN і AntChain відкривають лабораторії]. Якщо є зауваження до цього повторного надання, будь ласка, зв'яжіться Gate Learnкоманда, і вони оперативно цим займуться.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора та не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат статей, перекладених на інші мови, заборонені.