Порівняння Flux з іншими провідними оракулами
Порівняльний огляд рамкових принципів блокчейн -оракулів
Хоча блокчейни залишаються нездатними сприймати навколишній світ, не бракує інтерфейсів, які не тільки дозволяють їм бачити світ, але й реагувати на результат конкретних подій на основі заздалегідь визначених умов. Ці інтерфейси, відомі як оракули, передають дані із зовнішніх джерел у блокчейн, різко покращуючи можливості та корисні можливості технології за допомогою смарт -контрактів.
Не маючи жодного блокчейна або консенсусу, який би керував усіма ними, платформи Oracles були більш -менш такими різноманітними та різноманітними, як і галузь, яку вони обслуговують. У цій статті ми розглянемо відомі платформи Oracle та їх підходи на основі таких критеріїв:
- Модель мережі: Безперечно, оракули на основі блокчейну схильні до тієї самої атаки Sybil та ризику зіткнення, властивих технології, на якій вони побудовані. Той факт, що для запуску та підтримки більшості служб Oracle потрібні спеціальні знання, ще більше піддає постачальників послуг Oracle ризику централізації. З огляду на це, вкрай важливо, щоб мережевий дизайн та впровадження оракулів були зосереджені на надійності даних та децентралізації постачальників даних. Для цього деякі оракули узагальнюють результати кількох оракулів із використанням одного і того ж джерела даних або події, однак із великими потоками даних це може збільшити вартість для користувачів, а також спричинити проблеми з масштабуванням.
- Безпека: Через псевдоанонімну природу більшості публічних блокчейнів користувачі, як правило, користуються високим ступенем анонімності в мережі. Якщо вони уникають централізованих обмінів та найближчих адрес та активів, то практично неможливо розпізнати право власності та особу. Це часто залишає контрагентів у гострому кінці дуже липкої ситуації, і ніхто не буде нести відповідальність, якщо щось піде на південь. Взаємодія між невиразним актором ланцюга та невідомим джерелом даних поза ланцюгом є сприятливим ґрунтом для незліченної кількості векторів атаки з обох кінців.
- Джерело даних: З огляду на час, у кожної події завжди буде певний результат. Якщо результат або виміряне його представлення зберігається, будь -який оракул може отримати та передати його. Однак джерела даних часто є згустком баз даних, датчиків, людських джерел, інших розумних контрактів або суміші всього. Щоб отримати справжній результат, також відомий як основна істина, Оракули повинні мати можливість перевірити правдивість, бути захищеними від підробок, усунути людські помилки, одночасно відфільтровуючи шум від джерела.
- Механізм суперечок: Коли все сказано і зроблено, оракули настільки ж хороші, як і якість їх кінцевого результату. Тому захист правдивості цього кінцевого результату має вирішальне значення для надійності оракула та надійності мережі. Впровадження системи спорів не тільки гарантує цілісність даних, але також може усунути вставку поганих даних. Це можна додатково посилити за рахунок економічних стимулів, які дозволяють вирішити суперечки таким чином, що витрати на включення та захист поганих результатів стають непомірно дорогими, більшість гонорарів, які сплачує поганий актор (якщо не всі), покладаються на тих, хто повідомив про погані дані після вирішення суперечки.
- Доступність: Через свої технічні вимоги участь у екосистемах більшості оракулів часто є жахливою перспективою для пересічного користувача блокчейну. Хоча це гарантує, що учасники мережі зможуть нести свою власну вагу та сприяти збереженню активності мережі, це має жалюгідний побічний ефект, який різко стримує більшість зовнішньої екосистеми від участі. Однак не кожен модуль вимагає технічного введення. Додавання в білий список інтерфейсів для служб даних, вирішення спорів шляхом ставлення до правильного результату, курації реєстру та делегування відомим зацікавленим сторонам для забезпечення жвавості — це деякі функції, які можуть зробити мережу більш інклюзивною для широкої спільноти.
Ланка ланцюга
Будучи першим рушієм у космосі, Chainlink скористався своєю перевагою як піонер, щоб стати найбільш широко використовуваним оракулом, що призвело до безлічі партнерств та захопленої спільноти. Компанія Chainlink успішно усунула єдину точку збою, яка переслідувала галузь, використовуючи перевірені джерела даних та узагальнюючи результати з різних джерел.
Постачальники послуг запускають вузли в децентралізованій мережі для отримання та запиту даних. Оскільки мережа не є її власною рідною блокчейн, Chainlink може швидко розгортатись у різних блокчейнах, не турбуючись про порушення консенсусу на рівні протоколу або завдання валідаторів, а також забезпечити безпеку блокчейна. Однак, хоча мережа децентралізована, управління протоколом залишається централізованим, а його сукупність даних з різних джерел призвела до претензій щодо надмірності даних.
Смуговий протокол
Переходячи від маркера Ethereum до власного власного блокчейну в екосистемі Tendermint, Band Protocol прагне позиціонувати себе як надпотужний оракул у центрі протокольного центру взаємодії міжблочних ланцюгів (IBC) Космосу. IBC дозволяє блокчейнам, які реалізували протокол, спілкуватися між собою, подолавши раніше відключені середовища.
Розміщуючи себе в центрі цього перетину через власний ланцюг, BandChain, Band об’єднує послуги передачі даних Oracle та їх доступність, усуваючи витрати та обслуговування кількох вузлів у різних ланцюгах. Однак це також обтяжує валідаторів додатковою роботою щодо захисту блокчейна шляхом створення та перевірки блоків. Очікується, що кожен вузол у мережі матиме доступ до одних і тих же даних незалежно від мети через вбудовану протоколом випадковість. Зі зростанням стану мережі збільшується час, необхідний для синхронізації та апаратне забезпечення.
API3
API3 використовує інший підхід до служб oracle, маючи основне джерело даних як постачальника даних oracle і надаючи їм інтерфейс для підключення до блокчейнів та смарт -контрактів, а не покладаючись на вузли для отримання даних з джерела. Дозволяючи першочерговим оракулам підключатися до послідовних каналів даних, API3 спрямований на усунення ризиків централізації, змови та маніпуляцій, пов’язаних з існуючою системою, спираючись на репутацію реальних світових оракулів для забезпечення правдивості.
Власники токенів API3 можуть ставити свій маркер у мережу, однак замість того, щоб служити механізмом зв’язку для вузлів, він лише дозволяє користувачам брати участь у операційному ризику протоколу, а також стимулює їх мінімізувати ризик та брати участь в управлінні протокол.
Теллор
Теллор запустив нову модель Proof-of-Work (PoW) як маркер ERC20 на Ethereum, де запити даних перетворюються на виклик PoW, а запитувані дані повертаються як медіана результату, отриманого п’ятьма найшвидшими для вирішення проблеми. Кожен запит на дані має нагороду, яка надходить шахтарям, які надають дані. Майнери також отримують винагороду в жетонах TRB за вирішення проблеми PoW. Ця проблема стає все складнішою, оскільки все більше майнерів приєднуються до мережі та змагаються за виконання запитів даних. Складність покликана зробити мережу надзвичайно дорогою для атаки в міру її дозрівання.
Теллор, який переважно вважається оракулом на базі Ефіріума, тепер виходить на межі ланцюгової екосистеми через свій випуск v2.0, TellorX. TellorX змінює консенсус з PoW на PoS, успадковуючи більшість основних особливостей поточних систем PoS, включаючи делегування голосів, скорочення та скріплення активів.
Протокол потоку
Flux Protocol — це агностична платформа Oracle з блокчейном. Валідатори повинні виставляти облігації, щоб зробити ставку на правильний результат запиту даних у мережі. Хоча результат з найбільшою кількістю облігацій визнається правильним результатом, кожен може оскаржити цей результат, зробивши ставку на інший результат, викликаючи гру ескалації, де вартість вимоги до облігацій для оскарження результату слідує геометричній послідовності для кожного наступного раунду. Як тільки суперечка буде вирішена, ті, хто зробив ставку на правильний результат, отримують винагороду від облігації, виставленої неправильним результатом.
Підхід протоколу до обслуговування даних більше відображає взаємосумісну еволюцію галузі. Замість того, щоб бути ще одним учасником все більш конкурентоспроможного простору Oracle, протокол Flux дозволяє користувачам також підключати до мережі своє існуюче рішення Oracle. Таким чином, користувачі можуть використовувати протокол Flux як захист для довільних запитів даних.
Website: https://www.fluxprotocol.org/
Telegram: https://t.me/fluxprotocol
Twitter: https://twitter.com/fluxprotocol
Discord: https://discord.gg/4aWk2Zf7
