كما هو معروف، تعد دلائل الاحتيال حلا تقنيًا شائعًا في مجال تكنولوجيا البلوكشين. نشأت في مجتمع إيثيريوم وتم اعتمادها من قبل حلول إيثيريوم المعروفة مثل Arbitrum و Optimism. بعد ظهور نظام بيتكوين في عام 2023، اقترح روبن لينوس حلا يسمى BitVM، الذي، بناءً على تقنيات بيتكوين الحالية مثل Taproot، يركز على دلائل الاحتيال ويوفر نموذج أمان جديد لبيتكوين الطبقة 2 أو الجسور.

لقد قام BitVM بإطلاق عدة نسخ نظرية، من BitVM0 الأقدم، الذي استخدمته دوائر بوابات المنطق كأساس، إلى النسخ اللاحقة مثل BitVM2، التي ركزت على أدلة الاحتيال ZK ودوائر التحقق Groth16. لقد كانت مسارات التنفيذ التقني ذات الصلة بـ BitVM تتطور وتنضج، ما يجذب انتباه العديد من المحترفين في الصناعة. تستخدم مشاريع مثل Bitlayer و Citrea و BOB و Fiamma و Goat Network جميعها BitVM كأحد تقنياتها الأساسية، وتنفذ نسخًا مختلفة بناءً على هذا الأساس.

نظرًا لندرة وتعقيد الشروحات المتاحة علنًا حول BitVM، قمنا بإطلاق سلسلة من المقالات تهدف إلى نشر المعرفة حول BitVM. بنظر إلى الارتباط العميق بين BitVM ودلائل الاحتيال، سيتمحور هذا المقال حول دلائل الاحتيال ودلائل الاحتيال ZK، باستخدام لغة بسيطة ومفهومة لشرح هذه المفاهيم.

(آلية دليل التفاعلي لإثبات الاحتيال لمبدأ التفاؤل)

OutputRoot و StateRoot

التفاؤل هو مشروع معروف للتفاؤلي Rollup، وتتكون بنيته من مسلسل (مع الوحدات الرئيسية التي تشمل op-node، op-geth، op-batcher، و op-proposer) وعقود ذكية على سلسلة Ethereum.

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

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

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

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

يتمثل نظام الحساب والهيكل البياني لـ Optimism عمومًا في توافق مع Ethereum، حيث يستخدم أيضًا حقل StateRoot لتمثيل التغييرات في مجموعة الحالة. يقوم مسلسل OP برفع حقل مفتاحي يسمى OutputRoot بانتظام إلى Ethereum، والذي يتم احتسابه بناءً على StateRoot وحقلين آخرين.

عند العودة إلى السؤال الأول، عند تشغيل عميل العقد الذكي OP وحساب StateRoot و OutputRoot الحالي محليًا، إذا وجدت أن النتائج التي حسبتها لا تتطابق مع تلك التي تم تحميلها من قبل مُسجل OP، يمكنك بدء دليل على الاحتيال. إذاً، ما هي الآلية المحددة وراء هذا؟ فيما يلي، سنقدم تتابعًا لتحقق حالة جهاز MIPS الافتراضي ودلائل الاحتيال التفاعلية.

جهاز MIPS الظاهري وشجرة Merkle للذاكرة

كما ذكر سابقا، نفترض أنك تجد أن OutputRoot المقدم من قبل مسلسل OP غير صحيح، وترغب في بدء "تحدي." يتطلب عملية التحدي إكمال سلسلة من التفاعلات على السلسلة، بعد ذلك ستقوم العقود الذكية ذات الصلة بتحديد ما إذا قام مسلسل OP بتحميل OutputRoot غير صحيح.

للتحقق من صحة OutputRoot on-chain باستخدام العقود الذكية، أبسط طريقة ستكون تنفيذ عميل OP node على سلسلة Ethereum، باستخدام نفس المعلمات الداخلية كمسلسل OP، وتنفيذ نفس البرنامج، والتحقق مما إذا كانت النتيجة المحسوبة متطابقة. يُطلق على هذا النهج برنامج دليل على الاحتيال. بينما يكون من السهل نسبيًا تنفيذه خارج السلسلة، من الصعب جدًا تشغيله على سلسلة Ethereum بسبب مشكلتين:

1. العقود الذكية على إيثريوم لا يمكنها الحصول تلقائيًا على المعلمات اللازمة لدليل الاحتيال.

2. حد الغاز لكتلة Ethereum محدود، ولا يدعم المهام الحسابية المعقدة للغاية. وبالتالي، لا يمكننا تنفيذ عميل العقد OP بالكامل على سلسلة الكتل.

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

بالنسبة للقضية الثانية، كتب فريق تطوير OP جهازاً افتراضياً للـ MIPS بلغة Solidity لتنفيذ بعض وظائف عميل الـ OP Node التي تكفي لنظام دليل الاحتيال. MIPS هي مجموعة تعليمات شائعة لمعمارية معالج الـ CPU، وكود مُوجه OP مكتوب بلغات ذات مستوى أعلى مثل Golang/Rust. يمكننا تجميع برامج Golang/Rust إلى برامج MIPS ومعالجتها من خلال جهاز الـ MIPS الافتراضي على سلسلة الكتل Ethereum.

كتب فريق تطوير OP برنامجا مبسطا في Golang لإثبات الاحتيال ، والذي يحاكي بشكل أساسي الوحدات النمطية في عقدة OP التي تنفذ المعاملات وتولد الكتل وتنتج OutputRoot. ومع ذلك ، لا يزال هذا البرنامج المبسط غير قادر على "التنفيذ بالكامل". بمعنى آخر ، تحتوي كل كتلة OP على العديد من المعاملات. بعد معالجة هذه الدفعة من المعاملات، يتم إنشاء OutputRoot. بينما تعرف أي OutputRoot لارتفاع الكتلة غير صحيح ، سيكون من غير الواقعي تشغيل جميع المعاملات في تلك الكتلة على السلسلة لإثبات أن OutputRoot المقابل خاطئ. علاوة على ذلك ، أثناء تنفيذ كل معاملة ، تتم معالجة سلسلة من رموز تشغيل MIPS بالتسلسل. سيكون من غير العملي تشغيل هذه السلسلة الكاملة من أكواد التشغيل على الجهاز الظاهري MIPS الذي يتم تنفيذه في عقد على السلسلة ، حيث سيكون استهلاك النفقات العامة والغاز الحسابي كبيرا جدا.

(مبدأ عمل مجموعة تعليمات MIPS)

لمعالجة هذه المسألة، قام فريق الOptimism بتصميم نظام تفاعلي دليل على الاحتيال مستهدفًا تحليل عميق لتدفق معالجة المعاملات لـ OP. من خلال مراقبة عملية الحساب الكاملة لـ OutputRoot، يحدد النظام في أي كود MIPS حدث خطأ في ماكينة الـ MIPS الافتراضية لمُتسلسل OP. إذا تم تأكيد وجود خطأ، فيمكن استنتاج أن OutputRoot الذي قدمه المتسلسل غير صالح.

لذلك، يصبح الأمر واضحًا: يمكن تقسيم عملية تجميع متسلسل OP sequencer للمعاملات إلى كيفية معالجة مرتبة لعدد كبير من أكواد MIPS. بعد تنفيذ كل كود MIPS، يتغير تجزء الحالة الخاص بالجهاز الظاهري. يمكن تجميع هذه السجلات في شجرة Merkle.

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

من حيث تنفيذ الشفرة، ستقوم العقود الذكية على سلسلة الإيثيريوم المتعلقة بدليل الاحتيال بإكمال عملية تنفيذ رموز MIPS النهائية من خلال وظيفة تسمى Step:

المعلمات في الدالة أعلاه، _stateData و _proof، تمثل عناصر البيانات التابعة لتنفيذ فكرة MIPS واحدة، مثل حالة التسجيل لجهاز MIPS الافتراضي، وتجزئة حالة الذاكرة، إلخ. يظهر الرسم البياني أدناه:

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

نشير عمومًا إلى تجزئة _stateData باسم statehash، والتي يمكن تفهمها تقريبيًا على أنها تجزئة لحالة الجهاز الافتراضي MIPS بأكمله. من بين الحقول العديدة في _stateData، تعتبر memRoot أكثر تصميمات العبقرية. كما نعلم، أثناء تنفيذ برنامج ما، يتم استخدام كمية كبيرة من الذاكرة، ويتفاعل المعالج المركزي مع البيانات في عناوين الذاكرة معينة من خلال القراءة والكتابة. لذلك، عند تنفيذ سلسلة MIPS opcode على السلسلة من خلال وظيفة VM.Step، نحتاج إلى توفير البيانات من عناوين ذاكرة معينة في جهاز الافتراضي MIPS.

يستخدم OP معمارية بت 32 لجهاز العمل الظاهري MIPS، وذاكرته يحتوي على 2^27 عنوانًا، يمكن تنظيمها في شجرة Merkle ثنائية المستوى 28. تصل عقد الأوراق في أدنى مستوى إلى 2^27، حيث يسجل كل ورقة البيانات من عنوان الذاكرة الخاص بجهاز العمل الظاهري. الهاش الذي يتم حسابه من كل البيانات في الأوراق هو memRoot. تُظهر الرسم البياني أدناه هيكل شجرة Merkle التي تسجل بيانات ذاكرة جهاز العمل الظاهري MIPS:

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

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

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

قد يكون العديد من الأشخاص قد قرؤوا شروحات بسيطة عن دلائل الاحتيال التفاعلية عبر الإنترنت وسمعوا عن النهج الثنائي للبحث الذي يقف وراءها. فريق OP قام بتطوير بروتوكول يسمى Fault Dispute Game (FDG). يتضمن بروتوكول FDG دورين: المتحدى والمدافع.

إذا اكتشفنا أن OutputRoot المقدم من قبل المتسلسل على السلسلة غير صحيح، يمكننا العمل كمتحدين في FDG، مع المتسلسل يعمل كمدافع. لمساعدة في تحديد التعليمة MIPS التي يجب معالجتها على السلسلة، يتطلب بروتوكول FDG من المشاركين بناء شجرة Merkle محلياً تسمى GameTree، التي تتبع الهيكل المحدد التالي:

يمكننا رؤية أن GameTree معقد للغاية، بنية متداخلة بشكل تسلسلي، تتكون من شجرة مستوى أول وشجيرات فرعية من المستوى الثاني. بمعنى آخر، تحتوي العقد الورقية لشجرة المستوى الأول على شجرة فرعية.

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

بمجرد تحديد الكتلة المتنازع عليها، نقوم بالانتقال إلى المستوى الثاني من شجرة اللعبة. الشجرة في المستوى الثاني هي أيضًا شجرة Merkle، حيث تكون العقد الورقية التابعة لها تجاعيد حالة تجارب الآلة الافتراضية MIPS، كما تم تقديمه سابقًا. في سيناريو دليل الاحتيال، سيكون لدى المتحدي والدافع تناقضات في العقد الورقية لشجرة اللعبة التي يقومون بإنشائها محليًا. ستختلف عقد الحالة بعد معالجة تعليمة محددة.

بعد تفاعلات متعددة على السلسلة، تحديد الأطراف في النهاية الكود العملية المتنازع عليه بالضبط، محددًا رمز عملية MIPS الذي يجب تشغيله على السلسلة.

في هذه النقطة، لقد أكملنا عملية دليل الاحتيال التفاعلي بالكامل. للتلخيص، الآليتان الأساسيتان لدليل الاحتيال التفاعلي هما:

1. تحديد الـ FDG (لعبة النزاع على الخطأ) أولاً العنوان الفيزيائي الذي يجب تنفيذه على السلسلة، جنبًا إلى جنب مع معلومات حالة VM في ذلك الوقت؛

2. تُنفّذ آلة القياس الافتراضية MIPS المُنفّذة على سلسلة الكتل Ethereum الكود العملياتي، مما يؤدي إلى النتيجة النهائية.

دليل على الاحتيال ZK

بما أننا نرى، ينطوي النهج التقليدي لدليل الاحتيال على تفاعلات معقدة جدًا، مما يتطلب جولات متعددة من التفاعل في عملية FDG وإعادة تشغيل التعليمات الفردية على السلسلة. ومع ذلك، تواجه هذه الحلول تحديات عدة:

يجب تشغيل جولات متعددة من التفاعل على سلسلة الكتل الإيثريوم، مما يؤدي إلى عشرات من التفاعلات التي تتكبد تكاليف غاز كبيرة. 2. يستغرق عملية دليل الاحتيال التفاعلي وقتًا طويلاً، وبمجرد بدء التفاعل، يتعذر على Rollup معالجة المعاملات بشكل طبيعي. 3. تنفيذ آلة افتراضية محددة على السلسلة لإعادة تشغيل التعليمات معقد للغاية، مع صعوبة تطوير عالية.

لمعالجة هذه المشاكل، قدمت Optimism مفهوم ZK Fraud Proof. الفكرة الأساسية هي أنه عندما يثير المتحدي تحديًا، يحددون المعاملة التي يعتقدون أنه يجب إعادة تشغيلها على السلسلة. يوفر Rollup sequencer دليل ZK للمعاملة التي تم تحديها، والتي يتم التحقق منها بواسطة عقد ذكي على سلسلة Ethereum. إذا كان التحقق ناجحًا، يتم الاستنتاج من عدم وجود أخطاء في معالجة المعاملة، وأن العقد Rollup ليس مذنبًا.

في الرسم البياني، التحدييشير إلى الطرف الذي يثير التحدي، والمدافعهو متسلسل OP. في الظروف العادية، يولد متسلسل OP الكتل استنادًا إلى المعاملات المستلمة ويقدم التزامات الحالة للكتل المختلفة إلى إثيريوم. يمكن اعتبار هذه التزامات الحالة ببساطة كقيم التجزئة للكتل. يمكن للمتحد المتحد أن يتحدى استنادًا إلى تجزئة الكتلة. بعد قبول التحدي، يولد المدافع دليل ZK لإثبات أن نتائج توليد الكتل صحيحة. في الرسم البياني، بونسايهو في الواقع أداة توليد ZK proof. بالمقارنة مع دلائل الاحتيال التفاعلية، أكبر ميزة لـ ZK Fraud Proof هي أنها تستبدل جولات متعددة من التفاعل بجولة واحدة من توليد ZK proof والتحقق على السلسلة. هذا يوفر الوقت بشكل كبير ويقلل من تكاليف الغاز. علاوة على ذلك، على عكس ZK Rollups، OP Rollups القائمة على ZK Fraud Proof لا تتطلب توليد الأدلة في كل مرة يتم فيها إنتاج كتلة. بدلاً من ذلك، يتم توليد دليل ZK مؤقتًا فقط عند التحدي، مما يقلل أيضًا من تكاليف الحوسبة لعقد Rollup.

تم اعتماد مفهوم ZK Fraud Proof أيضًا بواسطة BitVM2. تقوم المشاريع التي تستخدم BitVM2 ، مثل Bitlayer و Goat Network و ZKM و Fiama ، بتنفيذ برنامج التحقق من ZK Proof من خلال سكريبتات بيتكوين ، مما يبسط بشكل كبير حجم البرامج التي تحتاج إلى إحضارها على السلسلة. بسبب قيود المساحة ، لن تدخل هذه المقالة في تفاصيل أكثر حول هذا الموضوع. ترقبوا مقالتنا القادمة حول BitVM2 للحصول على فهم أعمق لمسار تنفيذها!

تنصيح قانوني:

1. يتم استنساخ هذا المقال من [ GodRealmX], ينتمي حق الطبع إلى الكاتب الأصلي [Shew & Noah]، إذا كان لديك أي اعتراض على إعادة الطبع، يرجى الاتصال بالبوابة تعلمالفريق، وسيتولى الفريق ذلك في أقرب وقت ممكن وفقًا للإجراءات ذات الصلة.

2. إخلاء المسؤولية: تعبر الآراء والآراء المعبر عنها في هذه المقالة فقط عن آراء الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة إصدارات اللغات الأخرى من المقالة من قبل فريق Gate Learn ولم يتم ذكرها في Gate.io، قد لا يتم نسخ المقال المترجم أو توزيعه أو ارتكاب الانتحال.