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

المؤلف: Benben Luo ، السفير الفني السابق ل Arbitrum ، مساهم geek web3

في المقالة السابقة ، “يشرح سفراء Arbitrum الفنيون السابقون هيكل مكونات Arbitrum (الجزء الأول)” ، قدمنا دور أجهزة التسلسل ، والمدققين ، وعقود SequencerInbox ، وكتل التجميع ، وأدلة الاحتيال غير التفاعلية في المكونات الأساسية ل Arbitrum ، وفي مقال اليوم ، سنركز على مكونات مكونات Arbitrum الأساسية المتعلقة برسائل التفاعل عبر السلسلة ومداخل المعاملات المقاومة للرقابة.

الجسم: في مقالة سابقة ، ذكرنا أن عقد Sequencer Inbox يتلقى على وجه التحديد مجموعة حزم المعاملات المنشورة بواسطة جهاز التسلسل على الطبقة 1. في الوقت نفسه ، نشير إلى أن Sequencer Inbox يعرف أيضا باسم Fast Box ، على عكس Slow Box Delayed Inbox (Inbox للاختصار). ** أدناه ، سنلقي نظرة فاحصة على المكونات المتعلقة برسائل التفاعل عبر السلاسل ، مثل البريد الوارد المتأخر.

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

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

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

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

يختلف سلوك التفاعل عبر السلسلة بين Rollup و ETHMainnet اختلافا جوهريا عن التفاعل عبر السلسلة أعلاه ، لأن حالة الطبقة 2 تحددها البيانات المسجلة على الطبقة 1 ، طالما أنك تستخدم جسر التفاعل عبر السلسلة Rollup الرسمي ، فهو آمن تماما من حيث هيكل التشغيل. **

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

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

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

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

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

**2. الاسترداد التلقائي على L2. ** في معظم الحالات ، يمكن لجهاز التسلسل استرداد الفاتورة تلقائيا للمستخدم ، دون الحاجة إلى التشغيل اليدوي اللاحق.

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

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

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

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

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

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

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

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

يستخدم Arbitrum نظام البوابة لحل معظم نقاط الألم في التفاعل عبر السلسلة ERC20 ، مع الميزات التالية:

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

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

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

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

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

• لا يمكن فك غلاف WETH إلى ETH على L2 لأنه لا يوجد وضع قفل يتوافق مع ETH على L2.
• يمكن استخدام وظيفة Wrap ، ولكن لا يمكن فك تغليف WETH التي تم إنشاؤها حديثا على أنها ETH على L1 إذا عادت إلى L1 ، لأن عقود WETH على L1 و L2 ليست “متماثلة”.

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

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

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

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

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

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

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

إذا تم إرسال المعاملة إلى صندوق الوارد المؤجل ، بعد 24 ساعة ، فلن يتم تضمين المعاملة في Slowbox في تسلسل المعاملة بواسطة جهاز التسلسل ، ** يمكن للمستخدم تشغيل وظيفة تضمين القوة يدويا على الطبقة 1 ** ، ويتم تجميع طلبات المعاملات التي يتجاهلها جهاز التسلسل بالقوة في صندوق الوارد الخاص ب Fastbox Sequencer ، وبعد ذلك ستتم مراقبتها بواسطة جميع عقد Arbitrum One وسيتم تضمينها بالقوة في تسلسل معاملات الطبقة 2.

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

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

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

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

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

صندوق الصادر

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

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

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

إيداع ETH

1. يستدعي المستخدم وظيفة depositETH () الخاصة ب Slowbox.

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

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

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

ETH عمليات السحب

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

2. يرسل جهاز التسلسل طلب السحب إلى Quickbox.

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

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

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

دفعات سريعة

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

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

المدفوعات القسرية

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

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

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

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

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