На относительно вялом рынке спрос на оракулы растет в геометрической прогрессии.

Выступление: Фрэнк, инженер по связям с разработчиками, Chainlink Labs

Организаторы: aididiaojp.eth, Foresight News.

Я Фрэнк, инженер по связям с разработчиками из Chainlink Labs. Моя основная задача — дать возможность большему количеству разработчиков или строителей, увлеченных этой отраслью, узнать больше об оракулах. Основываясь на смарт-контрактах в нашей текущей инфраструктуре, мы можем рассматривать это как гибридный смарт-контракт. Смарт-контракты можно лучше интегрировать с различными данными в мире Web2, включая вычислительные сервисы, а затем на основе этой архитектуры мы можем значительно расширить возможности смарт-контрактов в цепочке.

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

Что такое оракул?

Состояние сети и данных постоянно меняются на этих трех этапах: от Интернета 1 к Интернету 2 и к Интернету 3. Вначале Web1 представлял собой веб-сервис, данные которого можно было читать только статически. Когда он достиг стадии Web2, данные стали доступны для чтения, записи и участия. Многие крупные компании построили бизнес-империи на основе собственных сервисов. Они хранят все пользовательские данные в собственных базах данных. При необходимости они фактически могут владеть и изменять пользовательские данные. Тогда возникает вопрос, то есть некоторые данные, которые мы создаем в Интернете или в виртуальном мире, иногда имеют некоторую ценность, так кому же принадлежит эта ценность? Исходя из этого, мы надеемся хорошо решить эту проблему на этапе Web 3. Все данные на этапе Web 3 не существуют на сервере или узле. Он имеет децентрализованную сеть, а децентрализованная сеть представляет собой систему с несколькими реестрами, состоящую из нескольких узлов. Данные хранятся в нескольких узлах только тогда, когда каждый узел согласен на изменение и хранение данных, окончательные данные могут быть сохранены. Это принесет нам выгоду, то есть, какую бы модификацию мы ни хотели внести в данные, нам нужно произвести модификацию в соответствии с заранее согласованным консенсусом. Например, если я захочу изменить баланс своего кошелька, если никто не переведет мне деньги, как бы владелец данных ни захотел их изменить, он в конечном итоге не сможет пройти процесс консенсуса, а это означает, что баланс кошелька не может быть изменено. Только владелец данных может окончательно изменить данные, отправив транзакцию, соответствующую правилам. Это имеет очень очевидное преимущество. В то же время это также имеет некоторые недостатки. Самый большой недостаток заключается в том, что это делает систему детерминированной. Другими словами, поскольку на протяжении всего процесса будет действовать консенсус, он может выполнять только те операции, которые могут проверить другие. Когда вы отправляете операцию, другие узлы должны выполнить вашу операцию. Если другие узлы могут успешно выполнить операцию, они действительно могут вернуть результаты. Что касается того, превышает ли оно 50% или 70%, это зависит от алгоритма консенсуса.Наконец, операция может быть записана в транзакцию, а транзакция может быть записана в блок, чтобы стать полной транзакцией.

Но если нам нужно выполнить некоторые недетерминированные операции, такие как получение некоторых данных API вне блокчейна, генерация случайных чисел и т. д., детерминированная система блокчейна не может быть завершена. Наша лотерея должна генерировать случайные числа, или протоколу цепочки необходимо знать цены активов вне цепочки, например, получение цен на акции или товары, что является недетерминированной операцией и не может быть завершено самим блокчейном. Другой пример — вызовы API. Как узел в сети, я вызываю внешние данные API, а затем сообщаю результат другим узлам в сети. Чтобы проверить подлинность результата, другие узлы также выполнят ту же операцию. и получить результат. Но что касается внешнего API, если разные люди обращаются к одному и тому же API в разное время, сервер может зависнуть, или служба может быть приостановлена, или данные могут измениться с течением времени. Если вы сделаете одно и то же в разное время, результаты будут противоречивыми. Пока результаты противоречивы, невозможно заблокировать финальную операцию и невозможно ее завершить. Вот почему, получив право собственности на данные, нам также придется принять на себя некоторые недостатки, которые это приносит.

Чтобы решить эту проблему, нужно полагаться на оракулов. Блокчейн — изолированная и детерминированная система. Он не может активно получать данные извне. Появление оракулов призвано решить эту проблему. Концепция оракулов появилась два-три года назад, но на тот момент было не так много применимых сценариев и она имела большие ограничения. Например, если вы хотите получить некоторые рыночные данные, загрузить биржевые данные в сеть блокчейна или создать структуру для размещения логики в цепочке для выполнения, но поместить активы в цепочку и защитить нормальное проведение транзакций посредством смарт-контракты и т. д. В это время необходимо получать некоторые данные из цепочки и периодически синхронизировать данные, включая данные о банковских платежах или розничной торговле, и даже некоторые другие данные о публичных событиях, такие как погодные условия, географическая информация, информация о логистике, результаты спортивных соревнований и т. д. эти данные невозможно получить без прохождения через машину оракула. Это сделает экологию в цепи очень ограниченной. Поскольку экосистема Web 3 продолжает развиваться, связь между двумя мирами Web 3 и Web 2 будет становиться всё теснее и теснее. Если мы хотим, чтобы Web3 получил широкомасштабное внедрение или чтобы его использовало больше людей, он должен предоставлять очень богатые функции и не может ограничиваться операциями, которые можно выполнить только с помощью собственных данных в цепочке.

Oracle стал популярен только в 2020 году, во время DeFi Summer, когда большинство людей это осознали. Сначала машина-оракул делала очень простые вещи. Например, если вы хотите получить внешние данные и загрузить их в децентрализованную сеть, то есть в блокчейн, то самый простой способ — создать централизованный узел в цепочке. То есть построить сервер, а затем получить данные через сервер и, наконец, записать данные в сеть блокчейна дедупликации, тогда эта модель называется централизованным оракулом. Хотя его относительно просто реализовать, он принесет некоторые проблемы. Например, существует риск единой точки отказа, то есть централизованный узел может вызвать простой по своим основным причинам. Другая возможность заключается в том, что если услуга, предоставляемая смарт-контрактом в цепочке, опирается на данные, предоставленные централизованным узлом, и если объем средств, задействованных в смарт-контракте в цепочке, очень велик, то централизованный оракул может передать свой собственные Данные, которыми можно манипулировать, могут быть использованы для проведения атак на сервисы. Пока интересы достаточно велики и нет возможности добиться полной защиты техническими средствами, то это единая точка отказа. Мы хотим размещать приложения в децентрализованных сетях, включая Ethereum или другие экосистемы уровня 2. Фактически, мы также надеемся, что сможем обеспечить справедливость наших приложений, то есть смарт-контрактов, через сотни или тысячи узлов оракулов в сети. секс и безопасность.

Конечно, если мы полагаемся на централизованные узлы для получения терминала данных, даже если безопасность других аспектов может быть гарантирована, если нет способа обеспечить безопасность самого важного актива, терминала данных, это сделает всю dApp бессмысленно. Таким образом, после централизованной машины-оракула возникла децентрализованная сеть машин-оракулов, которая вполне может решить риск единичного сбоя, о котором мы только что упомянули. Самая большая разница между децентрализованной сетью оракула заключается не в том, что один узел оракула предоставляет услуги децентрализованной сети, а в том, что услуги предоставляются через децентрализованную сеть оракула. ​​Его также можно понимать как своего рода уровень 2, то есть каждый. Узлы в централизованной сети оракула могут получать данные через собственные источники данных. После получения результатов они могут агрегировать данные с другими децентрализованными сетями. Это также можно понимать как процесс консенсуса, включая проверку отсутствия узлов. или же возвращаемые данные слишком сильно отклоняются от среднего значения, или просто сделать среднее значение, затем агрегировать данные и т. д., а затем записать их в децентрализованную сеть. Одним из преимуществ этого подхода является то, что он может технически гарантировать, что обслуживание не будет прервано, пока все узлы в децентрализованной сети Oracle не перестанут обслуживаться, но такая вероятность очень мала. Кроме того, со стороны данных также можно гарантировать, что данные, предоставляемые оракулом контракту в цепочке, контролируются не одним узлом, а многими узлами. Если вы хотите манипулировать данными для запуска атаки, цена будет очень высокой. Это эквивалентно атаке на уровень 2 или даже на децентрализованную сеть, такую ​​​​как Ethereum, которая в принципе вряд ли увенчается успехом.

Децентрализованные сети могут значительно повысить безопасность и справедливость данных, получаемых посредством смарт-контрактов. Для пользователей мы — просто децентрализованная сеть оракулов, но на основе децентрализованной сети оракулов мы можем предоставлять и другие услуги, такие как услуги передачи данных, вычислительные услуги и кросс-чейновые услуги. Если данные передаются в сеть на основе оракулов, некоторые более сложные и дорогостоящие операции также могут выполняться вне цепочки. То есть они упаковываются в оффчейн-сеть оракулов для вычислений, а затем записываются обратно в сравнение безопасности. высоко в блокчейне. Если мы можем получать данные из оффчейна, мы также можем получать данные из других цепочек, а затем записывать их в этот блокчейн, тогда это фактически предполагает кроссчейн. Пока безопасность децентрализованной сети Oracle достаточно сильна, она может гарантировать, что построенные на ней службы данных, вычислительные службы и кросс-чейн-сервисы очень безопасны. Chainlink предоставляет различные услуги на основе децентрализованных оракулов, которые могут соединять данные Web 3 и Web 2, включая данные уровней 1 и 2, чтобы каждый мог получить как можно больше соответствующих данных и услуг.

Какие услуги предоставляют оракулы Chainlink?

Далее позвольте мне кратко представить услуги, предоставляемые оракулами Chainlink. Конечно, Chainlink предоставляет множество услуг. Я поделюсь некоторыми услугами, применимыми ко многим сценариям.

Если вы хотите в будущем внести какие-то инновации в области DeFi, GameFi, NFT и SocialFi, существует высокая вероятность того, что вам понадобится оракул для получения данных. Потому что вы должны получить данные цепочки очень децентрализованным и безопасным способом и записать их обратно в свой смарт-контракт в цепочке.

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

На рисунке выше представлена ​​базовая блок-схема службы ценовой подачи, которая включает в себя 3 важные стороны. Первый — это децентрализованная сеть Oracle, о которой мы только что упомянули; второй — поставщик данных, которым может быть биржа или другие крупные авторитетные учреждения, все из которых могут выступать в качестве поставщиков данных; третий — это пользовательский контракт; Процесс, показанный на рисунке выше, очень прост. Каждый поставщик данных может предоставить их определенному узлу сети оракула Chanlink через интерфейс или службу источника данных. Каждый узел сети оракула также может получать данные в соответствии со своим собственным сервисом. , а затем в процессе агрегации данные, полученные из каждого канала, записываются в контракт проверки, развернутый в цепочке. Если проверка пройдет, данные могут быть записаны и использованы пользователем в дальнейшем. Вот и весь процесс. Клиенту необходимо использовать контракты только для получения и использования нескольких данных.

Существует множество вариантов использования для подачи цен, таких как Compound, Uniswap и Synthetics, о которых мы только что упомянули. Им необходимо сопоставить активы в Web2 с Web3. В настоящее время им нужен внешний механизм для предоставления цены актива. Как и в случае со стейблкоином, количество стейблкоинов может быть выпущено в зависимости от количества доступных активов, а цена его актива также должна быть получена на основе оракула. Кроме того, некоторые платформы управления активами и популярные приложения для торговли деривативами сильно зависят от цен, поэтому они на самом деле являются важными пользователями услуг по подаче цен. Судя по тенденции, спрос на услуги ценового питания растет в геометрической прогрессии. Несмотря на то, что рынок не так активен, использование данных все еще растет.

Далее я представлю второй, более отличительный сервис — Any API. Проще говоря, он помогает смарт-контрактам в цепочке получать некоторые нестандартные данные, например некоторые данные с длинным хвостом. Эти данные могут быть доступны только определенным людям или определенным контрактам, но это не стандартные данные, такие как цены токенов или цены активов. Многим DApps требуются нестандартные данные. Например, страховым бизнес-приложениям Web 3 необходимо получать данные о погоде или задержке рейсов. Например, парниковые газы можно использовать для проектов, аналогичных ESG, включая выборы и спортивные соревнования, которые можно объединить с рынками прогнозов. Мы предоставляем рынок данных на основе любого API. На каждом рынке данных существуют различные поставщики данных, которые предоставляют услуги внешним пользователям на основе своих собственных данных. Пока пользователь отправляет запрос, он может записать данные обратно пользователю. договор в соответствии с требованиями к обслуживанию. И поставщик данных, и получатель данных определяются рынком. Существует рынок для пользователей и поставщиков данных, и чиновники Chainlink не должны монополизировать все данные, а затем предоставлять их в цепочку.

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

Позже, когда разнообразие требований к данным возросло, многие нестандартные данные также надеялись записать обратно в цепочку децентрализованным способом. В начале апреля этого года мы также создали новый сервис под названием «Функции». Проще говоря, он выполняет любой запрос пользователя через децентрализованную сеть Oracle. Пользователи могут использовать некоторые продвинутые языки программирования, такие как Javascript, для написания операционных программ. Их больше нельзя писать только на языке Solidity. Программы, написанные на Javascript, определенно богаче, чем Solidity. Сервис «Функции» может инкапсулировать написанную программу в запрос и отправить его по всей сети Oracle. Каждый узел в сети будет выполнять одну и ту же операцию, которая может представлять собой вычислительные услуги, услуги сбора данных или другие услуги. После того, как каждый узел выполняется и получает результат, он проходит процесс агрегации, о котором мы только что упомянули, а затем записывает его обратно в смарт-контракт.

По сравнению с ценовым кормлением степень свободы здесь очень высока. Другими словами, смарт-контракту можно предоставить внешний интерфейс, который он сможет использовать по своему усмотрению. Вы также можете записать в контракт часть логики, которую необходимо выполнить, и тогда она будет выполняться не блокчейном, а машиной оракула, что эквивалентно встраиванию службы машины оракула непосредственно в смарт-контракт, превращая его в гибридный смарт-контракт. Если вы сделаете это таким образом, то ваше выполнение будет гарантировано через децентрализованную сеть. Тогда ваши недетерминированные операции, которые невозможно выполнить в блокчейне, могут быть выполнены через децентрализованный оракул. Сеть выполняет и возвращает результаты. В целом, это может значительно улучшить функциональность смарт-контрактов. Функции, которые он может выполнять, будут богаче, чем раньше, а фактическое приложение на стороне пользователя также будет очень простым. Вам нужно всего лишь добавить две функции в ваш контракт, и вы сможете напрямую использовать децентрализованную сеть Oracle как часть вашего смарт-контракта. . использовать. Он также очень удобен для традиционных программистов Web2, поскольку логика выполнения может быть реализована с помощью традиционных языков программирования. Общий процесс не изменился. Отправьте запрос, затем отправьте его в децентрализованную сеть Oracle, агрегируйте его после выполнения и, наконец, запишите его обратно в смарт-контракт пользователя.

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