ملاحظة: تم تجميع النص الأصلي من تغريدة تزيد عن 2000 كلمة على Twitter الرسمي لـ Geek web3 حول مشكلة OEV وحلها. نظرًا لأن هذا الموضوع مثير للاهتمام بشكل خاص، فقد قمنا بتجميعه في مقالة قصيرة كمرجع لك.

ما هو OEV (Oracle MEV)

ببساطة، عندما يراقب مشغل أوراكل التناقض بين بيانات الأسعار خارج السلسلة وبيانات الأسعار الموجودة على السلسلة، يمكن للمشغل بدء معاملة وتحديث السعر الذي تدركه أوراكل على السلسلة. عند حدوث معاملة يمكنها تعديل سعر Oracle، فهذا يعني غالبًا إنشاء MEV. نحن نسمي هذا MEV الذي يعتمد على Oracle OEV (قيمة Oracle القابلة للاستخراج).

وقد أدى وجود OEV إلى إعادة توزيع القيمة بين مختلف أصحاب المصلحة، وتدعي API3 استخدام آلية المزاد لجعل إعادة توزيع OEV معقولة قدر الإمكان (المخصصة من خلال آليات السوق)، ومحاولة تقديم تحديثات أسعار أسرع وأقل تكلفة.

من المعتقد بشكل عام أن توليد واستخراج OEV هو مجموعة فرعية من مشكلة MEV. هنا نقدم بإيجاز كيفية إنشاء OEV. وتكمن الأسباب الأساسية في الناحيتين التاليتين:

1. يستخدم نظام DeFi أوراكل للحصول على الأسعار وتنفيذ التصفية والمنطق الآخر بناءً على أسعار أوراكل. وغالباً ما تشير تصفية الأصول إلى وجود هامش ربح كبير.

2. هناك مشكلة دقيقة في تحديث أوراكل. فقط عندما يكون هناك انحراف معين بين الأسعار خارج السلسلة والأسعار داخل السلسلة، سيتم تحديث البيانات الموجودة على السلسلة، والتي سيتم تقديمها في شكل معاملة.

إن توليد OEV يعني خسارة القيمة لمقدمي السيولة. تظهر بعض البيانات أنه بناءً على الجانبين المذكورين أعلاه، هناك ثلاث طرق لإنشاء OEV:

Frontrunning: عندما يراقب باحثو OEV ظهور معاملة تحديث سعر Oracle في تجمع المعاملات، يمكنهم إدراج معاملاتهم الخاصة قبل هذه المعاملة للحصول على المزايا التي يجلبها تحديث الأسعار. هذه هي التجارة الأكثر تقليدية في المقدمة.

المراجحة: نظرًا لأن تحديث السعر الموجود على السلسلة لجهاز أوراكل يعتمد على الفرق بين السعر الموجود على السلسلة والسعر خارج السلسلة، فإن هذا يعني أن عرض أسعار جهاز أوراكل قد لا يتوافق مع أسعار الأنظمة الأخرى، ومساحة المراجحة سوف تنشأ في هذا الوقت.

التصفية: سيؤدي تحديث سعر أوراكل إلى تصفية سلسلة من مراكز الإقراض، ويمكن للمصفي الحصول على مبلغ كبير من دخل التصفية أثناء عملية التصفية.

إن الأرباح التي يتم سحبها باستخدام أساليب المراجحة والمراجحة هي في الواقع خسائر لمزود السيولة. أما الفوائد التي يتم الحصول عليها من التصفية فهي تؤثر من ناحية على مصالح المقترض، لأن المقترض سيخسر جزءا كبيرا من أمواله أثناء عملية التصفية، ومن ناحية أخرى بسبب التأخير في التسعيرة يحصل المُقرض أخيرًا على قيمة الضمان التي قد تكون أقل من المتوقع. لذلك، بغض النظر عن الأمر، فإن سحب OEV سيؤدي إلى خسائر في بروتوكول Defi المقابل فيما يتعلق بممتلكات الحضانة.

تعتبر عملية استخراج OEV في المقدمة بشكل أساسي

لاستخراج OEV، سيقوم الباحث بمراقبة "تعليمات تحديث بيانات Oracle" في مجمع الذاكرة، ودمج تعليمات معاملة تحديث بيانات Oracle مع تعليمات المعاملة التي بدأتها من خلال البنية التحتية MEV، وأخيرًا تنفيذها للحصول على الأرباح.

بالطبع، بالنسبة لمعاملات المراجحة والمقاصة، يحتاج الباحثون فقط إلى مراقبة الانحراف بين السعر الموجود على السلسلة والسعر خارج السلسلة، وأخيرًا التأكد من تنفيذ المعاملات التي يبدؤونها على السلسلة أولاً من خلال البنية التحتية MEV.

بغض النظر عن العملية التي يستخدمها الباحثون، يمكننا أن نرى أن فوائد OEV يتم توزيعها بين البنية التحتية MEV والباحثين عن OEV، والبروتوكولات التي "تلتقط" قيمة OEV لا تحصل على الفوائد التي تستحقها. (وفقًا لبعض البيانات، تسببت مشكلة OEV سابقًا في سحب ما يقرب من 10٪ من أرباح منصة GMX)

من أجل حل هذه المشكلة، اعتمدت GMX، التي ساهمت بكمية كبيرة من قيمة OEV وهي عبارة عن منصة لتداول المشتقات على السلسلة، طريقة بسيطة وبسيطة: اسمح لبعض الأشخاص المعينين بأنفسهم بالحصول على قيمة OEV، ثم قم بإرجاع القيمة قيمة OEV قدر الإمكان لمنصة GMX.

في هذا الصدد، قدمت GMX الرخ والقائمة البيضاء. ببساطة، يتم تنفيذ تحديث Oracle الخاص بـ GMX من خلال Rook، وسيقوم Rook بإجراء عملية استخراج OEV استنادًا إلى ظروف السوق الحالية للحصول على OEV في السوق. سيتم إرجاع 80% من OEV هذه إلى بروتوكول GMX.

خلاصة القول، يمنح GMX Rooks الحق في تحديث Oracle من خلال القائمة البيضاء، واستخراج OEV من خلال Rook لتجنب استخراجها بواسطة باحثين آخرين، وفي نفس الوقت إرجاع 80٪ من OEV إلى نظام GMX. هذا الروتين هو في الواقع بسيط بعض الشيء وخام.

آلية مزاد OEV تعتمد على عطاءات السوق

قبل تقديم مخطط مزاد OEV الذي اقترحته API3 والذي تمت مناقشته بشكل كبير في الأيام الأخيرة، نقدم أولاً بإيجاز مبدأ تشغيل آلة أوراكل API3. يُطلق على جوهر API3 اسم بروتوكول Airnode. يسمح هذا البروتوكول لمقدمي خدمة API بحزم واجهات برمجة تطبيقات Web2 الخاصة بهم مباشرةً في Oracle Web3.

ببساطة، يتطلب بروتوكول Airnode من مزود خدمة API استخدام مفتاحه الخاص لتوقيع كل البيانات المنشورة. يمكن للمستخدمين الحصول على أحدث البيانات وتوقيعها من مزود خدمة بروتوكول Airnode في أي وقت، ثم نشرها على أوراكل على السلسلة لتحديث البيانات.

بالنسبة لمقدمي خدمات واجهة برمجة التطبيقات (API)، فإن تعبئة خدمات Web2 API الخاصة بهم في شكل أوراكل blockchain لا تتطلب سوى إضافة رابط توقيع مفتاح خاص. يمكن إعادة استخدام كمية كبيرة من البنية التحتية لموفر خدمة واجهة برمجة التطبيقات (API) مباشرةً، مما يقلل بشكل كبير من عتبة دخول شركات واجهة برمجة التطبيقات (API) إلى مجال أجهزة أوراكل.

استنادًا إلى بروتوكول Airnode، يستخدم API3 مخطط مزاد مشابه لبرنامج flashbot ولكنه يستهدف نظام أوراكل لتحقيق توزيع معقول لـ OEV، وفي الوقت نفسه يزيد من تكرار تحديث أوراكل على السلسلة. يوضح الشكل التالي مخطط OEV لـ API3:

يسمح API3 لأي شخص بتحديث البيانات المسجلة في عقد أوراكل الخاص به بشكل نشط من خلال تقديم العطاءات، ويقدم عقدة OEV Relay باعتبارها جوهر عملية مزاد OEV بالكامل. يقوم OEV Relay بجمع البيانات في كل عقدة شبكة أوراكل ويعيدها إلى الباحث. يستخدمه الباحث بعد ذلك لتحديث البيانات المسجلة على API3 oracle، ويغتنم الفرصة لتجميع معاملات MEV معًا.

إن وجود OEV Relay يجلب المزايا التالية:

1. توفير جميع البيانات للباحثين بطريقة موحدة وتقليل عدد الباحثين الذين يتفاعلون مع عقد أوراكل وحدها؛

2. حماية عقدة أوراكل واحدة في الشبكة ومنع عقدة أوراكل واحدة من التعرض للهجوم من خلال هجمات حجب الخدمة التي يقوم بها الباحثون؛

يمكن للباحثين الحصول على بيانات وتوقيعات شبكة أوراكل المجمعة ضمن OEV Relay. عندما يعتقد الباحثون أن عرض أسعار شبكة Oracle الحالي يمكن أن يساعدهم في إكمال بعض عمليات استخراج OEV، سيبدأ الباحثون عرضًا لـ OEV Relay.

أثناء عملية تقديم العطاءات، إذا قدم الباحث أعلى عرض، فسوف تقوم OEV Relay بإرجاع meta-tx الذي تم توقيعه ويمكن تحميله مباشرة إلى السلسلة لتحديث سعر جهاز أوراكل الموجود على السلسلة. يمكن للباحثين حزم معاملة تحديث السعر هذه مع المعاملات الأخرى في السلسلة وتنفيذها للحصول على دخل OEV. في هذا الوقت، نظرًا لأن معاملة تحديث السعر يتم تجميعها أيضًا على السلسلة، فسيتم أيضًا تحديث سعر أوراكل على السلسلة.

يمكننا أن نرى أن أحد تأثيرات دعم مزادات OEV هو تحقيق تحديثات عالية التردد لأسعار أوراكل على السلسلة. بأخذ مصدر بيانات AAPL/USD كمثال، قبل أن يكون هناك مزاد OEV، عندما تنحرف الأسعار خارج السلسلة وعلى السلسلة بنسبة 1٪، فإن هذا الانحراف الكبير سيؤدي إلى قيام أوراكل بتحديث الأسعار على السلسلة بشكل نشط.

ولكن إذا سمحت آلة أوراكل للعالم الخارجي بإرسال تعليمات تحديث البيانات إليها بعد فتح مزاد OEV، فقد يعتقد الباحثون أن فرق السعر بنسبة 0.1٪ بين الأسعار الموجودة على السلسلة وخارج السلسلة يمكن أن يحقق فوائد OEV ضخمة. سيؤدي هذا إلى دفع الباحثين إلى أخذ meta-tx لتحديث السعر عندما يكون فرق السعر 0.1%، وتحميل أمر المعاملة إلى السلسلة.

سيؤدي هذا إلى تسريع التحديثات لمصدر بيانات AAPL/USD دون تكبد تكاليف تحديث Oracle إضافية للتطبيقات التي تستخدم هذا Oracle.

لذلك، يتم تمرير تكلفة تحديث بيانات Oracle إلى ملتقطي قيمة 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، مما يوفر المزيد من تحديثات الأسعار الدقيقة؛ لا تحتاج منصات البروتوكول التي تستخدم موجزات أسعار أوراكل إلى دفع تكاليف عالية للحصول على المزيد من تحديثات البيانات الدقيقة. يتم تمرير هذه التكلفة إلى المتسابقين الأوائل في OEV الذين يقدمون عروضًا من خلال المزادات.

بالمقارنة مع حل GMX المتخصص، يعتبر حل API3 أكثر تنوعًا. علاوة على ذلك، يحتاج مستخدم API3 oracle فقط إلى توفير عنوان المحفظة، وسيقوم بروتوكول API3 تلقائيًا بنقل دخل OEV إلى هذه المحفظة، مما يجعل إعادة توزيع OEV أكثر ملاءمة.

تنصل:

1. تمت إعادة طباعة هذه المقالة من [PANews]، جميع حقوق النشر مملوكة للمؤلف الأصلي [Geek Web3]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.