1. مقدمة

Bitcoin هو أصل رقمي لامركزي وآمن وجدير بالثقة. ومع ذلك ، فإنه يواجه قيودا كبيرة تمنعه من أن يصبح شبكة قابلة للتطوير للمدفوعات والتطبيقات الأخرى. كانت مشكلة توسيع نطاق Bitcoin مصدر قلق منذ إنشائها. يعامل نموذج UTXO (مخرجات المعاملات غير المنفقة) الخاص ب Bitcoin كل معاملة على أنها حدث مستقل ، مما يؤدي إلى نظام عديم الجنسية يفتقر إلى القدرة على تنفيذ حسابات معقدة تعتمد على الحالة. نتيجة لذلك ، في حين أن Bitcoin يمكنها إجراء برامج نصية بسيطة ومعاملات متعددة التواقيع ، إلا أنها تكافح لتسهيل تفاعلات العقود المعقدة والديناميكية الشائعة على منصات blockchain ذات الحالة. يقيد هذا القيد بشكل كبير نطاق التطبيقات اللامركزية (dApps) والأدوات المالية المعقدة التي يمكن بناؤها على Bitcoin ، في حين توفر نماذج النظام الأساسي ذات الحالة بيئة أكثر تنوعا لنشر وتنفيذ العقود الذكية الغنية بالميزات.

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

في ديسمبر 2023، روبن لينوس، قائد مشروع زيروسينك، نشر ورقة بيضاء بعنوان “بِتVM: حساب أي شيء على بِتكوين"، مما أثار تفكيرا كبيرا في تعزيز قابلية برمجة البيتكوين. تقترح الورقة حل عقد بيتكوين كامل تورينج يمكنه تنفيذ أي حساب معقد على بيتكوين دون تغيير قواعد إجماع الشبكة أو تغيير المبادئ الأساسية للبيتكوين. تستفيد BitVM من نصوص Bitcoin النصية و Taproot لتنفيذ مجموعات متفائلة. يستخدم توقيعات Lamport (المعروفة أيضا باسم التزام البت) لإنشاء اتصالات بين اثنين من Bitcoin UTXOs ، مما يتيح نصوص Bitcoin ذات الحالة. يتم الالتزام ببرنامج كبير داخل عنوان Taproot ، وينخرط المشغلون والمدققون في تفاعلات واسعة النطاق خارج السلسلة ، مما يترك بصمة ضئيلة على blockchain. إذا تعاون الطرفان ، يمكن تنفيذ أي حساب معقد وحالة خارج السلسلة دون ترك أي أثر على blockchain. ومع ذلك ، إذا لم يتعاون الطرفان ، فإن التنفيذ على السلسلة مطلوب في حالة حدوث نزاع. لذلك ، توسع BitVM بشكل كبير حالات الاستخدام المحتملة ل Bitcoin ، مما يسمح لها بالعمل ليس فقط كعملة ولكن أيضا كمنصة تحقق لمختلف التطبيقات اللامركزية والمهام الحسابية المعقدة.

ومع ذلك ، على الرغم من مزايا تقنية BitVM في توسيع نطاق Bitcoin ، إلا أنها لا تزال في المراحل المبكرة وتواجه بعض مشكلات الكفاءة والأمان ، مثل: (1) تتطلب التحديات والاستجابات تفاعلات متعددة ، مما يؤدي إلى ارتفاع رسوم المعاملات وفترات التحدي الطويلة ؛ (2) توقيعات لامبورت لمرة واحدة لها أطوال بيانات طويلة ، مما يستلزم تقليل حجم البيانات ؛ (3) يتطلب تعقيد وظيفة التجزئة العالية وظائف تجزئة صديقة للبيتكوين لتقليل التكاليف ؛ (4) عقود BitVM الحالية كبيرة ، وسعة كتلة Bitcoin محدودة ، لذا فإن استخدام البرامج النصية غير النصية يمكن أن يساعد في تحقيق البرامج النصية BitVM ، مما يوفر مساحة كتلة Bitcoin ويعزز كفاءة BitVM ؛ (5) تعمل BitVM الحالية على نموذج إذن ، مع بدء التحديات فقط من قبل أعضاء الاتحاد وتقتصر على طرفين ، والتي يجب توسيعها إلى نموذج تحدي متعدد الأطراف بدون إذن لتقليل افتراضات الثقة بشكل أكبر. لمعالجة هذه المشكلات ، تقترح الورقة العديد من أفكار التحسين لتحسين كفاءة BitVM وأمانها.

2. مبدأ بت VM

BitVM موضوعة كنظام عقد خارج السلسلة الرئيسية لبيتكوين، بهدف تعزيز وظائف العقد في بيتكوين. حاليًا، تكون النصوص الخاصة ببيتكوين خالية تمامًا من الحالة، مما يعني إعادة ضبط بيئة التنفيذ بعد كل نص. ليس هناك وسيلة أصلية في برمجة بيتكوين لضمان أن النصوص 1 و 2 لديها نفس قيمة x. ومع ذلك، يمكن جعل النصوص الخاصة ببيتكوين تحتفظ بالحالة باستخدام الأوامر الحالية والتواقيع ذات المرة الواحدة من لامبورت، مما يفرض أن x في النص 1 والنص 2 هما نفس القيمة. إذا قام المشاركون بتوقيع قيم x متعارضة، فإنهم يمكن أن يتعرضوا للعقوبة.

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

مثل النسخة الاحتياطية المتفائلة واقتراح MATT (تمرير كل الأشياء)، يعتمد نظام BitVM على دلائل الغش وبروتوكولات التحدي والرد لكنه لا يتطلب تغييرات في قواعد الاتفاق لبيتكوين. تعتمد مكونات BitVM الأساسية على قفل الهاش، قفل الزمن، وشجرات Taproot الكبيرة بشكل أساسي.

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

المكونات الرئيسية لـ بِت VM تتضمن:

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

3. تحسينات بِت VM

تقليل أرقام تفاعل OP بناءً على ZK 3.1

هناك نوعان رئيسيان من Rollups: ZK Rollups و Optimistic Rollups (OP Rollups). تعتمد ZK Rollups على التحقق من صحة الأدلة الرياضية (ZK) ، والتي هي أدلة تشفيرية على تنفيذ صحيح. أمنهم يعتمد على افتراضات تعقيد الحسابات. تعتمد Optimistic Rollups على أدلة الاحتيال ، مع افتراض أن جميع الحالات المقدمة صحيحة وعادةً ما تحدد فترة تحدي لمدة حوالي سبعة أيام. أمنهم يفترض أنه يمكن لطرف واحد على الأقل في النظام اكتشاف الحالة الغير صحيحة وتقديم دليل احتيال.

بفرض أن الحد الأقصى لعدد الخطوات في برنامج التحدي في BitVM هو 2^{32}، فإنه سيحتاج إلى حوالي 17 جيجابايت من الذاكرة (2^{32}×4 بايت). في أسوأ السيناريوهات، قد يستغرق حوالي 40 جولة من التحديات والردود حوالي ستة أشهر، مع حجم نصي إجمالي يبلغ حوالي 150 كيلوبايت. هذا السيناريو سيوفر حوافز غير كافية، لكنه نادرا ما يحدث في الواقع.

استخدام الأدلة بدون معرفة لتقليل عدد التحديات في بيتVM يمكن أن يعزز كفاءته. وفقًا لنظرية الأدلة بدون معرفة، إذا كانت البيانات Data تفي بالخوارزمية F، فإن البرهان يفي بخوارزمية التحقق Verify، مخرجًا True. وعلى العكس، إذا لم تف بالبيانات F، فإن البرهان لن يف بالتحقق Verify، مخرجًا False. في نظام بيتVM، إذا لم يقبل المتحدي بيانات المثبت، يتم بدء تحدي.

بالنسبة لخوارزمية F، باستخدام نهج البحث الثنائي، نفترض أن 2^n تحتاج التكرارات إلى العثور على نقطة الخطأ. إذا كانت تعقيد الخوارزمية مرتفعة جدًا، و n كبير، ويستغرق وقتًا طويلاً للاكتمال. ومع ذلك، يتم تحديد تعقيد خوارزمية التحقق من البرهان بصفر. من خلال الكشف العام عن البرهان وعملية التحقق Verify، من الممكن رؤية ناتج خطأ. تكمن ميزة البراهين بعدم المعرفة في الحد الأدنى للتعقيد الحسابي المطلوب لفتح خوارزمية التحقق Verify مقارنة بفتح الخوارزمية الأصلية F باستخدام البحث الثنائي. بالتالي، مع البراهين بدون المعرفة، لم يعد BitVM يتحدى الخوارزمية الأصلية F، بل خوارزمية التحقق Verify، مما يقلل من عدد جولات التحدي ويقصر فترة التحدي.

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

3.2 توقيع مرة واحدة ودية للبيتكوين

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

وفقًا لقواعد الاتفاق، يبلغ الحد الأقصى لحجم المعاملات القديمة (غير Segwit) 1 ميغابايت، والذي يمكن أن يملأ كتلة كاملة. ومع ذلك، تم تعيين الحد القياسي للمعاملات القديمة عند 100 كيلوبايت. بالنسبة لمعاملات Segwit، الحد الأقصى المسموح به وفقًا لقواعد الاتفاق هو 4 ميغابايت، المعروف باسم الحد الوزني، ولكن الحد القياسي لها هو 400 كيلوبايت.

توقيعات Lamport هي مكون أساسي من BitVM، وتقليل طول التوقيعات والمفاتيح العامة يساعد على تقليل حجم بيانات المعاملات، مما يقلل من رسوم المعاملات. يتطلب توقيعات Lamport لمرة واحدة وظيفة تجزئة (مثل وظيفة التبديل الوحيد f). في نظام توقيع Lamport لمرة واحدة، طول الرسالة هو v بت، وكل من مفتاح العامة وطول التوقيع هما 2v بت. هذه التوقيعات الطويلة والمفاتيح العامة تستهلك كمية كبيرة من الغاز التخزين. لذلك، من الضروري استكشاف خطط التوقيع التي يمكن أن تقلل من طول التوقيعات والمفاتيح العامة. بالمقارنة مع توقيعات Lamport لمرة واحدة، تقلل توقيعات Winternitz لمرة واحدة بشكل كبير من طول التوقيعات والمفاتيح العامة، ولكنها تزيد من تعقيد العمليات الحسابية للتوقيع والتحقق.

في نظام توقيع Winternitz لمرة واحدة ، تقوم وظيفة خاصة P بتعيين رسالة v-bit إلى متجه s بطول n ، مع أخذ كل عنصر من عناصر s قيمة في {0,...,d}. مخطط توقيع لامبورت لمرة واحدة هو حالة خاصة لمخطط وينترنيتز ، حيث d = 1. في مخطط وينترنيتز ، تكون العلاقة بين n و d و v تقريبا n ≈ v / log2 (d + 1). عندما d = 15 ، n ≈ (v / 4) + 1. بالنسبة لتوقيع Winternitz الذي يحتوي على عناصر n ، يكون طول المفتاح العام والتوقيع أقصر بأربع مرات من تلك الموجودة في نظام التوقيع لمرة واحدة في Lamport ، لكن تعقيد التحقق أعلى بأربع مرات. يمكن أن يؤدي استخدام d = 15 ، v = 160 ، f = ripemd160 (x) في BitVM لتوقيعات Winternitz لمرة واحدة إلى تقليل حجم التزام البت بنسبة 50٪ ، وبالتالي تقليل رسوم معاملات BitVM بنسبة 50٪ على الأقل. في المستقبل ، مع تحسين تنفيذ البرنامج النصي الحالي ل Winternitz Bitcoin ، يمكن متابعة استكشاف مخططات توقيع لمرة واحدة أكثر إحكاما يمكن التعبير عنها في نص Bitcoin.

3.3 وظائف التجزئة ودية للبيتكوين

وفقًا لقواعد الاتفاق، الحد الأقصى لحجم النص البرمجي P2TR هو 10 كيلوبايت، والحد الأقصى لحجم شاهد النص البرمجي P2TR هو نفس حجم معاملة Segwit الأقصى، والذي يبلغ 4 ميجابايت. ومع ذلك، الحد الأقصى للمعيارية لشاهد النص البرمجي P2TR هو 400 كيلوبايت.

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

BLAKE3 هو النسخة المحسنة من وظيفة تجزئة BLAKE2 ويقدم وضع شجرة Bao. بالمقارنة مع BLAKE2s-القائمة ، تم تقليل عدد جولات وظيفة الضغط من 10 إلى 7. تقسم وظيفة تجزئة BLAKE3 مدخلاتها إلى قطع بحجم 1024 بايت ، مع القطعة الأخيرة التي قد تكون أقصر ولكن ليست فارغة. عندما يكون هناك قطعة واحدة فقط ، فإنها تعمل كعقدة جذرية وعقدة الشجرة الوحيدة. يتم ترتيب هذه القطع كعقدة أوراق في شجرة ثنائية ، ويتم ضغط كل قطعة بشكل مستقل.

عند استخدام بِتVM للتحقق من دلائل الاحتواء ميركل، يتكون مدخل عملية الهاش من قيمتي هاش مكونتين متصلتين بطول 256 بت، مما يجعل إجمالي البيانات 64 بايت. مع وظيفة الهاش BLAKE3، يمكن أن تتناسب هذه البيانات 64 بايت ضمن قطعة واحدة، مما يعني أن عملية الهاش BLAKE3 تحتاج فقط إلى تطبيق وظيفة الضغط مرة واحدة على هذه القطعة الواحدة. في وظيفة الضغط في BLAKE3، تتطلب سبع وظائف دورية وست وظائف تبديل.

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

وعلاوة على ذلك، من خلال تقسيم هذه الرموز BLAKE3، يمكن للمحقق والدافع تقليل متطلبات بيانات السلسلة بشكل كبير عن طريق تقسيم التنفيذ إلى لعبة التحدي والاستجابة بدلاً من إجرائها بالكامل. وأخيرًا، تنفيذ وظائف التجزئة مثل Keccak-256 و Grøstl في سكريبت بيتكوين سيحدد وظيفة التجزئة الأكثر ودية لبيتكوين واستكشاف وظائف تجزئة جديدة ودية لبيتكوين.

3.4 النصوص النصية بدون سكريبت بِت VM

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

مزايا النصوص بدون سكريبت تشمل الوظائف والخصوصية والكفاءة:

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

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

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

التحديات متعددة الأطراف دون إذن 3.5

تتطلب تحدي BitVM الحالي إذنًا لأنه يمكن تنفيذ Bitcoin UTXO مرة واحدة فقط، مما يؤدي إلى حالة يمكن فيها للمحقق الخبيث "إضاعة" العقد من خلال تحدي البراهين الصادقة. يتم حاليًا تقييد BitVM بنموذج تحدي ثنائي الأطراف. يمكن للبراهين الخبيثة استخدام محقق يخضع لسيطرته لبدء تحدي و"إضاعة" العقد، مما يضمن نجاح إجراءه الخبيث بينما لا يمكن للمحققين الآخرين منع هذا السلوك. لذلك، فوق بتكوين، من الضروري البحث عن بروتوكول تحدي متعدد الأطراف دون إذن يمكنه توسيع نموذج الثقة 1 من n الحالي لـ 1 من N، حيث يكون N أكبر بكثير من n. بالإضافة إلى ذلك، من المهم معالجة قضايا التواطؤ بين المتحدين والبراهين أو التحديات الخبيثة التي "تضيع" العقود لتحقيق بروتوكول BitVM أكثر تقليلًا للثقة.

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

توسيع بِت VM إلى نموذج تحدي متعدد الأطراف بدون إذن ينطوي على معالجة الهجمات التالية:

• هجمات سيبيل: حتى لو قام المهاجم بإنشاء هويات متعددة للمشاركة في تحدي النزاع، يجب أن يكون بإمكان مشارك واحد صادق الفوز بالنزاع. إذا كانت تكلفة المشارك الصادق في الدفاع عن النتيجة الصحيحة تزداد بشكل خطي مع عدد المهاجمين، فإن تكلفة المشارك الصادق في الفوز بالنزاع تصبح غير عملية وعرضة لهجمات سيبيل عندما يشارك عدد كبير من المهاجمين. الورقة البطولات المحكمة بدون إذنيقترح خوارزمية لحل النزاعات تغيير قواعد اللعبة، حيث ينمو تكلفة فوز مشارك واحد صادق في النزاع بشكل لوغاريتمي، وليس خطيًا، مع عدد المنافسين.
• هجمات التأخير: فرد أو مجموعة من الجهات الفاعلة الخبيثة يتبعون استراتيجية لمنع أو تأخير تأكيد النتيجة الصحيحة (مثل سحب الأصول إلى L1) على L1، مما يجبر الدافع الصادق على إنفاق رسوم المعاملات L1. من أجل التخفيف من هذه المشكلة، قد يكون من الضروري أن يُطلب من المتحدين أن يقدموا رهنًا مسبقًا. إذا قام متحدي ما بشن هجوم تأخير، سيتم ضياع رهانهم. ومع ذلك، إذا كان المهاجمون على استعداد للتضحية برهانهم إلى حد ما من أجل مواصلة هجمات التأخير، يجب أن تكون هناك استراتيجيات لتقليل تأثير هذه الهجمات. الخوارزمية المقترحة في الورقة "BoLD: تأخير السيولة المقيدة في بروتوكول تحدي Rollupيضمن أن الوقت الأقصى للتأخير الناتج عن المهاجم محدود، بغض النظر عن مقدار الحصة التي يرغب المهاجم في خسارتها.

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

4. الختام

إن استكشاف تكنولوجيا بيت VM لا يزال في بدايته، وفي المستقبل، سيتم استكشاف المزيد من الأمثلة والممارسات لتحقيق التوسيع لبيتكوين وإثراء نظام البيتكوين.

إخلاء المسؤولية:

1. هذه المقالة مأخوذة من [ @Bitlayer/ bitvm-and-its-optimization-considerations-007da599d8ac">Bitlayer] ، جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [ليندل وموتوريند]. إذا كانت هناك اعتراضات على هذه الإعادة، يرجى التواصل معبوابة تعلمالفريق، وسيقومون بالتعامل معه بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء التي تم التعبير عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تُجري فرقة Gate Learn ترجمة المقال إلى لغات أخرى. ما لم يُذكر، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.