Sequencer عبارة عن عقدة Arbitrum كاملة مخصصة خصيصًا، وتكون مسؤولة، في ظل الظروف العادية، عن إرسال معاملات المستخدمين إلى L1. من حيث المبدأ، يمكن لجهاز تسلسل السلسلة أن يتخذ أشكالًا مختلفة؛ كما هو الحال حاليًا في Arbitrum One، فإن جهاز التسلسل هو كيان مركزي واحد؛ وفي نهاية المطاف، يمكن منح إمكانيات التسلسل إلى لجنة موزعة من أجهزة التسلسل التي تتوصل إلى توافق في الآراء بشأن الطلب. ومع ذلك، بغض النظر عن شكله، فإن جهاز التسلسل لديه قيود أساسية لا تنطبق على أي جزء آخر من النظام: يجب أن يعمل وفقًا لافتراضاته الأمنية الخاصة؛ أي أنه لا يمكنه، من حيث المبدأ، استخلاص الأمان مباشرة من الطبقة الأولى. وهذا يثير سؤالًا حول كيفية احتفاظ Arbitrum Rollup بمطالبته بمقاومة الرقابة عندما يسيء جهاز التسلسل التصرف.
سنصف هنا آليات عمل جهاز التسلسل عادةً، وكيف يمكن لأي مستخدم تجاوز جهاز التسلسل بالكامل لإرسال أي معاملة Arbitrum (بما في ذلك المعاملة التي، على سبيل المثال، تبدأ رسالة من L2 إلى L1 لسحب الأموال) مباشرة من الطبقة 1. وهكذا وبالتالي تحافظ الآلية على مقاومة الرقابة حتى لو كان جهاز التسلسل غير مستجيب تمامًا أو حتى ضارًا.
البريد الوارد الأساسي
عندما نتحدث عن “إرسال معاملة إلى سلسلة Arbitrum”، فإننا نتحدث عن تضمينها في صندوق الوارد الأساسي للسلسلة، والذي يمثله مصفوفة بايت التسلسل InboxAccs في Bridge. بمجرد تضمين المعاملات في البريد الوارد الأساسي، يتم إصلاح ترتيبها، ويصبح التنفيذ حتميًا تمامًا، ويمكننا التعامل بثقة مع الحالة الناتجة على أنها نهائية على مستوى L1 (راجع “دورة حياة المعاملة”). يتعلق دور مُسلسِل التسلسل (أو عدمه) بدقة بما يحدث مسبقًا؛ أي كيف تشق المعاملة طريقها إلى البريد الوارد الأساسي. سنقوم بتقسيم المسارات المحتملة التي يمكن أن تتخذها المعاملة إلى سيناريوهين: مُسلسِل جيد التصرف، ومُسلسل معيب.
حالة سعيدة/شائعة: جهاز التسلسل حي وحسن التصرف
هنا، نبدأ بافتراض أن جهاز التسلسل يعمل بكامل طاقته، ويعمل بهدف معالجة معاملات المستخدمين بطريقة آمنة وفي الوقت المناسب قدر الإمكان. يمكن لجهاز التسلسل تلقي معاملة المستخدم بطريقتين – إما مباشرة عبر طلب RPC، أو عبر L1 الأساسي.
إذا كان المستخدم ينشر معاملة Arbitrum “قياسية” (أي التفاعل مع تطبيق L2 الأصلي)، فسيقوم المستخدم بإرسال المعاملة الموقعة مباشرة إلى جهاز التسلسل، تمامًا مثلما يرسل المستخدم معاملة إلى عقدة Ethereum عند التفاعل مع L1 . عند استلامه، سيقوم جهاز التسلسل بتنفيذه وتسليم المستخدم إيصالًا على الفور تقريبًا. بعد مرور بعض الوقت القصير – عادة لا يزيد عن بضع دقائق – سيقوم جهاز التسلسل بتضمين معاملة المستخدم في دفعة ونشرها على L1 عن طريق استدعاء إحدى طرق addSequencerL2Batch الخاصة بـ SequencerInbox. لاحظ أن مُسلسِل التسلسل هو الوحيد الذي لديه صلاحية استدعاء هذه الأساليب؛ هذا التأكيد على عدم قدرة أي طرف آخر على تضمين رسالة مباشرة هو، في الواقع، نفس الشيء الذي يمنح جهاز التسلسل القدرة الفريدة على توفير إيصالات “التأكيد المبدئي” الفورية. بمجرد ترحيلها دفعة واحدة، تصبح المعاملات نهائية على مستوى L1.
وبدلاً من ذلك، يمكن للمستخدم إرسال رسالة L2 الخاصة به إلى جهاز التسلسل عن طريق نشرها على L1 الأساسي. يعد هذا المسار ضروريًا إذا كان المستخدم يرغب في إجراء بعض عمليات L1 مع رسالة L2 وللحفاظ على الذرية بين الاثنين – المثال الكتابي هنا هو إيداع رمزي عبر جسر (الضمان على L1، النعناع على L2). يقوم المستخدم بذلك عن طريق نشر معاملة L1 (أي إرسال معاملة عادية إلى عقدة L1) التي تستدعي إحدى الطرق ذات الصلة في عقد Inbox؛ على سبيل المثال، sendUnsignedTransaction. يؤدي هذا إلى إضافة رسالة إلى ما سنسميه “صندوق الوارد المؤجل”، (ممثلًا في InboxAccs المؤجل في عقد Bridge)، وهو عبارة عن قائمة انتظار تنتظرها الرسائل قبل نقلها إلى صندوق الوارد الأساسي. سيرسل جهاز التسلسل إيصال L2 بعد حوالي 10 دقائق تقريبًا من تضمين المعاملة في البريد الوارد المؤجل (سبب هذا التأخير هو تقليل مخاطر عمليات إعادة تنظيم L1 على المدى القصير والتي قد تؤدي بدورها إلى إعادة تنظيم L2 وإبطال L2 الخاص بجهاز التسلسل الإيصالات.) مرة أخرى، الخطوة الأخيرة هي أن يقوم جهاز التسلسل بتضمين رسالة L2 في دفعة – عند استدعاء طرق إرسال الدُفعة، يحدد جهاز التسلسل عدد الرسائل في البريد الوارد المتأخر المراد تضمينها – لإنهاء المعاملة.
باختصار – في كلتا الحالتين السعيدتين، يقوم المستخدم أولاً بتسليم رسالته إلى جهاز التسلسل، والذي بدوره يضمن وصولها إلى البريد الوارد الأساسي.
حالة غير سعيدة/غير شائعة: جهاز التسلسل لا يقوم بعمله
لنفترض الآن أن جهاز التسلسل، لأي سبب كان، يفشل تمامًا في تنفيذ مهمته المتمثلة في إرسال الرسائل. لا يزال بإمكان المستخدم تضمين معاملته في خطوتين:
أولاً، يقومون بإرسال رسالة L2 الخاصة بهم عبر L1 إلى صندوق الوارد المؤجل كما هو موضح أعلاه: لاحظ أنه على الرغم من أن الرسائل عبر السلسلة الذرية هي الحالة الشائعة لاستخدام صندوق الوارد المؤجل، إلا أنه يمكن استخدامها من حيث المبدأ لإرسال أي رسالة من المستوى الثاني.
بمجرد وصولنا إلى البريد الوارد المتأخر، من الواضح أنه لا يمكننا الاعتماد على جهاز التسلسل لتضمين المعاملة دفعة واحدة. بدلاً من ذلك، يمكننا استخدام طريقة forceInclusion الخاصة بـ SequencerInbox. بمجرد وجود رسالة في البريد الوارد المؤجل لفترة كافية من الوقت، يمكن استدعاء forceInclusion لنقلها من البريد الوارد المؤجل إلى البريد الوارد الأساسي، وعند هذه النقطة يتم الانتهاء منها. والأهم من ذلك، أن أي حساب يمكن أن يطلق عليه اسم forceInclusion.
حاليًا، في Arbitrum One، يبلغ وقت التأخير بين التقديم وإدراج القوة حوالي 24 ساعة، كما هو محدد بواسطة maxTimeVariation.delayBlocks / maxTimeVariation.delaySeconds. إن إدراج القوة من L1 سيؤثر بشكل مباشر على حالة أي معاملات L2 غير مؤكدة؛ إن الحفاظ على قيمة تأخير عالية بشكل متحفظ يضمن عدم استخدامها إلا في ظل ظروف استثنائية.
علاوة على التأخير نفسه، فإن مسار forceInclusion له جانب سلبي يتمثل في عدم اليقين بشأن طلب المعاملات؛ على سبيل المثال، أثناء انتظار مرور الحد الأقصى لتأخير الرسالة، يمكن لجهاز التسلسل الخبيث، من حيث المبدأ، نشر الرسائل مباشرة أمامه. ومع ذلك، لا يوجد في النهاية أي شيء يمكن أن يفعله جهاز التسلسل لمنع تضمينه في البريد الوارد الأساسي، وعند هذه النقطة يتم الانتهاء من ترتيبه.
على الرغم من أن المسار البطيء “غير السعيد” ليس هو الأمثل، ونادرًا ما يكون ضروريًا، فإن توفره كخيار يضمن احتفاظ Arbitrum Rollup دائمًا بنموذج الأمان غير الموثوق به، حتى لو كانت الأجزاء المسموح بها من النظام تعمل بشكل خاطئ.