ليرة تركية؛ د

المقدمة:

توفر هذه المقالة تفسيرًا لمستند معلومات BitVM، موضحًا نهج BitVM: لا يلزم أن تكون البيانات متصلة بالسلسلة في البداية؛ يتم نشره وتخزينه خارج السلسلة، مع حفظ الالتزام فقط على blockchain.

عنوان المقالة الأصلية المعاد توجيهها: تفسير مبسط لـ BitVM: كيفية التحقق من أدلة الاحتيال على سلسلة BTC Blockchain (تنفيذ EVM أو أكواد تشغيل VM أخرى)

مقدمة: في الوقت الحالي، أصبحت طبقة البيتكوين الثانية اتجاهًا، حيث تُعرف العشرات من المشاريع بأنها "طبقة البيتكوين الثانية". العديد من هؤلاء، الذين يدعون أنهم "مجموعات"، يشيرون إلى أنهم يستخدمون النهج المقترح في ورقة عمل BitVM، مما يجعل BitVM جزءًا بارزًا من نظام Bitcoin البيئي.

ومع ذلك، فإن معظم الأدبيات الموجودة حول BitVM لا تشرح مبادئها بعبارات عامة. تقدم هذه المقالة، استنادًا إلى قراءتنا لمستند معلومات BitVM المكون من 8 صفحات وبعد استشارة الموارد المتعلقة بـ Taproot وأشجار MAST وBitcoin Script، ملخصًا مبسطًا. للمساعدة في الفهم، قمنا بتغيير بعض التعبيرات عن تلك الموجودة في ورقة عمل BitVM، على افتراض أن القارئ لديه بعض المعرفة بالطبقة الثانية ويمكنه استيعاب الفكرة الأساسية المتمثلة في "إثباتات الاحتيال".

يمكن تلخيص المفهوم الأولي لـ BitVM في بضع جمل: فهو يلغي الحاجة إلى البيانات الموجودة على السلسلة، حيث يقوم في البداية بنشر البيانات وتخزينها خارج السلسلة، مع الالتزام فقط المخزن على blockchain. في حالات التحديات أو إثبات الاحتيال، يتم إحضار البيانات الضرورية فقط على السلسلة لإثبات ارتباطها بالالتزام على blockchain. بعد ذلك، تتحقق شبكة BTC الرئيسية من البيانات الموجودة على السلسلة بحثًا عن أي مشكلات وما إذا كان منتج البيانات (العقدة التي تعالج المعاملات) قد شارك في أنشطة ضارة. يلتزم هذا النهج بمبدأ Occam's Razor — "لا ينبغي مضاعفة الكيانات دون داع" (إذا كان من الممكن أن تكون خارج السلسلة، فابقها خارج السلسلة).

النص الرئيسي: ما يسمى بنظام التحقق من الاحتيال ضد الاحتيال في blockchain BTC استنادًا إلى BitVM، بعبارات الشخص العادي:

1. أولاً، الكمبيوتر/المعالج هو نظام إدخال وإخراج يتكون من عدد كبير من دوائر البوابات المنطقية. إحدى الأفكار الأساسية لـ BitVM هي استخدام Bitcoin Script لمحاكاة تأثيرات المدخلات والمخرجات لدوائر البوابة المنطقية. وطالما يمكن محاكاة دوائر البوابة المنطقية، فمن الناحية النظرية، يمكن تحقيق آلة تورينج، واستكمال جميع المهام القابلة للحساب. هذا يعني أنه إذا كان لديك ما يكفي من الموارد والقوى العاملة، فيمكنك جمع فريق من المهندسين لمحاكاة دوائر البوابة المنطقية أولاً باستخدام كود Bitcoin Script البدائي، ثم استخدام كمية هائلة من دوائر البوابة المنطقية لتنفيذ وظائف EVM أو WASM .

(لقطة الشاشة هذه مأخوذة من لعبة تعليمية: "Turing Complete"، حيث يتمثل المحتوى الأساسي في بناء معالج كامل لوحدة المعالجة المركزية (CPU)، خاصة باستخدام دوائر البوابات المنطقية مثل بوابات NAND.)

وقد شبه البعض أسلوب BitVM ببناء معالج M1 في "Minecraft" باستخدام دوائر ريدستون. أو أنه يشبه بناء مبنى إمباير ستيت في نيويورك باستخدام مكعبات ليغو.

(يقال أن أحدهم قضى سنة في بناء «معالج» في «ماين كرافت»).

1. فلماذا نستخدم Bitcoin Script لمحاكاة EVM أو WASM؟ أليس هذا مرهقا جدا؟ والسبب هو أن معظم حلول Bitcoin Layer 2 غالبًا ما تختار دعم اللغات عالية المستوى مثل Solidity أو Move، في حين أن اللغة الوحيدة التي يمكن تشغيلها حاليًا مباشرة على Bitcoin blockchain هي Bitcoin Script. هذه اللغة بدائية، وتتكون من مجموعة من أكواد التشغيل الفريدة، وليست لغة تورينج كاملة.

(مثال على كود Bitcoin النصي)

إذا كانت Bitcoin Layer 2 تهدف إلى التحقق من أدلة الاحتيال على الطبقة 1 مثل حلول الطبقة 2 من Ethereum مثل Arbitrum، لترث أمان BTC بشكل كبير، فإنها تحتاج إلى التحقق مباشرة من "معاملة متنازع عليها" أو "رمز تشغيل متنازع عليه" على blockchain BTC. وهذا يعني أن أكواد تشغيل لغة Solidity / EVM التي تستخدمها الطبقة الثانية تحتاج إلى إعادة تنفيذها على blockchain Bitcoin. ويتلخص التحدي في:

استخدام Bitcoin Script، وهي لغة برمجة أصلية ولكنها بدائية من Bitcoin، لتحقيق تأثيرات EVM أو الأجهزة الافتراضية الأخرى.

لذلك، من منظور مبادئ التجميع، يقوم نهج BitVM بترجمة أكواد تشغيل EVM / WASM / JavaScript إلى أكواد تشغيل Bitcoin Script، حيث تعمل دوائر البوابة المنطقية كتمثيل وسيط (IR) بين "أكواد تشغيل EVM -> أكواد تشغيل Bitcoin Script".

(تناقش ورقة عمل BitVM النهج العام لتنفيذ بعض "التعليمات المتنازع عليها" على blockchain Bitcoin)

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

1. دعونا نناقش مفهومًا أساسيًا آخر مذكورًا في ورقة عمل BitVM، وهو "إثباتات الاحتيال التفاعلية" التي تشبه إلى حد كبير تلك المستخدمة من قبل Arbitrum.

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

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

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

متابعة لهذا:

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

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

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

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

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

مراجع:

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

(المخطط التفاعلي لإثبات الاحتيال في Arbitrum، الشرح تقريبي نسبيًا)

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

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

تطبق Arbitrum التأثيرات المذكورة أعلاه من خلال العقود على Ethereum، بينما تهدف BitVM إلى تحقيق وظائف مماثلة باستخدام Bitcoin Script لتنفيذ أقفال الوقت والتوقيع المتعدد وميزات أخرى.

4. بعد مناقشة "أدلة الاحتيال التفاعلية" و"أدلة الاحتيال ذات الخطوة الواحدة"، سنتحدث عن أشجار MAST وأدلة Merkle. ذكرنا سابقًا أنه في حل BitVM، لا يتم وضع الكمية الهائلة من بيانات المعاملات ودوائر البوابات المنطقية التي تتم معالجتها خارج السلسلة في الطبقة الثانية مباشرة على السلسلة. يتم وضع كمية قليلة فقط من دوائر بوابة البيانات/المنطق على السلسلة عند الضرورة. ومع ذلك، نحتاج إلى طريقة لإثبات أن هذه البيانات، التي كانت في الأصل خارج السلسلة وتحتاج الآن إلى وضعها على السلسلة، ليست ملفقة. وهنا يأتي دور مفهوم الالتزام في التشفير، ويعد Merkle Proof أحد أشكال هذا الالتزام.

أولاً، دعونا نتحدث عن أشجار MAST. الاسم الكامل لـ MAST هو Merkelized Abstract Syntax Trees، وهي عبارة عن تحويل AST (أشجار بناء الجملة المجردة) من عالم مبادئ المترجم إلى Merkle Trees. إذًا، ما هو AST؟ بعبارات بسيطة، إنها بنية بيانات شبيهة بالشجرة تقوم بتقسيم أمر معقد إلى مجموعة من وحدات التشغيل الأساسية من خلال التحليل المعجمي.

(مثال على شجرة AST هو تقسيم العمليات الحسابية البسيطة مثل "x=2, y=x*3" إلى رموز وبيانات التشغيل الأساسية. )

شجرة MAST هي نتيجة تطبيق Merkleization على شجرة AST، مما يدعم Merkle Proofs. إحدى ميزات أشجار Merkle هي قدرتها على "ضغط" البيانات بكفاءة. على سبيل المثال، إذا كنت ترغب في نشر جزء من البيانات من شجرة Merkle على blockchain BTC عند الضرورة، مع جعل من المصداقية أيضًا أن شريحة البيانات هذه موجودة بالفعل على شجرة Merkle ولم يتم اختيارها بشكل تعسفي، فماذا تفعل؟

ما عليك سوى تسجيل جذر شجرة Merkle على blockchain مسبقًا. في المستقبل، سيكون تقديم دليل Merkle الذي يثبت وجود جزء من البيانات على شجرة Merkle المقابلة للجذر كافيًا.

(العلاقة بين دليل Merkle/الفرع والجذر)

وبالتالي، ليست هناك حاجة لتخزين شجرة MAST الكاملة على blockchain BTC؛ يكفي الكشف عن جذره مسبقًا كالتزام. عند الضرورة، يكون تقديم شريحة البيانات + إثبات/فرع Merkle كافيًا. وهذا يقلل بشكل كبير من كمية البيانات الموجودة على السلسلة مع ضمان وجود البيانات الموجودة على السلسلة بشكل حقيقي على شجرة MAST. علاوة على ذلك، فإن الكشف عن جزء صغير فقط من شرائح البيانات + Merkle Proof على blockchain BTC، بدلاً من جميع البيانات، يمكن أن يعزز حماية الخصوصية بشكل كبير.

المراجع:حجب البيانات ومقاومة الاحتيال: لماذا لا تدعم البلازما العقود الذكية

(مثال شجرة MAST)

في حل BitVM، يتم التعبير عن جميع دوائر البوابات المنطقية باستخدام نصوص Bitcoin، ويتم تنظيمها في شجرة MAST ضخمة. تتوافق الأوراق السفلية لهذه الشجرة، المشار إليها بالمحتوى في الرسم التخطيطي، مع دوائر البوابة المنطقية المطبقة في برنامج Bitcoin النصي. ينشر مقترح الطبقة الثانية بشكل متكرر جذر شجرة MAST على blockchain BTC، مع ربط كل شجرة MAST بمعاملة تتضمن جميع معلمات الإدخال/أكواد التشغيل/دوائر البوابة المنطقية. يشبه هذا إلى حد ما مقترح Arbitrum الذي ينشر الكتل المجمعة على blockchain Ethereum.

عندما ينشأ نزاع، يعلن المنافس على blockchain BTC عن الجذر الذي يرغب في تحديه، ثم يطلب من مقدم العرض الكشف عن شريحة بيانات محددة تتوافق مع الجذر. بعد ذلك، يقدم مقدم العرض دليل Merkle، ويكشف باستمرار عن أجزاء صغيرة من بيانات شجرة MAST الموجودة على السلسلة حتى يتم تحديد موقع دائرة البوابة المنطقية المتنازع عليها بشكل مشترك مع المنافس. بعد ذلك، يمكن تنفيذ Slash.

(المصدر:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

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

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

على الرغم من أن إثبات الاحتيال بخطوة واحدة لا يتطلب سوى كمية صغيرة جدًا من البيانات وبرنامج نصي للبوابة المنطقية على السلسلة، إلا أنه يجب تخزين شجرة Merkle الكاملة خارج السلسلة لفترة طويلة، بحيث يمكن الوصول إليها عبر السلسلة في أي وقت. الوقت إذا كان شخص ما يتحدى ذلك. تولد كل معاملة في الطبقة الثانية شجرة ميركل كبيرة، ويمكن للمرء أن يتخيل الضغط الحسابي والتخزيني على العقد. قد لا يرغب معظم الأشخاص في تشغيل العقد (ومع ذلك، يمكن التخلص التدريجي من هذه البيانات التاريخية، وتقدم شبكة B^2 على وجه التحديد أدلة تخزين zk مشابهة لـ Filecoin لتحفيز عقد التخزين للحفاظ على البيانات التاريخية على المدى الطويل).

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

ومع ذلك، هناك العديد من التحديات في تصميم حلول الطبقة الثانية المعتمدة على BitVM، مثل:

1) من الناحية النظرية، لمزيد من ضغط البيانات، ليس من الضروري التحقق من أكواد التشغيل مباشرة على الطبقة الأولى. يمكن ضغط تدفق معالجة أكواد التشغيل بشكل أكبر في دليل zk، مما يسمح للمنافسين بتحدي خطوات التحقق من دليل zk. وهذا يمكن أن يقلل بشكل كبير من كمية البيانات الموجودة على السلسلة. ومع ذلك، قد تكون تفاصيل التطوير المحددة معقدة للغاية.

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

تنصل:

1. تمت إعادة طباعة هذه المقالة من [Geek Web3]، إعادة توجيه العنوان الأصلي "تفسير مبسط لـ BitVM: كيفية التحقق من دليل الاحتيال على سلسلة BTC (تنفيذ رمز تشغيل EVM أو جهاز افتراضي آخر)"، حقوق الطبع والنشر مملوكة للمؤلف الأصلي [فاوست والقمر الضبابي]
   . إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.