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

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

مقدمة

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

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

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

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

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

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

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

التحضير

التعريف

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

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

1. جهاز التسلسل المشترك/المنشئ الفائق: يعمل بشكل أساسي على تحسين السرعة وتجربة المستخدم.

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

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

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

مثال:

1. نقل الرمز المميز نفسه
   → أرسل إلى نفسك: استبدل Eth إلى Eth أو ERC-20 إلى ERC-20 بين مجموعتين مجمعتين

2. شراء الرمز المميز
   ← أمر حد مجموعة البيانات المجمعة: استخدم Eth/ERC-20 في مجموعة التحديثات أ، وقم بشراء ERC-20 مختلف من DEX في مجموعة التحديثات ب، و(اختياري)) أرسل مرة أخرى إلى مجموعة التحديثات أ

المعنى:

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

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

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

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

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

نظرة عامة عالية المستوى

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

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

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

غير قابل للتطبيق

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

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

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

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

تجدر الإشارة إلى أن حلول الجهات الخارجية موجودة حاليًا:

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

2. إطار النوايا

يتطلب كلا المثالين لدينا حلولاً من جهات خارجية للمساعدة.

أرسل لنفسك:

1. الممارسة القياسية:
   → سحب الأصول من المجموعة "أ"
   → الإيداع يدويًا في المجموعة "ب"

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

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

1. المواصفات:
   → سحب الأصول من المجموعة A
   → الإيداع يدويًا في المجموعة B
   → تنفيذ أمر الحد
   →للإرسال مرة أخرى، يجب أن يكون هدف ERC-20 مغلفًا خارجيًا

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

نظرًا لأن هذا هو الإعداد الافتراضي، فهو موجود لا داعي لمناقشة التغييرات في UX وDevEx وMEV وRollup.

2. التضمين الذري

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

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

يضمن التضمين الذري فقط تضمين الحزمة المتراكمة في المجموعة التالية.

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

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

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

فكر في إطلاق تبادل بسيط للملخصات الشاملة مع ضمانات التضمين الذري فقط:

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

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

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

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

3 التسوية

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

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

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

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

p>

نرى أن كل مجموعة تراكمية ستكون غير متزامنة مع عقد الجسر على الشبكة الرئيسية. لا يزال عقد الجسر B المجمع يحتوي على 50 إيثريوم، لذا لا يمكن للمستخدم سحب 1 إيثريوم إلى L1.

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

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

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

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

أرسل لنفسك:

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

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

3. يرسل التتابع المعاملة إلى دار سك العملة وإثبات Merkle إلى المجموعة B

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

5. عمليات سك المستخدم على Rollup B Eth

   < /li>

6. يرسل التحديث B الدليل إلى L1

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

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

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

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

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

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

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

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

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

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

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

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

Shared Sorter // Super Builder

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

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

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

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

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

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

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

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



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

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

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

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

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

3. باحثو MEV:< br>تعد المراجحة المجمعة المتقاطعة أكثر أمانًا بالنظر إلى الذرية التنفيذ

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

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

5.قابلية التركيب على مستوى الكتلة

البنية الأساسية المطلوبة:

الفرز المشترك // الإنشاء الفائق // طبقة تجميع الإثبات* // عقد الجسر المشترك*

(* = اختياري)

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

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

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

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

هناك حالتان يجب أخذهما في الاعتبار:

1. قابلية التركيب على مستوى الكتلة

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

   < /li>

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

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

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

1. < p style="text-align: left;">المستخدمون يمتلكون ERC-20

2. يقوم المستخدمون بإنشاء tx من خلال dapp:< br> → قم بإيداع ERC-20 في صندوق قفل xERC-20 لتلقي الإصدار المغلف xERC-20
   →تدمير xERC-20
   →أرسل رسالة إلى البنية التحتية للطلب المشترك تشير إلى بدء النقل المتراكم، وإرفاق البيانات ذات الصلة لتسهيل التبادل

3. يلتقط Superbuilder المعاملة وينشئ حزمة مجمعة متقاطعة
   → Tx 1: الحزمة أعلاه ومعاملة النسخ
   → Tx 2: سك xERC-20 في مجموعة التحديثات B

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

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

6. تم إصدار xERC-20 للمستخدمين في المجموعة B

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

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

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

1. لف وتدمير ERC-20 على A

2. Mint xERC-20 على B

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

4. لف وتدمير الهدف ERC-20 على B

5. A Mint xERC-20

   p>

إليك سير العمل المحتمل:





التدفق:

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

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

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

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

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

ثق بشكل متفائل في جهاز التسلسل

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

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

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

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

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

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

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

4. المجموعات المجمعة
   يتطلب الاشتراك في البنية الأساسية للفرز المشترك (بما في ذلك Super Builder) ، ويسمح بالوصول إلى تدمير/سك العملة في أمر مشترك في حالة طبقة التسوية المشتركة.
   → يمكن استيعاب MEV من خلال بيع مساحة الكتلة للمنشئين

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

< h2 style="text-align: left;">البنية التحتية المطلوبة:

تغيير مستوى VM // التسوية المشتركة // البناء الفائق

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

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

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

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

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

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

   
   تجربة المطور هي تم تحسينها بشكل كبير → لا يزال يتعين وضع معاملات الأشعة تحت الحمراء لـ Superbuilder/Sequencer في كتلة المجموعة المتأثرة باستدعاء التجميع المتقاطع، ولكن ليس من الضروري إنشاء نفس الحزمة كما هو الحال مع قابلية التركيب على مستوى الكتلة.

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

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

< h2 style=" text-align: left;">الملخص ومخطط النظام البيئي

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

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

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

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

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

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



الاستنتاج

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

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

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

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

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