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

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

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

Де ж корінь проблеми? В основі — блокчейн не може безпосередньо підключатися до даних реального світу. Вам потрібен "міст" — тобто оракула — щоб переносити ціни, погоду, валютні курси та іншу інформацію з поза ланцюга на ланцюг. Проблема в тому, що це місто дуже легко зруйнувати:

дані можуть бути затримані або підроблені

екстрене цінове коливання може миттєво спричинити шторм ліквідацій

централізовані вузли можуть зловживати своїм становищем або один злом може спричинити відмову всієї системи

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

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

Чи зможе цей підхід повністю вирішити проблему орікав? Це ще потрібно перевірити на практиці. Але він щонайменше вказує напрямок: замість пасивного прийняття ризиків краще активно проектувати більш стійку архітектуру даних.