مقدمة

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

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

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

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

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

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

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

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

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

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

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

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

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

ضرائب MEV

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

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

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

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

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

إذا زادت هذه الرسوم بشكل كافٍ بوصفها وظيفة لنسبة الرسوم المفضلة للوقود بالغاز، فإن كمية إيرادات التجارة المتنافسة ستكون ضئيلة جدًا للمقترح. نظرًا لأن نسبة الرسوم المفضلة للوقود بالغاز معدلة بوحدة وي (مليار جزء من مليار جزء من واحد الإثيريوم)، لدينا الكثير من الدقة للعمل بها. على سبيل المثال، طالما أن ضريبة التجارة المتنافسة حساسة بما يكفي بحيث نسبة الرسوم المفضلة للوقود بالغاز تبلغ 50،000، ستؤدي إلى ضريبة مرتفعة لا يمكن تحملها، فإن المبلغ الإجمالي المدفوع للمقترح سيكون أقل من 0.01 دولار.5

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

استيلاء MEV على التطبيق الفردي

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

موجهات DEX

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

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

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

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

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

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

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

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

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

AMMs

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

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

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

نهاية_xy_end > (sqrt(x_start)y_start) + a*priorityFeePerGas)^2

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

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

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

المزادات الخلفية

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

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

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

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

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

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

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

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

• بروتوكولات لجمع قيمة الأوراكل القائمة التي ينشئونها، مثل مُلتَوَي
• عمليات الإعادة التمويل في بروتوكولات الإقراض المرتكزة على NFT مثلمزج
• التصفيات البروتوكولية للإقراض التي قيمة أقل تسربًامزادات هولندية

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

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

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

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

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

ضريبة_1(الأولوية_لكل_غاز) + ضريبة_2(الأولوية_لكل_غاز) = إجمالي MEV

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

في الحالة البسيطة لضرائب MEV التي هي خطية في الأولوية لكل وحدة غاز (بحيث يكون ضريبة_1(الأولوية لكل وحدة غاز) = a_1 * الأولوية لكل وحدة غاز)، يمكنك حل المسألة لمعرفة النسبة المئوية من MEV المستلمة من كل تطبيق:

a_1priorityPerGas + a_2الأولوية لكل جالون = MEV

الأولوية لكل غاز = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

ضريبة_2(الأولوية_لكل_غاز) = (أ_2/(أ_1+أ_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 الضرائب ليست متوافقة مع الحوافز لمقترح الكتلة الاحتكارية. إنها تعمل فقط إذا كانت هناك منافسة عادلة لإدراج المعاملات ، والتي لا يمكن أن تحدث إلا إذا اتبع مقترح الكتلة القواعد التي سنسميها "ترتيب الأولوية التنافسية" ، بدلا من تعظيم إيراداته الخاصة. بشكل غير رسمي وغير شامل ، نقترح أن تتضمن هذه القواعد ما يلي:

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

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

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

في غياب التنفيذ على مستوى البروتوكول، يجب الثقة في سيكون لدى السيكونسر الفردي الذي يلتزم بهذه القواعد بعدم الانحراف عنها، وإذا كان المقترحون يستعينون ببناء كتلة إلى مزاد تنافسي يهدف إلى تحقيق أقصى قدر من الإيرادات (مثل Ethereum L1’s تعزيز MEV), من المحتمل أن لا تتبع الكتل هذه التوجيهات.

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

كتل كاملة

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

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

تعتمد ضرائب MEV بشكل فعال على مزادات تتم في كتلة واحدة حيث يتم كلُّ مزايدة كعملية انتقال. أحد عيوب هذه المزادات هو أن المزايدات الخاسرة ستؤدي عادةً إلى تضمين عمليات انتقال معكوسة على السلسلة ودفع بعض قيمة الأساس وازدحام الشبكة.

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

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

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

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

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

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

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

قد يكون من الممكن أيضًا دمج ضرائب MEV مع ميزات المُنشئ الحريصة على الخصوصية كما هو متصور في تصاميم Flashbots’s لـلطيف.

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

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

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

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

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

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

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

تقاسم الرسوم. Blast، Ethereum L2، أسهمجزء من الرسوم المتقدمة والأساسية مع العقود الذكية المستخدمة في المعاملة.

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

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

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

هناك بحوث أخرى حول إنشاء آليات لبناء الكتل بأقل قدر من الثقة ، بما في ذلك Flashbots's.أنيق،سوريلاأنجستروممزادات بلا قادة, إسبريسو وOffchain Labs’@espressosys/نظام-الاسبريسو-و-شركة-أوف-تشين-لابس-تصدران-خارطة-طريق-للبحث-والتطوير-لتعزيز-الوقت-اللامركزي-5d0007dff66d">الوقت اللامركزي، و الإدراج العام المفروض للمعاملاتبواسطة بيتر سزيلاغي.

استنتاج

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

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

حواشي

1. في هذا المنشور، نستخدم "المقترح" للإشارة إلى الفاعل أو العملية التي تحدد المعاملات التي تم تضمينها في كتلة معينة. على L2s لـ Ethereum، يتم شغل هذا الدور عادة من قبل المتتابع. في Ethereum L1، يتم شغل هذا الدور من خلال مقترح Ethereum المحدد يسمى المقترح، على الرغم من أن المقترح غالبًا ما يتعاقد على مهمة بناء الكتلة مع مزاد تنافسي يشارك فيه "المؤرخون" و"البناؤون". تفاصيل كيفية تقسيم هذه المسؤوليات خارج نطاق هذا المنشور.↩
2. رسوم الأولوية لكل غاز لا تُحدد بشكل صريح في الصفقة ، ولكن يمكن حسابها فيها. تحدد الصفقة سعر الغاز ، ولكن إيثريوم يفرض أيضًا رسومًا أساسية ، والتي يتم خصمها من سعر الغاز وحرقها. يجب تجاهل الرسوم الأساسية لأغراض ضرائب ال MEV ، لأنها ليست تحت سيطرة المرسل. يمكن حساب رسوم الأولوية لكل غاز - السعر المخصص لجزء من رسوم الصفقة التي تذهب إلى مقترح الكتلة - في Solidity كـ priorityGasPrice = tx.gasprice - block.basefee.↩
3. بدلاً من ذلك ، يمكننا ببساطة تعريف "MEV" لاستبعاد أي ربح للباحث والإشارة فقط إلى القيمة التي ستذهب إلى المحقق.↩
4. يرجى ملاحظة أن رسوم المقترح—التي تساوي رسوم الأولوية لكل وحدة غاز ضربًا في إجمالي الغاز المستخدم في المعاملة—لا يمكن حسابها فعليًا أثناء التعاقد، لأنه ليس هناك طريقة لمعرفة كمية الغاز التي ستستخدمها المعاملة في النهاية. ومع ذلك، هذا عادة لن يكون له أهمية، لأن كل ما نحتاجه هو حد أعلى لها. للحفاظ على الأمان، يمكنك ضرب رسوم الأولوية لكل وحدة غاز بـ 30 مليون—عدد الغاز الأقصى الحالي في كتلة Ethereum. ستعني تقدير قيمة أعلى لها ببساطة أن ضريبة MEV ستلتقط نسبة حتى أكبر من MEV.↩
5. بفرض أن الصفقة لا يمكن أن تكون أكثر من 30 مليون وحدة غاز ، ستؤدي رسوم الأولوية لكل وحدة غاز قدرها 50،000 إلى دفع 1500 جيوي في شكل وحدات الغاز - حوالي 0.006 دولار بسعر ETH قدره 4000 دولار. ↩
6. في الحالة التي يتم فيها تعيين priorityFeePerGas بحيث يكون ربح الوسيط صفرًا، يجب أن يتوافق التجارة التحكيمية التي تعظم الربح مع نفس التجارة على آلية تعيين السعر التي تعمل على تحقيق الحد الأقصى للوظيفة. إثبات هذا يترك كتمرين للقارئ. ↩
7. يحتوي على منصة التحكيمناقشاستبدال هذا بنوع من ترتيب الأولويات المسمى Timeboost، لكن هذا لم يتم تنفيذه حتى كتابة هذا النص.

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

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