Oracle MEV (OEV) Sorunu Piyasa Mekanizmaları Kullanılarak Nasıl Çözülür?

Not: Orijinal metin, Geek web3'ün resmi Twitter'ında OEV sorunu ve çözümü hakkında atılan 2.000 kelimeyi aşkın bir tweet'ten derlenmiştir. Bu konu özellikle ilgi çekici olduğundan, referansınız için kısa bir makalede derledik.

OEV (Oracle MEV) nedir

Basitçe ifade etmek gerekirse, kahin operatör zincir dışı ve zincir içi fiyat verileri arasında bir tutarsızlık gözlemlediğinde, operatör bir işlem başlatabilir ve zincir içi kahin tarafından algılanan fiyatı güncelleyebilir. Oracle fiyatını değiştirebilecek bir işlem gerçekleştiğinde, bu genellikle MEV'in üretilmesi anlamına gelir. Oracle'a bağlı olan bu MEV'ye OEV (oracle extractable value) diyoruz.

OEV'nin varlığı, farklı paydaşlar arasında değerin yeniden dağıtılmasına neden olmuştur ve API3, OEV'nin yeniden dağıtımını mümkün olduğunca makul hale getirmek (piyasa mekanizmaları aracılığıyla tahsis edilen) ve daha hızlı ve daha düşük maliyetli fiyat güncellemeleri getirmeye çalışmak için bir açık artırma mekanizması kullandığını iddia etmektedir.

Genel olarak OEV'nin üretilmesi ve çıkarılmasının MEV probleminin bir alt kümesi olduğuna inanılmaktadır. Burada OEV'nin nasıl oluşturulduğunu kısaca tanıtacağız. Bunun temel nedenleri aşağıdaki iki hususta yatmaktadır:

1. DeFi sistemi, fiyatları elde etmek ve oracle fiyatlarına dayalı olarak likidasyon ve diğer mantıkları yürütmek için oracle'lar kullanır. Ve varlık tasfiyesi genellikle büyük bir kar marjı olduğunu gösterir.

2. Kehanet güncellemesinde ince taneli bir sorun vardır. Yalnızca zincir dışı ve zincir içi fiyatlar arasında belirli bir sapma olduğunda, zincir içi veriler güncellenecek ve bu veriler bir işlem şeklinde sunulacaktır.

OEV'nin oluşması, likidite sağlayıcılar için değer kaybı anlamına gelmektedir. Bazı veriler, yukarıdaki iki hususa dayalı olarak, OEV'nin üretilmesi için üç yol olduğunu göstermektedir:

Frontrunning: OEV arama yapanlar, işlem havuzunda bir oracle fiyat güncelleme işleminin göründüğünü izlediklerinde, fiyat güncellemesinin getirdiği faydaları elde etmek için kendi işlemlerini bu işlemden önce ekleyebilirler. Bu, en geleneksel önden koşan ticarettir.

Arbitraj: Kehanet makinesinin zincir içi fiyat güncellemesi zincir içi fiyat ile zincir dışı fiyat arasındaki farka bağlı olduğundan, bu, kehanet makinesi fiyat teklifinin diğer sistemlerin fiyat teklifiyle tutarsız olabileceği ve bu sırada arbitraj alanının ortaya çıkacağı anlamına gelir.

Tasfiyeler: Kahinin fiyat güncellemesi bir dizi borç verme pozisyonunun tasfiyesini tetikleyecek ve tasfiye memuru tasfiye sürecinde büyük miktarda tasfiye geliri elde edebilecektir.

Frontrunning ve arbitraj yöntemleri ile çekilen karlar aslında likidite sağlayıcının zararıdır. Tasfiyeden elde edilen faydalara gelince, bir yandan borçlunun çıkarlarını etkiler, çünkü borçlu tasfiye sürecinde fonların önemli bir kısmını kaybedecektir ve diğer yandan, kahin tarafından verilen fiyat teklifindeki gecikme nedeniyle, borç veren nihayetinde beklenenden daha düşük olabilecek teminatın değerini alır. Bu nedenle, ne olursa olsun, OEV'nin geri çekilmesi, ilgili Defi protokolüne velayet mülkiyeti açısından kayıplar getirecektir.

OEV'in çıkarma işlemi esasen önden yürütülmektedir

OEV'nin çıkarılması için, arama yapan kişi bellek havuzundaki "oracle veri güncelleme talimatlarını" izleyecek, oracle veri güncelleme işlem talimatlarını MEV altyapısı aracılığıyla başlattıkları işlem talimatlarıyla bir araya getirecek ve son olarak kar elde etmek için bunları yürütecektir.

Elbette, arbitraj ve takas işlemleri için, arama yapanların yalnızca zincir içi fiyat ile zincir dışı fiyat arasındaki sapmayı izlemeleri ve son olarak başlattıkları işlemlerin MEV altyapısı aracılığıyla önce zincir üzerinde gerçekleştirilmesini sağlamaları gerekir.

Arama yapanlar tarafından kullanılan süreç ne olursa olsun, OEV'in faydalarının MEV altyapısı ile OEV'i arayanlar arasında dağıtıldığını ve OEV değerini "yakalayan" protokollerin hak ettikleri faydaları alamadıklarını görebiliriz. (Bazı verilere göre, OEV sorunu daha önce GMX platformunun kârının neredeyse %10'unun elinden alınmasına neden olmuştur)

Bu sorunu çözmek için, büyük miktarda OEV değerine katkıda bulunan ve zincir içi bir türev ticaret platformu olan GMX, basit ve kaba bir yöntem benimsemiştir: kendileri tarafından belirlenen bazı kişilerin OEV değerini yakalamasına izin verin ve ardından OEV değerini mümkün olduğunca GMX platformuna iade edin.

Bu bağlamda GMX, Rook ve beyaz listeyi tanıttı. Basitçe ifade etmek gerekirse, GMX'in kehanet güncellemesi Rook aracılığıyla yürütülür ve Rook, piyasadaki OEV'yi elde etmek için mevcut piyasa koşullarına dayalı bir OEV çıkarma işlemi gerçekleştirir. Bu OEV'lerin %80'i GMX protokolüne iade edilecektir.

Özetle GMX, Rook'lara beyaz liste aracılığıyla kahini güncelleme, diğer arama yapanlar tarafından çıkarılmaması için Rook aracılığıyla OEV çıkarma ve aynı zamanda OEV'nin %80'ini GMX sistemine iade etme hakkı verir. Bu rutin aslında biraz basit ve kabadır.

Piyasa teklifine dayalı OEV açık artırma mekanizması

API3 tarafından önerilen ve son günlerde çok tartışılan OEV açık artırma planını tanıtmadan önce, API3'ün kehanet makinesinin çalışma prensibini kısaca tanıtacağız. API3'ün çekirdeği Airnode protokolü olarak adlandırılır. Bu protokol, API hizmet sağlayıcılarının Web2 API'lerini doğrudan Web3 oracle'larına paketlemelerine olanak tanır.

Basitçe söylemek gerekirse, Airnode protokolü API hizmet sağlayıcısının yayınlanan her veriyi imzalamak için kendi özel anahtarını kullanmasını gerektirir. Kullanıcılar istedikleri zaman Airnode protokol hizmet sağlayıcısından en son verileri ve imzasını alabilir ve ardından verileri güncellemek için zincir üzerindeki oracle'da yayınlayabilir.

API hizmet sağlayıcıları için Web2 API hizmetlerini blok zinciri oracle'ları olarak paketlemek aslında sadece özel bir anahtar imza bağlantısı eklemeyi gerektirir. API hizmet sağlayıcısının altyapısının büyük bir kısmı doğrudan yeniden kullanılabilir, bu da API işletmelerinin oracle makineleri alanına girme eşiğini büyük ölçüde azaltır.

Airnode protokolüne dayanan API3, OEV'nin makul bir dağılımını elde etmek ve aynı zamanda zincirdeki oracle'ın güncelleme sıklığını daha da artırmak için flashbot'a benzer ancak oracle sistemini hedefleyen bir açık artırma şeması kullanır. Aşağıdaki şekil API3'ün OEV şemasını göstermektedir:

API3, herkesin oracle sözleşmesinde kayıtlı verileri teklif verme yoluyla aktif olarak güncellemesine olanak tanır ve OEV Relay düğümünü tüm OEV açık artırma sürecinin çekirdeği olarak tanıtır. OEV Relay her bir oracle ağ düğümünde veri toplar ve arama yapan kişiye geri gönderir. Arama yapan kişi daha sonra bunu API3 oracle'ında kayıtlı verileri güncellemek için kullanır ve MEV işlemlerini bir araya getirme fırsatını yakalar.

OEV Rölesinin varlığı aşağıdaki iki avantajı beraberinde getirmektedir:

1. Arama yapanlara tüm verileri birleşik bir şekilde sağlayın ve yalnızca oracle düğümleriyle etkileşime giren arama yapanların sayısını azaltın;

2. Ağdaki tek bir oracle düğümünü koruyun ve tek bir oracle düğümünün arama yapanlar tarafından gerçekleştirilen DoS saldırılarına maruz kalmasını önleyin;

Arama yapanlar, OEV Relay içinde toplu oracle ağı teklif verilerini ve imzalarını elde edebilirler. Arama yapanlar, mevcut kahin ağı teklifinin belirli OEV çıkarma işlemlerini tamamlamalarına yardımcı olabileceğine inandıklarında, arama yapanlar OEV Rölesine bir teklif başlatacaklardır.

Teklif verme işlemi sırasında, arama yapan kişi en yüksek teklifi verirse, OEV Relay imzalanmış bir meta-tx döndürecek ve zincirdeki oracle makinesinin fiyat güncellemesi için doğrudan zincire yüklenebilecektir. Arayıcılar bu fiyat güncelleme işlemini zincirdeki diğer işlemlerle birlikte paketleyebilir ve OEV geliri elde etmek için gerçekleştirebilir. Bu sırada, fiyat güncelleme işlemi de zincir üzerinde paketlendiğinden, zincir üzerindeki oracle'ın fiyatı da güncellenir.

OEV ihalelerini desteklemenin bir etkisinin de zincir içi oracle fiyatlarının yüksek frekanslı güncellemelerini sağlamak olduğunu görebiliriz. Örnek olarak AAPL/USD veri kaynağını ele alırsak, bir OEV açık artırması yapılmadan önce, zincir dışı ve zincir içi fiyatlar %1 oranında saptığında, bu büyük sapma kahinin zincir içi fiyatları aktif olarak güncellemesine neden olacaktır.

Ancak oracle makinesi, OEV ihalesi açıldıktan sonra dış dünyanın kendisine veri güncelleme talimatları göndermesine izin verirse, arama yapanlar zincir içi ve zincir dışı fiyatlar arasındaki %0,1'lik fiyat farkının büyük OEV avantajları getirebileceğini düşünebilir. Bu, arama yapan kişileri fiyat farkı %0,1 olduğunda fiyat güncellemesi için meta-tx almaya ve işlem sırasını zincire yüklemeye yönlendirecektir.

Bu, bu oracle'ı kullanan uygulamalar için ek oracle güncelleme maliyetlerine neden olmadan AAPL/USD veri kaynağındaki güncellemeleri hızlandıracaktır.

Bu nedenle, oracle veri güncelleme maliyeti OEV değeri yakalayanlara aktarılır ve API3'ün OEV Aktarıcısı OEV oyuncularından büyük teklif ücretleri alabilir ve daha sonra bu ücretleri OEV değerini yakalayan Defi protokolüne geri besleyebilir.

OEV pazarı genişledikçe, arama yapanların açık artırma fiyatı üzerinde kıyasıya rekabet edeceği ve OEV değerinin çoğunun (hatta %95'inin) API3 protokolüne aktarılmasına neden olacağı öngörülebilir. API3 protokolü OEV gelirinin bu kısmını aldıktan sonra, OEV değerinin kaynağını ayırt edecek ve OEV değerinin yakalandığı Defi protokolüne iade edecektir.

Ayrıca, hiçbir OEV müzayedecisinin API3 sözleşmesinde kayıtlı verileri aktif olarak güncellememiş olması koşuluyla, zincir içi veriler ile zincir dışı veriler arasındaki fark büyük olduğunda, sigorta amacıyla API3'ün otomatik olarak veri güncelleme işlemleri gerçekleştireceği de unutulmamalıdır.

Özet

Airnode protokolünü temel alan ve Flashbot'tan esinlenen API3, aşağıdaki avantajları sağlayan bir OEV açık artırma çözümü geliştirmiştir:

OEV'nin çoğunu, daha ayrıntılı fiyat güncellemeleri sağlayan oracle fiyat beslemelerini kullanan protokollere iade edin; oracle fiyat beslemelerini kullanan protokol platformlarının daha ayrıntılı veri güncellemeleri için yüksek maliyetler ödemesine gerek yoktur. Bu maliyet, ihaleler yoluyla teklif veren OEV öncülerine yansıtılır.

GMX'in özel çözümü ile karşılaştırıldığında, API3'ün çözümü daha çok yönlüdür. Dahası, API3 oracle kullanıcısının yalnızca bir cüzdan adresi vermesi yeterlidir ve API3 protokolü OEV gelirini otomatik olarak bu cüzdana aktararak OEV'nin yeniden dağıtımını daha kolay hale getirecektir.

Sorumluluk Reddi：

1. Bu makale[PANews] adresinden yeniden basılmıştır, Tüm telif hakları orijinal yazar[Geek Web3]'e aittir. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.