Ролапи з нульовим розголошенням

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

Передумови

Ви повинні прочитати та зрозуміти наші сторінки про масштабування Етеріуму та рівень 2 (l2).

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

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

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

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

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

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

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

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

1. Ончейн контракти: Як уже згадувалося, протокол ZK-ролапу контролюється смарт-контрактами, що працюють в Етеріумі. Сюди входить головний контракт, який зберігає блоки ролапу, відстежує депозити та моніторить оновлення стану. Інший ончейн контракт (контракт верифікатора) перевіряє доведення з нульовим розголошенням, надіслані виробниками блоків. Таким чином, Етеріум слугує базовим рівнем або «рівнем 1 (l1)» для ZK-ролапу.

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

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

ZK-ролапи покладаються на основний протокол Етеріуму для такого:

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

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

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

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

Фінальність транзакцій

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

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

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

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

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

Транзакції

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

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

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

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

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

Фіксації стану

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

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

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

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

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

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

Докази дійсності дозволяють сторонам довести правильність твердження, не розкриваючи самого твердження — звідси вони також називаються доведеннями з нульовим розголошенням. ZK-ролапи використовують докази дійсності для підтвердження правильності позамережевих переходів стану без необхідності повторного виконання транзакцій в Етеріумі. Ці докази можуть бути у формі ZK-SNARK (opens in a new tab) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) або ZK-STARK (opens in a new tab) (Zero-Knowledge Scalable Transparent Argument of Knowledge).

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

ZK-SNARKs

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

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

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

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

ZK-STARKs

Як і 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 є те, що вони створюють докази більшого розміру, які дорожче перевіряти в Етеріумі.

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

Генерація доказів

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

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

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

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

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

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

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

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

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

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

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

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

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

• Корінь пакета: Корінь Меркла пакета, отриманий шляхом мерклізації транзакцій у пакеті та хешування кореня дерева.

• Вхідні дані транзакцій: Дані, пов'язані з транзакціями, виконаними як частина надісланого пакета.

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

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

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

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

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

• Доказ Меркла, що доводить включення транзакції користувача на акаунт для спалювання в пакет транзакцій

• Дані транзакції

• Корінь пакета

• Адреса L1 для отримання внесених коштів

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

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

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

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

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

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

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

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

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

2. Публікація даних: ZK-ролапи публікують дані стану для кожної транзакції в Етеріумі як calldata. Витрати на calldata наразі регулюються EIP-1559 (opens in a new tab), який передбачає вартість 16 газу для ненульових байтів і 4 газу для нульових байтів calldata відповідно. Вартість, що сплачується за кожну транзакцію, залежить від того, скільки calldata потрібно опублікувати ончейн для неї.

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

4. Генерація та перевірка доказів: Оператори ZK-ролапів повинні створювати докази дійсності для пакетів транзакцій, що є ресурсомістким процесом. Перевірка доведень з нульовим розголошенням у Головній мережі також коштує газу (~ 500 000 газу).

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

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

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

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

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

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

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

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

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

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

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

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

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

Проєкти, що працюють над zkEVM, включають:

• zkEVM (opens in a new tab) — zkEVM — це проєкт, що фінансується Фундацією Ethereum, для розробки EVM-сумісного ZK-ролапу та механізму генерації доказів дійсності для блоків Етеріуму.

• Polygon zkEVM (opens in a new tab) — це децентралізований ZK-ролап у головній мережі Ethereum, що працює на віртуальній машині Ethereum з нульовим розголошенням (zkEVM), яка прозоро виконує транзакції Етеріуму, включаючи смарт-контракти з перевірками доведень з нульовим розголошенням.

• Scroll (opens in a new tab) — Scroll — це технологічна компанія, що працює над створенням нативного рішення рівня 2 (l2) zkEVM для Етеріуму.

• Taiko (opens in a new tab) — Taiko — це децентралізований, еквівалентний Етеріуму ZK-ролап (ZK-EVM типу 1 (opens in a new tab)).

• ZKsync (opens in a new tab) — ZKsync Era — це EVM-сумісний ZK-ролап, створений Matter Labs, що працює на власній zkEVM.

• Starknet (opens in a new tab) — Starknet — це EVM-сумісне рішення для масштабування рівня 2 (l2), створене StarkWare.

• Morph (opens in a new tab) — Morph — це гібридне рішення для масштабування ролапів, яке використовує ZK-доведення для вирішення проблеми виклику стану рівня 2 (l2).

• Linea (opens in a new tab) — Linea — це еквівалентний Етеріуму zkEVM рівня 2 (l2), створений ConsenSys, повністю узгоджений з екосистемою Етеріуму.

Додаткова література про ZK-ролапи

• Що таке ролапи з нульовим розголошенням? (opens in a new tab)
• Що таке ролапи з нульовим розголошенням? (opens in a new tab)
• Практичний посібник з ролапів Етеріуму (opens in a new tab)
• STARK проти SNARK (opens in a new tab)
• Що таке zkEVM? (opens in a new tab)
• Типи ZK-EVM: еквівалентні Етеріуму, еквівалентні EVM, тип 1, тип 4 та інші загадкові модні слова (opens in a new tab)
• Вступ до zkEVM (opens in a new tab)
• Що таке ZK-EVM L2? (opens in a new tab)
• Ресурси Awesome-zkEVM (opens in a new tab)
• ZK-SNARK зсередини (opens in a new tab)
• Як можливі SNARK? (opens in a new tab)

Посібники: Приватність та нульове розголошення в Етеріумі

• Використання нульового розголошення для секретного стану – Як використовувати ZK-доведення та позамережеві серверні компоненти для підтримки секретного стану гри ончейн.
• Використання прихованих адрес – Як приховані адреси ERC-5564 забезпечують анонімні перекази ETH за допомогою криптографічного виведення ключів.
• Використання Етеріуму для автентифікації Веб2 – Як інтегрувати підписи гаманця Етеріуму з системами автентифікації Веб2 на основі SAML.