Оракулы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое проблема оракула?

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

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

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

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

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

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

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

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

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

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

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

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

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

pragma solidity >=0.4.21 <0.6.0;

contract Oracle {
  Request[] requests; //список запросов, сделанных к контракту
  uint currentId = 0; //увеличивающийся id запроса
  uint minQuorum = 2; //минимальное количество ответов, которое необходимо получить перед объявлением окончательного результата
  uint totalOracleCount = 3; // Жестко заданное количество оракулов

  // определяет общий запрос к API
  struct Request {
    uint id;                            //id запроса
    string urlToQuery;                  //URL API
    string attributeToFetch;            //атрибут json (ключ) для извлечения в ответе
    string agreedValue;                 //значение по ключу
    mapping(uint => string) answers;     //ответы, предоставленные оракулами
    mapping(address => uint) quorum;    //оракулы, которые будут запрашивать ответ (1=оракул не проголосовал, 2=оракул проголосовал)
  }

  //событие, которое запускает оракул вне Блокчейна
  event NewRequest (
    uint id,
    string urlToQuery,
    string attributeToFetch
  );

  //срабатывает, когда достигнут консенсус по окончательному результату
  event UpdatedRequest (
    uint id,
    string urlToQuery,
    string attributeToFetch,
    string agreedValue
  );

  function createRequest (
    string memory _urlToQuery,
    string memory _attributeToFetch
  )
  public
  {
    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
    Request storage r = requests[length-1];

    // Жестко заданный адрес оракулов
    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;

    // запустить событие для обнаружения оракулом вне Блокчейна
    emit NewRequest (
      currentId,
      _urlToQuery,
      _attributeToFetch
    );

    // увеличить id запроса
    currentId++;
  }

  //вызывается оракулом для записи своего ответа
  function updateRequest (
    uint _id,
    string memory _valueRetrieved
  ) public {

    Request storage currRequest = requests[_id];

    //проверить, находится ли оракул в списке доверенных оракулов
    //и не проголосовал ли еще оракул
    if(currRequest.quorum[address(msg.sender)] == 1){

      //отметка о том, что этот адрес проголосовал
      currRequest.quorum[msg.sender] = 2;

      //перебирать "массив" ответов, пока позиция не освободится, и сохранить полученное значение
      uint tmpI = 0;
      bool found = false;
      while(!found) {
        //найти первый пустой слот
        if(bytes(currRequest.answers[tmpI]).length == 0){
          found = true;
          currRequest.answers[tmpI] = _valueRetrieved;
        }
        tmpI++;
      }

      uint currentQuorum = 0;

      //перебрать список оракулов и проверить, достаточно ли оракулов (минимальный кворум)
      //проголосовали за тот же ответ, что и текущий
      for(uint i = 0; i < totalOracleCount; i++){
        bytes memory a = bytes(currRequest.answers[i]);
        bytes memory b = bytes(_valueRetrieved);

        if(keccak256(a) == keccak256(b)){
          currentQuorum++;
          if(currentQuorum >= minQuorum){
            currRequest.agreedValue = _valueRetrieved;
            emit UpdatedRequest (
              currRequest.id,
              currRequest.urlToQuery,
              currRequest.attributeToFetch,
              currRequest.agreedValue
            );
          }
        }
      }
    }
  }
}

Узлы оракула

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

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

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

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

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

Этот тип оракула предоставляет «поток данных», который другие контракты могут регулярно читать для получения информации. Ожидается, что данные в этом случае будут часто меняться, поэтому клиентские контракты должны прослушивать обновления данных в хранилище оракула. Примером является оракул, который предоставляет пользователям последнюю информацию о цене 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 состоит из офчейн-одноранговой сети узлов («ретрансляторов» и «фидов»), которые отправляют рыночные цены на залоговые активы, и ончейн-контракта «Медианизатор» (Medianizer), который вычисляет медиану всех предоставленных значений. По истечении указанного периода задержки это медианное значение становится новой базовой ценой для соответствующего актива.

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

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

Доступность

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

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

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

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

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

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

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

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

Извлечение финансовых данных

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

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

Популярные «ценовые оракулы» (как их часто называют) в DeFi включают ценовые фиды Чейнлинк, открытый ценовой фид (opens in a new tab) протокола Compound, средневзвешенные по времени цены (TWAP) (opens in a new tab) Юнисвоп и оракулы Maker (opens in a new tab).

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

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

pragma solidity ^0.6.7;

import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";

contract PriceConsumerV3 {

    AggregatorV3Interface internal priceFeed;

    /**
     * Сеть: Kovan
     * Агрегатор: ETH/USD
     * Адрес: 0x9326BFA02ADD2366b30bacB125260Af641031331
     */
    constructor() public {
        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
    }

    /**
     * Возвращает последнюю цену
     */
    function getLatestPrice() public view returns (int) {
        (
            uint80 roundID,
            int price,
            uint startedAt,
            uint timeStamp,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();
        return price;
    }
}

Генерация доказуемой случайности

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

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

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

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

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

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

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

Автоматизация смарт-контрактов

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

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

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

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

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

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

Существует множество приложений-оракулов, которые вы можете интегрировать в свое dapp на Эфириуме:

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

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

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

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

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

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

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

Сеть Pyth (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.

DIA (opens in a new tab) — Кроссчейн-сеть оракулов, предоставляющая проверяемые потоки данных для более чем 20 000 активов во всех основных классах активов. DIA получает необработанные торговые данные напрямую с более чем 100 первичных рынков и вычисляет их ончейн, обеспечивая полную прозрачность и проверяемость данных с пользовательскими конфигурациями для любого варианта использования.

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

Дополнительная литература

Статьи

Что такое блокчейн-оракул? (opens in a new tab) — Чейнлинк
Что такое блокчейн-оракул? (opens in a new tab) — Патрик Коллинз
Децентрализованные оракулы: всесторонний обзор (opens in a new tab) — Жюльен Тевенар
Реализация блокчейн-оракула в Эфириуме (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

Руководства

Как получить текущую цену Эфириума в Solidity (opens in a new tab) — Чейнлинк
Потребление данных оракула (opens in a new tab) — Chronicle
Испытание оракулов (opens in a new tab) — Speedrun Ethereum

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

Полный стартовый проект Чейнлинк для Эфириума на Solidity (opens in a new tab) — HackBG