Зведення з нульовим знанням

Роллапи з нульовим розголошенням (ZK-роллапи) — це рішення для масштабування другого рівня, які підвищують пропускну здатність в основній мережі Ethereum, переносячи обчислення та зберігання стану за межі ланцюга. ZK-rollups можуть обробляти тисячі транзакцій в пакеті, а потім розміщувати лише деякі мінімальні підсумкові дані в Mainnet. Ці зведені дані визначають зміни, які повинні бути внесені в стан Ethereum, і деякі криптографічні докази того, що ці зміни є правильними.

Передумови

Вам слід було прочитати й зрозуміти нашу сторінку про масштабування Ethereum та шар 2.

Що таке роллапи з нульовим розголошенням?

Роллапи з нульовим розголошенням (ZK-роллапи) об’єднують (або «згортають») транзакції в пакети, які виконуються поза ланцюгом. Обчислення поза ланцюгом зменшують обсяг даних, які необхідно опублікувати в блокчейні. Оператори ZK-роллапів надсилають зведення змін, необхідних для представлення всіх транзакцій у пакеті, замість того, щоб надсилати кожну транзакцію окремо. Вони також створюють , щоб довести правильність своїх змін.

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

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

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

Як ZK-роллапи взаємодіють з Ethereum?

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

Основна архітектура ZK-роллапу складається з таких компонентів:

Внутрішньоланцюгові контракти: як згадувалося, протокол ZK-роллапу контролюється смартконтрактами, що працюють на Ethereum. Сюди входить основний контракт, який зберігає блоки роллапу, відстежує депозити й контролює оновлення стану. Інший внутрішньоланцюговий контракт (контракт-верифікатор) перевіряє докази з нульовим розголошенням, надані виробниками блоків. Таким чином, Ethereum слугує базовим рівнем, або «рівнем 1», для ZK-роллапу.
Позаланцюгова віртуальна машина (ВМ): хоча протокол ZK-роллапу функціонує на Ethereum, виконання транзакцій і зберігання стану відбуваються на окремій віртуальній машині, незалежній від EVM. Ця позаланцюгова ВМ є середовищем виконання транзакцій у ZK-роллапі та слугує вторинним рівнем, або «рівнем 2», для протоколу ZK-роллапу. Докази дійсності, перевірені в основній мережі Ethereum, гарантують правильність переходів стану в позаланцюговій ВМ.

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

ZK-роллапи покладаються на основний протокол Ethereum для таких цілей:

Доступність даних

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

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

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

Завершеність транзакцій

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

Стійкість до цензури

Більшість ZK-роллапів використовують «супервузол» (оператора) для виконання транзакцій, створення пакетів і надсилання блоків на перший рівень. Хоча це забезпечує ефективність, це збільшує ризик цензури: зловмисні оператори ZK-роллапів можуть цензурувати користувачів, відмовляючись включати їхні транзакції в пакети.

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

Як працюють ZK-роллапи?

Транзакції

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

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

Як ZK-роллапи публікують дані транзакцій в Ethereum

Як пояснювалося, дані транзакцій публікуються в Ethereum як calldata. calldata — це область даних у смартконтракті, що використовується для передачі аргументів у функцію, і поводиться подібно до пам’яті. Хоча calldata не зберігається як частина стану Ethereum, вона зберігається в ланцюзі як частина журналів історіїopens in a new tab ланцюга Ethereum. calldata не впливає на стан Ethereum, що робить її дешевим способом зберігання даних у ланцюзі.

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

Зобов'язання щодо стану

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

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

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

Докази дійсності

Новий корінь стану, який оператор ZK-роллапу надсилає до контракту першого рівня, є результатом оновлень стану роллапу. Скажімо, Аліса надсилає 10 токенів Бобу. Оператор просто зменшує баланс Аліси на 10 і збільшує баланс Боба на 10. Потім оператор хешує оновлені дані облікового запису, перебудовує дерево Меркла роллапу й надсилає новий корінь Меркла до внутрішньоланцюгового контракту.

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

Докази дійсності дають змогу сторонам довести правильність твердження, не розкриваючи самого твердження, тому їх також називають доказами з нульовим розголошенням. ZK-роллапи використовують докази дійсності для підтвердження правильності позаланцюгових переходів стану без необхідності повторного виконання транзакцій в Ethereum. Ці докази можуть мати форму ZK-SNARKopens in a new tab (лаконічний неінтерактивний аргумент знання з нульовим розголошенням) або ZK-STARKopens in a new tab (масштабований прозорий аргумент знання з нульовим розголошенням).

І SNARK, і STARK допомагають засвідчити цілісність позаланцюгових обчислень у ZK-роллапах, хоча кожен тип доказу має свої відмінні риси.

ZK-SNARK

Для роботи протоколу ZK-SNARK необхідно створити загальний довідковий рядок (CRS): CRS надає загальнодоступні параметри для доведення та перевірки доказів дійсності. Безпека системи доведення залежить від налаштування CRS; якщо інформація, що використовується для створення загальнодоступних параметрів, потрапить до зловмисників, вони можуть генерувати неправдиві докази дійсності.

Деякі ZK-роллапи намагаються розв’язати цю проблему, використовуючи церемонію багатосторонніх обчислень (MPC)opens in a new tab за участю довірених осіб для створення загальнодоступних параметрів для схеми ZK-SNARK. Кожна сторона вносить певну випадковість (так звані «токсичні відходи») у конструкцію CRS, яку вони повинні негайно знищити.

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

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

ZK-STARK

Як і ZK-SNARK, ZK-STARK доводять дійсність позаланцюгових обчислень, не розкриваючи вхідних даних. Однак ZK-STARK вважаються вдосконаленням ZK-SNARK через їхню масштабованість і прозорість.

ZK-STARK є «прозорими», оскільки вони можуть працювати без довіреного налаштування загального довідкового рядка (CRS). Натомість ZK-STARK покладаються на загальнодоступну випадковість для налаштування параметрів для створення та перевірки доказів.

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

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

Як працюють докази дійсності в ZK-роллапах?

Створення доказів

Перш ніж приймати транзакції, оператор виконає звичайні перевірки. Це включає підтвердження того, що:

Облікові записи відправника та одержувача є частиною дерева станів.
Відправник має достатньо коштів для обробки транзакції.
Транзакція правильна й відповідає відкритому ключу відправника в роллапі.
Нонс відправника є правильним тощо.

Щойно вузол ZK-роллапу має достатньо транзакцій, він об’єднує їх у пакет і компілює вхідні дані для схеми доведення, щоб скомпілювати їх у стислий ZK-доказ. Сюди входить таке:

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

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

Цей корінь Меркла відображає єдину зміну в стані ZK-роллапу: зміну балансу та нонсу відправника. Це можливо, оскільки доказ Меркла, який використовується для доведення існування облікового запису, використовується для отримання нового кореня стану.

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

Процес повторюється для кожної транзакції; кожен «цикл» створює новий корінь стану після оновлення облікового запису відправника та наступний новий корінь після оновлення облікового запису одержувача. Як пояснювалося, кожне оновлення кореня стану представляє одну частину зміни дерева стану роллапу.

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

Перевірка доказів

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

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

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

Входи та виходи

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

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

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

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

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

ZK-роллапи та сумісність з EVM

На відміну від оптимістичних роллапів, ZK-роллапи не є легко сумісними з віртуальною машиною Ethereum (EVM). Доведення обчислень EVM загального призначення в схемах є складнішим і ресурсомісткішим, ніж доведення простих обчислень (як-от описаний раніше переказ токенів).

Однак прогрес у технології нульового розголошенняopens in a new tab викликає новий інтерес до обгортання обчислень EVM у докази з нульовим розголошенням. Ці зусилля спрямовані на створення реалізації zkEVM, яка зможе ефективно перевіряти правильність виконання програм. zkEVM відтворює наявні опкоди EVM для доведення/перевірки в схемах, що дає змогу виконувати смартконтракти.

Як і EVM, zkEVM переходить між станами після виконання обчислень над деякими вхідними даними. Різниця в тому, що zkEVM також створює докази з нульовим розголошенням для перевірки правильності кожного кроку у виконанні програми. Докази дійсності можуть перевіряти правильність операцій, які торкаються стану ВМ (пам’ять, стек, сховище), і самого обчислення (тобто чи викликала операція правильні опкоди та чи правильно їх виконала?).

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

Як працюють комісії ZK-роллапів?

Сума, яку користувачі платять за транзакції в ZK-роллапах, залежить від плати за газ, так само як і в основній мережі Ethereum. Однак плата за газ працює по-різному на другому рівні та залежить від таких витрат:

Запис стану: існує фіксована вартість запису в стан Ethereum (тобто надсилання транзакції в блокчейн Ethereum). ZK-роллапи зменшують цю вартість, об’єднуючи транзакції в пакети та розподіляючи фіксовані витрати між кількома користувачами.
Публікація даних: ZK-роллапи публікують дані про стан для кожної транзакції в Ethereum як calldata. Витрати на calldata наразі регулюються EIP-1559opens in a new tab, який передбачає вартість 16 одиниць газу за ненульові байти та 4 одиниці газу за нульові байти calldata відповідно. Вартість, що сплачується за кожну транзакцію, залежить від того, скільки calldata потрібно опублікувати для неї в ланцюзі.
Комісії оператора другого рівня: це сума, що сплачується оператору роллапу як компенсація за обчислювальні витрати, пов’язані з обробкою транзакцій, подібно до «пріоритетних комісій (чайових)» за транзакції в основній мережі Ethereum.
Створення та перевірка доказів: оператори ZK-роллапів повинні створювати докази дійсності для пакетів транзакцій, що є ресурсомістким. Перевірка доказів із нульовим розголошенням в основній мережі також коштує газу (~ 500 000 одиниць газу).

Окрім пакетування транзакцій, ZK-роллапи зменшують комісії для користувачів шляхом стиснення даних транзакцій. Ви можете побачити в реальному часі оглядopens in a new tab вартості використання ZK-роллапів Ethereum.

Як ZK-роллапи масштабують Ethereum?

Стиснення даних транзакцій

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

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

Рекурсивні докази

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

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

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

Переваги та недоліки ZK-роллапів

Переваги	Недоліки
Докази дійсності забезпечують правильність позаланцюгових транзакцій і не дають операторам змоги виконувати недійсні переходи стану.	Витрати, пов'язані з обчисленням та перевіркою доказів дійсності, є значними і можуть призвести до збільшення комісій для користувачів роллапу.
Забезпечує більш швидке завершення транзакції, оскільки оновлення стану затверджуються після перевірки доказів дійсності на рівні L1.	Створення EVM-сумісних ZK-роллапів є складним через складність технології нульового розголошення.
Покладається на бездовірні криптографічні механізми для безпеки, а не на чесність стимульованих учасників, як у випадку з оптимістичними роллапами.	Створення доказів дійсності вимагає спеціалізованого обладнання, що може сприяти централізованому контролю над ланцюгом кількома сторонами.
Зберігає дані, необхідні для відновлення позаланцюгового стану на першому рівні, що гарантує безпеку, стійкість до цензури та децентралізацію.	Централізовані оператори (секвенсори) можуть впливати на порядок транзакцій.
Користувачі отримують вигоду від більшої ефективності капіталу та можуть виводити кошти з другого рівня без затримок.	Вимоги до обладнання можуть зменшити кількість учасників, які можуть змусити ланцюг прогресувати, що збільшує ризик заморожування стану роллапу та цензури користувачів зловмисними операторами.
Не залежить від припущень про живучість, і користувачам не потрібно перевіряти ланцюг, щоб захистити свої кошти.	Деякі системи доведення (наприклад, ZK-SNARK) вимагають довіреного налаштування, яке, у разі неправильного поводження, може потенційно скомпрометувати модель безпеки ZK-роллапу.
Краще стиснення даних може допомогти зменшити витрати на публікацію `calldata` в Ethereum і мінімізувати комісії роллапів для користувачів.

Візуальне пояснення ZK-роллапів

Подивіться, як Finematics пояснює ZK-rollups:

Хто працює над zkEVM?

До проєктів, що працюють на zkEVMs відносяться:

zkEVMopens in a new tab - zkEVM — це проєкт, що фінансується Ethereum Foundation для розробки EVM-сумісного ZK-роллапу та механізму для генерації доказів дійсності для блоків Ethereum.
Polygon zkEVMopens in a new tab - це децентралізований ZK-роллап в основній мережі Ethereum, що працює на віртуальній машині Ethereum із нульовим розголошенням (zkEVM), яка прозоро виконує транзакції Ethereum, включаючи смартконтракти з перевірками на основі доказів із нульовим розголошенням.
Scrollopens in a new tab - Scroll — це технологічна компанія, яка працює над створенням нативного рішення zkEVM другого рівня для Ethereum.
Taikoopens in a new tab - Taiko — це децентралізований, еквівалентний Ethereum ZK-роллап (ZK-EVM типу 1opens in a new tab).
ZKsyncopens in a new tab - ZKsync Era — це EVM-сумісний ZK-роллап, створений Matter Labs, що працює на власному zkEVM.
Starknetopens in a new tab - StarkNet — це EVM-сумісне рішення для масштабування другого рівня, створене StarkWare.
Morphopens in a new tab - Morph — це гібридне рішення для масштабування роллапів, яке використовує zk-докази для розв’язання проблеми зі станом другого рівня.
Lineaopens in a new tab — Linea — це еквівалентне Ethereum рішення zkEVM другого рівня, створене Consensys, що повністю узгоджується з екосистемою Ethereum.