أعد توجيه العنوان الأصلي:

يقدم هذا المقال تفسيرًا تقنيًا لـ Arbitrum One بواسطة Luo Benben (罗奔奔)، السفير التقني السابق لـ Arbitrum والمؤسس السابق لشركة Goplus Security، وهي شركة تدقيق التشغيل التلقائي للعقود الذكية.

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

مقدمة موجزة عن Rollup sequencer

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

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

السيكونسر قريب من خادم مركزي بمعنى ما. في "الثالوث المستحيل للبلوكتشين"، يتم التخلي عن "اللامركزية" مقابل مزايا TPS والتكلفة. يمكن للمستخدمين السماح لطبقة الـ L2 بمعالجة تعليمات المعاملات بدلاً من الـ Ethereum، والتكلفة أقل بكثير من التداول على الـ Ethereum.

(المصدر: سلسلة بي ان بي)

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

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

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

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

لمنع السلوك الخبيث من قبل متسلسلي Rollup، هناك نوعان من أساليب التحقق من الحالة: دليل الاحتيال ودليل الصحة. تُسمى حلول Rollup التي تستخدم دليل الاحتيال Optimistic Rollup (OPR)، بينما تُشار إلى تلك التي تستخدم دليل الصحة في كثير من الأحيان باسم ZK Rollup (Zero-knowledge Proof Rollup، ZKR)، بدلاً من Validity Rollup، بسبب الأمتعة التاريخية.

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

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

(طريقة عمل تكديس متفائلة)

(طريقة عمل ZK Rollup)

سيقدم هذا المقال مقدمة شاملة للمشروع الرائد في النسخة الايجابية - Arbitrum One، مغطيًا جميع جوانب النظام. بعد قراءة دقيقة، ستكتسب فهمًا عميقًا لـ Arbitrum والنسخة الايجابية (OPR).

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

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

أهم العقود في Arbitrum تتضمن SequencerInbox، DelayedInbox، البوابات L1، البوابات L2، Outbox، RollupCore، Bridge، الخ. سيتم تفصيلها لاحقًا.

مُتسلسل:

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

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

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

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

بروتوكول Arbitrum Rollup:

يحدد هيكل الكتل ، المسمى RBlocks ، على سلسلة Rollup ، واستمرار السلسلة ، ونشر RBlocks ، وعملية وضع التحدي ، وما إلى ذلك ، من خلال سلسلة من العقود. من المهم ملاحظة أن سلسلة Rollup المذكورة هنا ليست دفتر الأستاذ الذي يفهم عادة على أنه الطبقة 2 ، بل هي "بنية بيانات تشبه السلسلة" مجردة تم إنشاؤها بشكل مستقل بواسطة Arbitrum One لتنفيذ آليات مقاومة الاحتيال.

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

المحققون:

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

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

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

تحدي:

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

فترة التحدي:

نظرًا للطبيعة المتفائلة لـ OP Rollup، بعد تقديم كل RBlock إلى السلسلة، لا يتحقق العقد منه نشطًا، مما يترك فترة زمنية للمحققين لتزييفه. تكون هذه الفترة الزمنية هي فترة التحدي، والتي تبلغ أسبوعًا على شبكة Arbitrum One الرئيسية. بعد انتهاء فترة التحدي، سيتم تأكيد 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. يرسل جهاز التسلسل إيصال المعاملة إلى المستخدم (عادة بسرعة كبيرة) ، ولكن هذه ليست سوى "المعالجة المسبقة" التي يقوم بها جهاز التسلسل على سلسلة Ethereum ، وهي في حالة نهائية ناعمة وغير موثوقة. ومع ذلك ، بالنسبة للمستخدمين الذين يثقون في جهاز التسلسل (معظم المستخدمين) ، يمكنهم أن يفترضوا بتفاؤل أن المعاملة قد اكتملت ولن يتم التراجع عنها.
4. يقوم جهاز التسلسل بتغليف بيانات المعاملات التي تمت معالجتها مسبقا في دفعة بعد ضغطها بدرجة عالية.
5. في فترات منتظمة (تتأثر بعوامل مثل حجم البيانات وازدحام إيثريوم)، يقوم المُسلسل بنشر دفعة الصفقات إلى عقد صندوق المسلسل على L1. في هذه النقطة، يمكن اعتبار أن الصفقة حصلت على القطعية الصارمة.

عقد صندوق البريد التسلسلي

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

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

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

سيقوم المحققون بمراقبة الصندوق الوارد المتسلسل بشكل مستمر. في كل مرة يقوم فيها المتسلسل بنشر دفعة إلى هذا العقد، يتم تشغيل حدث على السلسلة. عند اكتشاف هذا الحدث، سيقوم المحقق بتنزيل بيانات الدفعة، تنفيذها محليًا، ثم نشر RBlock إلى عقد بروتوكول Rollup على سلسلة Ethereum.

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

(يقوم المتسلسل بتقديم دفعات بشكل مستمر إلى صندوق البريد التسلسلي)

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

عقد SequencerInbox لديه وظيفتان رئيسيتان:

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

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

سيتصل الوظيفتان أعلاه بـ 'bridge.enqueueSequencerMessage()' لتحديث معلمة التراكم 'accumulator' في عقد الجسر.

تسعير الغاز

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

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

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

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

إثبات احتيال متفائل

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

مدخلات المعاملة -> وظيفة انتقال الحالة (STF) -> مخرجات الحالة

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

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

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

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

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

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

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

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

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

على الرغم من أن دلائل الاحتيال لا يمكن أن تحقق مستوى عالي من الإيجاز كما تفعل دلائل الصفر المعرفة، إلا أن أربيترم يستخدم عملية تفاعلية "تقسيم متعدد الجولات - دليل بخطوة واحدة"، حيث يتعين في نهاية المطاف إثبات ما يحتاج إلى إثباته من عمليات الآلة الظاهرية واحدة فقط، مما يؤدي إلى تكاليف أقل نسبيًا.

بروتوكول اللف

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

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

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

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

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

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

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

سيتم تفنيد الكتلة الزرقاء المرقمة بالرقم 111 في الزاوية السفلية اليمنى من الرسم التخطيطي في النهاية لأن كتلة الوالد الخاصة بها، الكتلة رقم 104، غير صحيحة (اللون الأصفر).

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

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

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

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

3. يتحقق عقد ChallengeManager فقط مما إذا كانت "شريحة البيانات" التي تم إنشاؤها بعد تقسيم البيانات الأصلية صالحة.

4. عندما يحدد الطرف المتحد الذي يتحداه تعليمة الجهاز المطلوب تحديها، يستدعي الطرف المتحدي oneStepProveExecution() لإرسال دليل احتيال خطوة واحدة، يثبت أن نتيجة تنفيذ هذه التعليمة الجهازية غير صحيحة.

الدليل الذي يُثبت بخطوة واحدة

يعد الإثبات بخطوة واحدة جوهر كل إثبات احتيال في 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 الافتراضية.

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

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

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

كما يمكن رؤيته في الكود أدناه، يقوم OneStepProofEntry أولاً بتحديد التصنيف الذي ينتمي إليه رمز العملية للتعليمة التي يجب إثباتها، ثم يقوم بالاتصال بالبروفر المقابل مثل Mem، Math، إلخ، لتمرير التعليمة خطوة واحدة إلى عقد البروفر.

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

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

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