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

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

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

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

وصف موجز لجهاز التسلسل التراكمي

يمكن تلخيص مبدأ توسيع نطاق التراكمي في نقطتين:

تحسين التكلفة: قم بإلغاء تحميل معظم مهام الحوسبة والتخزين إلى L1 خارج السلسلة ، أي L2. ** L2 هو في الغالب سلسلة تعمل على خادم واحد ، أي جهاز تسلسل / مشغل.

يبدو جهاز التسلسل قريبا من خادم مركزي ، متخليا عن “اللامركزية” في “Blockchain Impossible Three Times” مقابل TPS ومزايا التكلفة. يمكن للمستخدمين السماح ل L2 بمعالجة تعليمات المعاملات بدلا من Ethereum بتكلفة أقل بكثير من التداول على Ethereum.

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

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

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

تنقسم طرق التحقق من الحالة لمنع جهاز التسلسل التراكمي من أن يكون شريرا إلى نوعين: إثبات الاحتيال وإثبات الصلاحية. تسمى عمليات التجميع التي تستخدم إثباتات الاحتيال OP مجموعات (مجموعات متفائلة ، OPRs) ، وبسبب بعض الأمتعة التاريخية ، غالبا ما تسمى المجموعات التي تستخدم إثباتات الصلاحية ZK Rollups (مجموعات إثبات المعرفة الصفرية ، ZKR) بدلا من مجموعات الصلاحية.

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

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

في هذه المقالة ، سوف نقدم Depth Arbitrum One ، المشروع الرائد في عمليات التجميع المتفائلة ، والتي تغطي جميع جوانب النظام بأكمله ، وبعد القراءة بعناية ، سيكون لديك فهم عميق ل Arbitrum و rollup المتفائل / OPR.

المكونات الأساسية ل Arbitrum وسير العمل

العقود الأساسية:

تشمل أهم عقود Arbitrum SequencerInbox و DelayedInbox و L1 Gateways و L2 Gateways و Outbox و RollupCore و Bridge وما إلى ذلك. المزيد عن ذلك لاحقا.

المنظم:

يتم استلام معاملات المستخدم وفرزها ، ويتم حساب نتائج المعاملات ، ويتم إرجاع إيصال إلى المستخدم بسرعة (عادة < 1s). يمكن للمستخدمين في كثير من الأحيان رؤية معاملاتهم على سلسلة L2 في غضون ثوان ، تماما مثل منصة Web2.

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

كل بضع دقائق ، سيقوم جهاز التسلسل بضغط بيانات معاملة L2 التي تم فرزها ، وتجميعها على دفعات ، وإرسالها إلى عقد البريد الوارد SequencerInbox على الطبقة 1 لضمان توفر البيانات وتشغيل بروتوكول Rollup. بشكل عام ، لا يمكن التراجع عن بيانات L2 المقدمة إلى الطبقة 1 ويمكن إنهائها.

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

بروتوكول التحكيم:

سلسلة من العقود التي تحدد هيكل كتلة RBlock لسلسلة Rollup ، واستمرار السلسلة ، وإصدار RBlock ، وعملية وضع التحدي. لاحظ أن سلسلة Rollup المذكورة هنا ليست دفتر أستاذ Layer2 كما نفهمه ، ولكنها “بنية بيانات سلسلة” مجردة أنشأتها Arbitrum One من أجل تنفيذ آلية مقاومة للاحتيال.

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

مدقق:

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

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

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

التحدي:

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

فترة التحدي:

نظرا للطبيعة المتفائلة ل OP Rollup ، بعد تقديم كل RBlock إلى السلسلة ، لا يتحقق العقد منه بنشاط ، مما يترك نافذة زمنية للمدققين للتزوير. هذه النافذة الزمنية هي فترة التحدي ، وهي 1 أسبوع على Arbitrum One Mainnet. بعد انتهاء فترة التحدي ، سيتم الانتهاء من RBlock ، ويمكن إصدار الرسالة المقابلة من L2 إلى L1 في الكتلة (مثل عملية السحب التي يتم إجراؤها عبر الجسر الرسمي).

ArbOS ، Geth ، WAVM:

الجهاز الظاهري الذي يستخدمه Arbitrum يسمى AVM ، والذي يتكون من جزأين: Geth و ArbOS. Geth هو برنامج العميل الأكثر استخداما في Ethereum ، وقد أجرى Arbitrum تعديلات خفيفة عليه. ArbOS مسؤول عن جميع الوظائف الخاصة المتعلقة ب L2 ، مثل إدارة موارد الشبكة ، وإنشاء كتل L2 ، والعمل مع EVM ، وما إلى ذلك. نفكر في الجمع بين الاثنين على أنه AVM أصلي ، وهو الجهاز الظاهري الذي يستخدمه Arbitrum. WAVM هو نتيجة تجميع كود AVM في Wasm. في عملية تحدي Arbitrum ، يتحقق “إثبات الخطوة الواحدة” النهائي من تعليمات WAVM.

هنا ، يمكننا توضيح العلاقة وسير العمل بين المكونات المذكورة أعلاه في الرسم البياني التالي:

دورة حياة معاملة L2

إليك كيفية عمل معاملة L2:

1. يرسل المستخدم تعليمات تداول إلى جهاز التسلسل.

2. يتحقق جهاز التسلسل أولا من البيانات مثل التوقيع الرقمي للمعاملة المراد معالجتها ، ويزيل المعاملة غير الصالحة ، ويفرز ويحسب.

3. يرسل جهاز التسلسل إيصال المعاملة إلى المستخدم (عادة ما يكون سريعا جدا) ، ولكن هذه ليست سوى “المعالجة المسبقة” لسلسلة جهاز التسلسل خارج ETH ، والتي تكون في حالة نهائية ناعمة وغير موثوقة. ولكن بالنسبة للمستخدمين الذين يثقون في جهاز التسلسل (معظم المستخدمين) ، فمن المتفائل أن المعاملة قد اكتملت ولن يتم التراجع عنها.

4. يقوم جهاز التسلسل بتغليف البيانات الأولية للمعاملة المعالجة مسبقا في دفعة بعد الضغط العالي.

5. من حين لآخر (تتأثر بعوامل مثل حجم البيانات ، ETH الازدحام ، وما إلى ذلك) ، سينشر جهاز التسلسل دفعات المعاملات إلى عقد Sequencer Inbox على L1. في هذه المرحلة ، يمكن اعتبار المعاملة نهائية صعبة.

عقد علبة وارد جهاز التسلسل

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

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

عقد علبة وارد Sequencer ، المعروف أيضا باسم Fastbox ، هو جهاز تسلسل يرسل المعاملات التي تمت معالجتها مسبقا إليه ، ويمكن فقط لجهاز التسلسل إرسال البيانات إليه. المربع السريع المقابل هو المربع البطيء Delayer Inbox ، وسيتم وصف وظائفه في العملية اللاحقة.

سيستمع المدقق دائما إلى عقد SequencerInbox ، وكلما أصدر جهاز التسلسل دفعة للعقد ، فإنه سيلقي حدثا على السلسلة ، وبعد أن يسمع المدقق هذا الحدث ، سيقوم بتنزيل بيانات الدفعات ، وبعد التنفيذ المحلي ، سيصدر RBlock إلى عقد بروتوكول Rollup على سلسلة ETH.

يحتوي عقد جسر Arbitrum على معلمة تسمى المجمع ، والتي ستسجل عدد دفعات L2 المقدمة حديثا ، بالإضافة إلى عدد المعاملات المستلمة حديثا والمعلومات المتعلقة بالبريد الوارد البطيء.

يحتوي عقد SequencerInbox على وظيفتين رئيسيتين:

إضافة جهاز التسلسل L2Batch From Origin() ، والذي يستدعيه جهاز التسلسل في كل مرة لإرسال بيانات الدفعات إلى عقد Sequencer Inox.

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

تستدعي كلتا الدالتين bridge.enqueueSequencerMessage() لتحديث مجمع معلمة المجمع في عقد الجسر.

تسعير الغاز

من الواضح أن معاملات L2 لا يمكن أن تكون مجانية بسبب هجمات DoS ، وتكاليف تشغيل جهاز التسلسل L2 نفسه ، والنفقات العامة لتقديم البيانات على L1. عندما يبدأ المستخدم معاملة داخل شبكة الطبقة 2 ، يتم تنظيم رسوم الغاز على النحو التالي:

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

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

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

دليل متفائل على الاحتيال

للتلخيص ، L2 هو في الحقيقة مجرد إسقاط لإدخال الدفعات للمعاملات المقدمة بواسطة جهاز التسلسل في Fastbox ، أي:

مدخلات المعاملات -> STF -مخرجات حالة >。 يتم تحديد الإدخال ، و STF ثابت ، ويتم تحديد الإخراج أيضا ، ونظام إثبات الاحتيال وبروتوكول Arbitrum Rollup هو نظام ينشر جذر حالة الإخراج إلى L1 في شكل RBlock (المعروف أيضا باسم التأكيد) ويثبت ذلك بتفاؤل.

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

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

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

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

في هذه المرحلة ، سيسألك عقد الطبقة 1: ما هي حالتك في الطبقة 2 ، وكيف يمكنك إثبات أنك تمتلك حقا الأصول التي تدعي عبورها. في هذا الوقت ، يجب على المستخدم تقديم دليل Merkle المقابل ، إلخ.

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

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

ميزة هذا التصميم هي أنه ليست هناك حاجة للتحقق بنشاط من صحة كل RBlock منشور على L1 لتجنب إهدار الغاز. في الواقع ، ليس من العملي أن تتحقق OPR من كل تأكيد ، لأن كل rblock يحتوي على كتلة L2 واحدة أو أكثر ، ولا يختلف عن تنفيذ معاملات L2 مباشرة على L1 لإعادة تنفيذ كل معاملة على L1 ، مما يفقد معنى تحجيم الطبقة 2.

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

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

بروتوكول التراكمي

دعنا نلقي نظرة على كيفية عمل بروتوكول Rollup ، نقطة الدخول لبدء التحديات وإطلاق البراهين.

العقد الأساسي لبروتوكول Rollup هو RollupProxy.sol ، والذي يستخدم بنية وكيل مزدوجة نادرة لضمان اتساق بنية البيانات ، وكيل واحد يتوافق مع تطبيقين من RollupUserLogic.sol و RollupAdminLogic.sol ، والتي لا يمكن تحليلها بشكل جيد في أدوات مثل Scan.

بالإضافة إلى ذلك ، هناك عقد ChallengeManager.sol لإدارة التحدي ، وسلسلة عقود OneStepProver لتحديد أدلة الاحتيال.

في RollupProxy ، يتم تسجيل سلسلة من RBlocks (المعروفة أيضا باسم التأكيدات) المقدمة من مدققين مختلفين ، وهي المربعات في الرسم البياني التالي: أخضر - مؤكد ، أزرق - غير مؤكد ، أصفر - مزور.

يحتوي RBlock على الحالة النهائية لكتلة L2 واحدة أو أكثر بعد التنفيذ منذ آخر RBlock. تشكل هذه RBlocks شكليا سلسلة تراكمية رسمية (لاحظ أن دفتر الأستاذ L2 نفسه مختلف). في سيناريو متفائل ، لا ينبغي أن تكون سلسلة Rollup هذه متشعبة ، لأن وجود شوكة يعني أن هناك مدققين أرسلوا كتل تراكمية متضاربة.

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

سيتم تزوير الكتلة الزرقاء 111 في الركن الأيمن السفلي من الصورة في النهاية لأن الكتلة الأصلية 104 هي كتلة خاطئة (صفراء).

بالإضافة إلى ذلك ، يقترح المدقق A Rollup Block 106 ، بينما لا يوافق B ، ويتحداه.

بعد أن يبدأ B تحديا، يكون عقد ChallengeManager مسؤولا عن التحقق من صحة تفاصيل خطوات التحدي:

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

2. بعد ذلك ، يمكنك الاستمرار في تحديد المعاملة والنتيجة التي تمثل مشكلة ، ثم تقسيمها إلى تعليمات آلية متنازع عليها في تلك المعاملة.

3. يتحقق عقد ChallengeManager فقط مما إذا كانت “أجزاء البيانات” التي تم إنشاؤها صالحة بعد تقسيم البيانات الأصلية.

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

إثبات من خطوة واحدة

البراهين أحادية الخطوة هي في صميم براهين الاحتيال في جميع أنحاء Arbitrum. دعونا نلقي نظرة على ما يثبته دليل الخطوة.

وهذا يتطلب فهم WAVM, Wasm Arbitrum Virtual Machine, وهو جهاز افتراضي تم تجميعه من وحدات ArbOS والوحدات الأساسية Geth (عميل Ethereum). نظرا لأن L2 يختلف تماما عن L1 من نواح كثيرة ، كان لا بد من تعديل جوهر Geth الأصلي بشكل طفيف والعمل مع ArbOS.

لذا ، فإن انتقالات الحالة على L2 هي في الواقع سمة شائعة ل ArbOS + Geth Core.

يقوم عميل عقدة Arbitrum (جهاز التسلسل ، المدقق ، العقدة الكاملة ، إلخ) بتجميع البرنامج الذي تمت معالجته بواسطة ArbOS + Geth Core أعلاه في رمز الجهاز الأصلي (ل x86 / ARM / PC / Mac / إلخ) الذي يمكن معالجته مباشرة بواسطة مضيف العقدة.

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

السبب الرئيسي هو أن العقد الذي يتحقق من إثبات الاحتيال بخطوة واحدة يستخدم EthereumSmart Contract لمحاكاة جهاز افتراضي VM يمكنه التعامل مع مجموعة معينة من مجموعات التعليمات ، و WASM سهل التنفيذ على العقد.

ومع ذلك ، فإن WASM أبطأ قليلا من رمز الجهاز الأصلي ، لذلك لن يتم استخدام WAVM إلا بواسطة عقدة / عقد Arbitrum عند إنشاء أدلة الاحتيال والتحقق منها.

بعد الجولات السابقة من تجزئة التفاعل ، أثبت إثبات الخطوة الواحدة في النهاية أنه تعليمات الخطوة الواحدة في مجموعة تعليمات WAVM.

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

ستعود النتيجة النهائية ل afterHash إلى ChallengeManager ، وإذا كانت التجزئة غير متوافقة مع التجزئة المسجلة في كتلة Rollup ، فسيكون التحدي ناجحا. إذا كان متسقا ، فهذا يعني أن نتيجة تنفيذ التعليمات المسجلة على كتلة التجميع جيدة ، ويفشل التحدي.

في المقالة التالية ، سنقوم بتحليل وحدات العقد التي تتعامل مع وظائف التفاعل / التجسير عبر السلسلة بين Arbitrum وحتى الطبقة 2 والطبقة 1 ، ونوضح بشكل أكبر كيف يجب أن تكون الطبقة 2 الحقيقية مقاومة للرقابة.