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

النية

التجربة الحالية باستخدام معاملات سلسلة الكتل

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

من المحتمل أن تبدو معاملته كما يلي: "أوقع وأرسل هذه المعاملة ، بقيمة Nonce تبلغ 23 ورسوم غاز تبلغ 30 Gwei. ستنفذ عقد Uniswap لمبادلة 1000 USDT الخاصة بي ب 0.5 ETH ، بحد أقصى للانزلاق يبلغ 1٪ ".

△ رقم ترتيبي؟ جوي؟ مصدر الصورة:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

نفترض أن آليس مستخدمة مبتدئة، وأنها ترغب فقط في تبادل الدولار الأمريكي (USDT) الخاص بها بالإيثريوم (ETH)، لكنها يتوجب عليها تخطي العديد من العقبات لتحقيق هذا الرغبة الصغيرة:

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

كل مستوى هو سؤال لا يحتاج المستخدمون المبتدئون فعليًا إلى فهمه ولكنهم مضطرون لاتخاذ خيار: أين تريد الاسترداد؟ هل تريد تعيين انزلاق؟ ما هو النسبة التي يجب تعيينها للاختلاف؟ هل تريد تعديل رسوم الغاز (رسوم الإدارة)؟ كم يجب ضبطه من جيوي؟ لماذا فشلت العملية؟ لماذا تعلقت العملية هناك لفترة طويلة (ربما يكون المشكلة في الرقم التسلسلي أو رسوم الإدارة)؟ ماذا يجب علي فعله؟

تجربة استخدام المعاملات المقصودة

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

في النية ، حددت أليس أنه يجب تبادل 1000 دولار أمريكي مقابل 0.5 إيثريوم ، ولكن باعتبار رسوم التداول ، تم تعديل السعر إلى 0.495 إيثريوم ، ثم تم توقيع الطلب وإرساله. ستبدو معاملة أليس مثل هذا: 'أنا أوقع وأرسل هذا الطلب. أريد تبادل 1000 دولار أمريكي مقابل 0.495 إيثريوم. هذا الطلب صالح طالما أستطيع الحصول على 0.495 إيثريوم.'

إنه بسيط جدًا، أليس كذلك؟ هذه هي تجربة استخدام أمر الحد (الأمر المحدد)، وهي أيضًا التجربة العامة لاستخدام مجمعات DEX (مثل 1inch وTokenlon).

△ الفرق بين المعاملة (أعلى) والنية (أسفل). مع النية، يحتاج المستخدمون فقط إلى تحديد الشروط ولا داعي للقلق بشأن كيفية تحقيقها. التسمية: https://www.paradigm.xyz/2023/06/intents

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

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

النية ستعزز تجربة سلسلة الكتل بشكل كبير.

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

نصيحة القراءة 2: في اللغة الإنجليزية، تُستخدم كلمة الأمرية ("imperative") لوصف تجربة استخدام العملية، والتي تعني إصدار أمر كامل لإكمال الهدف، بينما تُستخدم كلمة "Declarative" ("بيانية") لوصف تجربة استخدام النية. الوصفية، مما يشير إلى أنها تُستخدم من خلال تحديد شروط التنفيذ ونتائج التنفيذ.

النية في العالم عبر السلسلة

في التطبيقات عبر السلسلة مثل الجسور عبر السلسلة و DEX عبر السلسلة ، نظرا لوجود سلسلتين أو أكثر ، يتعين على المستخدمين التعامل مع المزيد من المعاملات على سلاسل مختلفة.

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

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

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

أنيق

الاسم الكامل لـ SUAVE هو العطاء الوحيد الموحّد لتعبير القيمة ، الغرض هو أن يصبح سوق MEV موحّدًا عبر عدة سلاسل. في هذا السوق ، يمكن للمستخدمين التعبير عن شروط الإغلاق والمكافآت للمعاملة بطريقة فعالة. في الوقت نفسه ، سيتنافس المنفذون (المنفذون) مع بعضهم البعض ، وسيتعاونون بكفاءة لإكمال طلبات المستخدم.

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

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

من فلاشبوت إلى تعزيز MEV إلى SUAVE

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

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

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

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

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

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

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

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

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

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

فوائد أخرى لسوافي

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

هندسة SUAVE

لوحة الإعلانات لتفضيلات المستخدم

يمكن وصف SUAVE بأنه "لوحة نقاش تفضيل المستخدم". لا يُشير مصطلح "المستخدم" هنا بالضرورة إلى مستخدمي سلسلة الكتل العامة، ولكن يمكن أن يكون الباحثون أيضًا مستخدمين لـ SUAVE. فيما يلي، سيُشير "المستخدم" إلى مستخدمي سلسلة الكتل العامة بشكل عام، وسيُشير "مستخدم SUAVE" إلى مستخدمي SUAVE.

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

• “أريد أن يتم فرز صفقتي قبل صفقة 0xabcd وأن تدرج قبل البلوك 110050.” في الواقع، هو مثل الشروط المحددة من قبل البحث عن المرجّح عند استخدام فلاشبوت.”
• "أريد أن يتم تضمين حزمتي وتحقيق 0.05 ETH في الإيرادات لي."
• "أريد تضمين النية A والنية B في الكتلة 1001 من السلسلة X والكتلة 50900 من السلسلة Y على التوالي." \

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

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

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

• "أريد أن تُرتب معاملتي قبل معاملة 0xabcd وتكون مُدرجة قبل البلوك 110050. إذا تحقق ذلك، سأعطيك 3 ETH."
• "أريد أن يتم تضمين حزمتي ويجلب لي 0.05 إيثر في الدخل. إذا تحقق ذلك، سأعطيك 0.02 إيثر."
• "أريد أن يتم تضمين النية أ والنية ب في الكتلة 1001 من سلسلة X والكتلة 50900 من سلسلة Y على التوالي. إذا تم ذلك، سأعطيك 1.8 ETH".

الهندسة المعمارية

يمكن اعتبار SUAVE عبارة عن ثلاث مكونات: بيئة التفضيل، وسوق التنفيذ، وبناء الكتل اللامركزي.

• البيئة التفضيلية هي مكان يوفر تفضيلات المستخدم والمكافآت من مختلف السلاسل، بما في ذلك سلسلة SUAVE وبركة المعاملات الخاصة بها. قد يكون مستخدم SUAVE مستخدمًا عامًا أو باحثًا.
• سوق التنفيذ هو مجموعة من المنفذين المحترفين الذين يبحثون عن تنفيذ تفضيلات المستخدم (تنفيذ تفضيلات المستخدم عن طريق تجميعها في باقات) لكسب المكافآت. يمكن أن يكون المنفذ بحثًا أو بنّاءًا
• بناء الكتل اللامركزي هو عملية تجميع الحزم المتعددة في كتل لسلسلة واحدة أو أكثر.

△ يجمع PE الموجود على اليسار النوايا ومعاملات المراجحة على سلاسل مختلفة ، ثم يحاول المنفذون في المنتصف تلبية هذه التفضيلات وتجميعها في حزم ، وتسليم هذه الحزم إلى الدور الموجود على اليمين الذي له الحق في إنتاج كتل لتجميع الكتل. مصدر الصورة:https://writings.flashbots.net/the-future-of-mev-is-suave

سواف سيكون لديها سلسلة خاصة بها وبركة معاملات. سواف تسمي السلسلة طبقة التسوية وبركة المعاملات طبقة الرسائل.

يمكن نشر العقود الذكية على السلسلة لتأسيس عقود بين Preference والمكافآت. ستمتلئ حوض المعاملات بالمعاملات التي يعلن مستخدم SUAVE عن الـ Preference ويتلقى المنفذ المكافآت.

دورة حياة معاملة SUAVE

1. تعبير التفضيل: يحدد المستخدم التفضيل ويقدم عروضاً لواحد أو أكثر من نواياه/المعاملات.
2. تحسين التنفيذ: يجد المنفذ مسار تنفيذ يرضي تفضيل المستخدم، ويمكنه حتى العثور على المسار الأمثل له.
3. تسوية التفضيل: تم تضمين حزمة (حزم) المنفذ بنجاح في كتلة السلسلة الهدف وتلبية التفضيل المحدد من قبل مستخدم SUAVE.
4. تسوية الدفع: يعيد Oracle حالة السلسلة المستهدفة إلى سلسلة SUAVE، ويقوم المنفذ بتنفيذ العقد الذكي. بعد أن يؤكد العقد أن الأفضلية قد تمت الرضا عنها، يتم منح مكافأة مستخدم SUAVE إلى المنفذ.

△ التفضيل أربع خطوات من التأسيس إلى التنفيذ إلى التسوية. مصدر الصورة:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

يجب أن يكون بإمكان SUAVE كتابة التفضيل بلغة برمجة وتحويله إلى عقد ذكي من أجل الوفاء بالعقد بين مستخدم SUAVE والمنفذ. يُتوقع من SUAVE تصميم بيئة تنفيذ EVM محددة لـ MEV استنادًا إلى EVM - MEVM.

سيقوم MEVM بإضافة عقد Precompile ونوع معاملة جديدين خصيصًا لـ MEV. يمكن إكمال وظائف تفضيل المستخدم وتجميع الحزمة وبناء الكتل بسهولة في MEVM.

يكتب كود البرنامج العيني في الشكل أدناه خوارزمية بناء الكتلة لسعر الغاز الفعال (EGP) باستخدام Solidity وعقود MEVM Precompile.

يقوم EGP Block Building بفرز الحزم حسب سعر الغاز الذي يتم تقديمه من كل حزمة. سيتم تصنيف الحزم ذات السعر الأعلى للغاز في الجزء الأمامي من الكتلة:

△ تعد الوظيفة الزهرية في الصورة وظيفة البريكومبايل لـ MEVM، والتي صممت خصيصًا للاستخدام في MEV. مصدر الصورة:https://writings.flashbots.net/MEV-suave-centauri-and-beyond

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

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

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

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

التوصيل والتشغيل السلس

إذا كان مُطوِّر الكتلة أو المُحقق (Validator) لسلسلة معينة يعرف بوجود SUAVE وينوي استخدام SUAVE، فسيعتبر SUAVE كمُنشئ كتلة. إذا قدّم SUAVE سعر مزايدة أعلى للكتل التي يبنيها، فسيستخدم المُنقبون أو المُحققون كتل SUAVE. على سبيل المثال، بالنظر إلى MEV-Boost الحالي على إيثريوم، ستُحول الكتل التي يُشكّلها SUAVE إلى شكل يتوافق مع آلية المزايدة MEV-Boost من خلال المكون الإضافي الذي يُوفّره SUAVE. لن يحتاج المُقترح إلى إجراء أي تغييرات من أجل اعتماد كتل SUAVE.

إذا لم يكن مطور الكتلة أو المدقق لسلسلة يعرف بوجود SUAVE، فسيقدم Executor لـ SUAVE عرضًا لتلقي حزمته عبر قواعد الرسوم الخاصة بالسلسلة.

تحديات تبادل MEV عبر السلاسل

كل سلسلة لها مطور كتلة ومدقق خاص بها. لا تعني الكتلة B1 من SUAVE التي يتم استلامها بواسطة السلسلة X أن الكتلة B2 سيتم استلامها أيضا بنجاح بواسطة مدقق السلسلة Y. آليات إنتاج البلوك وأسواق سلسلة X وسلسلة Y مستقلة. ما لم تستخدم كل من السلسلة X والسلسلة Y جهاز التسلسل المشترك ، وينتج نفس جهاز التسلسل كتلا لكلتا السلسلتين في نفس الوقت ، فعندئذ فقط من خلال الجمع بين SUAVE يمكننا ضمان التضمين الذري: يجب ألا تقوم السلسلتان "بجمع معاملات (أو كتل) محددة معا". يوان)"، أو "لا دخل على الإطلاق".

وحتى لو يمكن لجهاز Shared Sequencer ضمان الإدراج الذري، فإن ذلك لا يعني أن الصفقة ستنفذ بنجاح بعد الإدراج. إذا لم تُنفذ كلتا الصفقتين بنجاح، فهذا يعني أن MEV عبر السلاسل قد فشل. بافتراض أن مستخدم SUAVE يرغب في إتمام تحكيم عبر السلاسل، يجب إنشاء صفقات على كلتا السلاسل في الوقت الحقيقي وتنفيذها بنجاح قبل أن يستفيد.

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

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

إذا تم دفع كل من الصفقتين في الوقت الحقيقي وتنفيذهما بنجاح، يمكن لمستخدم SUAVE كسب فارق السعر. السيناريو 1 و 2 في الجدول في الصورة هما "مستخدم SUAVE على استعداد لتحمل المخاطر بنفسه" و"التنفيذي على استعداد لتحمل المخاطر" على التوالي.

الأعمدة الثلاثة السفلية من الجدول هي "مكافآت لكل من النجاحات"، "مكافآت لنجاح واحد فقط"، و "النتيجة النهائية لنجاح واحد فقط":

• المكافآت لكلتا الصفقتين الناجحتين (يكسب مستخدم SUAVE الفارق في السعر):
  • السيناريو 1: يدفع المستخدم SUAVE رسوم تسديد بقيمة 50 دولارًا للمنفذ.
  • السيناريو 2: يدفع المستخدم البخاري رسوم إدارية بقيمة 70 دولارًا للمنفذ (أكثر تكلفة لأن المنفذ يتحمل المخاطر).
• لا يوجد سوى مكافأة واحدة للنجاح (لم يكسب مستخدم SUAVE الانتشار):
  • السيناريو 1: يدفع المستخدم السويف 25 دولارًا كرسوم معالجة إلى المنفذ. يتحمل مستخدمو السويف المخاطر بأنفسهم.
  • السيناريو 2: لا يجب على مستخدم SUAVE دفع الرسوم أو تحمل المخاطر.
• هناك نتيجة واحدة ناجحة فقط (لم يكسب مستخدم SUAVE الفارق):
  • سيناريو 1: يدفع مستخدم SUAVE رسوم تنفيذ بقيمة 25 دولارًا للمنفذ ولديه إيثريوم إضافي في يده.
  • السيناريو 2: لا يجب على مستخدم SUAVE دفع رسوم الإدارة إلى المنفذ ولن يكون لديه إيثر إضافي في يده. ولدى المنفذ إيثر إضافي واحد في يده.

△ نتائج تنفيذ مختلفة تحت مختلف الظروف. مصدر الصورة:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

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

لماذا يحتاج SUAVE إلى سلسلة خاصة به؟

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

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

بالإضافة إلى ذلك، نظرًا لأن SUAVE يحتاج إلى الحصول على معلومات من سلاسل أخرى للتحقق مما إذا كانت الأفضلية مُرضية، يمكن لسلسلة SUAVE المستقلة الحفاظ على الحيادية من خلال جمع المعلومات من جميع السلاسل الأخرى.

ومع ذلك، يحتوي SUAVE على سلسلة خاصة به، مما يعني أيضًا أن (1) قد يحتاج مستخدم SUAVE إلى نقل الأصول من سلاسل أخرى إلى سلسلة SUAVE لاستخدام SUAVE، و (2) يحتاج SUAVE إلى الاعتماد على Oracle للإبلاغ عن المعلومات من سلاسل أخرى. يعني هذا أن SUAVE نفسه لديه متطلب إضافي للثقة في Oracle. إذا كان Oracle غير آمن، فسيؤثر ذلك على أمان العقد على SUAVE.

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

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

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

ملخص تحديات سواف

• وقت كتلة سلسلة SUAVE: يجب أن يكون وقت كتلة سلسلة SUAVE كافيًا قصيرًا بحيث يمكن لمستخدم SUAVE الإعلان عن تفضيله للمنفذ ليراه. إذا كان وقت سلسلة SUAVE أطول من السلسلة التي ترتبط بها (مثل Solana أو Rollup الأخرى) ، فمن السهل على مستخدم SUAVE عدم الحصول على الوقت الكافي لإبلاغ Executor SUAVE بأنه يرغب في تضمين الصفقة في الكتلة التالية لسلسلة معينة. تم إنتاج كتلة.
• مخاطر الأوراق المالية: يتحمل الأوراق المالية مسؤولية توفير المعلومات حول سلاسل أخرى، وقد يكون مسؤولًا أيضًا عن تحويل أصول مستخدمي SUAVE إلى سلسلة SUAVE، لذا فإن أهمية الأوراق المالية ليست أمرًا بسيطًا.
• تجربة استخدام السلسلة العابرة: يحتاج المستخدم إلى نقل الأصول إلى سلسلة SUAVE وهو أيضًا نقص في تجربة الاستخدام.
• النموذج الاقتصادي: هل تحتاج سوافي إلى إصدار أصولها الخاصة، كيفية تحفيز مُحققي سوافي، كيفية منع آلية التحفيز الاقتصادي لسوافي من التأثير على أمان السلاسل الاقتصادية الأخرى، إلخ.
• تكنولوجيا الخصوصية: في المدى القصير، سيضطر SUAVE إلى الاعتماد على الأجهزة الموثوقة مثل SGX لتوفير وظائف الخصوصية في المعاملات، ولكن في المدى الطويل سيتعين عليه التحول إلى نهج أكثر لفتا وأمانًا لتقليل المخاطر.
• لغة التفضيل المناسبة: هل EVM مناسب كوسيلة للتعبير عن التفضيلات وتنفيذها؟

ملخص وأبرز النقاط

• ظهور SUAVE هو (1) لمعالجة مخاطر التمركز الناجمة عن الفرق في المزايا للبناة التي يمكن أن تنتج من Cross Domain MEV، و (2) فتح الباب للتعاون بين الباحثين / البناة من خلال إدخال الخصوصية القابلة للبرمجة، مما يقلل من مخاطر التمركز التي قد تنشأ من Private Order Flow.
• تجعل المعاملات الخاصة بالكامل عمل الباحثين صعبًا، حيث لا يمكنهم تنفيذ معاملات المستخدم بشكل فعال، مما يؤدي إلى تقليل كفاءة السلسلة الجانبية. ومع ذلك، لا يجب على المستخدمين الاختيار بين "الخصوصية" و"الكفاءة". بدلاً من ذلك، يمكنهم استخدام الخصوصية القابلة للبرمجة لاختيار الكشف عن معلومات جزئية، مما يجعل عمل الباحثين أسهل ويحسن من كفاءة السلسلة الجانبية ومكافآت العمل السابق.
• مع SUAVE، يمكن لمستخدمي SUAVE تحديد نواياهم / تفضيلات معاملاتهم وظروف مختلفة، بينما يتم التعامل مع البقية من قبل الوصيون المحترفين لتحقيق الشروط والمطالبة بالمكافآت التي وعد بها مستخدمو SUAVE عند الوفاء.
• سوف تمتلك SUAVE سلسلتها الخاصة لأن P2P النقي لا يمكنه منع هجمات DoS، وسوف تحتوي SUAVE على ميزاتها وإعداداتها الفريدة الخاصة بالسلسلة (MEV)، لذا لا يمكن استخدام السلاسل الحالية مباشرة. ستعتمد هذه السلسلة على تعديل EVM، مضيفة الوظائف اللازمة ل MEV، والتي تسمى MEVM.
• يعتبر MEV عبر السلسلة الجانبية عملية تحدٍ كبيرة للغاية، حيث يتطلب ضمان الإدراج الذري وضمان "تنفيذ ناجح" للمعاملات. يمكن لمستخدمي SUAVE تحديد الحالات التي تتطلب أن تتم تنفيذ المعاملات بنجاح قبل مكافأة الجهة المنفذة، مما ينقل المخاطرة إلى الجهة المنفذة. يمكن للسيكونسر المشترك ضمان الإدراج الذري ولكنه لا يضمن أن تتم تنفيذ المعاملات "بنجاح".
• كون SUAVE سلسلتها الخاصة يعني أن مستخدمي SUAVE يحتاجون إلى تحويل الأصول إلى سلسلة SUAVE قبل أن يتمكنوا من استخدام SUAVE. علاوة على ذلك، يجب توفير Oracle آمن للإبلاغ عن المعلومات من سلاسل أخرى إلى سلسلة SUAVE للتحقق مما إذا كانت تتم مطابقة الأولويات.
• ما زالت SUAVE تواجه العديد من التحديات التقنية والتصميمية، مثل Oracle الآمن، وتقنيات الخصوصية الآمنة، ولغة التفضيل، والنماذج الاقتصادية، وغيرها.

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

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