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

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

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

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

Отримати історичні дані

Існує багато використань історичних даних блокчейну. Їх можна використовувати для підтвердження власності активів, поведінки користувачів та історії транзакцій, а потім вводити їх в онлайн-смарт-контракти чи додатки.На момент написання більше 18 мільйонів блоків було записано в Ethereum.Розумні контракти можуть отримувати доступ лише до останніх 256 блоків (або даних за останні 30 хвилин), тому термін "історичні дані" вказує на все, що не входить в останні 256 блоків.

Сьогодні, для доступу до історичних даних протоколи часто запитують архівний вузолпостачальники, тобто сторонні сторони, такі як Infura, Alchemy або інші індексатори. Це означає довіру та покладання на них і їх дані.

Історичні дані

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

Історичні дані

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

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

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

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

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

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

Які випадки використання для доказу зберігання?

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

Спочатку зберігання доказів може підтвердити будь-які історичні дані на джерелі блокчейну, такі як

1. Баланс рахунку та власність на токени
2. Діяльність користувача або статичний стан торгівлі
3. Історична ціна угоди з активом протягом вказаного періоду часу
4. Пул ліквідності міжланцюжкових реальних активів в реальному часі

Підтвердження може бути відправлено на цільовий ланцюжок для розблокування ряду використань міжланцюжкового зв'язку:

1. Дозволяє користувачам голосувати за управлінські пропозиції на угоди на більш низькій вартості на другому рівні
2. Дозволяючи власникам NFT отримувати нові монети NFT або користуватися благами спільноти на новому ланцюжку
3. Винагороджуйте користувачів на основі їх історії та взаємодій з конкретними додатками (наприклад, через роздачі)
4. Позики, які пропонують індивідуальні процентні ставки на основі загальної історії транзакцій та кредитної історії користувача
5. Запустіть відновлення облікового запису для неактивних облікових записів
6. Обчислення історії майбутніх обмінів TWAP
7. Розрахуйте більш точні ціни на обмін AMM на основі пулів ліквідності на декількох ланцюгах

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

Випадки використання доказів зберігання

Давайте візьмемо докладний приклад, щоб зрозуміти, як працює доказ зберігання.

Як працює доказ зберігання: Детальні приклади

Припустимо, що “X” - це протокол DeFi з токенами на Ethereum. Пропозиція щодо управління має бути висунута, і вони хочуть просувати голосування на ланцюжках з меншими витратами. Користувачі можуть голосувати лише у випадку, якщо вони утримують токени X на Ethereum в конкретний момент часу (ми називаємо це “знімком”), таким як блок # 17,000,000

Як зараз проводиться голосування на ланцюгу?

Поточний підхід полягає в запиті архівного вузла, щоб отримати повний список вибраних власників токенів на блоках №17 ,000,000. Адміністратор DAO потім зберігає цей список в розумному контракті на цільовому ланцюжку, щоб визначити, хто може голосувати. Існує кілька обмежень цього підходу:

1. Список виборців може бути дуже довгим, і кожен знімок змінюється, що ускладнює зберігання та оновлення кожного виборчого пропозиції on-chain;
2. Існує неявна довіра до постачальника вузла архіву та наданої ним даних;
3. Члени, що керують DAO, повинні бути довірені, щоб не втручатися у список виборців

Як доказ зберігання вирішує цю проблему?

Як ми пояснили в статті 2, дорогі обчислення можуть бути перенесені на нуль-знання поза ланцюжком.

ZK атестатор згенерує короткий доказ і відправить його на цільовий ланцюг для перевірки. Для вищезазначених прикладів визначеності виборців DAO наступне:

1. Атестатор генерує доказ про нульовий вміст, що блок #17,000,000 є частиною історії Ethereum (як у першому кроці вище).
2. Після підтвердження валідності блоку ми можемо використовувати Меркле, щоб включити доказ того, що користувач утримував токени DAO, коли блок був завершений (як у кроці 2 вище*)

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

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

Цей підхід вирішив декілька проблем. Йому не потрібно:

Довіряйте постачальнику вузла архіву;

1. нехай угода зберігає дорогі списки виборців on-chain;
2. Для користувачів переносити активи на ланцюг призначення

Які налаштування потрібні для доказу зберігання?

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

1. Повний ланцюг нуль-знання доказу («зк обіцянка»): постачальник послуг групує всі історичні блоки на джереловому ланцюгу в неперервні фіксованого розміру «блоки» (з використанням дерев Меркля)і генерує нульові докази для кожного блоку, які використовуються для перевірки групувань. Ці докази потім рекурсивно комбінуються до отримання остаточного доказу нульового знання, «обіцянка zk» всьому ланцюжку. Це доводить, що постачальник правильно проіндексував всю історію ланцюжка.

Обіцянка 'zk' пояснює весь історію Ethereum

• **Гірський діапазон Меркле:** Постачальник також зберігає корені Merkle Keccak хешів хешів блоків джерела ланцюга (блоки), згруповані в структуру даних на ланцюжку, яка називається Гірським діапазоном Меркла (MMR). Ця структура даних використовується, оскільки вона легко запитується та оновлюється, і дозволяє постачальникам ефективно доводити, що певний блок існує в історії ланцюга. MMR створюється за допомогою хешу Keccak256, хешу Poseidon або обох. Хеші Poseidon більш дружні до нульового знання та підтримують обчислення історичних даних. Пізніше можна буде довести правильність даних та обчислень за допомогою нульового знання.

Ілюстрація гірського хребта Меркель (MMR)

При додаванні нових блоків до джерела ланцюжка постачальники послуг регулярно (наприклад, щогодини або щодня) оновлюють "zk зобов'язання" та MMR, щоб встигати за темпом ланцюжка. Це робиться для того, щоб минулий блок завжди був пов'язаний з одним з 256 блоків, які в даний момент доступні з EVM. Це забезпечує, що історичні дані пов'язані з одним з блоків, які в даний момент доступні на Ethereum.

На зображенні нижче ми докладно описали, як завершити налаштування:

У підсумку, нижче показано, як використовувати доказ зберігання після завершення налаштування у контексті прикладу голосування DAO, про який ми говорили раніше:

1. Постачальники послуг створюють та зберігають «zk обіцянки» для всього ланцюжка (тобто історія Ethereum) та MMR на цільовому ланцюжку
2. Постачальник дозволяє додаткам запитувати історичні дані on-chain або off-chain через API
3. Голосувальний додаток на ланцюжку цілей надсилає запит до смарт-контракту провайдера, щоб дізнатися, чи у користувача є токени DAO на блоках №17,000,000 на Ethereum

Постачальник перевірить дві речі:

1. Запитаний блок є частиною регуляторної історії Ethereum (перший крок вище); потім постачальник генерує доказ нуль-знання вмісту блоку через гірський діапазон Меркле
2. Користувач утримує токени DAO в блоку #17,000,000 (крок 2 вище); потім постачальник генерує ще одне доказ нульового знання, що користувач утримує токени DAO в межах блоку
3. Постачальник агрегує доказ, згенерований вище, в доказ нульового знання
4. Агрегований ZK-доказ відправляється назад до розумного договору голосування dApp на цільовому ланцюжку для перевірки ZK-доказу та дозволу користувачеві голосувати, якщо перевірка пройшла успішно.

Формування команди в цій галузі

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

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

Протокол Relicнадає технічний підхід, схожий на Аксіом, протокол працює на Ethereum та zkSync Era. Relic використовує докази включення Меркля для підтвердження включення даних (на відміну від методу підтвердження включення Меркля в нульовому знанні у Аксіома).

Геродотпрацює над забезпеченням історичних даних про Ethereum для протоколів 2 рівня. Тестова реалізація тепер доступна на Starknet та zkSync Era. За фінансуванням від Фонду OP ми вважаємо, що знаємо, куди наступним кроком рухається команда Геродота.

Лабораторії Лагранж Лабсвпровадило повністю оновлюване доказ через свою останню інновацію ZK MapReduce (ZKMR). Воно використовує нове векторне обіцянку під назвою Recproofsрозширити концепцію можливості оновлення обчислення даних.

Команди, які працюють над сертифікацією зберігання

епілог

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

Оскільки загальна заблокована вартість (TVL) продовжує мігрувати з Ethereum до екосистеми рівня 2, ми передбачаємо появу більш виразних додатків, які використовують історичні дані on-chain через докази зберігання.

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

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

Disclaimer：

1. Цю статтю перепечатано з [ дзеркало]. Усі авторські права належать оригінальному авторові [Jacob, Hitesh, Ji Hao]. Якщо є заперечення щодо цього перевидання, будь ласка, зв'яжіться з командою Gate Learn（gatelearn@gate.io), і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно думкою автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат статей, перекладених іншими мовами, заборонені.