قابلية التشغيل البيني غير الموثوق بين Rollups: نظرة عامة ، والبناء ، والتحديات

المؤلف: مارشال فيليتل جونيور المصدر:1KX الترجمة: شان أوبا ، رؤية Baitchain

يقدم

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

1. غالبًا ما تكون جسور السيولة هي الهدف من أكبر هجمات قراصنة العملة المشفرة (مثل هجوم قراصنة الجسر البالغ 321 مليون دولار)

2. أصول التغليف الخارجية ليست شائعة ، وتظهر البيانات أن الأشخاص أكثر استعدادًا للاحتفاظ بالأصول في شكل أصلي كلما كان ذلك ممكنًا (على سبيل المثال ، وفقًا لبيانات L2Beat ، تبلغ قيمة أصول جسر المواصفات 22 مليار دولار ، في حين أن أصول التغليف الخارجية تبلغ 30 ٪ فقط 100 مليون دولار)

3. يعتمد إطار النية على الأطراف الثالثة التي تتطلب بعض الثقة التي لا يمكن تجاهلها وشحن الرسوم الإضافية لتسهيل أنشطة اللولوب المتقاطع (على سبيل المثال ، يفقد مستخدمو سلسلة Degen أكثر من 80 ٪ من الرموز المميزة بسبب مخالفات الجسر الرسمية).يعني إطار النية المركزية أيضًا انخفاض المنافسة ، مما قد يؤدي إلى ضعف التسعير والأداء

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

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

يناقش هذا المقال بشكل أساسي Ethereum و L2 ، ويركز فقط على قابلية التشغيل البيني غير الموثوق بها.في هذه الحالة ، يشير “قابلية التشغيل البيني غير الموثوق” إلى قنوات البروتكول ، والتي لا تتطلب طرفًا ثالثًا لتسهيل الإرسال خارج البنية التحتية اللازمة التي تتطلبها معظمها بالفعل.

تحضير

تعريف

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

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

1. Serializer/Super Builder: يحسن السرعة وتجربة المستخدم بشكل أساسي.

2. التسوية المشتركة: لا حاجة للالتفاف الخارجي والرسائل داخل البروتوكول.

أولاً ، سنحدد المستويات الستة غير الموثوقة من قابلية التشغيل البيني المذكورة في المقدمة:

1. L1 غير متزامن:
   → نقل الأصول اليدوي من خلال تسوية موجزة L1 لتحقيق قابلية التشغيل البيني.

2. الذرات تحتوي على:
   → تأكد من إدراج جميع المعاملات عبر حزمة Rollup في الكتلة التالية من كل رولوب تشارك في تلك الحزمة ، أو غير مدرجة.

3. التسوية المشتركة:
   → يتم توصيل Rollups المتعددة بـ L1 من خلال عقد الجسر نفسه.

4. التنفيذ الذري:
   → تأكد من إدراج جميع المعاملات عبر حزمة Rollup في الكتلة التالية من كل رولوب متورط في الحزمة وتنفيذها بنجاح ، وإلا فلن يتم تنفيذ أي معاملات.التنفيذ الناجح يعني أن كل معاملة يتم تنفيذها دون تراجع وينعكس في الحالة المحدثة لكل رولوب في الحزمة.

5. إمكانية التكلفة على مستوى الكتلة:
   → تضمن الكتلة التالية عبر حزمة Rollup أنها يمكن أن تحتوي على معاملات تابعة (TX B على Rollup B تعتمد على نتيجة TX A ON Rollup A)

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

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

مثال:

1. نقل الرمز نفسه
   → أرسل إلى نفسك: استرداد ETH إلى ETH بين اثنين من rollup ، أو تبادل ERC-20 إلى ERC-20

2. شراء الرمز المميز
   → ترتيب الحد المتقاطع لفة: استخدم ETH/ERC-20 في Rollup A لشراء ERC-20 مختلفًا من DEX على Rollup B و (اختياريًا) إرسال مرة أخرى إلى Rollup

معنى:

سنجيب أيضًا على الأسئلة التالية لزيادة فهم التأثير على المساهمين الرئيسيين في أي نظام بيئي مجمعة.

1. تجربة المستخدم
   كيف ستتغير تجربة المستخدم من خلال تحقيق هذا المستوى من قابلية التشغيل البيني؟

2. تجربة المطور
   كيف سيتغير المطور عن طريق تحقيق هذا المستوى من قابلية التشغيل البيني؟

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

4. تأثير Rollup
   هل يتعين على Rollup اختيار أي بنية تحتية جديدة لتحقيق ذلك؟ما هي التغييرات التي تم إجراؤها في هيكل رسوم Rollup؟ما هي الفوائد المحتملة لمشاركة رولوب في هذه البنية التحتية؟

نظرة عامة متقدمة

ست مراحل من قابلية التشغيل البيني غير الموثوق بها

1. L1 غير متزامن

البنية التحتية المطلوبة:

لا ينطبق

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

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

من أجل التفاؤل ، بالنظر إلى نافذة مقاومة للأخطاء ، يكون تأخير الانسحاب حوالي 7 أيام.في ZK Rollup ، ليس تأخير الانسحاب مؤكدًا تمامًا ، ولكن قد يكون ذلك بين 15 دقيقة ويوم كامل ، وهذا هو الحال مع Zksync.

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

تجدر الإشارة إلى أن هناك حاليًا حلول الطرف الثالث:

1. جسر السيولة

2. إطار نوايا

كل من الأمثلة لدينا تتطلب حلول الطرف الثالث للمساعدة.

أرسل إلى نفسك:

1. الممارسات الموحدة:
   → استخراج الأصول من Rollup
   → حفظ يدويًا Rollup B

2. طرف ثالث:
   → شبكة السيولة / شبكة حلال

أوامر الحد المتبادل

1. مواصفة:
   → استخراج الأصول من Rollup
   → حفظ يدويًا Rollup B
   → تنفيذ أوامر الحد
   → للعودة ، يجب تعبئة ERC-20 المستهدفة خارجيًا

2. طرف ثالث
   → مساحة الحلول الناشئة عبر أوامر الحد المجمعة
   → هناك تصميمات مفتوحة تعزز هذا حول نية الاستخدام

نظرًا لأن هذا هو الافتراضي ، فليس هناك حاجة لمناقشة التغييرات في UX و DeVex و MEV والملخص.

2. الذرية تحتوي على

البنية التحتية المطلوبة

المسلسل المشترك *

لا يضمن التضمين الذري إلا أن يتم تضمين حزمة التصريف في الكتلة التالية.

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

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

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

فكر في بدء تبادل بسيط متقاطع مع ضمانات التضمين الذرية فقط:

1. حزم مبادلة عبر Rollup
   → تكساس 1: قفل/تدمير الرموز على رولوب المصدر
   → TX 2: Mint الرمز المميز لعنوان المستخدم على الهدف

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

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

هام: لن يكون للتضمين الذري تأثير كبير على إمكانية التشغيل البيني

3. تسوية مشتركة

البنية التحتية المطلوبة:

طبقة التجميع دليل // عقد الجسر المشترك

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

لماذا تأسيس عقد جسر مشترك؟لفهم لماذا يتيح لنا عقد الجسر المشترك نقل الأصول عبر Rollup بطريقة غير موثوق بها ، فأخذ أولاً ما إذا كان بإمكانك الحصول على ETH في Rollup A ، وتدميره ، ثم النعناع أصلاً على Rollup B دون البناء على عقد الجسر المشترك Layer1 ، ما يحدث .

نرى أن كل رولوب غير متزامن مع عقد الجسر على mainnet.لا يزال عقد Rollup B Bridge يحتوي على 50 ETH ، لذلك لا يمكن للمستخدم استخراج 1 من ETHS إلى L1.

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

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

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

باستخدام طبقة الفواتير المشتركة ، قد تبدو العملية ما يلي للإرسال البسيط إلى نفسك.

أرسل إلى نفسك:

1. يقوم المستخدم بإنشاء معاملة أولية:
   → تكساس 1: استخراج ETH على Rollup A (ويلقي على Rollup B)
   → يتم تقديم المعاملة على دفعات وتقديمها إلى عقد L1
   → يتم تجميعها في جذر المعاملة ، والتي تجمع جميع عمليات التسوية المشتركة

2. Rollup B يستورد هذا الجذر للمعاملة

3. يقدم مكرر المعاملة إلى النعناع ويقدم شهادة Merkle إلى Rollup B.

4. يستخدم Rollup B إثبات Merkle وجذر المعاملة للتحقق من تدمير المعاملات

5. يلقي المستخدم ETH على Rollup B

6. يقدم Rollup B دليلًا على L1

يمكننا تمديد هذه العملية إلى أي ERC-20 لها عقود في جميع المجاميع في النظام البيئي للتسوية المشتركة.

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

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

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

التأثير على أصحاب المصلحة:

1. مستخدم:
   يمكن الآن نقل الأصول في شكل أصلي دون الحاجة إلى فترة سحب L1

2. المطور:
   تقتصر التغييرات على المصدرين الرمزيين الذين يمكنهم الآن إصدار إصدارات أصلية من ERC-20 على جميع الأدوات المتصلة باستخدام المراسلة داخل البروتوكول

3. باحث MEV:
   نظرًا لأن هذا يحدث على كتل متعددة لكل Rollup ، فلا توجد إمكانات جديدة MEV

4. rollups:
   يجب أن تختار Rollups استخدام عقد جسر مشترك وقد يضيف مسبقًا للتعامل مع رسائل Rollup

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

4. التنفيذ الذري

البنية التحتية المطلوبة:

شارك في سوبر باني

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

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

هذه الحزمة غير ممكنة بدون طرف وسيط (مثل Super Builder) يمكن أن تنشئ معاملة مستهدفة.

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

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

2. قم بإنشاء معاملة ثانية على Rollup المستهدف إلى Mint:
   → لا يمكن للمستخدمين إنشاء هذا tx بأنفسهم لأنهم لا يملكون حقوق الرموز على الرموز على Rollup B.
   → على سبيل المثال) تحتاج السلسلة المستهدفة إلى إثبات أن الرمز قد تم حرقه/قفله على سلسلة المصدر ، ولكن هذا الدليل غير متوفر حتى يتم تنفيذ المعاملة الأولية ، مما سيدمر متطلباتنا للذرة.→ من الناحية النظرية ، أي علبة أخرى
   يمكن للحزب الذي ينشئ معاملة ثانية مع حقوق الصب إنشاء معاملة “مصبوب” على السلسلة المستهدفة في أي وقت دون إنشاء “حرق” أو قفل على سلسلة المصدر ، وهو ثغرة أمنية كبيرة.

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

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

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

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

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

التأثير على أصحاب المصلحة:

1. مستخدم:
   قد لا تكون هناك أي تغييرات ، على الرغم من أن الأطراف الثالثة قد تقدم حلولًا مثل النية ، فمن غير الواضح كيفية تنفيذها

2. المطور:
   ربما لا يتغير

3. باحث MEV:
   التحكيم المتقاطع هو أكثر أمانًا بالنظر إلى التنفيذ الذري

4. رولب:
   يجب أن تختار Rollup استخدام SARTER/Super Builder المشترك لتقديم كتلة تحتوي على معاملات من كل مجموعة ترغب في التبادل معها ، مما قد يغير هيكل الإيرادات من Rollup.ليس من الواضح كيف سيتغير.-
   قد يزيد سوق الفرز من إيرادات Rollup من خلال السماح للبنائين الناضجين بشراء مساحة TOB

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

5. التكلفة على مستوى الكتلة

البنية التحتية المطلوبة:

sorter المشتركة // Super Builder // Proof Aggregation Layer * // CHERSION BRIDGE CONTRY *

(* = اختياري)

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

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

في هذا المستوى ، نبدأ في رؤية القدرة الحقيقية بين Rollups ، وليس مجرد إرسالها إلى نفسك للمشاركة في DAPP على Rollup آخر.

من خلال إضافة جهاز تسلسل مشترك يمكنه إنشاء معاملات ، يمكننا الآن إنشاء حزمة ملخص SPAN يمكن للمطورين الاستفادة برمجيًا.

هناك حالتان يجب مراعاتهما:

1. إمكانية التكلفة على مستوى الكتلة

2. إمكانية تكوين مستوى الكتلة + طبقة تسوية مشتركة

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

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

نقل الرمز نفسه عبر XERC-20 (لا تسوية مشتركة):

1. يمتلك المستخدم ERC-20

2. يقوم المستخدمون بإنشاء TX من خلال DAPP:
   → حفظ ERC-20 في مربع قفل XERC-20 لتلقي نسخة XERC-20 المعبأة
   → تدمير XERC-20
   → أرسل رسالة إلى البنية التحتية للفرز المشترك تشير إلى أن نقل نقل المتقاطع قد تم بدء تشغيل البيانات ذات الصلة لتسهيل التبادل

3. يلتقط Superbuilder المعاملات ويخلق حزمًا متقاطعة
   → تكساس 1: معاملات التغليف والتدمير أعلاه
   → تكساس 2: CAST XERC-20 على Rollup B

4. يقدم Superbuilder هذا التقاطع إلى الفارز المشترك
   → نظرًا لأن Superbuilder تعمل على تشغيل عقدتين كاملتين متصلتين بـ Rollups ، فإنها تحاكي المعاملات لضمان تنفيذ الحزمة بنجاح.إذا تم التراجع عن أي معاملة ، فسيتم التراجع عن الحزمة بأكملها.

5. يقدم الفارز المشترك الكتلة التي تحتوي على معاملتين لطبقة DA والعقدة التي تؤدي تغيير الحالة

6. XERC-20 يلقي للمستخدمين على Rollup B

مع طبقة التسوية المشتركة ، يتم تبسيط العملية بشكل أكبر لأنه لا توجد حاجة إلى حزمة ERC-20 أولاً كـ XERC-20 للتبادل.

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

فيما يلي المعاملات المطلوبة في هذه الحالة:

1. حزمة وتدمير ERC-20 على

2. Mint XERC-20 على ب

3. تبادل XERC-20 الأولي مع الهدف ERC-20 على ب

4. حزمة وتدمير الهدف ERC-20 على ب

5. Mint XERC-20 على

فيما يلي سير العمل الممكنة:

تدفق:

1. يبدأ المستخدم الصفقة الأولى:
   → حزمة وتدمير XERC-20 وأرسل رسالة لتحديد معلمات التبادل (السلسلة المستهدفة ، عنوان DEX ، ERC-20 ليتم تبادلها ، الحد من سعر الطلب ، القيمة المنطقية ما إذا كان سيتم إرسالها)

2. يرى Super Builder الصفقة ويخلق الحزمة:
   → تكساس 1: يقوم المستخدم بإنشاء المعاملة أعلاه
   → TX 2: Cast XERC-20 في الوجهة (يجب أن يكون لدى Super Builders أذونات صب)
   → تكساس 3: استخدم البيانات من TX 1 لتنفيذ أوامر الحد
   → تكساس 4: حزمة وتدمير ERC-20 على B ، على افتراض أن ترتيب الحد قد تم الوفاء به بالكامل وإرسال رسالة على سلسلة المصدر للصب
   → تكساس 5: الهدف الهدف XERC-20 من إخراج التبادل على سلسلة المصدر

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

في حالة عدم وجود بنية تحتية للفرز المشترك لطبقة التسوية المشتركة ، يلزم وجود إصدارات التغليف الخارجية من ETH و XERC-20 ، مما قد يتسبب في تفاقم ظروف السوق لـ DEX عندما يصبح مجموعة السيولة لأصول التغليف أرق.في هذه الحالة ، قد يضطر المستخدمون إلى استخدام قيود أكثر وضوحًا ، وارتفاع التسامح في الانزلاق ، وقد يحصلون على أسعار دون المستوى الأمثل.إذا كان USDC متورطًا ، فهناك استثناء واحد.قد يعمل سفر مشترك بدون فواتير مشتركة مع Circle لاكتساب حقوق حصرية لعقود USDC عبر Rollups لتسهيل عمليات نقل وتبادلات USDC الأصلية عبر Rollups.

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

الثقة بتفاؤل في التسلسل

يتطلب Rollup ثقة متفائلة في Sorters/Super Builders المشتركة لإنشاء حزم فعالة لتجميع.ويرجع ذلك أساسًا إلى أن حزمة Rollup المتقاطعة تحتوي على معاملات تابعة لا يمكن للتحقق من عمليات التدحرج الفردية حتى تتم إضافة الكتل إلى كل سلسلة متداولة وتجميعها إلى طبقة التسوية على L1.مثال على ذلك هو التدمير الأولي وصب ETH من المصدر إلى الوجهة.بشكل حاسم ، يجب تدمير ETH فعليًا على سلسلة المصدر قبل الانتقال على السلسلة المستهدفة ، وإلا فقد تحدث المدفوعات المزدوجة.

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

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

التأثير على أصحاب المصلحة:

1. مستخدم
   ترقيات ضخمة لتجربة المستخدم ، مما يسمح بطلبات الحد المتقاطع في كتلة واحدة

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

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

4. Rollups
   يتطلب الاشتراك في البنية التحتية للفرز المشترك (بما في ذلك بناة سوبر) ويسمح بالوصول إلى تدمير/صب ETH في الفارق المشترك في حالة طبقة الفوترة المشتركة.
   → يمكن استيعاب MEV عن طريق بيع مساحة الكتلة للبناة

6. قابلية التكلفة على مستوى المعاملة

البنية التحتية المطلوبة:

تغيير مستوى VM // تسوية مشتركة // Super Builder

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

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

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

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

التأثير على أصحاب المصلحة

1. مستخدم:
   نفس المعنى مثل إمكانية تأليف مستوى الكتلة ولديه ميزات متقدمة أخرى مثل Lightning Loan
   → UX يستخدم نفس السلسلة تقريبا مثل الاشتراك في dapp

2. المطور: بما أن مطوري DAPP يمكنهم استدعاء العقد المتقاطع محليًا واستخدام إخراج هذه المكالمات (مثل المكالمات الموجزة الفردية) ،
   يواجه المطور بشكل كبير
   التحسين → لا يزال يتعين على Superbuilder/Sequencer Infra وضع معاملات في كتلة ملخص تتأثر بدعوة التحكم المتقاطعة ، ولكن ليس من الضروري بناء نفس الحزمة مثل التكلفة على مستوى الكتلة.

3. باحث MEV:
   حزم الرول المتقاطعة الآن تعادل بشكل أساسي معاملة واحدة على سلسلة ، وبالتالي فإن إمكانات MEV عالية

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

خريطة التجريد والنظام الإيكولوجي

بعد فهم التفاصيل الفنية لكل مستوى قابلية التشغيل البيني المحددة هنا ، يمكننا تلخيص:

1. يتيح الفواتير المشتركة التبادل عبر الأدوات المفروضة بدون أصول التفاف الخارج

2. يتيح فرز/بناة Superiilders المشتركة ضمانات تنفيذ الكتلة التالية على حزم Rollup المتقاطعة

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

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

حاليًا ، تظهر العديد من المشاريع لإنشاء هذه النظم الإيكولوجية المحلية القابلة للتشغيل البيني.فيما يلي نظرة عامة رفيعة المستوى على الحقل:

خريطة النظام البيئي

خاتمة

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

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

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

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

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