Як вирішити проблему Oracle MEV (OEV) за допомогою ринкових механізмів?

Примітка: Оригінальний текст складено з твіту обсягом понад 2 000 слів в офіційному Твіттері Geek web3 про проблему OEV та її вирішення. Оскільки ця тема є особливо інтригуючою, ми зібрали її в коротку статтю для ознайомлення.

Що таке OEV (Oracle MEV)

Простіше кажучи, коли оператор оракула відстежує розбіжність між даними про ціну в мережі та поза мережею, він може ініціювати транзакцію і оновити ціну, яку сприймає мережевий оракул. Коли відбувається транзакція, яка може змінити ціну оракула, це часто означає генерацію MEV. Ми називаємо це MEV, яке залежить від оракула OEV (oracle extractable value).

Існування ОЕВ призвело до перерозподілу вартості між різними зацікавленими сторонами, і API3 стверджує, що використовує механізм аукціону, щоб зробити перерозподіл ОЕВ якомога більш обґрунтованим (розподіленим через ринкові механізми), і намагається зробити оновлення цін швидшим і дешевшим.

Зазвичай вважається, що генерування та вилучення ОЕВ є підмножиною проблеми MEV. Тут ми коротко пояснимо, як генерується OEV. Основні причини полягають у наступних двох аспектах:

1. Система DeFi використовує оракули для отримання цін і виконання ліквідації та іншої логіки на основі цін оракула. А ліквідація активів часто свідчить про наявність великої маржі прибутку.

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

Генерування OEV означає втрату вартості для постачальників ліквідності. Деякі дані показують, що, виходячи з двох вищезгаданих аспектів, існує три способи генерування ОЕВ:

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

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

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

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

Процес вилучення ОЕВ по суті є передовим

Для вилучення OEV пошуковик відстежує "інструкції з оновлення даних оракула" в пулі пам'яті, об'єднує інструкції з оновлення даних оракула з інструкціями транзакцій, ініційованими ним через інфраструктуру MEV, і, нарешті, виконує їх для отримання прибутку.

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

Незалежно від процесу, який використовують пошукачі, ми бачимо, що вигоди від ОЕВ розподіляються між інфраструктурою MEV і пошукачами ОЕВ, а протоколи, які "фіксують" цінність ОЕВ, не отримують тих вигод, на які вони заслуговують. (За деякими даними, проблема OEV раніше призвела до вилучення майже 10% прибутку платформи GMX)

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

У зв'язку з цим GMX ввів Rook і білий список. Простіше кажучи, оновлення оракула GMX виконується через Rook, а Rook виконує операцію вилучення OEV на основі поточних ринкових умов, щоб отримати OEV на ринку. 80% цих OEV будуть повернуті до протоколу GMX.

Підсумовуючи, GMX надає Rooks право оновлювати оракул через білий список, видобувати OEV через Rook, щоб уникнути видобутку іншими пошукачами, і в той же час повертати 80% OEV в систему GMX. Ця рутина насправді трохи проста і груба.

Механізм аукціону ОЕВ на основі ринкових торгів

Перш ніж представити схему аукціону OEV, запропоновану API3, яка активно обговорювалася останніми днями, ми спочатку коротко представимо принцип роботи оракула API3. Ядро API3 називається протоколом Airnode. Цей протокол дозволяє постачальникам послуг API безпосередньо пакувати свої Web2 API в оракули Web3.

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

Для постачальників послуг API пакування їхніх сервісів Web2 API як оракулів блокчейну фактично вимагає лише додавання посилання на підпис приватного ключа. Значна частина інфраструктури постачальника послуг API може бути використана безпосередньо повторно, що значно знижує поріг входження API-бізнесу в сферу оракул-машин.

Заснований на протоколі Airnode, API3 використовує схему аукціону, схожу на flashbot, але орієнтовану на систему оракулів, щоб досягти розумного розподілу OEV, і в той же час ще більше збільшити частоту оновлення оракула в ланцюжку. На наступному малюнку показано схему OEV для API3:

API3 дозволяє будь-кому активно оновлювати дані, записані в їхньому oracle-контракті, шляхом участі в торгах, і представляє вузол OEV Relay як ядро всього процесу аукціону OEV. OEV Relay збирає дані в кожному вузлі мережі oracle і повертає їх шукачеві. Потім пошуковик використовує його для оновлення даних, записаних в оракулі API3, і користується можливістю об'єднати транзакції MEV разом.

Існування OEV Relay дає наступні дві переваги:

1. Надайте всі дані пошукачам в уніфікованому вигляді та зменшіть кількість пошукачів, які взаємодіють лише з вузлами оракула;

2. Захистіть єдиний вузол оракула в мережі та запобігайте DoS-атакам з боку пошукових систем на єдиний вузол оракула;

Пошуковці можуть отримати агреговані дані котирувань мережі oracle та підписи в рамках OEV Relay. Коли пошукачі вважають, що поточне котирування мережі oracle може допомогти їм виконати певні операції з вилучення OEV, вони ініціюють заявку на OEV Relay.

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

Ми бачимо, що одним з наслідків підтримки аукціонів OEV є досягнення високочастотного оновлення цін на оракули в мережі. Якщо взяти за приклад джерело даних AAPL/USD, то перед аукціоном OEV, коли позабіржові та біржові ціни відхиляються на 1%, таке велике відхилення змусить оракул активно оновлювати біржові ціни.

Але якщо машина-оракул дозволяє зовнішньому світу надсилати їй інструкції з оновлення даних після відкриття аукціону OEV, пошукачі можуть подумати, що різниця в 0,1% між цінами в мережі та поза мережею може принести величезні переваги OEV. Це змусить пошукачів брати мета-тег для оновлення ціни, коли різниця в ціні становить 0,1%, і завантажувати замовлення на транзакцію в ланцюжок.

Це прискорить оновлення джерела даних AAPL/USD без додаткових витрат на оновлення оракула для додатків, що використовують цей оракул.

Таким чином, вартість оновлення даних оракула перекладається на захоплювачів вартості OEV, а OEV Relay в API3 може отримувати великі комісії за торги від гравців OEV, а потім передавати ці комісії назад до протоколу Defi, який фіксує вартість OEV.

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

Слід також зазначити, що з метою страхування API3 автоматично виконуватиме операції з оновлення даних, коли різниця між даними в ланцюжку та поза ланцюжком буде великою, за умови, що жоден учасник аукціону OEV активно не оновлював дані, зафіксовані в контракті API3.

Зведення

На основі протоколу Airnode і натхненна Flashbot, API3 розробила рішення для аукціону OEV, яке має наступні переваги:

Повернути більшу частину OEV до протоколів, які використовують цінові стрічки Oracle, забезпечуючи більш детальне оновлення цін; платформи протоколів, які використовують цінові стрічки Oracle, не повинні платити високі витрати за більш детальне оновлення даних. Ці витрати перекладаються на лідерів ОЕВ, які беруть участь в аукціонах.

У порівнянні зі спеціалізованим рішенням GMX, рішення API3 є більш універсальним. Більш того, користувачеві оракула API3 потрібно лише вказати адресу гаманця, і протокол API3 автоматично переведе дохід OEV на цей гаманець, роблячи перерозподіл OEV більш зручним.

Відмова від відповідальності:.

1. Ця стаття передрукована з[PANews], всі авторські права належать оригінальному автору[Geek Web3]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.