Оракулы

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

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

Предварительные условия

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

Что такое блокчейн-оракул?

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

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

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

Зачем смарт-контрактам нужны оракулы?

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

Использовать смарт-контракты для обеспечения соблюдения соглашений между людьми непросто, учитывая предопределенность Ethereum. Детерминированная система (opens in a new tab) — это система, которая всегда выдает одинаковые результаты при заданном начальном состоянии и определенных входных данных, что означает отсутствие случайности или вариативности в процессе вычисления выходных данных на основе входных.

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

«Подписал ли владелец счета (идентифицированный по открытому ключу) эту транзакцию с помощью парного закрытого ключа?»
"Достаточно ли средств на этом счёте для оплаты комиссии за операцию?"
«Действительна ли эта транзакция в контексте данного смарт-контракта?» и т. д.

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

Для общественного блокчейна, такого как Ethereum, с тысячами узлов по всему миру, обрабатывающих транзакции, предопределенность имеет решающее значение. В отсутствие центрального органа, выступающего в качестве источника истины, узлам необходимы механизмы для достижения одного и того же состояния после применения одних и тех же транзакций. Случай, когда узел A выполняет код смарт-контракта и получает в результате «3», а узел B получает «7» после выполнения той же транзакции, приведет к нарушению консенсуса и сведет на нет ценность Ethereum как децентрализованной вычислительной платформы.

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

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

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

В чем проблема оракула?

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

Как мы можем проверить, что введенная информация была извлечена из правильного источника и не была подделана?
Какое гарантирование того, что эти данные всегда доступны и регулярно обновляются?

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

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

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

Как работает сервис блокчейн-оракулов?

Пользователи

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

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

Контракт оракула

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

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

Ниже приведен пример контракта оракула (opens in a new tab), написанный Педро Костой. Это простой сервис оракула, который может запрашивать оффчейн-API по запросу других умных контрактов и сохранять запрошенную информацию в блокчейне:

1pragma solidity >=0.4.21 <0.6.0;
2
3contract Oracle {
4  Request[] requests; //список запросов, сделанных контракту
5  uint currentId = 0; //увеличивающийся идентификатор запроса
6  uint minQuorum = 2; //минимальное количество ответов, которые необходимо получить до объявления окончательного результата
7  uint totalOracleCount = 3; // Жестко заданное количество оракулов
8
9  // определяет общий запрос к API
10  struct Request {
11    uint id;                            //id запроса
12    string urlToQuery;                  //URL-адрес API
13    string attributeToFetch;            //атрибут json (ключ), который нужно получить в ответе
14    string agreedValue;                 //значение от ключа
15    mapping(uint => string) answers;     //ответы, предоставленные оракулами
16    mapping(address => uint) quorum;    //оракулы, которые будут запрашивать ответ (1 = оракул не голосовал, 2 = оракул проголосовал)
17  }
18
19  //событие, которое запускает оракула за пределами блокчейна
20  event NewRequest (
21    uint id,
22    string urlToQuery,
23    string attributeToFetch
24  );
25
26  //срабатывает при достижении консенсуса по окончательному результату
27  event UpdatedRequest (
28    uint id,
29    string urlToQuery,
30    string attributeToFetch,
31    string agreedValue
32  );
33
34  function createRequest (
35    string memory _urlToQuery,
36    string memory _attributeToFetch
37  )
38  public
39  {
40    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
41    Request storage r = requests[length-1];
42
43    // Жестко заданные адреса оракулов
44    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
45    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
46    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
47
48    // запустить событие, которое будет обнаружено оракулом за пределами блокчейна
49    emit NewRequest (
50      currentId,
51      _urlToQuery,
52      _attributeToFetch
53    );
54
55    // увеличить id запроса
56    currentId++;
57  }
58
59  //вызывается оракулом для записи своего ответа
60  function updateRequest (
61    uint _id,
62    string memory _valueRetrieved
63  ) public {
64
65    Request storage currRequest = requests[_id];
66
67    //проверить, находится ли оракул в списке доверенных оракулов
68    //и если оракул еще не голосовал
69    if(currRequest.quorum[address(msg.sender)] == 1){
70
71      //отметка о том, что этот адрес проголосовал
72      currRequest.quorum[msg.sender] = 2;
73
74      //перебирать "массив" ответов, пока позиция не освободится, и сохранить полученное значение
75      uint tmpI = 0;
76      bool found = false;
77      while(!found) {
78        //найти первый пустой слот
79        if(bytes(currRequest.answers[tmpI]).length == 0){
80          found = true;
81          currRequest.answers[tmpI] = _valueRetrieved;
82        }
83        tmpI++;
84      }
85
86      uint currentQuorum = 0;
87
88      //перебрать список оракулов и проверить, достаточно ли оракулов (минимальный кворум)
89      //проголосовали за тот же ответ, что и текущий
90      for(uint i = 0; i < totalOracleCount; i++){
91        bytes memory a = bytes(currRequest.answers[i]);
92        bytes memory b = bytes(_valueRetrieved);
93
94        if(keccak256(a) == keccak256(b)){
95          currentQuorum++;
96          if(currentQuorum >= minQuorum){
97            currRequest.agreedValue = _valueRetrieved;
98            emit UpdatedRequest (
99              currRequest.id,
100              currRequest.urlToQuery,
101              currRequest.attributeToFetch,
102              currRequest.agreedValue
103            );
104          }
105        }
106      }
107    }
108  }
109}
Показать все

Узлы оракулов

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

Распространенной задачей для узлов оракула является отправка запроса HTTP GET (opens in a new tab) в службу API, анализ ответа для извлечения соответствующих данных, форматирование в читаемый для блокчейна вид и отправка в ончейн путем включения в транзакцию к контракту оракула. От узла оракула также может потребоваться подтвердить достоверность и целостность предоставленной информации с помощью «доказательств подлинности», которые мы рассмотрим позже.

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

Шаблоны проектирования оракулов

Оракулы бывают разных типов, включая немедленное чтение, публикация-подписка и запрос-ответ, причем последние два являются наиболее популярными среди умных контрактов Ethereum. Здесь мы кратко опишем модели «публикация-подписка» и «запрос-ответ».

Этот тип оракула предоставляет «поток данных», который другие контракты могут регулярно считывать для получения информации. В этом случае ожидается, что данные будут часто меняться, поэтому клиентские контракты должны отслеживать обновления данных в хранилище оракула. Примером может служить оракул, который предоставляет пользователям последнюю информацию о цене ETH-USD.

Оракулы по модели «запрос-ответ»

Схема «запрос-ответ» позволяет клиентскому контракту запрашивать произвольные данные, отличные от тех, которые предоставляет оракул по модели «публикация-подписка». Оракулы по модели «запрос-ответ» идеальны, когда набор данных слишком велик для хранения в хранилище умного контракта и/или пользователям в любой момент времени потребуется лишь небольшая часть данных.

Хотя оракулы «запрос-ответ» сложнее, чем модели «публикация-подписка», по сути они представляют собой то, что мы описали в предыдущем разделе. У оракула будет ончейн-компонент, который получает запрос данных и передает его на обработку оффчейн-узлу.

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

Централизованные и децентрализованные оракулы

Централизованные оракулы

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

Низкие гарантии корректности

С централизованными оракулами нет способа подтвердить, верна ли предоставленная информация. Даже «авторитетные» поставщики могут стать мошенниками или быть взломаны. Если оракул будет скомпрометирован, умные контракты будут выполняться на основе неверных данных.

Низкая доступность

Централизованные оракулы не гарантируют постоянную доступность оффчейн-данных для других умных контрактов. Если поставщик решит отключить услугу или хакер захватит оффчейн-компонент оракула, ваш умный контракт подвергнется риску атаки типа «отказ в обслуживании» (DoS).

Плохая совместимость стимулов

Централизованные оракулы часто имеют плохо продуманные или несуществующие стимулы для поставщика данных отправлять точную/неизмененную информацию. Оплата оракулу за корректность не гарантирует честности. Эта проблема усугубляется по мере увеличения объема ценностей, контролируемых умными контрактами.

Децентрализованные оракулы

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

Децентрализованный оракул должен (в идеале) быть бездоверительным, не требующим разрешений и свободным от администрирования со стороны центральной стороны; в действительности децентрализация среди оракулов находится в определенном спектре. Существуют полудецентрализованные сети оракулов, в которых может участвовать любой, но с «владельцем», который утверждает и удаляет узлы на основе их прошлых показателей. Также существуют полностью децентрализованные сети оракулов: обычно они работают как автономные блокчейны и имеют определенные механизмы консенсуса для координации узлов и наказания за ненадлежащее поведение.

Использование децентрализованных оракулов дает следующие преимущества:

Высокие гарантии корректности

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

Доказательства подлинности

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

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

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

Аттестации доверенной среды выполнения (TEE): доверенная среда выполнения (opens in a new tab) (TEE) — это изолированная («песочница») вычислительная среда, отделенная от операционных процессов своей хост-системы. TEE гарантируют, что любой код приложения или данные, хранящиеся/используемые в вычислительной среде, сохраняют целостность, конфиденциальность и неизменность. Пользователи также могут сгенерировать аттестацию, чтобы доказать, что экземпляр приложения работает в доверенной среде выполнения.

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

Проверка информации на основе консенсуса

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

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

Голосование/стейкинг за точность данных

Некоторые децентрализованные сети оракулов требуют от участников голосования или стейкинга за точность ответов на запросы данных (например, «Кто победил на выборах в США в 2020 году?»). используя нативный токен сети. Затем протокол агрегации объединяет голоса и стейки и принимает ответ, поддержанный большинством, как действительный.

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

Стейкинг/голосование также защищает децентрализованные оракулы от , когда злоумышленники создают несколько удостоверений для манипулирования системой консенсуса. Однако стейкинг не может предотвратить «безбилетный проезд» (узлы оракула копируют информацию у других) и «ленивую проверку» (узлы оракула следуют за большинством, не проверяя информацию самостоятельно).

Механизмы точки Шеллинга

Точка Шеллинга (opens in a new tab) — это концепция теории игр, которая предполагает, что несколько субъектов всегда будут приходить к общему решению проблемы в отсутствие какой-либо коммуникации. Механизмы точки Шеллинга часто используются в децентрализованных сетях оракулов, чтобы позволить узлам достичь консенсуса по ответам на запросы данных.

Ранней идеей для этого был SchellingCoin (opens in a new tab), предложенный канал данных, где участники предоставляют ответы на «скалярные» вопросы (вопросы, ответы на которые описываются величиной, например, «какова цена ETH?»), вместе с депозитом. Пользователи, предоставившие значения между 25-м и 75-м процентилями (opens in a new tab), вознаграждаются, в то время как те, чьи значения сильно отклоняются от медианного значения, наказываются.

Хотя SchellingCoin сегодня не существует, ряд децентрализованных оракулов, в частности оракулы протокола Maker (opens in a new tab), используют механизм точки Шеллинга для повышения точности данных оракула. Каждый оракул Maker состоит из оффчейн P2P-сети узлов («ретрансляторов» и «фидов»), которые предоставляют рыночные цены на залоговые активы, и ончейн-контракта «Medianizer», который вычисляет медиану всех предоставленных значений. По истечении указанного периода задержки это медианное значение становится новой справочной ценой для соответствующего актива.

Другие примеры оракулов, использующих механизмы точки Шеллинга, включают Chainlink Offchain Reporting (opens in a new tab) и Witnet (opens in a new tab). В обеих системах ответы от узлов оракула в одноранговой сети агрегируются в одно совокупное значение, например, среднее или медианное. Узлы вознаграждаются или наказываются в зависимости от того, насколько их ответы соответствуют или отклоняются от совокупного значения.

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

Доступность

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

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

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

Хорошая совместимость стимулов

Децентрализованные оракулы реализуют различные схемы стимулирования для предотвращения византийского (opens in a new tab) поведения среди узлов-оракулов. В частности, они достигают атрибутируемости и подотчетности:

От децентрализованных узлов оракулов часто требуется подписывать данные, которые они предоставляют в ответ на запросы данных. Эта информация помогает оценить историческую производительность узлов оракулов, чтобы пользователи могли отфильтровывать ненадежные узлы оракулов при выполнении запросов данных. Примером является алгоритмическая система репутации (opens in a new tab) Witnet.
Децентрализованные оракулы, как объяснялось ранее, могут требовать от узлов размещения стейка в подтверждение своей уверенности в истинности предоставляемых ими данных. Если претензия подтвердится, этот стейк может быть возвращен вместе с вознаграждением за честную службу. Но он также может быть урезан в случае, если информация неверна, что обеспечивает определенную меру подотчетности.

Применение оракулов в умных контрактах

Ниже приведены распространенные варианты использования оракулов в Ethereum:

Получение финансовых данных

Приложения децентрализованных финансов (DeFi) позволяют осуществлять одноранговое кредитование, заимствование и торговлю активами. Для этого часто требуется получение различной финансовой информации, включая данные об обменных курсах (для расчета фиатной стоимости криптовалют или сравнения цен на токены) и данные о рынках капитала (для расчета стоимости токенизированных активов, таких как золото или доллар США).

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

Популярные «ценовые оракулы» (как их часто называют) в DeFi включают в себя ценовые каналы Chainlink, Open Price Feed (opens in a new tab) от Compound Protocol, Time-Weighted Average Prices (TWAPs) (opens in a new tab) от Uniswap и Maker Oracles (opens in a new tab).

Разработчики должны понимать оговорки, связанные с этими ценовыми оракулами, прежде чем интегрировать их в свой проект. Эта статья (opens in a new tab) содержит подробный анализ того, что следует учитывать при планировании использования любого из упомянутых ценовых оракулов.

Вот пример того, как получить последнюю цену ETH в вашем смарт-контракте, используя канал цен Chainlink:

1pragma solidity ^0.6.7;
2
3import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
4
5contract PriceConsumerV3 {
6
7    AggregatorV3Interface internal priceFeed;
8
9    /**
10     * Network: Kovan
11     * Aggregator: ETH/USD
12     * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
13     */
14    constructor() public {
15        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
16    }
17
18    /**
19     * Returns the latest price
20     */
21    function getLatestPrice() public view returns (int) {
22        (
23            uint80 roundID,
24            int price,
25            uint startedAt,
26            uint timeStamp,
27            uint80 answeredInRound
28        ) = priceFeed.latestRoundData();
29        return price;
30    }
31}
Показать все

Генерация проверяемой случайности

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

Первоначальный подход заключался в использовании псевдослучайных криптографических функций, таких как blockhash, но они могли быть подвержены манипуляциям со стороны майнеров (opens in a new tab) решающих алгоритм доказательства выполнения работы. Кроме того, переход Ethereum на доказательство доли владения означает, что разработчики больше не могут полагаться на blockhash для ончейн-случайности. Вместо этого альтернативный источник случайности предоставляет механизм RANDAO (opens in a new tab) Beacon Chain.

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

Оракулы, предназначенные для оффчейн-вычислений, решают эту проблему путем безопасной генерации случайных результатов оффчейн, которые они передают ончейн вместе с криптографическими доказательствами, подтверждающими непредсказуемость процесса. Примером является Chainlink VRF (opens in a new tab) (проверяемая случайная функция), который представляет собой доказуемо честный и защищенный от взлома генератор случайных чисел (RNG), полезный для создания надежных умных контрактов для приложений, которые полагаются на непредсказуемые результаты.

Получение результатов событий

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

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

Автоматизация умных контрактов

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

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

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

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

Сеть Keeper Network (opens in a new tab) от Chainlink предоставляет умным контрактам опции для аутсорсинга регулярных задач по обслуживанию с минимизацией доверия и децентрализованным способом. Прочитайте официальную документацию Keeper (opens in a new tab) для получения информации о том, как сделать ваш контракт совместимым с Keeper и использовать сервис Upkeep.

Как использовать блокчейн-оракулы

Существует несколько приложений-оракулов, которые вы можете интегрировать в свое децентрализованное приложение Ethereum:

Chainlink (opens in a new tab) — децентрализованные сети оракулов Chainlink предоставляют защищенные от несанкционированного доступа входные, выходные данные и вычисления для поддержки передовых умных контрактов на любом блокчейне.

RedStone Oracles (opens in a new tab) — RedStone — это децентрализованный модульный оракул, который предоставляет оптимизированные по газу потоки данных. Он специализируется на предоставлении ценовых потоков для новых активов, таких как токены ликвидного стейкинга (LST), токены ликвидного рестейкинга (LRT) и деривативы стейкинга Биткоина.

Chronicle (opens in a new tab) — Chronicle преодолевает текущие ограничения передачи данных в ончейне, разрабатывая действительно масштабируемые, экономичные, децентрализованные и проверяемые оракулы.

Witnet (opens in a new tab) — Witnet — это децентрализованный, не требующий разрешений и устойчивый к цензуре оракул, помогающий умным контрактам реагировать на реальные события с сильными криптоэкономическими гарантиями.

UMA Oracle (opens in a new tab) — оптимистичный оракул UMA позволяет умным контрактам быстро получать любые данные для различных приложений, включая страхование, финансовые деривативы и рынки прогнозов.

Tellor (opens in a new tab) — Tellor — это прозрачный и не требующий разрешений протокол оракула, который позволяет вашему умному контракту легко получать любые данные, когда это необходимо.

Band Protocol (opens in a new tab) — Band Protocol — это межсетевая платформа оракулов данных, которая агрегирует и подключает реальные данные и API к умным контрактам.

Pyth Network (opens in a new tab) — сеть Pyth — это финансовая сеть оракулов от первого лица, предназначенная для публикации непрерывных данных из реального мира в ончейне в защищенной от несанкционированного доступа, децентрализованной и самодостаточной среде.

API3 DAO (opens in a new tab) — API3 DAO предоставляет решения оракулов от первого лица, которые обеспечивают большую прозрачность источника, безопасность и масштабируемость в децентрализованном решении для умных контрактов

Supra (opens in a new tab) — вертикально интегрированный инструментарий кроссчейн-решений, которые связывают все блокчейны, публичные (L1 и L2) или частные (корпоративные), предоставляя децентрализованные ценовые потоки оракулов, которые могут использоваться для ончейн- и оффчейн-приложений.

Gas Network (opens in a new tab) — распределенная платформа оракулов, предоставляющая данные о ценах на газ в реальном времени для различных блокчейнов. Перенося данные от ведущих поставщиков данных о ценах на газ в ончейн, Gas Network помогает повысить совместимость. Gas Network поддерживает данные для более чем 35 сетей, включая основную сеть Ethereum и многие ведущие L2.

Дополнительные материалы

Статьи

Что такое блокчейн-оракул? (opens in a new tab) — Chainlink
Что такое блокчейн-оракул? (opens in a new tab) — Патрик Коллинз
Децентрализованные оракулы: всеобъемлющий обзор (opens in a new tab) — Жюльен Тевенар
Реализация блокчейн-оракула на Ethereum (opens in a new tab) — Педро Коста
Почему умные контракты не могут совершать вызовы API? (opens in a new tab) — StackExchange
Итак, вы хотите использовать ценовой оракул (opens in a new tab) — samczsun

Видео

Оракулы и расширение полезности блокчейна (opens in a new tab) — Real Vision Finance

Учебники

Как получить текущую цену Ethereum в Solidity (opens in a new tab) — Chainlink
Использование данных оракула (opens in a new tab) — Chronicle

Примеры проектов

Полный стартовый проект Chainlink для Ethereum на Solidity (opens in a new tab) — HackBG