النظرية والتطبيق: كيف يتم تفعيل المعاملات المقاومة للرقابة في Ethereum Rollup؟

المؤلف: NIC Lin، الشخص المسؤول عن Taipei Ethereum Meetup

العنوان الأصلي: "مقدمة إلى آلية تضمين القوة المجمعة"

بالأمس فقط حدث شيء صدم عددًا لا يحصى من الأشخاص: < قوي> تم إغلاق Linea، الطبقة الثانية من Ethereum التي أطلقتها شركة Consensys، الشركة الأم لـ Metamask، بشكل استباقي. وهذا لا يسعه إلا أن يذكر الناس بالإغلاق السابق لسلسلة BSC (سلسلة BNB) بموجب تنسيق رسمي من أجل تقليل الخسائر الناجمة عن هجمات القراصنة. عندما يتحدث الناس عن هذا النوع من الأشياء، فإنهم سوف يشككون في القيمة اللامركزية التي يدعو إليها Web3.

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

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

في السنوات القليلة الماضية، اقترحت الطبقات الثانية الرئيسية من الإيثريوم حلولًا مختلفة لمشكلة مكافحة الرقابة، مثل Loopring وDegate، والسحب القسري لـ StarkEx ووظائف مقصورة الهروب، وArbitrum وغيرها من وظائف Force Inclusion. من OP Rollup، يمكن لهذه الأساليب فحص وموازنة التسلسل في ظل ظروف معينة لمنعه من رفض أي طلب معاملة خاص بالمستخدم بشكل غير معقول.

في مقال اليوم، يقدم NIC Lin من جمعية Taipei Ethereum حسابه الخاص. وهو يجرب شخصيًا وظائف المعاملات المقاومة للرقابة لأربعة مجموعات رئيسية، ويقدم تحليلًا متعمقًا من جوانب مثل كطرق سير العمل والتشغيل، مع تصميم آلية الدمج Force، يعد هذا ذا قيمة خاصة لمجتمع Ethereum وكبار المستثمرين الذين يمتلكون كميات هائلة من الأصول.

مراجعة المعاملات وفرض الإدراج

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

ملاحظة: في هيكل PBS الحالي لـ Ethereum، سيتم تخفيض تكلفة مراجعة المعاملات كثيرًا يمكنك الرجوع إلى نسبة الكتل التي تتعاون مع OFAC لمراجعة معاملات Tornado Cash . تعتمد مقاومة الرقابة الحالية على محققين مستقلين ومرسلين خارج نطاق ولاية مكتب مراقبة الأصول الأجنبية والولاية القضائية الحكومية.

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

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

آلية فرض الدمج

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

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

لا يستطيع جهاز التسلسل مراجعة معاملات L1 الخاصة بالمستخدم دون دفع تكلفة عالية

كيف يجب فرض ذلك المعاملات نافذة المفعول؟

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

إذا كان بإمكان فرض التضمين كتابة المعاملة مباشرة في العقد التراكمي ودخولها حيز التنفيذ على الفور، فستتغير الحالة على الفور

إذا كان المُسلسِل يجمع أيضًا المعاملات خارج السلسلة في هذا الوقت ويرسل الدفعة التالية من المعاملات إلى عقد التجميع، فقد يتأثر بالمعاملات التي يُدرجها بوب قسرًا وتصبح سارية المفعول على الفور. يجب تجنب هذا النوع من المشاكل قدر الإمكان، لذلكلا يؤدي التحديث الإجمالي عمومًا إلى تفعيل معاملة فرض التضمين على الفور، وبدلاً من ذلك، يسمح أولاً للمستخدم بإدراج المعاملة في قائمة انتظار الانتظار على L1 وإدخال ". تحضير "الدولة.

عندما يقوم Sequencer بحزم المعاملات خارج السلسلة وإرسالها إلى عقد التجميع، فإنه يختار ما إذا كان سيتم إدراج المعاملات المذكورة أعلاه في تسلسل المعاملات إذا استمر Sequencer في تجاهل هذه المعاملات في "إعداد" معاملات الحالة، بعد انتهاء فترة النافذة، يمكن للمستخدمين إدراج هذه المعاملات بقوة في عقد القيمة المجمعة.

يمكن لجهاز التسلسل أن يقرر متى "يتلقى بالصدفة" المعاملات في قائمة الانتظار

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

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

بعد ذلك، سنقدم بالترتيب فرض التضمين لأربعة مجموعات تراكمية أكثر شهرة، بما في ذلك التفاؤل، والأربتروم، يتم تنفيذ آلية StarkNet وzkSync.

آلية تضمين قوة التفاؤل

قدم أولاً عملية إيداع التفاؤل. لا يشير هذا الإيداع إلى إيداع الأموال في التفاؤل فحسب، بل يشير أيضًا يتضمن "إرسال المعلومات التي أرسلها المستخدم إلى L2" إلى 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  ملاحظة: في بعض الصور في هذه المقالة، يتم كتابة CrossDomainMessager باسم CrossChainMessager

عقد OptimismPortal

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

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

ستقوم عقدة L2 بتحويل معلمة حدث المعاملة المودعة لـ OptimismPortalemit إلى معاملة L2

على سبيل المثال، هذا< strong> قام أحد المستخدمين بإيداع 0.01ETH من خلال عقد L1StandardBridge، وتم إرسال هذه الرسالة وETH إلى عقد OptimismPortal (العنوان هو 0xbEb5...06Ed)، ثم تم تحويلهما إلى معاملة L2 بعد بضع دقائق: < /strong>

بادئ الرسالة هو عقد L1CrossDomainMessenger؛ والمتلقي هو عقد L2CrossDomainMessenger على L2؛ ومحتوى الرسالة هو أن L1StandardBridge تلقى إيداع BoB بقيمة 0.01ETH. بعد ذلك، سيتم تشغيل بعض العمليات، مثل إصدار 0.01 ETH إضافية إلى L2StandardBridge، والتي سيتم بعد ذلك نقلها إلى Bob.

كيفية تفعيلها على وجه التحديد

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

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

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

إذا كنت تريد استدعاء وظيفة Force Inclusion الخاصة بـ Optimism، فيجب عليك الاتصال مباشرة بـ وظيفة وديعة المعاملات لعقد OptimismPortal وإضافة ملء معلمات المعاملة المنفذة على L2

لقد قمت بإجراء تجربة فرض التضمين البسيطة.تريد هذه المعاملة تحقيقها شيء واحد: في L2 استخدم عنواني للتحويل الذاتي (0xeDc1...6909) مع رسالة نصية "فرض التضمين".

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

يتم ترميز القيمة الموجودة في عمود البيانات المعتم المتبقي بـ "call" ما مقدار ETH الذي تجلبه وظيفة معاملة الإيداع، و"كم من ETH الذي يريد بادئ معاملة L2 إرساله إلى المستلم"، و"معاملة L2 GasLimit" و"البيانات إلى مستلم L2" ومعلومات أخرى.

بعد فك تشفير المعلومات المذكورة أعلاه، ستحصل على:

"كم تم إرفاق مبلغ ETH بواسطة الشخص الذي اتصل بمعاملة الإيداع": < /strong>0 ، لأنني لا أقوم بإيداع ETH من L1 إلى L2؛

"ما مقدار ETH الذي يريد بادئ معاملة L2 إرساله إلى المستلم": 5566 (wei) )

< p>"GasLimit لمعاملة L2": 50000

"بيانات مستلم L2":0x666f72636520696e636c7573696f6e، وهي الكلمة "فرض التضمين" التشفير السداسي العشري للسلسلة

بعد فترة ليست طويلة، ظهرت معاملة L2 المحولة: معاملة L2 قمت فيها بتحويل الأموال إلى نفسي.كان المبلغ 5566 وي ، وكانت البيانات عبارة عن سلسلة "فرض التضمين". ويمكنك ملاحظة أن TxnType (نوع المعاملة) في السمات الأخرى في السطر الثاني إلى الأخير في الصورة يوضح معاملة النظام 126 (النظام)، مما يعني أن هذه المعاملة لم أبدأها في L2، ولكن تم إيداعها بواسطة L1 المعاملات المحولة من الأحداث.

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

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

SequencerWindow

تعمل عقدة Optimism L2 المذكورة سابقًا على تحويل حدث المعاملة المودعة إلى معاملة L2. في الواقع، تشير عقدة التفاؤل هذه إلى Sequencer ، هذه العلاقة بطلب المعاملات، لذلكفقط المُسلسل يمكنه تحديد متى يتم تحويل الحدث المذكور أعلاه إلى معاملة L2.

عند الاستماع إلى حدث TransactionDeposited، لا يقوم Sequencer بالضرورة بتحويل الحدث إلى معاملة L2 على الفور. يمكن أن يكون هناك تأخير. تسمى القيمة القصوى لهذه الفترة SequencerWindow.

تبلغ مدة نافذة التسلسل الحالية على شبكة Optimism الرئيسية 24 ساعة، أي أنه عندما يقوم المستخدم بإيداع مبلغ من المال من L1 أو القوة التي تتضمن معاملة، فإن السيناريو الأسوأ هو أنه سيتم تضمينه في. سجل المعاملات L2 بعد 24 ساعة.

آلية تضمين القوة في Arbitrum

ستؤدي عملية إيداع L1 في Optimism إلى إلقاء حدث إيداع المعاملة، والباقي هو انتظار تضمين المُسلسِل العملية المذكورة أعلاه؛ولكن في Arbitrum، سيتم تخزين العمليات التي تحدث على L1 (إيداع الأموال أو إرسال الرسائل إلى L2، وما إلى ذلك) في قائمة انتظار على L1، بدلاً من مجرد إلقاء حدث.

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

سيحتفظ Arbitrum بقائمة انتظار في عقد L1. إذا لم يقم مُسلسِل التسلسل بمعالجة المعاملات في قائمة الانتظار بشكل فعال، فعندما يحين الوقت، يمكن لأي شخص فرض إدراج المعاملات في قائمة الانتظار في سجل معاملات L2.

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

عندما يكتب Sequencer معاملة جديدة، يمكنك إخراج المعاملة من DelayedInbox وكتابتها معًاتصميم معقد ومواد مرجعية عديدة

إذا أشار القراء مباشرة إلى الفصل الرسمي لـ Arbitrum حول Sequencer and Force Inclusion، فسوف يرون أن Force مذكور فيه كيفية عمل التضمين تقريبًا، بالإضافة إلى بعض أسماء المعلمات وأسماء الوظائف:

ينتقل المستخدم أولاً إلى عقد DelayedInbox لاستدعاء sendUnsignedTransaction. إذا لم يتم تضمين Sequencer في غضون 24 ساعة تقريبًا، فيمكن للمستخدم استدعاء وظيفة forceInclusion في عقد SequencerInbox. ثم لم يقم مسؤول Arbitrum بإرفاق رابط الوظيفة بوثيقة الموقع الرسمي، لذلك يمكنك فقط إلقاء نظرة على الوظيفة المقابلة في رمز العقد بنفسك.

عندما تجد وظيفة sendUnsignedTransaction، تجد أنه يتعين عليك ملء قيمة nonce وقيمة maxFeePerGas بنفسك. أي عنوان هو nonce؟ على أي شبكة يتم تشغيل maxFeePerGas؟ ما هي أفضل طريقة لملء ذلك؟ لا يوجد مرجع للملف، ولا حتى Natpsec. ثم ستجد أيضًا مجموعة من الوظائف المشابهة في عقد Arbitrum:

sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. ولا يوجد أيضًا مستند يخبرك بالفرق بين هذه الوظائف وكيفية استخدامها لملء المعلمات، ولا حتى Natpsec.

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

sendL2Message

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

من كان يعلم أن "الرسالة المرسلة إلى المستوى الثاني من خلال فرض الدمج" ستكون في الواقع "معاملة موقعة من المستوى الثاني"؟ ولا توجد وثائق أو Natspec توضح متى وكيف يتم استخدام هذه الوظيفة.

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

عندما سألت على Discord، أخبرني الطرف الآخر فقط أن أنظر إلى sendL2Message، ولم يرغبوا في شرح وظائف الوظائف الأخرى (حتى sendUnsignedTransaction المذكورة في مستند Force Inclusion)، وما هي. استخدامها، وكيفية استخدامها، وما هي أوقات استخدامها.

آلية ForceInclusion في StarkNet

لسوء الحظ، ليس لدى StarkNet حتى الآن آلية ForceInclusion. لا يوجد سوى مقالتين تناقشان الرقابة والإدماج القسري في المنتدى الرسمي.

غير قادر على إثبات معاملة فاشلة

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

تتوقع StartNet تقديم وظيفة إثبات المعاملات الفاشلة في الإصدار v0.15.0، وبعد ذلك يجب أن يكون من الممكن تنفيذ آلية فرض الدمج بشكل أكبر.

آلية ForceInclusion الخاصة بـ zkSync

يتم إرسال رسائل L1->L2 الخاصة بـ zkSync وآلية Force Inclusion كلها من خلال requestL2Transaction لعقد MailBox عندما يكون بعد تنفيذ الوظيفة، يحدد المستخدم عنوان L2، وبيانات الاتصال، ومبلغ ETH الإضافي، وقيمة L2GasLimit، وما إلى ذلك. سيقوم requestL2Transaction بدمج هذه المعلمات في معاملة L2 ثم وضعها في قائمة انتظار الأولوية (سيقوم جهاز التسلسل بحزم المعاملة). عند التحميل إلى L1 (من خلال وظيفة CommitBatches)، قم بالإشارة إلى عدد المعاملات التي يجب أخذها من قائمة انتظار الأولوية وإدراجها في سجل معاملات L2.

يشبه zkSync إلى حد كبير Optimism في شكل Force Inclusion. ويستخدم كلاهما عنوان L2 الخاص بالبادئ (المتوافق مع عنوان L1) لاستدعاء الوظائف ذات الصلة وملء البيانات ( يتم استلامها من قبل المتصل وبيانات الاتصال وما إلى ذلك)، بدلاً من ملء معاملة L2 موقعة مثل Arbitrum، ولكن في التصميم، فهي مماثلة لـ Arbitrum، حيث تحافظ على قائمة انتظار في L1، ويأخذها جهاز التسلسل من إخراج قائمة الانتظار المعلقة؛ المعاملات المقدمة مباشرة من قبل المستخدم وكتابتها في سجل المعاملات.

إذا ذهبت لإيداع ETH من خلال الجسر الرسمي لـ zkSync، بالنسبة لهذه المعاملة، فإنه يستدعي وظيفة requestL2Transaction لعقد MailBox، وسيضع معاملة L2 الخاصة بإيداع ETH في قائمة انتظار الأولوية ويطلق حدث NewPriorityRequest. نظرًا لأن العقد يقوم بتشفير بيانات معاملة L2 في سلسلة من البايتات، فمن الصعب قراءتها إذا نظرت إلى معلمات معاملة L1 هذه، فسترى أن مستلم L2 في المعلمات هو أيضًا بادئ المعاملة ( لأنها مودعة لنفسك)، لذلك بعد فترة من الوقت، عندما يتم إخراج معاملة L2 هذه من قائمة انتظار الأولوية بواسطة Sequencer وإدراجها في سجل المعاملة، سيتم تحويلها إلى معاملة تم نقلها إلى نفسها على L2، ومبلغ التحويل هو إيداع بادئ المعاملة في L1 مبلغ ETH المحمول في معاملة ETH.

في معاملة L1Deposit، يكون كل من بادئ المعاملة والمتلقي 0xeDc1...6909، والمبلغ 0.03ETH، وبيانات الاتصال فارغة

< p style="text-align: center;">

ستكون هناك معاملة 0xeDc1...6909 منقولة إلى نفسها على L2. نوع المعاملة (TxnType) هو 255، وهي معاملة نظام

ثم قمت باستدعاء وظيفة requestL2Transaction الخاصة بـ zkSync مباشرة وأرسلت تحويلاً ذاتيًا كما فعلت من قبل عندما جربت وظيفة المعاملة القسرية لـ OP: بدون أي ETH، جلبت بيانات الاستدعاء تشفير HEX لـ سلسلة "قوة التضمين".

ثم يتم تحويلها إلى معاملة L2 السابقة لنفسها. تحتوي بيانات الاستدعاء على سلسلة سداسية عشرية من "فرض التضمين": 0x666f72636520696e636c7573696f6e.

عندما يأخذ المُسلسِل المعاملة من قائمة انتظار الأولوية ويكتبها في سجل المعاملات، سيتم تحويلها إلى معاملة L2 المقابلة على L2

من خلال وظيفة requestL2Transaction، يمكن للمستخدمين استخدام حساب L1 بنفس عنوان عنوان L2، وإرسال المعلومات في L1، وتحديد مستلم L2، ومبلغ ETH المصاحب، وبيانات الاتصال. إذا أراد المستخدم استدعاء عقود أخرى ببيانات مختلفة، فسيتم ذلك عن طريق ملء المعلمات في وظيفة requestL2Transaction واحدًا تلو الآخر.

لا توجد وظيفة تسمح للمستخدمين بفرض التضمين

على الرغم من أنه بعد وضع معاملة L2 في قائمة انتظار الأولوية، سيتم حسابها بواسطة جهاز التسلسل توجد فترة انتظار للتضمين، ولكن لا توجد حاليًا وظيفة فرض التضمين التي يمكن للمستخدمين فرضها في تصميم zkSync، وهو ما يعادل نصف مجموعة فقط. وهذا يعني أنه على الرغم من وجود "فترة انتظار للتضمين"، إلا أنه في الواقع لا يزال "يرى ما إذا كان مُسلسِل التسلسل يريد تلقي الإيرادات": يمكن لمُسلسِل التسلسل الانتظار حتى انتهاء صلاحيته قبل تلقي المعاملة، أو لا يمكنه تلقي أي معاملات أبدًا في قائمة الانتظار ذات الأولوية.

في المستقبل، يجب على zkSync إضافة وظائف ذات صلة حتى يتمكن المستخدمون من فرض تضمين المعاملة في سجل معاملات L2 عند مرور فترة صلاحية الدخل ولكن لم يتم تضمينها بواسطة Sequencer آلية الإدماج الفعالة.

الملخص

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

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

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

يحتفظ كل من zkSync وArbitrum بقائمة انتظار في L1 لإدارة معاملات L2 التي يرسلها المستخدمون من L1 أو الرسائل إلى L2. يسمى Arbitrum DelayedInbox؛ ويسمى zkSync PriorityQueue

ولكن الطريقة التي يرسل بها zkSync معاملات L2 تشبه إلى حد كبير Optimism، حيث يستخدم كلاهما عنوان L2 لإرسال الرسائل إلى L1، والذي يحولها. إلى L2 بعد المعاملة، سيكون البادئ هو عنوان L2. تسمى وظيفة التفاؤل لإرسال معاملات L2 باسم "depositTransaction" ؛ ويسمى zkSync "requestL2Transaction". يقوم Arbitrum بإنشاء معاملة L2 كاملة وتوقيعها، ثم يرسلها من خلال وظيفة sendL2Message وسيقوم Arbitrum باستعادة المُوقع من خلال التوقيع على L2 باعتباره البادئ لمعاملة L2.

لا تحتوي StarkNet حاليًا على آلية فرض التضمين؛ يشبه zkSync نصف مجموعة فرض التضمين، مع قائمة انتظار الأولوية وكل معاملة L2 في قائمة الانتظار لها تاريخ انتهاء الصلاحية. لكن فترة الصلاحية هذه مخصصة حاليًا للزينة فقط. في الواقع، يمكن لـ Sequencer اختيار عدم تضمين أي معاملات L2 في PriorityQueue على الإطلاق

<. / ع>