المؤلف: بافيل بارامونوف المصدر: X، @paramonoww الترجمة: شان أوبا، Golden Finance
كثير من الناس أعتقد أن "ASS هو كل ما تحتاجه" وأعتقد أنه حل كامل يتطلب القليل من التحسين. ومع ذلك، فإن ASS لا يحل جميع المشكلات، كما أنه يضع بعض افتراضات الثقة.
1. تطبيق dApp للتسلسل الذاتي هو أداة إنشاء كتل جزئية
عندما تدخل حزمة المعاملات إلى كتلة، يحق للتطبيق اللامركزي سحب MEV الخاص به (الحد الأقصى للقيمة القابلة للاستخراج) من "الأعضاء" الآخرين في سلسلة توريد MEV مثل مقدمي العروض والباحثين والبنائين. احصل على القيمة الخاصة بك. ومع ذلك، فإن هذا المفهوم ليس مثاليًا (لا يوجد شيء مثالي في عالم العملات المشفرة) وقد يكون له أيضًا بعض افتراضات الثقة.
p> p>
2. الألعاب الشاملة
واجهات التطبيقات اللامركزية ذات التسلسل الذاتي التحدي هو: كلما ارتفعت قيمة الحزمة، زادت الحاجة إلى ضمان التضمين في الكتلة. إذا لم يتم تضمين المعاملات التي تلتقط MEV في الكتلة، فقد تصبح غير مربحة تمامًا، مما لا يضر المعاملات الأخرى التي لا يمكنها إنشاء MEV فحسب، بل يضر أيضًا بالمستخدمين.
هذا سيناريو تفكير مثير للاهتمام:
dApp لديه القدرة على التقاط جميع MEVs الناتجة عنه
ولكن إذا لم تكن فرصة MEVs هي الوحيدة قد تفقد أيضًا المستخدمين الذين يضيفون قيمة إلى النظام الأساسي (على سبيل المثال، إذا استمرت AMM في الفشل، فمن سيستخدمها)، لذلك لا فائدة من القيام بذلك.
الشيء الأكثر إثارة للاهتمام هو أن مقدم العرض يحتاج أيضًا إلى تحقيق الربح، مما يخلق موقفًا خاسرًا:
p>
يفقد التطبيق اللامركزي المتسلسل ذاتيًا MEV نظرًا لعدم تضمين الحزمة في الكتلة
li >يفقد مقدمو العروض MEV بسبب عدم قدرتهم على تفريغ وإعادة ترتيب الحزم الذرية (على الرغم من أنه يمكنهم اختيار معاملات أخرى)
ul>3.يجب ألا يضر تطبيق ASS dApp بالمستخدمين العاديين ومزودي السيولة (LPs) عن طريق استخراج MEV
كما نعلم جميعًا، يتم إنشاء MEV في الغالب واستخراجه من خلال حركة المرور السامة. تفقد الشركات المحدودة معظم المكاسب الناتجة عن التدفقات غير المدروسة بسبب MEV. يعد جذب السيولة إلى المنصة أحد أصعب الأشياء في مجال العملات المشفرة، ويجب أن تركز AMMs على التوزيع العادل لـ MEV على LPs، مما قد يساعد في تقليل الخسائر غير الدائمة.
في الواقع الحالي، يمكن اعتبار الإدارة النشطة لمنصب LP (أو حتى مناصب LP متعددة) وظيفة بدوام كامل. إذا كان الهجوم عبارة عن هجوم ساندويتش، فسيتم إرجاع القيمة إلى المتداول؛ وإذا كان عبارة عن مراجحة بين بورصة مركزية وبورصة لامركزية، فسيتم إرجاع القيمة إلى مزودي السيولة. السؤال إذن هو ما مقدار العائد الذي يجب أن يحصلوا عليه، وما هي القيمة التي يجب أن يحتفظ بها التطبيق اللامركزي؟
4. ماذا لو كان حجم الحزمة يتعارض مع حجم الكتلة للسلسلة الأساسية؟
على ما يبدو، لن تكون جميع التطبيقات اللامركزية تسلسلية ذاتيًا (على الأقل في المستقبل القريب). أحجام الكتل (أو مجموعات المعاملات) محدودة بلا حدود، ولن يكون هناك blockchain أو "blockchain". بافتراض أن الكتلة يمكن أن تستوعب ما يصل إلى 100 معاملة، فقد تحدث المواقف التالية:
The يرسل dApp حزمة من 100 معاملة، مما يملأ الكتلة بأكملها. ما مدى ربحية "الأعضاء" الآخرين في سلسلة التوريد MEV من إدراجها واقتراح الكتل وتنفيذها؟
أرسل التطبيق اللامركزي حزمة من 99 معاملة مع بقاء مكان واحد. هل لدى مقدم العرض الحافز الكافي لتضمين هذه الحزمة؟ (ما لم يقموا بنوع من التعاون، مثل التأكيد المسبق)
أرسل اثنان من التطبيقات اللامركزية الحزمة. تحتوي الحزمة الأولى على 60 معاملة والثانية تحتوي على 50 معاملة. من الواضح أنه يمكن تضمين حزمة واحدة فقط.
النقطة المهمة هي أن الحزمة الأولى تنتج MEV أكثر من الثانية، ولكن من منظور آخر، بما في ذلك الحزمة الثانية أكثر فائدة لأن 50 معاملة من تطبيقات dApps غير ذاتية التسلسل بالإضافة إلى الحزمة تخلق قيمة أكبر للكتلة.
إذن من الذي يجب تضمينه؟ من هو الأكثر ربحية في الكتلة، وليس فقط داخل الحزمة؟
الحل الذي يمكن تنفيذه هو FCFS (من يأتي أولاً يخدم أولاً)، لكنه لا يضمن الدقة لأن زمن الاستجابة لا يزال موجودًا.
كيف يمكن التأكد من أن التسلسل يفيد الجميع، بدلاً من استفادة مشارك واحد فقط وحرمان المشاركين الآخرين (LPs والمستخدمين) من القيمة؟
الحل المحتمل هو تعيين قواعد تسلسل محددة، وسيكون للقواعد التي يتم اتباعها فقط الحق في فرز الحزمة. وهذا أمر مهم لأن التسلسل غير الصحيح يمكن أن يؤدي إلى ثغرات أمنية.
بالنسبة لأزواج تداول AMM، فإن استخدام القواعد الجشعة التي يمكن التحقق منها يمكن أن يمنع المعاملات من التعرض للضغط في مجمع AMM محدد. ومع ذلك، فإن معظم معاملات DEX هي معاملات متعددة التبادل، لذلك هناك حاجة إلى وسائل أخرى لتوفير ضمانات مقاومة MEV.
لا تزال الأيام الأولى!
هناك العديد من الطرق لإجراء التسلسل الذاتي، وقد ألهمني نهج @SorellaLabs في هذا الموضوع. ما زلنا في الأيام الأولى من تنفيذ التسلسل الذاتي (أو ASS، كما يطلق عليه @ballsyalchemist)، وهناك مقايضات مختلفة للبنى التحتية المختلفة.
p> p>
الهدف من ASS هو جعل dApp مسؤولاً عن تسلسله وعدم الاهتمام بالتنفيذ (الذي يتم التعامل معه بواسطة السلسلة). في حين أن ASS على L1 واضح نسبيًا، إلا أنه أكثر جاذبية على L2 نظرًا لوجود مُسلسل واحد فقط للتعامل معه، ويقدم L2 الكثير إلى الطاولة من خلال فرض قواعد التسلسل المحلية.
هناك مجال كبير للنمو! (باستثناء مساحة الكتلة)