كيفية حل مشكلة أوراكل MEV (OEV) من خلال آليات السوق؟

المؤلف: Shew, Geek web3

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

ما هو OEV (Oracle MEV)

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

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

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

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

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

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

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

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

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

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

عملية استخراج OEV: لا يزال الجوهر في المقدمة

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

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

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

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

< / p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

من المتوقع أنه مع توسع سوق OEV، سيتنافس الباحثون بشدة على أسعار المزادات، مما يؤدي إلى تحويل معظم قيمة OEV (حتى 95%) إلى بروتوكول API3، وAPI3 بعد ذلك يتلقى البروتوكول هذا الجزء من دخل OEV، وسيقوم بتمييز مصدر قيمة OEV وإعادته إلى بروتوكول Defi الذي حصل على قيمة OEV.

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

الملخص

استنادًا إلى بروتوكول Airnode والإلهام من Flashbot، طورت API3 مخطط مزاد OEV، والذي يوفر المزايا التالية:

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

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