Как решить проблему Oracle MEV (OEV) с помощью рыночных механизмов?

Средний2/21/2024, 3:47:19 AM
Существование OEV привело к перераспределению стоимости между различными заинтересованными сторонами, и API3 утверждает, что использует механизм аукциона, чтобы сделать перераспределение OEV как можно более разумным (распределение через рыночные механизмы), и попытаться обеспечить более быстрое и недорогое обновление цен.

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

Что такое OEV (Oracle MEV)

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

Существование OEV привело к перераспределению стоимости между различными заинтересованными сторонами, и API3 утверждает, что использует механизм аукциона, чтобы сделать перераспределение OEV как можно более разумным (распределение через рыночные механизмы), и попытаться обеспечить более быстрое и недорогое обновление цен.

Обычно считается, что создание и извлечение OEV - это подмножество проблемы MEV. Здесь мы вкратце расскажем, как создается OEV. Основные причины кроются в следующих двух аспектах:

  1. Система DeFi использует оракулы, чтобы получить цены и выполнить ликвидацию и другие логические действия, основанные на ценах оракулов. А ликвидация активов часто указывает на наличие большой прибыли.

  2. В обновлении оракула есть проблема с мелкими деталями. Только при определенном отклонении между ценами "вне цепи" и "в цепи" данные "в цепи" будут обновлены, что будет представлено в виде транзакции.

Генерация OEV означает потерю стоимости для поставщиков ликвидности. Некоторые данные показывают, что, исходя из двух вышеперечисленных аспектов, существует три способа создания OEV:

Забегание вперед: Когда искатели OEV наблюдают, что в пуле транзакций появляется транзакция обновления цены oracle, они могут вставить свои собственные транзакции перед этой транзакцией, чтобы получить выгоду от обновления цены. Это самая традиционная торговля на опережение.

Арбитраж: Поскольку обновление цены оракула зависит от разницы между ценой на цепи и ценой вне цепи, это означает, что котировка оракула может не совпадать с котировками других систем, и в это время возникнет арбитражное пространство.

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

Прибыль, полученная с помощью методов опережения и арбитража, на самом деле является убытками поставщика ликвидности. Что касается выгод, получаемых от ликвидации, то, с одной стороны, она затрагивает интересы заемщика, поскольку он потеряет значительную часть средств в процессе ликвидации, а с другой стороны, из-за задержки в котировке, выданной оракулом, кредитор в итоге получает стоимость залога, которая может оказаться ниже ожидаемой. Поэтому, несмотря ни на что, изъятие OEV принесет убытки соответствующему протоколу Defi в части имущества, находящегося под опекой.

Процесс извлечения OEV, по сути, является передовым

Для извлечения OEV искатель будет отслеживать "инструкции обновления данных оракула" в пуле памяти, объединять инструкции транзакций обновления данных оракула с инструкциями транзакций, инициированных им через инфраструктуру MEV, и, наконец, выполнять их для получения прибыли.

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

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

Чтобы решить эту проблему, GMX, которая внесла большой объем стоимости OEV и является платформой для торговли деривативами на цепи, приняла простой и грубый метод: пусть несколько человек, назначенных самостоятельно, захватят стоимость OEV, а затем вернут стоимость OEV в максимально возможном объеме на платформу GMX.

В связи с этим GMX представил Rook и белый список. Проще говоря, обновление оракула GMX выполняется через Rook, а Rook выполняет операцию извлечения OEV, основываясь на текущих рыночных условиях, чтобы получить OEV на рынке. 80% этих OEV будут возвращены в протокол GMX.

Подводя итог, можно сказать, что GMX дает Рукам право обновлять оракул через белый список, извлекать OEV через Рук, чтобы избежать извлечения другими поисковиками, и в то же время возвращать 80% OEV в систему GMX. Эта процедура на самом деле немного проста и грубовата.

Механизм аукциона OEV, основанный на рыночных торгах

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

Проще говоря, протокол Airnode требует, чтобы поставщик услуг API использовал свой собственный закрытый ключ для подписи всех публикуемых данных. Пользователи могут в любой момент получить последние данные и их подпись от поставщика услуг протокола Airnode, а затем опубликовать их в оракуле на цепи, чтобы обновить данные.

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

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

API3 позволяет любому человеку активно обновлять данные, записанные в его оракульном контракте, посредством торгов, и представляет узел OEV Relay в качестве ядра всего процесса аукциона OEV. OEV Relay собирает данные в каждом узле сети оракулов и возвращает их искателю. Затем искатель использует его для обновления данных, записанных в оракуле API3, и использует возможность объединить транзакции MEV.

Существование OEV Relay дает следующие два преимущества:

  1. Предоставьте все данные искателям в едином виде и сократите количество искателей, взаимодействующих только с узлами оракула;

  2. Защитите один узел оракула в сети и предотвратите его от DoS-атак, проводимых искателями;

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

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

Мы видим, что одним из эффектов поддержки аукционов OEV является достижение высокочастотного обновления оракульных цен на цепочке. Если взять в качестве примера источник данных AAPL/USD, то перед проведением аукциона OEV, когда цены вне цепи и на цепи отклоняются на 1%, это большое отклонение заставит оракула активно обновлять цены на цепи.

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

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

Таким образом, стоимость обновления данных оракула передается тем, кто собирает значение OEV, а OEV-реле API3 может получать большие комиссии за участие в торгах от игроков OEV, а затем передавать эти комиссии обратно в протокол Defi, который собирает значение OEV.

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

Следует также отметить, что в целях страховки API3 автоматически выполняет операции обновления данных, когда разница между данными на цепи и вне цепи велика, при условии, что ни один из участников аукциона OEV активно не обновлял данные, записанные в контракте API3.

Краткая информация

Основываясь на протоколе Airnode и вдохновляясь Flashbot, API3 разработал решение для аукциона OEV, которое дает следующие преимущества:

Верните большую часть OEV протоколам, которые используют оракульные ценовые каналы, обеспечивая более точное обновление цен; протокольным платформам, которые используют оракульные ценовые каналы, не нужно платить большие деньги за более точное обновление данных. Эти расходы перекладываются на плечи тех, кто занял первые места в рейтинге OEV и участвует в аукционах.

По сравнению со специализированным решением GMX, решение API3 является более универсальным. Более того, пользователю оракула API3 нужно только указать адрес кошелька, и протокол API3 автоматически переведет доход OEV на этот кошелек, что делает перераспределение OEV более удобным.

Отказ от ответственности:

  1. Эта статья перепечатана с сайта[PANews], все авторские права принадлежат автору оригинала[Geek Web3]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
  2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
  3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.

Как решить проблему Oracle MEV (OEV) с помощью рыночных механизмов?

Средний2/21/2024, 3:47:19 AM
Существование OEV привело к перераспределению стоимости между различными заинтересованными сторонами, и API3 утверждает, что использует механизм аукциона, чтобы сделать перераспределение OEV как можно более разумным (распределение через рыночные механизмы), и попытаться обеспечить более быстрое и недорогое обновление цен.

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

Что такое OEV (Oracle MEV)

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

Существование OEV привело к перераспределению стоимости между различными заинтересованными сторонами, и API3 утверждает, что использует механизм аукциона, чтобы сделать перераспределение OEV как можно более разумным (распределение через рыночные механизмы), и попытаться обеспечить более быстрое и недорогое обновление цен.

Обычно считается, что создание и извлечение OEV - это подмножество проблемы MEV. Здесь мы вкратце расскажем, как создается OEV. Основные причины кроются в следующих двух аспектах:

  1. Система DeFi использует оракулы, чтобы получить цены и выполнить ликвидацию и другие логические действия, основанные на ценах оракулов. А ликвидация активов часто указывает на наличие большой прибыли.

  2. В обновлении оракула есть проблема с мелкими деталями. Только при определенном отклонении между ценами "вне цепи" и "в цепи" данные "в цепи" будут обновлены, что будет представлено в виде транзакции.

Генерация OEV означает потерю стоимости для поставщиков ликвидности. Некоторые данные показывают, что, исходя из двух вышеперечисленных аспектов, существует три способа создания OEV:

Забегание вперед: Когда искатели OEV наблюдают, что в пуле транзакций появляется транзакция обновления цены oracle, они могут вставить свои собственные транзакции перед этой транзакцией, чтобы получить выгоду от обновления цены. Это самая традиционная торговля на опережение.

Арбитраж: Поскольку обновление цены оракула зависит от разницы между ценой на цепи и ценой вне цепи, это означает, что котировка оракула может не совпадать с котировками других систем, и в это время возникнет арбитражное пространство.

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

Прибыль, полученная с помощью методов опережения и арбитража, на самом деле является убытками поставщика ликвидности. Что касается выгод, получаемых от ликвидации, то, с одной стороны, она затрагивает интересы заемщика, поскольку он потеряет значительную часть средств в процессе ликвидации, а с другой стороны, из-за задержки в котировке, выданной оракулом, кредитор в итоге получает стоимость залога, которая может оказаться ниже ожидаемой. Поэтому, несмотря ни на что, изъятие OEV принесет убытки соответствующему протоколу Defi в части имущества, находящегося под опекой.

Процесс извлечения OEV, по сути, является передовым

Для извлечения OEV искатель будет отслеживать "инструкции обновления данных оракула" в пуле памяти, объединять инструкции транзакций обновления данных оракула с инструкциями транзакций, инициированных им через инфраструктуру MEV, и, наконец, выполнять их для получения прибыли.

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

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

Чтобы решить эту проблему, GMX, которая внесла большой объем стоимости OEV и является платформой для торговли деривативами на цепи, приняла простой и грубый метод: пусть несколько человек, назначенных самостоятельно, захватят стоимость OEV, а затем вернут стоимость OEV в максимально возможном объеме на платформу GMX.

В связи с этим GMX представил Rook и белый список. Проще говоря, обновление оракула GMX выполняется через Rook, а Rook выполняет операцию извлечения OEV, основываясь на текущих рыночных условиях, чтобы получить OEV на рынке. 80% этих OEV будут возвращены в протокол GMX.

Подводя итог, можно сказать, что GMX дает Рукам право обновлять оракул через белый список, извлекать OEV через Рук, чтобы избежать извлечения другими поисковиками, и в то же время возвращать 80% OEV в систему GMX. Эта процедура на самом деле немного проста и грубовата.

Механизм аукциона OEV, основанный на рыночных торгах

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

Проще говоря, протокол Airnode требует, чтобы поставщик услуг API использовал свой собственный закрытый ключ для подписи всех публикуемых данных. Пользователи могут в любой момент получить последние данные и их подпись от поставщика услуг протокола Airnode, а затем опубликовать их в оракуле на цепи, чтобы обновить данные.

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

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

API3 позволяет любому человеку активно обновлять данные, записанные в его оракульном контракте, посредством торгов, и представляет узел OEV Relay в качестве ядра всего процесса аукциона OEV. OEV Relay собирает данные в каждом узле сети оракулов и возвращает их искателю. Затем искатель использует его для обновления данных, записанных в оракуле API3, и использует возможность объединить транзакции MEV.

Существование OEV Relay дает следующие два преимущества:

  1. Предоставьте все данные искателям в едином виде и сократите количество искателей, взаимодействующих только с узлами оракула;

  2. Защитите один узел оракула в сети и предотвратите его от DoS-атак, проводимых искателями;

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

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

Мы видим, что одним из эффектов поддержки аукционов OEV является достижение высокочастотного обновления оракульных цен на цепочке. Если взять в качестве примера источник данных AAPL/USD, то перед проведением аукциона OEV, когда цены вне цепи и на цепи отклоняются на 1%, это большое отклонение заставит оракула активно обновлять цены на цепи.

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

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

Таким образом, стоимость обновления данных оракула передается тем, кто собирает значение OEV, а OEV-реле API3 может получать большие комиссии за участие в торгах от игроков OEV, а затем передавать эти комиссии обратно в протокол Defi, который собирает значение OEV.

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

Следует также отметить, что в целях страховки API3 автоматически выполняет операции обновления данных, когда разница между данными на цепи и вне цепи велика, при условии, что ни один из участников аукциона OEV активно не обновлял данные, записанные в контракте API3.

Краткая информация

Основываясь на протоколе Airnode и вдохновляясь Flashbot, API3 разработал решение для аукциона OEV, которое дает следующие преимущества:

Верните большую часть OEV протоколам, которые используют оракульные ценовые каналы, обеспечивая более точное обновление цен; протокольным платформам, которые используют оракульные ценовые каналы, не нужно платить большие деньги за более точное обновление данных. Эти расходы перекладываются на плечи тех, кто занял первые места в рейтинге OEV и участвует в аукционах.

По сравнению со специализированным решением GMX, решение API3 является более универсальным. Более того, пользователю оракула API3 нужно только указать адрес кошелька, и протокол API3 автоматически переведет доход OEV на этот кошелек, что делает перераспределение OEV более удобным.

Отказ от ответственности:

  1. Эта статья перепечатана с сайта[PANews], все авторские права принадлежат автору оригинала[Geek Web3]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
  2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
  3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.
Начните торговать сейчас
Зарегистрируйтесь сейчас и получите ваучер на
$100
!