Bitlayer: BitVM وأفكار التحسين الخاصة به

المؤلف: لينديل، موتوريند؛ المصدر: مجموعة أبحاث Bitlayer

1. مقدمة

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

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

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

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

2. مبدأ BitVM

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

على غرار Optimistic Rollup واقتراح MATT (Merkelize All The Things)، يعتمد نظام BitVM على بروتوكولات مقاومة الاحتيال والاستجابة للتحدي، ولكنه لا يتطلب تعديل نظام Bitcoin. قواعد الإجماع. البدائيات الأساسية لـ BitVM بسيطة، وتعتمد بشكل أساسي على أقفال التجزئة وأقفال الوقت وأشجار Taproot الكبيرة.

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

المكونات الرئيسية لـ BitVM هي:

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

• التحدي والاستجابة: يقوم المُثبت والمتحقق بالتوقيع مسبقًا على سلسلة من المعاملات لتنفيذ لعبة التحدي والاستجابة. من الناحية المثالية، يتم تنفيذ هذا التفاعل خارج السلسلة، ولكن يمكن أيضًا إجراؤه على السلسلة عندما يكون المُثبِّت غير متعاون.

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

3.تحسين BitVM

3.1 تقليل عدد تفاعلات OP بناءً على ZK

يوجد حاليًا مجموعتان رئيسيتان من المجموعات المجمعة: مجموعات ZK ومجموعات OP. من بينها، تعتمد ZK Rollups على التحقق من صحة ZK Proof، أي إثبات التشفير للتنفيذ الصحيح، ويعتمد أمانها على افتراض التعقيد الحسابي؛ وتعتمد OP Rollups على Fraud Proof، على افتراض أن الحالات المقدمة صحيحة، وإعداد عادة ما تكون فترة التحدي 7 أيام، ويفترض أمانها أن طرفًا نزيهًا واحدًا على الأقل في النظام يمكنه اكتشاف الحالة غير الصحيحة وتقديم دليل على الاحتيال. افترض أن الحد الأقصى لعدد خطوات برنامج تحدي BitVM هو 2^{32}، وأن الذاكرة المطلوبة هي 2^{32}*4 بايت، أي حوالي 17 جيجابايت. في أسوأ الحالات، يستغرق الأمر حوالي 40 جولة من التحدي والاستجابة، أي حوالي نصف عام، ويبلغ إجمالي النص حوالي 150 كيلو بايت. هناك نقص خطير في الحوافز في هذه الحالة، لكن هذا لا يحدث أبدًا في الممارسة العملية.

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

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

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

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

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

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

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

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

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

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

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

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

عند استخدام BitVM للتحقق من سيناريو إثبات تضمين Merkle، يتكون إدخال عملية التجزئة من قيمتي تجزئة 256 بت، أي إدخال التجزئة العملية 64 بايت. عند استخدام وظيفة تجزئة BLAKE3، يمكن تخصيص هذه البايتات البالغ عددها 64 بايت داخل قطعة واحدة، وتحتاج عملية تجزئة BLAKE3 بأكملها فقط إلى تطبيق وظيفة الضغط مرة واحدة على قطعة واحدة. في وظيفة الضغط لـ BLAKE3، من الضروري تشغيل الوظيفة الدائرية 7 مرات ووظيفة الإزاحة 6 مرات.

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

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

3.4 البرامج النصية بدون نصوص BitVM

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

تتمثل مزايا البرامج النصية بدون Script في الأداء الوظيفي والخصوصية والكفاءة.

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

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

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

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

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

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

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

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

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

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

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

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

4. الخلاصة

لقد بدأ للتو استكشاف تقنية BitVM. وفي المستقبل، سيتم استكشاف المزيد من اتجاهات التحسين وممارستها لتحقيق توسع Bitcoin وازدهار نظام Bitcoin البيئي.

المراجع

1. BitVM: حساب أي شيء على Bitcoin

2. BitVM: عقود البيتكوين خارج السلسلة

3. روبن لينوس على BitVM< / span>

4. [bitcoin-dev] BitVM: حساب أي شيء على Bitcoin

   < / li>

5. الزوجان الغريبان: ZK والمجموعات المتفائلة في تاريخ قابلية التوسع

6. < p >ما هي حدود المعاملات والنصوص الخاصة بالبيتكوين؟

7. BIP-342: التحقق من صحة البرامج النصية Taproot

8. https://twitter.com / robin_linus/status/1765337186222686347

دورة الدراسات العليا في التشفير التطبيقي

9. BLAKE3: وظيفة واحدة، سريعة في كل مكان

10. [bitcoin-dev] تنفيذ Blake3 في برنامج Bitcoin النصي

11. https://github.com/BlockstreamResearch/scriptless-scripts

12. مقدمة إلى البرامج النصية بدون نصوص برمجية

13. BitVM باستخدام نصوص برمجية

14. حلول لتأخير الهجمات على مجموعات التحديثات

15. نقدم لك DAVE. نظام Cartesi المقاوم للأخطاء بدون إذن.

16. هجمات التأخير على مجموعات التحديثات

17. حلول لتأخير الهجمات على مجموعات التحديثات - أبحاث Arbitrum

18. ملاحظات حول ألعاب الحوسبة التفاعلية متعددة اللاعبين

19. BoLD: تأخير السيولة المحدود في بروتوكول تحدي التجميع

20. البطولات المُحكمة بدون إذن < /span>