В нашем предыдущем посте, который был бы действенным, мы обсудили роль консенсусного доказательства этого нового метода минимизации доверия в облегчении моста между блокчейнами.

В этой статье мы рассмотрим доказательство хранения, которое берет концепцию минимизации доверия и расширяет ее на транзакции в старых исторических блоках. Возможность проверять прошлые транзакции и деятельность пользователей таким образом открывает широкий спектр кросс-цепочечных случаев использования.

В наших предыдущий постМы представили Proof of Consensus — подход к минимизации доверия при мостиковании средств между блокчейнами. Поскольку пользователи моста обычно хотят видеть моментальное осуществление транзакций в самый последний момент, доказательство консенсуса очень полезно, потому что они постоянно проверяют последнее состояние блокчейна в процессе его работы.

Эта концепция минимизации доверия к мостам также может быть применена в другом направлении, которое заключается в возвращении к прошлому и использовании доказательств нулевого знания для верификации транзакций и данных в старых блоках. Эти "доказательства исторического хранения" поддерживают разнообразный спектр межцепочных случаев использования, и в этой статье мы рассмотрим эти случаи использования, как они работают, и актеров, построенных в этом пространстве.

Извлечь исторические данные

Существует много способов использования исторических данных блокчейна. Их можно использовать для подтверждения владения активами, поведения пользователей и истории транзакций, а затем вводить их в смарт-контракты или приложения на цепочке.На момент написания было написано более 18 миллионов блоков в Ethereum.Смарт-контракты могут обращаться только к последним 256 блокам (или данным за последние 30 минут), поэтому "исторические данные" означают все, что не относится к последним 256 блокам.

Сегодня, чтобы получить доступ к историческим данным, протоколы часто запрашивают узел архивапоставщики, т.е. третьи стороны, такие как Infura, Alchemy или другие индексаторы. Это означает доверие и полагание на них и их данные.

Исторические данные

Эти данные, однако, могут быть расслаблены более доверительным образом через использование доказательств хранения.

Исторические данные

Однако эти данные можно извлечь более доверенным способом, используя доказательства хранения.

Доказательство хранения - это доказательство нулевого знания, которое позволяет проверить исторические данные, хранящиеся в блокчейне. Более конкретно, доказательство хранения может быть использовано для доказательства существования определенного состояния в определенном блоке в прошлом.Этот подход не требует доверия к третьим сторонам или оракулам; вместо этого его доверие встроено в доказательство хранения.

Как доказательства хранения могут помочь подтвердить, что некоторые данные существуют в старых исторических блоках? Для этого необходимо проверить две вещи:

• Первый шаг - проверить, является ли конкретный блок частью регулятивной истории блокчейна, то есть, блок является допустимой частью истории исходной цепочки
• Второй шаг - проверить, входит ли конкретные данные в блок, то есть, является ли кусок информации (например, конкретная транзакция) частью блока (это можно доказать, включив доказательство Меркла)

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

Проще говоря, доказательство хранения поддерживает извлечение данных в исторической цепочке таким образом, чтобы свести к минимуму доверие. Это важно, потому что, как мы уже отмечали в нашем первом посте, в ближайшие несколько лет мы видим, что web3 станет более многоцепочечным и многоуровневым пространством. Появление нескольких протоколов уровня 1, роллапов и цепочек приложений означает, что ончейн-активность пользователей может быть разбросана по нескольким цепочкам. Это еще раз подчеркивает потребность в решениях для обеспечения функциональной совместимости, минимизирующих доверие, которые поддерживают компонуемость пользовательских активов, удостоверений и истории транзакций в нескольких доменах. Это проблема, которую может помочь решить доказательство хранилища.

Каковы сценарии использования для доказательства хранения?

Доказательство хранения позволяет смарт-контрактам проверять любые исторические транзакции или данные в качестве предпосылки. Это делает дизайн приложений для взаимодействия цепочек более гибким.

Сначала, хранение доказательств может доказать любые исторические данные на исходной блокчейне, такие как

1. Баланс счета и владение токенами
2. Активность пользователя в торговле или статическое состояние
3. Историческая цена сделки по активу за определенный период времени
4. Баланс активов пула ликвидности межцепочечного взаимодействия в реальном времени

Доказательство затем может быть отправлено на целевую цепь для разблокировки широкого спектра кросс-цепных случаев использования:

1. Позволяет пользователям голосовать за предложения по управлению на дешевых соглашениях уровня 2
2. Позволяя держателям NFT получать новые монеты NFT или сообщественные выгоды на новой цепи
3. Награждайте пользователей на основе их истории и взаимодействия с конкретными dApps (например, через airdrops)
4. Кредиты, предлагающие индивидуальные процентные ставки на основе общей истории транзакций и кредитной истории пользователя
5. Запустить восстановление учетной записи для забытых аккаунтов
6. Расчет истории средневзвешенной цены фьючерсных свопов
7. Рассчитывайте более точные цены на обмен AMM на основе ликвидности мультицепных пулов

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

Применение доказательства хранения

Давайте рассмотрим подробный пример, чтобы понять, как работает доказательство хранения.

Как работает доказательство хранения: Подробные примеры

Предположим, что «X» - это протокол DeFi с токенами на Ethereum. Предложение по управлению собирается быть выдвинуто, и им хотят продвигать голосование на цепях с более низкой стоимостью. Пользователи могут голосовать только в том случае, если они держат токены X на Ethereum в определенный момент времени (мы называем это «снимком»), например, на блоке №17 000 000.

Как в настоящее время проводится голосование на цепи?

Текущий подход заключается в запросе узла архива для получения полного списка участников токенов на блоке #17 000 000. Затем администратор DAO сохраняет этот список в смарт-контракте на целевой цепочке, чтобы определить, кто может голосовать. У этого подхода есть несколько ограничений:

1. Список избирателей может быть очень длинным, и каждый снимок меняется, что делает дорогостоящим хранение и обновление каждого предложения по голосованию на цепи;
2. В поставщика узла архива и предоставляемых им данных вложено неявное доверие;
3. Участники, управляющие DAO, должны быть доверены, чтобы не вмешиваться в список избирателей

Как доказательство хранения решает эту проблему?

Как мы объяснили в статье 2, дорогостоящие вычисления могут быть переданы на нулевые доказательства вне цепи блоков.

Zk аттестатор сгенерирует краткое доказательство и отправит его на целевую цепь для проверки. Для приведенных выше примеров права голоса в DAO следующее:

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

Проверьте исторические данные, чтобы активировать голосование межцепочечного взаимодействия

Доказательство затем отправляется на смарт-контракт на целевой цепочке для верификации. Если верификация успешна, то смарт-контракт на протоколе уровня 2 позволяет пользователям голосовать.

Этот подход решил несколько проблем. Это не требует:

Доверяйте провайдеру узла архива;

1. пусть соглашение поддерживает дорогостоящие списки избирателей на цепи;
2. Для пользователей передача активов в цепочку целей

Какие настройки требуются для доказательства хранения?

До сих пор мы абстрагировали некоторые сложности доказательств хранения. Однако для их использования также требуется тщательная начальная настройка со стороны поставщика услуг, чтобы гарантировать, что они могут быть использованы без доверия к поставщику. В ходе этого процесса генерируются и сохраняются две вещи на цепи:

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

Обещание zk объясняет всю историю Ethereum

• **Merkle Mountain Range: ** Провайдер также хранит Keccak Merkle roots хэшей блоков (блоков) исходной цепи, сгруппированных вместе в структуру данных на цепи, называемую Merkle Mountain Range (MMR). Эта структура данных используется, потому что ее легко запросить и обновить, и позволяет провайдерам эффективно доказать, что данный блок существует в истории цепи. MMR создается с использованием хэша Keccak256, хэша Poseidon или обоих. Хеши Poseidon более дружелюбны к нулевому знанию и поддерживают вычисление исторических данных. Правильность данных и вычислений позже можно будет доказать с помощью нулевого знания.

Иллюстрация горного массива Меркель (MMR)

Поскольку к новым блокам добавляются в исходной цепочке, поставщики услуг регулярно (например, ежечасно или ежедневно) обновляют «zk commitment» и MMR, чтобы не отставать от темпа цепочки. Это делается так, чтобы прошлый блок всегда был связан с одним из 256 блоков, которые в настоящее время доступны из EVM. Это гарантирует, что исторические данные связаны с одним из блоков, доступных в настоящее время на Ethereum.

На изображении ниже мы подробно рассказали, как завершить настройку:

В заключение, в следующем показано, как использовать доказательство хранения после завершения настройки в контексте примера голосования DAO, который мы рассмотрели ранее:

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

Поставщик проверит две вещи:

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

Формирование команды в этой области

Некоторые участники создают смарт-контракты, которые позволяют смарт-контрактам получать доступ к данным исторических цепочек таким образом, что доверие минимизируется.

В настоящее время, Аксиома работает на Ethereum и нацелен на предоставление смарт-контрактов на Ethereum и доступ к историческим данным Ethereum через доказательства хранения на основе zk. Команда также улучшает возможности вычислений вне цепи на основе исторических данных и использует нулевое знание для подтверждения точности этих данных и вычислений.

Протокол реликвийпредоставляет технический подход, аналогичный Axiom, и протокол работает на Ethereum и zkSync Era. Relic использует доказательства включения Merkle для доказательства включения данных (в отличие от метода доказательства включения Merkle в нулевом знании Axiom).

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

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

Команды, работающие над сертификацией хранения

эпилог

В этой статье мы описали, как доказательство хранения может поддерживать проверку данных на исторической цепочке без доверия к третьим сторонам. Это делает их ценным инструментом для составления цепочек и межцепочечной совместимости.

Поскольку общая заблокированная стоимость (TVL) продолжает переходить с Ethereum в экосистему уровня 2, мы ожидаем появления более выразительных приложений, использующих исторические данные on-chain через доказательства хранения.

Пока технология нулевого доверия становится быстрее и дешевле, непрерывное создание доказательств хранения для поддержания затрат, связанных с нахождением в сети, по-прежнему остается вызовом. Прибыльность таких услуг будет зависеть от объема запросов, генерируемых приложением запросов.

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

Отказ от ответственности:

1. Эта статья перепечатана с [ зеркало]. Все авторские права принадлежат оригинальному автору [Джейкоб, Хитеш, Джи Хао]. Если у вас есть возражения против этого перепечатывания, пожалуйста, свяжитесь с командой Gate Learn（gatelearn@gate.io）, и они немедленно этим займутся.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционной рекомендацией.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.