كيفية تحقيق تسلسل عادل للمعاملات باستخدام وحدات MEV؟

المؤلف: Maven11

مترجم: لوفي ، أخبار البصيرة

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

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

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

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

VSR مثير للاهتمام بشكل خاص عندما نأخذ في الاعتبار حقيقة أن غالبية مستثمري التجزئة لم يتبنوا بعد (أو من غير المرجح) نهج الحفظ. لا تقوم معظم Wallet / DEXs أيضا بتنفيذ mempools خاصة أو RPCs أو طرق مماثلة. يتم إرسال معظم المعاملات مباشرة من خلال الواجهة الأمامية (سواء كانت مجمعا أو واجهة واجهة DEX). نتيجة لذلك ، ما لم يتداخل التطبيق بشكل مباشر مع عملياته وطريقة معالجة الطلبات ، فقد يواجه المستخدم النهائي تنفيذا أقل من مرض.

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

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

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

في ورقة "تصميم تبادلات DEX الموثوقة مع عمليات التجميع التي يمكن التحقق منها" ، يقترح Matheus V. و X. Ferreira و David C. Parkes نموذجا يخضع فيه تسلسل الكتلة لسلسلة من القيود التي تنفذ عمليات الترتيب (وهذه القيود قابلة للتحقق). دون الالتزام بالقواعد المحددة ، يمكن للمراقب إنشاء دليل على الفشل (أو نظرا لأن القيود يمكن التحقق منها رياضيا ، يمكنك أيضا تخيل دائرة ZK بهذه القيود ، والتي تستخدم ZKP كدليل على الصلاحية). الفكرة الرئيسية هي في الأساس توفير ضمان سعر التنفيذ للمستخدم النهائي (التاجر). يضمن هذا الضمان تنفيذ المعاملة بنفس جودة المعاملة الوحيدة في الكتلة (من الواضح ، إذا افترضنا أمر شراء / بيع / شراء / بيع بناء على أساس من يأتي أولا يخدم أولا ، فهناك قدر معين من التأخير هنا). الفكرة الأساسية للمقترحات في الورقة هي أنه إذا كان أداؤها بسعر أفضل من السعر المتاح في الجزء العلوي من الكتلة ، فإن عمليات التجميع هذه ستقيد المنشئ (في سيناريو PBS) أو جهاز التسلسل من تضمين المعاملات في نفس الاتجاه فقط (على سبيل المثال بيع / بيع). بالإضافة إلى ذلك ، إذا كان هناك موقف تقوم فيه بإجراء عملية بيع في نهاية سلسلة من عمليات الشراء ، فلن يتم تنفيذ البيع (على سبيل المثال ، شراء ، شراء ، شراء ، بيع) ، مما قد يشير إلى أن الباحثين (أو البناة / المتسلسلين) يستخدمون هذه المشتريات لدفع السعر لصالحهم. هذا يعني بشكل أساسي أن قواعد البروتوكول تضمن عدم استخدام المستخدمين لتقديم سعر أفضل (أي MEV) لشخص آخر ، أو للتسبب في انخفاض السعر بسبب رسوم الأولوية. من الواضح أن عيب القاعدة هنا (في حالة البيع أكثر من الشراء ، والعكس صحيح) هو أنك قد تحصل على سعر ذيل طويل ضعيف نسبيا.

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

في حالة مجموعة التحديثات باستخدام توفر البيانات ومستويات الإجماع ومستويات تسوية السيولة، تكون الإعدادات المحتملة كما يلي:

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

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

فكرة أخرى مثيرة للاهتمام ذكرناها سابقا في المنشور هي استخدام المزادات الجماعية المتكررة (FBA) ، التي دعا إليها الأسطوري إريك بوديش وزملاؤه ، لمعالجة المعاملات بطريقة المزاد بالجملة بدلا من الموضة المتسلسلة. هذا للمساعدة في تحديد الطلب المتداخل (CoW) ودمج فرص المراجحة في تصميم آلية السوق. يساعد هذا أيضا على "محاربة" الألعاب المؤجلة في إصدارات Block المستمرة (أو معارك التكلفة ذات الأولوية في الكتلة التسلسلية). شكرا لمايكل جوردان (DBA) على لفت انتباهنا إلى هذه الورقة وعلى عمله على التخفيف من Latency Roast. يعد تنفيذه كجزء من اختيار شوكة Rollup وترتيبها أيضا إعدادا مثيرا للاهتمام يمكن للمطورين استخدامه ، وقد رأينا قوة جذب كبيرة خلال العام الماضي ، خاصة بالنسبة ل Penumbra و CoWSwap. سيبدو أحد الإعدادات المحتملة كما يلي:

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

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

من المهم أيضا ملاحظة أنه في عام 2018 ، تمت مناقشة تصميمات مثل تلك التي غطيناها للتو في منتديات Ethresear.ch (انظر هنا). في المنشور ، يذكرون ورقتين توفران آلية مزاد بالجملة على البلازما (تشبه إلى حد ما مقدمة ل Rollups الحديثة) ، حيث تقبل كل دفعة أوامر لشراء رموز ERC20 إضافية بسعر حد أقصى معين. يتم جمع هذه الطلبات على فترات زمنية معينة وتوفر سعر تسوية موحد لجميع أزواج تداول الرمز المميز. الفكرة العامة وراء هذا النموذج هي أنه سيساعد في القضاء على ظاهرة التشغيل الأمامي الشائعة في AMMs الشائعة.

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

هذا واضح لمعظم الناس ، ولكن لا يزال يتعين ذكره عند مناقشة ترتيب مستويات التراكم. إذا كان بإمكانك التحكم في الطلب ، فسيكون من الأسهل "استخراج" قيمة البروتوكول. هذا لأنك تتحكم في القدرة على إعادة ترتيب المعاملات ، والتي تعتمد عادة على رسوم الأولوية (إعدادات MEV-boost-esque) في معظم L1s. يوفر لك رسوم الأولوية التي يدفعها المشاركون المعقدون الذين يستخرجون القيمة على السلسلة. عادة ما يكون هؤلاء المشاركون على استعداد لدفع مبلغ كبير (حتى يصبح غير قادر على تقديم قيمة). ومع ذلك ، فإن معظم عمليات التجميع الحالية تكون في المقام الأول على أساس من يأتي أولا يخدم أولا. يتم تنفيذ معظم عمليات استخراج MEV من خلال الحروب المتأخرة ، مما يضع ضغطا خطيرا على البنية التحتية التراكمية. نتيجة لما سبق ، من المحتمل أن نرى المزيد والمزيد من عمليات التجميع تبدأ في تنفيذ هيكل فرز بمفهوم رسوم الأولوية (على سبيل المثال ، آلية Arbitrum لتعزيز الوقت).

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

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

إذا افترضنا وجود مجموعة تحديثات بآلية PBS جزئية ، فقد تبدو عملية تدفق الطلبات وتسويقها كما يلي:

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

الإصدار (PoS) + دخل الرسوم (+ الأولوية) - تكلفة DA ، حانة الدولة ، التخزين

يمكن العثور على طريقة جيدة لمعرفة مقدار القيمة التي يتم سحبها حاليا على Ethereum (خاصة Arbitrage) على Mevboost.pics ، والتي تعطي نظرة عامة جيدة على مقدار القيمة التي يمكن استخلاصها بالفعل من أوجه القصور.

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

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

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