Передмова
Поки що більшість протоколів, які ми застосовували в Web3, мають певний ступінь довіри. Коли ми сподіваємося на подальшу «децентралізацію», нам неминуче доведеться пожертвувати часткою конфіденційності. Наприклад, коли протокол забезпечує MEV-Protection, він, швидше за все, використовує Private Mempool. Користувачі повинні припускати, що ця частина постачальників вузлів працюватиме чесно, тобто існує припущення про довіру третьої сторони вірно для всіх протоколів – передбачається певний рівень довіри. Згідно з нашими спостереженнями в попередньому дослідницькому звіті, для установ і великих інвесторів захист конфіденційності є одним із важливих факторів, коли вони вирішують, чи варто переміщувати активи в мережу. Це також означає, що деякі сторонні платформи даних у ланцюзі можуть посилити цілеспрямовані атаки MEV-Searcher і хакерів на великі домогосподарства та установи, тому впровадження захисту конфіденційності в ланцюзі, безсумнівно, природним чином задовольнить їхні потреби.
До цього ми також написали дослідницький звіт про Singularity, проект із треку конфіденційності, спрямований на транзакції темного пулу (розширене читання: детальне пояснення Singularity: приватні транзакції на прозорих блокчейнах).
Тож виникає запитання: що ми можемо зробити, щоб захистити конфіденційність?
Чотири поширені обчислювальні рішення для конфіденційності: повністю гомоморфне шифрування (FHE), багатостороннє обчислення (MPC), довірене середовище виконання (TEE) і підтвердження нульового знання (ZKP, підтвердження нульового знання). Насправді вони вирішують потреби сценарію в різних ситуаціях.
По-перше, для зашифрованих даних право власності на дані визначається тим, хто володіє ключем дешифрування/шифрування. Загалом, приватні дані можна розділити на особисті та групові.
Особисті видимі дані (Особистий приватний стан): Дані може переглядати та змінювати лише один суб’єкт, наприклад особистий баланс.
Групові видимі дані (загальний приватний стан): дані можуть використовуватися для розрахунків кількома об’єктами, забезпечуючи при цьому конфіденційність, як-от баланс у пулі ліквідності.
Для FHE, MPC і TEE всі вони можуть вирішити проблему групових видимих даних. Однак FHE потребує дорогих обчислювальних ресурсів, MPC вимагає, щоб усі валідатори були онлайн, а TEE має довіряти постачальнику послуг. Поточне дослідження галуззю цих рішень підходить лише для кількох сценаріїв, таких як транзакції темного пулу, керування приватними ключами тощо. Незважаючи на те, що інформація про результати, яку видає ZKP, обмежена (тобто питання «правда чи хибність») і здебільшого застосовна лише до особистих видимих даних, сценарії його застосування повністю вивчені поточними користувачами, такі як міжланцюгові мости, рівень 2, KYC і т.д. Навіть у майбутньому, якщо FHE та MPC або навіть інші рішення конфіденційних обчислень стануть популярними, ZKP не буде залишено через ефект канібалізації/ринкову конкуренцію, оскільки:
ZKP + FHE: наприклад, ланцюжок ZKVM, який використовує модель UTXO, якщо ви хочете перевірити кожну транзакцію, верифікатор повинен завантажити все дерево Merkle і декодувати одне за одним перед перевіркою, тому FHE представлено для обчислення без декодування. дає той самий результат.
ZKP + MPC: наприклад, темний пул, який використовує MPC + ZKP, дозволяє користувачам додатково забезпечувати атомарність транзакцій, одночасно забезпечуючи власну конфіденційність.
ZKP + TEE: наприклад, для ZK-SNARK, генерація загального еталонного рядка може бути виконана вузлом, на якому запущено TEE, щоб гарантувати, що проміжна інформація не витікає.
Ми можемо передбачити, що широкий спектр прикладних сценаріїв буде вибухнути. Однак цей попит все ще важко собі дозволити, виходячи з поточного основного рівня 1. Для цього потрібно не лише чекати перевірки мережі . Modular ZK As A Service (MZaaS), як структура проектування постачальника послуг ZKP, добре вирішує вищезазначені проблеми. MZaaS надає низку послуг, пов’язаних з ZKP, щоб зменшити складність генерації ZKP і підвищити ефективність. Ці послуги можна далі розбити на такі підкатегорії:
Proof Marketplace: головним чином базується на концепції розділення Requester-Prover, він поділяє Prover за різними сценаріями, щоб використовувати неактивні ресурси Prover для забезпечення публічного ринку доказів. Серед проектів, які можна назвати Mina, =nil; і ZKPool.
Верифікаційний рівень: головним чином базуючись на концепції агрегації, перевіряльник збирає кілька доказів і генерує новий доказ, щоб підтвердити достовірність початкового доказу та зменшує вартість процесу перевірки, надаючи рівень перевірки. Проекти, які можна назвати, включають Aligned Layer, Horizen, Cloaking Layer (zCloak Network) і Nebra.
Як слід розуміти ЗКП?
Перш ніж зрозуміти ринок ЗКП, давайте мати загальну концепцію життєвого циклу ЗКП. В основному система перевірки ZKP дотримується наступного процесу:
Правер заявляє, що він знає певну інформацію, і виражає її в системі обмежень на основі цієї проблеми.
Генеруйте схеми відповідно до сформульованої системи обмежень
Prover Введіть відповідь рішення (Witness), яке відповідає схемі для обчислення ZK Proof
Валідатор може перевірити ZKP, щоб визначити, чи справді Провер знає інформацію
Припустімо, що тепер у нас є дерево Merkle, яке використовується для запису балансу облікового запису користувача. Зазвичай, щоб оновити баланс облікового запису, нам потрібно виконати такий процес:
Перевірте записи відправника та одержувача в кінцевих вузлах
Перевірте підпис відправника
Оновлення балансу відправника та одержувача
Оновіть корінь Merkle дерева Merkle
Але з благословення ЖКП цей процес відбувається наступним чином:
Повністю побудуйте процес верифікації Merkle Tree у схему
Взявши дерево Меркла до і після оновлення та запис транзакції (хтось надіслав 10 доларів до A) як вхідні дані, обчисліть ZKP
Верифікатор перевіряє ZKP (взявши ZKP, ключ перевірки та публічний вхід як вхідні дані), і якщо вихідний результат правильний, то транзакція вважається достовірною.
У цьому процесі самому верифікатору не потрібно повторно перевіряти Дерево Меркла, йому потрібно лише вірити в результати перевірки (за умови, що схема побудована правильно).
Якщо ZKP далі демонтовано з точки зору високого рівня, то процес від визначення проблеми до побудови схеми виконується переднім кінцем (компілюється на мові високого рівня), тоді як бек-енд (компілюється на мові низького рівня ) відповідає за вбудовування/комбінування цієї схеми з певною системою перевірки для генерації ZKP, зокрема, схема спочатку поєднується з інформаційно-теоретичним протоколом, а потім компілюється у відповідну систему ZKP із криптографічним компілятором, наприклад Groth16.
сексуальність і цілісність. Обґрунтованість говорить про те, що твердження є істинним, якщо воно доведено в системі доказів. Повнота гарантує, що якщо твердження правдиве, його можна довести в системі.
Інтерактивний доказ (IP): Верифікатор задає перевіряючому серію «випадкових» запитань. Доказ відповідає. Це триває протягом багатьох раундів, доки верифікатор не переконається, що твердження првера є правильним.
Імовірнісні перевіряються докази (PCP): докази перетворюються у формат фіксованого розміру, який називається «пробна копія». Верифікатор може випадковим чином запитувати невелику кількість даних у репліці для підтвердження перевірки. Щоб запобігти тому, щоб перевіряльник заздалегідь передбачив значення запиту та підготував підроблене доказ, можна запровадити оракул для генерації випадкових значень, які верифікатор використовуватиме для випадкових запитів. З теоретичної точки зору цей метод більш ефективний, але з точки зору процесу верифікації він відносно неефективний.
Interactive Oracle Proof (IOP): перевірка та перевірка взаємодіють один з одним і мають доступ до випадкових прикладів. IOP покращує ефективність інтерактивних перевірок, використовуючи часткові копії даних для зменшення зв’язку та складності запитів. Це також часто використовувана система перевірки в ZKP System.
Усі згадані раніше інформаційно-теоретичні системи доказів роблять ідеальні припущення, які важко реалізувати в реальному житті. Наприклад, можна припустити, що верифікатор є надійним і що доступ до атестації обмежено. Але характеристики Cryptograph роблять ці припущення здійсненними за певних обставин, як-от звичайні математичні проблеми:
Проблема факторизації цілих чисел. Наприклад, безпека RSA ґрунтується на факторизації великих чисел.
Проблема дискретного логарифму: обмін ключами Діффі-Хеллмана базується на обчисленні дискретного логарифму великих чисел.
Проблема дискретного логарифму еліптичної кривої: криптографія еліптичної кривої (ECC) базується на еліптичних кривих у скінченних полях і дискретних логарифмах комплексної еліптичної кривої.
Після поєднання інформаційно-теоретичної системи доказів і криптографічного компілятора можна отримати систему ZKP, тому характеристики ZKP змінюватимуться при різних комбінаціях:
Обчислювальні методи: існує два основних режими загальних обчислень: схеми та машини Тьюринга. Хоча більшість основних мов програмування намагаються описати обчислювальний шлях машини Тьюринга, машина Тьюринга не є найефективнішою моделлю програмування для криптографічних обчислень, як правило, значно ускладнює зміну криптографічних протоколів. Тому люди використовують схеми замість машин Тьюрінга, оскільки схеми можуть дуже легко виражати багато прямих операторів, але компроміс полягає в тому, що користувачеві потрібно попередньо обробити оброблені обчислення.
Обчислювальна вартість: для різних комбінацій витрати на верифікатори, перевірки та зв’язок будуть різними. Наприклад, у системі ZKP у поєднанні з PCP + Collision-Resistant Hash Function (CRFS) вартість розрахунку така:
Антиквант: деякі алгоритми шифрування можуть ефективно протистояти грубому злому квантовими комп’ютерами. Наприклад, хеш-функція стійка до зіткнень, яку використовує ZK-STARK, не може бути зламана квантовими комп’ютерами, які зараз розробляються. Однак ризик злому все ще існує. Наприклад, два вчені з Шаньдунського університету описали, як зламати SHA1 і MD5 у статті, опублікованій у 2009 році. Отже, нам все ще потрібно мати припущення про довіру.
Довірена конфігурація зазвичай поділяється на дві категорії: випадкові числа, згенеровані URS, є загальнодоступними, що означає, що "структурована еталонна рядок" (SRS) ділиться на два типи. Універсальне налаштування та спеціальне налаштування, перше дозволяє кільком суб’єктам брати участь у генеруванні випадкових чисел, зазвичай у формі MPC, а друге дозволяє брати участь у генеруванні випадкових чисел для певного сценарію.
Якщо в одноранговому сценарії поганий актор знає випадкове значення, тоді він може підробити вихід системи та згенерувати правильний ZKP.
З вищесказаного також видно, що різні комбінації можна поширити на різні типи систем ЗКП. Підводячи підсумок, можна в основному розділити на ZK-SNARK, ZK-STARK і Bulletproof. Наступні основні відмінності можуть допомогти нам краще зрозуміти:
Надійна конфігурація: ZK-SNARK зазвичай приймає надійну конфігурацію, ZK-STARK і Bulletproof не потребують такої конфігурації.
Витрати на обчислення:
Час перевірки: куленепробивний > ZK-SNARK > ZK-STARK
Час перевірки: Bulletproof > ZK-STARKs > ZK-SNARKs
Складність зв’язку/захищений розмір: ZK-STARKs > Bulletproof > ZK-SNARK, але коли обсяг даних збільшується, простір для зберігання, необхідний для ZK-STARK і Bulletproof, буде меншим, ніж для ZK-SNARK.
Квантова стійкість: ZK-STARKS, як правило, квантово стійкі, ZK-SNARK і Bulletproof не вимагають таких властивостей.
Джерело зображення: https://github.com/matter-labs/awesome-zero-knowledge-proofs?ref=blog.pantherprotocol.io
Джерело зображення: https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa Потенціал і масштаб ринку, що підтверджує нульові знання
Зараз траса ЗКП розвивається в основному в двох основних напрямках: закритість і розширення.
План розширення
В основному це стосується прийняття ZKP як рішення для покращення масштабованості, включаючи підтвердження доступності рівня 2, крос-ланцюжок тощо. Поширені рішення наразі включають Starknet, ZKsync, Polyhedra тощо. Зазвичай його можна розділити на дві системи побудови: рівень 1/рівень 2 і протокол. У системі побудови рівня 1/рівня 2 зведені транзакції та програми виконуються на ZKEVM і мають характеристики захисту від нульового знання. Ідеальна ZKEVM має бути еквівалентною EVM, що означає, що вона може бути повністю сумісною з існуючими протоколами та досвідом розробки EVM. Відповідно до блогу Віталіка, чинний ЗКЕВМ можна розділити на 5 категорій:
Тип 1: повністю ідентичний Ethereum, жодних змін не буде внесено до його стану чи дерева транзакцій, хеш-коду чи будь-якої іншої логіки в його консенсусі. Type-1 буде повністю сумісний з усіма нативними програмами Ethereum, але потребуватиме довшого часу перевірки, оскільки попередня компіляція не виконується для прискорення створення перевірки. Серед проектів, доступних для довідки, наразі є Scroll і Taiko.
Тип 2: зовнішній вигляд схожий на Ethereum, але з незначними внутрішніми змінами, такими як дерево станів, структура блоків тощо, для полегшення розробки та прискорення створення доказів. Поточні проекти, доступні для довідки, включають Polygon Hermez.
Тип 2.5: обмежте деякі функції ZK, збільшивши плату за газ, щоб скоротити потенційний час перевірки, яка по суті лікує симптоми, але не першопричину.
Тип 3: деякі функції, які особливо складно реалізувати в реалізації ZK-EVM, можуть бути видалені. Крім того, іноді існують незначні відмінності в тому, як обробляється код контракту, пам’ять або стеки, тому сумісність з Ethereum буде слабшою. Ця категорія більше нагадує перехідний період розробки продукту, ніж позиціонування продукту.
Тип 4: Вихідний код смарт-контракту, написаний мовою високого рівня (наприклад, Solidity), компілюється в мову, спеціально розроблену для підтримки системи ZKP, наприклад Cairo. Хоча, виявляється, час можна прискорити. Однак його сумісність є найгіршою. Наприклад, деякі DApps, розроблені з використанням байт-коду Ethereum, можуть не бути перенесені. Проекти, доступні для довідки, включають ZKsync і Starknet.
Джерело зображення: https://vitalik.eth.limo/general/2022/08/04/zkevm.html
На початку розробки Ethereum не передбачалося, що ZKEVM буде використовуватися для розширення потужностей у майбутньому, тому складність розробки, безсумнівно, є дуже високою. Тому вибір ZKsync і Starknet полягає також у запуску загального- Мета ZKEVM на ринку якомога швидше. Насправді вони повинні називатися ZKVM, тому що їхня сумісність з Ethereum (для розробників) відносно низька, але натомість вони мають вищу архітектурну гнучкість і нижчу вартість генерації ZKP.
Цей тип ZKVM може позбутися обмежень системи EVM і стати рівнем 1. Розробники використовують мови високого рівня для написання кодів для конкретних архітектур віртуальних машин, а потім компілюють їх у схеми ZK або використовують доменно-залежні мовами (DSL) (наприклад, Circom) для безпосереднього створення кодів ZK.
Джерело зображення: https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
Якщо взяти до уваги лише розмір ринку ZK Layer2, то, згідно з даними L2Beat, поточний TVL ZK Layer2 (включаючи ZK Rollup і Validium) становить приблизно 5,015 мільярдів доларів США, що становить 10% і 7% від загального TVL Layer2 і Ethereum відповідно. Якщо ринкову частку OP Rollup використовувати як еталон, ZK Rollup наразі має можливість для зростання приблизно в 10 разів у TVL, і очікується запуск додатково 10-12 нових ZK Layer2.
Серед них Linea, Starknet і ZKsync є першою трійкою, на яку припадає 1,22 млрд доларів США, 1,06 млрд доларів США та 855 млн доларів США відповідно. Показник концентрації трьох компаній становить 62%, що означає, що поточна конкуренція рівня 2 монополізована кількома проектами. . Подальше спостереження за зростанням Layer2 TVL, зростання TVL в основному відбулося 20 лютого 2024 року. Причиною є приплив і подорожчання власних токенів Starknet. Наразі 75% власних токенів Starknet все ще зберігаються в ланцюжку.
Серед них Linea належить до Type2 ZKEVM, а Starknet і ZKsync належать до Type4 ZKEVM. І всі трійки найкращих — це ZK Rollup, який використовує Ethereum як DA, а другий DA буде розміщено поза ланцюгом і керуватиметься DAC. У Validium Immutable X займає перше місце з TVL майже 200 мільйонів доларів. Варто також зазначити, що в OP Rollup більшість із 10 найкращих рівнів 2 із найвищим TVL використовують стек OP, що означає, що певний стек має високу частку ринку. Але в ZK Rollup 10 найкращих Layer2 з найвищим TVL фактично вирішили розробити власний стек ZK.
Джерело зображення: https://l2beat.com/scaling/summary
Джерело зображення: https://l2beat.com/scaling/summary
Окрім вищезгаданого рівня 1/рівня 2, основні сценарії розширення ZKP включають протокольний рівень, наприклад крос-ланцюг. Впровадження ZKP у крос-ланцюг в основному обслуговує міжланцюгову інфраструктуру верифікації легких вузлів і створювача та відправника, наприклад Polyhedra, Orbiter Finance тощо. Під час початкового процесу верифікації світлового вузла контракт, розгорнутий у цільовому ланцюжку, повинен постійно отримувати заголовок блоку вихідного ланцюжка для подальшої міжланцюжкової перевірки інформації, яка неминуче споживатиме газ, однак, якщо процес перевірки розміщено Якщо в ланцюжку зберігається лише одне зобов’язання, вартість зберігання буде значно зменшена, і чим вища частота оновлення вихідного ланцюжка, тим вище вартість газу. Зобов'язання можна сконструювати за допомогою ZKP, який може ефективно стискати одну або кілька транзакцій. У режимі Maker&Sender ZKP поєднується з доказами шахрайства для подальшого зменшення кількості ZKP. З точки зору розміру ринку, беручи за приклад Orbiter Finance, хоча на даний момент він має щомісячний обсяг транзакцій приблизно 628 мільйонів доларів США та TVL 1,48 мільйона доларів, попит на ZKP також зросте у випадку високого обороту.
план конфіденційності
В основному стосується протоколів/мереж, які використовують ZKP як рішення безпеки конфіденційності, зокрема Zcash, Aztec і Tornado Cash.
Рішення, орієнтовані на конфіденційність, потребують менше зусиль у розробці, ніж напрямки розробки, орієнтовані на масштабування. Існуючі програми конфіденційності в основному зосереджені на конфіденційності платежів і не дуже програмовані. Поєднання конфіденційності та можливості програмування є складним завданням. Рішення, орієнтовані на конфіденційність, можна створити двома способами:
Протоколи: ці протоколи в основному використовують ZKP для створення приватних фондів. Користувачі використовують ці приватні фонди як рішення для захисту конфіденційності, наприклад Tornado Cash. Для цих додатків перевірка виконується користувачем, а перевірка відбувається в мережі. Оскільки Layer1 не призначений для криптографічних обчислень, витрати на перевірку часто є високими для звичайних користувачів, що обмежує впровадження цих програм. Інтуїтивно зрозуміле рішення полягає в тому, щоб перемістити програми для приватних транзакцій у Rollup, щоб зменшити плату за газ. У цьому випадку приватне підтвердження транзакції має бути включено до зведеного підтвердження, тобто рекурсивного підтвердження, що зараз неможливо зі звичайним зведеним ZK на Ethereum.
Рівень 1/Рівень 2: ці рівні 1/рівень 2 переважно реалізують захист конфіденційності через ZKP, наприклад Manta Network і Aztec. Більшість мереж, орієнтованих на конфіденційність, ще не можуть підтримувати обчислення загального призначення і можуть зосереджуватися лише на конкретних випадках використання. Наприклад, Penumbra і Renegade зосереджені на приватних транзакціях. Моделі облікових записів, прийняті цими рівнями 1/рівня 2, можна розділити на: на основі облікових записів і на основі UTXO. Обидва мають власні недоліки: перший може призвести до певної конфіденційності через маршрут транзакції та вимагає послідовної обробки, тоді як другий вимагає розшифровки кожного дочірнього вузла під час перевірки та оновлення балансу транзакції, перш ніж його можна буде правильно запитати.
За даними Defilama, поточний TVL треку конфіденційності становить близько 709 мільйонів доларів, а коефіцієнт концентрації трьох фірм становить майже 99%, а саме Tornado Cash (595 мільйонів доларів), Railgun (96,97 мільйонів доларів) і Aztec (9,45 мільйонів доларів). Серед них Tornado Cash і Railgun є протоколами, а Aztec належить до рівня 2.
Джерело зображення: https://defillama.com/protocols/Privacy
Серед них Tornado Cash стикається з придушенням відповідності, що також означає, що багато вимог щодо «відповідності конфіденційності» поступово мігруватимуть до інших протоколів і мереж, а рівень концентрації лише поступово зменшуватиметься. Крім того, багато сторонніх платформ даних і централізованих постачальників вузлів на ринку зараз підривають опір цензурі, і деякі великі інвестори та установи сподіваються переказувати великі суми коштів безпечнішим і більш приватним способом. Станом на 3 червня приблизно 37% блоків підлягали перевірці OFAC, чого публічний Mempool не може уникнути.
Джерело зображення: https://www.mevwatch.info
Це також розширює вимоги до відповідності, тому постачальники послуг, такі як KYC, також є дуже важливими. Однак користувачі все ще хочуть зберегти особисту конфіденційність у найбільшій мірі. Потенційні сценарії ZKP + KYC збільшаться з удосконаленням транзакцій конфіденційності Основними постачальниками послуг на поточному ринку є zCloak, zkMe тощо. У традиційному процесі KYC, коли нам потрібно довірити кілька постачальників послуг KYC, нам потрібно провести повторну перевірку, але у випадку ZKP + KYC інші постачальники послуг можуть спробувати перевірити ZKP, щоб переконатися в дійсності ідентифікаційної інформації. Крім того, під час процесу KYC постачальники послуг повинні записувати певну необхідну інформацію, наприклад конфіденційну інформацію, як-от ідентифікаційні картки. Якщо це відбувається в кількох постачальників послуг, ризик витоку інформації також зростатиме лінійно.
З якими проблемами зараз стикається ЖКП?
Як ми зазначали раніше, генерація ZKP вимагає значних обчислювальних ресурсів. Беручи за приклад звичайний ZK-Rollup, час генерації ZKP для ZKsync становить близько 1 години. У разі подальшого демонтажу процес генерації ZKP ZK-SNAKS в основному включає мультискалярне множення (MSM) і теоретико-числове перетворення (NTT). На ці два процеси може припадати від 80% до 95% часу створення доказу. Хоча ZK-STARKs використовує різні алгоритми, він також стикається з проблемою низької ефективності.
Крім того, за останні роки системи ЗКП надали широкий і постійно розширюваний діапазон опцій з різними компромісами. Наприклад, компромісом для швидшої швидкості перевірки є більший розмір перевірки або використання пам’яті. Різноманітність систем перевірки з різними можливостями налаштування величезна і постійно розширюється. Але Ethereum не може підтримувати систему доказів, що розвивається. Наприклад, тільки еліптичні криві BN-254 можуть підтримуватися за низькою ціною. Але перехід на більш безпечну криву (наприклад, BLS12-381) є дуже складним завданням, не кажучи вже про сумісність з новою системою ZKP.
Крім того, з точки зору верифікації рівня 1 ZKP, вартість перевірки STARK становить приблизно 5 000 000 Gas, тоді як підтвердження на основі Plonk становить менше 290 000 Gas. Якщо система перевірки перевіряється безпосередньо в Ethereum, наразі існує кілька обмежень. Наприклад, системи перевірки на основі внутрішніх аргументів продукту, такі як Mina's Kimchi (ефективна рекурсія через Pickles) або Binius на основі Brakedown (докази з розміром квадратного кореня). обсяг обчислень або розмір перевірки є відносно великим, тому вартість перевірки буде дуже високою. Для цього нам, можливо, знадобиться перейти на Ethereum-Friendly ZKP.
Як модульні послуги ЗК прискорюють процес ЗКП
Таким чином, як підвищити ефективність, стало напрямком, який потрібно дослідити в наступній розробці ZKP. Окрім змін в алгоритмах/схемах, поточні основні рішення можна розділити на дві категорії:
Апаратне прискорення: вдосконалення процесу генерації ZKP шляхом удосконалення обладнання. GPU зазвичай має обмежений час перевірки ZKP. Іншим варіантом є використання спеціального обладнання, наприклад FPGA або ASIC, а потім розширення апаратного рівня абстракції, який можна віднести до хмарної служби AI. Оскільки ця стаття не присвячена обговоренню апаратного прискорення, ми не будемо обговорювати його детально.
Модульний ZK-As-A-Service (MZaaS): зменшує складність генерації ZKP і підвищує ефективність, надаючи низку послуг, пов’язаних із ZKP. Ці послуги можна далі розбити на такі підкатегорії:
Proof Marketplace: головним чином базується на концепції розділення Requester-Prover, він поділяє Prover за різними сценаріями, щоб використовувати неактивні ресурси Prover для забезпечення публічного ринку доказів. Серед проектів, на які можна посилатися, Mina, =nil і ZKPool.
Верифікаційний рівень: головним чином базуючись на концепції агрегації, перевіряльник збирає кілька доказів і генерує новий доказ, щоб підтвердити достовірність початкового доказу та зменшує вартість процесу перевірки, надаючи рівень перевірки. Проекти, які можна назвати, включають Aligned Layer, Horizen, Cloaking Layer (zCloak Network) і Nebra.
Ринок доказів
По-перше, із наведених вище прикладних сценаріїв ми можемо виявити, що не всі транзакції будуть згенеровані в прикладних сценаріях ZKP, тому ми можемо класифікувати їх за двома методами генерації (взявши за приклад кросчейн):
Повний ZK: ZKP генерується для кожної транзакції. Наприклад, для кожної транзакції на ZK Bridge Maker генеруватиме ZKP для перевірки.
Половина ZK: ZKP буде створено лише за виконання певних умов. Наприклад, Orbiter Finance потрібно лише створити ZKP, коли з’являється неправильна або недостовірна інформація про трансакцію.
Таким чином, у сценарії Half ZK не всі Првери використовуються повністю. Коли ми розділяємо роль Prover на Requester і Prover і створюємо спільну платформу/Marketplace Prover, ми можемо покращити використання Prover і потенційно скоротити час, необхідний для створення ZKP у сценаріях Full ZK. Але питання в тому, як вибрати Прувер?
Конкретний дизайн того, як вибрати Prover, насправді можна розглядати в кількох вимірах: продуктивність, вартість і децентралізація. По суті, це схоже на неможливий трикутник механізму консенсусу. Наприклад, для забезпечення децентралізації обрано багатовузлову перевірку, але повторна перевірка, безсумнівно, лише збільшить час перевірки (нижча продуктивність). На основі різних економічних моделей ZKP, які досліджував Тайко, вони узагальнили наведений нижче графік. Автор не буде тут вдаватися в подробиці.
Джерело зображення: https://www.theblockbeats.info/news/45260 Верифікаційний рівень
По-перше, нам потрібно пояснити різницю між агрегацією та верифікаційним рівнем: перший лише певним чином стискає ZKP, наприклад, рекурсію та згортання; другий додає на цій основі процес попередньої перевірки (Soft Finality). Процес Soft Finality може покладатися на зовнішні контракти/мережі, що вимагає певного рівня довіри.
У фактичному процесі агрегації архітектура, прийнята різними проектами, дещо відрізняється, але загалом є такі чотири посилання (взявши за приклад ZKTree, який використовує Polymer):
Композиція ZKP: об’єднайте будь-яку схему в нову ZKP, можливо, за допомогою рекурсії та згортання.
Уніфікація ЗКП: Уніфікуйте вищевказаний процес у новий ЗКП.
Рекурсія ZKP: знову повторіть щойно згенерований пакет дочірніх вузлів (уніфікований ZKP) і використовуйте цей пакет ZKP як підтвердження перевірки для досягнення м’якої дійсності/фінальності.
Трансформація ZKP: якщо їм потрібно обслуговувати певну віртуальну машину, вони можуть мати власну адаптивність до різних систем ZKP, і вони будуть надалі зіставлені з ZKP різних систем відповідно до ситуації, щоб зменшити витрати на перевірку.
Верифікаційний рівень може забезпечити миттєву перевірку за допомогою Soft Finality та інтегруватися з різними системами (не обмежуючись Ethereum), якщо вимоги до безпеки є відносно низькими, Soft Finality можна використовувати для підвищення ефективності. А за допомогою верифікаційного рівня також можна зробити паралельні обчислення, ще більше позбувшись технічної заборгованості Ethereum. Що ще важливіше, це може зменшити витрати на перевірку. Згідно з фактичними тестами Nebra, кожне підтвердження, подане в ланцюжку Ethereum, може заощадити до 184 тис. газу (приблизно 75%), а кожне підтвердження, подане поза ланцюгом, може заощадити до 207 тис. газу (приблизно 85%). Крім того, Aligned Layer також оцінює, що вартість перевірки на Groth16 і STARKs буде в 29 і 80 разів нижчою, ніж початкова перевірка на Ethereum, і вона використовуватиме апаратне забезпечення домашнього рівня.
Рівень маскування. Як застосувати рівень перевірки
вступ
Cloaking Layer — це новий продукт zCloak Network, який зосереджується на наданні послуг верифікаційного рівня для ZKP. Основна ідея полягає в тому, щоб скористатися перевагами надвисокої ефективності та наднизької вартості Internet Computer (ICP) і використовувати контракт Canister на основі WebAssembly (WASM) для безпосередньої перевірки кожного ZKP. Потім на основі того самого припущення про довіру використовується технологія порогового підпису для надсилання результатів перевірки до будь-якого цільового публічного ланцюга, щоб отримати послуги перевірки ZKP, що охоплюють увесь ланцюг. (Розширена інформація: Рівень маскування — ZK Verification Infra for All Chains)
Основна архітектура
Джерело зображення: https://zcloaknetwork.medium.com/cloaking-layer-a-zk-verification-infra-for-all-chains-1162d3fcc37b
Перш за все, ядром Cloaking Layer є ICP Canister, який може безпосередньо запускати верифікатор ZKP (Verifier) у формі WASM для безпосередньої перевірки доказів "SNARK" і "STARK". ICP Canister можна розуміти як смарт-контракт у ланцюжку EVM. Його не можна змінювати після розгортання, а результати роботи вимагають консенсусу всієї мережі. На відміну від контрактів EVM, які мають бути написані мовою Solidity, контракти Canister можуть добре підтримувати скомпільовані об’єкти WASM. Оскільки переважна більшість поточних систем ZKVM, таких як Polygon Miden, RISC0, SP1, Jolt тощо, написані на мові програмування Rust і можуть бути легко скомпільовані в WASM, Canister дуже підходить як засіб перевірки ZKP.
Публічний ланцюг ICP складається з кількох підмереж (Subnets), і кожна підмережа містить велику кількість вузлів (Replica). Після розгортання контракту Canister копія буде збережена в кожному вузлі підмережі, і вона буде працювати незалежно в кожному вузлі під час виконання. Потім підмережа порівнюватиме результати роботи всіх вузлів і отримає консенсус, забезпечуючи тим самим результати роботи. Каністра правильна. Коли рівень маскування отримує ZKP, контейнер валідатора, розгорнутий у кожному вузлі, самостійно обчислить і перевірить ZKP. Коли результат атестації досягає консенсусу в підмережі, підмережа цифрово підписує результат перевірки за допомогою технології підпису Threshold ECDSA. Підписані результати перевірки можна надіслати в будь-яку загальнодоступну мережу, яка підтримує перевірку підпису ECDSA, наприклад Bitcoin, Ethereum і Solana, для використання.
аналіз конкуренції
Ключові моменти:
Існує великий розрив між оцінками рішень на поточному ринку.
На даний момент більшість рішень вже є на Testnet
За оцінками, середня вартість верифікації буде зменшена більш ніж у 10 разів, причому Cloaking Layer матиме найвищу продуктивність.
Більшість припущень щодо довіри базуються на Рівні 1
Більшість проектів проводять лише «розширення перевірки» для Ethereum
оцінити
Найбільша відмінність між рівнем маскування та іншими поточними рішеннями рівня перевірки полягає в припущенні довіри. Наразі подання заявки на отримання статусу репліки (вузла ICP) вимагає схвалення від ICP Foundation і вищих вимог до конфігурації вузла (вищих, ніж рівень 1 із більш важкими конфігураціями вузла, як-от Solana та Sui). певне обмеження довіри щодо ефективності порогового підпису ECDSA, який, по суті, все ще покладається на 2/3 чесних вузлів у мережі. Крім того, завдяки перевагам продуктивності вузлів ICP Cloaking Layer не потрібно вдаватися до складних схем рекурсії ZKP для досягнення стиснення ZKP. Цей метод також є найбільш прямим і зручним.
розширене обговорення
Як я можу створити стійкість до цензури в Verification Layer?
Найпростішим і найефективнішим способом є використання механізму захисту від цензури Рівня 1. Поки Verifier/Unified Prover на рівні верифікації не може перехопити надіслану транзакцію, здатність захисту від цензури рівня 1 може бути успадкована. Фактичне розуміння полягає в тому, що користувач/протокол може безпосередньо надіслати ZKP до смарт-контракту Рівня перевірки на Рівні 1 (Каністер на ICP) і зберегти його в черзі очікування в очікуванні упаковки Verifier/Unified Prover. З точки зору Arbitrum, будь-хто може включити транзакцію в історію транзакцій рівня 2 через певний період часу без відповідного секвенсора.
Що таке ринок ЗКП-ЕВ?
Завдяки вищезазначеним міркуванням ми можемо забезпечити додаткові збори за обробку, щоб визначити пріоритетність упаковки. Якщо масштаб є відносно великим, можна розвинути ринок ZKP-EV (Extractable Value), подібний до ринку MEV.
Як поєднуються Soft Finality і Hard Finality?
Усі рівні перевірки забезпечуватимуть м’яку остаточність, і оскільки продуктивність цих рівнів перевірки вища, ніж у Ethereum, швидкість перевірки також краща, ніж у Ethereum. Але якщо вам потрібно пройти Hard Finality Layer1, то час буде довшим, ніж час без використання Verification Layer. Це також є недоліком збереження Hard Finality + Aggregated ZKP. Таким чином, для протоколів, які вимагають більшої обережності в Hard Finality, поточний рівень перевірки може бути недостатньо хорошим рішенням. Слід запровадити модулі скорочення, системи репутації та механізми страхування, щоб знайти баланс між ефективністю та безпекою. Ви можете ознайомитися з нашими минулими статтями (розширене читання: TeleportDAO: гра в безпеку та ефективність перевірки даних, останні практики в дизайні легких вузлів).
Які джерела доходу для ZK-As-A-Service?
Поточна бізнес-модель усіх ZaaS все ще є відносно розпливчастою. Окрім того, що вона може отримувати частину комісії в процесі ZKP, це випуск монет. Але грошовий потік бізнесу фактично відокремлений від вартості токена, якщо він не пов’язаний через тверде зобов’язання зворотного викупу (наприклад, MKR MakerDAO). Таким чином, незважаючи на те, що поточний розмір ринку очікується великим, фактичні доходи ще мають бути підтверджені ринком.
довідка
https://medium.com/casperblockchain/verified-merkle-tree-updates-without-zk-90d8f5100ccd
https://www.zkcamp.xyz/blog/information-theory
https://x.com/iam_preethi/status/1656411033366396929 https://crypto.stackexchange.com/questions/92018/which-is-the-relation-between-zero-knowledge-proofs-of-knowledge-and-circuits https://web.archive.org/web/20090521024709/http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa
https://www.paradigm.xyz/2022/04/zk-hardware
https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4?ref=blog.pantherprotocol.io
https://x.com/jaosef/status/1730313497513476326
https://l2beat.com/scaling/summary
https://defillama.com/protocols/Privacy
https://docs.zksync.io/zk-stack/concepts/finality.html#finality-on-zksync-era
https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
https://dune.com/nebra/zkp-verify-spending
https://medium.com/@eternal1997L/Причини занепаду icp - унікальна технологія та тонка екологія - 51dd7a9362fb
