Bitcoin هي أصول رقمية لا مركزية وآمنة وجديرة بالثقة. ومع ذلك، فهي تعاني من قيود كبيرة تمنعها من أن تصبح شبكة قابلة للتطوير للمدفوعات والتطبيقات الأخرى. لقد كانت مشكلة توسيع نطاق عملة البيتكوين مصدر قلق منذ بدايتها. يتعامل نموذج Bitcoin UTXO مع كل معاملة كحدث مستقل، مما يؤدي إلى نظام عديم الحالة يفتقر إلى القدرة على إجراء حسابات معقدة تعتمد على الحالة. لذلك، في حين أن Bitcoin يمكن أن تؤدي نصوصًا بسيطة ومعاملات متعددة التوقيع، فإنها تواجه صعوبة في تسهيل تفاعلات العقود المعقدة والديناميكية الشائعة على منصات blockchain الرسمية. تحد هذه المشكلة بشكل كبير من نطاق التطبيقات اللامركزية (dApps) والأدوات المالية المعقدة التي يمكن بناؤها على البيتكوين، في حين توفر المنصات النموذجية الحكومية بيئة أكثر تنوعًا لنشر وتنفيذ العقود الذكية الغنية بالميزات.
بالنسبة لتوسيع Bitcoin، هناك تقنيات مثل القنوات الحكومية والسلاسل الجانبية والتحقق من العميل. ومن بينها، توفر القنوات الحكومية حلول دفع آمنة ومتنوعة، لكنها محدودة في قدرتها على التحقق من الحسابات المعقدة بشكل تعسفي. يقلل هذا القيد من استخدامه في مجموعة متنوعة من السيناريوهات التي تتطلب منطقًا وتفاعلات معقدة ومشروطة. تتمتع Sidechains، على الرغم من دعمها لمجموعة واسعة من التطبيقات وتوفير مجموعة متنوعة من الوظائف خارج Bitcoin، بأمان أقل. ينبع هذا الاختلاف في الأمان من حقيقة أن السلاسل الجانبية تستخدم آليات إجماع مستقلة، وهي أقل قوة بكثير من آلية إجماع البيتكوين. يمكن للتحقق من جانب العميل، باستخدام نموذج Bitcoin UTXO، التعامل مع المعاملات الأكثر تعقيدًا، لكنه لا يتمتع بقدرة قيد المجموع الاختباري ثنائي الاتجاه مع Bitcoin، مما يجعل أمانه أقل من Bitcoin. يعتمد التصميم خارج السلسلة لبروتوكولات التحقق من العميل على الخادم أو البنية التحتية السحابية، مما قد يؤدي إلى المركزية أو الرقابة المحتملة من خلال الخوادم المخترقة. يقدم التصميم خارج السلسلة للتحقق من جانب العميل أيضًا المزيد من التعقيد في البنية التحتية لـ blockchain، مما قد يؤدي إلى مشكلات قابلية التوسع.
في ديسمبر 2023، نشر قائد مشروع ZeroSync، Robin Linus، ورقة بيضاء بعنوان "BitVM: Compute Anything On Bitcoin"، والتي أثارت تفكير الجميع في تحسين قابلية برمجة Bitcoin. تقترح هذه الورقة حل عقد بيتكوين يمكنه تحقيق اكتمال تورينج دون تغيير إجماع شبكة بيتكوين، بحيث يمكن التحقق من أي حساب معقد على بيتكوين دون تغيير القواعد الأساسية للبيتكوين. تستفيد BitVM بشكل كامل من Bitcoin Script وTaproot لتحقيق مجموعة متفائلة. استنادًا إلى توقيع لامبورت (المعروف أيضًا باسم التزام البت)، يتم إنشاء اتصال بين اثنين من Bitcoin UTXOs لتنفيذ نصوص Bitcoin النصية ذات الحالة. من خلال الالتزام ببرنامج كبير في عنوان Taproot، يشارك المشغلون والمدققون في تفاعلات واسعة النطاق خارج السلسلة، مما يؤدي إلى بصمة صغيرة على السلسلة. إذا تعاون الطرفان، يمكن إجراء حسابات خارج السلسلة معقدة بشكل تعسفي دون ترك أي أثر على السلسلة. إذا لم يتعاون الطرفان، فعند حدوث نزاع، يلزم التنفيذ على السلسلة. ونتيجة لذلك، تعمل BitVM على توسيع حالات الاستخدام المحتملة للبيتكوين بشكل كبير، مما يسمح للبيتكوين بالعمل ليس فقط كعملة ولكن أيضًا كمنصة للتحقق لمجموعة متنوعة من التطبيقات اللامركزية ومهام الحوسبة المعقدة.
ومع ذلك، على الرغم من أن تقنية BitVM تتمتع بمزايا كبيرة في توسيع Bitcoin، إلا أنها لا تزال في مراحلها الأولى ولا تزال هناك بعض المشكلات من حيث الكفاءة والأمان. على سبيل المثال: (1) تتطلب التحديات والاستجابات تفاعلات متعددة، مما يؤدي إلى رسوم معالجة باهظة الثمن ودورات تحدي طويلة؛ (2) بيانات توقيع لامبورت لمرة واحدة طويلة ويجب تقليل طول البيانات؛ (3) وظيفة التجزئة هي معقدة وتتطلب دالة تجزئة صديقة للبيتكوين لتقليل التكاليف؛ (4) عقد BitVM الحالي ضخم وقدرة كتلة Bitcoin محدودة. ويمكن استخدام أقل من s لتنفيذ BitVM أقل، مما يوفر مساحة كتلة Bitcoin ويحسن كفاءة BitVM؛ (5) ) يعتمد BitVM الحالي نموذج إذن. يمكن لأعضاء التحالف فقط بدء التحديات، ويقتصر على طرفين فقط. ويجب توسيعه ليشمل نموذج تحدي متعدد الأطراف غير مسموح به لزيادة تقليل افتراض الثقة. ولتحقيق هذه الغاية، تقترح هذه المقالة بعض أفكار التحسين لزيادة تحسين كفاءة وأمان BitVM.
2.مبدأ BitVM
يتم وضع BitVM كعقد خارج السلسلة لـ Bitcoin وهو ملتزم بتعزيز وظائف عقد Bitcoin. في الوقت الحالي، تعد نصوص Bitcoin عديمة الحالة تمامًا، لذلك عند تنفيذ برنامج Bitcoin النصي، تتم إعادة تعيين بيئة التنفيذ الخاصة به بعد كل برنامج نصي. لا توجد طريقة أصلية للنص 1 والنص 2 ليكون لهما نفس قيمة x، ولا يدعم Bitcoin Script هذا محليًا. ومع ذلك، لا يزال بإمكانك استخدام أكواد التشغيل الموجودة لجعل نص Bitcoin صالحًا من خلال توقيع Lamport لمرة واحدة، على سبيل المثال، يمكنك إجبار x في 1 و2 على أن تكون نفس القيمة. يمكن معاقبة المشاركين إذا وقعوا على قيم x متضاربة. تحدث حسابات برنامج BitVM خارج السلسلة، بينما يتم التحقق من نتيجة الحساب على السلسلة. كتلة البيتكوين الحالية لديها حد 1 ميجابايت، وعندما يكون حساب التحقق معقدًا للغاية، يمكن استخدام تقنية OP لتبني وضع الاستجابة للتحدي لدعم التحقق من الحساب الأكثر تعقيدًا.
على غرار Optimistic Rollup واقتراح MATT (Merkelize All The Things)، يعتمد نظام BitVM على بروتوكولات إثبات الاحتيال والاستجابة للتحدي، ولكنه لا يتطلب تعديل قواعد الإجماع الخاصة بالبيتكوين. البدائيات الأساسية لـ BitVM بسيطة، وتعتمد بشكل أساسي على أقفال التجزئة وأقفال الوقت وأشجار Taproot الكبيرة.
ينفذ المُثبِّت بايتًا تلو الآخر، لكن التحقق من جميع العمليات الحسابية على السلسلة سيكون مكلفًا للغاية. لذلك، يقوم المدقق بتنفيذ سلسلة من التحديات المصممة بعناية لدحض ادعاءات المثبت الكاذبة بإيجاز. يقوم المثبتون والمدققون بالتوقيع المسبق بشكل مشترك على سلسلة من معاملات التحدي والاستجابة التي يتم استخدامها لحل النزاعات، مما يسمح بالتحقق الحسابي العالمي على البيتكوين.
المكونات الرئيسية لـ BitVM هي:
التزامات الدائرة: يقوم المثبتون والمتحققون بتجميع البرامج في دوائر ثنائية كبيرة. يلتزم المُثبت بالدائرة في عنوان Taproot، وكل نص ورقي تحت هذا العنوان يتوافق مع كل بوابة منطقية في الدائرة. ويستند جوهر على التزام بت لتنفيذ التزام البوابة المنطقية والتزام الدائرة.
التحدي والاستجابة: يقوم المثبتون والمتحققون بالتوقيع مسبقًا على سلسلة من المعاملات لتنفيذ لعبة التحدي والاستجابة. من الناحية المثالية، يتم إجراء هذا التفاعل خارج السلسلة، ولكن يمكن أيضًا إجراؤه على السلسلة عندما يكون المُثبِّت غير متعاون.
العقوبة الغامضة: إذا أدلى المُثبِّت بأي عبارة غير صحيحة، فيمكن للمُحقِّق سحب إيداع المُثبِّت بعد تحديه بنجاح لإحباط سلوك المُثبِّت الشرير.
3.تحسين BitVM
3.1 تقليل عدد تفاعلات OP بناءً على ZK
يوجد حاليًا مجموعتان رئيسيتان من المجموعات المجمعة: ZK Rollups وOP Rollups. من بينها، تعتمد 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 التوقيع لمرة واحدة الصديق للبيتكوين
في شبكة البيتكوين، تعتبر المعاملات التي تتبع قواعد الإجماع معاملات صالحة، ولكن بالإضافة إلى قواعد الإجماع، يتم أيضًا تقديم قواعد المعيارية. تعمل عقد البيتكوين فقط على توجيه المعاملات القياسية للبث، والطريقة الوحيدة لحزم المعاملات الصالحة ولكن غير القياسية هي مباشرة من خلال العمل مع عمال المناجم.
وفقًا لقواعد الإجماع، يبلغ الحد الأقصى لحجم المعاملات القديمة (غير Segwit) 1 ميجابايت، وهو ما يشغل الكتلة بأكملها. لكن الحد الأقصى للمعايير للمعاملات القديمة هو 100 كيلو بايت. وفقًا لقواعد الإجماع، فإن الحد الأقصى لحجم معاملة Segwit هو 4 ميجابايت، وهو الحد الأقصى للوزن. ومع ذلك، فإن الحد الأقصى لمعايير معاملات Segwit هو 400 كيلو بايت.
يعد توقيع Lamport مكونًا أساسيًا في BitVM، فهو يقلل من طول التوقيع والمفتاح العام، مما يساعد على تقليل بيانات المعاملات وبالتالي تقليل رسوم المعالجة. يتطلب توقيع لامبورت لمرة واحدة استخدام دالة التجزئة (مثل وظيفة التقليب ذات الاتجاه الواحد f). في نظام التوقيع لمرة واحدة الخاص بـ Lamport، يبلغ طول الرسالة v بت، وطول المفتاح العام هو 2 v بت، وطول التوقيع أيضًا 2 v بت. التوقيع والمفتاح العام طويلان ويتطلبان كمية كبيرة من غاز التخزين. ولذلك، هناك حاجة إلى إيجاد مخططات توقيع ذات وظائف مماثلة لتقليل أطوال التوقيع والمفتاح العام. بالمقارنة مع توقيع لامبورت لمرة واحدة، فإن توقيع وينترنيتز لمرة واحدة قد قلل بشكل كبير من طول التوقيع والمفتاح العام، ولكنه يزيد من التعقيد الحسابي للتوقيع والتحقق من التوقيع.
في مخطط توقيع Winternitz لمرة واحدة، يتم استخدام دالة خاصة P لتعيين رسالة v-bit إلى متجه s بطول n. قيمة كل عنصر في s هي {0,..., d}. مخطط توقيع لامبورت لمرة واحدة هو مخطط توقيع وينترنيتز لمرة واحدة في الحالة الخاصة d=1. في مخطط توقيع وينترنيتز لمرة واحدة، فإن العلاقة بين n، d، v ترضي: n≈v/log 2(d+ 1). عندما يكون d= 15، يكون هناك n≈(v/4)+ 1. بالنسبة لتوقيع Winternitz الذي يحتوي على عناصر n، يكون طول المفتاح العام وطول التوقيع أقصر بأربع مرات من نظام التوقيع لمرة واحدة الخاص بـ Lamport. ومع ذلك، فإن تعقيد التحقق من التوقيع يزيد بمقدار 4 مرات. يمكن أن يؤدي استخدام d= 15, v= 160, f=ripemd 160(x) في BitVM لتنفيذ توقيع Winternitz لمرة واحدة إلى تقليل حجم التزام البت بنسبة 50%، وبالتالي تقليل رسوم معاملات BitVM بنسبة 50% على الأقل. في المستقبل، أثناء تحسين تطبيق Winternitz Bitcoin Script الحالي، يمكن استكشاف مخططات توقيع أكثر إحكاما لمرة واحدة يتم التعبير عنها في Bitcoin Script.
3.3 وظائف التجزئة الملائمة للبيتكوين
وفقًا لقواعد الإجماع، فإن الحد الأقصى لحجم P 2 TR هو 10 كيلو بايت، والحد الأقصى لحجم شاهد P 2 TR هو نفس الحد الأقصى لحجم معاملة Segwit، وهو 4 ميجابايت. ومع ذلك، فإن الحد الأعلى لمعيارية الشاهد P 2 TR هو 400 كيلو بايت.
حاليًا، لا تدعم شبكة Bitcoin OP_CAT، ولا يمكن ربط السلاسل للتحقق من مسار Merkle. لذلك، من الضروري استخدام نصوص Bitcoin الحالية لتنفيذ وظيفة تجزئة متوافقة مع Bitcoin بالحجم الأمثل وحجم الشاهد لدعم وظيفة التحقق من إثبات تضمين Merkle.
BLAKE 3 هو نسخة محسنة من وظيفة تجزئة BLAKE 2 ويقدم وضع شجرة Bao. بالمقارنة مع BLAKE 2 s، تم تقليل عدد دورات وظيفة الضغط الخاصة به من 10 إلى 7. ستقوم دالة التجزئة BLAKE 3 بتقسيم مدخلاتها إلى أجزاء متتالية يبلغ حجمها 1024 بايت، وقد تكون القطعة الأخيرة أقصر ولكنها ليست فارغة. عندما يكون هناك قطعة واحدة فقط، تكون القطعة هي العقدة الجذرية والعقدة الوحيدة للشجرة. قم بترتيب هذه القطع كعقد ورقية لشجرة ثنائية، ثم قم بضغط كل قطعة بشكل مستقل.
عند استخدام BitVM للتحقق من سيناريو إثبات تضمين Merkle، يتكون إدخال عملية التجزئة من قيمتي تجزئة 256 بت، أي أن إدخال عملية التجزئة هو 64 بايت. عند استخدام وظيفة تجزئة BLAKE 3، يمكن تخصيص هذه البايتات البالغ عددها 64 بايت داخل قطعة واحدة، وتحتاج عملية تجزئة BLAKE 3 بأكملها فقط إلى تطبيق وظيفة الضغط مرة واحدة على القطعة المفردة. في وظيفة الضغط لـ BLAKE 3، من الضروري تشغيل الدالة الدائرية 7 مرات ووظيفة التقليب 6 مرات.
في الوقت الحاضر، تم إكمال العمليات الأساسية مثل XOR والإضافة المعيارية والتحول الصحيح للبت استنادًا إلى قيم u 32 في BitVM، ويمكن تجميع وظيفة تجزئة BLAKE 3 التي ينفذها برنامج Bitcoin النصي بسهولة. استخدم 4 بايتات منفصلة في المكدس لتمثيل u 32 كلمة لتنفيذ إضافة u 32، وu 32 بت XOR وu 32 دورات بت مطلوبة بواسطة BLAKE 3. يبلغ إجمالي نص Bitcoin النصي الحالي لوظيفة تجزئة BLAKE 3 حوالي 100 كيلو بايت، وهو ما يكفي لإنشاء نسخة لعبة من BitVM.
بالإضافة إلى ذلك، يمكن تقسيم رموز BLAKE 3 هذه، مما يسمح لـ Verifier وProver بتقليل البيانات الموجودة على السلسلة المطلوبة بشكل كبير عن طريق تقسيم التنفيذ في لعبة الاستجابة للتحدي إلى النصف بدلاً من تنفيذها بالكامل. أخيرًا، استخدم برنامج Bitcoin النصي لتنفيذ وظائف التجزئة مثل Keccak-256 وGrøstl، وحدد وظيفة التجزئة الأكثر ملائمة للبيتكوين، واستكشف وظائف التجزئة الجديدة الأخرى الملائمة للبيتكوين.
3.4 أقل من BitVM
أقل s هي طريقة لتنفيذ العقود الذكية خارج السلسلة باستخدام توقيعات شنور. مفهوم Scripless ولد من Mimblewimble، الذي لا يقوم بتخزين البيانات الدائمة باستثناء النواة وتوقيعها.
مزايا الأقل هي الوظيفة والخصوصية والكفاءة.
**الميزات: **أقل من ذلك يمكن أن يزيد من نطاق وتعقيد العقود الذكية. قدرات البرمجة النصية للبيتكوين محدودة بعدد OP_CODES الممكنة في الشبكة، وأقل من ذلك ينقل مواصفات وتنفيذ العقود الذكية من السلسلة إلى المناقشات فقط بين المشاركين في عقد التصميم، دون انتظار شوكة شبكة البيتكوين لتمكينها رمز التشغيل الجديد.
الخصوصية: يؤدي نقل مواصفات العقود الذكية وتنفيذها من السلسلة إلى خارج السلسلة إلى زيادة الخصوصية. في السلسلة، سيتم مشاركة العديد من تفاصيل العقد مع الشبكة بأكملها، وتشمل هذه التفاصيل عدد المشاركين وعناوينهم ومبلغ التحويل. من خلال نقل العقود الذكية خارج السلسلة، تعرف الشبكة فقط أن المشاركين يوافقون على استيفاء شروط عقودهم وأن المعاملات الأساسية صالحة.
** الكفاءة: ** أقل يقلل من كمية البيانات التي تم التحقق منها وتخزينها على السلسلة. من خلال نقل العقود الذكية خارج السلسلة، سيتم تخفيض رسوم الإدارة للعقد الكاملة كما سيتم تخفيض رسوم المعاملات للمستخدمين.
less s هو أسلوب لتصميم بروتوكولات التشفير على البيتكوين والذي يتجنب الحاجة إلى تنفيذ عقود ذكية صريحة. الفكرة الأساسية هي استخدام خوارزميات التشفير لتحقيق الوظيفة المطلوبة بدلاً من استخدام البرامج النصية لتحقيق الوظيفة. تعد توقيعات المحول والتوقيعات المتعددة بمثابة اللبنات الأساسية الأصلية لأقل من s. باستخدام عدد أقل من المعاملات، يمكنك تحقيق معاملات أصغر من المعاملات العادية وتقليل رسوم المعاملات.
بمساعدة أقل s، يمكن استخدام التوقيع المتعدد Schnorr وتوقيع المحول، والذي لم يعد يوفر قيم التجزئة والصور الأولية للتجزئة مثل حل BitVM، ويمكنه أيضًا تحقيق التزام البوابة المنطقية في دائرة BitVM، وبالتالي حفظ BitVM مساحة البرنامج النصي وتحسين كفاءة BitVM. على الرغم من أن مخطط أقل s الموجود يمكن أن يقلل مساحة البرنامج النصي لـ BitVM، إلا أنه يتطلب قدرًا كبيرًا من التفاعل بين المُثبِّت والمنافس لدمج المفتاح العام. في المستقبل، سوف نقوم بتحسين هذا الحل ومحاولة تقديم Scripless s إلى وحدات وظيفية محددة في BitVM.
3.5 تحدي تعدد الأحزاب بدون إذن
السبب وراء أن تحديات BitVM الحالية تتطلب إذنًا افتراضيًا هو أن UTXO الخاص بـ Bitcoin لا يمكن تنفيذه إلا مرة واحدة، مما يسمح للمدقق الخبيث "بإضاعة" العقد من خلال تحدي مُثبِّت نزيه. يقتصر BitVM حاليًا على وضع التحدي ثنائي الأطراف. يمكن للمُثبِّت الذي يحاول فعل الشر أن يطلق تحديًا في نفس الوقت مع المُحقق الذي يتحكم فيه، وبالتالي "إضاعة" العقد، مما يجعل الفعل الشرير ناجحًا، ولا يستطيع المتحققون الآخرون منع السلوك. لذلك، استنادًا إلى Bitcoin، يجب دراسة بروتوكول تحدي OP متعدد الأطراف غير المسموح به، والذي يمكنه توسيع نموذج الثقة الحالي الخاص بـ BitVM 1 of-n إلى 1-of-N. ومن بينها، N أكبر بكثير من n. وبالإضافة إلى ذلك، هناك حاجة إلى دراسة وحل مشكلة تواطؤ المتنافسين مع المثبتين أو الطعن بشكل خبيث في العقود "المهدورة". في النهاية تنفيذ بروتوكول BitVM بثقة أقل.
تحديات متعددة الأطراف بدون إذن، مما يسمح لأي شخص بالمشاركة بدون قائمة أذونات. وهذا يعني أنه يمكن للمستخدمين سحب العملات المعدنية من L2 دون مشاركة أي طرف ثالث موثوق به. بالإضافة إلى ذلك، يمكن لأي مستخدم يرغب في المشاركة في بروتوكول تحدي OP تحدي عمليات السحب غير الصالحة وحذفها.
يتطلب توسيع BitVM إلى نموذج تحدي متعدد الأطراف غير المسموح به حل الهجمات التالية:
هجوم Sybil: حتى إذا قام أحد المهاجمين بتزوير هويات متعددة للمشاركة في تحدي النزاع، فلا يزال بإمكان طرف واحد نزيه الفوز في النزاع. إذا كانت تكلفة الدفاع عن النتيجة الصحيحة لطرف نزيه مرتبطة خطيًا بعدد المهاجمين، فعندما يشارك عدد كبير من المهاجمين، تصبح تكلفة الفوز في النزاع غير واقعية وعرضة لهجوم الساحرات. في بحث البطولات التحكيمية غير المسموح بها، تم اقتراح خوارزمية لحل النزاعات لتغيير قواعد اللعبة. وتزداد تكلفة فوز مشارك نزيه واحد في النزاع لوغاريتميًا مع عدد المعارضين، وليس خطيًا.
هجوم التأخير: يتبع طرف خبيث أو مجموعة من الأطراف الخبيثة استراتيجية معينة لمنع أو تأخير تأكيد النتائج الصحيحة (مثل سحب الأصول إلى المستوى 1) على المستوى 1، وإجبار المُثبتين الصادقين على إنفاق رسوم المستوى 1. يمكن التخفيف من هذه المشكلة من خلال مطالبة المنافسين بالمشاركة مقدمًا. إذا شن المنافس هجومًا متأخرًا، فسيتم مصادرة حصته. ومع ذلك، إذا كان المهاجم على استعداد للتضحية بالتحصيل ضمن حدود معينة لمتابعة هجوم التأخير، فيجب أن تكون هناك إجراءات مضادة لتقليل تأثير هجوم التأخير. الخوارزمية المقترحة في ورقة BoLD: تأخير السيولة المحدود في بروتوكول تحدي التجميع تمكن الهجوم الأسوأ من التسبب فقط في حد أعلى معين من التأخير، بغض النظر عن مقدار التعهد الذي يرغب المهاجم في خسارته.
في المستقبل، سنستكشف نموذج التحدي متعدد الأطراف غير المسموح به من BitVM والذي يناسب خصائص Bitcoin ويمكنه مقاومة مشاكل الهجوم المذكورة أعلاه.
4. الخلاصة
لقد بدأ للتو استكشاف تقنية BitVM. وفي المستقبل، سيتم استكشاف وتنفيذ المزيد من اتجاهات التحسين لتحقيق توسع Bitcoin وازدهار نظام Bitcoin البيئي.
مراجع
BitVM: حساب أي شيء على البيتكوين
BitVM: عقود البيتكوين خارج السلسلة
روبن لينوس على BitVM
[bitcoin-dev] BitVM: حساب أي شيء على البيتكوين
الثنائي الغريب: ZK والمجموعات المتفائلة في تاريخ قابلية التوسع
ما هي معاملات البيتكوين وحدودها؟
7.BIP-342: التحقق من صحة Taproot s
_linus/status/1765337186222686347
دورة الدراسات العليا في التشفير التطبيقي
BLAKE 3: وظيفة واحدة، سريعة في كل مكان
[bitcoin-dev] تنفيذ Blake 3 في البيتكوين
مقدمة لأقل ق
BitVM باستخدام عدد أقل من الملفات
حلول لتأخير الهجمات على مجموعات التحديثات
تقديم ديف. Cartesi's Permissionless Fault-Proof .
تأخير الهجمات على عمليات التجميع
حلول لتأخير الهجمات على مجموعات التحديثات - Arbitrum Research
ملاحظات ألعاب الحساب التفاعلية متعددة اللاعبين
BOLD: تأخير السيولة المحدود في بروتوكول التحدي التراكمي
البطولات التحكيمية غير المسموح بها
الرابط الأصلي
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
تحليل مبدأ BitVM واعتبارات التحسين
المصدر الأصلي: مجموعة أبحاث Bitlayer
المؤلف الأصلي: ليندل، موتوريند.
1 المقدمة
Bitcoin هي أصول رقمية لا مركزية وآمنة وجديرة بالثقة. ومع ذلك، فهي تعاني من قيود كبيرة تمنعها من أن تصبح شبكة قابلة للتطوير للمدفوعات والتطبيقات الأخرى. لقد كانت مشكلة توسيع نطاق عملة البيتكوين مصدر قلق منذ بدايتها. يتعامل نموذج Bitcoin UTXO مع كل معاملة كحدث مستقل، مما يؤدي إلى نظام عديم الحالة يفتقر إلى القدرة على إجراء حسابات معقدة تعتمد على الحالة. لذلك، في حين أن Bitcoin يمكن أن تؤدي نصوصًا بسيطة ومعاملات متعددة التوقيع، فإنها تواجه صعوبة في تسهيل تفاعلات العقود المعقدة والديناميكية الشائعة على منصات blockchain الرسمية. تحد هذه المشكلة بشكل كبير من نطاق التطبيقات اللامركزية (dApps) والأدوات المالية المعقدة التي يمكن بناؤها على البيتكوين، في حين توفر المنصات النموذجية الحكومية بيئة أكثر تنوعًا لنشر وتنفيذ العقود الذكية الغنية بالميزات.
بالنسبة لتوسيع Bitcoin، هناك تقنيات مثل القنوات الحكومية والسلاسل الجانبية والتحقق من العميل. ومن بينها، توفر القنوات الحكومية حلول دفع آمنة ومتنوعة، لكنها محدودة في قدرتها على التحقق من الحسابات المعقدة بشكل تعسفي. يقلل هذا القيد من استخدامه في مجموعة متنوعة من السيناريوهات التي تتطلب منطقًا وتفاعلات معقدة ومشروطة. تتمتع Sidechains، على الرغم من دعمها لمجموعة واسعة من التطبيقات وتوفير مجموعة متنوعة من الوظائف خارج Bitcoin، بأمان أقل. ينبع هذا الاختلاف في الأمان من حقيقة أن السلاسل الجانبية تستخدم آليات إجماع مستقلة، وهي أقل قوة بكثير من آلية إجماع البيتكوين. يمكن للتحقق من جانب العميل، باستخدام نموذج Bitcoin UTXO، التعامل مع المعاملات الأكثر تعقيدًا، لكنه لا يتمتع بقدرة قيد المجموع الاختباري ثنائي الاتجاه مع Bitcoin، مما يجعل أمانه أقل من Bitcoin. يعتمد التصميم خارج السلسلة لبروتوكولات التحقق من العميل على الخادم أو البنية التحتية السحابية، مما قد يؤدي إلى المركزية أو الرقابة المحتملة من خلال الخوادم المخترقة. يقدم التصميم خارج السلسلة للتحقق من جانب العميل أيضًا المزيد من التعقيد في البنية التحتية لـ blockchain، مما قد يؤدي إلى مشكلات قابلية التوسع.
في ديسمبر 2023، نشر قائد مشروع ZeroSync، Robin Linus، ورقة بيضاء بعنوان "BitVM: Compute Anything On Bitcoin"، والتي أثارت تفكير الجميع في تحسين قابلية برمجة Bitcoin. تقترح هذه الورقة حل عقد بيتكوين يمكنه تحقيق اكتمال تورينج دون تغيير إجماع شبكة بيتكوين، بحيث يمكن التحقق من أي حساب معقد على بيتكوين دون تغيير القواعد الأساسية للبيتكوين. تستفيد BitVM بشكل كامل من Bitcoin Script وTaproot لتحقيق مجموعة متفائلة. استنادًا إلى توقيع لامبورت (المعروف أيضًا باسم التزام البت)، يتم إنشاء اتصال بين اثنين من Bitcoin UTXOs لتنفيذ نصوص Bitcoin النصية ذات الحالة. من خلال الالتزام ببرنامج كبير في عنوان Taproot، يشارك المشغلون والمدققون في تفاعلات واسعة النطاق خارج السلسلة، مما يؤدي إلى بصمة صغيرة على السلسلة. إذا تعاون الطرفان، يمكن إجراء حسابات خارج السلسلة معقدة بشكل تعسفي دون ترك أي أثر على السلسلة. إذا لم يتعاون الطرفان، فعند حدوث نزاع، يلزم التنفيذ على السلسلة. ونتيجة لذلك، تعمل BitVM على توسيع حالات الاستخدام المحتملة للبيتكوين بشكل كبير، مما يسمح للبيتكوين بالعمل ليس فقط كعملة ولكن أيضًا كمنصة للتحقق لمجموعة متنوعة من التطبيقات اللامركزية ومهام الحوسبة المعقدة.
ومع ذلك، على الرغم من أن تقنية BitVM تتمتع بمزايا كبيرة في توسيع Bitcoin، إلا أنها لا تزال في مراحلها الأولى ولا تزال هناك بعض المشكلات من حيث الكفاءة والأمان. على سبيل المثال: (1) تتطلب التحديات والاستجابات تفاعلات متعددة، مما يؤدي إلى رسوم معالجة باهظة الثمن ودورات تحدي طويلة؛ (2) بيانات توقيع لامبورت لمرة واحدة طويلة ويجب تقليل طول البيانات؛ (3) وظيفة التجزئة هي معقدة وتتطلب دالة تجزئة صديقة للبيتكوين لتقليل التكاليف؛ (4) عقد BitVM الحالي ضخم وقدرة كتلة Bitcoin محدودة. ويمكن استخدام أقل من s لتنفيذ BitVM أقل، مما يوفر مساحة كتلة Bitcoin ويحسن كفاءة BitVM؛ (5) ) يعتمد BitVM الحالي نموذج إذن. يمكن لأعضاء التحالف فقط بدء التحديات، ويقتصر على طرفين فقط. ويجب توسيعه ليشمل نموذج تحدي متعدد الأطراف غير مسموح به لزيادة تقليل افتراض الثقة. ولتحقيق هذه الغاية، تقترح هذه المقالة بعض أفكار التحسين لزيادة تحسين كفاءة وأمان BitVM.
2.مبدأ BitVM
يتم وضع BitVM كعقد خارج السلسلة لـ Bitcoin وهو ملتزم بتعزيز وظائف عقد Bitcoin. في الوقت الحالي، تعد نصوص Bitcoin عديمة الحالة تمامًا، لذلك عند تنفيذ برنامج Bitcoin النصي، تتم إعادة تعيين بيئة التنفيذ الخاصة به بعد كل برنامج نصي. لا توجد طريقة أصلية للنص 1 والنص 2 ليكون لهما نفس قيمة x، ولا يدعم Bitcoin Script هذا محليًا. ومع ذلك، لا يزال بإمكانك استخدام أكواد التشغيل الموجودة لجعل نص Bitcoin صالحًا من خلال توقيع Lamport لمرة واحدة، على سبيل المثال، يمكنك إجبار x في 1 و2 على أن تكون نفس القيمة. يمكن معاقبة المشاركين إذا وقعوا على قيم x متضاربة. تحدث حسابات برنامج BitVM خارج السلسلة، بينما يتم التحقق من نتيجة الحساب على السلسلة. كتلة البيتكوين الحالية لديها حد 1 ميجابايت، وعندما يكون حساب التحقق معقدًا للغاية، يمكن استخدام تقنية OP لتبني وضع الاستجابة للتحدي لدعم التحقق من الحساب الأكثر تعقيدًا.
على غرار Optimistic Rollup واقتراح MATT (Merkelize All The Things)، يعتمد نظام BitVM على بروتوكولات إثبات الاحتيال والاستجابة للتحدي، ولكنه لا يتطلب تعديل قواعد الإجماع الخاصة بالبيتكوين. البدائيات الأساسية لـ BitVM بسيطة، وتعتمد بشكل أساسي على أقفال التجزئة وأقفال الوقت وأشجار Taproot الكبيرة.
ينفذ المُثبِّت بايتًا تلو الآخر، لكن التحقق من جميع العمليات الحسابية على السلسلة سيكون مكلفًا للغاية. لذلك، يقوم المدقق بتنفيذ سلسلة من التحديات المصممة بعناية لدحض ادعاءات المثبت الكاذبة بإيجاز. يقوم المثبتون والمدققون بالتوقيع المسبق بشكل مشترك على سلسلة من معاملات التحدي والاستجابة التي يتم استخدامها لحل النزاعات، مما يسمح بالتحقق الحسابي العالمي على البيتكوين.
المكونات الرئيسية لـ BitVM هي:
3.تحسين BitVM
3.1 تقليل عدد تفاعلات OP بناءً على ZK
يوجد حاليًا مجموعتان رئيسيتان من المجموعات المجمعة: ZK Rollups وOP Rollups. من بينها، تعتمد 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 التوقيع لمرة واحدة الصديق للبيتكوين
في شبكة البيتكوين، تعتبر المعاملات التي تتبع قواعد الإجماع معاملات صالحة، ولكن بالإضافة إلى قواعد الإجماع، يتم أيضًا تقديم قواعد المعيارية. تعمل عقد البيتكوين فقط على توجيه المعاملات القياسية للبث، والطريقة الوحيدة لحزم المعاملات الصالحة ولكن غير القياسية هي مباشرة من خلال العمل مع عمال المناجم.
وفقًا لقواعد الإجماع، يبلغ الحد الأقصى لحجم المعاملات القديمة (غير Segwit) 1 ميجابايت، وهو ما يشغل الكتلة بأكملها. لكن الحد الأقصى للمعايير للمعاملات القديمة هو 100 كيلو بايت. وفقًا لقواعد الإجماع، فإن الحد الأقصى لحجم معاملة Segwit هو 4 ميجابايت، وهو الحد الأقصى للوزن. ومع ذلك، فإن الحد الأقصى لمعايير معاملات Segwit هو 400 كيلو بايت.
يعد توقيع Lamport مكونًا أساسيًا في BitVM، فهو يقلل من طول التوقيع والمفتاح العام، مما يساعد على تقليل بيانات المعاملات وبالتالي تقليل رسوم المعالجة. يتطلب توقيع لامبورت لمرة واحدة استخدام دالة التجزئة (مثل وظيفة التقليب ذات الاتجاه الواحد f). في نظام التوقيع لمرة واحدة الخاص بـ Lamport، يبلغ طول الرسالة v بت، وطول المفتاح العام هو 2 v بت، وطول التوقيع أيضًا 2 v بت. التوقيع والمفتاح العام طويلان ويتطلبان كمية كبيرة من غاز التخزين. ولذلك، هناك حاجة إلى إيجاد مخططات توقيع ذات وظائف مماثلة لتقليل أطوال التوقيع والمفتاح العام. بالمقارنة مع توقيع لامبورت لمرة واحدة، فإن توقيع وينترنيتز لمرة واحدة قد قلل بشكل كبير من طول التوقيع والمفتاح العام، ولكنه يزيد من التعقيد الحسابي للتوقيع والتحقق من التوقيع.
في مخطط توقيع Winternitz لمرة واحدة، يتم استخدام دالة خاصة P لتعيين رسالة v-bit إلى متجه s بطول n. قيمة كل عنصر في s هي {0,..., d}. مخطط توقيع لامبورت لمرة واحدة هو مخطط توقيع وينترنيتز لمرة واحدة في الحالة الخاصة d=1. في مخطط توقيع وينترنيتز لمرة واحدة، فإن العلاقة بين n، d، v ترضي: n≈v/log 2(d+ 1). عندما يكون d= 15، يكون هناك n≈(v/4)+ 1. بالنسبة لتوقيع Winternitz الذي يحتوي على عناصر n، يكون طول المفتاح العام وطول التوقيع أقصر بأربع مرات من نظام التوقيع لمرة واحدة الخاص بـ Lamport. ومع ذلك، فإن تعقيد التحقق من التوقيع يزيد بمقدار 4 مرات. يمكن أن يؤدي استخدام d= 15, v= 160, f=ripemd 160(x) في BitVM لتنفيذ توقيع Winternitz لمرة واحدة إلى تقليل حجم التزام البت بنسبة 50%، وبالتالي تقليل رسوم معاملات BitVM بنسبة 50% على الأقل. في المستقبل، أثناء تحسين تطبيق Winternitz Bitcoin Script الحالي، يمكن استكشاف مخططات توقيع أكثر إحكاما لمرة واحدة يتم التعبير عنها في Bitcoin Script.
3.3 وظائف التجزئة الملائمة للبيتكوين
وفقًا لقواعد الإجماع، فإن الحد الأقصى لحجم P 2 TR هو 10 كيلو بايت، والحد الأقصى لحجم شاهد P 2 TR هو نفس الحد الأقصى لحجم معاملة Segwit، وهو 4 ميجابايت. ومع ذلك، فإن الحد الأعلى لمعيارية الشاهد P 2 TR هو 400 كيلو بايت.
حاليًا، لا تدعم شبكة Bitcoin OP_CAT، ولا يمكن ربط السلاسل للتحقق من مسار Merkle. لذلك، من الضروري استخدام نصوص Bitcoin الحالية لتنفيذ وظيفة تجزئة متوافقة مع Bitcoin بالحجم الأمثل وحجم الشاهد لدعم وظيفة التحقق من إثبات تضمين Merkle.
BLAKE 3 هو نسخة محسنة من وظيفة تجزئة BLAKE 2 ويقدم وضع شجرة Bao. بالمقارنة مع BLAKE 2 s، تم تقليل عدد دورات وظيفة الضغط الخاصة به من 10 إلى 7. ستقوم دالة التجزئة BLAKE 3 بتقسيم مدخلاتها إلى أجزاء متتالية يبلغ حجمها 1024 بايت، وقد تكون القطعة الأخيرة أقصر ولكنها ليست فارغة. عندما يكون هناك قطعة واحدة فقط، تكون القطعة هي العقدة الجذرية والعقدة الوحيدة للشجرة. قم بترتيب هذه القطع كعقد ورقية لشجرة ثنائية، ثم قم بضغط كل قطعة بشكل مستقل.
عند استخدام BitVM للتحقق من سيناريو إثبات تضمين Merkle، يتكون إدخال عملية التجزئة من قيمتي تجزئة 256 بت، أي أن إدخال عملية التجزئة هو 64 بايت. عند استخدام وظيفة تجزئة BLAKE 3، يمكن تخصيص هذه البايتات البالغ عددها 64 بايت داخل قطعة واحدة، وتحتاج عملية تجزئة BLAKE 3 بأكملها فقط إلى تطبيق وظيفة الضغط مرة واحدة على القطعة المفردة. في وظيفة الضغط لـ BLAKE 3، من الضروري تشغيل الدالة الدائرية 7 مرات ووظيفة التقليب 6 مرات.
في الوقت الحاضر، تم إكمال العمليات الأساسية مثل XOR والإضافة المعيارية والتحول الصحيح للبت استنادًا إلى قيم u 32 في BitVM، ويمكن تجميع وظيفة تجزئة BLAKE 3 التي ينفذها برنامج Bitcoin النصي بسهولة. استخدم 4 بايتات منفصلة في المكدس لتمثيل u 32 كلمة لتنفيذ إضافة u 32، وu 32 بت XOR وu 32 دورات بت مطلوبة بواسطة BLAKE 3. يبلغ إجمالي نص Bitcoin النصي الحالي لوظيفة تجزئة BLAKE 3 حوالي 100 كيلو بايت، وهو ما يكفي لإنشاء نسخة لعبة من BitVM.
بالإضافة إلى ذلك، يمكن تقسيم رموز BLAKE 3 هذه، مما يسمح لـ Verifier وProver بتقليل البيانات الموجودة على السلسلة المطلوبة بشكل كبير عن طريق تقسيم التنفيذ في لعبة الاستجابة للتحدي إلى النصف بدلاً من تنفيذها بالكامل. أخيرًا، استخدم برنامج Bitcoin النصي لتنفيذ وظائف التجزئة مثل Keccak-256 وGrøstl، وحدد وظيفة التجزئة الأكثر ملائمة للبيتكوين، واستكشف وظائف التجزئة الجديدة الأخرى الملائمة للبيتكوين.
3.4 أقل من BitVM
أقل s هي طريقة لتنفيذ العقود الذكية خارج السلسلة باستخدام توقيعات شنور. مفهوم Scripless ولد من Mimblewimble، الذي لا يقوم بتخزين البيانات الدائمة باستثناء النواة وتوقيعها.
مزايا الأقل هي الوظيفة والخصوصية والكفاءة.
less s هو أسلوب لتصميم بروتوكولات التشفير على البيتكوين والذي يتجنب الحاجة إلى تنفيذ عقود ذكية صريحة. الفكرة الأساسية هي استخدام خوارزميات التشفير لتحقيق الوظيفة المطلوبة بدلاً من استخدام البرامج النصية لتحقيق الوظيفة. تعد توقيعات المحول والتوقيعات المتعددة بمثابة اللبنات الأساسية الأصلية لأقل من s. باستخدام عدد أقل من المعاملات، يمكنك تحقيق معاملات أصغر من المعاملات العادية وتقليل رسوم المعاملات.
بمساعدة أقل s، يمكن استخدام التوقيع المتعدد Schnorr وتوقيع المحول، والذي لم يعد يوفر قيم التجزئة والصور الأولية للتجزئة مثل حل BitVM، ويمكنه أيضًا تحقيق التزام البوابة المنطقية في دائرة BitVM، وبالتالي حفظ BitVM مساحة البرنامج النصي وتحسين كفاءة BitVM. على الرغم من أن مخطط أقل s الموجود يمكن أن يقلل مساحة البرنامج النصي لـ BitVM، إلا أنه يتطلب قدرًا كبيرًا من التفاعل بين المُثبِّت والمنافس لدمج المفتاح العام. في المستقبل، سوف نقوم بتحسين هذا الحل ومحاولة تقديم Scripless s إلى وحدات وظيفية محددة في BitVM.
3.5 تحدي تعدد الأحزاب بدون إذن
السبب وراء أن تحديات BitVM الحالية تتطلب إذنًا افتراضيًا هو أن UTXO الخاص بـ Bitcoin لا يمكن تنفيذه إلا مرة واحدة، مما يسمح للمدقق الخبيث "بإضاعة" العقد من خلال تحدي مُثبِّت نزيه. يقتصر BitVM حاليًا على وضع التحدي ثنائي الأطراف. يمكن للمُثبِّت الذي يحاول فعل الشر أن يطلق تحديًا في نفس الوقت مع المُحقق الذي يتحكم فيه، وبالتالي "إضاعة" العقد، مما يجعل الفعل الشرير ناجحًا، ولا يستطيع المتحققون الآخرون منع السلوك. لذلك، استنادًا إلى Bitcoin، يجب دراسة بروتوكول تحدي OP متعدد الأطراف غير المسموح به، والذي يمكنه توسيع نموذج الثقة الحالي الخاص بـ BitVM 1 of-n إلى 1-of-N. ومن بينها، N أكبر بكثير من n. وبالإضافة إلى ذلك، هناك حاجة إلى دراسة وحل مشكلة تواطؤ المتنافسين مع المثبتين أو الطعن بشكل خبيث في العقود "المهدورة". في النهاية تنفيذ بروتوكول BitVM بثقة أقل.
تحديات متعددة الأطراف بدون إذن، مما يسمح لأي شخص بالمشاركة بدون قائمة أذونات. وهذا يعني أنه يمكن للمستخدمين سحب العملات المعدنية من L2 دون مشاركة أي طرف ثالث موثوق به. بالإضافة إلى ذلك، يمكن لأي مستخدم يرغب في المشاركة في بروتوكول تحدي OP تحدي عمليات السحب غير الصالحة وحذفها.
يتطلب توسيع BitVM إلى نموذج تحدي متعدد الأطراف غير المسموح به حل الهجمات التالية:
في المستقبل، سنستكشف نموذج التحدي متعدد الأطراف غير المسموح به من BitVM والذي يناسب خصائص Bitcoin ويمكنه مقاومة مشاكل الهجوم المذكورة أعلاه.
4. الخلاصة
لقد بدأ للتو استكشاف تقنية BitVM. وفي المستقبل، سيتم استكشاف وتنفيذ المزيد من اتجاهات التحسين لتحقيق توسع Bitcoin وازدهار نظام Bitcoin البيئي.
مراجع
الرابط الأصلي