BitVM 2: التحقق بدون إذن على البيتكوين

المؤلف: روبن لينوس، دراسة BTC

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

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

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

مقدمة

بالنسبة لبرنامج معين f، نريد التحقق من بعض التأكيدات: إدخال بعض x، سيتم إخراج y، أي f (x) = y. على سبيل المثال، يمكن أن يكون f أداة التحقق من صحة SNARK، مثل نظام إثبات Groth16. ثم x هو جزء من الدليل، وy هي حالة الإخراج التي تثبت صحة SNARK.

في حالة مدقق SNARK، تكون الدرجة أكبر من أن يتم تمثيلها بقطعة من نص Bitcoin. قد يتطلب تنفيذ أداة التحقق من صحة Groth16 نصًا يصل حجمه إلى 20 ميجابايت. ومع ذلك، فإن حجم البرنامج النصي المسموح به محدد بحجم كتلة Bitcoin: 4 ميغابايت. وحتى إذا تم ضغطه إلى هذا الحجم، فقد يظل ضخمًا جدًا.

الحل الساذج

يوفر "توقيع لامبورت" طريقة لتقسيم البرنامج f(x)=y إلى خطوات متعددة. على سبيل المثال، الخطوات: ن = 42.

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

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

الحل المتوازن

يمكننا تقليل البصمة على السلسلة بشكل كبير عن طريق تفريغ بعض الأحمال الثقيلة من جانب المُبرهن إلى جهة التحقق من أجل منع الاحتيال. الآن، يحتاج المُثبِّت فقط إلى الالتزام بـ x وy مرة واحدة، بالإضافة إلى جميع النتائج المتوسطة z1، z2...، z42.

يمكن لأي محقق دحض أي تأكيد كاذب. في مرحلة بدء التشغيل، نقوم بتعريف Taptree، الذي يحتوي على 43 نصًا للتحقق من أي عملية حسابية لـ f1 وf2 وf3 وf43. تأكيد واحد فقط

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

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

يمكن استخدام هذه الآلية باعتبارها حجر الأساس للتحقق من عقود الجسر بدون إذن.

الحل المتفائل

يعمل البروتوكول التالي على تحسين المسار السعيد في التصميم أعلاه (نأمل أن يكون المسار الأكثر شيوعًا)، على حساب إضافة جولتين أخريين من التفاعل في أسوأ الحالات:

1. يعد المُثبِّت بإخراج الحالة y

2. إذا كان غير صحيح، فيمكن لأي شخص بدء جولة من التحديات

3 يعد المُثبِّت بالنتيجة المتوسطة z1, z2,...z42

4. إذا كانت غير صحيحة، يمكن لأي شخص إثبات التأكيد أو نفيه f _i

جسر بدون إذن تصميم العقد

< img src="https://img.jinse.cn/7205819_watermarknone.png" title="7205819" alt="fSJTiPgstO1WN5lSZ5gJUUCPKKO91BfzfxCy6hdC.jpeg">

القيود: رسوم المناولة

في التصميم أعلاه، يمكن للممثل سرقة بعض رسوم المناولة. في هذه الحالة، لا يزال احتياطي رأس المال آمنًا، لكن المدقق سيفقد بعض الأموال المضمونة.

سيناريو الهجوم كالتالي:

• المثل خبيث

• < p>يستخدم الدليل KickOff_Tx الخاص به (لا يحتوي على PegOut_Tx صالح)

• ينتظر المُثبِّت منافسًا لتنفيذ Challenge_TX ويدفع للمُثبِّت الذي ينفذ التحدي< /p>

• الممثل لا ينفذ التحدي ويتوقف ببساطة عن الاستجابة

الصورة المصححة أدناه تحل هذه المشكلة. هناك حاجة إلى معاملتين إضافيتين من نوع n-of-n.

القيود: عامل الصدق

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