Чем оракул morpher отличается от традиционных ораклов?

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

Давайте возьмем пример: settling a bet — это известный случай.

С недавними выборами в США 2024 года давайте рассмотрим один умный контракт, который стал чрезвычайно успешным во время президентской гонки: Polymarket.

Узнайте о Morpher Oracle

Как работают рынки ставок на блокчейне

На рынках ставок вы можете делать ставки на вероятность реальных событий. В преддверии результатов выборов 2024 года это была гонка между Камалой Харрис и Дональдом Трампом. Умный контракт позволяет людям ставить деньги на победу или поражение любой из сторон.

В сильно упрощенном виде: если 10 человек ставят по $1 на победу Харрис и 5 человек ставят по $1 на ее поражение, мы получаем около 66% (или $10/$15) на победу Харрис и 33% на ее поражение. Вы можете купить ставку на поражение Харрис за $0.33 и так далее. Это немного сложнее, но здесь вступают в дело оракулы, такие как Morpher oracle: Как определить, на блокчейне, кто победил?

Проблема оракула: кто предоставляет достоверные данные?

Таким образом, вопрос заключается в следующем: кто, если вообще кто-то, имеет полномочия объявить в блокчейне, что Трамп победил или Харрис победила? И почему мы должны доверять этому человеку или организации?

В реальном мире это просто: достаточно следить за новостями и ждать подсчета голосов.

Но перенести этот результат в блокчейн довольно сложно.

Среди прочего, существует несколько популярных вариантов:

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

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

По сути, так работает Polymarket: когда ставка завершается и требует разрешения, кто-то может предложить результат и поставить залог. Если результат оспаривается сообществом, залог может быть востребован. Если в течение определенного времени спора не возникает, результат принимается как "истина", и ставки рассчитываются.

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

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

Но что, если сообщество маленькое? Или вообще нет сообщества, и что-то нужно решить между всего лишь двумя сторонами? Кому вы доверяете?

Как реальные данные попадают в блокчейн

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

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

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

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

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

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

Такой агрегированный набор данных с датчиков уже существует сегодня, но он еще не интегрирован в блокчейн.

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

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

Предоставление данных на основе порога: как работают push-оракулы

До изобретения Morpher Oracle существовало два основных способа передачи данных в блокчейн.

Вернемся к нашему примеру с показаниями датчиков. Представьте, что корабль отправляется из Азии, и производится первоначальное измерение, которое фиксирует -15°C, что отмечает начало пути. Это первое измерение успешно заносится в блокчейн.

Однако мы знаем, что обновление значений в блокчейне не бесплатно (по крайней мере, не всегда). Кроме того, блокчейны имеют ограниченную пропускную способность транзакций в секунду. Теперь подумайте, сколько кораблей работает в мире и как часто они могут записывать показания датчиков, возможно, десятки раз в минуту или даже в секунду. Если каждое отдельное измерение требует транзакции в блокчейне, система быстро станет перегруженной.

Возможное решение? Отправлять транзакцию только тогда, когда достигается определенный порог.

Именно так работают push-оракулы, такие как Chainlink.

В данном конкретном случае нас интересует показание датчика только в том случае, если значение изменяется на 1–2 градуса Цельсия. Кроме того, «сердечный» транзакция могла бы отправляться каждые 1–2 часа, если температура остается в пределах порога.

Для нашего умного контракта он будет получать показания датчиков из другого умного контракта. Этот контракт будет продолжать отображать -15°C, пока температура не изменится на 1 или 2 градуса, обновляясь до -13°C и так далее. Наш умный контракт затем позволит подать заявление, если показания температуры достигнут +5°C или выше. Этот процесс может быть полностью автоматизирован, и, пока оракул (посредник, передающий данные) будет достаточно децентрализован, система останется надежной.

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

Один из таких случаев? Живая информация о ценах в блокчейне.

Pull-оракулы: новый подход к данным в реальном времени

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

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

Реальный пример этой концепции используется некоторыми компаниями: они вакуумируют небольшой пакет с фасолью или цветными мраморными шариками внутри прозрачной упаковки. Перед отправкой они делают фотографию и отправляют ее по электронной почте получателю. При доставке вы можете сравнить упаковку с фотографией; если фасоль или мраморы точно такие же, как на изображении, пакет не тронут. Но если кто-то вмешался, будет почти невозможно вернуть все обратно в точно таком же порядке.

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

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

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

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

Это создает две большие проблемы:

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

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

Oracle Morpher: новое решение для потоков данных блокчейна

С Oracle Morpher пользователь не несет ответственность за отправку транзакции, а вместо этого отправляет намерение отправить транзакцию. Это меняет механизм pull oracle:

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

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

Таким образом, пользователь гарантированно отправляет свою транзакцию. У смарт-контракта есть гарантии, что информация актуальна и криптографически подписана, аналогично pull oracle. Однако контрагент также имеет гарантии, что транзакция подана, даже если точка данных оракула неблагоприятна для пользователя — это честная игра.

Более того, данные не могут быть выведены в большом объеме, что предотвращает проблемы с лицензированием, с которыми сталкиваются традиционные pull oracle.

Присоединяйтесь к группе в Telegram Morpher Oracle для получения дополнительной информации.

Oracle Morpher обеспечивает поток данных в реальном времени, защищенный от подделки, без манипуляций или задержек — гарантируя честные, надежные транзакции в цепочке. Проверьте это сейчас на BNB и Radix.

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