مقدمة

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

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

مشكلة التشتت

تشتت الدولة عبر تراكبات مختلفة يؤدي إلى تجربة مستخدم سيئة، وفاقية رأس المال المخفضة، ونقص القابلية الأصيلة:

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

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

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

التوافقية

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

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

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

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

تحديات التوافقية

تحقيق التوافق الحقيقي بين اللففات ليس مجرد إرسال رسائل هنا وهناك؛ بل يتعلق الأمر بضمان استكمال المعاملات بشكل آمن وسريع. الاعتماد فقط على Ethereum L1 يمكن أن يعني تأخيرًا طويلًا وتكاليف عالية. يمكن أن تجد آليس أموالها على rollup A ولكنها ترغب في شراء رمز متوفر فقط على Rollup B. هناك خياران ممكنان:

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

عندما يتفاعل L2ان بسرعة أعلى من تأخر إيثيريوم (أي قبل أن يقوموا حتى بالتزامن أو تسوية تحولات حالتهم إلى L1)، هناك ثلاث قضايا أساسية يجب على الRollups التعامل معها: الإفصاح، عدم الصحة، وعدم التسوية.

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

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

دعونا نوضح هذه التحديات بمثال: لنفترض أن أليس تمتلك 10 ETH على شبكة Scroll الرئيسية وترغب في تحويلها إلى بوب في Arbitrum. في الواقع، ينبغي على أليس أن تكون قادرة على نقل السيولة بين هاتين السلسلتين بشكل طبيعي بسرعات أسرع من تأخيرات الإيثيريوم. لنفترض أن مثل هذا الحل موجود، حيث يُقدم Arbitrum 10 ETH لأليس في Arbitrum قبل أن يقدم Scroll أي شيء إلى L1، ما الذي يمكن أن يحدث من سوء لـ Arbitrum؟

• التردد: يتردد Scroll من خلال الارتباط بحالة انتقال مختلفة في L1 حيث لا تتم تضمين صفقة أليس، مما يقتنص 10 ETH من Arbitrum (الذي يحتاج إلى إعادة تنظيم ليكون قادرًا على التسوية).
• عدم الصحة: لا تتوافق التمريرة، ولكن الانتقال الحالي الذي احتوى على الصفقة غير صالح، وبالتالي لا يمكن للتمريرة أبدًا تسويتها (أي إثباتها) على L1 وتقديم الأموال لـ Arbitrum. مرة أخرى، يحتاج Arbitrum إلى إعادة تنظيم لتمكين التسوية.
• عدم التسوية: لا يتردد سكرول والانتقال الحالي صحيح، ولكن يخرج مثبتو سكرول المعينون عن الخط وبالتالي لا تحدث أبدًا تسوية. يحتاج Arbitrum إلى إعادة التنظيم مرة أخرى.

من خلال دمج Arbitrum لل 10 ETH المُرسلة من Alice في Scroll قبل أن يُلتزم Scroll على L1 (في حالة التناقض) وقبل تسوية Scroll (في حالة العدم صحة وعدم التسوية)، يتحمل Arbitrum مخاطر في سلسلته تعتمد على الاعتبارات الأمنية لـ Scroll.

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

سيتم حل كل من عدم التسوية والبطلان بشكل تافه بمجرد أن يصبح التوليد في الوقت الفعلي لإثبات zk عمليا (المعروف أيضا باسم الإثبات في الوقت الفعلي). ومع ذلك ، فإن مشكلة المراوغة مختلفة اختلافا جوهريا. يمكن أن يثبت دليل zk أن أليس أرسلت 10 ETH إلى Bob on Arbitrum ، لكنه لا يضمن أن Scroll ستلتزم بهذا الانتقال على L1. براهين Zk وحدها لا تحل المراوغة ولن تحل أبدا. ثم مرة أخرى ، فإن انتظار تسوية L1 يحل المراوغة ولكن على حساب ميزة سرعة القيمة المحتسبة. وبالتالي ، فإننا نركز على المراوغة قبل التسوية ، أي ضمانات منع المراوغة قبل تسوية Ethereum. كما سنرى ، يتضمن كل نهج مقايضات مختلفة ، لا سيما فيما يتعلق بافتراضات الثقة التي نناقشها أدناه.

بنية التوافقية

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

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

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

شبكة

يعمل نموذج الشبكة الشبكية تمامًا كما قد تتوقع، حيث يتواصل ال rollups مع بعضهم مباشرة بينما يظلون مسؤولين عن التسوية إلى Ethereum L1 بأنفسهم:

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

بينما تعتمد أنظمة الشبكة على الثقة لضمان السلامة قبل التسوية المُحددة مُسبقًا، يمكنها اكتشاف التناقض في التسوية، مما يُثير عمليات إعادة التنظيم في جميع الرول-آب المتصلة.

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

Hub

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

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

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

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

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

• باستخدام rollup الحالي: تتمتع هذه الخيارات بميزة كونها الأبسط، حيث يكون الrollup موجودًا بالفعل وقد تم اختباره في المعركة على الأرجح، وسيكون الأمر مسألة نشر العقود الذكية عليه.
• إنشاء مكون مخصص: بدلاً من طلب من rollups الاعتماد على جميع خصائص الأمان ل rollup موجود، نقوم بإنشاء مكون مخصص جديد ليعمل كمحور. الميزة هنا هي أن هذا المكون الجديد سيكون لديه سطح أخطاء/استغلال مصغر من خلال تصميمه خصيصًا لاحتياجات الشبكة المتقاطعة (ويمكن حتى التحقق منه رسميًا!).
• استخدام Ethereum L1 نفسه: تتضمن هذه الخيارمؤكدات مسبقة مستندةمباشرة على الطبقة 1 للحصول على مزيج مثالي: استخدام الطبقة المركزية إلى أقصى حد لضمان النشاط القصوى والأمان بينما يتمتع الشخص بتأكيدات قريبة من الفور، وأوقات سحب مصغرة، وما إلى ذلك.

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

الأنظمة الحالية

لقد اقترحت العديد من المشاريع حلول توافقية متنوعة، يمكن تصنيفها على النحو التالي.

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

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

أنظمة المحور. إسبريسو و zkSync’s سلسلة مرنةنظم المحور هي. في Scroll، لقد كنا نستكشف تصميم المحور الذي يمكن أن يمكن حلول التوافقية أكثر قابلية للتوسيع وثقة.عرضفي ورشة عمل كولومبيا للاقتصاديات الرقمية 2024 يقدم نظرة عامة على التصميم، مع المزيد من التفاصيل القادمة في مشاركة قادمة.

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

طبقة AggLayer الخاصة بـ Polygon هي نوع آخر من نظام العُقد الذي يوفر طبقة مشتركة يتواصل من خلالها جميع اللفات. ومع ذلك، يختلف عن البقية من خلال تجنب افتراضات الثقة الإضافية في تلك الطبقة المشتركة. بدلاً من ذلك، ينتظرون التسوية ويستخدمونهاأدلة متشائمةلضمان الأمان، يتم منع الاضطراب فقط في وقت التسوية. يمكن استخدام التأكيدات الأولية اختياريًا لتقديم ضمانات أسرع للنهوية. أعلنت AggLayer مؤخرًا عن شراكةمع أنظمة Espresso، التي توفر آلية تسلسل مشتركة.

استنتاج

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

تنصل:

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