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

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

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

Хоча Web3 часто описується як «читання, запис, володіння», ми вважаємо, що кращею ідеєю для третьої ітерації Інтернету є «читання, запис, перевірка», оскільки ключовою перевагою публічних блокчейнів єгарантоване обчисленняі проста перевірка того, що ці гарантії були забезпечені. Власність може бути підмножиною гарантованого обчислення, якщо ми будуємо цифрові артефакти, які можна купити, продати та контролювати. Однак багато випадків використання блокчейнів користуються гарантованим обчисленням, але не мають прямого відношення до власності. Наприклад, якщо ваше здоров'я в повністю онлайн-грі складає 77/100 - ви володієте цим здоров'ям, чи це лише може бути забезпечено онлайн згідно з загальноприйнятими правилами? Ми стверджуємо останнє, але Chris Dixonможе не погоджуватися.

Web3 = Читати, Писати, Перевіряти

ZK та Модульність - Два Тренди, Які Прискорять

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

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

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

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

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

Ми вважаємо, що як модульність, так і «ZKfication of everything» - це тенденції, які будуть продовжувати прискорюватися. Хоча обидві надають цікаві можливості для дослідження простору окремо - нас особливо цікавить перетин обох. Дві ключові питання, які нас цікавлять, це:

1. Які частини модульного стеку вже включають ZKPs, а які ще не досліджені?
2. Які проблеми можуть бути пом'якшені за допомогою ZKPs?

Однак, перш ніж ми зможемо відповісти на ці питання, нам потрібен оновлений погляд на те, як виглядатиме модульний стек у 2024 році.

Модульний стек у 2024 році

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

Раніше спроби дослідження стеку web3 включають ті, які були проведені Кайл Самані(Multikoin) - спочатку опубліковано в2018 та оновлено в 2019. Це охоплює все, починаючи від децентралізованого Інтернет-доступу останньої милі (такого як Гелій) до управління ключами кінцевого користувача. Хоча принципи, що стоять за цим, можуть бути відновлені, деякі частини, такі як доведення та перевірка, повністю відсутні.

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

ZK У модульному стеку

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

1 - Абстракція операцій користувача

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

• Абстракція облікового запису (AA) дозволяє смарт-контрактам здійснювати операції без необхідності підпису користувача для кожної операції (“програмований криптовалютний рахунок”). Його можна використовувати для визначення того, хто може підписувати (управління ключами), що підписувати (транзакційний навантаження), як підписувати (алгоритм підпису) та коли підписувати (умова схвалення транзакції). У поєднанні ці функції дозволяють такі речі, як використання соціального входу для взаємодії з додатками, двофакторна автентифікація, відновлення облікового запису та автоматизація (автоматичне підписування транзакцій). Хоча обговорення часто обертаються навколо Ethereum (ERC-4337пройшли весною 2023 року), багато інших ланцюгів вже мають вбудовану, внутрішню абстракцію облікового запису (Aptos, Sui, Поблизу, ICP, Starknet, та zkSync).
• Абстракція ланцюга дозволяє користувачам підписувати транзакції на різних ланцюгах, взаємодіючи лише з одним обліковим записом (один інтерфейс, кілька ланцюгів). Над цим працює кілька команд, включаючи Поблизу, ICP, та dГаманець. Ці рішення використовують MPC та ланцюжкові підписи, де приватний ключ іншої мережі розбивається на кілька невеликих шматків та розподіляється між валідаторами на джерелі ланцюжка, які підписують трансграничні транзакції. Коли користувачі хочуть взаємодіяти з іншим ланцюжком, достатня кількість валідаторів повинна підписати транзакцію, щоб задовольнити порогове шифрування. Це зберігає безпеку, оскільки приватний ключ ніколи не повністю розповсюджується ніде. Однак воно стикається з ризиком колюзії валідаторів, тому криптоекономічна безпека та децентралізація валідаторів базового ланцюжка залишається дуже актуальною.
• Наміри, на високому рівні, дозволяють зводити бажання та потреби користувачів до операцій, які можуть бути виконані на блокчейні. Це потребує розв'язувачів намірів - спеціалізованих агентів позачергового вирішення, які мають за мету знаходження найкращого можливого рішення для наміру користувача. Вже існують декілька додатків, які використовують спеціалізовані наміри, такі як DEX-агрегатори ("найкраща ціна") та місто-агрегатори ("найдешевший/найшвидший міст"). Загальні мережі вирішення намірівAnoma, Необхідний, Елегантний) метою є полегшити користувачам вираження більш складних намірів та розробникам будувати додатки, орієнтовані на наміри. Проте є ще багато відкритих питань, включаючи як формалізувати процес, якою би виглядала мова, орієнтована на наміри, чи завжди існує оптимальне рішення та чи його можна знайти.

Існуючі ZK Інтеграції

• Аутентифікація за допомогою AA x ZK: Один приклад цього - Sui’s zkLogin, яке дозволяє користувачам увійти, використовуючи звичайні облікові дані, такі як адреса електронної пошти. Воно використовує ZKPs, щоб запобігти стороннім особам пов'язати адресу Sui з відповідним ідентифікатором OAuth.
• Більш ефективна перевірка підпису для гаманців AA: Перевірка транзакцій у контрактах AA може бути значно дорожчою, ніж ті, які ініціюються традиційним обліковим записом (EOA).Орбітернамагається впоратися з цим за допомогою сервісу зв'язування, який використовує ZKPs для перевірки правильності підписів транзакцій та підтримує значення nonce та баланс газу облікового запису АА (через дерево світового стану Меркла). За допомогою агрегації доказів та розподілу вартості перевірки on-chain порівну між усіма користувачами це може призвести до значних економій витрат.

Відкриті проблеми, які можуть вирішити ZKP

• Доказ виконання найкращого або намір виконання: Хоча наміри та AA можуть абстрагувати складність від користувачів, вони також можуть діяти як централізуюча сила та потребувати від нас покладатися на спеціалізованих акторів (розв'язувачів), щоб знайти оптимальні шляхи виконання. Замість того, щоб просто довіряти доброзичливості розв'язувача, ZKPs можуть потенційно бути використані, щоб довести, що був вибраний оптимальний шлях для користувача серед тих, які були вибрані розв'язувачем.
• Приватність для вирішення намірів: Протоколи, такі як Тайгамає на меті забезпечити повністю захищене вирішення намірів для збереження конфіденційності користувачів - частина широкого руху в напрямку додавання конфіденційності (або принаймні конфіденційності) до блокчейн-мереж. Він використовує ZKPs (Halo2), щоб приховати чутливу інформацію про переходи стану (типи додатків, учасники, тощо).
• Відновлення пароля для гаманців AA: Ідея за ця пропозиція полягає в тому, щоб користувачі могли відновити свої гаманці, якщо вони втратять свої приватні ключі. Зберігаючи хеш (пароль, nonce) на контрактному гаманці, користувачі можуть згенерувати ZKP за допомогою свого пароля, щоб підтвердити, що це їхній обліковий запис, і запросити зміну приватного ключа. Період підтвердження (3 дні і більше) служить захистом від спроб несанкціонованого доступу.

2 - Послідовність

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

Ще одне питання - хто має право робити замовлення транзакцій. У модульному світі це можуть робити кілька різних сторін, включаючи послідовника rollup (централізованого або децентралізованого), L1 sequencing (на основі rollups) та спільну мережу послідовності (децентралізовану мережу послідовників, яку використовують декілька rollups). Усі вони мають різні припущення про довіру та можливості масштабуванняНа практиці фактичне упорядкування транзакцій та їх пакування в блок також може проводитися поза протоколом спеціалізованими учасниками (блокбілдерами).

Існуючі ZK Інтеграції

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

Відкриті проблеми, які можуть вирішити ZKPs

• Перевірні правила послідовності (VSR): Піддавання пропонента / послідовника набір правил щодо порядку виконанняз додатковими гарантіями, що ці правила дотримуються. Підтвердження може бути здійснене або через ZKPs, або через докази шахрайства, останнє з яких вимагає достатньо велику економічну заставу, яка буде зменшена, якщо пропонент/послідовник вчинить нечесно.

3 - Виконання (Масштабування записів)

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

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

Існуючі ZK Інтеграції

• zkEVM rollups: Особливий тип zkVM, оптимізований для сумісності з Ethereum та доведення середовища виконання EVM. Чим більша сумісність з Ethereum, тим більша компроміс у продуктивності. Кілька zkEVM були запущені в 2023 році, включаючи Polygon zkEVM, zkSync Ера, Прокручувати, та Linea. Останнім часом Polygon оголосив про свою тип 1 довідник zkEVM, що дозволяє доводити блоки основної мережі Ethereum за $0.20- $0.50 за блок (з майбутніми оптимізаціями для подальшого зниження витрат).RiscZero також має рішення що дозволяє підтверджувати блоки Ethereum, але за вищою ціною з обмеженими можливостями бенчмаркінгу.
• Альтернативні zkVMs: Деякі протоколи йдуть альтернативним шляхом та оптимізуються для продуктивності/доведенняStarknet, Зорп) або доброзичливість для розробників, а не намагання бути максимально сумісним з Ethereum. Прикладами останніх є протоколи zkWASM (Плавний, Delphinus Labs) та zkMOVE (M2 та zkmove).
• Приватно спрямовані zkVMs: У цьому випадку ZKPs використовуються для двох речей: уникнення повторного виконання та досягнення конфіденційності. Хоча конфіденційність, яку можна досягти лише за допомогою ZKPs, обмежена (лише особистий приватний стан), майбутні протоколи додають багато виразності та програмованості до існуючих рішень. Приклади включають Aleo’s snarkVM, Aztec’sAVM, та ПолігонаMidenVM.
• ZK-співпроцесори: Дозволяють виконання обчислень поза ланцюжком на даних, що знаходяться в ланцюжку (але без стану). ZKPs використовуються для підтвердження правильного виконання, що забезпечує швидке здійснення розрахунків порівняно з оптимістичними співпроцесорами, але існує компроміс у вартості. У зв'язку із вартістю та/або складністю генерації ZKPs ми спостерігаємо деякі гібридні версії, такі як Brevis coChain, що дозволяє розробникам вибирати між режимом ZK або оптимістичним режимом (компроміс між вартістю та складністю гарантій).

Відкриті проблеми, які можуть бути вирішені ZKPs

• Закріплений zkVM: Більшість базових шарів (L1s) все ще використовують повторне виконання для перевірки правильних переходів стану. Закріплення zkVM на базовому рівні уникнуло б цього, оскільки валідатори могли б перевірити доказ замість цього. Це покращило б ефективність операцій. Більшість очей спрямовані на Ethereum з закріпленим zkEVM, але багато інших екосистем також покладаються на повторне виконання.
• zkSVM: Хоча SVM в основному використовується в межах Solana L1 сьогодні, команди, такі як Eclipse, намагаються використовувати SVM для rollups, які вирішуються на Ethereum. Eclipse також планує використовувати Risc Zero для доказів ZK шахрайствадля потенційних викликів станових переходів в SVM. Повноцінний zkSVM, однак, ще не досліджувався - ймовірно, через складність проблеми та той факт, що SVM оптимізований для інших речей, ніж доведення.

4 - Запит даних (масштабування читань)

Запит даних або читання даних з блокчейну є невід'ємною частиною більшості додатків. У той час як багато обговорень та зусиль за останні роки було спрямовано на масштабування записів (виконання) - масштабування читань навіть важливіше через дисбаланс між ними (особливо в децентралізованому середовищі). Співвідношення між читанням/записом відрізняється для різних блокчейнів, але один даний пункт є Оцінка Sigщо більше 96% всіх викликів до вузлів на Solana були читаючими (на основі 2 років емпіричних даних) - співвідношення читання/запису 24:1.

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

Ще одним аспектом є децентралізація методів запиту даних. Сьогодні більшість запитів на отримання даних в блокчейнах здійснюються завдяки довіреним третім сторонам (на основі репутації), таким як вузли RPC (Infura) та індексатори (Пісок). Приклади більш децентралізованих варіантів включають Графікі операторів, які доводять зберігання (які також можна перевірити). Існують також кілька спроб створення децентралізованої мережі RPC, наприклад Infura DINабоLava Мережа (крім децентралізованого RPC, Lava має на меті надавати пізніше додаткові послуги з доступу до даних).

Існуючі ZK Інтеграції

• Докази зберігання: Дозволяє запитувати як історичні, так і поточні дані з блокчейнів без використання довірених третіх сторін. ZKPs використовуються для стиснення та підтвердження того, що були отримані правильні дані. Приклади проектів, які розробляються в цьому просторі, включають Аксіома, Brevis, ГеродоттаЛаґранж.

Відкриті проблеми, які можуть вирішити ZKPs

• Ефективний запит приватного стану: Проекти з приватністю часто використовують варіацію моделі UTXO, яка забезпечує кращі можливості приватності, ніж модель рахунку, але це коштує зручності для розробників. Приватна модель UTXO також може призвести до проблем синхронізації - щось Zcash має проблеми зз 2022 року після значного збільшення обсягу захищених транзакцій. Гаманці повинні синхронізуватися з ланцюгом перед тим, як мати змогу витрачати кошти, тому це досить фундаментальне виклик для роботи мережі. У передчутті цієї проблеми,Aztec недавно опублікував запит на пропозиціїдля ідей щодо виявлення нотаток, але чіткого рішення поки що не знайдено.

5 - Доведення

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

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

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

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

Джерело: Figment Capital

Існуючі ZK Інтеграції

• STARK з обгорткою SNARK: доказувачі STARK швидкі та не потребують довіреного налаштування, але недолік полягає в тому, що вони створюють великі докази, які надто дорого перевіряти на Ethereum L1. Обгортання STARK у SNARK як останній крок робить його значно дешевше у перевірці на Ethereum. З іншого боку, це додає складності, і безпека цих "складених систем доказів" не була глибоко вивчена. Приклади існуючих реалізацій включають Polygon zkEVM, Boojum у zkSync Era, та RISC Zero.
• Загальнопризначені децентралізовані мережі доказів: Інтеграція більше застосувань у децентралізовану мережу доказів робить її ефективнішою для довідкових осіб (вище використання апаратного забезпечення) та дешевшою для користувачів (не потрібно платити за дублювання апаратного забезпечення). Проекти в цій галузі включають GevulotіСтислий.

Відкриті проблеми, які можуть вирішити ZKPs

• ZK Шахрайські докази: У оптимістичних рішеннях будь-хто може викликати перехід стану та створити доказ шахрайства протягом періоду виклику. Однак перевірка доказу шахрайства все ще досить громіздка, оскільки вона виконується шляхом повторного виконання. ZK шахрайські докази спрямовані на вирішення цієї проблеми шляхом створення доказу переходу стану, який був оспорюваний, що дозволяє більш ефективну перевірку (немає потреби в повторному виконанні) та можливо швидше вирішення. Над цим працює принаймніОптимізм(у співпраці з O1 Labs та RiscZero), таAltLayer x RiscZero.
• Більш ефективна агрегація доказів: Велика перевага ZKPs полягає в тому, що ви можете об'єднати кілька доказів в один доказ, не суттєво збільшуючи витрати на верифікацію. Це дозволяє амортизувати витрати на верифікацію на кілька доказів або застосувань. Агрегація доказів також є доказом, але вхід складається з двох доказів, а не з виконавчого сліду. Приклади проектів у цій області включають NEBRA та Gevulot.

Джерело: Figment Capital

6 - Публікація даних (Доступність)

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

Celestiaбув першим альтернативним рівнем DP, що запустив свою основну мережу (31 жовтня), але незабаром з'явиться багато альтернатив на вибір, так як Скористатися, EigenDA, та Близько до DAвсі очікуються запустити протягом 2024 року. Крім того, Ethereum’s EIP 4844оновлення масштабування публікації даних на Ethereum (на додачу до створення окремого ринку оплати за зберігання блобів) та підготовка ґрунту для повного денк-шардінгу. DP також розширюється на інші екосистеми - одним прикладом є@nubit_org/riema-secureє ангельське інвестування для запуску першого біткойн-нативного шару доступності даних, який прагне побудувати Native DP на біткойні.

Багато рішень DP також пропонують послуги поза чистою публікацією даних, включаючи спільну безпеку для суверенних роллапів (таких як СелестіяіДоступно) або більш плавна взаємодія між rollups (наприклад, Avail’sNexus). Також є проекти (ДоміконіНульова гравітація) які пропонують як публікацію даних, так і зберігання довгострокового стану, що є привабливою пропозицією. Це також приклад повторного пакетування двох компонентів у модульному стеку, щось, що ми, ймовірно, побачимо більше в майбутньому (експерименти як із подальшим розбунтовуванням, так і знову збунтовуванням).

Існуючі ZK Інтеграції

• Доведення правильності кодування стирання: Кодування стирання забезпечує певний рівень зайвості, щоб оригінальні дані можна було відновити навіть у випадку, якщо частина закодованих даних недоступна. Це також є передумовою для DAS, де легкі вузли вибирають лише невелику частину блоку для ймовірнісної гарантії наявності даних. Якщо злоумисний пропонент закодує дані неправильно, оригінальні дані можуть бути невідновні, навіть якщо легкі вузли виберуть достатньо унікальних частин. Доведення правильності кодування стирання можна виконати або за допомогою доказів дійсності (ZKPs), або шахрайські докази - останні страждають від затримок, пов'язаних з періодом виклику. Усі інші рішення, окрім Celestia, працюють над використанням доказів дійсності.
• ZK легкі клієнти, що живлять мости даних: Rollups, які використовують зовнішні шари публікації даних, все ще потребують спілкування з рівнем розрахунків, що дані були опубліковані належним чином. Для цього існують мости атестації даних. Використання ZKPs дозволяє зробити верифікацію підписів консенсусу джерела даних більш ефективною на Ethereum. Обидва Avail’s (VectorX) і Селестії (BlobstreamX) докази атестації даних працюють за допомогою ZK легких клієнтів, побудованих разом з Succinct.

Відкриті проблеми, які можуть вирішити ZKPs

• Celestia, яка включає докази про вірність для правильного кодування стирання: Celestia наразі є відхиленцем серед мереж публікації даних, оскільки вона використовує докази шахрайства для правильного кодування стирання. Якщо зловмисник-пропонувач блоку закодує дані неправильно, будь-який інший повний вузол може згенерувати доказ шахрайства та викликати це. Хоча цей підхід трохи простіший у впровадженні, він також вводить затримки (блок остаточний лише після вікна доказу шахрайства) і вимагає, щоб легкі вузли довірили одному чесному повному вузлу, щоб згенерувати доказ шахрайства (не можуть перевірити його самостійно). Однак, Celestia досліджуєпоєднуючи їх поточне кодування Ріда-Соломона з ZKP, щоб довести правильність кодування, що значно зменшило б завершеність. Останню дискусію на цю тему можна знайти тутз записами з попередніх робочих груп (на додаток до більш загальних спроб додавання ZKPs до базового рівня Celestia).
• ZK-доказ ДАС: Були проведені деякі дослідження на Докази доступності даних ZK, де світлі вузли просто перевіряли б мерклівський корінь та ZKP, а не мали робити звичайну вибіркову вибірку, завантажуючи невеликі фрагменти даних. Це зменшило б вимоги до світлих вузлів ще більше, але здається, що розвиток зупинився.

7 - Довготривале (державне) зберігання

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

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

Існуючі ZK інтеграції

• Доказ зберігання: Постачальники довгострокового зберігання повинні регулярно генерувати ZKPs, щоб довести, що вони зберегли всі дані, які вони стверджують. Прикладом цього є Доказ простору часу Filecoin(PoSt), де постачальники сховищ заробляють блокові винагороди кожного разу, коли вони успішно відповідають на виклик PoSt.

Відкриті проблеми, які ZKPs можуть вирішити

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

8 - Узгодження

Враховуючи, що блокчейни є розподіленими P2P-системами, не існує довіреної третьої сторони, яка визначає глобальну правду. Натомість, вузли мережі домовляються про те, якою є поточна істина (який блок є правильним) за допомогою механізму, який називається консенсусом. Методи консенсусу на основі PoS можна розділити на BFT (де візантійський відмовостійкий кворум валідаторів визначає остаточний стан) або на основі ланцюга (де остаточний стан визначається ретроспективно правилом вибору форку). У той час як більшість існуючих реалізацій консенсусу PoS базуються на BFT, Карданоце приклад реалізації найдовшого ланцюжка. Існує також зростаючий інтерес до механізмів консенсусу на основі DAG, таких як Narwhal-Bullshark, які реалізовані у деяких варіаціях на Aleo, Aptos та Sui.

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

Існуючі ZK Інтеграції

• Стейкінг в мережах конфіденційності на основі ZK: Мережі конфіденційності на основі PoS становлять виклик, оскільки власники токенів стейкінгу повинні вибирати між конфіденційністю та участю в консенсусі (і отриманням винагороди за стейкінг).Penumbra має на меті вирішити цешляхом виключення винагород за стейкінг, замість цього розглядаючи необліковані та обліковані стейки як окремі активи. Цей метод зберігає конфіденційність окремих делегацій, тоді як загальна сума, зв'язана з кожним валідатором, все ще є публічною.
• Приватне управління: Досягнення анонімного голосування давно є викликом у криптовалюті, із проектами, такими як Іменники приватне голосуваннянамагається просунути це вперед. Те ж саме стосується управління, де анонімне голосування за пропозиціями працює принаймні Penumbra. У цьому випадку ZKPs можуть бути використані для підтвердження того, що у когось є право голосу (наприклад, через володіння токенами) і що виконані певні критерії голосування (наприклад, ще не голосували).

Відкриті проблеми, які можуть вирішити ZKPs

• Приватний вибір лідера: у даний час Ethereum обирає наступних 32 пропонентів блоків на початку кожної епохи, і результати цього вибору публічні. Це створює ризик того, що злоумисна сторона запустить атаку DoS проти кожного пропонента послідовно, щоб відключити Ethereum. У спробі вирішити цю проблему,Взбитице пропозиція щодо протоколу збереження конфіденційності для вибору пропонентів блоку на Ethereum. ZKPs використовуються валідаторами для доведення того, що перемішування та випадковий вибір виконувалися чесно. Існують і інші підходи для досягнення схожої кінцевої мети, деякі з яких розглянуті в цьомупости блогу від a16z.
• Агрегація підписів: Використання ZKPs для агрегування підписів може значно зменшити комунікаційне та обчислювальне навантаження підтвердження підпису (перевіряти один агрегований доказ замість кожного окремого підпису). Це вже використовується в ZK легких клієнтах, але, можливо, може бути розширене і на консенсус також.

9 - Вирішення

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

Повільна остаточність є особливою проблемою в комунікації між роллапами, де роллапам потрібно чекати на підтвердження від Ethereum перед тим, як зможуть схвалити транзакцію (7 днів для оптимістичних роллапів, 12 хвилин та час доведення для роллапів валідності). Це призводить до поганого досвіду користувачів. Існують кілька зусиль для вирішення цієї проблеми за допомогою попередніх підтверджень з певним рівнем безпеки. Приклади включають в себе як рішення, специфічні для екосистеми, так іБагатокутник AggLayerабоzkSync ГіперМіст) та універсальні рішення, такі як Швидкий шар швидкості Nearяка має на меті об'єднати кілька різних екосистем rollup, використовуючи економічну безпеку від EigenLayer. Є також варіантмісцеві роллап-мости, які використовують EigenLayerдля м'яких підтверджень, щоб уникнути очікування повної остаточності.

Існуючі ZK Інтеграції

• Швидший розрахунок за допомогою валідних зведень: На відміну від оптимістичних зведень, зведення валапів валідності не вимагають періоду виклику, оскільки натомість вони покладаються на ZKP, щоб довести правильний перехід стану, незалежно від того, чи хтось оскаржує чи ні (песимістичні зведення). Це значно пришвидшує розрахунки на базовому рівні (12 хвилин проти 7 днів на Ethereum) і дозволяє уникнути повторного виконання.

10 - Безпека

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

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

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

• EigenLayer має на меті використовувати існуючу безпеку Ethereum для захисту широкого спектру додатків. Біла книга була опублікована наприкінці 2023 року, і в даний час EigenLayer знаходиться в основній альфа-мережі, з повною основною мережею, очікується запуск пізніше цього року.
• Космос запустив свій Безпека міжланцюжкового(ICS) в травні 2023 року, що дозволяє Cosmos Hub - одному з найбільших ланцюжків на Cosmos, що підтримується ~$2.4 млрд ATOM, які було застосовано- надавати в оренду свою безпеку ланцюгам споживачів. Використовуючи той самий набір перевіряючих, який використовується для роботи космічного вузла, щоб також перевіряти блоки на ланцюгу споживачів, вона має на меті знизити бар'єр для запуску нових ланцюгів на основі стеку Cosmos. Проте наразі лише два ланцюги споживачів працюють(Нейтрон та Страйд).
• Babylon також намагається дозволити використовувати BTC для спільної безпеки. Щоб протистояти проблемам, пов'язаним зі злиттям майнінгу (важко покарати за погану поведінку), він створює віртуальний рівень PoS, де користувачі можуть заблокувати BTC у контракті на стейкінг на Bitcoin (без мосту). Оскільки Bitcoin не має рівня смарт-контрактів, правила скорочення контрактів на стейкінг натомість виражаються в термінах транзакцій UTXO, написаних у сценарії Bitcoin.
• Перевідпочивання на інших мережах включають Восьминігна Near та Picasso на Solana. PolkadotПарачейнитакож використовує концепцію спільної безпеки.

Існуючі ZK Інтеграції

• Змішання між ZK та економічною безпекою: Хоча гарантії безпеки на основі ZK можуть бути міцнішими - доведення все ще є надто дорогим для деяких застосувань і генерація доказу займає надто багато часу. Один приклад цього є Brevis coChain, який є співпроцесором, який отримує свою економічну безпеку від перерозподільників ETH та гарантує оптимізацію обчислень оптимістично (з підтвердженнями ZK-шахрайства). Додатки можуть вибирати між чистим ZK або режимом співланцюга, залежно від їх конкретних потреб у безпеці та вартісних умовах.

11 - Взаємодія

Безпечна та ефективна взаємодія залишається великою проблемою в світі багатьох ланцюжків, чому ілюструє $2.8bn втрачено в результаті взломів мостів. У модульних системах взаємодія стає ще важливішою - Ви спілкуєтеся не лише з іншими ланцюгами, але і модульні блокчейни потребують, щоб різні компоненти спілкувалися один з одним (наприклад, шар розповсюдження та розрахунковий шар). Таким чином, вже не є реальним просто запустити повний вузол або перевірити одне консенсус-доказ, як у інтегрованих блокчейнах. Це додає більше рухомих частин до рівняння.

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

Хоча нам ще не вистачає чіткого визначення різних типів легких клієнтів (або вузлів), цей пост від Діно(співзасновник Fluent & Modular Media) дає гарне вступ. Більшість легких клієнтів сьогодні перевіряють лише згоду, але в ідеалі ми мали б мати легкі клієнти, які можуть перевіряти виконання та DA, щоб зменшити припущення про довіру. Це дозволило б наблизитися до безпеки повного вузла, без високих вимог до обладнання.

Існуючі інтеграції ZK

• ZK легкі клієнти (перевірка згоди): Більшість поточних легких клієнтів дозволяють перевіряти згоду іншого ланцюжка - або повний набір валідаторів (якщо він досить малий), або піднабір загальних валідаторів (таких як Комітет синхронізації Ethereum). ZKPs використовуються для зроблення верифікації швидшою та дешевшою, оскільки схема підпису, яка використовується на початковому ланцюжку, може не підтримуватися на призначеному ланцюжку. Хоча важливість ZK легких клієнтів у містку очікується зростати, поточні тертя для більшої уваги включають в себе вартість доведення та верифікації разом із впровадженням ZK легких клієнтів для кожного нового ланцюжка. Приклади протоколів в цьому просторі включають Полігедри, мости підтвердження даних Avail та Celestia, та zkIBC від Electron Labs.
• Докази зберігання: Як вже зазначалося, докази зберігання дозволяють запитувати як історичні, так і поточні дані з блокчейнів без використання довірених третіх сторін. Це також важливо для міжопераційності, оскільки їх можна використовувати для міжланцюжкового зв'язку. Наприклад, користувач може довести, що у нього є токени на одному ланцюжку і використовувати їх для управління на іншому ланцюжку (без потреби в мостуванні). Також є спроби використовувати докази зберігання для мостінгу, такі як це рішення, розроблене LambdaClass.
• ZK Оракули: Оракули виступають посередниками і містять дані з реального світу у блокчейні. ZK оракули покращують поточні моделі оракулів на основі репутації, дозволяючи доводити походження та цілісність даних, разом з будь-якими обчисленнями, зробленими на цих даних.

Відкриті проблеми, які можуть вирішити ZKPs

• Повні клієнти зі світлом: Замість сліпої довіри до набору перевіряючих іншого ланцюжка - повні клієнти зі світлом також перевіряють правильне виконання та DA. Це зменшує припущення про довіру та наближає до повного вузла, при цьому зберігаючи низькі вимоги до обладнання (що дозволяє більшій кількості людей запускати легкі клієнти). Однак перевірка чого-небудь, крім консенсусу, все ще є надзвичайно дорогою на більшості ланцюжків, особливо Ethereum. Крім того, легкі клієнти дозволяють лише перевірку інформації (половина проблеми), тобто вони можуть визначити, що інформація є недостовірною, але все ж потрібен додатковий механізм для того, щоб вони могли зробити щось з цим.
• Шари агрегації: AggLayer на Polygonмає на меті забезпечити плавну взаємодію між L2 в екосистемі, використовуючи агреговані докази та єдиний міст-контракт. Агрегований доказ дозволяє як більш ефективну перевірку, так і безпеку - забезпечуючи, що залежні стани ланцюга та пакети є послідовними та гарантуючи, що стан rollup не може бути вирішено на Ethereum, якщо він залежить від недійсного стану з іншого ланцюга.HyperChains zkSync від Gate та Доступний Nexusберуть схожий підхід.

Коли ZK їв модульний стек?

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

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

1. Усі непотрібні повторні виконання усуваються: Переходячи до моделі виконання 1/N (замість N/N з повторним виконанням), ми значно зменшуємо загальну зайвість мережі та дозволяємо більш ефективно використовувати базове обладнання. Хоча залишається певні накладні витрати, це допоможе блокчейнам асимптотично наблизитися до централізованих систем з точки зору обчислювальної ефективності.
2. Більшість додатків покладаються на криптографічні гарантії, підтверджені за допомогою ZK, а не на економічну безпеку: коли вартість і час генерації доказів більше не є важливими умовами, ми вважаємо, що більшість додатків буде покладатися на ZKPs для забезпечення більш міцних гарантій. Це також вимагає певних поліпшень у використаності та зручності для розробників, які будують ZK-додатки, проте це проблеми, над вирішенням яких працюють кілька команд.

Третім умовою було б конфіденційність (або управління потоком інформації), але це складніше. ZKPs можуть бути використані для деяких додатків з конфіденційністю з доведенням на клієнтському боці, що будується для платформ, таких як Aleo, Aztec або Polygon Miden, але досягнення широкомасштабної конфіденційності для всіх потенційних використань залежить також від прогресу MPC і FHE - потенційна тема для майбутнього блог-посту.

Ризики для нашої тези

Що, якщо ми помиляємося, і майбутнє не буде ані модульним, ані ZK'fied? Деякі потенційні ризики для нашої тези включають:

Модульність збільшує складність

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

Чи буде ZK коли-небудь досить продуктивним?

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

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

Ingonyamaспробував створити деякі вимірювання продуктивності доведення через порівняльну метрику під назвою ZK оцінка. Вона базується на вартості виконання обчислень (OPEX) та відстежує MMOPS/WATT, де MMOPS означає модулярні операції множення на секунду. Для подальшого читання на цю тему ми рекомендуємо блоги від @Cysic/BJQcpVbXn?ref=blog.succinct.xyz">Cysic and @ingonyama/revisiting-paradigms-hardware-acceleration-for-zero-knowledge-proofs-5dffacdc24b4">Ingonyama, а також ця промова Вей Дай.

Чи корисна обмежена конфіденційність, яку можуть забезпечити ZKPs?

ZKPs можуть бути використані лише для забезпечення конфіденційності особистого стану, а не спільного стану, де кілька сторін повинні обчислювати на зашифрованих даних (наприклад, приватний Uniswap). FHE та MPC також необхідні для повної конфіденційності, але перед тим як вони стануть прийнятними варіантами для широкомасштабного використання, вони повинні значно покращити свої показники витрат та продуктивності. Зазначимо, що ZKPs все ще корисні для певних випадків використання, які не потребують конфіденційного спільного стану, наприклад, рішення для ідентифікації або платежі. Не всі проблеми потребують вирішення за допомогою одного й того ж інструменту.

Огляд

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

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

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

Хоча цей матеріал спрямований саме на ZKPs, ми також все більше цікавимося тим, як сучасні криптографічні рішення (ZKPs, MPC, FHE та TEE) врешті-решт будуть грати разом - щось, що ми вже бачимо.

Дякую за увагу!

Відмова від відповідальності：

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