اشرح السبب الحقيقي وراء تخفيف Bitcoin Core v30 لقيود OP_RETURN

المؤلف: آرون تشانغ؛ المصدر: X، @zzmjxy

يعمل Bitcoin Core v30 على تخفيف قيود OP_RETURN. يقول الجميع أن السبب في ذلك هو أن “تقييد نقش الترتيبات غير صالح”.

على مدار الأشهر الثلاثة الماضية، قمت بالتعمق في القائمة البريدية لـ Bitcoin Core v30، والورقة البيضاء لـ Citrea، والوثائق الفنية ذات الصلة.اكتشف الحقيقة التي تجاهلها الجميع: السبب الحقيقي لتغيير سياسة OP_RETURN لم يكن الترتيبي على الإطلاق.إنها BitVM.

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

<ب>خلفية القضية

في أبريل 2024، أصدرت Citrea أول جسر BitVM-Clementine كاملًا.

إنه أول zkRollup على Bitcoin، باستخدام BitVM للتحقق من L1.

ثم واجهوا مشكلة فنية: يلزم نشر 144 بايت من بيانات الإرساء على السلسلة.

<ب>المتطلبات الفنية

تتضمن هذه البايتات الـ 144 ما يلي:

<لي>

128 بايت: إثبات المعرفة الصفرية من Groth16<لي>

16 بايت: إجمالي العمل المتراكم (إجمالي إثبات العمل)

تم استخدام هذه البيانات بواسطة Watchtower لإثبات أن لديهم سلسلة Bitcoin الصحيحة عند استجواب العميل.إليك المشكلة: OP_RETURN يسمح فقط بـ 83 بايت.لا يكفي.

<ب>القيود التقنية الأساسية

قد يتساءل البعض: لماذا لا نشهده؟مثل الترتيبيات؟الفرق الرئيسي: تتطلب معاملات التحقق اللاحقة لـ Citrea قراءة هذه البيانات.

لا يمكن لـ Bitcoin Script الرجوع إلى البيانات الشاهدة للمعاملة السابقة.لذلك **يجب** أن تكون البيانات في موقع scriptPubKey، وهذا ليس اختياريًا.

<ب>المبادئ الفنية

بكل بساطة هو:

بيانات الشاهد:

<لي>

يمكنه فقط إثبات أن “المعاملة الحالية صالحة”✓<لي>

لا يمكن قراءتها من خلال المعاملات اللاحقة ✗

بيانات scriptPubKey:

<لي>

يمكن الرجوع إليها عن طريق البرامج النصية في المعاملات اللاحقة ✓

يتطلب منطق التحقق الخاص بـ BitVM مراجع متسلسلة، لذا يجب استخدام scriptPubKey.

<ب>خطة القسري

لم يكن 83 بايت كافيًا، لذلك اضطرت Citrea إلى استخدام أسلوب رهيب: إنشاء مخرجات Taproot “غير قابلة للإنفاق” والتي تخفي البيانات كمفاتيح عامة.

طرق محددة:

<لي>

الإخراج 0: OP_1 <يتم إخفاء أول 32 بايت كمفتاح عام><لي>

الإخراج 1: OP_1 <32 بايت متخفية كمفتاح عام><لي>

الإخراج 2: OP_RETURN <80 بايت متبقية>

هذه “المفاتيح العامة” ليس لها مفاتيح خاصة مقابلة على الإطلاق.لن يتم إنفاقها أبدًا.

<ب>تحليل المخاطر

مشكلة هذا الحل: تضخيم مجموعة UTXO بشكل دائم.

تنشئ كل معاملة WatchtowerChallenge اثنين من UTXOs لا يمكن تنظيفهما أبدًا.يجب على جميع العقد الكاملة تخزين هذه “المفاتيح العامة المزيفة” بشكل دائم.هذا هو بالضبط السيناريو الأسوأ الذي يحاول مطورو Core تجنبه.

<ب>القائمة البريدية النص الأصلي

كتب أنطوان بوانسوت بوضوح في الاقتراح:

“يستخدم كليمنتين مخرجات Taproot غير القابلة للصرف لتخزين البيانات… بسبب قيود الحجم على OP_RETURN”

تؤدي هذه الحالة **مباشرة** إلى اقتراح تغيير سياسة OP_RETURN.البريد الإلكتروني الأصلي.