Введение

Что, если бы Вы теряли память каждый час? И Вам нужно постоянно просить кого-то рассказать Вам, что Вы сделали? Таково текущее состояние смарт-контрактов. На таких блокчейнах, как Ethereum, смарт-контракты не могут напрямую обращаться к состояниям, выходящим за пределы 256 блоков. Эта проблема еще более усугубляется в многоцепочечной экосистеме, где поиск и проверка данных на разных уровнях исполнения еще более затруднены.

В 2020 году Виталик Бутерин и Томаш Станчак предложили способ доступа к данным во времени. Несмотря на то, что EIP застоялся, его необходимость вновь возникла в мире мультицепочек, ориентированных на рулоны. Сегодня доказательства хранения появились как передовой рубеж, чтобы придать смарт-контрактам осознанность и память.

Доступ к данным о цепи

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

Доверие к людям/существам:

• Архивные узлы: Операторы могут сами запустить архивный узел или прибегнуть к услугам поставщиков архивных узлов, таких как Alchemy или Infura, чтобы получить доступ ко всем данным, начиная с блока Genesis. Они предоставляют все те же данные, что и полный узел, а также все исторические данные о состоянии всего блокчейна. Такие внецепочечные сервисы, как Etherscan и Dune Analytics, используют архивные узлы для доступа к данным на цепочке. Участники вне цепочки могут подтвердить достоверность этих данных, а смарт-контракты на цепочке могут проверить, что данные были подписаны доверенным участником/комитетом. Целостность базовых данных не проверяется. Этот подход требует от dapp доверия к тому, что поставщик услуг архивных узлов управляет инфраструктурой правильно и без злого умысла.

Доверьтесь экономической безопасности криптовалют:

• Индексаторы: Протокол индексирования организует все данные в блокчейне, позволяя разработчикам создавать и публиковать открытые API, к которым могут обращаться приложения. Индивидуальные индексаторы - это операторы узла, которые ставят токены для предоставления услуг индексирования и обработки запросов. Однако могут возникнуть споры, если поданные данные неверны, и арбитражный процесс может занять много времени. Более того, данные из таких индексаторов, как The Graph, не могут напрямую использоваться бизнес-логикой смарт-контрактов и применяются в контексте web2-анализа данных.
• Оракулы: Поставщики услуг Oracle используют данные, агрегированные от многих независимых операторов узлов. Проблема здесь заключается в том, что данные, доступные в Oracles, могут обновляться нечасто и имеют ограниченный объем. Оракулы, подобные Chainlink, обычно хранят только определенные состояния, например, информацию о ценах, и для специфических для приложения состояний и истории они не подходят. Более того, этот подход также вносит определенный уровень отклонений в данные и требует доверия к операторам узлов.

Код доверия:

• Специальные переменные и функции: В блокчейнах, таких как Ethereum, есть специальные переменные и функции, которые в основном используются для предоставления информации о блокчейне или являются утилитарными функциями общего назначения. Только смарт-контракт может получить доступ к хэшу 256 последних блоков. По причинам масштабируемости хэши блоков доступны не для всех блоков. Доступ к историческим хэшам блоков был бы полезен, так как позволил бы проверять доказательства по ним. В процессе выполнения EVM нет опкода, позволяющего получить доступ к содержимому старого блока, содержимому предыдущей транзакции или выходу квитанции, поэтому узел может спокойно забыть об этих вещах и по-прежнему обрабатывать новые блоки. Этот метод также ограничен одним блокчейном.

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

Хранение данных в блокчейне

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

В качестве примера возьмем блок Ethereum. В Ethereum используется особый тип дерева Меркле, известный как "дерево Меркле-Патриция" (MPT). Заголовки блоков Ethereum содержат корни четырех различных попыток Меркла-Патриция, т.е. Тройка состояний, тройка хранения, тройка поступлений и тройка транзакций. Эти 4 попытки кодируют отображения, из которых состоят все данные Ethereum. Деревья Меркле используются благодаря своей эффективности при хранении данных. При использовании рекурсивных хэшей в конечном итоге нужно хранить только корневой хэш, что позволяет сэкономить много места. Они позволяют любому доказать существование элемента в дереве, доказав, что рекурсивное хэширование узлов приводит к одному и тому же корневому хэшу. Доказательства Меркла позволяют легким клиентам на Ethereum получать ответы на такие вопросы, как:

• Существует ли эта транзакция в определенном блоке?
• Каков текущий баланс моего счета?
• Существует ли такой счет?

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

Доказательства хранения

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

Что могут дать доказательства хранения?

Доказательства хранения позволяют выполнять две основные функции:

1. Доступ к историческим данным о цепочке за пределами последних 256 блоков, вплоть до блока генезиса
2. Доступ к данным на цепи (как историческим, так и текущим) одного блокчейна на другом блокчейне с помощью проверки консенсуса или моста L1-L2 в случае L2

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

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

• Обработка на цепочке: dapps могут взять начальный доверенный блок, передать этот блок в качестве calldata для доступа к предыдущему блоку и пройти весь путь назад до генезисного блока. Это требует большого количества вычислений в цепи и огромного количества данных о звонках. Такой подход совершенно непрактичен из-за огромного объема вычислений, требуемых на цепочке. В 2018 году компания Aragon пыталась использовать подход "на цепи", но это оказалось нецелесообразным из-за высокой стоимости "на цепи".
• Использование ZK-доказательств: Этот подход похож на обработку на цепи, за исключением того, что для переноса сложных вычислений за пределы цепи используется ZK-доказательство.

1. Доступ к данным по одной и той же цепочке: ZK-доказательство можно использовать для утверждения, что произвольный исторический заголовок блока является предком одного из 256 самых последних заголовков блока, доступных в среде выполнения. Другой подход заключается в том, чтобы проиндексировать всю историю исходной цепочки и сгенерировать ZK-доказательство этого, чтобы доказать, что индексация произошла правильно. Это доказательство регулярно обновляется по мере добавления новых блоков в исходную цепочку. Доступ к данным между цепочками: Провайдер собирает заголовки блоков исходной цепочки в цепочке назначения и подтверждает достоверность этих заголовков блоков с помощью доказательства консенсуса ZK. Также можно использовать существующее решение AMP, например, Axelar, Celer или LayerZero, для запроса заголовков блоков.
2. Кэш хэшей заголовков блоков исходной цепочки или корневой хэш аккумулятора хэшей блоков вне цепочки хранится в цепочке назначения. Этот кэш обновляется на регулярной основе и используется для эффективного доказательства на цепи, что данный блок существует и имеет криптографическую связь с недавним хэшем блока, доступным из состояния. Этот процесс известен как доказательство непрерывности цепи. Также можно использовать специальный блокчейн для хранения заголовков блоков всех исходных цепочек.
3. Доступ к историческим данным/блоку осуществляется из индексированных данных вне цепочки или кэша на цепочке (в зависимости от сложности запроса) по запросу dapp на целевой цепочке. В то время как кэш хэша заголовков блоков хранится на цепи, фактические данные могут храниться вне цепи.
4. Существование данных в указанном блоке проверяется с помощью доказательств включения Меркла и генерируется zk-доказательство для этого блока. Это доказательство объединяется с доказательством правильности индексации zk или доказательством консенсуса ZK, и доказательство становится доступным в цепи для проверки без доверия.
5. Затем dapps могут проверить это доказательство на цепи и использовать данные для выполнения желаемого действия. Наряду с проверкой ZK-доказательства, такие открытые параметры, как номер блока и хэш блока, проверяются по кэшу заголовков блоков, хранящемуся на цепи.

Некоторые из проектов, использующих этот подход, - Herodotus, Lagrange, Axiom, Hyper Oracle, Brevis Network и nil foundation. В то время как прилагаются значительные усилия для того, чтобы сделать приложения с поддержкой состояния в нескольких блокчейнах, IBC (Inter Blockchain Communication) выделяется как стандарт совместимости, который позволяет использовать такие приложения, как ICQ (Interchain queries) и ICA (Interchain accounts). ICQ позволяет приложениям на цепочке A запрашивать состояние цепочки B, включив запрос в простой пакет IBC, а ICA позволяет одному блокчейну безопасно контролировать учетную запись на другом блокчейне. Комбинируя их, можно создавать интересные сценарии использования цепочки. RaaS-провайдеры, такие как Saga, предлагают эти функции всем своим цепочкам приложений по умолчанию, используя IBC.

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

• Доступ к данным
• Обработка данных
• ZK Генерация доказательств для доступа к данным и их обработки

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

• Существующая блокчейн Ethereum: Существующая структура блокчейна Ethereum может быть использована для доказательства ценности любого исторического слота хранения по отношению к текущему блокчейну с помощью ZKP. Это можно представить как одно большое доказательство включения. Доказано, что для недавнего блочного заголовка X на высоте b существует блочный заголовок Y, который является предком X на высоте b-k. Он основан на безопасности консенсуса Ethereum и требует быстрой системы проверки для обеспечения эффективности. Такой подход использовал Лагранж.
• Цепочечный кэш Merkle Mountain Ranges (MMR): Горный хребет Меркла можно рассматривать как список деревьев Меркла, в котором отдельные деревья Меркла объединяются, когда два дерева достигают одинакового размера. Отдельные деревья Меркле в MMR объединяются путем добавления родительских узлов к предыдущим корням деревьев. MMR - это структура данных, похожая на деревья Меркла с некоторыми дополнительными преимуществами, такими как эффективное добавление элементов и эффективные запросы к данным, особенно при чтении последовательных данных из больших массивов данных. Добавление новых заголовков с помощью дерева Меркла потребует прохождения всех сестринских узлов на каждом уровне. Чтобы эффективно добавлять данные, Axiom использует MMR для хранения кэша хэшей заголовков блоков в цепи. Herodotus хранит корневой хэш аккумулятора хэша блока MMR на цепи. Это позволяет им проверять полученные данные на соответствие хэшам заголовков блоков с помощью доказательств включения. Такой подход требует регулярного обновления кэша и влечет за собой проблемы, связанные с "быстродействием", если он не децентрализован.
• Геродот поддерживает два разных MMR. В зависимости от конкретного блокчейна или уровня, аккумуляторы могут быть настроены на использование различных функций хэширования, оптимизируя эффективность и вычислительные затраты. Для проверки в Starknet можно использовать хэш poseidon, а для цепочек EVM - хэш Keccack.
• Внецепочечный кэш MMR: Herodotus поддерживает внецепочечный кэш ранее полученных запросов и результатов, чтобы ускорить получение данных в случае, если они будут запрошены снова. Это требует дополнительной инфраструктуры по сравнению с простым запуском архивного узла. Оптимизация, проведенная в инфраструктуре вне цепочки, может потенциально снизить затраты для конечного пользователя.
• Выделенный блокчейн для хранения данных: Brevis полагается на выделенный ZK-рулон (уровень агрегации) для хранения всех заголовков блоков всех цепочек, которые они заверяют. Без этого агрегирующего слоя каждой цепочке пришлось бы хранить заголовки блоков для каждой другой цепочки, что привело бы к O(N2) "соединений" для N блокчейнов. Благодаря внедрению агрегирующего слоя, каждому блокчейну нужно хранить только корень состояния для сворачивания, что сокращает общее количество соединений до O(N). Этот уровень также используется для объединения нескольких доказательств для заголовков блоков/результатов запросов, и может быть представлено одно доказательство для проверки на каждом подключенном блокчейне.
• Передача сообщений L1-L2: Проверки консенсуса цепочки источников можно избежать в случае L2, поскольку L2 поддерживают передачу сообщений для обновления контрактов L2 на L1. Кэш может обновляться на Ethereum, а передача сообщений L1-L2 может использоваться для отправки хэша блока или корня дерева, составленного вне цепочки, другим L2. Геродот использует этот подход, но для alt L1 это не представляется возможным.

Обработка данных:

Наряду с доступом к данным, смарт-контракты должны иметь возможность выполнять произвольные вычисления поверх данных. Хотя для некоторых случаев использования вычисления могут и не потребоваться, они являются важной дополнительной услугой для многих других случаев использования. Многие поставщики услуг позволяют производить вычисления на данных, поскольку zk-доказательство вычислений может быть сгенерировано и предоставлено на цепочке для проверки достоверности. Поскольку существующие решения AMP, такие как Axelar, LayerZero, Polyhedra Network, потенциально могут быть использованы для доступа к данным, обработка данных может стать отличительным фактором для поставщиков услуг хранения данных.

Hyper Oracle, например, позволяет разработчикам определять пользовательские вычисления вне цепочки с помощью JavaScript. Компания Brevis разработала открытый рынок ZK Query Engines, который принимает запросы данных от dApps и обрабатывает их, используя подтвержденные заголовки блоков. Смарт-контракт отправляет запрос на данные, который подхватывается проверяющим с рынка. Доказательство генерируется на основе входных данных запроса, заголовков соответствующих блоков (из агрегирующего слоя Brevis) и результатов. Компания Lagrange представила ZK Big Data Stack для подтверждения моделей распределенного программирования, таких как SQL, MapReduce и Spark/RDD. Доказательства являются модульными и могут быть сгенерированы из любого заголовка блока, исходящего от существующих межцепочечных мостов и протоколов AMP. ZK MapReduce, первый продукт в стеке Lagrange ZK BigData, представляет собой механизм распределенных вычислений (основанный на известной модели программирования MapReduce) для доказательства результатов вычислений с использованием больших наборов многоцепочечных данных. Например, одно доказательство ZKMR может быть использовано для подтверждения изменений в ликвидности DEX, развернутого на 4-5 цепочках, за определенный промежуток времени. Для относительно простых запросов вычисления также могут выполняться непосредственно на цепи, как это делает Herodotus в настоящее время.

Генерация доказательств:

• Обновляемые доказательства: Обновляемые доказательства могут использоваться, когда доказательство должно быть вычислено и эффективно поддерживаться в движущемся потоке блоков. Когда dapp хочет поддерживать доказательство скользящего среднего для переменной контракта (например, цены токена), по мере создания новых блоков, не вычисляя новое доказательство с нуля, существующие доказательства могут быть эффективно обновлены. Чтобы доказать динамическое параллельное вычисление данных на цепочке состояний, Лагранж строит пакетное векторное обязательство, называемое Recproof, поверх части MPT, обновляет его на лету и динамически вычисляет над ним. Рекурсивно создавая дерево Веркле поверх MPT, Лагранж может эффективно вычислять большие объемы динамических данных о состоянии цепи.
• Деревья Веркле: В отличие от деревьев Меркле, где нам нужно указать все узлы, имеющие общего родителя, деревьям Веркле требуется только путь к корню. Этот путь гораздо меньше по сравнению со всеми родственными узлами в случае дерева Меркла. Ethereum также изучает возможность использования деревьев Веркле в будущих выпусках, чтобы минимизировать объем состояния, которое должны хранить полные узлы Ethereum. Brevis использует дерево Веркле для хранения проверенных заголовков блоков и результатов запросов на уровне агрегации. Он значительно уменьшает размер доказательства включения данных, особенно когда дерево содержит большое количество элементов, а также поддерживает эффективное доказательство включения для пакета данных.
• Мониторинг Mempool для более быстрой генерации доказательств: Недавно Herodotus анонсировал turbo, который позволяет разработчикам добавить несколько строк кода в код своего смарт-контракта, чтобы указать запрос данных. Herodotus отслеживает мемпул на предмет транзакций смарт-контракта, которые взаимодействуют с турбо-контрактом. Процесс создания доказательства начинается, когда транзакция находится в самом мемпуле. После того, как доказательство сгенерировано и проверено на цепочке, результаты записываются в турбо-своп-контракт на цепочке. Результаты могут быть записаны в контракт турбо-свопа только после того, как они будут подтверждены доказательствами хранения. Как только это происходит, часть комиссии за транзакцию передается секвенсору или блокчейну, что стимулирует их подождать немного дольше, чтобы собрать комиссию. Для простых запросов данных возможно, что запрашиваемые данные становятся доступными на цепочке до того, как транзакция от пользователя будет включена в блок.

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

Доказательства состояния и хранения могут открыть множество новых вариантов использования смарт-контрактов на уровне приложений, промежуточного программного обеспечения и инфраструктуры. Вот некоторые из них:

Прикладной уровень:

Управление:

• Межцепочечное голосование: Протокол голосования на цепочке может позволить пользователям цепочки B подтвердить право собственности на активы цепочки A. Пользователям не придется переносить свои активы, чтобы получить право голоса на новой цепочке. Пример: SnapshotX о Геродоте
• Распределение токенов управления: Приложения могут распространять больше токенов управления среди активных пользователей или ранних последователей. Пример: RetroPGF по Лагранжу

Идентичность и репутация:

• Доказательство владения: Пользователь может предоставить доказательство владения определенным NFT, SBT или активами на цепочке А, что позволит ему выполнять определенные действия на цепочке В. Например, цепочка игровых приложений может решить запустить сбор NFT на другой цепочке с существующей ликвидностью, например, Ethereum или любой L2. Это позволит игре использовать ликвидность, существующую в других местах, и создать мост для NFT, не требуя на самом деле создания мостов для NFT.
• Доказательство использования: Пользователям могут быть предоставлены скидки или премиальные возможности на основании их исторического использования платформы (докажите, что пользователь торговал объемом X на Uniswap).
• Доказательство OG: Пользователь может доказать, что он/она владеет активным аккаунтом, которому более X дней
• Цепочечная кредитная история: Многоцепочечная платформа кредитных баллов может объединять данные из нескольких аккаунтов одного пользователя для создания кредитного балла

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

Дефи:

• Межцепочечное кредитование: Пользователи могут заблокировать активы в цепи A и взять кредит в цепи B вместо того, чтобы соединять токены.
• Страхование на цепочке: Сбои можно определить, получив доступ к историческим данным о цепочке, а страховка может быть полностью урегулирована на цепочке.
• TWAP цены актива в пуле: Приложение может рассчитать и получить среднюю цену актива в пуле AMM за определенный период времени. Пример: Uniswap TWAP Oracle с Axiom
• Ценообразование опционов: протокол опционов на цепочке может определить цену опциона, используя волатильность актива за последние n блоков на децентрализованной бирже.

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

Среднее программное обеспечение:

• Намерения: Доказательства хранения позволят пользователям более четко и ясно выражать свои намерения. Хотя работа решателей заключается в выполнении необходимых шагов для реализации намерений пользователя, пользователь может более четко определить условия, основываясь на данных и параметрах цепи. Решатели также могут подтвердить достоверность данных о цепочке, использованных для поиска оптимального решения.
• Абстракция аккаунта: Пользователи могут полагаться на данные, поступающие из других цепочек, используя доказательства хранения для установления правил через Account Abstraction. Пример: У каждого кошелька есть свой nonce. Мы можем доказать, что год назад nonce был определенным числом, и в настоящее время nonce такой же. Это может быть использовано для доказательства того, что данный кошелек вообще не использовался, и доступ к нему может быть передан другому кошельку.
• Автоматизация на цепи: Умные контракты могут автоматизировать определенные действия на основе заранее заданных условий, которые зависят от данных в цепи. Автоматизированные программы должны вызывать смарт-контракты через определенные промежутки времени, чтобы поддерживать оптимальный ценовой поток в AMM или поддерживать здоровые протоколы кредитования, избегая безнадежных долгов. Hyper Oracle обеспечивает автоматизацию и доступ к данным в цепочке.

Инфраструктура

• Доверительный цепной оракул: Децентрализованные сети оракулов объединяют ответы от множества отдельных узлов оракула в пределах сети оракулов. Oracle Networks может устранить эту избыточность и использовать криптографическую защиту для данных в цепи. Сеть Oracle может собирать данные из нескольких цепочек (L1, L2 и alt L1) в одну цепочку и просто доказывать их существование, используя доказательства хранения в других местах. Решения DeFi, имеющие значительную популярность, могут работать и над индивидуальным решением. Например, Lido Finance, крупнейший провайдер ликвидных ставок, объединился с Nil Foundation, чтобы финансировать разработку zkOracle. Эти решения обеспечат беспрепятственный доступ к историческим данным внутри EVM и обеспечат ликвидность Ethereum в размере 15 млрд долларов США, поставленных Lido Finance.
• Протоколы AMP: Существующие AMP-решения могут повысить выразительность своих сообщений, заключив партнерство с поставщиками услуг доказательства хранения данных. Такой подход предлагает компания Lagrange в своей статье Modular Thesis.

Заключение

Осведомленность дает технологическим компаниям возможность лучше обслуживать своих клиентов. От личности пользователя до покупательского поведения и социальных графов - технологические компании используют осведомленность для раскрытия таких возможностей, как точный таргетинг, сегментация покупателей и вирусный маркетинг. Традиционные технологические компании нуждаются в явном разрешении своих пользователей и должны быть осторожны при управлении пользовательскими данными. Однако все пользовательские данные в блокчейн без права доступа являются общедоступными без обязательного раскрытия личности пользователя. Умные контракты должны уметь использовать общедоступные данные, чтобы лучше обслуживать пользователей. Развитие и внедрение более специализированных экосистем сделает осознание состояния во времени и блокчейн все более важной проблемой, требующей решения. Доказательства хранения могут позволить Ethereum стать уровнем идентификации и владения активами, а также уровнем расчетов. Пользователи могли бы хранить свою личность и ключевые активы в Ethereum, которые можно было бы использовать в нескольких блокчейнах, не соединяя активы постоянно. Мы не перестаем радоваться новым возможностям и сценариям использования, которые откроются в будущем.

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

1. Эта статья перепечатана с[medium]. Все авторские права принадлежат оригинальному автору[LongHash Ventures]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.