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

المؤلف: لو بنبن، سفير تكنولوجيا Arbitrum السابق، مساهم في geek web3

المقدمة: هذه المقالة هي التفسير الفني لـ Arbitrum One بقلم Luo Benben، السفير الفني السابق لـ Arbitrum والمؤسس المشارك السابق لشركة تدقيق أتمتة العقود الذكية Goplus Security.

في المقالة السابقة"السفير الفني السابق لشركة Arbitrum يفسر هيكل مكونات Arbitrum (الجزء 1)"، قدمنا ​​جهاز التسلسل والمدقق والتسلسل في المكونات الأساسية لـ Arbitrum  دور عقد البريد الوارد، وكتلة التجميع، وإثبات الاحتيال غير التفاعلي.في مقال اليوم، سنركز على المكونات المتعلقة بالمراسلة عبر السلاسل ومداخل المعاملات المقاومة للرقابة بين مكونات Arbitrum الأساسية.

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

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

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

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

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

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

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

الأشياء القابلة لإعادة المحاولة

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

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

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

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

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

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

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

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

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

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

• رمز منتشر على L1، كيفية نشره على L2؟

• هل يلزم نشر عقد المستوى الثاني المقابل يدويًا مسبقًا، أم يمكن يقوم النظام بنشرها تلقائيًا عبر هل يتم نشر الرموز المميزة التي تأتي ولكن لم يتم نشر العقود تلقائيًا على عقود الأصول؟

• ما هو عنوان العقد المقابل لأصول ERC-20 على L1 على L2 ؟؟ هل يجب أن يكون متسقًا مع L1؟

• كيفية إصدار الرموز المميزة عبر السلسلة محليًا على L2 إلى L1؟

• الرموز المميزة ذات الوظائف الخاصة، مثل الرموز المميزة القابلة لإعادة الأساس بكميات قابلة للتعديل، والنمو الذاتي الرموز المميزة ذات الفائدة، وكيفية عبور السلسلة؟

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

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

يستخدم Arbitrum نظام البوابة لحل معظم نقاط الضعف عبر السلسلة ERC20. يحتوي على ما يلي الميزات:< /p>

• تظهر مكونات البوابة في أزواج في L1 و L2 .

• جهاز توجيه البوابة مسؤول عن صيانة الرمز المميز L1<->Token L2 تعيين العنوان بين ،والتعيين بين بعض الرموز المميزة<->بعض البوابة.

• يمكن تقسيم البوابة نفسها إلى بوابة StandardERC20، وبوابة عامة مخصصة، وبوابة مخصصة وما إلى ذلك، لحل مشاكل التجسير بأنواعها ووظائفها المختلفة لـ ERC20.

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

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

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

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

• من المستحيل فك WETH في ETH على L2 لأنه لا يوجد قفل مطابق على L2 لـ ETH.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

البريد الصادر

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

• نحن نعلم أن عمليات السحب من جسر Arbitrum الرسمي تحتاج إلى الانتظار حتى نهاية فترة التحدي التي تبلغ حوالي 7 أيام. بعد الانتهاء من الكتلة المجمعة ، عمليات السحب يمكن تنفيذ السلوك. بعد انتهاء فترة التحدي، يرسل المستخدم إثبات Merkle المقابل إلى عقد Outbox على Layer1، والذي يتصل بعد ذلك بعقود وظائف أخرى (مثل فتح الأصول المقفلة في عقود أخرى)، ويكمل في النهاية عملية السحب.

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

  mapping(uint256 => bytes32 ) تم إنفاقه بشكل عام، إذا كان تعيين [spentIndex] != bytes32(0)، فقد تم سحب الطلب. المبدأ مشابه لعداد المعاملات Nonce لمنع هجمات إعادة التشغيل.

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

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

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

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

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

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

سحب ETH

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

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

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

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

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

السحب السريع

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

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

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

السحب القسري

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

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

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

• بعد الانتظار لمدة 24 ساعة للتضمين القسري، قم باستدعاء Force Inclusion() في المربع السريع لتنفيذ التضمين القسري.سيتحقق عقد الصندوق السريع مما إذا كانت هناك رسالة مقابلة في الجسر.

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

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