У випадку відносно млявого ринку попит на машини Oracle демонструє тенденцію до експоненціального зростання.
Говорить: Френк, інженер із зв’язків із розробниками, Chainlink Labs
Організація: aididiaojp.eth, Foresight News
Я Френк, інженер із зв’язків із розробниками в Chainlink Labs. Моя основна робота полягає в тому, щоб надати більше розробників або будівельників, які захоплені цією галуззю, дізнатися більше про машини Oracle. Виходячи з розумних контрактів у нашій поточній інфраструктурі, ми можемо розглядати це як гібридний смарт-контракт. Смарт-контракти можна краще інтегрувати з різними даними у світі Web2, включаючи обчислювальні сервіси, а потім на основі цієї архітектури можливості смарт-контрактів у ланцюжку значно розширюються.
У сьогоднішній розмові я спершу познайомлю концепцію машини оракул, а потім, спираючись на концепцію машини оракул, я коротко познайомлю децентралізовану мережу машини оракул і деякі послуги, які ми можемо надавати, включаючи служби даних і обчислювальні послуги.
Що таке оракул?
Від Web 1 до Web 2 і Web 3 стан мережі та даних постійно змінюється. Спочатку Web1 був веб-сервісом, дані якого можна було читати лише статично. Коли він розвинувся до етапу Web2, дані стали доступними для читання, запису та участі. Багато великих компаній створили бізнес-імперії на базі власних сервісів, вони зберігатимуть усі дані користувачів у власних базах даних, а за потреби зможуть фактично володіти та змінювати дані користувачів. У цьому випадку виникає питання, тобто деякі дані, які ми створюємо в Інтернеті або у віртуальному світі, іноді мають певну цінність, тож кому ця цінність належить? Виходячи з цього, ми сподіваємося, що зможемо добре вирішити цю проблему на етапі Web 3. Усі дані на етапі Web 3 не існують на сервері чи вузлі.Вона має децентралізовану мережу, а децентралізована мережа є системою з кількома книгами, що складається з кількох вузлів. Дані зберігаються в кількох вузлах, і лише коли кожен вузол погоджується на зміну та зберігання даних, остаточні дані можуть бути збережені. Тоді це принесе нам користь, тобто незалежно від того, які зміни ми хочемо внести в дані, нам потрібно змінити їх відповідно до попередньо узгодженого консенсусу. Наприклад, якщо я хочу змінити баланс гаманця, якщо ніхто не надішле мені гроші, незалежно від того, як власник даних хоче це змінити, він зрештою провалить процес консенсусу, через що баланс гаманця не зможе бути змінений. Тільки коли власник даних надсилає транзакцію, яка відповідає правилам, дані можуть бути остаточно змінені, що приносить дуже очевидну вигоду. У той же час це також приносить деякі недоліки.Найбільший недолік полягає в тому, що він робить систему детермінованою. Тобто, оскільки процес консенсусу відбуватиметься протягом усього процесу, він може виконувати лише операції, які інші можуть перевірити. Коли ви надсилаєте операцію, інші повинні виконати вашу операцію, і якщо інші вузли виконають операцію успішно, вони можуть фактично повернути результат. Що стосується того, чи буде він більше 50% чи 70%, це залежить від алгоритму консенсусу. Зрештою операцію можна записати в транзакцію, а транзакцію можна записати в блок, щоб стати повною транзакцією.
Але якщо нам потрібно виконати деякі недетерміновані операції, такі як отримання деяких даних API та генерація випадкових чисел поза блокчейном, детермінована система блокчейну не може бути завершена. Наш розіграш має генерувати випадкові числа або протокол у ланцюжку повинен знати ціну активу поза ланцюгом, наприклад придбання ціни акцій або товарів, що є недетермінованою операцією, і не може бути виконана самим блокчейном. . Іншим прикладом є виклики API. Якщо я, як вузол у мережі, викликаю зовнішні дані API, а потім повідомляю результат іншим вузлам у мережі, інші вузли також виконають його, щоб перевірити автентичність результату. ту саму операцію та отримати результат. Але для зовнішнього API, якщо різні люди отримують той самий API в різний час, сервер може зависнути, або служба може бути призупинена, або дані можуть змінитися з часом. Ви робите те саме в різний час, і результати ви отримуєте суперечливі. Поки результат непослідовний, остаточна операція не може бути введена в блок, і немає можливості завершити її. Це після того, як ми маємо право власності на дані, ми також повинні нести деякі недоліки, які це приносить.
Щоб вирішити цю проблему, нам потрібно покладатися на оракулів. Блокчейн є ізольованою детермінованою системою, вона не може активно отримувати дані з оф-чейну, поява машини Oracle має вирішити цю проблему. Два-три роки тому з'явилася концепція машини-оракула, але на той час не було багато застосовних сценаріїв, і вона мала великі обмеження. Наприклад, якщо ви хочете отримати певні ринкові дані, завантажити дані про акції в мережу блокчейну або створити структуру, щоб розмістити логіку в ланцюжку для виконання, але включити в ланцюжок сторону активів і захистити нормальний хід транзакцій через смарт-контракти тощо. У цей час потрібно отримати деякі дані з ланцюга та періодично виконувати синхронізацію даних, включаючи банківські платежі чи роздрібні дані, і навіть деякі інші публічні дані про події, такі як погодні умови, географічні інформація, інформація про логістику, інформація про спорт тощо. Результати ігор тощо. Ці дані неможливо отримати без машини Oracle. Це зробить екологію в ланцюзі дуже обмеженою. З постійним розвитком екосистеми Web 3 зв’язок між двома світами Web 3 і Web 2 ставатиме все тіснішим і тіснішим. Якщо ми хочемо, щоб Web3 був прийнятий у великих масштабах або використовувався більшою кількістю людей, він повинен надавати дуже багаті функції, а не обмежуватися лише деякими операціями, які можна виконати лише через вихідні дані в ланцюжку.
Ймовірно, машина Oracle стала популярною у 2020 році, коли було DeFiSummer, і більшість людей це зрозуміли. На початку машина Oracle робила дуже прості речі. Наприклад, якщо ви хочете отримати зовнішні дані та завантажити їх у децентралізовану мережу, тобто блокчейн, найпростішим способом буде встановити централізований вузол у ланцюжку, який це, щоб створити сервер, потім отримує дані через сервер і, нарешті, записує дані в дедупліковану мережу блокчейну, тоді ця модель називається централізованим оракулом. Хоча це відносно просто реалізувати, це спричинить певні проблеми.Наприклад, він має ризик єдиної точки відмови, тобто централізований вузол може призвести до простою через власні основні причини. Інша можливість полягає в тому, що якщо послуга, яку надає смарт-контракт у ланцюжку, залежить від даних, наданих централізованим вузлом, і якщо сума коштів, залучених у смарт-контракт у ланцюжку, дуже велика, тоді ця централізована машина-оракул може пройти власні Дані, якими можна маніпулювати, щоб почати атаку на службу. Поки переваги є досить великими і немає можливості досягти повноти за допомогою технічних засобів, це єдина точка провалу. Ми хочемо розмістити програму в децентралізованій мережі, включаючи Ethereum або інші екосистеми рівня 2. Фактично, ми також сподіваємося, що зможемо забезпечити чесність нашої програми, тобто смарт-контракту, через сотні чи тисячі вузлів oracle в мережі та безпеки.
Звичайно, якщо ми покладаємося на централізовані вузли для отримання терміналів даних, навіть якщо можна гарантувати інші аспекти безпеки, але найважливіший термінал даних активів не може гарантувати безпеку, це зробить весь dApp безглуздим. Таким чином, після централізованої машини оракул, є децентралізована мережа машини оракул, яка може добре усунути ризик єдиної точки відмови, про яку ми щойно згадували. Найбільша відмінність у децентралізованій мережі Oracle полягає не в тому, що один вузол Oracle надає послуги децентралізованій мережі, а через децентралізовану мережу Oracle.Це також можна розуміти як різновид Layer2, тобто кожен децентралізований вузол у децентралізованій мережі Oracle Мережа oracle може отримувати дані через власні джерела даних, і після отримання результатів вони можуть виконувати агрегацію даних з іншими децентралізованими мережами, що також можна розуміти як консенсусний процес, включаючи перевірку того, чи є дані. Чи є вузли, чи чи повернуті дані надто сильно відхиляються від середнього значення, або просто зробіть середнє значення, потім агрегуйте дані тощо, а потім запишіть їх у децентралізовану мережу. Одна з переваг цього методу полягає в тому, що технічно він може гарантувати, що служба не буде перервана, якщо всі вузли в децентралізованій мережі Oracle не припинять обслуговування, але така можливість дуже низька. Крім того, з боку даних також можна гарантувати, що дані, надані оракулом для контракту в ланцюжку, контролюються не одним вузлом, а багатьма вузлами. Якщо ви хочете маніпулювати даними, щоб розпочати атаку, ціна буде дуже високою, що еквівалентно атаці рівня 2 або навіть децентралізованої мережі, як-от Ethereum, яка в принципі навряд чи вдасться.
Децентралізована мережа може значно підвищити безпеку та чесність даних, отриманих смарт-контрактами. Для користувачів ми лише децентралізована мережа Oracle, але на основі децентралізованої мережі Oracle ми можемо надавати деякі інші послуги, такі як служби даних, обчислювальні послуги та міжланцюгові послуги. Якщо він базується на машині оракула для надання даних у мережу, насправді є деякі більш складні та дорогі операції, які також можуть бути виконані поза ланцюгом, тобто він упаковується в оф-чейн мережу оракула для розрахунків , а потім записується назад у високий блокчейн порівняння безпеки. Якщо ми можемо отримувати дані з інших ланцюжків, ми також можемо отримувати дані з інших ланцюгів і записувати їх у цей блокчейн, що фактично включає крос-ланцюг. Поки безпека децентралізованої мережі Oracle достатньо сильна, вона може гарантувати безпеку служб даних, обчислювальних служб і міжланцюжкових служб на її основі. Chainlink надає різноманітні сервіси на основі децентралізованих оракулів, які можуть з’єднувати дані Web 3 і Web 2, включаючи дані рівня 1 і рівня 2, щоб кожен міг отримати якомога більше відповідних даних і послуг.
Які послуги надає Chainlink oracles?
Далі дозвольте мені коротко представити послуги, які надає оракул Chainlink. Звичайно, існує багато сервісів, заснованих на Chainlink, і я поділюся деякими сервісами з більш придатними сценаріями.
Якщо ви захочете в майбутньому зробити деякі інновації в сферах DeFi, GameFi, NFT і SocialFi, є висока ймовірність, що вам знадобиться оракул для отримання даних. Тому що ви повинні отримати дані ланцюжка дуже децентралізованим і безпечним способом і записати їх назад у свій смарт-контракт у ланцюжку.
Перша послуга – це інформація про ціни, яку ви часто чули раніше, і ця послуга вибухне в DeFiSummer у 2020 році. У 2020 році з’явилося багато проектів DeFi, починаючи з Uniswap, за яким пішов lending contract Compound, а потім проект синтетичних активів Synthetics та інші додатки.Всі вони мають великий попит на дані поза мережею, тому що можна використовувати лише безпечні дані. Дані можуть використовуватися користувачами децентралізовано за допомогою контрактів, і важливу роль відіграє служба цінових каналів оракула.
На малюнку вище наведена базова блок-схема служби подачі цін, яка включає 3 важливих учасників. Перший — це децентралізована мережа машин Oracle, про яку ми щойно згадали; другий — це постачальники даних, якими можуть бути біржі чи інші великі авторитетні установи, усі з яких можуть виступати в якості постачальників даних; третій — контракт користувача. Процес, показаний на малюнку вище, дуже простий. Кожен постачальник даних може надати вузол мережі оракула Chanlink через інтерфейс джерела даних або службу, і кожен вузол мережі оракула також може отримувати дані відповідно до власної служби. , і потім у процесі агрегації дані, отримані кожним каналом, записуються в контракт перевірки, розгорнутий у ланцюжку. Якщо він пройшов перевірку, дані можуть бути записані та використані користувачами в майбутньому. Це весь процес. Клієнту потрібно використовувати договір лише для отримання та використання кількох даних.
Існує багато варіантів використання цінової подачі, як-от Compound, Uniswap і Synthetics, про які ми щойно згадували, їм потрібно відобразити активи в Web2 до Web3, і їм потрібні зовнішні механізми для надання цін на активи. Так само, як і стейблкойн, він базується на тому, скільки активів може випустити стільки стейблкойнів, і його ціну активу також слід отримати на основі машини оракула. Крім того, як і деякі платформи управління активами та популярні додатки для торгівлі деривативами, вони сильно залежать від цін, тому вони насправді є важливими користувачами служб формування цін. З точки зору тенденції, попит на послуги цінового каналу зростає експоненціально. Використання даних зростає навіть на менш активних ринках.
Далі я розповім про другу більш відмітну послугу, Any API.Простіше кажучи, вона допомагає смарт-контрактам у ланцюжку отримувати деякі нестандартні дані, такі як дані з довгим хвостом. Ці дані можуть бути доступні лише певним людям або певним контрактам, але це не стандартні дані, такі як ціни на токени або ціни на активи. Багато DApps вимагають нестандартних даних. Наприклад, страхові бізнес-додатки Web 3 потребують отримання даних про погоду або дані про затримку рейсів. Наприклад, парникові гази можуть створювати деякі проекти, подібні до ESG, зокрема виборчі спортивні ігри можна поєднувати з ринками прогнозів. Ми надаємо ринки даних на основі будь-якого API. На кожному ринку даних є різні постачальники даних, які надають зовнішні послуги на основі власних даних. Поки користувач надсилає запит, він може записати дані назад у договір користувача відповідно до вимоги до обслуговування.. Як постачальник даних, так і отримувач даних визначаються ринком. Існує ринок для користувачів і постачальників даних, і Chainlink офіційно не монополізує всі дані, а потім надає дані в мережу.
Робочий процес Any API і каналу цін насправді досить послідовний.Контракт спочатку надсилає запит, а потім цей запит виявляють вузли Chanlink. Після виявлення Chanlink може вибрати необхідні дані відповідно до запиту, а потім записати їх назад у блокчейн. AnyAPI може надавати користувачам різноманітні дані, але його характеристика полягає в тому, що хоча він створюється відносно швидко, він надається одним вузлом. Те, що AnyAPI хоче зробити, це отримати дані якомога швидше простим способом, замість того, щоб отримувати дані через децентралізовану мережеву машину Oracle, про яку ми згадували раніше.
Пізніше, коли розмаїття вимог до даних зросло, багато нестандартних даних також сподівалися записати в ланцюжок децентралізованим способом. На початку квітня цього року ми також створили новий сервіс під назвою Functions.Простіше кажучи, він виконує будь-який запит користувача через децентралізовану мережу Oracle. Користувачі можуть використовувати деякі передові мови програмування, такі як Java, щоб написати операційну програму, більше не можна писати лише мовою Solidity, програм, написаних на Java, безумовно, більше, ніж Solidity. Служба Functions може інкапсулювати написану програму в запит і відправляти її до всієї мережі Oracle. Кожен вузол у мережі виконуватиме ту саму операцію, яка може бути обчислювальними службами, службами збору даних або іншими службами. Після того, як кожен вузол виконується й отримує результат, він проходить процес агрегації, про який ми щойно згадували, а потім записує його назад у смарт-контракт.
У порівнянні з ціною корму його ступінь свободи дуже високий. Тобто смарт-контракту можна надати зовнішній інтерфейс для використання будь-якого методу, який він хоче. Він також може записати певну логіку, яку він має виконувати, у контракті, і тоді він виконується не блокчейном, а машиною Oracle, що еквівалентно безпосередньому вбудовуванню служби машини Oracle у смарт-контракт, стаючи гібридом тип смарт-контракту. Якщо ви зробите це таким чином, то ваше виконання гарантується через децентралізовану мережу, а ваші недетерміновані операції є операціями, які не можуть бути виконані в блокчейні, але можуть бути виконані через децентралізовану машину оракула. Мережа виконує та повертає результат. . Загалом це може значно покращити функціональність смарт-контрактів. Функцій, які він може виконувати, стане більше, ніж раніше, і його також дуже просто застосувати на стороні клієнта. Вам потрібно лише додати дві функції до свого контракту, і ви зможете безпосередньо використовувати децентралізовану мережу Oracle як частину свого розумного контракт.використовувати. Крім того, він дуже зручний для традиційних програмістів Web2, оскільки логіку виконання можна завершити за допомогою традиційних мов програмування. Загальний процес не змінився. Запит надсилається, потім надсилається до децентралізованої мережі Oracle, агрегується після виконання та, нарешті, записується назад у смарт-контракт користувача.
Вище я розповів про машину Oracle і деякі служби, які може надати децентралізована мережа на основі машини Oracle.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Інженери Chainlink: як Oracles з’єднують Web2 і Web3
Говорить: Френк, інженер із зв’язків із розробниками, Chainlink Labs
Організація: aididiaojp.eth, Foresight News
Я Френк, інженер із зв’язків із розробниками в Chainlink Labs. Моя основна робота полягає в тому, щоб надати більше розробників або будівельників, які захоплені цією галуззю, дізнатися більше про машини Oracle. Виходячи з розумних контрактів у нашій поточній інфраструктурі, ми можемо розглядати це як гібридний смарт-контракт. Смарт-контракти можна краще інтегрувати з різними даними у світі Web2, включаючи обчислювальні сервіси, а потім на основі цієї архітектури можливості смарт-контрактів у ланцюжку значно розширюються.
У сьогоднішній розмові я спершу познайомлю концепцію машини оракул, а потім, спираючись на концепцію машини оракул, я коротко познайомлю децентралізовану мережу машини оракул і деякі послуги, які ми можемо надавати, включаючи служби даних і обчислювальні послуги.
Що таке оракул?
Від Web 1 до Web 2 і Web 3 стан мережі та даних постійно змінюється. Спочатку Web1 був веб-сервісом, дані якого можна було читати лише статично. Коли він розвинувся до етапу Web2, дані стали доступними для читання, запису та участі. Багато великих компаній створили бізнес-імперії на базі власних сервісів, вони зберігатимуть усі дані користувачів у власних базах даних, а за потреби зможуть фактично володіти та змінювати дані користувачів. У цьому випадку виникає питання, тобто деякі дані, які ми створюємо в Інтернеті або у віртуальному світі, іноді мають певну цінність, тож кому ця цінність належить? Виходячи з цього, ми сподіваємося, що зможемо добре вирішити цю проблему на етапі Web 3. Усі дані на етапі Web 3 не існують на сервері чи вузлі.Вона має децентралізовану мережу, а децентралізована мережа є системою з кількома книгами, що складається з кількох вузлів. Дані зберігаються в кількох вузлах, і лише коли кожен вузол погоджується на зміну та зберігання даних, остаточні дані можуть бути збережені. Тоді це принесе нам користь, тобто незалежно від того, які зміни ми хочемо внести в дані, нам потрібно змінити їх відповідно до попередньо узгодженого консенсусу. Наприклад, якщо я хочу змінити баланс гаманця, якщо ніхто не надішле мені гроші, незалежно від того, як власник даних хоче це змінити, він зрештою провалить процес консенсусу, через що баланс гаманця не зможе бути змінений. Тільки коли власник даних надсилає транзакцію, яка відповідає правилам, дані можуть бути остаточно змінені, що приносить дуже очевидну вигоду. У той же час це також приносить деякі недоліки.Найбільший недолік полягає в тому, що він робить систему детермінованою. Тобто, оскільки процес консенсусу відбуватиметься протягом усього процесу, він може виконувати лише операції, які інші можуть перевірити. Коли ви надсилаєте операцію, інші повинні виконати вашу операцію, і якщо інші вузли виконають операцію успішно, вони можуть фактично повернути результат. Що стосується того, чи буде він більше 50% чи 70%, це залежить від алгоритму консенсусу. Зрештою операцію можна записати в транзакцію, а транзакцію можна записати в блок, щоб стати повною транзакцією.
Але якщо нам потрібно виконати деякі недетерміновані операції, такі як отримання деяких даних API та генерація випадкових чисел поза блокчейном, детермінована система блокчейну не може бути завершена. Наш розіграш має генерувати випадкові числа або протокол у ланцюжку повинен знати ціну активу поза ланцюгом, наприклад придбання ціни акцій або товарів, що є недетермінованою операцією, і не може бути виконана самим блокчейном. . Іншим прикладом є виклики API. Якщо я, як вузол у мережі, викликаю зовнішні дані API, а потім повідомляю результат іншим вузлам у мережі, інші вузли також виконають його, щоб перевірити автентичність результату. ту саму операцію та отримати результат. Але для зовнішнього API, якщо різні люди отримують той самий API в різний час, сервер може зависнути, або служба може бути призупинена, або дані можуть змінитися з часом. Ви робите те саме в різний час, і результати ви отримуєте суперечливі. Поки результат непослідовний, остаточна операція не може бути введена в блок, і немає можливості завершити її. Це після того, як ми маємо право власності на дані, ми також повинні нести деякі недоліки, які це приносить.
Щоб вирішити цю проблему, нам потрібно покладатися на оракулів. Блокчейн є ізольованою детермінованою системою, вона не може активно отримувати дані з оф-чейну, поява машини Oracle має вирішити цю проблему. Два-три роки тому з'явилася концепція машини-оракула, але на той час не було багато застосовних сценаріїв, і вона мала великі обмеження. Наприклад, якщо ви хочете отримати певні ринкові дані, завантажити дані про акції в мережу блокчейну або створити структуру, щоб розмістити логіку в ланцюжку для виконання, але включити в ланцюжок сторону активів і захистити нормальний хід транзакцій через смарт-контракти тощо. У цей час потрібно отримати деякі дані з ланцюга та періодично виконувати синхронізацію даних, включаючи банківські платежі чи роздрібні дані, і навіть деякі інші публічні дані про події, такі як погодні умови, географічні інформація, інформація про логістику, інформація про спорт тощо. Результати ігор тощо. Ці дані неможливо отримати без машини Oracle. Це зробить екологію в ланцюзі дуже обмеженою. З постійним розвитком екосистеми Web 3 зв’язок між двома світами Web 3 і Web 2 ставатиме все тіснішим і тіснішим. Якщо ми хочемо, щоб Web3 був прийнятий у великих масштабах або використовувався більшою кількістю людей, він повинен надавати дуже багаті функції, а не обмежуватися лише деякими операціями, які можна виконати лише через вихідні дані в ланцюжку.
Ймовірно, машина Oracle стала популярною у 2020 році, коли було DeFiSummer, і більшість людей це зрозуміли. На початку машина Oracle робила дуже прості речі. Наприклад, якщо ви хочете отримати зовнішні дані та завантажити їх у децентралізовану мережу, тобто блокчейн, найпростішим способом буде встановити централізований вузол у ланцюжку, який це, щоб створити сервер, потім отримує дані через сервер і, нарешті, записує дані в дедупліковану мережу блокчейну, тоді ця модель називається централізованим оракулом. Хоча це відносно просто реалізувати, це спричинить певні проблеми.Наприклад, він має ризик єдиної точки відмови, тобто централізований вузол може призвести до простою через власні основні причини. Інша можливість полягає в тому, що якщо послуга, яку надає смарт-контракт у ланцюжку, залежить від даних, наданих централізованим вузлом, і якщо сума коштів, залучених у смарт-контракт у ланцюжку, дуже велика, тоді ця централізована машина-оракул може пройти власні Дані, якими можна маніпулювати, щоб почати атаку на службу. Поки переваги є досить великими і немає можливості досягти повноти за допомогою технічних засобів, це єдина точка провалу. Ми хочемо розмістити програму в децентралізованій мережі, включаючи Ethereum або інші екосистеми рівня 2. Фактично, ми також сподіваємося, що зможемо забезпечити чесність нашої програми, тобто смарт-контракту, через сотні чи тисячі вузлів oracle в мережі та безпеки.
Звичайно, якщо ми покладаємося на централізовані вузли для отримання терміналів даних, навіть якщо можна гарантувати інші аспекти безпеки, але найважливіший термінал даних активів не може гарантувати безпеку, це зробить весь dApp безглуздим. Таким чином, після централізованої машини оракул, є децентралізована мережа машини оракул, яка може добре усунути ризик єдиної точки відмови, про яку ми щойно згадували. Найбільша відмінність у децентралізованій мережі Oracle полягає не в тому, що один вузол Oracle надає послуги децентралізованій мережі, а через децентралізовану мережу Oracle.Це також можна розуміти як різновид Layer2, тобто кожен децентралізований вузол у децентралізованій мережі Oracle Мережа oracle може отримувати дані через власні джерела даних, і після отримання результатів вони можуть виконувати агрегацію даних з іншими децентралізованими мережами, що також можна розуміти як консенсусний процес, включаючи перевірку того, чи є дані. Чи є вузли, чи чи повернуті дані надто сильно відхиляються від середнього значення, або просто зробіть середнє значення, потім агрегуйте дані тощо, а потім запишіть їх у децентралізовану мережу. Одна з переваг цього методу полягає в тому, що технічно він може гарантувати, що служба не буде перервана, якщо всі вузли в децентралізованій мережі Oracle не припинять обслуговування, але така можливість дуже низька. Крім того, з боку даних також можна гарантувати, що дані, надані оракулом для контракту в ланцюжку, контролюються не одним вузлом, а багатьма вузлами. Якщо ви хочете маніпулювати даними, щоб розпочати атаку, ціна буде дуже високою, що еквівалентно атаці рівня 2 або навіть децентралізованої мережі, як-от Ethereum, яка в принципі навряд чи вдасться.
Децентралізована мережа може значно підвищити безпеку та чесність даних, отриманих смарт-контрактами. Для користувачів ми лише децентралізована мережа Oracle, але на основі децентралізованої мережі Oracle ми можемо надавати деякі інші послуги, такі як служби даних, обчислювальні послуги та міжланцюгові послуги. Якщо він базується на машині оракула для надання даних у мережу, насправді є деякі більш складні та дорогі операції, які також можуть бути виконані поза ланцюгом, тобто він упаковується в оф-чейн мережу оракула для розрахунків , а потім записується назад у високий блокчейн порівняння безпеки. Якщо ми можемо отримувати дані з інших ланцюжків, ми також можемо отримувати дані з інших ланцюгів і записувати їх у цей блокчейн, що фактично включає крос-ланцюг. Поки безпека децентралізованої мережі Oracle достатньо сильна, вона може гарантувати безпеку служб даних, обчислювальних служб і міжланцюжкових служб на її основі. Chainlink надає різноманітні сервіси на основі децентралізованих оракулів, які можуть з’єднувати дані Web 3 і Web 2, включаючи дані рівня 1 і рівня 2, щоб кожен міг отримати якомога більше відповідних даних і послуг.
Які послуги надає Chainlink oracles?
Далі дозвольте мені коротко представити послуги, які надає оракул Chainlink. Звичайно, існує багато сервісів, заснованих на Chainlink, і я поділюся деякими сервісами з більш придатними сценаріями.
Якщо ви захочете в майбутньому зробити деякі інновації в сферах DeFi, GameFi, NFT і SocialFi, є висока ймовірність, що вам знадобиться оракул для отримання даних. Тому що ви повинні отримати дані ланцюжка дуже децентралізованим і безпечним способом і записати їх назад у свій смарт-контракт у ланцюжку.
Перша послуга – це інформація про ціни, яку ви часто чули раніше, і ця послуга вибухне в DeFiSummer у 2020 році. У 2020 році з’явилося багато проектів DeFi, починаючи з Uniswap, за яким пішов lending contract Compound, а потім проект синтетичних активів Synthetics та інші додатки.Всі вони мають великий попит на дані поза мережею, тому що можна використовувати лише безпечні дані. Дані можуть використовуватися користувачами децентралізовано за допомогою контрактів, і важливу роль відіграє служба цінових каналів оракула.
На малюнку вище наведена базова блок-схема служби подачі цін, яка включає 3 важливих учасників. Перший — це децентралізована мережа машин Oracle, про яку ми щойно згадали; другий — це постачальники даних, якими можуть бути біржі чи інші великі авторитетні установи, усі з яких можуть виступати в якості постачальників даних; третій — контракт користувача. Процес, показаний на малюнку вище, дуже простий. Кожен постачальник даних може надати вузол мережі оракула Chanlink через інтерфейс джерела даних або службу, і кожен вузол мережі оракула також може отримувати дані відповідно до власної служби. , і потім у процесі агрегації дані, отримані кожним каналом, записуються в контракт перевірки, розгорнутий у ланцюжку. Якщо він пройшов перевірку, дані можуть бути записані та використані користувачами в майбутньому. Це весь процес. Клієнту потрібно використовувати договір лише для отримання та використання кількох даних.
Існує багато варіантів використання цінової подачі, як-от Compound, Uniswap і Synthetics, про які ми щойно згадували, їм потрібно відобразити активи в Web2 до Web3, і їм потрібні зовнішні механізми для надання цін на активи. Так само, як і стейблкойн, він базується на тому, скільки активів може випустити стільки стейблкойнів, і його ціну активу також слід отримати на основі машини оракула. Крім того, як і деякі платформи управління активами та популярні додатки для торгівлі деривативами, вони сильно залежать від цін, тому вони насправді є важливими користувачами служб формування цін. З точки зору тенденції, попит на послуги цінового каналу зростає експоненціально. Використання даних зростає навіть на менш активних ринках.
Далі я розповім про другу більш відмітну послугу, Any API.Простіше кажучи, вона допомагає смарт-контрактам у ланцюжку отримувати деякі нестандартні дані, такі як дані з довгим хвостом. Ці дані можуть бути доступні лише певним людям або певним контрактам, але це не стандартні дані, такі як ціни на токени або ціни на активи. Багато DApps вимагають нестандартних даних. Наприклад, страхові бізнес-додатки Web 3 потребують отримання даних про погоду або дані про затримку рейсів. Наприклад, парникові гази можуть створювати деякі проекти, подібні до ESG, зокрема виборчі спортивні ігри можна поєднувати з ринками прогнозів. Ми надаємо ринки даних на основі будь-якого API. На кожному ринку даних є різні постачальники даних, які надають зовнішні послуги на основі власних даних. Поки користувач надсилає запит, він може записати дані назад у договір користувача відповідно до вимоги до обслуговування.. Як постачальник даних, так і отримувач даних визначаються ринком. Існує ринок для користувачів і постачальників даних, і Chainlink офіційно не монополізує всі дані, а потім надає дані в мережу.
Робочий процес Any API і каналу цін насправді досить послідовний.Контракт спочатку надсилає запит, а потім цей запит виявляють вузли Chanlink. Після виявлення Chanlink може вибрати необхідні дані відповідно до запиту, а потім записати їх назад у блокчейн. AnyAPI може надавати користувачам різноманітні дані, але його характеристика полягає в тому, що хоча він створюється відносно швидко, він надається одним вузлом. Те, що AnyAPI хоче зробити, це отримати дані якомога швидше простим способом, замість того, щоб отримувати дані через децентралізовану мережеву машину Oracle, про яку ми згадували раніше.
Пізніше, коли розмаїття вимог до даних зросло, багато нестандартних даних також сподівалися записати в ланцюжок децентралізованим способом. На початку квітня цього року ми також створили новий сервіс під назвою Functions.Простіше кажучи, він виконує будь-який запит користувача через децентралізовану мережу Oracle. Користувачі можуть використовувати деякі передові мови програмування, такі як Java, щоб написати операційну програму, більше не можна писати лише мовою Solidity, програм, написаних на Java, безумовно, більше, ніж Solidity. Служба Functions може інкапсулювати написану програму в запит і відправляти її до всієї мережі Oracle. Кожен вузол у мережі виконуватиме ту саму операцію, яка може бути обчислювальними службами, службами збору даних або іншими службами. Після того, як кожен вузол виконується й отримує результат, він проходить процес агрегації, про який ми щойно згадували, а потім записує його назад у смарт-контракт.
У порівнянні з ціною корму його ступінь свободи дуже високий. Тобто смарт-контракту можна надати зовнішній інтерфейс для використання будь-якого методу, який він хоче. Він також може записати певну логіку, яку він має виконувати, у контракті, і тоді він виконується не блокчейном, а машиною Oracle, що еквівалентно безпосередньому вбудовуванню служби машини Oracle у смарт-контракт, стаючи гібридом тип смарт-контракту. Якщо ви зробите це таким чином, то ваше виконання гарантується через децентралізовану мережу, а ваші недетерміновані операції є операціями, які не можуть бути виконані в блокчейні, але можуть бути виконані через децентралізовану машину оракула. Мережа виконує та повертає результат. . Загалом це може значно покращити функціональність смарт-контрактів. Функцій, які він може виконувати, стане більше, ніж раніше, і його також дуже просто застосувати на стороні клієнта. Вам потрібно лише додати дві функції до свого контракту, і ви зможете безпосередньо використовувати децентралізовану мережу Oracle як частину свого розумного контракт.використовувати. Крім того, він дуже зручний для традиційних програмістів Web2, оскільки логіку виконання можна завершити за допомогою традиційних мов програмування. Загальний процес не змінився. Запит надсилається, потім надсилається до децентралізованої мережі Oracle, агрегується після виконання та, нарешті, записується назад у смарт-контракт користувача.
Вище я розповів про машину Oracle і деякі служби, які може надати децентралізована мережа на основі машини Oracle.