Чи є Flux кращим варіантом для довільних даних?
Чим Flux відрізняється від інших провідних оракулів
Порівняльний огляд структури оракулів блокчейна
Хоча блокчейни як і раніше не здатні сприймати навколишній світ, немає недоліків в інтерфейсах, які не тільки дозволяють їм бачити світ, а й реагують на результат конкретних подій на основі заздалегідь визначених умов. Ці інтерфейси, відомі як оракули, передають дані з зовнішніх джерел в блокчейн, різко поліпшуючи можливості і корисність технології за допомогою смарт-контрактів.
Без єдиного ланцюжка блоків або консенсусу, який би керував ними всіма, платформи оракулів були більш-менш різноманітні і різноманітні, як і галузь, яку вони обслуговують. У цій статті ми розглянемо відомі платформи Oracle і їх підходи на основі наступних критеріїв:
- Мережева модель: Без сумніву, оракули на основі блокчейнов схильні до тих же ризиків атаки Сібілли і зіткнень, властивим технології, на якій вони побудовані. Той факт, що для запуску і обслуговування більшості служб Oracle потрібні спеціальні знання, ще більше піддає постачальників служб Oracle ризиків централізації. Маючи це на увазі, вкрай важливо, щоб при проектуванні мережі і реалізації оракулів особлива увага приділялася надійності даних і децентралізації постачальників даних. Для цього деякі оракули агрегують результати декількох оракулів, які використовують одне і те ж джерело даних або подію, проте з великими потоками даних це може збільшити вартість для користувачів, а також привести до проблем з масштабністю.
- Безпека: через псевдоанонімність характеру більшості загальнодоступних блокчейнов користувачі, як правило, користуються високим ступенем анонімності в мережі. Якщо вони уникають централізованого обміну і об’єднання адрес і активів, стає майже неможливо розрізнити власність і ідентичність. Це часто призводить до того, що контрагенти виявляються на вістрі дуже складної ситуації, коли нікому притягати до відповідальності, якщо щось піде не так. Взаємодія між непоказним суб’єктом в мережі і невідомим джерелом даних поза мережею є благодатним грунтом для безлічі векторів атак з обох сторін.
- Джерело даних: з часом у кожної події завжди буде певний результат. Якщо результат або його виміряне уявлення збережені, будь-який оракул може отримати і передати його. Однак джерела даних часто являють собою мішанину з баз даних, датчиків, людських джерел, інших смарт-контрактів або усього іншого. Щоб отримати справжній результат, також відомий як наземна істина, оракули повинні вміти перевіряти правдивість, бути захищеними від несанкціонованого доступу, усувати людські помилки, одночасно фільтруючи шум від джерела.
- Механізм вирішення спорів: коли все сказано і зроблено, оракули хороші рівно настільки, наскільки хороший їх кінцевий результат. Отже, забезпечення правдивості цього кінцевого результату має вирішальне значення для надійності оракула і стійкості мережі. Впровадження системи вирішення спорів не тільки гарантує цілісність даних, але також може виключити вставку невірних даних. Це можна ще більше посилити за рахунок економічних стимулів, які спрощують вирішення спорів таким чином, що витрати на включення і захист поганих результатів стають непомірно високими, при цьому велика частина гонорарів, виплачуваних поганим суб’єктом (якщо не всі), йде тим, хто повідомив про невірні дані після вирішення спору.
- Доступність: через технічні вимоги участь в екосистемах більшості оракулів часто є передбачуваною перспективою для середнього користувача блокчейна. Хоча це гарантує, що учасники мережі можуть нести свою власну вагу і вносити свій вклад в підтримку працездатності мережі, у нього є сумний побічний ефект, що полягає в різкому стримуванні участі більшої частини зовнішньої екосистеми. Однак не кожен модуль вимагає технічної підтримки. Внесення інтерфейсів в білі списки для служб даних, вирішення спорів з урахуванням правильного результату, курирування реєстру і делегування повноважень відомим зацікавленим сторонам для забезпечення жвавості — ось деякі з функцій, які можуть зробити мережу більш інклюзивною для більш широкої спільноти.
Ланка ланцюга
Як першопроходець в цій області, Chainlink отримала вигоду від свого першопрохідника, щоб стати найбільш широко використовуваним оракулом, що призвело до безлічі партнерств і захопленої спільноти. Chainlink успішно усунув єдину точку відмови, яка переслідувала галузь, використовуючи сертифіковані джерела даних і агрегування результатів з декількох джерел.
Постачальники послуг запускають вузли в децентралізованій мережі для отримання і запиту даних. Оскільки мережа не є власним ланцюжком блоків, Chainlink може швидко розгортатися в різних ланцюжках блоків, не турбуючись про порушення консенсусу на рівні протоколу або призначення валідаторам завдань для забезпечення безпеки ланцюжка блоків. Однак, хоча мережа децентралізована, управління протоколом залишається централізованим, а агрегування даних з декількох джерел призвело до заяв про надмірності даних.
Band протокол
Перетворившись з токена в Ethereum в свій особистий блокчейн в екосистемі Tendermint, Band Protocol прагне позиціонувати себе як потужний оракул в центрі протоколу міжблочного зв’язку (IBC) Cosmos. IBC дозволяє блокчейнам, в яких реалізований протокол, взаємодіяти один з одним, поєднуючи раніше відключені середовища.
Помістивши себе в центр цього перетину через свій власний ланцюжок BandChain, Band об’єднує служби даних Oracle і їх доступність, усуваючи вартість і обслуговування декількох вузлів в різних ланцюжках. Однак це також покладає на валідаторів додаткову роботу по захисту блокчейна шляхом створення і перевірки блоків. Також очікується, що кожен вузол в мережі буде мати доступ до одних і тих же даних незалежно від мети через вбудовану в протокол випадковість. У міру зростання стану мережі збільшуються час, необхідний для синхронізації, і вимоги до обладнання.
API3
API3 використовує інший підхід до служб Oracle, використовуючи основне джерело даних в якості постачальника даних Oracle і надаючи їм інтерфейс для підключення до ланцюжків блоків і смарт-контрактів, замість того, щоб покладатися на вузли для отримання даних з джерела. Дозволяючи стороннім оракулам підключатися до потоків даних в ланцюжку, API3 спрямований на усунення ризику централізації, змови і маніпуляцій, пов’язаних з існуючою системою, покладаючись на реальну репутацію сторонніх оракулів для забезпечення правдивості.
Тримачі токенов API3 можуть розміщувати свої токени в мережі, однак замість того, щоб також служити в якості механізму зв’язування для вузлів, вони тільки дозволяють користувачам брати участь в операційному ризику протоколу, а також спонукають їх мінімізувати ризик і брати участь в управлінні протоколом.
Теллор
Tellor запустив нову модель Proof-of-Work (PoW) в якості токена ERC20 на Ethereum, де запити даних перетворюються в запит PoW, а запитані дані повертаються як медіана результату, отриманого п’ятьма найшвидшими для вирішення проблеми. За кожен запит даних призначається нагорода, яка дістається майнерам, що надають дані. Майнер також отримують винагороду в токенах TRB за вирішення завдання PoW. Це завдання стає все більш складним, оскільки все більше майнерів приєднуються до мережі і змагаються за виконання запитів на дані. Складність полягає в тому, щоб зробити мережу надзвичайно дорогою для атаки по мірі її розвитку.
Tellor, в основному вважається оракулом на основі Ethereum, тепер переходить на крос-ланцюгову екосистему з випуском версії 2.0, TellorX. TellorX змінює консенсус з PoW на PoS, успадкувавши більшість характерних особливостей поточних систем PoS, включаючи делегування голосів, скорочення і зв’язування активів.
Протокол потоку
Flux Protocol — це платформа Oracle, яка не залежить від блокчейнів. Валідатори повинні розміщувати облігації, щоб робити ставки на правильний результат запиту даних в мережі. Хоча результат з найбільшою кількістю облігацій визнаний правильним, будь-хто може заперечити цей результат, зробивши ставку на інший результат, запустивши гру на ескалацію, в якій вартість вимоги облігації для сумнівного результату відповідає геометричній послідовності для кожного наступного раунду. Як тільки спір вирішено, ті, хто зробив ставку на правильний результат, отримують винагороду у вигляді застави, пов’язаної з неправильним результатом.
Підхід протоколу до служб даних в більшій мірі відображає розвиток інтероперабельності в галузі. Замість того, щоб бути ще одним учасником все більш конкурентного простору Oracle, Flux Protocol дозволяє користувачам також підключати своє існуюче рішення Oracle до мережі. Таким чином, користувачі можуть використовувати протокол Flux в якості підтримки для довільних запитів даних.
Original text: https://www.fluxprotocol.org/blog/is-flux-the-best-bet-for-arbitrary-data
Join Flux Protocol:
