السفير الفني السابق لشركة Arbitrum يشرح البنية المكونة لـ Arbitrum (الجزء الثاني)

كيف تتعامل Arbitrum مع الرسائل عبر السلسلة والمعاملات المقاومة للرقابة؟ ما هو نموذج الجسر المتقاطع؟

** بقلم: لوه بنبن، السفير الفني السابق لشركة Arbitrum والمساهم المهوس في web3**

في المقالة السابقة* “السفير الفني السابق لشركة Arbitrum يفسر بنية مكونات Arbitrum (الجزء الأول)”**، قدمنا جهاز التسلسل، والمدقق، وعقد Sequencer Inbox، و Rollup Block، وإثبات الاحتيال غير التفاعلي في المكونات الأساسية لـ Arbitrum في مقال اليوم، سنركز على المكونات المتعلقة بالمراسلة عبر السلاسل ومداخل المعاملات المقاومة للرقابة بين المكونات الأساسية لـ Arbitrum. *

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

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

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

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

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

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

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

التذاكر القابلة لإعادة المحاولة Retryables

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

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

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

**2. الاسترداد التلقائي على المستوى 2. **في معظم الحالات، يمكن لأداة الفرز أن تساعد المستخدمين تلقائيًا على دفع الفواتير دون إجراء عمليات يدوية لاحقة.

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

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

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

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

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

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

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

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

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

**يستخدم Arbitrum نظام Gateway لحل معظم نقاط الضعف في سلسلة ERC20. **يحتوي على الميزات التالية:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*إيداع ETH()، أبسط وظيفة لإيداع ETH.

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

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

صندوق الصادر صندوق الصادر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

السحب السريع

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

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

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

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

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

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

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

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