Оракули

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

Надання смарт-контрактам можливості виконуватися з використанням позамережевих даних розширює корисність і цінність децентралізованих застосунків (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) від Педро Кости (Pedro Costa). Це простий сервіс оракула, який може запитувати позамережеві API за запитом інших смарт-контрактів і зберігати запитану інформацію в блокчейні:

pragma solidity >=0.4.21 <0.6.0;

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

  // визначає загальний запит до API
  struct Request {
    uint 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
    );

    // збільшити ідентифікатор запиту
    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), який обчислює медіану всіх наданих значень. Після закінчення вказаного періоду затримки це медіанне значення стає новою довідковою ціною для відповідного активу.

Інші приклади оракулів, які використовують механізми точки Шеллінга, включають 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.
Децентралізовані оракули — як пояснювалося раніше — можуть вимагати від вузлів робити стейк на свою впевненість у правдивості даних, які вони подають. Якщо затребування підтверджується, цей стейк може бути повернений разом із винагородою за чесне обслуговування. Але до нього також може бути застосований слешинг у разі, якщо інформація є неправильною, що забезпечує певну міру підзвітності.

Застосування оракулів у смарт-контрактах

Нижче наведено поширені варіанти використання оракулів в Етеріумі:

Отримання фінансових даних

Застосунки децентралізованих фінансів (DeFi) дозволяють здійснювати однорангове кредитування, запозичення та торгівлю активами. Це часто вимагає отримання різної фінансової інформації, включаючи дані про обмінні курси (для розрахунку фіатної вартості криптовалют або порівняння цін на токени) і дані ринків капіталу (для розрахунку вартості токенізованих активів, таких як золото або долар США).

Протокол кредитування DeFi, наприклад, повинен запитувати поточні ринкові ціни на активи (наприклад, ETH), внесені як застава. Це дозволяє контракту визначити вартість активів застави та визначити, скільки він може запозичити із системи.

Популярні «цінові оракули» (як їх часто називають) у DeFi включають канали цін Чейнлінк (Chainlink Price Feeds), Open Price Feed (opens in a new tab) протоколу Compound, середньозважені за часом ціни (TWAP) (opens in a new tab) Юнісвоп (Uniswap) та оракули 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) сигнального ланцюга надає альтернативне джерело випадковості.

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

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

Отримання результатів для подій

З оракулами створювати смарт-контракти, які реагують на події реального світу, легко. Сервіси оракулів роблять це можливим, дозволяючи контрактам підключатися до зовнішніх 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 на Етеріумі:

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

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) — Теллор — це прозорий і бездозвільний протокол оракула для вашого смарт-контракту, щоб легко отримувати будь-які дані, коли це потрібно.

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.

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

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

Подальше читання

Статті

Що таке блокчейн-оракул? (opens in a new tab) — Chainlink
Що таке блокчейн-оракул? (opens in a new tab) — Патрік Коллінз
Децентралізовані оракули: всебічний огляд (opens in a new tab) — Жульєн Тевенар (Julien Thevenard)
Реалізація блокчейн-оракула в Етеріумі (opens in a new tab) – Педро Коста (Pedro Costa)
Чому смарт-контракти не можуть здійснювати виклики 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) — Chainlink
Споживання даних оракула (opens in a new tab) — Chronicle
Виклик оракулів (opens in a new tab) - Speedrun Ethereum

Приклади проєктів

Повний стартовий проєкт Chainlink для Етеріуму в Solidity (opens in a new tab) — HackBG