هذه المقالة هي التفسير الفني لـ Arbitrum One بقلم Luo Benben، السفير الفني السابق لـ Arbitrum والمؤسس المشارك السابق لشركة تدقيق أتمتة العقود الذكية Goplus Security.
** بقلم: لوه بنبن، السفير الفني السابق لشركة Arbitrum والمساهم المهوس في web3**
** هذه المقالة هي التفسير الفني لـ Arbitrum One بقلم Luo Benben، السفير الفني السابق لشركة Arbitrum والمؤسس المشارك السابق لشركة تدقيق أتمتة العقود الذكية Goplus Security. **
نظرًا لعدم وجود تفسير احترافي لـ Arbitrum وحتى OP Rollup في المقالات أو المواد المتعلقة بالطبقة الثانية في الدائرة الصينية، تحاول هذه المقالة سد الفجوة في هذا المجال من خلال تعميم آلية تشغيل Arbitrum. نظرًا لأن بنية Arbitrum نفسها معقدة للغاية، فإن النص الكامل لا يزال يتجاوز 10000 كلمة على الرغم من تبسيطه قدر الإمكان، لذا فهو مقسم إلى جزأين، يوصى بجمعه وإعادة توجيهه كمرجع! **
وصف موجز لفارز القيمة المجمعة
يمكن تلخيص مبدأ التوسع التراكمي في نقطتين:
**تحسين التكلفة: نقل معظم مهام الحوسبة والتخزين إلى سلسلة L1، أي L2. **L2 عبارة عن سلسلة تعمل على خادم واحد في الغالب، أي جهاز التسلسل/المشغل.
يبدو جهاز الفرز وكأنه قريب من خادم مركزي. في “الجوانب الثلاثة المستحيلة لـ blockchain”، يتم التخلي عن “اللامركزية” مقابل TPS ومزايا التكلفة. يمكن للمستخدمين السماح لـ L2 بمعالجة تعليمات المعاملات بدلاً من Ethereum، والتكلفة أقل بكثير من التداول على Ethereum.
(المصدر: سلسلة BNB)
ضمان الأمان: **ستتم مزامنة محتوى المعاملة وحالة ما بعد المعاملة على L2 مع Ethereum L1، وسيتم التحقق من صحة انتقال الحالة من خلال العقد. **في الوقت نفسه، سيتم الاحتفاظ بالسجلات التاريخية لـ L2 على Ethereum.حتى لو كان جهاز التسلسل معطلاً بشكل دائم، يمكن للآخرين استعادة حالة L2 بأكملها من خلال السجلات الموجودة على Ethereum.
**في الأساس، يعتمد أمان Rollup على Ethereum. **إذا كان المُسلسل لا يعرف المفتاح الخاص للحساب، فلا يمكنه بدء المعاملات باسم الحساب، أو لا يمكنه التلاعب برصيد أصول الحساب (حتى لو فعل ذلك، فسيتم اكتشافه بسرعة).
على الرغم من أن الفارز مركزي كمركز النظام،** في حل القيمة المحتسبة الناضج نسبيًا، يمكن للفارز المركزي فقط تنفيذ السلوكيات الشريرة الناعمة مثل مراجعة المعاملات، أو التوقف الضار،** ولكن في حل القيمة المحتسبة المثالي، توجد وسائل مقابلة للاحتواء (مثل الآليات المقاومة للرقابة مثل السحب القسري أو فرز الأدلة).
(يقوم بروتوكول Loopring بتعيين وظيفة السحب القسري في كود مصدر العقد على L1 ليتمكن المستخدمون من الاتصال بها)
تنقسم طرق التحقق من الحالة لمنع جهاز التسلسل التراكمي من فعل الشر إلى فئتين: إثبات الاحتيال وإثبات الصلاحية. يُطلق على نظام القيمة المجمعة الذي يستخدم إثبات الاحتيال اسم OP Rollup (التراكمي المتفائل، OPR)، في حين أنه نظرًا لبعض الأمتعة التاريخية، غالبًا ما يُطلق على نظام القيمة المجمعة الذي يستخدم إثبات الصلاحية اسم ZK Rollup** (مجموعة إثبات المعرفة الصفرية، ZKR) بدلاً من مجموعة الصلاحية. .
Arbitrum One هو OPR نموذجي، فهو ينشر العقود على L1 ولا يتحقق بشكل نشط من البيانات المقدمة، وهو متفائل بعدم وجود مشكلة في البيانات. إذا كانت البيانات المقدمة غير صحيحة، فستبدأ عقدة التحقق L2 في إجراء اختبار فعال.
لذلك، **OPR يتضمن أيضًا افتراض الثقة: هناك عقدة تحقق L2 صادقة واحدة على الأقل في أي وقت. ** يستخدم عقد ZKR حسابات التشفير للتحقق بشكل فعال ولكن فعال من حيث التكلفة من البيانات المقدمة من جهاز التسلسل.
(طريقة عملية التجميع المتفائلة)
(وضع التشغيل ZK التراكمي)
ستقدم هذه المقالة مقدمة متعمقة عن Arbitrum One، المشروع الرائد في مجال التراكم المتفائل، والذي يغطي جميع جوانب النظام بأكمله. بعد قراءته بعناية، سيكون لديك فهم عميق لـ Arbitrum والتراكم المتفائل/OPR.
المكونات الأساسية وسير العمل في Arbitrum
العقد الأساسي:
تشمل أهم عقود Arbitrum **SequencerInbox، وDelayedInbox، وL1 Gateways، وL2 Gateways، وOutbox، وRollupCore، وBridge، وما إلى ذلك. **التفاصيل سنعرضها لاحقاً.
التسلسل:
تلقي معاملات المستخدم وفرزها، وحساب نتائج المعاملات، وإرجاع الإيصالات إلى المستخدمين بسرعة (عادةً أقل من 1 ثانية). يمكن للمستخدمين غالبًا رؤية معاملاتهم مدرجة على L2 في غضون ثوانٍ قليلة، وتكون التجربة تمامًا مثل منصة Web2.
في الوقت نفسه، سيقوم جهاز التسلسل أيضًا ببث أحدث كتلة L2 مباشرة ضمن سلسلة Ethereum، ويمكن لأي عقدة Layer2 استقبالها بشكل غير متزامن. لكن في هذا الوقت، هذه الكتل L2 ليست نهائية ويمكن إعادتها مرة أخرى بواسطة جهاز التسلسل.
كل بضع دقائق، سيقوم جهاز التسلسل بضغط بيانات معاملات L2 المصنفة، وتجميعها على دفعات، وإرسالها إلى عقد البريد الوارد SequencerInbox على Layer1 لضمان توفر البيانات وتشغيل بروتوكول التراكمي. . بشكل عام، لا يمكن إرجاع بيانات L2 المرسلة إلى Layer1 ويمكن أن تكون نهائية.
من العملية المذكورة أعلاه، يمكننا تلخيص ما يلي: ** لدى الطبقة 2 شبكة عقد خاصة بها، ولكن عدد هذه العقد متناثر، ولا يوجد عمومًا بروتوكول إجماع شائع الاستخدام من قبل السلاسل العامة، لذا فإن الأمان ضعيف للغاية ويجب ضمانه من خلال الاعتماد على الايثيريوم موثوقية إصدار البيانات وفعالية انتقالات الدولة. **
بروتوكول تراكمي Arbitrum:
سلسلة من العقود التي تحدد هيكل الكتلة RBlock لسلسلة Rollup، وطريقة استمرار السلسلة، وإصدار RBlock، وعملية وضع التحدي. **لاحظ أن سلسلة التجميع المذكورة هنا ليست دفتر الأستاذ من الطبقة الثانية الذي يفهمه الجميع، ولكنها عبارة عن “بنية بيانات شبيهة بالسلسلة” تم إعدادها بشكل مستقل بواسطة Arbitrum One من أجل تنفيذ آلية مقاومة الاحتيال. **
يمكن أن يحتوي RBlock واحد على نتائج كتل L2 متعددة، كما أن البيانات مختلفة تمامًا أيضًا، ويتم تخزين كيان البيانات الخاص به RBlock في سلسلة من العقود في RollupCore. إذا كانت هناك مشكلة في RBlock، فسيقوم المدقق بتحدي مرسل RBlock.
المدقق:
عقد التحقق من صحة Arbitrum هي في الواقع مجموعة فرعية خاصة من العقد الكاملة للطبقة الثانية، ولديها حاليًا إمكانية الوصول إلى القائمة البيضاء.
** يقوم برنامج التحقق بإنشاء RBlock جديد ** (كتلة القيمة المحتسبة، وتسمى أيضًا التأكيد) استنادًا إلى مجموعة المعاملات المرسلة بواسطة جهاز التسلسل إلى عقد SequencerInbox، ** ويراقب حالة سلسلة القيمة المحتسبة الحالية، ويقيم المعاملات المقدمة من قبل جهاز التسلسل. تحدي البيانات غير الصحيحة. **
يحتاج المدقق النشط إلى رهن الأصول الموجودة على سلسلة ETH مقدمًا، وأحيانًا نسميها أيضًا Staker. على الرغم من أن عقد الطبقة الثانية التي لا تتعهد يمكنها أيضًا مراقبة ديناميكيات تشغيل مجموعة التحديثات وإرسال إنذارات غير طبيعية للمستخدمين، إلا أنها لا تستطيع التدخل بشكل مباشر في بيانات الخطأ المقدمة من جهاز التسلسل في سلسلة ETH.
تحدي:
يمكن تلخيص الخطوات الأساسية في جولات متعددة من التجزئة التفاعلية والإثبات بخطوة واحدة. في عملية التجزئة، تقوم الأطراف المتحدية أولاً بإجراء جولات متعددة من التجزئة على بيانات المعاملة الإشكالية حتى تقوم بتحليل تعليمات رمز التشغيل الإشكالية وإجراء التحقق. يعتبر مطورو Arbitrum أن نموذج “** دليل التقسيم الفرعي متعدد الجولات والخطوة الواحدة” هو التطبيق الأكثر توفيرًا لإثبات الاحتيال. **جميع الجوانب تحت سيطرة العقد، ولا يمكن لأي طرف الغش.
فترة التحدي:
نظرًا للطبيعة المتفائلة لـ OP Rollup، بعد إرسال كل RBlock إلى السلسلة، لا يتم التحقق من العقد بشكل نشط، مما يترك فترة زمنية للمدقق للتزييف. **هذه النافذة الزمنية هي فترة التحدي، وهي أسبوع واحد على شبكة Arbitrum One الرئيسية. بعد انتهاء فترة التحدي، سيتم تأكيد RBlock أخيرًا، ويمكن تحرير الرسائل المقابلة التي تم تمريرها من L2 إلى L1 في الكتلة ** (مثل عمليات السحب التي تتم عبر الجسر الرسمي).
أربوس، جيث، WAVM:
يُطلق على الجهاز الظاهري الذي تستخدمه Arbitrum اسم AVM، والذي يتضمن Geth وArbOS. **Geth هو برنامج العميل الأكثر استخدامًا في Ethereum، وقد أجرت Arbitrum تعديلات خفيفة عليه. **يتولى ArbOS مسؤولية جميع الوظائف الخاصة المتعلقة باللغة الثانية، مثل إدارة موارد الشبكة، وإنشاء كتل اللغة الثانية، والعمل مع EVM، وما إلى ذلك. نحن نعتبر الجمع بين الاثنين بمثابة جهاز AVM أصلي، وهو الجهاز الظاهري الذي تستخدمه Arbitrum. WAVM هو نتيجة تجميع كود AVM في Wasm. **في عملية تحدي Arbitrum، يتحقق آخر “دليل من خطوة واحدة” من تعليمات WAVM. **
هنا، يمكننا استخدام الشكل التالي لتمثيل العلاقة وسير العمل بين المكونات المذكورة أعلاه:
دورة حياة المعاملة L2
تدفق المعالجة لمعاملة L2 هو كما يلي:
1. يرسل المستخدم تعليمات التداول إلى جهاز التسلسل.
2. يتحقق عامل الفرز أولاً من المعاملات التي ستتم معالجتها وتحويلها إلى توقيعات رقمية وبيانات أخرى، ويزيل المعاملات غير الصالحة، ويجري الفرز والحسابات.
3. يرسل جهاز التسلسل إيصال المعاملة إلى المستخدم (عادةً ما يكون سريعًا جدًا)، ** ولكن هذه مجرد “معالجة مسبقة” يقوم بها جهاز التسلسل ضمن سلسلة ETH. وهو في حالة نهائية ناعمة وهو كذلك غير موثوقة.**. ولكن بالنسبة للمستخدمين الذين يثقون في جهاز التسلسل (معظم المستخدمين)، فيمكنهم أن يكونوا متفائلين بأن المعاملة قد اكتملت ولن يتم التراجع عنها.
4. يقوم جهاز الفرز بضغط بيانات المعاملة الأصلية التي تمت معالجتها مسبقًا وتغليفها في دفعة واحدة.
**5. بين الحين والآخر (يتأثر بعوامل مثل حجم البيانات وازدحام ETH)، سيقوم مُسلسِل البيانات بنشر دفعات المعاملات إلى عقد Sequencer Inbox على L1. **في هذه المرحلة، يمكن اعتبار أن المعاملة ذات نهائية صعبة.
عقد علبة الوارد للتسلسل
سيتلقى العقد دفعة المعاملة المقدمة من جهاز التسلسل لضمان توفر البيانات. بإلقاء نظرة فاحصة، فإن بيانات الدُفعة في SequencerInbox تسجل بالكامل معلومات إدخال المعاملة الخاصة بالطبقة 2. ** حتى إذا كان جهاز التسلسل معطلاً بشكل دائم، يمكن لأي شخص استعادة الحالة الحالية لـ Layer2 بناءً على سجل الدُفعة واستبدال جهاز التسلسل الفاشل/الجري. . **
لفهم ذلك بطريقة مادية، فإن L2 الذي نراه هو مجرد إسقاط للدفعة في SequencerInbox، ومصدر الضوء هو STF. نظرًا لأن مصدر الضوء STF لا يتغير بسهولة، يتم تحديد شكل الظل فقط من خلال الدفعة التي تعمل ككائن.
** يُسمى عقد Sequencer Inbox أيضًا بالصندوق السريع، حيث يقوم مُسلسِل المستندات على وجه التحديد بإرسال المعاملات المُجهزة مسبقًا إليه، ويمكن فقط المُسلسِل إرسال البيانات إليه. **الصندوق السريع المقابل هو الصندوق البطيء لصندوق الوارد المؤجل، وسيتم وصف وظيفته في العملية اللاحقة.
سيقوم المدقق دائمًا بمراقبة عقد SequencerInbox. **عندما يقوم المُسلسل بإصدار دفعة للعقد، سيتم طرح حدث على السلسلة. بعد أن يستمع المدقق إلى حدوث هذا الحدث، سيقوم بتنزيل بيانات الدُفعة وتنفيذها محليًا، وأخيرًا، قم بإصدار RBlock لعقد بروتوكول التراكمي على سلسلة ETH.
توجد معلمة تسمى المجمع في عقد الجسر الخاص بـ Arbitrum، والتي تسجل دفعة L2 المقدمة حديثًا، بالإضافة إلى عدد ومعلومات المعاملات المستلمة حديثًا على صندوق الوارد البطيء.
(يرسل جهاز التسلسل دفعات بشكل مستمر إلى SequencerInbox)
*
(معلومات محددة للدفعة، حقل البيانات يتوافق مع بيانات الدفعة، هذا الجزء من البيانات كبير جدًا، ولا يتم عرض لقطة الشاشة بالكامل)
يحتوي عقد SequencerInbox على وظيفتين رئيسيتين:
** إضافة Sequencer L2Batch From Origin()، ** سوف يقوم جهاز التسلسل باستدعاء هذه الوظيفة في كل مرة لإرسال بيانات الدُفعات إلى عقد Sequencer Inox.
force Inclusion(), يمكن لأي شخص استدعاء هذه الوظيفة واستخدامها لتنفيذ معاملات مقاومة للرقابة. سيتم شرح طريقة تفعيل هذه الوظيفة بالتفصيل لاحقًا عندما نتحدث عن عقد البريد الوارد المؤجل.
ستستدعي الوظيفتان المذكورتان أعلاه Bridge.enqueueSequencerMessage() لتحديث مُراكم معلمة المجمع في عقد الجسر.
تسعير الغاز
من الواضح أن معاملات L2 لا يمكن أن تكون مجانية، لأن هذا سيؤدي إلى هجمات حجب الخدمة. بالإضافة إلى ذلك، هناك تكاليف تشغيل للفارز L2 نفسه، وستكون هناك نفقات إضافية لإرسال البيانات على L1. عندما يبدأ المستخدمون معاملات داخل شبكة الطبقة الثانية، يكون هيكل رسوم الغاز كما يلي:
تكلفة نشر البيانات المتكبدة بسبب شغل موارد الطبقة 1 تأتي بشكل أساسي من الدُفعة التي يرسلها فارز البيانات (تحتوي كل دفعة على العديد من معاملات المستخدم)، ويتم تقاسم التكلفة في النهاية بالتساوي بين بادئي المعاملة. تعد خوارزمية تسعير الرسوم الناتجة عن إصدار البيانات ديناميكية، وسيقوم جهاز الفرز بالتسعير بناءً على حالة الربح والخسارة الأخيرة، وحجم الدفعة، وسعر غاز الإيثيريوم الحالي.
** التكلفة التي يتكبدها المستخدمون بسبب احتلال موارد الطبقة الثانية ** تحدد حدًا للغاز يمكن معالجته في الثانية لضمان التشغيل المستقر للنظام (حاليًا يبلغ Arbitrum One 7 ملايين). يتم تتبع وتعديل الأسعار الإرشادية للغاز L1 وL2 بواسطة ArbOS، ولن يتم وصف الصيغ هنا في الوقت الحالي.
على الرغم من أن عملية حساب سعر الغاز المحددة معقدة نسبيًا، إلا أن المستخدمين لا يحتاجون إلى أن يكونوا على دراية بهذه التفاصيل ويمكنهم أن يشعروا بوضوح أن رسوم المعاملات المجمعة أرخص بكثير من شبكة ETH الرئيسية.
دليل متفائل على الاحتيال
تذكر ما ورد أعلاه، L2 هو في الواقع مجرد إسقاط لمجموعة إدخال المعاملة المقدمة من فارز في المربع السريع، أي:
مدخلات المعاملة -> STF -> مخرجات الحالة. تم تحديد الإدخال ولم يتغير STF، وبالتالي يتم تحديد نتيجة الإخراج أيضًا. ** ينشر نظام إثبات الاحتيال وبروتوكول Arbitrum Rollup جذر حالة الإخراج إلى L1 في شكل RBlock (المعروف أيضًا باسم التأكيد) وهو عبارة عن نظام لإثبات التفاؤل. **
في L1، توجد بيانات إدخال منشورة بواسطة جهاز التسلسل وحالة الإخراج منشورة بواسطة أداة التحقق. دعونا نفكر في الأمر بعناية، هل من الضروري نشر حالة الطبقة الثانية في السلسلة؟
نظرًا لأن الإدخال يحدد المخرجات بالكامل بالفعل، وبيانات الإدخال مرئية للعامة، فإن إرسال نتيجة الإخراج - هل تبدو الحالة زائدة عن الحاجة؟ لكن هذه الفكرة تتجاهل الحاجة الفعلية لتسوية الحالة بين النظامين L1-L2، أي أن سلوك الانسحاب من L2 إلى L1 يتطلب إثبات الحالة.
عند إنشاء مجموعة Rollup، تتمثل إحدى الأفكار الأساسية في وضع معظم عمليات الحوسبة والتخزين على L2 لتجنب التكلفة العالية للL1، وهذا يعني أن L1 لا يعرف حالة L2، فهو يساعد فقط L2، ويقوم جهاز التسلسل بنشر بيانات الإدخال جميع المعاملات، ولكنها ليست مسؤولة عن حساب حالة L2.
**إن سلوك السحب هو في الأساس اتباع الرسالة عبر السلسلة المقدمة من L2، أو فتح الأموال المقابلة من عقد L1، أو تحويلها إلى حساب L1 الخاص بالمستخدم أو إكمال أشياء أخرى. **
في هذا الوقت، سيطرح عقد Layer1 السؤال التالي: **ما هي حالتك على Layer2، وكيف تثبت أنك تمتلك حقًا الأصول التي تعلن عن نقلها. في هذا الوقت، يجب على المستخدم تقديم إثبات Merkle المقابل، وما إلى ذلك. **
لذلك، إذا قمنا بإنشاء مجموعة تراكمية بدون وظيفة سحب، فمن الممكن نظريًا عدم مزامنة الحالة مع L1، وليست هناك حاجة لنظام إثبات الحالة مثل إثبات الاحتيال (على الرغم من أنه قد يسبب مشاكل أخرى). ولكن في التطبيقات الحقيقية، من الواضح أن هذا غير ممكن.
في ما يسمى بالدليل المتفائل، لا يتحقق العقد مما إذا كانت حالة الإخراج المقدمة إلى L1 صحيحة، ويعتقد بشكل متفائل أن كل شيء دقيق. **يفترض نظام الإثبات المتفائل وجود جهة مصادقة واحدة على الأقل في أي وقت، وفي حالة حدوث حالة غير صحيحة، سيتم الطعن فيها من خلال إثبات الاحتيال. **
وتتمثل ميزة هذا التصميم في أنه ليست هناك حاجة للتحقق بشكل فعال من كل RBlock تم إصداره إلى L1 لتجنب إهدار الغاز. في الواقع، بالنسبة لـ OPR، من غير الواقعي التحقق من كل تأكيد، لأن كل Rblock يحتوي على كتلة L2 واحدة أو أكثر، وتحتاج كل معاملة إلى إعادة تنفيذها على L1. ولا يختلف الأمر عن تنفيذ معاملات L2 مباشرة على L1، الأمر الذي يفقده معنى توسيع الطبقة الثانية.
لا يواجه ZKR هذه المشكلة، لأن ZK Proof بسيط ويحتاج فقط إلى التحقق من دليل صغير جدًا، وليست هناك حاجة إلى تنفيذ العديد من المعاملات المقابلة للإثبات فعليًا. لذلك فإن ZKR لا تعمل بشكل متفائل، ففي كل مرة يتم فيها إصدار الحالة، سيكون هناك عقد Verfier للتحقق الرياضي.
**على الرغم من أن إثبات الاحتيال لا يمكن أن يكون موجزًا مثل إثبات المعرفة الصفرية، فإن Arbitrum تستخدم عملية تفاعلية تعتمد على “دليل مقسم متعدد الخطوات بخطوة واحدة”. وفي النهاية، ما يجب إثباته هو مجرد جهاز افتراضي واحد رمز التشغيل، والتكلفة صغيرة نسبيا. **
بروتوكول التجميع
دعونا أولاً نلقي نظرة على كيفية عمل بروتوكول الإظهار، وهو نقطة الدخول لبدء التحديات وبدء البراهين.
**العقد الأساسي لبروتوكول الإظهار هو RollupProxy.sol. **في ظل شرط ضمان بنية بيانات متسقة، يتم استخدام بنية وكيل مزدوج نادر. وكيل واحد يتوافق مع تطبيقين لـ RollupUserLogic.sol وRollupAdminLogic.sol. في الأدوات مثل Scan It لا يمكن تحليلها بشكل جيد حتى الآن.
هناك أيضًا عقد **ChallengeManager.sol المسؤول عن إدارة التحديات، وسلسلة عقود OneStepProver لتحديد أدلة الاحتيال. **
(مصدر الصورة: الموقع الرسمي لـ L2BEAT)
في RollupProxy، يتم تسجيل سلسلة من RBlocks (المعروفة أيضًا باسم التأكيدات) المقدمة من قبل جهات التحقق المختلفة، وهي المربعات الموجودة في الشكل أدناه: الأخضر - مؤكد، الأزرق - غير مؤكد، الأصفر - المزور.
**يحتوي RBlock على الحالة النهائية بعد تنفيذ كتلة L2 واحدة أو أكثر منذ آخر RBlock. **تشكل كتل RBlocks هذه سلسلة تراكمية رسمية (لاحظ أن دفتر الأستاذ L2 نفسه مختلف). في ظل ظروف متفائلة، يجب ألا تحتوي سلسلة التراكمي هذه على أي شوكات، لأن الشوكة تعني أن المدقق قد أرسل كتل تراكمية متعارضة.
لاقتراح تأكيد أو الموافقة عليه، يحتاج المدقق أولاً إلى حصة مبلغ معين من ETH للتأكيد ويصبح حائزًا. وبهذه الطريقة، عند حدوث تحدي/إثبات احتيال، سيتم مصادرة ضمانات الخاسر، وهذا هو الأساس الاقتصادي لضمان السلوك الصادق للمدقق.
سيتم تزوير الكتلة الزرقاء رقم 111 في الزاوية اليمنى السفلية من الشكل في النهاية لأن الكتلة الأصلية رقم 104 خاطئة (أصفر).
**بالإضافة إلى ذلك، اقترح المدقق “أ” الكتلة المجمعة رقم 106، لكن “ب” لم يوافق عليها واعترض عليها. **
بعد أن يبدأ B التحدي، يكون عقد ChallengeManager مسؤولاً عن التحقق من تفاصيل خطوات التحدي:
-
التجزئة هي عملية يتناوب فيها الطرفان للتفاعل. يقوم أحد الطرفين بتقسيم البيانات التاريخية الموجودة في كتلة تراكمية معينة، ويشير الطرف الآخر إلى أي جزء من جزء البيانات يمثل مشكلة. عملية مشابهة للانقسام (في الواقع N/K) والتي تعمل على تضييق النطاق بشكل مستمر وتدريجي.
-
بعد ذلك، يمكنك الاستمرار في تحديد موقع المعاملة والنتيجة التي بها مشكلات، ثم تقسيمها فرعيًا إلى تعليمات آلة متنازع عليها في المعاملة.
-
يتحقق عقد ChallengeManager فقط مما إذا كانت “أجزاء البيانات” التي تم إنشاؤها بعد تجزئة البيانات الأصلية صالحة أم لا.
-
بعد أن يحدد المنافس والمعترض تعليمات الآلة المراد الاعتراض عليها، يستدعي المنافس oneStepProveution() ويرسل دليل احتيال من خطوة واحدة لإثبات وجود مشكلة في نتيجة تنفيذ تعليمات الآلة هذه. **
إثبات بخطوة واحدة
يعد إثبات الخطوة الواحدة جوهر إثبات الاحتيال لدى 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/etc.).
إذا قمت بتغيير اللغة المستهدفة التي تم الحصول عليها بعد التجميع إلى Wasm، فستحصل على WAVM الذي يستخدمه المدقق عند إنشاء أدلة الاحتيال، كما يحاكي عقد التحقق من الدليل أحادي الخطوة أيضًا وظائف الجهاز الظاهري WAVM.
** إذًا لماذا يجب تجميعها في رمز Bytecode Wasm عند إنشاء أدلة الاحتيال؟ **السبب الرئيسي هو أنه للتحقق من عقد إثبات الاحتيال بخطوة واحدة، من الضروري استخدام عقد Ethereum الذكي لمحاكاة جهاز افتراضي VM يمكنه معالجة مجموعة معينة من مجموعات التعليمات، كما أن WASM سهل تنفيذ المحاكاة على العقد.
ومع ذلك، يعمل WASM بشكل أبطأ قليلاً من كود الجهاز الأصلي، لذلك ستستخدم عقد/عقود Arbitrum WAVM فقط عند إنشاء أدلة الاحتيال والتحقق منها.
**بعد الجولات السابقة من التقسيمات الفرعية التفاعلية، أثبت إثبات الخطوة الواحدة أخيرًا التعليمات المكونة من خطوة واحدة في مجموعة تعليمات WAVM. **
كما هو موضح في الكود أدناه، يجب على OneStepProofEntry أولاً تحديد الفئة التي ينتمي إليها رمز تشغيل التعليمات المراد إثباتها، ثم استدعاء المثل المقابل مثل Mem وMath وما إلى ذلك، لتمرير التعليمات المكونة من خطوة واحدة إلى العقد الاثبات .
سيتم إرجاع النتيجة النهائية بعد التجزئة إلى ChallengeManager. إذا كانت التجزئة غير متسقة مع التجزئة بعد عملية التعليمات المسجلة على الكتلة المجمعة، يكون التحدي ناجحًا. إذا كانت متسقة، فهذا يعني أنه لا توجد مشكلة في نتيجة تنفيذ هذا الأمر المسجلة على الكتلة التراكمية، وفشل التحدي.
في المقالة التالية، سنقوم بتحليل Arbitrum وحتى وحدة العقد التي تتعامل مع الرسائل عبر السلسلة/وظائف الربط بين Layer2 وLayer1، ونوضح بشكل أكبر كيف يجب أن تحقق Layer2 الحقيقية مقاومة الرقابة.
