معرفة BitVM: أفكار تنفيذية لمكافحة الاحتيال ومكافحة الاحتيال ZK

المؤلف: Shew & Noah, GodRealmX

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

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

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

OutputRoot وStateRoot

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

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

إذا قام المُسلسل بتحميل مجموعة تجزئة الحالة الخاطئة إلى إيثريوم،فإن مجموعة تجزئة الحالة التي حسبتها محليًا ستكون مختلفة عنها. في هذا الوقت، يمكنك طرح سؤال من خلال نظام مقاومة الاحتيال.سيقوم النظام بتقييد أو معاقبة أو عدم معاقبة المُسلسل بناءً على نتيجة الحكم. عندما يتعلق الأمر بمصطلح "مجموعة الحالة"، غالبًا ما تستخدم سلاسل الكتل EVM بنية بيانات على غرار Merkle Tree لتسجيل مجموعات الحالة، والتي تسمى World State Trie. بعد تنفيذ المعاملة، ستتغير حالة بعض الحسابات، وستتغير حالة العالم Trie، كما ستتغير التجزئة النهائية أيضًا. يستدعي Ethereum التجزئة النهائية لحالة العالم Trie StateRoot، والتي تُستخدم لتمثيل التغييرات في مجموعة الحالة.

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

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

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

آلة MIPS الافتراضية وشجرة ميركل للذاكرة

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

إذا كنت تريد استخدام عقد ذكي على السلسلة للتحقق من صحة OutputRoot، فإن أسهل طريقة هي تنفيذ عميل عقدة OP على سلسلة Ethereum، واستخدام نفس معلمات الإدخال مثل جهاز تسلسل OP، وتنفيذ نفس البرنامج، والتحقق مما إذا كانت نتائج الحساب متسقة. يُطلق على هذا المخطط اسم Fault Proof Program، وهو سهل التنفيذ خارج السلسلة، ولكن من الصعب جدًا تشغيله على سلسلة Ethereum. لأن هناك مشكلتين: 1. لا يمكن للعقد الذكي على Ethereum الحصول تلقائيًا على معلمات الإدخال المطلوبة لإثبات الاحتيال؛ 2. حد الغاز لكل كتلة في Ethereum محدود، ولا يدعم مهام الحوسبة المعقدة للغاية. لا يمكننا تنفيذ عميل عقدة OP بالكامل على السلسلة. المشكلة الأولى تعادل السماح للعقد الذكي الموجود على السلسلة بقراءة البيانات خارج السلسلة، والتي يمكن حلها بحل مشابه لـ Oracle. لقد قام OP بنشر عقد PreimageOracle على سلسلة Ethereum بشكل خاص. يمكن للعقود المقاومة للاحتيال قراءة البيانات المطلوبة في PreimageOracle.

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

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

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

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

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

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

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

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

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

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

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

إثبات الاحتيال التفاعلي

في ما سبق، قمنا بحل المشكلة الثانية وأكملنا تنفيذ التعليمات البرمجية لـ MIPS على السلسلة والتحقق من حالة الجهاز الظاهري، ولكن كيف يمكن للمتحدي والمتسلسل تحديد تعليمات التعليمات البرمجية المثيرة للجدل لـ MIPS؟ أعتقد أن كثيرًا من الناس قد قرأوا شرحًا بسيطًا لأساليب إثبات الاحتيال التفاعلية على الإنترنت وسمعوا عن ثنائيتها. قام فريق OP بتطوير بروتوكول يسمى Fault Dispute Game (FDG). في FDG، هناك دوران: المتحدي والمدافع.

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

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

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

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

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

إثبات الاحتيال القائم على ZK

يمكننا أن نرى أن تفاعل إثبات الاحتيال التقليديالمذكور أعلاه معقد للغاية، ويتطلب جولات متعددة من التفاعل في عملية FDG ثم إعادة تشغيل تعليمة واحدة على السلسلة. ومع ذلك، فإن هذا الحل يواجه العديد من الصعوبات: 1. يجب تشغيل جولات متعددة من التفاعلات على سلسلة Ethereum، الأمر الذي يتطلب عشرات التفاعلات وسيتسبب في الكثير من تكاليف الغاز؛ 2. عملية إثبات الاحتيال التفاعلي طويلة. بمجرد بدء التفاعل، لا يمكن لـ Rollup تنفيذ المعاملات بشكل طبيعي؛ 3. من الأكثر تعقيدًا تنفيذ جهاز افتراضي محدد على السلسلة لإعادة تشغيل التعليمات، وصعوبة التطوير عالية للغاية. من أجل حل هذه المشكلات، اقترحت Optimism رسميًا مفهوم ZK Fraud Proof. الجوهر هو أنه عندما يقوم المتحدي بتحدي، فإنه يحدد معاملة يعتقد أنها بحاجة إلى إعادة تشغيلها على السلسلة. يقدم مُسلسل Rollup دليل ZK للمعاملة المتحدية، والتي يتم التحقق منها بواسطة العقد الذكي على Ethereum. إذا نجح التحقق، فيمكن اعتبار أن تدفق معالجة المعاملة صحيح وأن عقدة Rollup لم تفعل أي شيء شرير.

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

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

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