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

المؤلف: لوه بنبن، السفير الفني السابق لشركة Arbitrum، والمساهم في geek web3

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

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

تبسيط فارز القيمة المجمعة description

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

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

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

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

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

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

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

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

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

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

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

(وضع التشغيل المتفائل)

< /p>

(وضع تشغيل ZK Rollup)

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

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

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

تتضمن أهم عقود ArbitrumSequencerInbox، وDelayedInbox، وL1 Gateways، وL2 Gateways، وOutbox، وRollupCore، وBridge، وما إلى ذلك. سيتم تقديم المزيد من التفاصيل لاحقًا.

جهاز التسلسل:

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

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

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

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

بروتوكول Arbitrum Rollup:

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

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

أداة التحقق:

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

يقوم Validator بإنشاء RBlock جديد استنادًا إلى مجموعة المعاملات المرسلة بواسطة جهاز التسلسل إلى عقد SequencerInbox< / قوي>(كتلة التجميع، وتسمى أيضًا التأكيد)،ومراقبة حالة سلسلة التجميع الحالية، والتحقق من البيانات غير الصحيحة المقدمة من جهاز التسلسل.

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

التحدي:

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

فترة التحدي:

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

ArbOS وGeth وWAVM:

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

هنا، يمكننا استخدام الشكل التالي لتمثيل العلاقة وسير العمل بين المكونات المذكورة أعلاه:

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

واحد تدفق معالجة معاملة L2 هي كما يلي:

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

2.يقوم القائم بالفرز أولاً بالتحقق من المعاملات التي ستتم معالجتها وتحويلها إلى توقيعات رقمية وبيانات أخرى، وإزالة المعاملات غير الصالحة، وإجراء الفرز والحسابات.

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

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

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

عقد صندوق الوارد للتسلسل< /h3>

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

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

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

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

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

(يرسل جهاز التسلسل بشكل مستمر دفعات إلى SequencerInbox)

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

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

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

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

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

تسعير الغاز

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

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

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

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

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

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

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

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

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

عند إنشاء مجموعة التحديثات، فإن إحدى الأفكار الأساسية هي وضع معظم عمليات الحوسبة والتخزين على 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 موجز. فهو يحتاج فقط إلى التحقق من دليل صغير جدًا، وليست هناك حاجة إلى تنفيذ العديد من الخطوات المقابلة خلف Proof.transactions. لذلك فإن ZKR لا تعمل بشكل متفائل، ففي كل مرة يتم فيها إصدار الحالة، سيكون هناك عقد Verfier للتحقق الرياضي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إثبات بخطوة واحدة< / h3>

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

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

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

المراجحة يقوم عميل العقدة (التسلسل، المدقق، العقدة الكاملة، وما إلى ذلك) بتجميع برنامج معالجة 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 A الوحدة التي تتعامل مع وظائف المراسلة/الجسر عبر السلسلة، وتوضح أيضًا كيف ينبغي للطبقة الثانية الحقيقية أن تحقق مقاومة الرقابة.