Уявіть собі, що смарт-контракти — це як цілодобові трейдери, їхні рішення повністю залежать від зовнішніх даних — цінової інформації, ринкових умов, результатів розрахунків. Але що станеться, якщо цей канал передачі даних іноді працює погано, іноді надсилає неправильну ціну, а іноді затримується на півдня? Наслідки будуть серйозними: DeFi-додатки зроблять помилкові транзакції, динамічні NFT-атрибути застрягнуть, процес страхових виплат зупиниться. Це і є найглибша прихована проблема сучасного блокчейн-світу: **надійність і реальність даних значно відстають від амбіцій застосунків на ланцюгу**.



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

APRO намагається радикально перебудувати цю систему. Основна ідея — створити "розподілений центр обробки даних". Як саме?

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

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

**AI для моніторингу в реальному часі**: моделі машинного навчання постійно працюють, щоб виявляти і ізолювати аномальні дані або забруднену інформацію, подібно до лікаря, що контролює якість крові.

Але таке рішення має і свої виклики: **різні сценарії вимагають різних типів даних**. Деякі застосунки потребують миттєвої реакції, інші — чутливі до вартості.

Відповідь APRO — пропонувати два канали:

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

**Pull-модель** (оплата за запит): додатки запитують дані лише тоді, коли вони дійсно потрібні, і в неробочий час не виникає витрат. Страхові виплати, оцінка активів — ідеально підходять для такого підходу.

Проще кажучи, розробники можуть гнучко керувати цим, як регулювати кран води, обираючи відповідний спосіб подачі даних залежно від бізнес-вимог. Це не просто технічне оновлення, а кардинальне рішення проблеми "недостатнього кровопостачання" даних у ланцюгу.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 6
  • Репост
  • Поділіться
Прокоментувати
0/400
AirdropChaservip
· 9год тому
Цієї проблеми з оракулом давно вже потрібно було вирішити, одна точкова відмова справді може знищити всю екосистему, це не перебільшення. Множинна джерельна резервність — ця ідея не нова, але справді реалізовуваних мало, і в方案 APRO є щось цікаве. Двонапрямна система push-pull дійсно гнучка, але не відомо, наскільки зможе знизити витрати, адже ті, хто обіцяють низькі ціни, в кінцевому підсумку не пропонують особливо дешевих варіантів.
Переглянути оригіналвідповісти на0
StakeWhisperervip
· 9год тому
Це справді складна частина — орієнтація на один пункт провалу дуже страшна... Мультиджерельне збирання звучить надійно, але боюся, що на практиці все може бути інакше
Переглянути оригіналвідповісти на0
WalletDivorcervip
· 9год тому
Проблема оракулів дійсно є великою головоломкою, але ця двонапрямна схема звучить трохи надто ідеалізовано... Збір даних з кількох джерел звучить непогано, але боязко, хто буде обслуговувати цю купу вузлів на рівні вузла, і хто нестиме витрати.
Переглянути оригіналвідповісти на0
GateUser-beba108dvip
· 9год тому
Оракул дійсно є старою проблемою, одна точка відмови дійсно може спричинити проблеми.
Переглянути оригіналвідповісти на0
SchroedingersFrontrunvip
· 9год тому
Це справді складна проблема — один злом точки призведе до всього збоїв, але ідея з багатоканальним збором даних у APRO нарешті має сенс.
Переглянути оригіналвідповісти на0
TestnetNomadvip
· 9год тому
Ей, ця проблема з оракулом дійсно є складною, оскільки один єдиний джерело даних дуже легко зламати.
Переглянути оригіналвідповісти на0
  • Закріпити