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

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

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

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

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

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

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

يمكن إعادة المحاولة

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

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

1. إرسال التذكرة على L1: أنشئ تذكرة إيداع باستخدام طريقة createRetryableTicket() في عقد Delayed Inbox وأرسلها.

2. الاسترداد التلقائي على L2: في معظم الحالات، يمكن لجهاز التسلسل استرداد التذكرة تلقائيًا للمستخدم دون مزيد من التدخل اليدوي.

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

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

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

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

بوابة الأصول عبر السلسلة ERC-20

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

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

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

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

تستخدم Arbitrum نظام Gateway لمعالجة معظم نقاط الضعف في المعاملات عبر سلسلة ERC20، والتي تتميز بالخصائص التالية:

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

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

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

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

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

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

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

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

البريد الوارد المتأخر

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

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

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

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

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

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

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

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

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

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

صندوق الصادر

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

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

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

إيداع الإثيريوم

1. يقوم المستخدم باستدعاء وظيفة الإيداعETH() لصندوق الوارد المؤجل.
2. تقوم هذه الدالة بعد ذلك باستدعاء Bridge.enqueueDelayedMessage()‎، الذي يسجل الرسالة في عقد الجسر ويرسل ETH إلى عقد الجسر. يتم الاحتفاظ بجميع أموال ETH المودعة في عقد الجسر، الذي يعمل كعنوان إيداع.
3. يراقب جهاز التسلسل رسالة الإيداع في صندوق الوارد المؤجل ويعكس عملية الإيداع في قاعدة بيانات L2. يمكن للمستخدمين رؤية أصولهم المودعة على شبكة L2.
4. يقوم جهاز التسلسل بتضمين سجل الإيداع في مجموعة من المعاملات وإرساله إلى عقد Fast Inbox على L1.

سحب الإثيريوم

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

2. يرسل جهاز التسلسل طلب السحب إلى الصندوق السريع.

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

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

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

عمليات سحب سريعة

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

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

انسحاب القوة

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

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

• قم باستدعاء inbox.sendL2Message() في عقد Delayed Inbox على L1، مع المعلمات المطلوبة عند استدعاء drawEth() على L2. تتم مشاركة هذه الرسالة مع عقد الجسر على L1.
• بعد الانتظار لفترة انتظار فرض التضمين لمدة 24 ساعة، قم باستدعاء forceInclusion() في عقد Fast Inbox لفرض التضمين. سيتحقق عقد Fast Inbox من وجود رسالة مقابلة في الجسر.

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

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

تنصل:

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