Доставка данных на основе намерений: почему это важно и как это работает

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

Давайте быстро подытожим, как они работают, чтобы стало очевидно, почему нам нужен новый тип оракула - оракул на основе намерений.

Пуш-оракулы

«Пуш-оракул» является, вероятно, самой старой идеей. С помощью пуш-оракула данные доступны на блокчейне и обновляются через некоторое время или по достижении определённого порога. Например, компонент вне цепи наблюдает за средней температурой в Париже. В начале она составляет 25°C, и это значение записывается в цепь. Теперь каждый в блокчейне может получить доступ к этим данным. Может быть установлено правило, что данные обновляются в блокчейне, когда температура изменяется на 1°C или каждые 60 минут, что называется сердцебиением, чтобы убедиться, что оракул работает в общем плане. Предположим, теперь температура изменяется на 25.6, 25.7, 25.8°C, но на цепи ничего не меняется. Вне цепи тренд становится очень очевидным. Наконец, она достигает 26°C, и транзакция отправляется в блокчейн для обновления температуры в так называемом контракте оракула. 

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

Предположим, что на блокчейне существует крупный рынок производных инструментов, использующий эти данные, где вы можете делать ставки на температуру. Это может быть так же просто: вы делаете ставку на то, что температура вырастет, но всегда можете выйти из своей позиции. Если вы когда-либо торговали опционами, это может показаться вам знакомым. Представьте, что вы сделали ставку на падение температуры, и видите, что поступает новая транзакция с более высокими температурами, которые могут сделать вашу позицию недействительной. Вы можете просто отправить транзакцию с более высокой комиссией, чтобы опередить обновление оракула, и получить подтверждение по старым 25°C прямо перед обновлением оракула до 26°C. 

Таким образом, данные не являются реальными в любое общее время, как мы определяем термин «реальное время». Данные в основном устарели, и они публичны и видимы до того, как будут подтверждены. 

Даже с меньшими и меньшими порогами и/или всё более быстрыми сердцебиениями эта архитектура не масштабируется должным образом. Давайте перейдём к крайности и скажем, что мы хотим перенести традиционные данные о фондовых рынках США на блокчейн. Не редкость, что акция торгуется несколько тысяч или десятков тысяч раз в секунду, изменяя цену на несколько центов вверх и вниз. В Ethereum транзакция (в настоящее время) подтверждается каждые ~14 секунд. В Polygon это происходит гораздо быстрее. Важно не только пропускная способность транзакций, но и время подтверждения. Десятки тысяч обновлений в секунду — и на каждый рынок — невозможно реализовать с этой архитектурой. Обновление информации на блокчейне на основе пуша просто не работает, если данные должны быть на блокчейне в реальном времени. Кроме того, при загруженности сети, даже если провести простые расчёты стоимости всех транзакций, даже если они составляют 0.001 цента за транзакцию, не удастся обработать все обновления цен с достаточно высокой частотой выборки, чтобы удовлетворить компании, которые зависят от данных в реальном времени.

Пул оракулы

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

Вы подписываетесь на регулярную http/websocket ленту данных. Вы получаете обновления в реальном времени. И когда вам нужна цена, вы используете данные в своей транзакции. Данные предоставляются вам таким образом, что вы не можете изменить их.

Вернемся к примеру с температурой и ставкой на температуру. Есть Оракул (O), Участник или Пользователь (U) и Рынок (M).

O имеет данные. U хочет торговать на M. Вместо того чтобы запрашивать данные на блокчейне, Пользователь U получает температуру от O вне блокчейна. Однако O не просто отправляет текущую температуру, а отправляет ее с криптографической подписью, чтобы M (или кто-либо другой) мог проверить, что данные не были подделаны. Теперь Пользователь отправляет транзакцию на блокчейн, содержащую данные от Оракула на Рынок, который затем может подтвердить, что эта точка данных действительно от внеблокчейн оракула и позволяет вам торговать чем угодно.

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

1. Сторона Пользователя/Рынка, Пользователь может видеть данные перед их отправкой. Пользователь запрашивает данные и, не имея возможности изменить (подделать) их, он может решить, отправлять транзакцию или нет.
2. Данные доступны публично, что является проблемой для лицензирования данных и прав на данные. Многие данные, особенно финансовые, имеют узкие лицензии на распространение, отображение и другие права. Если сам оракул требует, чтобы данные были видимыми и распространяет их через сокет, это обычно означает, что традиционные поставщики данных не могут (и не будут) предоставлять данные через этот оракул.

Оракул Morpher отличается от обоих подходов.

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

Абстракция аккаунтов: краткий углубленный обзор

Абстракция аккаунтов решает проблему, не связанную с оракулами, но представляющую собой давнюю проблему для систем на базе EVM (Ethereum Virtual Machine).

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

В текущих системах на базе EVM существует два типа аккаунтов: EOA (внешне управляемые аккаунты) и контрактные аккаунты. EOA – это те аккаунты, которые вы обычно видите в своем кошельке, и они контролируются закрытым ключом. Контрактные аккаунты представляют собой смарт-контракты.

На Ethereum только EOA могут оплачивать транзакции. Это нельзя делегировать. Я не могу сказать: "Я хочу отправить эту транзакцию, но я хочу, чтобы [другой аккаунт] оплатил её". Эта проблема пытались решить на протяжении многих лет, создавая конструкцию, называемую "абстракция аккаунтов". Этот термин обычно означает, что граница между EOA и контрактами становится размытым, где контракты могут сами оплачивать транзакции.

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

Затем поступило другое предложение – предложение номер 4337, или ERC4337. Здесь не потребовалось никаких изменений в самом блокчейне. Оно было полностью обратнос совместимым и относительно простым в реализации.

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

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

Давайте рассмотрим конкретный пример.

В мире ERC4337 существует несколько участников.

1. Вы – пользователь, который хочет отправить транзакцию.
2. Существует бандлер, который представляет собой программное обеспечение, принимающее так называемые пользовательские операции, очень похожие на обычные транзакции, но еще не оплаченные.
3. Существует платильщик, который может оплатить вашу транзакцию. Это ключевая часть, где вы можете делегировать оплату транзакций кому-то другому. Этот человек может затем убедиться, что он получает оплату от вас либо вне цепи, либо напрямую и прозрачно на цепи.
4. Существует точка входа, которая является смарт-контрактом, в основном проверяющим подписи и обеспечивающим правильную оплату всем участникам.
5. Существует кошелек на цепи, так называемый смарт-аккаунт, который является еще одним смарт-контрактом. Смарт-аккаунты существовали уже до ERC4337 и разрабатываются параллельно или независимо от абстракции аккаунтов, они просто дополняют друг друга. Это смарт-контракты, которые ведут себя как обычные кошельки, но контролируются внешне управляемым аккаунтом (аккаунтом, управляемым закрытым ключом).
6. И, наконец, существует финальный контракт, с которым вы хотите взаимодействовать.

Ключевой момент в ERC4337 заключается в том, что не вы, с вашим внешне управляемым аккаунтом, взаимодействуете с финальным контрактом, а вы инструктируете ваш кошелек на цепи взаимодействовать с финальным контрактом, с которым хотите взаимодействовать.

В общем, общая рекомендация заключается в том, чтобы использовать кошельки на цепи вместо EOA, независимо от того, используется ли абстракция аккаунтов или нет. Например, https://safe.global/: он имеет множество преимуществ, таких как многофакторная авторизация, социальное восстановление и многое другое. Хотя это выходит за рамки данной статьи, в целом движение идет в сторону кошельков на цепи.

Для нашего примера предположим, что вы хотите отправить 1 ETH со своего смарт-кошелька кому-то другому. Но вместо того, чтобы напрямую взаимодействовать со своим смарт-кошельком, вы хотите отправить его "без газа". Это означает, что ваш EOA может иметь 0 ETH для оплаты транзакции, но вы все равно хотите каким-то образом инструктировать ваш кошелек на цепи отправить 1 ETH от себя кому-то другому от вашего имени.

Это работает путем создания UserOperation (userOp). UserOp структурно очень похож на обычную транзакцию.

Давайте немного углубимся для лучшего понимания:

1. У него есть отправитель, который является вашим смарт-аккаунтом.
2. У него есть nonce, который представляет собой постоянно увеличивающееся число. Очень похоже на обычную транзакцию, однако, вместо получения этого от узлов блокчейна, вы получаете это от точки входа.
3. У него есть initCode, который создает смарт-аккаунт (кошелек на цепи), если у вас его еще нет.
4. У него есть callData, который аналогичен части данных в обычной транзакции. Эта часть инструктирует ваш смарт-кошелек сделать что-то от вашего имени.
5. Затем у него есть несколько переменных газа, чтобы определить, сколько заплатить бандлеру.
6. Затем есть платильщик, который является еще одним участником, который мог бы оплатить транзакцию.
7. Подпись является криптографическим механизмом, обеспечивающим защиту userOp от подделки. Это схема подписи сообщения от внешне управляемого аккаунта, которая подписывает весь userOp, не отправляя его как транзакцию.

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

Бандлер – это программное обеспечение, которое имеет, по сути, одну лишь цель: оно принимает userOps (один или несколько из них, что важно!), упаковывает их в реальную транзакцию, за которую он платит, и отправляет их в точку входа. Бандлер не является благотворительной организацией, он не отправляет userOps без получения оплаты. Вот здесь и вступают в игру газовые переменные в userOp. Точка входа использует эти переменные, чтобы определить, сколько "возместить" бандлеру.

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

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

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

Интересный момент для оракула: бандлер может отправить одну или несколько userOps в одной транзакции. Таким образом, это одна транзакция, которая объединяет несколько userOps.

Оракул Morpher

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

В обычной схеме абстракции аккаунта пользователь взаимодействует с бандлером, отправляя POST-запрос на определенный URL. Бандлер принимает этот UserOp и добавляет его в свой пул транзакций.

В оракуле Morpher пользователь также взаимодействует с бандлером, однако вместо отправки UserOp пользователь отправляет немного другой запрос, который называется DataOp.

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

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

Это атомарная операция, не существует двух транзакций, а только одна единственная транзакция, отправленная в точку входа с двумя (или более) UserOps. Первый UserOp обновляет оракул, очень похоже на push-оракул, но основанный на намерениях, где данные действительно являются актуальными с точки зрения пользователя. Второй UserOp — это UserOp пользователя, который затем взаимодействует с его смарт-кошельком, который взаимодействует с конечным контрактом, который считывает данные оракула из контракта оракула.

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

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

Хотите узнать, как работают оракулы на основе намерений? Посмотрите вживую на Morpher Oracle.

Хотите углубиться в обсуждение? Присоединяйтесь к нашей группе в Telegram.

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