Оракули

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

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

Передумови

Ця сторінка розрахована на читача, знайомого з основами Ethereum, зокрема з вузлами, механізмами досягнення консенсусу та EVM. Ви також повинні добре розуміти смарт-контракти й анатомію смарт-контрактів, особливо .

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

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

Без оракула смарт-контракт був би повністю обмежений даними в ланцюжку.

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

Навіщо смарт-контрактам оракули?

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

Але використання смарт-контрактів для забезпечення виконання угод між людьми не є простим, враховуючи, що Ethereum є детермінованим. Детермінована системаopens in a new tab — це система, яка завжди дає однакові результати за заданого початкового стану та певних вхідних даних, тобто в процесі обчислення вихідних даних із вхідних немає жодної випадковості чи варіації.

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

"Чи підписував власник облікового запису (ідентифікований за допомогою відкритого ключа) цю транзакцію за допомогою парного закритого ключа?"
"Чи достатньо коштів на цьому рахунку для проведення операції?"
"Чи дійсна ця транзакція в контексті цього смарт-контракту?" тощо.

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

Для публічного блокчейну, як-от Ethereum, з тисячами вузлів по всьому світу, що обробляють транзакції, детермінізм має вирішальне значення. За відсутності центрального органу, що слугує джерелом істини, вузлам потрібні механізми для переходу в однаковий стан після застосування однакових транзакцій. Випадок, коли вузол А виконує код смарт-контракту і отримує в результаті "3", в той час як вузол Б отримує "7" після виконання тієї ж транзакції, призведе до порушення консенсусу і нівелює цінність Ethereum'у як децентралізованої обчислювальної платформи.

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

Для цього оракул зазвичай складається зі смарт-контракту, що працює в ланцюжку, і деяких компонентів поза ланцюжком. Контракт у ланцюжку отримує запити на дані від інших смарт-контрактів, які він передає компоненту поза ланцюжком (що називається вузлом оракула). Ця нода оракула може запитувати джерела даних - наприклад, використовуючи інтерфейси прикладного програмування (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; //list of requests made to the contract
5  uint currentId = 0; //increasing request id
6  uint minQuorum = 2; //minimum number of responses to receive before declaring final result
7  uint totalOracleCount = 3; // Hardcoded oracle count
8
9  // defines a general api request
10  struct Request {
11    uint id;                            //request id
12    string urlToQuery;                  //API url
13    string attributeToFetch;            //json attribute (key) to retrieve in the response
14    string agreedValue;                 //value from key
15    mapping(uint => string) answers;     //answers provided by the oracles
16    mapping(address => uint) quorum;    //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted)
17  }
18
19  //event that triggers oracle outside of the blockchain
20  event NewRequest (
21    uint id,
22    string urlToQuery,
23    string attributeToFetch
24  );
25
26  //triggered when there's a consensus on the final result
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    // Hardcoded oracles address
44    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
45    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
46    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
47
48    // launch an event to be detected by oracle outside of blockchain
49    emit NewRequest (
50      currentId,
51      _urlToQuery,
52      _attributeToFetch
53    );
54
55    // increase request id
56    currentId++;
57  }
58
59  //called by the oracle to record its answer
60  function updateRequest (
61    uint _id,
62    string memory _valueRetrieved
63  ) public {
64
65    Request storage currRequest = requests[_id];
66
67    //check if oracle is in the list of trusted oracles
68    //and if the oracle hasn't voted yet
69    if(currRequest.quorum[address(msg.sender)] == 1){
70
71      //marking that this address has voted
72      currRequest.quorum[msg.sender] = 2;
73
74      //iterate through "array" of answers until a position if free and save the retrieved value
75      uint tmpI = 0;
76      bool found = false;
77      while(!found) {
78        //find first empty slot
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      //iterate through oracle list and check if enough oracles(minimum quorum)
89      //have voted the same answer as the current one
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 GETopens in a new tab до служби API, аналіз відповіді для вилучення відповідних даних, форматування у вивід, що читається блокчейном, і надсилання його в ланцюжок шляхом включення в транзакцію до контракту оракула. Від вузла оракула також може знадобитися засвідчити достовірність і цілісність наданої інформації за допомогою "доказів автентичності", які ми розглянемо пізніше.

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

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

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

Цей тип оракула надає «канал даних», який інші контракти можуть регулярно читати для отримання інформації. У цьому випадку очікується, що дані часто змінюватимуться, тому клієнтські контракти повинні прослуховувати оновлення даних у сховищі оракула. Прикладом є оракул, який надає користувачам найновішу інформацію про ціну ETH-USD.

Оракули запиту-відповіді

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

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

Користувачі, які ініціюють запити даних, повинні покривати вартість отримання інформації з джерела поза ланцюжком. Клієнтський контракт також повинен надати кошти для покриття витрат на газ, понесених контрактом оракула під час повернення відповіді через функцію зворотного виклику, зазначену в запиті.

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

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

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

Низькі гарантії правильності

З централізованими оракулами немає можливості підтвердити, чи правильна надана інформація, чи ні. Навіть «авторитетні» постачальники можуть стати шахраями або їх можуть зламати. Якщо оракул стає корумпованим, смарт-контракти будуть виконуватися на основі поганих даних.

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

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

Низька сумісність стимулів

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

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

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

Децентралізований оракул (в ідеалі) має бути бездозвільним, не вимагати довіри та вільним від адміністрування центральною стороною; насправді децентралізація серед оракулів — це спектр. Існують напівдецентралізовані мережі оракулів, у яких може брати участь будь-хто, але є «власник», який схвалює та видаляє вузли на основі попередньої продуктивності. Існують також повністю децентралізовані мережі оракулів: вони зазвичай працюють як автономні блокчейни і мають визначені механізми консенсусу для координації вузлів і покарання за неправомірну поведінку.

Використання децентралізованих оракулів має наступні переваги:

Високі гарантії правильності

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

Докази автентичності

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

Приклади доказів автентичності включають:

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

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

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

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

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

Децентралізовані оракули, однак, повинні мати справу з розбіжностями в інформації, отриманій з декількох джерел поза ланцюжком. Щоб мінімізувати розбіжності в інформації та гарантувати, що дані, передані в оракул-контракт, відображають колективну думку вузлів оракула, децентралізовані оракули використовують наступні механізми:

Голосування/оцінка точності даних

Деякі децентралізовані мережі оракулів вимагають від учасників голосувати або робити ставки на точність відповідей на запити даних (наприклад, "Хто переміг на виборах у США в 2020 році?") використовуючи нативний токен мережі. Потім протокол агрегації об'єднує голоси та ставки і приймає відповідь, підтриману більшістю, як правильну.

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

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

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

Точка Шеллінгаopens in a new tab — це концепція теорії ігор, яка припускає, що кілька об’єктів завжди будуть за замовчуванням приймати спільне розв’язання проблеми за відсутності будь-якого зв’язку. Механізми точок Шеллінга часто використовуються в децентралізованих мережах оракулів, щоб дозволити вузлам досягти консенсусу щодо відповідей на запити даних.

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

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

Інші приклади оракулів, які використовують механізми точки Шеллінга, включають Chainlink Offchain Reportingopens in a new tab і Witnetopens in a new tab. В обох системах відповіді від вузлів оракула в одноранговій мережі зводяться в єдине загальне значення, наприклад, середнє або медіану. Вузли заохочуються або караються відповідно до того, наскільки їхні відповіді збігаються або відхиляються від загального значення.

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

Доступність

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

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

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

Хороша сумісність стимулів

Децентралізовані оракули реалізують різні схеми стимулювання, щоб запобігти візантійськійopens in a new tab поведінці серед вузлів оракулів. Зокрема, вони досягають можливості атрибуції та підзвітності:

Децентралізовані вузли оракула часто повинні підписувати дані, які вони надають у відповідь на запити даних. Ця інформація допомагає оцінити історичну продуктивність вузлів оракула, щоб користувачі могли відфільтрувати ненадійні вузли оракула під час запитів даних. Прикладом є алгоритмічна система репутаціїopens in a new tab Witnet.
Децентралізовані оракули - як пояснювалося раніше - можуть вимагати від вузлів зробити ставку на їхню впевненість у правдивості даних, які вони надають. Якщо претензія підтверджується, ця частка може бути повернута разом із винагородою за чесне обслуговування. Але її також можна скоротити, якщо інформація невірна, що забезпечує певний рівень підзвітності.

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

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

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

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

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

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

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

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

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

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

Використання оракулів для отримання даних на основі реальних результатів дає змогу використовувати інші нові варіанти; наприклад, для ефективної роботи децентралізованого страхового продукту потрібна точна інформація про погоду, стихійні лиха тощо.

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

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

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

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

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

Мережа Keeper Networkopens in a new tab від Chainlink надає можливості для смарт-контрактів передавати на аутсорсинг регулярні завдання з технічного обслуговування в мінімізований за довірою та децентралізований спосіб. Прочитайте офіційну документацію Keeper'sopens in a new tab, щоб отримати інформацію про те, як зробити ваш контракт сумісним з Keeper і використовувати службу Upkeep.

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

Існує кілька застосунків-оракулів, які ви можете інтегрувати у свій децентралізований застосунок Ethereum:

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

RedStone Oraclesopens in a new tab - RedStone — це децентралізований модульний оракул, який надає оптимізовані за газом канали даних. Він спеціалізується на пропонуванні цінових каналів для нових активів, як-от токени ліквідного стейкінгу (LST), токени ліквідного рестейкінгу (LRT) і похідні інструменти стейкінгу Bitcoin.

Chronicleopens in a new tab - Chronicle долає поточні обмеження передачі даних у ланцюжку, розробляючи справді масштабовані, економічно ефективні, децентралізовані та перевірні оракули.

Witnetopens in a new tab - Witnet — це бездозвільний, децентралізований і стійкий до цензури оракул, що допомагає смарт-контрактам реагувати на реальні події з сильними крипто-економічними гарантіями.

UMA Oracleopens in a new tab - Оптимістичний оракул UMA дає змогу смарт-контрактам швидко отримувати будь-які дані для різних застосунків, зокрема страхування, фінансових деривативів і ринків прогнозів.

Telloropens in a new tab - Tellor — це прозорий і бездозвільний протокол оракула, за допомогою якого ваш смарт-контракт може легко отримати будь-які дані, коли вони йому потрібні.

Band Protocolopens in a new tab - Band Protocol — це міжланцюгова платформа оракула даних, яка агрегує та підключає реальні дані та API до смарт-контрактів.

Pyth Networkopens in a new tab - Мережа Pyth — це першостороння фінансова мережа оракулів, призначена для публікації безперервних реальних даних у ланцюжку в захищеному від несанкціонованого доступу, децентралізованому та самодостатньому середовищі.

API3 DAOopens in a new tab - API3 DAO надає першосторонні рішення оракулів, які забезпечують більшу прозорість джерел, безпеку та масштабованість у децентралізованому рішенні для смарт-контрактів

Supraopens in a new tab - вертикально інтегрований набір інструментів для міжланцюгових рішень, які об’єднують усі блокчейни, публічні (L1 та L2) або приватні (підприємства), надаючи децентралізовані цінові канали оракулів, які можна використовувати для випадків у ланцюжку та поза ланцюжком.

Gas Networkopens 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 — Жульєн Тевенар
Реалізація блокчейн-оракула на Ethereumopens 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 у Solidityopens in a new tab — Chainlink
Споживання даних оракулаopens in a new tab — Chronicle

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

Повний стартовий проєкт Chainlink для Ethereum на Solidityopens in a new tab — HackBG