بالأمس فقط ، وقع حدث صادم: تم إغلاق Linea ، الحل إثيريوم طبقة 2 الذي طورته Consensys ، الشركة الأم ل Metamask ، بشكل استباقي. كان السبب الرسمي المقدم هو التخفيف من تأثير حادث القرصنة Velocore. يعيد هذا الحادث حتما إلى الأذهان حالة سابقة حيث تم إغلاق سلسلة BSC (BNB Chain) أيضا بتنسيق رسمي لتقليل خسائر القرصنة. غالبا ما تدفع هذه الأحداث الناس إلى التشكيك في القيم اللامركزية التي يدافع عنها Web3.

يكمن السبب الأساسي وراء الأحداث المذكورة أعلاه في نقص البنية التحتية ، وتحديدا افتقارها إلى اللامركزية. إذا كانت blockchain لامركزية بما فيه الكفاية ، فلا ينبغي أن تكون قادرة على الإغلاق بهذه السهولة. نظرا للهيكل الفريد ل إثيريوم طبقة 2 ، تعتمد معظم حلول طبقة 2 على أجهزة التسلسل المركزية. على الرغم من الخطاب المتزايد حول أجهزة التسلسل اللامركزية في السنوات الأخيرة ، بالنظر إلى الغرض من طبقة 2 وهيكلها ، يمكننا أن نفترض أنه من غير المرجح أن يحقق طبقة 2 أجهزة التسلسل مستويات عالية من اللامركزية. في الواقع ، قد ينتهي بهم الأمر إلى أن يكونوا أقل لامركزية من سلسلة BSC. إذا كان هذا هو الحال، فما الذي يمكن عمله؟ بالنسبة طبقة 2 ، فإن المخاطر الأكثر إلحاحا لأجهزة التسلسل اللامركزية هي نقص مقاومة الرقابة والحيوية. إذا لم يكن هناك سوى عدد قليل من الكيانات التي تعالج المعاملات (أجهزة التسلسل) ، فلديهم سلطة مطلقة على ما إذا كانوا سيخدمونك أم لا: يمكنهم رفض معاملاتك حسب الرغبة ، مما يتركك دون ملجأ. ومن الواضح أن معالجة مسألة مقاومة الرقابة في طبقة 2 موضوع هام. على مدى السنوات القليلة الماضية ، اقترحت حلول إثيريوم طبقة 2 المختلفة مناهج مختلفة لمعالجة هذه المشكلة. على سبيل المثال ، قدمت Loopring و Degate و StarkEx وظائف فتحة السحب والهروب القسري ، بينما نفذت Arbitrum وغيرها من عمليات التجميع المتفائلة ميزات تضمين القوة. يمكن لهذه الآليات فرض ضوابط على أجهزة التسلسل لمنع الرفض التعسفي لمعاملات المستخدم. في مقال اليوم ، يشارك NIC Lin من جمعية تايبيه إثيريوم تجربته المباشرة ، حيث قام بتجربة ميزات المعاملات المقاومة للرقابة لأربعة مجموعات رئيسية وتقديم تحليل متعمق لآلية تضمين القوة ، مع التركيز على سير العمل والأساليب التشغيلية. هذا التحليل ذو قيمة خاصة لمجتمع إثيريوم وأصحاب الأصول الكبيرة.

الرقابة على المعاملات وفرض التضمين

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

ملاحظة: في بنية الفصل بين مقدم الاقتراح والمنشئ (PBS) الحالية في إثيريوم ، يتم تقليل تكلفة الرقابة على المعاملات بشكل كبير. على سبيل المثال ، يمكنك إلقاء نظرة على نسبة الكتل التي تتوافق مع رقابة مكتب مراقبة الأصول الأجنبية على معاملات Tornado Cash. يعتمد مقاومة الرقابة الحالي على المدققون ومرحلات مستقلة تقع خارج نطاق اختصاص مكتب مراقبة الأصول الأجنبية والكيانات الحكومية الأخرى.

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

يمكن ل Sequencer رفض معالجة معاملة المستخدم، مما يؤدي إلى تأمين أموال المستخدم وعدم قدرته على مغادرة مجموعة التحديثات.

Force Inclusion آلية

بدلا من مطالبة Rollups بعدد كبير من أجهزة التسلسل اللامركزية ، من الأكثر فعالية الاستفادة مباشرة من مقاومة الرقابة الطبقة 1 (L1):

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

Sequencer لا يمكنه مراجعة معاملات L1 للمستخدم دون دفع تكلفة عالية

كيف ينبغي تنفيذ المعاملات القسرية؟

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

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

يمكن ل Sequencer اختيار وقت الحصول على المعاملات من قائمة انتظار الانتظار.

لا يزال بإمكان أجهزة التسلسل رفض معالجة المعاملات في قائمة انتظار الانتظار.

إذا رفض جهاز التسلسل باستمرار معالجة المعاملات، فبعد فترة معينة، يمكن لأي شخص استخدام وظيفة فرض التضمين لإدراج الحركات بالقوة في عقد التراكم. بعد ذلك ، سنقدم كيفية تنفيذ آلية تضمين القوة في أربعة مجموعات بارزة: التفاؤل ، Arbitrum ، StarkNet ، و zkSync.

آلية إدراج قوة التفاؤل

أولا ، دعنا نناقش عملية إيداع التفاؤل. لا تتضمن عملية الإيداع هذه تحويل الأموال إلى Optimism فحسب ، بل تتضمن أيضا إرسال "رسائل مستخدم إلى L2". عندما تتلقى عقدة L2 رسالة مودعة حديثا ، فإنها تحول الرسالة إلى معاملة L2 وتنفذها ، وتسلمها إلى المستلم المحدد.

رسائل المستخدم المودعة من L1 إلى L2

عقد L1CrossDomainMessenger

عندما يرغب المستخدم في إيداع ETH أو ERC-20 الرموز المميزة إلى Optimism ، فإنه يتفاعل مع عقد L1StandardBridge على L1 عبر صفحة ويب أمامية ، مع تحديد المبلغ الذي يجب إيداع وعنوان L2 الذي سيتلقى هذه الأصول. ثم يقوم عقد L1StandardBridge بإعادة توجيه الرسالة إلى عقد L1CrossDomainMessenger ، والذي يعمل ك الجسر اتصال أساسي بين L1 و L2. يستخدم L1StandardBridge مكون الاتصال هذا للتفاعل مع L2StandardBridge على L2 ، وتحديد من يمكنه سك الرموز المميزة على L2 أو إلغاء قفل الرموز المميزة من L1. يمكن للمطورين الذين يحتاجون إلى إنشاء عقود تعمل بشكل بيني ومزامنة الحالات بين L1 و L2 بناءها على رأس عقد L1CrossDomainMessenger.

رسائل المستخدم المرسلة من L1 إلى L2 عبر عقد CrossDomainMessenger

ملاحظة: في بعض الصور في هذه المقالة ، تتم كتابة CrossDomainMessenger ك CrossChainMessenger.

عقد بوابة التفاؤل

ثم يقوم عقد L1CrossDomainMessenger بإعادة توجيه الرسالة إلى الطبقة الدنيا، عقد OptimismPortal. بعد معالجة الرسالة، يصدر عقد OptimismPortal حدثا يسمى TransactionDeposited، والذي يتضمن معلمات مثل "المرسل" و "المستلم" وتفاصيل التنفيذ الأخرى ذات الصلة. تستمع عقد Optimism على L2 إلى حدث TransactionDeposited هذا من عقد OptimismPortal وتحويل معلمات الحدث إلى معاملة L2. سيكون بادئ هذه المعاملة هو "المرسل" المحدد في الحدث ، وسيكون المستلم هو "المستلم" المذكور في الحدث ، كما سيتم اشتقاق تفاصيل المعاملة الأخرى من معلمات الحدث.

L2 تقوم العقد بتحويل معلمات الحدث المودع للمعاملة المنبعثة من OptimismPortal إلى معاملة L2.

على سبيل المثال، عندما يقوم مستخدم بإيداع 0.01 ETH من خلال عقد L1StandardBridge، يتم إرسال الرسالة و ETH إلى عقد OptimismPortal (العنوان 0xbEb5... 06Ed). بعد بضع دقائق ، يتم تحويل هذا إلى معاملة L2: مرسل الرسالة هو عقد L1CrossDomainMessenger ، والمستقبل هو عقد L2CrossDomainMessenger على L2 ، ويشير محتوى الرسالة إلى أن L1StandardBridge تلقى 0.01 ETH إيداع من Bob. يؤدي هذا بعد ذلك إلى تشغيل عمليات إضافية ، مثل السك 0.01 ETH ل L2StandardBridge ، والتي تنقلها لاحقا إلى Bob.

كيفية تشغيله

إذا كنت ترغب في تضمين معاملة بالقوة في عقد Optimism's Rollup ، فإن هدفك هو التأكد من أن المعاملة "التي تم بدؤها وتنفيذها من عنوان L2 الخاص بك على L2" يمكن تنفيذها بنجاح. لتحقيق ذلك، يجب عليك إرسال الرسالة مباشرة إلى عقد OptimismPortal باستخدام عنوان L2 الخاص بك (لاحظ أن عقد OptimismPortal موجود بالفعل على L1، ولكن تنسيق عنوان OP يطابق تنسيق عنوان L1، بحيث يمكنك استدعاء هذا العقد باستخدام الحساب L1 بنفس عنوان L2 الحساب). سيكون "مرسل" معاملة L2 المشتقة من حدث المعاملة المودعة المنبعث من هذا العقد هو الحساب L2 الخاص بك ، وسيكون تنسيق المعاملة متسقا مع معاملة L2 القياسية.

في معاملة L2 المشتقة من الحدث المودع للمعاملة ، سيكون بوب نفسه هو البادئ ؛ سيكون المتلقي هو عقد Uniswap ؛ وسيتضمن ETH المحدد ، تماما كما لو كان بوب يبدأ معاملة L2 بنفسه.

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

تقوم
القيم المتبقية في عمود البيانات غير الشفافة بتشفير معلومات مثل "مقدار ETH الشخص الذي يتصل بوظيفة الإيداع Transaction المرفقة" و "مقدار ETH الذي يريد بادئ معاملة L2 إرساله إلى جهاز الاستقبال" و "GasLimit" لمعاملة L2 و "بيانات جهاز استقبال L2". بعد فك تشفير هذه المعلومات ، ستحصل على التفاصيل التالية: "كم ETH الشخص الذي يتصل بالإيداعالمعاملة المرفقة": 0 ، لأنني لا أودع ETH من L1 إلى L2 ؛ "كم ETH يريد بادئ المعاملة L2 إرساله إلى المستلم": 5566 (wei) ؛ "L2 معاملة GasLimit": 50000 ؛ "بيانات جهاز الاستقبال L2": 0x666f72636520696e636c7573696f6e ، وهو الترميز السداسي العشري للسلسلة "تضمين القوة". بعد فترة وجيزة ، ظهرت معاملة L2 المحولة: معاملة L2 حيث أقوم بنقل 5566 wei إلى نفسي ، مع حقل البيانات الذي يحتوي على السلسلة "تضمين القوة". بالإضافة إلى ذلك ، في السطر الثاني إلى الأخير من قسم السمات الأخرى ، يظهر TxnType (نوع المعاملة) كمعاملة نظام 126 (نظام) ، مما يشير إلى أن هذه المعاملة لم أبدأها على L2 ولكن تم تحويلها من الحدث المودع لمعاملة L1.

تحويل معاملة L2

إذا كنت ترغب في استدعاء عقد L2 من خلال فرض التضمين وإرسال بيانات مختلفة ، فأنت تحتاج ببساطة إلى ملء المعلمات في وظيفة depositTransaction. فقط تذكر استخدام نفس عنوان L1 مثل الحساب L2 الخاص بك عند الاتصال بوظيفة depositTransaction. بهذه الطريقة ، عندما يتم تحويل الحدث المودع إلى معاملة L2 ، سيكون البادئ هو الحساب L2 الخاص بك. نافذة التسلسل عقدة Optimism L2 التي تحول حدث المعاملة المودعة إلى معاملة L2 هي في الواقع جهاز التسلسل. نظرا لأن هذا يتضمن ترتيب المعاملات ، يمكن لجهاز التسلسل فقط تحديد وقت تحويل الحدث إلى معاملة L2. عندما يستمع Sequencer إلى الحدث TransactionDeposited ، فإنه لا يقوم بالضرورة بتحويل الحدث إلى معاملة L2 على الفور ؛ يمكن أن يكون هناك تأخير. الحد الأقصى لمدة هذا التأخير يسمى نافذة التسلسل. حاليا ، نافذة التسلسل على شبكة Optimism الرئيسية هي 24 ساعة. هذا يعني أنه عندما يقوم المستخدم بإيداع الأموال من L1 أو يستخدم Force Inclusion لإجراء معاملة ، في أسوأ السيناريوهات ، سيتم تضمينها في سجل معاملات L2 بعد 24 ساعة.

آلية إدراج قوة التحكيم

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

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

عندما يكتب جهاز التسلسل معاملات جديدة، يمكن أن يتضمن أيضا معاملات من DelayedInbox.

التصميم المعقد ونقص المواد المرجعية

إذا قمت بالرجوع إلى الوثائق الرسمية ل Arbitrum حول Sequencer و Force Inclusion، فستجد شرحا عاما لكيفية عمل Force Inclusion ، إلى جانب بعض أسماء المعلمات والوظائف: يقوم المستخدمون أولا باستدعاء وظيفة sendUnsignedTransaction في عقد DelayedInbox. إذا لم يقم جهاز التسلسل بتضمينه في غضون 24 ساعة تقريبا، فيمكن للمستخدمين استدعاء الدالة forceInclusion في عقد SequencerInbox. ومع ذلك ، لا توفر الوثائق الرسمية روابط لهذه الوظائف ، لذلك عليك البحث عنها في رمز العقد بنفسك. عندما تجد وظيفة sendUnsignedTransaction ، فإنك تدرك أنه يجب عليك ملء قيمة nonce وقيمة maxFeePerGas بنفسك. لمن nonce؟ ما هي الشبكة maxFeePerGas؟ كيف يجب أن تملأها بشكل صحيح؟ لا توجد وثائق مرجعية ، ولا حتى NatSpec. ستجد أيضا العديد من الوظائف المماثلة في عقد Arbitrum: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. لا توجد مستندات تشرح الاختلافات بين هذه الوظائف ، أو كيفية استخدامها ، أو كيفية ملء المعلمات ، ولا حتى NatSpec.

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

الخلاصة: يعد إنشاء معاملة قسرية يدويا على Arbitrum أمرا معقدا للغاية. يوصى باتباع البرنامج التعليمي الرسمي واستخدام Arbitrum SDK. على عكس Rollups الأخرى ، يفتقر Arbitrum إلى وثائق المطور الواضحة والتعليقات التوضيحية للتعليمات البرمجية. تفتقر العديد من الوظائف إلى تفسيرات لأغراضها ومعلماتها ، مما يتسبب في قضاء المطورين وقتا أطول بكثير مما كان متوقعا لدمجها واستخدامها. طلبت أيضا المساعدة في Arbitrum Discord ، لكنني لم أتلق إجابات مرضية. عند السؤال على Discord ، وجهوني فقط للنظر في sendL2Message ولم يشرحوا وظائف الطرق الأخرى (بما في ذلك تلك المذكورة في وثائق تضمين القوة مثل sendUnsignedTransaction) ، أو أغراضها ، أو كيفية استخدامها ، أو متى يتم استخدامها.

StarkNet's ForceInclusion آلية

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

يتم التعامل مع آلية zkSync لنقل الرسائل L1->L2 وتضمين القوة من خلال وظيفة requestL2Transaction لعقد MailBox. يحدد المستخدمون عنوان L2 وبيانات الاتصال ومقدار ETH المراد إرفاقه وقيمة L2GasLimit وتفاصيل أخرى. تجمع الدالة requestL2Transaction هذه المعلمات في معاملة L2 وتضعها في قائمة انتظار الأولوية. عندما يقوم جهاز التسلسل بحزم المعاملات وتحميلها إلى L1 (عبر وظيفة commitBatches) ، فإنه يشير إلى عدد المعاملات التي يجب أخذها من PriorityQueue لتضمينها في سجلات معاملات L2. من حيث تضمين القوة ، يشبه zkSync التفاؤل ، حيث يتم استخدام عنوان L2 الخاص بالبادئ (نفس عنوان L1) لاستدعاء الوظائف ذات الصلة وملء التفاصيل الضرورية (المتصل ، بيانات الاتصال ، إلخ) ، بدلا من الإعجاب Arbitrum ، الذي يتطلب معاملة L2 موقعة. ومع ذلك ، في التصميم ، يشبه Arbitrum ، حيث يحتفظ كلاهما بقائمة انتظار على L1 ، ويأخذ Sequencer المعاملات المعلقة التي يرسلها المستخدمون مباشرة من قائمة الانتظار ويكتبها في سجل المعاملات.

إذا قمت إيداع ETH من خلال الجسر الرسمي ل zkSync، مثل هذه المعاملة، فإنه يستدعي وظيفة requestL2Transaction لعقد MailBox. تضع هذه الدالة معاملة إيداع ETH L2 في قائمة انتظار الأولوية وتصدر حدث NewPriorityRequest. نظرا لأن العقد يشفر بيانات معاملة L2 في سلسلة من البايتات ، فلا يمكن قراءتها بسهولة. ومع ذلك ، إذا نظرت إلى معلمات معاملة L1 هذه ، فسترى أن مستلم L2 هو أيضا البادئ بالمعاملة (لأنه إيداع لنفسه). بعد مرور بعض الوقت ، عندما يأخذ Sequencer معاملة L2 هذه من PriorityQueue ويدرجها في سجل المعاملات ، سيتم تحويلها إلى معاملة L2 حيث تقوم بالتحويل إلى نفسك. سيكون مبلغ التحويل هو المبلغ ETH المرفقة من قبل البادئ في معاملة ETH إيداع L1. في معاملة إيداع L1، يتم 0xeDc1 كل من البادئ والمستلم ... 6909 ، المبلغ 0.03 ETH ، ولا توجد بيانات اتصال. في L2 ، ستكون هناك معاملة حيث 0xeDc1 ... 6909 ينقل إلى نفسه. نوع المعاملة (TxnType) هو 255 ، مما يشير إلى معاملة النظام. بعد ذلك ، تماما كما جربت وظيفة المعاملة القسرية على Optimism من قبل ، اتصلت بوظيفة requestL2Transaction الخاصة ب zkSync وبدأت معاملة نقل ذاتي: لم يتم إرفاق أي ETH ، واحتوت بيانات المكالمة على ترميز HEX للسلسلة "تضمين القوة". ثم تم تحويل هذا إلى معاملة L2 حيث أقوم بالتحويل إلى نفسي ، مع بيانات المكالمة التي تحتوي على السلسلة السداسية العشرية ل "تضمين القوة": 0x666f72636520696e636c7573696f6e. عندما يأخذ جهاز التسلسل المعاملات من PriorityQueue ويكتبها في محفوظات المعاملات، يتم تحويلها إلى معاملات L2 المقابلة. باستخدام وظيفة requestL2Transaction ، يمكن للمستخدمين إرسال البيانات على L1 بنفس الحساب L1 مثل عنوان L2 الخاص بهم ، مع تحديد مستلم L2 ، ومقدار ETH الذي يجب إرفاقه ، وبيانات المكالمة. إذا أراد المستخدمون الاتصال بعقود أخرى أو تضمين بيانات مختلفة ، فإنهم يحتاجون ببساطة إلى ملء المعلمات في وظيفة requestL2Transaction. لا توجد وظيفة تضمين القوة للمستخدمين حتى الآن على الرغم من أن معاملة L2 الموضوعة في PriorityQueue سيكون لها فترة انتظار محسوبة لإدراجها بواسطة Sequencer ، إلا أن التصميم الحالي ل zkSync لا يحتوي على وظيفة تضمين القوة التي تسمح للمستخدمين بفرضها. هذا يعني أنه حل جزئي فقط. على الرغم من وجود "فترة انتظار للإدراج" ، إلا أن ذلك يعتمد في النهاية على ما إذا كان جهاز التسلسل يقرر تضمينه: يمكن ل Sequencer تضمينه بعد انتهاء الفترة أو عدم تضمين أي معاملات من PriorityQueue. في المستقبل ، يجب أن تضيف zkSync وظائف تسمح للمستخدمين بتضمين المعاملات بالقوة في سجل معاملات L2 إذا لم يتم تضمينها بواسطة Sequencer بعد فترة الانتظار. ومن شأن ذلك أن يكون آلية فعالة حقا لإدراج القوة. يعتمد Summarize

L1 على عدد كبير من المدققون لضمان "أمان" الشبكة و"مقاومة الرقابة". ومع ذلك ، فإن عمليات التجميع لها مقاومة الرقابة أضعف لأن المعاملات تتم كتابتها بواسطة عدد قليل أو حتى جهاز تسلسل واحد. لذلك ، تحتاج Rollups إلى آلية تضمين القوة للسماح للمستخدمين بتجاوز Sequencer وكتابة المعاملات في السجل ، ومنع الرقابة من قبل Sequencer من جعل Rollup غير قابل للاستخدام ومنع المستخدمين من سحب الأموال. يسمح فرض التضمين للمستخدمين بكتابة المعاملات بالقوة في السجل ، ولكن يجب أن يختار التصميم ما إذا كان "يمكن إدراج المعاملات على الفور في السجل وتصبح سارية المفعول على الفور". إذا تم السماح بالتأثير الفوري ، فسيؤثر ذلك سلبا على جهاز التسلسل لأن المعاملات المعلقة على L2 يمكن أن تتأثر بالمعاملات المضمنة قسرا من L1. لذلك ، فإن آليات تضمين القوة الحالية في Rollups تضع أولا المعاملات المدرجة من L1 في حالة انتظار وتمنح جهاز التسلسل نافذة زمنية للرد وتحديد ما إذا كان سيتم تضمين هذه المعاملات المعلقة. يحتفظ كل من zkSync و Arbitrum بقائمة انتظار على L1 لإدارة معاملات L2 أو الرسائل المرسلة من L1 إلى L2. يسميها Arbitrum DelayedInbox. zkSync يسميها PriorityQueue. ومع ذلك ، فإن طريقة zkSync لإرسال معاملات L2 تشبه إلى حد كبير Optimism ، حيث يتم إرسال الرسائل من L1 باستخدام عنوان L2 ، بحيث يكون البادئ هو عنوان L2 عند تحويله إلى معاملة L2. تسمى وظيفة إرسال معاملات L2 في Optimism depositTransaction. في zkSync ، يطلق عليه requestL2Transaction. في المقابل ، ينشئ Arbitrum معاملة L2 كاملة ويوقعها ، ثم يرسلها من خلال وظيفة sendL2Message. في L2 ، يستخدم Arbitrum التوقيع لاستعادة الموقع كبادئ لمعاملة L2. ليس لدى StarkNet حاليا آلية لإدراج القوة. يحتوي zkSync على آلية تضمين فرض نصف مطبقة - يحتوي على PriorityQueue ، وكل معاملة L2 في قائمة الانتظار لها فترة صلاحية تضمين ، ولكن فترة الصلاحية هذه مخصصة حاليا للعرض فقط. في الممارسة العملية ، يمكن ل Sequencer اختيار عدم تضمين أي معاملات L2 من PriorityQueue.

إخلاء المسؤولية:

1. تمت إعادة توجيه هذه المقالة من: [Geek Web3] ، العنوان الأصلي هو "النظرية والتطبيق: كيفية تشغيل المعاملات المقاومة للرقابة في إثيريوم Rollup؟" ، إسناد حقوق الطبع والنشر إلى المؤلف الأصلي [NIC Lin ، رئيس Taipei إثيريوم Meetup] ، إذا كان لديك أي اعتراض على إعادة الطبع ، يرجى الاتصال Gate Learn Team، سيقوم الفريق بالتعامل معها في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.

2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة تمثل فقط وجهات نظر المؤلف الشخصية ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة إصدارات اللغات الأخرى من المقالة بواسطة فريق Gate Learn. بدون الرجوع إلى Gate.io، يحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.