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

النص الرئيسي: ذكرنا في المقالات السابقة أن عقد Sequencer Inbox مصمم خصيصًا لتلقي دفعات بيانات المعاملات المنشورة من قبل المنظم على الطبقة الأولى. في الوقت نفسه، أشرنا إلى أن صندوق الوارد الخاص بـ Sequencer يشار إليه أيضًا باسم «الصندوق السريع»، وعلى النقيض من ذلك، هناك «الصندوق البطيء» أو البريد الوارد المتأخر (يشار إليه باسم البريد الوارد). أدناه، سنقدم تفسيرًا تفصيليًا للمكونات المتعلقة بتمرير الرسائل عبر السلاسل، بما في ذلك البريد الوارد المتأخر.

مبدأ السلسلة المتقاطعة والجسور

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

بالمقارنة مع معاملات L2 الخالصة، تتضمن المعاملات عبر السلاسل تبادل المعلومات بين نظامين مختلفين، L1 و L2، مما يجعل العملية أكثر تعقيدًا.

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

من ناحية أخرى، تختلف الإجراءات عبر السلاسل بين Rollup وشبكة ETH الرئيسية اختلافًا جوهريًا عن العمليات عبر السلاسل المذكورة أعلاه. هذا لأن حالة Layer2 يتم تحديدها من خلال البيانات المسجلة على Layer1. طالما أنك تستخدم جسر Rollup الرسمي عبر السلاسل، فهو آمن من الناحية الهيكلية في عملياته.

يسلط هذا الضوء على جوهر Rollup، والذي يظهر، من منظور المستخدم، كسلسلة مستقلة، ولكن في الواقع، فإن ما يسمى بـ «Layer2" هو مجرد نافذة عرض سريعة تفتحها Rollup للمستخدمين، ولا يزال هيكلها الحقيقي الشبيه بالسلسلة مسجلاً على Layer1. لذلك، يمكننا اعتبار L2 بمثابة نصف سلسلة أو «سلسلة تم إنشاؤها على Layer1".

الجداول القابلة لإعادة المحاولة

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

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

1. إرسال التذكرة على L1: استخدم طريقة «CreateRetryableTicket ()» في عقد البريد الوارد المؤجل لإنشاء تذكرة إيداع وإرسالها.
2. الاسترداد التلقائي على L2: في معظم الحالات، يمكن للمُسلسل استرداد التذكرة تلقائيًا للمستخدم دون الحاجة إلى إجراءات يدوية إضافية.
3. الاسترداد اليدوي على L2: في بعض الحالات القصوى، مثل الارتفاع المفاجئ في أسعار الغاز على L2، إذا كان الغاز المدفوع مسبقًا على التذكرة غير كافٍ، فلا يمكن أن يحدث الاسترداد التلقائي. في هذا السيناريو، يكون التدخل اليدوي من قبل المستخدم ضروريًا. من المهم ملاحظة أنه في حالة فشل الاسترداد التلقائي، يحتاج المستخدم إلى استرداد التذكرة يدويًا في غضون 7 أيام؛ وإلا، سيتم حذف التذكرة (مما يؤدي إلى خسارة دائمة للأموال) أو يحتاج المستخدم إلى دفع رسوم معينة لتجديد تخزين التذكرة.

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

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

بوابة متعددة السلاسل لأصول ERC-20

يعد التسلسل المتقاطع لأصول ERC-20 أمرًا معقدًا. يمكننا التفكير في العديد من الأسئلة:

• كيفية نشر رمز تم نشره على L1 على L2؟
• هل يلزم نشر عقد L2 المقابل يدويًا مسبقًا، أم يمكن للنظام نشر عقود الأصول تلقائيًا للرموز التي تم تجاوزها ولكن لم يتم نشر العقد بعد؟
• بالنسبة لأصول ERC-20 على L1، ما هو عنوان العقد المقابل على L2؟ هل يجب أن تكون متوافقة مع L1؟
• كيف يمكن ربط الرموز المميزة الصادرة محليًا على L2 إلى L1؟
• كيف يمكن ربط الرموز ذات الوظائف الخاصة، مثل رموز إعادة التأسيس بكميات قابلة للتعديل والرموز ذات الفائدة المتنامية ذاتيًا؟

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

حاليًا، تستخدم العديد من حلول التحجيم حلول القائمة البيضاء والقائمة اليدوية لتجنب العديد من المشكلات المعقدة والشروط الحدودية.

يستخدم Arbitrum نظام البوابة لحل معظم المشاكل العالقة في سلسلة ERC20 المتقاطعة. يحتوي على الميزات التالية:

• تظهر مكونات البوابة في أزواج في L1 وL2.
• جهاز توجيه البوابة مسؤول عن الحفاظ على تعيين العنوان بين الرمز المميز L1<->Token L2. إلى جانب ذلك، فإن التعيين بين بعض الرموز<->بعض البوابات.
• يمكن تقسيم البوابة نفسها إلى بوابة ERC20 القياسية، والبوابة العامة المخصصة، والبوابة المخصصة، وما إلى ذلك، لحل أنواع ووظائف مختلفة من مشاكل سد ERC20.

لنأخذ سلسلة WETH المتقاطعة البسيطة نسبيًا كمثال لتوضيح ضرورة تخصيص البوابة.

يُعد WETH مكافئًا لـ ERC20 لعملة ETH. باعتبارها العملة الرئيسية، لا يمكن لـ Ether تنفيذ وظائف معقدة في العديد من dApps، لذلك هناك حاجة إلى مكافئ ERC20. قم بتحويل بعض ETH إلى عقد WETH، وسيتم قفلها في العقد، وسيتم توليد نفس الكمية من WETH.

وبنفس الطريقة، يمكن أيضًا حرق WETH وسحب ETH. من الواضح أن نسبة تداول WETH و ETH المقفل هي دائمًا 1:1.

إذا قمنا الآن بنقل WETH مباشرة إلى L2، فسنجد بعض المشكلات الغريبة:

• من المستحيل فك تحويل WETH إلى ETH على L2 نظرًا لعدم وجود ETH مقابل للقفل على L2.
• يمكن استخدام وظيفة Wrap، ولكن إذا تم إرجاع WETH التي تم إنشاؤها حديثًا إلى L1، فلا يمكن قطع ارتباطها إلى ETH على L1 لأن عقود WETH على L1 و L2 ليست «متماثلة».

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

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

البريد الوارد المؤجل

النظير للبريد الوارد السريع، المعروف باسم Sequencer Inbox، هو البريد الوارد البطيء (المسمى بالكامل البريد الوارد المتأخر). لماذا نميز بين السريع والبطيء؟ هذا لأن البريد الوارد السريع مخصص لاستقبال مجموعات من معاملات L2 المنشورة من قبل المنظم، وأي معاملات لم تتم معالجتها مسبقًا بواسطة المنظم داخل شبكة L2 يجب ألا تظهر في عقد البريد الوارد السريع.

تتمثل الوظيفة الأولى للبريد الوارد البطيء في التعامل مع عملية الإيداع من L1 إلى L2. يبدأ المستخدمون عمليات الإيداع من خلال البريد الوارد البطيء، وبمجرد أن يلاحظ المنظم ذلك، ينعكس ذلك على L2. في النهاية، يتم تضمين سجل الإيداع هذا في تسلسل معاملات L2 بواسطة المنظم وإرساله إلى عقد البريد الوارد السريع (Sequencer Inbox).

في هذا السيناريو، من غير المناسب للمستخدمين إرسال معاملات الإيداع مباشرة إلى البريد الوارد السريع (Sequencer Inbox) لأن المعاملات المرسلة إلى البريد الوارد السريع قد تعطل ترتيب المعاملات العادي في Layer2، مما يؤثر على تشغيل جهاز التسلسل.

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

إذا تم إرسال المعاملة إلى صندوق الوارد المؤجل، وبعد 24 ساعة، ظلت غير مدمجة في تسلسل المعاملات بواسطة المُسلسِل، يمكن للمستخدمين تشغيل وظيفة تضمين القوة يدويًا على Layer1. يجبر هذا الإجراء المعاملات التي يتجاهلها المُسلسِل على تجميعها بالقوة في البريد الوارد السريع (Sequencer Inbox). بعد ذلك، سيتم اكتشافها بواسطة جميع عقد Arbitrum One وإدراجها بقوة في تسلسل معاملات Layer2.

لقد ذكرنا للتو أن البيانات الموجودة في البريد الوارد السريع تمثل كيان البيانات التاريخي لـ L2. لذلك، في حالات الرقابة الضارة، يسمح استخدام البريد الوارد البطيء بتضمين تعليمات المعاملات في نهاية المطاف في دفتر الأستاذ L2، والذي يغطي سيناريوهات مثل عمليات السحب القسري للهروب من Layer2.

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

العديد من الوظائف الأساسية للبريد الوارد البطيء (البريد الوارد):

• DepositETH (): أبسط وظيفة لإيداع ETH.
• إنشاء تذكرة قابلة لإعادة المحاولة (): تُستخدم لإيداع ETH وERC20 والرسائل. يوفر مرونة أكبر مقارنة بـ DepositETH ()، مما يسمح بمواصفات مثل عنوان الاستلام في L2 بعد الإيداع.
• forceInclusion (): يمكن لأي شخص استدعاء هذه الوظيفة، وهي ميزة التضمين القسري. تتحقق الوظيفة مما إذا كانت المعاملة المرسلة إلى عقد البريد الوارد البطيء لم تتم معالجتها بعد 24 ساعة. إذا تم استيفاء الشروط، فإنها تتضمن الرسالة بقوة.

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

صندوق الصادر

يرتبط Outbox فقط بعمليات السحب ويمكن فهمه كنظام تسجيل وإدارة لسلوكيات السحب:

• نحن نعلم أن عمليات السحب على جسر Arbitrum الرسمي تحتاج إلى الانتظار لمدة 7 أيام تقريبًا حتى تنتهي فترة التحدي، ولا يمكن تنفيذ السحب إلا بعد الانتهاء من Rollup Block. بعد انتهاء فترة التحدي، يقوم المستخدم بإرسال Merkle Proof المقابل إلى عقد Outbox على Layer1، والذي يتصل بعد ذلك بعقود الوظائف الأخرى (مثل فتح الأصول المقفلة في عقود أخرى)، ويكمل السحب أخيرًا.
• سيسجل عقد OutBox الرسائل عبر السلاسل من L2 إلى L1 التي تمت معالجتها لمنع أي شخص من إرسال طلبات السحب المنفذة بشكل متكرر. وهو يسجل المراسلات بين مؤشر الإنفاق ومعلومات طلب السحب باستخدام «رسم الخرائط (uint256 = > bytes32) الإنفاق العام». في حالة رسم الخرائط [SpentIndex]! = bytes32 (0)، تم سحب الطلب. يشبه المبدأ عداد المعاملات Nonce لمنع هجمات إعادة التشغيل.

أدناه سنأخذ ETH كمثال لشرح عملية الإيداع والسحب بشكل كامل. الفرق الوحيد بين ERC20 و ETH هو أن الأول يستخدم Gateway. لن نوضحها بالتفصيل.

إيداع ETH

1. يستدعي المستخدم وظيفة DepositETH () الخاصة بالمربع البطيء.

2. ستستمر هذه الوظيفة في استدعاء 'bridge.enqueueDelayedMessage () '، سجل الرسالة في عقد الجسر، وأرسل ETH إلى عقد الجسر. يتم الاحتفاظ بجميع أموال إيداع ETH في العقد المرحلي، وهو ما يعادل عنوان الإيداع.

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

4. يقوم المنظم بتضمين سجل الإيداع في دفعة المعاملة وإرساله إلى عقد الصندوق السريع على L1.

سحب إيثريوم

1. يستدعي المستخدم وظيفة withDraweth () لعقد ArbSys على L2، ويتم حرق الرقم المقابل من ET على L2.

2. يرسل المنظم طلب السحب إلى المربع السريع.

3. تقوم عقدة Validator بإنشاء مجموعة Rollup Block جديدة استنادًا إلى تسلسل المعاملات في المربع السريع، والذي سيحتوي على معاملات السحب المذكورة أعلاه.

4. بعد مرور Rollup Block بفترة التحدي التي تم تأكيدها أيضًا، يمكن للمستخدم استدعاء وظيفة Outbox.execute Transaction () على L1 لإثبات أن المعلمات مقدمة في عقد ArbSys المذكور أعلاه.

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

سحب نقدي سريع

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

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

الانسحاب القسري

يتم استخدام وظيفة Force Inclusion () لمقاومة رقابة جهاز التسلسل. يمكن تنفيذ أي معاملة محلية من L2 ومعاملة L1 إلى L2 ومعاملة من L2 إلى L1 باستخدام هذه الوظيفة. تؤثر الرقابة الخبيثة على جهاز التسلسل بشكل خطير على تجربة المعاملة. في معظم الحالات، سنختار سحب الأموال وترك L2. لذلك، يستخدم ما يلي السحب القسري كمثال لتقديم استخدام ForceInclusion.

إذا نظرنا إلى الوراء في خطوات سحب ETH، فإن الخطوتين 1 و 2 فقط تتضمنان رقابة التسلسل، لذلك يجب تغيير هاتين الخطوتين فقط:

• عند استدعاء 'inbox.sendl2message () 'في عقد المربع البطيء على L1، فإن معاملات الإدخال هي المعلمات التي يجب إدخالها عند استدعاء withDraweth () على L2. ستتم مشاركة هذه الرسالة مع عقد الجسر على L1.
• بعد فترة انتظار التضمين القسري لمدة 24 ساعة، يتم استدعاء فرض Inclusion () في المربع السريع لإجراء التضمين القسري. سيتحقق عقد الصندوق السريع مما إذا كانت هناك رسالة مقابلة في الجسر.

يمكن للمستخدمين النهائيين سحب الأموال في Outbox، وبقية الخطوات هي نفس عمليات السحب العادية.

بالإضافة إلى ذلك، هناك أيضًا دروس تفصيلية حول استخدام Arb SDK في دروس التحكيم لتوجيه المستخدمين حول كيفية إجراء معاملات L2 المحلية ومعاملات L2 إلى L1 من خلال وظيفة forceInclusion ().

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

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