مقدمة

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

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

في هذا المقال، نقوم بمسح منظر التوافقية عديم الثقة عن طريق تحديد ومناقشة ستة مستويات من حلول التوافقية بين نظم ال rollup المتشظية.

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

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

التمهيدات

تعريفات

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

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

1. مشاركة المتسلسلين/البناة الفائقين: ترقيات أساسية في السرعة وتجربة المستخدم بشكل أساسي.
2. التسوية المشتركة: تبادل الأصول دون تغليف خارجي بالإضافة إلى رسائل داخل بروتوكولية.

لبدء، سنقوم أولاً بتحديد الستة مستويات من عدم الثقة المتوافقية التي ألمح إليها في المقدمة:

1. L1 Async:
   → التوافقية عن طريق نقل الأصول يدويًا من خلال L1 التي يتم تسويتها بواسطة rollups.
2. الإدماج الذري:
   → ضمان بأن جميع المعاملات في حزمة cross-rollup ستتم إدراجها في الكتلة التالية لكل rollup مشارك في الحزمة، أو لن تتم إدراج أيًا منها.
3. التسوية المشتركة:
   → العديد من الروابط المتصلة بالطبقة 1 عبر نفس عقد الجسر.
4. التنفيذ الذري:
   ضمان بأن جميع المعاملات في حزمة cross-rollup ستُدرج وتُنفذ بنجاح في الكتلة التالية لكل rollup مشارك في الحزمة، أو لن تُنفذ أي منها. يُشير التنفيذ الناجح إلى تنفيذ كل معاملة دون عكس وتعكسها في الحالة المحدثة لكل rollup في الحزمة.
5. تكامل على مستوى الكتلة:
   → الكتلة التالية تضمنات على حزم العمليات العابرة للرولاب التي يمكن أن تحتوي على معاملات معتمدة (المعاملة ب على الرولاب ب تعتمد على نتيجة المعاملة أ على الرولاب أ)
6. مستوى القابلية للتركيب على مستوى Tx:
   مستوى التوافقية على مستوى العقد الذكي الذي يتطلب معاملة واحدة فقط يمكن أن تتسبب في تغيير حالة عبر العديد من rollups في وقت واحد (بدون حزم). استخدام أي بروتوكول عبر أي rollup مكافئ بشكل منطقي لاستخدام عقود ذكية مختلفة على سلسلة واحدة. ومن الأهمية بمكان أن هذا يعني أن تغييرات الحالة قبل أي استدعاء يمكن إلغاؤها عند عودتها.

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

أمثلة توضيحية:

1. نقل نفس الرمز
   → إرسال إلى الذات: تبديل الإثيريوم بالإثيريوم أو ERC-20 بـ ERC-20 عبر لفتين
2. شراء الرمز
   → النظام الأمر المحدود عبر البول اب: باستخدام Eth/ERC-20 من البول اب A، قم بشراء ERC-20 مختلفة من DEX على البول اب B و (اختياريًا) إرسالها مرة أخرى إلى البول اب A

المضاعفات:

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

1. تجربة المستخدم
   كيف تتغير تجربة المستخدم من خلال تحقيق هذا المستوى من التوافقية؟
2. تجربة المطور
   كيف يتغير تجربة المطور من خلال تحقيق هذا المستوى من التوافقية؟
3. إمكانية MEV
   هل هناك إمكانية لفرص MEV الجديدة إذا تحققنا هذا المستوى من التوافقية؟
4. تداعيات Rollup
   هل يجب على الرول اب الاشتراك في أي بنية تحتية جديدة لتحقيق هذا؟ ما هي التغييرات في هياكل الرسوم للرول اب؟ ما قد تكون الفوائد المحتملة للرول اب للمشاركة في هذه البنية التحتية؟

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

نظرة عامة على التغييرات لأصحاب المصلحة الرئيسيين

التقدم الستيبي نحو عديم الثقة التوافقية

1. L1 Async

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

غير متاح

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

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

بالنسبة للتجميعات التفاؤلية، فإن وقت سحب هذه العملة يبلغ حوالي 7 أيام للحسومات في النافذة. في تجميع ZK، فإن وقت سحب العملة غير مؤكد بشكل أقل ولكن يمكن أن يكون في أي مكان من 15 دقيقة إلى يوم كامل، كما هو الحال مع ZkSync.

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

يجدر بالذكر الحلول من الطرف الثالث الموجودة حاليا:

1. جسور السيولة
2. أطر النية

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

الإرسال إلى الذات:

1. بشكل كنسي
   سحب الأصول من Rollup A
   → الإيداع يدويًا في Rollup B
2. طرف ثالث:
   → جسر السيولة / شبكات الحل

النظام المحدد عبر الطبقات

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

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

2. الإدراج الذري

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

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

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

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

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

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

النظر في ببدء تبادل بسيط للرول أب مع ضمانات الاندماج الذري فقط:

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

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

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

أهم نقطة: لا يؤثر Inclusion الذري بشكل ملموس على القدرة على التوافقية

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

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

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

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

لماذا نبني عقد جسر مشترك؟ لفهم السبب في أن وجود عقد جسر مشترك يسمح لنا بنقل الأصول دون ثقة عبر عمليات التجميع ، فكر أولا في ما سيحدث إذا كان من الممكن الحصول على Eth في Rollup A ، وحرقه ، وسكه أصلا على Rollup B بدون عقد جسر مشترك على L1.

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

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

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

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

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

إرسال للذات:

1. المستخدم يقوم بإنشاء المعاملة الأولية:
   → Tx 1: سحب الإيثر على الرول أب (مع رسالة لتقديمه على الرول أب ب)
   → يتم تجميع الصفقة وتقديمها إلى عقد L1
   → يتم تجميعها في جذر المعاملة الذي يجمع جميع تجميعات التسوية المشتركة
2. الإظهار B يستورد جذر tx هذا
3. يقوم المعاد بتقديم الصفقة للتنقيب مع دليل ميركل للتراكم B
4. يتحقق Rollup B من صفقة الحرق باستخدام دليل Merkle وجذر الصفقة
5. المستخدم يتم توليد Eth على Rollup B
6. يقدم Rollup B دليلًا إلى L1

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

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

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

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

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

1. المستخدمين:
   يمكن الآن نقل الأصول بشكل أصلي دون فترة سحب L1
2. المطورين:
   التغييرات مقتصرة على مرسلي الرموز الذين يمكنهم الآن استخدام الرسائل في البروتوكول لإصدار الإصدارات الأصلية من ERC-20 عبر جميع الـ rollups المتصلة
3. باحثو MEV:
   لأن هذا يحدث عبر عدة كتل لكل رول أب، لا يوجد إمكانية MEV جديدة
4. Rollups:
   سيتعين على الرول‌أبس الاختيار في استخدام عقد جسر مشترك وعلى الأرجح إضافة مسبقة للتعامل مع رسائل الانتقال عبر الرول‌أب

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

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

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

السيكونسر المشترك // البناة الخارقون

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

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

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

انظر إلى ما يجب أن يكون صحيحًا لبناء حزم تبادل عبر cross-rollup دون حاجة إلى طرف آخر بخلاف المستخدم. يجب إنشاء حزمة لقفل/حرق الأصل على cross-rollup المصدر وصك الأصل على cross-rollup الوجهة، ولكن نواجه مشكلات:

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

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

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

التحكيم عبر Cross-Rollup DEX مع التنفيذ الذري

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

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

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

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

1. المستخدمون:
   ربما لا تتغير، على الرغم من احتمالية أن تكون الحلول التي يسهلها طرف ثالث مثل النوايا ذات طابع ذري، ولكن الكيفية بالضبط غير واضحة
2. المطورين:
   ربما لا تغيير
3. باحثو MEV:
   التحكم المتقاطع في التحكم أكثر أمانًا نظرًا للتنفيذ الذري
4. Rollups:
   يجب على Rollups الاختيار في استخدام مسلسل مشترك / مصممون متفوقون يقدمون كتلًا مع معاملات من كل Rollup يرغب في التوافق، والتي قد تغير هيكل الإيرادات للRollup. لم يتضح حتى الآن كيف سيتغير ذلك.

• قد تزيد أسواق التسلسل من الإيرادات المتداولة عن طريق السماح للمساحة ToB بأن تُشترى من قبل البنائين المتطورين

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

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

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

مشترك متوالي // بناء فائق // طبقة تجميع البرهان// عقد الجسر المشترك

(* = اختياري)

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

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

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

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

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

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

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

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

Same Token Transfer via xERC-20 (No Shared Settlement):

1. المستخدم لديه ERC-20
2. يقوم المستخدم بإنشاء صفقة عبر التطبيق اللامركزي:
   → الوديعة ERC-20 في صندوق القفل xERC-20 لاستلام الإصدار الملفوف xERC-20
   → حرق xERC-20
   → إرسال رسالة تدل على البنية التسلسلية المشتركة بأن تم بدء تحويل عبر اللفة المشتركة مع البيانات ذات الصلة لتيسير التبادل
3. يقوم Superbuilder بالتقاط المعاملة وإنشاء حزمة عبر رول اب
   → Tx 1: الصفقة المذكورة أعلاه وعملية الحرق
   → Tx 2: إنشاء xERC-20 على rollup B
4. يقدم Superbuilder هذا العبر عن التدوير إلى المسلسل المشترك
   → لأن البناء الفائق يقوم بتشغيل عقد كامل للعقدتين المتصلتين، يحاكيون التحويلات لضمان تنفيذ ناجح للحزمة. إذا كان أي من التحويلات سيتم إلغاؤه، سيتم إلغاء الحزمة بأكملها.
5. يقوم المسلسل المشترك بإرسال الكتلة التي تحتوي على كل من الصفقات إلى طبقة DA وكذلك إلى العقد التنفيذية للتغيير في الحالة
6. يتم ضرب xERC-20 للمستخدم على Rollup B

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

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

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

1. لف وحرق ERC-20 على A
2. العملات المعدنية xERC-20 على B
3. تبديل xERC-20 الابتدائي بERC-20 المستهدف على B
4. قم بلف وحرق ERC-20 المستهدفة على B
5. انشاء xERC-20 على A

هنا تدفق محتمل لكيفية عمل هذا:

النظام المقنن للحد الأقصى للطلبات عبر البلوك في بيئة قابلة للتركيب على مستوى Gate

تدفق:

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

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

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

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

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

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

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

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

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

1. المستخدمين
   ترقيات ضخمة لتجربة المستخدم في السماح بالطلبات المحدودة عبر البلوك الواحد
2. المطورين
   سيحتاج إلى أن يكون على علم بالتبادل عبر اللفات المتقاطعة لنشاط التبادل عبر اللفات المتقاطعة، مستفيدًا على الأرجح من الإعدادات المخصصة المسبقة. بدلاً من المعاملات فقط، يجب على المطورين التفكير في مصطلح الحزم، ولكن من المحتمل أن تقوم مشاريع البناء الفائقة وبنية التراكم المخصصة بتجاهل أغلب تعقيدات المطور.
3. باحثو MEV
   لدى البستانين في البحث عن MEV فرصة ما يعادلة تقريبًا لاستخدام استراتيجيات L1 على حزم الاتصال عبر الرول أب، ولكن يعتمد ذلك على كيفية تنفيذ PBS (الفصل بين المقترح والباني).
   يُعتبر حزم Cross-rollup في الأساس عملية واحدة، لذا يمكن العثور على MEV عن طريق الجبهة أو تضمين هذه الحزم طالما أنها لا تؤثر على الأسعار خارج الحدود المقبولة من التسرب (لأنه في هذه الحالة سيتم استرجاع الحزمة بأكملها وسيفشل محاولات MEV)
4. التجميعات
   سيكون هناك حاجة للاختيار في البنية التسلسلية المشتركة (بما في ذلك المشيدون الفائقون) وكذلك السماح بالوصول إلى حرق / ختم Eth لجهاز تسلسل مشترك في حالة طبقة تسوية مشتركة.
   يمكن أن يتبنى MEV من خلال بيع مساحة الكتلة للبنائين

6. تكامل على مستوى المعاملات

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

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

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

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

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

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

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

1. المستخدمون:
   نفس الآثار كما في التكامل على مستوى الكتل مع إمكانيات متقدمة إضافية مثل القروض الفلاش
   → يكاد تكون تجربة المستخدم مماثلة تمامًا لاستخدام سلسلة واحدة لتطبيقات الويب اللامركزية التي تختار المشاركة فيها
2. مطورين:
   تحسن تجربة المطور بشكل كبير حيث يمكن لمطوري التطبيقات اللامركزية استدعاء العقود بشكل أصلي عبر الرول-أب واستخدام النواتج من هذه الاستدعاءات مثل استدعاءات الرول-أب الواحدة
   → سيتعين لبنية Superbuilder/Sequencer لا تزال وضع الصفقة في الكتل للعمليات الداخل العمليات الداخلية التي تؤثر على الاتصال عبر الكتل، ولكن لن تحتاج إلى بناء حزم مماثلة كما في حالة القابلية للتكامل على مستوى الكتل.
3. باحثو MEV:
   إمكانية MEV العالية حيث أصبحت حزم cross-rollup في الواقع ما يعادل المعاملات الفردية على سلسلة واحدة الآن
4. Rollups:
   سيتطلب تغييرات على مستوى VM، بالإضافة إلى الاختيار في مسجل مشترك وطبقة تسوية مشتركة
   → الافتراضات الإضافية لعدم الثقة المتضمنة في الاضطلاع بالثقة في المداخل والمخرجات للبكرات الأخرى قبل أن يتمكن من التحقق من الحالة عبر الأدلة، ولكن يمكن أن تقلل آليات التقليم من عبء الثقة

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

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

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

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

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

خريطة البيئة

الأفكار إغلاق

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

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

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

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

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

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

الاعترافات

نمت هذه المقالة من مناقشة دائرية متوافقة للتوافق الرائعة التي عقدها 1kx في EthCC. الشكر الخاص يذهب إلى نواه برافيسيك, إيلي ديفيدسون، وتيريلقراءة الإصدارات الأولية لهذا المقال وتقديم التغذية الراجعة، فضلاً عنMarti, mteam, و Bo Duلمزيد من المحادثات حول الموضوع.

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

1. تم نقل هذه المقالة من [مرآةإلى الأمام عنوان العنوان الأصلي 'عديم الثقة التوافق بين اللفات: المشهد، البناء، والتحديات'، كل الحقوق محفوظة للكاتب الأصلي [مارشال فيليتيل جونيور]. إذا كانت هناك اعتراضات على هذا النشر، يرجى الاتصال بـبوابة تعلمالفريق، وسيتولون على التعامل معه بسرعة.

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

3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.