نظرًا لوجود نقص في التفسير الاحترافي للمقالات أو المواد المتعلقة ببروتوكولات Layer2، خاصة بالنسبة لـ Arbitrum و OP Rollup، في المجتمع الصيني، تهدف هذه المقالة إلى سد هذه الفجوة من خلال شرح الآلية التشغيلية لـ Arbitrum. نظرًا لتعقيد Arbitrum نفسه، لا يزال النص الكامل، حتى بعد تبسيطه قدر الإمكان، يتجاوز 10000 كلمة. لذلك، يتم تقسيمها إلى قسمين، ويوصى بحفظها ومشاركتها كمواد مرجعية.»

نظرة عامة على مُسلسِل التجميع

يمكن تلخيص مبدأ تحجيم Rollup في نقطتين:

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

ويبدو جهاز التسلسل تقريبًا كخادم مركزي من حيث الإدراك، متخليًا عن اللامركزية في «الثالوث المستحيل لبلوكتشين» للحصول على مزايا في TPS والتكلفة. يمكن للمستخدمين استخدام L2 للتعامل مع تعليمات المعاملات بدلاً من Ethereum، بتكاليف أقل بكثير مقارنة بالمعاملات على Ethereum.

(المصدر: سلسلة BNB)

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

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

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

(يقوم بروتوكول Loopring بتعيين وظيفة السحب القسري في شفرة مصدر العقد على L1 للمستخدمين للاتصال بها)

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

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

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

(طريقة تشغيل التجميع المتفائلة)

(طريقة تشغيل ZK Rollup)

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

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

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

تشمل العقود الأكثر أهمية في Arbitrum صندوق التسلسل، و DelayenBox، و L1 Gateways، و L2، و Outbox، و RolluPCore، و Bridge، وما إلى ذلك. سيتم تفصيلها في الأقسام التالية.

المُسلسِل:

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

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

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

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

بروتوكول مجموعة التحكيم:

هذه سلسلة من العقود التي تحدد بنية الكتلة rBlock لسلسلة Rolup، وطريقة استمرار السلسلة، وإصدار rBlock، وعملية وضع التحدي. لاحظ أن سلسلة Rollup المذكورة هنا ليست دفتر الأستاذ للطبقة الثانية الذي يفهمه الجميع، ولكنها عبارة عن «بنية بيانات شبيهة بالسلسلة» تم إعدادها بشكل مستقل بواسطة Arbitrum One من أجل تنفيذ آلية إثبات الاحتيال.

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

المدقق:

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

يقوم
Validator بإنشاء rBlock جديد (كتلة Rollup، وتسمى أيضًا التأكيد) استنادًا إلى دفعة المعاملة التي أرسلها المُسلسِل إلى عقد SequencerInbox، بالإضافة إلى مراقبة حالة سلسلة Rollup الحالية وتحدي البيانات غير الصحيحة المقدمة من المُسلِس.

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

التحدي:

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

فترة التحدي:

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

أربوس، جيث، 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. إنها في حالة Soft Finality ولا يمكن الاعتماد عليها. ولكن بالنسبة للمستخدمين (معظم المستخدمين) الذين يثقون في جهاز التسلسل، يمكنهم أن يكونوا متفائلين بأن المعاملة قد اكتملت ولن يتم التراجع عنها.

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

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

عقد صندوق الوارد الخاص بالمسلسل

سيستلم العقد دفعة المعاملات المقدمة من قبل المنظم لضمان توفر البيانات. إذا نظرنا إلى هذا بطريقة أعمق، فإن البيانات المجمعة في Sequencer Inbox تسجل بالكامل معلومات إدخال المعاملة الخاصة بـ Layer2. حتى في حالة تعطل جهاز التسلسل نهائيًا، يمكن لأي شخص استعادة الحالة الحالية للطبقة الثانية استنادًا إلى السجل الدفعي واستبدال جهاز التسلسل المعيب/الجاري تشغيله.

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

يُطلق على عقد Sequencer Inbox اسم الصندوق السريع. يقوم منظم التسلسل على وجه التحديد بإرسال المعاملات التي تمت معالجتها مسبقًا إليه، ويمكن للمسلسل فقط إرسال البيانات إليه. المربع السريع المقابل هو مربع Delayer Inbox البطيء، وسيتم وصف وظيفته في العملية اللاحقة.

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

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

（يقوم المنظم بإرسال الدفعات باستمرار إلى صندوق الوارد الخاص بالمسلسل）

（المعلومات المحددة للدفعة؛ حقل البيانات يتوافق مع بيانات الدفعة. حجم هذا الجزء من البيانات كبير جدًا، ولا يتم عرض لقطة الشاشة بالكامل.）

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

إضافة جهاز التسلسل L2Batch من الأصل ()

سيقوم المنظم باستدعاء هذه الوظيفة في كل مرة لإرسال بيانات الدفعة إلى عقد Sequencer Inox.

إدراج القوة ()

يمكن لأي شخص استدعاء هذه الوظيفة واستخدامها لتنفيذ معاملات مقاومة للرقابة. سيتم شرح طريقة تفعيل هذه الوظيفة بالتفصيل لاحقًا عندما نتحدث عن عقد Delayed Inbox.

ستقوم الوظيفتان المذكورتان أعلاه باستدعاء 'Bridge.enqueueSequencerMessage () 'لتحديث معلمة المجمع في عقد الجسر.

تسعير الغاز

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

تكاليف نشر البيانات التي يتكبدها احتلال موارد Layer1

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

التكلفة التي يتكبدها المستخدمون الذين يشغلون موارد الطبقة الثانية

تم وضع حد للغاز لـ TPS لضمان التشغيل المستقر للنظام (حاليًا 7 ملايين في Arbitrum One). يتم تتبع أسعار توجيه الغاز لكل من L1 و L2 وتعديلها بواسطة ARBOs، ولم يتم تفصيل الصيغة هنا في الوقت الحالي.

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

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

بالإشارة إلى ما سبق، فإن L2 هو في الواقع مجرد عرض لدفعة إدخال المعاملات المقدمة من قبل المنظم في المربع السريع، أي:

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

في L1، توجد بيانات إدخال منشورة بواسطة المُسلسِل وحالة الإخراج المنشورة بواسطة المدقق. لننظر في الأمر بعناية: هل من الضروري نشر حالة الطبقة الثانية على السلسلة؟

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

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

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

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

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

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

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

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

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

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

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

العقد الأساسي لبروتوكول التجميع هو RollupProxy.sol، والذي يستخدم بنية وكيل مزدوج نادرة مع ضمان اتساق بنية البيانات. عامل واحد يتوافق مع تطبيقين لـ RolupUserLogic.sol و RolupAdminLogic.sol، والتي لا يمكن تحليلها جيدًا بواسطة أدوات مثل Scan.

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

(المصدر: موقع L2BEAT الرسمي)

يُظهر هذا تسجيل سلسلة من RBlocks (المعروفة أيضًا باسم التأكيدات)، في RolluProxy، مقدمة من مدققين مختلفين، وهي المربعات الموجودة في الشكل أدناه: مؤكد باللون الأخضر، غير مؤكد باللون الأزرق، مزور باللون الأصفر.

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

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

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

وبالإضافة إلى ذلك، اقترح المدقق «أ» مجموعة التجميع رقم 106، لكن «ب» لم يوافق عليها واعترض عليها.

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

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

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

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

4. عندما يحدد المنافس والطرف المعترض عليه تعليمات الجهاز التي سيتم الطعن فيها، يقوم المنافس باستدعاء وظيفة «OneStepProveExecution ()» ويرسل دليل الاحتيال المكون من خطوة واحدة لإثبات وجود مشكلة في نتيجة تنفيذ تعليمات الجهاز هذه.

مقاوم بخطوة واحدة

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

هذا يتطلب فهم WAVM أولاً. آلة Wasm Arbitrum الافتراضية عبارة عن آلة افتراضية تم تجميعها بواسطة وحدة ARbOS والوحدة الأساسية لـ Geth (عميل Ethereum). نظرًا لأن L2 يختلف تمامًا عن L1، كان لابد من تعديل نواة Geth الأصلية بشكل طفيف والعمل مع ARBOs.

لذلك، فإن انتقال الحالة على L2 هو في الواقع عمل مشترك لـ ARBOS+Geth Core.

يقوم عميل عقدة Arbitrum (المُسلسِل والمتحقق والعقدة الكاملة وما إلى ذلك) بتجميع برنامج معالجة ARBOS+Geth Core المذكور أعلاه في كود الجهاز الأصلي الذي يمكن لمضيف العقدة معالجته مباشرةً (لـ x86/ARM/PC/Mac/إلخ).

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

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

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

بعد الجولات السابقة من المقاطع التفاعلية، أثبت الدليل المكون من خطوة واحدة أخيرًا التعليمات المكونة من خطوة واحدة في مجموعة تعليمات WAVM.

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

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

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

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

1. تمت إعادة طباعة هذه المقالة من [WeChat]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [Luo Benben]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.