Introduction

في هذا المنشور ، نقدم ضرائب MEV ، وهي آلية يمكن للتطبيقات التعسفية استخدامها لالتقاط MEV الخاصة بها.

يمكن استخدام هذه الآلية اليوم على OP Stack L2s مثل OP الشبكة الرئيسية و Base و Blast، لأن مقترحي الكتلة على تلك السلاسل يتبعون مجموعة من القواعد التي نسميها ترتيب الأولوية التنافسية.

لتطبيق ضريبة MEV على إحدى هذه السلاسل ، يفرض العقد الذكي رسوما دالة على رسوم الأولوية للمعاملة. نظهر أنه إذا فرض التطبيق على الباحثين ضريبة MEV قدرها (على سبيل المثال) 99 دولارا لكل 1 دولار من رسوم الأولوية ، فيمكنه الحصول على 99٪ من MEV التنافسية لتلك المعاملة.

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

نوضح كيف يمكن استخدام الضرائب MEV لحل ثلاث مشاكل رئيسية في MEV البحث:

• أجهزة توجيه تبادل اللامركزية (DEX) التي تعمل على تحسين السعر الذي يتلقاه المبادل
• صناع السوق الآليون (AMMs) الذين يقللون من الخسارة مقابل إعادة التوازن (LVR) التي يعاني منها مزودو السيولة
• محافظ تتيح لمستخدميها التقاط أي MEV "تراجع" تم إنشاؤها بواسطة معاملاتهم

ولكن هناك مشكلة. لا تعمل MEV الضرائب إلا إذا اتبع مقترحو الكتل بدقة قواعد ترتيب الأولوية التنافسية ، والتي تشمل فرز المعاملات حسب رسوم الأولوية دون فرض رقابة أو إلقاء نظرة خاطفة أو تأخير أي منها. إذا انحرف مقترحو الكتلة عن هذه القواعد ، فيمكنهم التهرب من الضرائب MEV للحصول على القيمة لأنفسهم. اليوم ، لذلك ، تعتمد ضرائب MEV على الثقة في أجهزة تسلسل L2 ، ومن المحتمل ألا تعمل على الإطلاق إثيريوم L1 ، حيث يهيمن على بناء البلوك مزاد منشئ تنافسي يزيد من إيرادات مقدم العرض.

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

ترتيب الأولوية

عندما يرسل شخص ما معاملة على إثيريوم L1 أو L2 ، فإنه يحدد رسوم الأولوية ، والتي يدفعها إلى مقترح الكتلة.1 يمكنك أن تتخيل أن هذا محدد على أنه أولويةFeePerGas ، وهو رقم مضروبا في غاز المستخدمة في المعاملة للحصول على builderPriorityFee - إجمالي الدفعة في ETH. 2

لا توجد قاعدة في إثيريوم بروتوكول مفادها أنه يجب ترتيب المعاملات في الكتلة بشراهة عن طريق تنازلي الأولويةFeePerGas. ومع ذلك ، فهذه طريقة شائعة لبناء الكتل - على سبيل المثال ، إنها الخوارزمية الافتراضية التي يستخدمها متسلسلو سلاسل المكدس OP ، بالإضافة إلى geth و reth. لا يسمح ترتيب الأولوية للمعاملات بالتعبير بكفاءة عن إلحاح معاملاتهم فحسب ، بل يقوم أيضا بشكل طبيعي بتوجيه أنواع معينة من MEV إلى مقترح الكتلة.

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

في سيناريو تنافسي حيث يتم التنافس على الأرباح الخالية من المخاطر إلى الصفر ، يجب أن ينتهي الأمر بالباحث الفائز بدفع كامل مبلغ MEV في رسوم الأولوية. 3 لذلك إذا كان هناك 100 ETH من الأرباح التي يمكن تحقيقها من التفاعل مع العقد ، فإن المعاملة الأولى التي تطالب بها ستحدد رسوم أولوية قدرها 100 ETH. (نناقش بعض المحاذير لهذا في قسم القيود).

MEV الضرائب

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

لكن في الواقع ، ليس علينا بالضرورة معرفة أي شيء عن التطبيق. إذا علمنا أن الكتلة يتم بناؤها من خلال ترتيب الأولوية التنافسي ، فلدينا إشارة عالمية واحدة لمقدار MEV في المعاملة: رسوم الأولوية.

نقترح أن العقد الذكي يمكن أن ينظر إلى رسوم الأولوية للمعاملة ويتقاضى رسومه الخاصة كوظيفة متزايدة له. على سبيل المثال ، قد يتطلب العقد من أي شخص يتصل به نقل applicationPriorityFee = 99 * proposerPriorityFee في ETH إلى العقد. 4

يتم دفع هذه الرسوم الجديدة من قبل الباحث الذي يرسل المعاملة ، لذلك يؤثر على سلوك هذا الباحث. إذا كان هناك 100 MEV في فرصة ، فإن المعاملة الفائزة ستحدد الآن فقط رسوم أولوية قدرها 1 ETH ، لأن ذلك سيؤدي إلى دفع إجمالي قدره 100 ETH (1 ETH إلى مقترح الكتلة ، و 99 ETH إلى العقد الذكي). ومن شأن أي رسم أولوية أعلى أن يجعل المعاملة غير مربحة؛ أي رسوم أولوية أقل ستؤدي إلى فقدان الفرصة لمنافس يحدد رسوما أعلى. هذا يعني أن العقد الذكي قد استحوذ على 99٪ من MEV في المعاملة.

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

إذا زادت هذه الرسوم بسرعة كافية كدالة ل priorityFeePerGas ، فلن يتراكم لمقدم العرض سوى مبلغ ضئيل من MEV. نظرا لأن الأولوية FeePerGas مقومة ب wei (واحد من المليار من المليار من ETH واحد) ، فلدينا الكثير من الدقة للعمل معها. على سبيل المثال ، بقدر ما طويل كانت ضريبة MEV حساسة بما فيه الكفاية بحيث تؤدي أولوية FeePerGas البالغة 50,000 إلى ضريبة عالية للغاية ، فإن إجمالي الدفع لمقدم العرض سيكون أقل من 0.01 دولار. 5

ومع ذلك ، هناك تحذير مهم. كما تمت مناقشته في قسم القيود ، لا تعمل الضرائب MEV إلا إذا اتبع مقترحو الكتلة قواعد معينة - ما نسميه "ترتيب الأولوية التنافسي" - بدلا من الانحراف عن تلك القواعد في طلب لزيادة إيراداتهم إلى أقصى حد. إن فرض هذه القواعد بطريقة غير موثوقة يمثل مشكلة مفتوحة.

Single-application MEV capture

هنا نرسم كيف ، على سلسلة مضمونة لاستخدام ترتيب الأولوية التنافسي لبناء الكتل ، يمكن استخدام ضرائب MEV للتخفيف من ثلاث مشاكل مهمة في MEV: السماح لواجهات DEX بتحسين تنفيذ التجارة للمبادلات ، والسماح ل AMMs بتقليل الخسائر في المراجحة ل LPs الخاصة بهم ، والسماح للمحافظ بتقليل تسرب MEV لمستخدميها عن طريق بيع الحق في إعادة تشغيل المستخدم.

DEX أجهزة التوجيه

في بروتوكولات توجيه DEX القائمة على المقاصد مثل UniswapX و 1inch Fusion ، يوقع المستخدم (Alice) على نية المبادلة ، ويتنافس الباحثون على توجيه أو ملء هذه النية بأفضل سعر ممكن لأليس.

تستخدم الإصدارات الحالية من UniswapX آليتين لتشغيل تلك المنافسة: مزاد هولندي حيث يتغير سعر أليس المحدد بمرور الوقت حتى يملأه الباحث ، ومزاد أولي لطلب عرض الأسعار (RFQ) لتحديد سعر البداية لهذا المزاد الهولندي.

على منصة تضمن ترتيب الأولوية التنافسي ، يمكن ل UniswapX استبدالها بآلية واحدة: ضريبة MEV. يمكنه تنفيذ ذلك من خلال جعل المستخدم يوقع على طلب يمكن لأي شخص ملؤه على الفور ، ولكن بسعر تنفيذ يتم تعيينه كدالة لأولوية المعاملة.

على سبيل المثال ، إذا كان لدى Alice طلب UniswapX لبيع ETH واحد ، فيمكنها تحديد سعر تنفيذ طلب ليكون الحد الأدنىالسعر + (0.01 دولار * priorityFeePerGas). الحد الأدنىيمكن أن يكون السعر بعض القيمة الثابتة التي تتوقع أن تكون أقل بكثير من السعر الحالي.

سيتنافس الباحثون لملء طلب أليس من خلال تقديم المعاملات. أي معاملة لها أعلى رسوم أولوية ولا تعود ستحصل على ملء طلب ، مما يضمن حصول المبادلة على أفضل سعر يمكن للباحثين العثور عليه. (تتم مناقشة بعض الاستثناءات لهذا في قسم القيود.)

إذا كان الحد الأدنى لسعر Alice هو 3,000 دولار والسعر الحالي ل ETH هو 3,500 دولار ، فإن الأولوية FeePerGas في الصفقة الفائزة ستكون حوالي 50,000. (لاحظ أنه في معاملة تكلف 200000 غاز ، سيؤدي ذلك إلى دفع حوالي 10 مليارات wei فقط - حوالي 0.000035 دولار - لمقترح الكتلة.)

هذا له بعض الفوائد المحتملة على الآليات الحالية المستخدمة في UniswapX.

يمكن إكمال الطلبات التي تستخدم ضرائب MEV بشكل أسرع وبسعر أفضل من الطلبات التي تستخدم المزادات الهولندية. كما تمت مناقشته في هذه الورقة ، تسرب المزادات الهولندية onchain بعض القيمة إلى MEV بسبب تحركات الأسعار بين الكتل ، وقد تستغرق العديد من الكتل لإكمالها. في المقابل ، يمكن عادة إكمال الطلبات التي تستخدم ضرائب MEV في الكتلة التالية مع التقاط الغالبية العظمى من MEV.

على عكس RFQ خارج السلسلة ، فإن المزاد لملء طلب يستخدم ضرائب MEV سيحدث ذريا مع تنفيذ المعاملات على السلسلة. هذا يعني أنه يمكن ضمان أن مقدم العطاء الفائز ملتزم فقط بملء طلب إذا نجحت معاملته على السلسلة. قد يسهل ذلك على السيولة على السلسلة مثل AMMs التنافس مع السيولة خارج السلسلة ، مما يعني أن UniswapX يمكن أن يكون بمثابة جهاز توجيه أكثر فعالية للأنظمة متعددة المجمعات مثل Uniswap v4.

AMMs

عادة ، تسرب AMMs القيمة إلى المراجحين الذين يتداولون مقابل أسعار قديمة في الجزء العلوي من الكتلة ، كما تمت مناقشته في loss-vs-rebalance papers. يمكننا استخدام الضرائب MEV لجعل AMMs تلتقط هذا MEV. لتبسيط الأمور، سنناقش كيف يمكن أن يعمل ذلك على AMM بدون سيولة مركزة. (إذا كنت مهتما بكيفية حل هذا النوع من المشاكل بالسيولة المركزة ، فإن Sorella ستنشر قريبا حلا واحدا.)

يمكن ل AMM الحصول على MEV عن طريق فرض رسوم إضافية كدالة لرسوم الأولوية على المعاملة ، مما يسمح لها بالمزاد العلني على حق التداول أولا في الكتلة. هناك العديد من الطرق لحساب هذه الرسوم وتحديدها. سنناقش واحدة يمكن القول إنها محايدة - مقومة بوحدات سيولة المجمع ، sqrt (xy). ستكون الصفقة الفائزة هي التي تزيد من سيولة المجمع بأكبر قدر من السيولة.

عند تنفيذ المعاملة الأولى على تجمع في كتلة ، بدلا من فرض الشرط x_end y_end > x_start y_start ، يمكن للمجمع فرض الشرط (مع بعض الثابت):

x_end y_end > (sqrt (x_start y_start) + a * priorityFeePerGas) ^ 2

ستحفز هذه الصيغة متداول المراجحة على التداول بالسعر الحقيقي ، وبعد هذه الصفقة ، يجب أن يكون سعر نقطة المنتصف في المجمع هو السعر الحقيقي. 6

بعد تلك المعاملة الأولى ، يمكن أن تعمل التداولات كما تفعل على Uniswap v2 ، مع رسوم مقايضة ثابتة. المعاملات غير المستنيرة التي ترغب في التداول على المجمع دون دفع ضريبة MEV إضافية ستحدد رسوما ذات أولوية منخفضة.

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

Backrunning auctions

توضح الأوصاف أعلاه كيف يمكن تصميم تطبيقات معينة لتجنب تسرب MEV. ومع ذلك ، ماذا لو أرادت المحفظة محاولة مساعدة مستخدميها على التقاط MEV التي ينشئونها من المعاملات التعسفية التي تتفاعل مع أي تطبيق ، حتى تلك التي لا تتضمن ضرائب MEV؟

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

MEV-Share و MEVBlocker هما بروتوكولان يسمحان للمستخدمين بالتقاط MEV من معاملاتهم ، لكنهما يعتمدان على نظام مزاد معقد خارج السلسلة. تصف مساحة تصميم مزاد تدفق الطلبات بعض الحلول الأخرى.

MEV الضرائب ، عندما تقترن بمحفظة عقود ذكية قائمة على النوايا ، يمكن أن تسمح لنا ببناء نظام بديل لالتقاط MEV المتأخرة لأليس. لنفترض أنه بدلا من إنشاء معاملة يتم تداولها على AMM ، توقع أليس نية يمكن لأي شخص تقديمها إلى محفظة العقود الذكية الخاصة بأليس لجعلها تتخذ هذا الإجراء. تفرض محفظة العقود الذكية الخاصة ب Alice على كل من يقدم هذه المعاملة ضريبة MEV ، والتي يتم دفعها إلى Alice.

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

لاحظ أن هذا النظام قد لا يحمي المستخدمين بالضرورة من الهجمات التي تتضمن معاملات مستخدم مسبقة، لأن المعاملة التي تدير المستخدم قد تكون قادرة على تجنب دفع ضريبة MEV لهذا المستخدم. تتم مناقشة هذه المشكلة (وبعض التخفيفات الممكنة لها) بمزيد من التفصيل في قسم القيود أدناه. ومع ذلك ، يمكن أن يكون هذا على الأقل تحسينا للأنظمة التي تستخدم mempools العامة دون أي تخفيف.

حالات الاستخدام الأخرى

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

• بروتوكولات أوراكل لالتقاط قيمة أوراكل القابلة للاستخراج التي تنشئها ، مثل البيضاوي
• مزادات إعادة التمويل في بروتوكولات الإقراض المضمونة NFT مثل Blend
• Lending بروتوكول التصفية التي تسرب أقل القيمة من المزادات الهولندية

التقاط MEV عبر التطبيقات

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

إذا كان واحد فقط من هذه التطبيقات لديه ضريبة MEV ، فيجب أن تذهب جميع MEV من المعاملة إلى التطبيق مع ضريبة MEV ، بغض النظر عن مدى ارتفاع أو انخفاض ضريبة MEV.

ولكن ماذا لو تفاعلت معاملة الباحث مع تطبيقين يستخدمان ضرائب MEV؟ على سبيل المثال ، ماذا لو كان هناك بعض MEV التي لا يمكن التقاطها إلا عن طريق ملء أحد أوامر UniswapX الخاضعة للضريبة MEV الموضحة أعلاه مقابل AMM خاضع للضريبة MEV؟

في هذه الحالة ، يتم تحديد المبلغ النسبي لل MEV الزائدة التي تم التقاطها بواسطة كل طلب من خلال كيفية تعيين تلك التطبيقات لضرائب MEV الخاصة بها. إذا تم إعطاء القيمة app_i الرسوم كضريبة MEV بواسطة الدالة tax_i (الأولوية) ، فيمكن تحديد أولوية المعاملة الفائزة من خلال حل الأولوية في هذه المعادلة:

tax_1 (الأولويةPerGas) + tax_2 (الأولويةPerGas) = إجمالي MEV

(من الناحية الفنية ، يمكننا إضافة مصطلح ثالث ل PriorityPerGas * gasUsed to الحساب مقابل رسوم الأولوية المدفوعة لمقترح الكتلة ، لكننا سنتجاهل ذلك لأنه ، كما تمت مناقشته في الملحق أ ، من المحتمل أن يكون ضئيلا في ظل الظروف العادية.)

في الحالة البسيطة للضرائب MEV الخطية في الأولويةPerGas (لذلك tax_1(priorityPerGas) = a_1 * priorityPerGas) ، يمكنك حل حصة MEV التي يتلقاها كل تطبيق:

a_1 الأولويةPerGas + الأولوية a_2 PerGas = MEV

الأولويةPerGas = MEV / (a_1 + a_2)

tax_1(الأولويةPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(الأولويةPerGas) = (a_2/(a_1+a_2))*MEV

عند تعيين ضريبة MEV الخاصة به ، يواجه التطبيق مقايضة - تسمح له الضرائب الأعلى بالحصول على حصة أكبر من MEV التطبيقات المشتركة عند حدوثها ، ولكنها تعني أنه قد يفوت بعض MEV التطبيقات المشتركة إذا كانت هناك طرق متنافسة لاستخراجها. على سبيل المثال ، إذا كان هناك AMM يفرض ضريبة MEV على كل صفقة ، فمن المرجح أن يتم ملء طلب UniswapX ذات الضريبة MEV بواسطة AMM مختلف أو حشو خارج السلسلة.

في كثير من الحالات ، قد يكون هناك توازن حيث يقوم تطبيقان بتصميم ضرائب MEV الخاصة بهما طلب لتقاسم MEV بطريقة تزيد من رفاهية كل منهما. على سبيل المثال ، من المحتمل أن ترغب AMM MEV الضريبية في الحصول على قيمة من تاجر واحد مطلع بالقرب من الجزء العلوي من الكتلة ، ولكنها تريد بعد ذلك توفير السيولة للمتداولين والتطبيقات الأخرى (بما في ذلك تلك التي تستخدم ضرائب MEV) برسوم ثابتة منخفضة. في هذه الحالة ، من المرجح أن تحدد AMM ضريبة MEV منخفضة نسبيا (على سبيل المثال ، 0.00001 دولار من priorityFeePerGas) ، بحيث تحدث معاملة المراجحة (إن وجدت) في وقت مبكر من الكتلة ، ثم لا تفرض ضريبة MEV على المعاملات اللاحقة في الكتلة. يمكن لتطبيقات مثل UniswapX التي ترغب في التفاعل مع AMM تعيين ضريبة MEV أعلى بكثير (على سبيل المثال 0.01 دولار أولويةFeePerGas) ، لضمان تضمين معاملاتها بعد التحكيم في المجمع بالفعل. مع هذه الضرائب النسبية ، سينتهي الأمر ب AMM أولا حتى لو كان هناك 1 دولار فقط من MEV عليه و 50,000 ألف دولار من MEV في طلب UniswapX.

نعتقد أن هذه مساحة تصميم واسعة تستحق الدراسة المستقبلية.

القيود

MEV الضرائب لها بعض التعقيدات والعيوب. نعتقد أن كل من هذه المجالات مثيرة للاهتمام للبحث في المستقبل.

عدم توافق الحوافز

MEV الضرائب ليست متوافقة مع الحوافز لمقترح الكتلة الاحتكارية. إنها تعمل فقط إذا كانت هناك منافسة عادلة لإدراج المعاملات ، والتي لا يمكن أن تحدث إلا إذا اتبع مقترح الكتلة القواعد التي سنسميها "ترتيب الأولوية التنافسية" ، بدلا من تعظيم إيراداته الخاصة. بشكل غير رسمي وغير شامل ، نقترح أن تتضمن هذه القواعد ما يلي:

• ترتيب الأولوية. يجب ترتيب المعاملات داخل الكتلة في طلب تنازلي من FeePerGas.
• الرقابة مقاومة. إذا تلقى مقترح الكتلة معاملة t1 أثناء الكتلة ، وكانت الكتلة إما غير ممتلئة أو تتضمن بعض المعاملات t2 مثل t2.priorityFeePerGas < t1.priorityFeePerGas ، فيجب أن تتضمن الكتلة المعاملة t1.
• خصوصية ما قبل المعاملة. يجب على مقترح الكتلة قبول المعاملات من خلال نقطة نهاية خاصة ويجب ألا يشارك هذه المعاملات مع أي شخص آخر قبل الالتزام بالكتلة ، أو استخدام محتوى تلك المعاملات كمدخل في إنشاء معاملاته الخاصة.
• لا نظرة أخيرة. يجب على مقترح الكتلة تعيين وقت محدد يقبل قبله المعاملات من أي شخص ، وبعد ذلك لا يقبل المعاملات من أي شخص.

إذا تم انتهاك واحد أو أكثر من هذه الممتلكات ، فقد يضعف فعالية الضرائب MEV. يمكن لمقترح الكتلة الذي ينتهك مقاومة الرقابة تجنب معظم الضرائب MEV من خلال استبعاد المعاملات المنافسة وتقديم معاملة ذات أولوية صفرية تنتهز الفرصة لنفسها. يمكن لمقترح الكتلة الذي ينتهك خصوصية ما قبل المعاملة أن يسرق MEV من المعاملات الأخرى أو يلقي نظرة خاطفة على رسوم الأولوية الخاصة به ليعرف بالضبط مدى الارتفاع الذي يحتاجه لتعيين رسومه الخاصة ، في حين أن الشخص القادر على تقديم المعاملات في وقت متأخر عن أي شخص آخر سيكون لديه "نظرة أخيرة" مجانية حول ما إذا كان يجب المزايدة على الآخرين للحصول على فرصة ، وأي منهما يمكن أن يخلق مشاكل اختيار سلبية تؤدي في نهاية المطاف إلى تثبيط المنافسة.

لسوء الحظ ، في حين أن الخاصية الأولى سيكون من السهل فرضها في طبقة البروتوكول ، فإن فرض الخصائص الأخرى دون ثقة يمثل مشكلة مفتوحة.

في غياب الإنفاذ في طبقة البروتوكول ، يجب الوثوق بجهاز تسلسل واحد يلتزم بهذه القواعد بعدم الانحراف عنها ، وإذا قام المقترحون بالاستعانة بمصادر خارجية لبناء الكتل إلى مزاد تنافسي لتعظيم الإيرادات (مثل إثيريوم L1's MEV-Boost) ، فمن المحتمل ألا تتبعها الكتل.

يمكن "حل" هذه المشكلات باستخدام جهاز تسلسل واحد موثوق به يلتزم باستخدام ترتيب الأولوية التنافسي لبناء الكتل. قد تكون أيضا قابلة للحل باستخدام آلية لامركزية باستخدام مزيج من الإجماع والتشفير و / أو بيئات التنفيذ الموثوقة ، مثل Sorella's Angstrom أو Flashbots's SUAVE أو Leaderless Auctions أو Multiplicity.

Full blocks

يحدث استثناء واحد للتشغيل العادي للضرائب MEV عندما تكون الكتل ممتلئة تماما. في هذه الحالة ، قد يضطر مقترحو الكتلة إلى استبعاد المعاملات ذات الأولوية المنخفضة ، بدلا من مجرد تضمينها في وقت متأخر من الكتلة. نظرا لأن المعاملات التي تتفاعل مع التطبيقات الخاضعة للضريبة MEV من المحتمل أن يكون لها رسوم أولوية منخفضة للغاية ، فمن المحتمل أن تزاحم هذه التطبيقات بالتطبيقات التي لا تستخدم ضرائب MEV ، أو تلك التي لديها ضرائب MEV منخفضة للغاية. ومع ذلك ، في سلسلة تستخدم آلية تشبه EIP-1559 لتعيين رسوم أساسية منفصلة ، يجب أن يكون من النادر نسبيا أن تكون الكتل ممتلئة تماما. بالإضافة إلى ذلك ، نظرا لأن بعض المعاملات تحتاج إلى تأخير عندما تكون الكتل ممتلئة ، فإن تأخير المعاملات التي تعبر عن إلحاح أقل من خلال تحديد ضرائب MEV أعلى قد يكون نتيجة معقولة.

المعاملات المرتجعة

تعتمد MEV الضرائب بشكل فعال على مزادات الكتلة الواحدة التي يكون فيها كل "عطاء" معاملة. أحد الجوانب السلبية لهذه المزادات هو أن العطاءات الخاسرة ستؤدي عموما إلى إدراج المعاملات المرتجعة في السلسلة ، ودفع بعض الرسوم الأساسية وازدحام السلسلة.

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

تسريب نوايا المستخدم

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

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

على سبيل المثال ، افترض أن Alice تريد شراء رمز مميز منخفض السيولة باستخدام بروتوكول المزاد الخلفي الموضح أعلاه. تنشر نية موقعة لمحفظتها التعاقدية الذكية لشراء هذا الرمز المميز على AMM ، مما يضع بعض التسامح مع الانزلاق. يمكن للباحثين أن يتسابقوا لدفع سعر هذا الرمز المميز إلى تسامحها مع الانزلاق في معاملة ذات أولوية عالية ، دون ملء طلب المستخدم. يمكن للفائز ، بوب ، بعد ذلك أن يملأ نية أليس بشكل غير تنافسي من خلال تضمينها وإعادتها في معاملة ذات أولوية منخفضة ، وبالتالي وضع صفقة أليس ومنحها سعرا أسوأ مع التهرب من ضريبة MEV. يمكن أن تحدث مشكلة مماثلة مع مشتريات NFTs.

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

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

قد يكون من الممكن أيضا الجمع بين الضرائب MEV وميزات المنشئ المدركة للخصوصية مثل المتصورة في تصميمات Flashbots ل SUAVE.

أخيرا ، في الحالات التي تقرر فيها أليس أن تكاليف مشاركة نيتها تفوق الفائدة من البحث التنافسي ، يمكنها إنشاء معاملة بنفسها وتقديمها مباشرة إلى الكتلة. وكما نوقش أعلاه، فإن التنفيذ المثالي لترتيب الأولويات التنافسي من شأنه أن يوفر خصوصية ما قبل المعاملة من مقترح الكتلة.

المناقشة والعمل السابق

أولوية غاز المزادات. تمت دراسة بعض ديناميكيات ترتيب الأولويات في سلاسل الكتل اللامركزية في ورقة Flash Boys 2.0 ، والتي صاغت مصطلح "قيمة التعدين القابلة للاستخراج". ولاحظت تلك الورقة أن إثيريوم عمال المناجم (عندما كانت تلك الشبكة تستخدم إثبات العمل) كانوا يطلبون بالفعل المعاملات حسب الأولوية، وأن المراجحين يعتمدون على هذا السلوك للمشاركة في "مزادات غاز ذات الأولوية" التي يتقدمون فيها بعطاءات للحصول على الحق في أن يدرجوا أولا في كتلة ما، مما أدى إلى الكثير من MEV من المراجحة تبادل اللامركزية التي تعود إلى عمال المناجم.

من يأتي أولا يخدم أولا. ركزت بعض المحاولات لتخفيف MEV من خلال قواعد ترتيب المعاملات ، مثل Themis أو Arbitrum One's sequencer,7 على فرض قاعدة ترتيب مختلفة، من يأتي أولا، يخدم أولا (تسمى أحيانا "الترتيب العادل") حيث يجب على مقترحي الكتلة طلب المعاملات في طلب التي يرونها فيها.

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

من الصعب فرض من يأتي أولا يخدم أولا أو حتى تحديده في بيئة شبكة حقيقية مع أكثر من مدقق واحد. يمكن أن يؤدي أيضا إلى إهدار سباقات وقت الإستجابة والبريد العشوائي حتى مع وجود جهاز تسلسل واحد موثوق به. وأخيرا، قد تكون الضرائب MEV قادرة على القضاء على أنواع معينة من MEV التي لا يستطيع من يأتي أولا يخدم أولا أن يتحقق، مثل أرباح المراجحة من "القفزات" المتقطعة في أسعار الأصول. ترتبط المزايا المحتملة للترتيب ذي الأولوية على الطلب من يأتي أولا يخدم أولا إلى حد ما بمزايا الوقت المنفصل على التبادلات المستمرة التي تمت مناقشتها في Budish، Cramton، Shim (2015) .

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

تقاسم الرسوم. Blast, a إثيريوم L2, يشترك في جزء من كل من رسوم الأولوية والرسوم الأساسية مع العقود الذكية التي يتم الوصول إليها في المعاملة.

تسمح الضرائب MEV بشيء مماثل (على الأقل بالنسبة لرسوم الأولوية) ، ولكن يمكن تنفيذها في طبقة التطبيق على أي سلسلة تستخدم ترتيب الأولوية التنافسي ، دون الدعم خاص لتقاسم الرسوم. كما أنها تسمح للتطبيقات بتعريف الضرائب الخاصة بها كوظائف مخصصة لرسوم الأولوية ، مما يوفر مزيدا من المرونة ويحتمل أن يؤدي إلى زيادة قابلية تكوين التطبيقات المدركة MEV.

حلول عديم الثقة. يركز هذا المنشور على الدافع وراء استخدام المنصات لترتيب الأولويات التنافسي - وطرق الاستفادة من المنصات التي تفعل ذلك - بدلا من مناقشة كيفية فرضه بلا ثقة.

وكانت هناك مناقشة سابقة مستفيضة لكل من الممتلكات الأخرى اللازمة لترتيب الأولويات التنافسي. على سبيل المثال ، في Fox, Pai, Resnick (2023)، يناقش المؤلفون نقاط الضعف في مزادات onchain في غياب مقاومة الرقابة، ويصفون تصميما لمزاد مقاوم للرقابة باستخدام العديد من المقترحات المتزامنة. ومع ذلك ، فإنها لا تقترح ترتيبا محددا للمعاملات.

كانت هناك أبحاث أخرى حول بناء آليات لبناء الكتل إلى الحد الأدنى من الثقة ، بما في ذلك Flashbots SUAVE ، Sorella's Angstrom ، مزادات بلا قيادة ، Espresso و Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentral Timeboost, and إلزامي إدراج المعاملات العامة من قبل بيتر زيلاجي.

استنتاج

نأمل أن يشجع هذا المنشور L2s على التفكير في استخدام ترتيب الأولوية (كما هو مدعوم افتراضيا في OP Stack) ويلهم التطبيقات لتجربة ضرائب MEV حيث يتم دعمها.

نأمل أيضا أن يحفز ذلك على إجراء مزيد من البحث في بروتوكولات ترتيب الأولوية التنافسية المخفضة للثقة على كل من L1 و L2. إذا كنت مهتما بالتعاون في حل هذه المشكلة ، وتقرأ هذا قبل يوم الخميس ، 6 يونيو ، فلا يزال بإمكانك التقدم بطلب للحصول على زمالة TLDR للعمل على أجهزة تسلسل L2 المقاومة ل MEV مع دان. أو لا تتردد في التواصل مع dan@paradigm.xyz و dave@paradigm.xyz بالأفكار!

Footnotes

1. في هذا المنشور ، نستخدم كلمة "مقترح" للإشارة إلى الممثل أو العملية التي تحدد المعاملات المضمنة في كتلة معينة. في إثيريوم L2s ، يتم ملء هذا الدور عادة بواسطة "جهاز تسلسل". في إثيريوم L1 ، يتم ملؤها بواسطة مدقق إثيريوم محدد يسمى مقدم العرض ، على الرغم من أن مقدم العرض غالبا ما يستعين بمصادر خارجية لمهمة بناء الكتلة إلى مزاد تنافسي يشارك فيه "القائمون" و "البناة". تفاصيل كيفية تقسيم هذه المسؤوليات خارج نطاق هذا المنشور. ↩
2. لم يتم تحديد رسوم الأولوية لكل غاز صراحة في المعاملة ، ولكن يمكن حسابها فيها. تحدد المعاملة سعر الغاز ، ولكن إثيريوم تفرض أيضا رسوما أساسية ، يتم إخراجها من سعر الغاز وحرقها. يجب تجاهل الرسوم الأساسية لأغراض MEV الضرائب ، لأنها ليست تحت سيطرة المتداول. يمكن حساب رسوم الأولوية لكل غاز - سعر جزء رسوم المعاملة الذي يذهب إلى مقترح الكتلة - في Solidity كأولويةGasPrice = tx.gasprice - block.basefee. ↩
3. بدلا من ذلك ، يمكننا ببساطة تعريف "MEV" لاستبعاد أي ربح للباحث والإشارة فقط إلى القيمة التي ستذهب إلى المدقق. ↩
4. لاحظ أن proposerPriorityFee - يساوي الأولويةFeePerGas مضروبا في إجمالي غاز المستخدمة في المعاملة - لا يمكن حسابه فعليا أثناء العقد ، حيث لا توجد طريقة لمعرفة مقدار غاز التي ستنتهي بها المعاملة. ومع ذلك ، لن يكون هذا مهما بشكل عام ، لأن كل ما نحتاجه هو حد أعلى لذلك. لكي تكون آمنا ، يمكنك مضاعفة الأولوية FeePerGas بمقدار 30 مليون - الحد الأقصى الحالي غاز في كتلة إثيريوم. إن المبالغة في تقدير هذه القيمة تعني ببساطة أن ضريبة MEV تستحوذ على نسبة أكبر من MEV. ↩
5. بافتراض أن المعاملة لا يمكن أن تزيد عن 30 مليون غاز ، فإن أولوية FeePerGas البالغة 50000 ستؤدي إلى دفعة غاز قدرها 1500 gwei - حوالي 0.006 دولار بسعر ETH قدره 4000 دولار. ↩
6. في الحالة التي يتم فيها تعيين الأولويةFeePerGas بحيث يكون ربح المحكم صفرا ، يجب أن تتوافق تجارة المراجحة لتعظيم الربح مع نفس التجارة على وظيفة تعظيم AMM. يتم ترك إثبات ذلك كتمرين للقارئ. ↩
7. ناقش Arbitrum ↩

إخلاء المسؤولية:

1. تمت إعادة طباعة هذه المقالة من [paradigm]. جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [Dan Robinson & Dave White]. إذا كانت هناك اعتراضات على إعادة الطبع هذه ، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.

2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. يحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها، ما لم يذكر ذلك.