1 مقدمة

بالنسبة لخوارزمية f ، يمكن لأليس وبوب ، المشاركين اللذين يشكلون عدم الثقة المتبادلة ، إقامة الثقة بالطرق التالية:

1. تدخل أليس x، تشغل خوارزمية f، وتحصل على النتيجة y. بوب يشغل أيضًا خوارزمية f بنفس الإدخال x، مما يؤدي إلى y′. إذا كانت y = y′، فإن بوب يعترف بإدخال أليس المقدم x والإخراج y. هذه آلية إثبات صحة خاصة تستخدم عادة في اتفاقية سلسلة الكتل، حيث أليس هو العقدة التي تقوم بتجميع الكتلة وبوب هو العقدة التي تشارك في الاتفاق.
2. أليس تدخل x ، تشغل برنامج zk.prove على الخوارزمية f ، وتحصل على النتيجة y ودليل الإثبات. يقوم بوب بتشغيل برنامج zk.verify بناءً على f و y ودليل الإثبات. إذا كانت النتيجة صحيحة ، فإن بوب يعترف بنتيجة أليس y ؛ إذا كانت النتيجة خاطئة ، فإن بوب لا يعترف بنتيجة أليس y. هذا هو إثبات الصحة ، حيث يمكن لبوب أن يكون عقدًا على السلسلة.
3. تقوم أليس بإدخال x ، وتشغيل الخوارزمية f ، والحصول على النتيجة y. يقوم بوب أيضا بتشغيل الخوارزمية f بنفس الإدخال x، مما ينتج عنه y′. إذا كانت y = y ′ ، فلن يتم فعل أي شيء ؛ إذا كانت y ≠ y′ ، فإن بوب يتحدى أليس ، مع كون البرنامج الذي تم تحديه هو f. يمكن أن يكون عدد التفاعلات بين أليس وبوب واحدا أو متعددا. يتم تحقيق التحكيم من خلال عملية الاستجابة للطعن. هذا دليل على الاحتيال ، حيث يكون بوب هو المنافس ، ويستمع خارج السلسلة ويتحدى على السلسلة.
4. أليس تدخل x، تشغل برنامج zk.prove على خوارزمية f، وتحصل على النتيجة y ودليل الإثبات. بوب يشغل برنامج zk.verify استنادًا إلى f، y، ودليل الإثبات. إذا كانت النتيجة صحيحة، فلن يتم فعل شيء. إذا كانت النتيجة غير صحيحة، فإن بوب يتحدى أليس، ويكون البرنامج المتحدى zk.verify. يمكن أن يكون عدد التفاعلات بين أليس وبوب واحدًا أو متعددًا. يتم تحقيق التحكيم من خلال عملية التحدي والاستجابة. هذا دليل على الاحتيال، حيث يكون بوب المتحدي، مستمعًا خارج السلسلة الرئيسية ويتحدى داخلها.

بالنسبة للأعداد 2 و 3 و 4 أعلاه، دع x يكون معاملات طبقة 2 والحالة الأولية، ودع f يكون برنامج الاتفاق للطبقة 2 ودع y يكون الحالة النهائية للمعاملة، وذلك يتوافق مع حل توسيع سلسلة الكتل طبقة 2. من بينها:

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

الجدول 1: طرق لإقامة الثقة

بالإضافة إلى ذلك، من المهم أن نلاحظ:

• المفتاح للتمييز بين أدلة الاحتيال وأدلة الصحة ليس ما إذا كانت أنظمة الإثبات ذات الصفر المعرفة مثل SNARK/STARK مستخدمة. نظام الإثبات ذو الصفر يعبر عن طريقة الإثبات المستخدمة، بينما الاحتيال أو الصحة يمثل المحتوى الذي يتم إثباته. وهذا هو السبب في أن يُقال إن سيناريو 1 في الجدول 1 يمثل إثبات صحة.
• إثبات صحة لديها دقة أفضل، ولكن تعقيد التحقق على السلسلة نسبياً عالي؛ أما دلائل الاحتيال فلديها تعقيد أقل في التحقق على السلسلة، لكن دقتها نسبياً منخفضة.
• بالنسبة للحالتين 2 و 4 في الجدول 1، يمكن باستخدام تقنيات الركون ZK والجمع، حساب العديد من f وضغطها، مما يقلل بشكل كبير من تكلفة التحقق من الحساب خارج السلسلة على السلسلة.

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

2 القيود والاختراقات تحت نموذج بيتكوين

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

2.1 نموذج UTXO وقيود البرنامج النصي

يعتمد بيتكوين نموذج UTXO، حيث يتم قفل كل UTXO في سكريبت قفل يحدد الشروط التي يجب تحقيقها لإنفاق تلك UTXO. تتمتع سكريبتات بيتكوين بالقيود التالية:

1. بيتكوين النصوص لا تحتفظ بالحالة؛
2. بالنسبة لأنواع إخراج P2TR ، يمكن استيعاب الحد الأقصى لعدد التعليمات البرمجية في صفقة واحدة حوالي 4 مليون ، مما يملأ الكتلة بأكملها ، بينما بالنسبة لأنواع الإخراج الأخرى ، لا توجد سوى 10،000 تعليمات برمجية؛
3. طرق الإنفاق لـUTXO الواحد محدودة، ناقصة في استكشاف طرق الإنفاق المجمعة؛
4. وظائف العقد المرن غير مدعومة؛
5. يتم تحديد حجم الكومة بحد أقصى 1000 عنصر (altstack + stack)، وحجم العنصر الفردي الأقصى هو 520 بايت؛
6. العمليات الحسابية (مثل الجمع والطرح) محدودة إلى عناصر بحجم 4 بايتات. لا يمكن تعديلها إلى عناصر طويلة، مثل 20 بايتًا أو أكبر، التي تكون ضرورية للعمليات التشفيرية؛
7. تم تعطيل تعليمات التشغيل مثل OPMUL و OPCAT ، ومحاكاة هذه التعليمات باستخدام التعليمات التشغيلية الموجودة تكلفة عالية للغاية ، مثل محاكاة تجزئة BLAKE3 لجولة واحدة ، بحجم برنامج نصي يبلغ حوالي 75 كيلوبايت.

2.2 الالتزام بيت: الكسر من خلال حدود خلوة UTXO

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

مبدأ الالتزام بالبت نسبياً بسيط. يشير البت إلى تعيين قيمتي هاش مختلفتين، هاش0 وهاش1، لكل بت في الرسالة التي سيتم توقيعها. إذا كانت قيمة البت التي سيتم توقيعها هي 0، يتم الكشف عن الصورة الأصلية0 لهاش0؛ إذا كانت قيمة البت التي سيتم توقيعها هي 1، يتم الكشف عن الصورة الأصلية1 لهاش1.

من خلال أخذ رسالة بت واحدة m ∈ {0,1} كمثال، فإن نص الفتح للالتزام بت المقابل هو مجرد بعض العناصر السابقة: إذا كانت القيمة البتية 0، فإن نص الفتح المقابل هو العنصر السابق 0 - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"، وإذا كانت القيمة البتية 1، فإن نص الفتح المقابل هو العنصر السابق 1 - "0x47c31e611a3bd2f3a7a42207613046703fa27496". وبالتالي، باستخدام الالتزام بالبت، يُمكن اختراق قيود حالة UTXO البيتكوين الخالية من الحالة وتحقيق نصوص بيتكوين ذات حالة، مما يتيح ميزات جديدة مثيرة للاهتمام.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // هذا هو hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // هذا هو هاش0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// الآن قيمة التزام البت على الشكل. إما "0" أو "1".

حاليا، هناك 2 تنفيذات لالتزام البت:

• توقيع لامبورت لمرة واحدة: المبدأ بسيط نسبيا ولا يتطلب سوى استخدام وظائف التجزئة ، مما يجعله صديقا للبيتكوين. ولكل بت في الرسالة، يلزم الالتزام بقيمتي بعثرة، مما يؤدي إلى بيانات توقيع كبيرة نسبيا. بمعنى آخر ، بالنسبة لرسالة طولها v بت ، يكون طول المفتاح العام 2v بت ، وطول التوقيع هو v bits.
• توقيع Winternitz لمرة واحدة: بالمقارنة مع توقيعات Lamport، فإنه يقلل بشكل كبير من طول التواقيع والمفاتيح العامة ولكنه يزيد من تعقيد التوقيع والتحقق. يسمح هذا النظام بضبط مرن لأطوال سلسلة التجزئة المختلفة d، مما يحقق توازنًا بين الطول والتعقيد. على سبيل المثال، ضبط d = 15 يؤدي إلى انخفاض طول كل من مفتاح العام وتوقيع بمقدار 4 مرات، ولكن تعقيد التحقق سيزيد بمقدار 4 مرات. هذا هو في الأساس تضاد بين مساحة الكومة وحجم النص النصي لبيتكوين. يمكن رؤية توقيعات Lamport على أنها حالة خاصة من توقيعات Winternitz عندما d = 1.

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

2.3 الجذر: اختراق قيود مساحة البرنامج النصي

تتضمن ترقية Bitcoin Taproot soft fork ، التي تم تفعيلها في نوفمبر 2021 ، ثلاثة مقترحات: توقيعات Schnorr (BIP 340) و Taproot (BIP 341) و TapScript (BIP 342). يقدم نوعا جديدا من المعاملات - معاملات الدفع إلى Taproot (P2TR). يمكن لمعاملات P2TR إنشاء تنسيق معاملات أكثر خصوصية ومرونة وقابلية للتطوير من خلال الجمع بين مزايا Taproot و MAST (شجرة بناء جملة Merkel المجردة) وتوقيعات Schnorr.

يدعم P2TR طريقتين للإنفاق: الإنفاق وفقًا لمسار المفتاح أو مسار النص.

وفقا للأحكام الواردة في Taproot (BIP 341) ، عند الإنفاق عبر مسار البرنامج النصي ، لا يمكن أن يتجاوز مسار Merkle المقابل الحد الأقصى للطول 128. هذا يعني أن عدد أوراق الشجر في شجرة الصنبور لا يمكن أن يتجاوز 2 ^ 128. منذ ترقية SegWit في عام 2017 ، تقيس شبكة Bitcoin حجم الكتلة بوحدات الوزن ، بحد أقصى لدعم 4 ملايين وحدة وزن (حوالي 4 ميجابايت). عندما يتم إنفاق إخراج P2TR عبر مسار البرنامج النصي ، فإنه يحتاج فقط إلى الكشف عن نص نصي واحد ، مما يعني أن الكتلة معبأة بنص نصي واحد. هذا يعني أنه بالنسبة لمعاملات P2TR ، يمكن أن يكون حجم البرنامج النصي المقابل لكل ورقة نقرة بحد أقصى حوالي 4 ميغابايت. ومع ذلك ، بموجب سياسة Bitcoin الافتراضية ، فإن العديد من العقد تقوم فقط بإعادة توجيه المعاملات الأصغر من 400 ألف. تحتاج المعاملات الأكبر إلى التعاون مع عمال المناجم ليتم تعبئتها.

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

عند إنشاء حساب يمكن التحقق منه استنادا إلى P2TR ، لم يعد حجم البرنامج النصي المقابل يقتصر على قيد 4 ميجابايت ، ولكن يمكن تقسيمه إلى وظائف فرعية متعددة موزعة عبر أوراق نقر متعددة ، وبالتالي اختراق حدود مساحة البرنامج النصي البالغة 4 ميجابايت. في الواقع ، فإن خوارزمية التحقق من Groth16 المطبقة في BitVM2 الحالية لها حجم يصل إلى 2 جيجابايت. ومع ذلك ، يمكن تقسيمها وتوزيعها عبر حوالي 1000 ورقة ، ومن خلال دمجها مع التزام البت ، يمكن تقييد الاتساق بين مدخلات ومخرجات كل وظيفة فرعية ، مما يضمن سلامة وصحة الحساب بأكمله.

2.4 إخراج الموصل: الكسر من خلال قيود طريقة إنفاق UTXO

حاليًا، يوفر بيتكوين طريقتين للإنفاق الأساسيتين لـ UTXO الواحد: الإنفاق عن طريق النص البرمجي أو عن طريق المفتاح العام. لذلك، طالما تم استيفاء التوقيع الصحيح للمفتاح العام أو شروط النص البرمجي، يمكن إنفاق UTXO. يمكن إنفاق UTXOانين بشكل مستقل، ولا يمكن إضافة أي قيود لتقييد UTXOين الاثنين، مما يعني أن يجب استيفاء شروط إضافية لإنفاقهما.

ومع ذلك ، استخدم بوراك ، مؤسس بروتوكول Ark ، بذكاء علم SIGHASH لتحقيق إخراج الموصل. على وجه التحديد ، يمكن لأليس إنشاء توقيع لإرسال BTC الخاص بها إلى بوب. ومع ذلك ، نظرا لأن التوقيع يمكن أن يلتزم بمدخلات متعددة ، يمكن لأليس تعيين توقيعها ليكون شرطيا: يكون التوقيع صالحا لمعاملة Taketx إذا وفقط إذا كانت هذه المعاملة تستهلك الإدخال الثاني. يسمى الإدخال الثاني الموصل ، الذي يربط UTXO A و UTXO B. بمعنى آخر ، تكون معاملة Taketx صالحة إذا وفقط إذا لم يتم إنفاق UTXO B بواسطة Challengetx. لذلك ، من خلال تدمير إخراج الموصل ، يمكن حظر فعالية معاملة Taketx.

الشكل 1: رسم توضيحي لمخرج الموصل

في بروتوكول BitVM2، يعمل إخراج الموصِّل كدالة if...else. بمجرد إنفاق إخراج الموصِّل من قبل عملية تحويل، لا يمكن إنفاقه من قبل عملية تحويل أخرى لضمان إنفاقه الحصري. في النشر العملي، للسماح بفترة الرد التحدي، يتم إدخال مخرجات UTXO الإضافية مع timelock. علاوة على ذلك، يمكن أيضًا تعيين إخراج الموصِّل المقابل باستراتيجيات إنفاق مختلفة حسب الحاجة، مثل السماح لأي طرف بالإنفاق في حالة عمليات التحدي، في حين السماح فقط للمشغّل بالإنفاق أو السماح لأي شخص بالإنفاق بعد فترة زمنية محددة لعمليات الرد.

2.5 العقود: الانتصار على قيود التوقيع المسبق

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

يمكن تقسيم تنفيذات العقود الحالية إلى فئتين:

• التوقيع المسبق: استنادا إلى إمكانات برنامج Bitcoin النصي الحالية ، يتم إنشاء عقود محدودة الوظائف محددة مسبقا من خلال التوقيع المسبق. وهذا يعني تصميم وتوقيع جميع المعاملات المستقبلية المحتملة مقدما ، وقفل المشاركين في مفاتيح خاصة محددة ومعدلات رسوم. حتى أن بعض المخططات تتطلب من المشاركين إنشاء مفاتيح خاصة قصيرة الأجل لجميع المعاملات الموقعة مسبقا. بمجرد اكتمال التوقيع المسبق ، يتم حذف هذه المفاتيح الخاصة قصيرة المدى بشكل آمن ، مما يمنع المهاجمين من الحصول عليها وسرقة الأموال. ومع ذلك ، في كل مرة يتم فيها إضافة مشارك جديد أو تحديث عملية ، يجب تكرار العملية المذكورة أعلاه ، مما يؤدي إلى ارتفاع تكاليف الصيانة. على سبيل المثال ، تحقق شبكة Lightning Network عقودا من طرفين من خلال التوقيع المسبق وتستخدم تقنية Hash Time-Locked Contracts (HTLC) لتنفيذ وظائف التوجيه لعقود متعددة من طرفين ، وبالتالي تحقيق استراتيجية تحجيم تقلل من الثقة. ومع ذلك ، تتطلب شبكة Lightning التوقيع المسبق على معاملات متعددة وتقتصر على طرفين ، مما يجعلها مرهقة إلى حد ما. في BitVM1 ، يجب توقيع مئات المعاملات مسبقا عند كل تهيئة ، بينما في BitVM2 المحسن ، يصل عدد المعاملات التي تحتاج إلى توقيع مسبق عند كل تهيئة أيضا إلى العشرات. في كل من BitVM1 و BitVM2 ، فقط المشغلين المشاركين في التوقيع المسبق مؤهلون للسداد. إذا كان n مشاركا في التوقيع المسبق ، ويحتاج كل مشارك إلى التوقيع المسبق على معاملات m ، فسيكون تعقيد التوقيع المسبق لكل مشارك n * m.
• تقديم أكواد تشغيل العقد: يمكن أن يؤدي إدخال أكواد تشغيلية جديدة لوظيفة العقد إلى تقليل تعقيد الاتصال وتكاليف الصيانة بين المشاركين في العقد بشكل كبير ، وبالتالي تقديم طريقة تنفيذ عقد أكثر مرونة للبيتكوين. على سبيل المثال ، OPCAT: تستخدم لتسلسل سلاسل البايت. على الرغم من أن وظيفتها بسيطة للغاية ، إلا أنها قوية جدا ويمكن أن تقلل بشكل كبير من تعقيد BitVM ؛ OPTXHASH: يسمح بتحكم دقيق أفضل في الإجراءات داخل العقد. إذا تم استخدامه في BitVM ، فيمكنه دعم مجموعة أكبر من المشغلين ، وبالتالي تحسين الافتراضات الأمنية ل BitVM بشكل كبير وتقليل الثقة. بالإضافة إلى ذلك ، فإن طريقة التوقيع المسبق تعني بطبيعتها أن المشغلين في BitVM يمكنهم فقط اعتماد عملية السداد ، مما يؤدي إلى انخفاض كفاءة استخدام رأس المال ؛ في حين أنه من خلال رموز تشغيل العقود الجديدة ، قد يكون من الممكن الدفع مباشرة من مجمع صناديق الربط لمستخدمي المخرجات ، مما يزيد من تحسين كفاءة رأس المال. لذلك ، فإن نموذج العقد المرن سوف يخترق بشكل فعال القيود التقليدية للتوقيع المسبق.

3 بيتكوين Layer2 Scaling: إثباتات الصحة ودلائل الاحتيال

يمكن استخدام كل من إثبات صحة ودليل الاحتيال لتوسيع بيتكوين في الطبقة 2 ، مع الاختلافات الرئيسية الموضحة في الجدول 2.

الجدول 2: إثباتات الصلاحية مقابل إثباتات الاحتيال

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

وفقًا لعدد تفاعلات التحدي والاستجابة بين أليس وبوب، يمكن تقسيم دلائل الاحتيال إلى دلائل الاحتيال ذات جولة واحدة ودلائل الاحتيال متعددة الجولات، كما هو موضح في الشكل ٢.

الشكل 2: إثباتات الاحتيال في جولة واحدة مقابل إثباتات الاحتيال في عدة جولات

كما هو مبين في الجدول 3، يمكن تنفيذ دلائل الاحتيال من خلال نماذج تفاعل مختلفة، بما في ذلك نماذج التفاعل ذات جولة واحدة ونماذج التفاعل متعددة الجولات.

الجدول 3: تفاعل لفترة واحدة مقابل تفاعل متعدد الجولات

في نموذج توسيع Bitcoin Layer2 ، يعتمد BitVM1 آلية إثبات الاحتيال متعددة الجولات ، بينما يستخدم BitVM2 آلية إثبات الاحتيال لجولة واحدة ، ويستخدم bitcoin-circle stark إثباتات الصحة. بين هذه ، يمكن تنفيذ BitVM1 و BitVM2 دون إجراء أي تعديلات على بروتوكول Bitcoin ، بينما يتطلب bitcoin-circle stark إدخال عملية تشغيل جديدة OP_CAT.

بالنسبة لمعظم المهام الحسابية، لا يمكن لـ signet و testnet و mainnet لبيتكوين تمثيل سكريبت بحجم 4 ميغابايت بالكامل، مما يستدعي استخدام تقنية تقسيم السكريبت - أي تقسيم سكريبت الحساب الكامل إلى أجزاء أصغر من 4 ميغابايت، الموزعة عبر مختلف الأوراق التنبيهية.

3.1 دلائل الاحتيال متعددة الجولات على بيتكوين

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

في ورقة البيضاء المبكرة لـ Robin Linus حول BitVM (المشار إليه عادة باسم BitVM1)، تم استخدام دلائل على الاحتيال متعددة الجولات. بافتراض أن فترة كل تحدي تستمر أسبوعًا واستخدام طريقة البحث الثنائي لتحديد الأجزاء الحسابية المشكوك فيها، يمكن أن يصل وقت الاستجابة للتحدي على السلسلة لمحقق Groth16 إلى 30 أسبوعًا، مما يؤدي إلى سوء التوقيت. على الرغم من أن هناك فرق تبحث حاليًا في طرق بحث n-ary أكثر كفاءة من البحث الثنائي، إلا أن توقيتها لا يزال أقل بكثير مقارنة بدورات الأسبوعين في دلائل على الاحتيال من جولة واحدة.

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

3.2 دليل على الاحتيال في جولة واحدة على بيتكوين

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

الشكل 3: دليل الاحتيال لجولة واحدة

في 15 أغسطس 2024، قام روبن لينوس بإصدار ورقة بيضاء تقنية BitVM2: ربط بيتكوين بالطبقات الثانية، التي نفذت جسرًا عبر السلسلة باستخدام طريقة دليل على الاحتيال في جولة واحدة مماثلة لتلك الموضحة في الشكل 3.

3.3 إثباتات الصلاحية على البيتكوين مع OP_CAT

كان OPCAT جزءًا من لغة البرمجة الأصلية عند إصدار بيتكوين ولكن تم تعطيله في عام 2010 بسبب ثغرات الأمان. ومع ذلك ، فقد كانت مجتمع بيتكوين يناقش إعادة تنشيطه لسنوات. تم تعيين OPCAT الآن بالرقم 347 وتم تمكينه على signet بيتكوين.

تتمثل الوظيفة الرئيسية ل OP_CAT في الجمع بين عنصرين في المكدس ودفع النتيجة المدمجة مرة أخرى إلى المكدس. تفتح هذه الوظيفة إمكانية العقود ومدققات STARK على Bitcoin:

• العقود: اقترح أندرو بولسترا CAT و Schnorr Tricks I ، باستخدام تقنيات OPCAT و Schnorr لتنفيذ العقود على Bitcoin. خوارزمية Schnorr هي توقيع رقمي لأنواع مخرجات P2TR ؛ بالنسبة لأنواع المخرجات الأخرى ، يمكن استخدام تقنيات ECDSA مماثلة ، كما هو موضح في العهود مع CAT و ECDSA. بمساعدة عقود OPCAT ، يمكن تقسيم خوارزمية STARK Verifier إلى معاملات متعددة ، والتحقق تدريجيا من إثبات STARK بالكامل.
• مدقّق STARK: المدقق STARK يربط البيانات معًا ويتجزأها. على عكس العمليات الجبرية، يعد التجزئة عملية برمجة Bitcoin الأصلية التي يمكن أن توفر كمية كبيرة من الأعباء. على سبيل المثال، OPSHA256 هو فرد من طرازه الأصلي، بينما الإصدار المحاكى يتطلب مئات الأكواد الفرعية K. تشمل العمليات الرئيسية للتجزئة في STARK التحقق من مسارات Merkle وتحويلات Fiat-Shamir. وبالتالي، OPCAT ودود جدًا لخوارزمية المدقق STARK.

تقنية تقسيم سكريبت البيتكوين 3.4

على الرغم من أن الحمل الحسابي المطلوب لتشغيل خوارزمية التحقق المقابلة للإثبات SNARK/STARK بعد الإثبات أقل بكثير مما يلزم لتشغيل الحساب الأصلي f مباشرة، إلا أن كمية النص البرمجي المطلوب عند تحويله لتنفيذ خوارزمية المحقق في نص Bitcoin ما زالت هائلة. حاليًا، وبناءً على أوامر العملة المشفرة Bitcoin الموجودة، فإن حجم النص البرمجي المحقق المحسّن Groth16 وحجم النص البرمجي المحقق Fflonk لا يزالان أكبر من 2 جيجابايت. ومع ذلك، فإن حجم كتلة Bitcoin الفردية هو فقط 4 ميجابايت، مما يجعل من المستحيل تشغيل النص البرمجي المحقق بأكمله داخل كتلة واحدة. ومع ذلك، بعد ترقية Taproot، يدعم Bitcoin تنفيذ النصوص عن طريق Tapleaf، مما يسمح بتقسيم النص البرمجي المحقق إلى أجزاء متعددة، حيث يعمل كل جزء منها كـ Tapleaf لبناء شجرة تابتري. يمكن ضمان تماسك القيم بين الأجزاء من خلال التزام البت.

في وجود عقود OP_CAT، يمكن تقسيم التحقق من صحة STARK Verifier إلى معاملات قياسية متعددة أصغر من 400 كيلوبايت، مما يسمح بإكمال التحقق من صحة إثبات STARK بالكامل دون الحاجة إلى التعاون مع المنقبين.

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

عند تقسيم النص النصي، يجب موازنة الأبعاد التالية للمعلومات:

• حجم نص كتلة واحدة يجب ألا يتجاوز 4 ميغابايت ويجب أن يتضمن سكريبتات الالتزام بالبت وتوقيعات المعاملات وغيرها من المساحة.
• يجب ألا يتجاوز الحجم الأقصى للمكدس لشظية واحدة 1000. لذا يجب أن يحتفظ مكدس كل شظية بالعناصر الضرورية فقط لحجز مساحة مكدس كافية لتحسين حجم النص التعليمي، حيث أن رسوم تحويل بيتكوين لا تعتمد على حجم المكدس المستخدم.
• التزام بت على بيتكوين مكلفة. لذلك ، يجب تقليل عدد البتات في المدخلات والمخرجات بين قطعتين متجاورتين ، حيث يتوافق 1 بت حاليا مع 26 بايت.
• لسهولة التدقيق، يجب أن تكون وظيفة كل شريحة واضحة قدر الإمكان.

حالياً، يمكن تقسيم أساليب تقسيم النصوص إلى الفئات الرئيسية التالية ثلاثة:

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

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

تكاليف الحساب وبيئات التشغيل للغات البرمجة في الويب2 مختلفة تمامًا عن تلك الموجودة في سكريبتات بيتكوين، لذلك فإن ترجمة التنفيذات الحالية لمختلف الخوارزميات إلى سكريبتات بيتكوين ليست ممكنة. لذلك، يجب مراعاة تحسينات محددة لسيناريو بيتكوين:

• ابحث عن خوارزميات تحسن موقع الذاكرة، حتى على حساب بعض الحمل الحسابي، لتقليل عدد بتات الإدخال/الإخراج بين القطع، مما يقلل من كمية البيانات المطلوبة للالتزامات في تصميم assertTx لعملية BitVM2.
• استخدم تبادل العمليات ذات الصلة (مثل العمليات المنطقية)، مثل x&y = y&x، لتوفير ما يقرب من نصف جدول البحث.
• حاليًا ، حجم النص المقابل لعمليات Fq12 كبير ؛ يُرجى النظر في استخدام برامج Fiat-Shamir و Schwartz-Zipple و polynomial commitment لتقليل تعقيد الحساب الحاسوبي لعمليات توسيع Fq12 بشكل كبير.

4 ملخص

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

تنصل من المسؤولية:

1. يتم نشر هذه المقالة من [ aicoin]. جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [mutourend & lynndell , مختبرات Bitlayer]. إذا كانت هناك اعتراضات على هذا النشر مرجوا التواصل معبوابة التعلمالفريق، وسوف يتعاملون معها بسرعة.
2. تنصل المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر ، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوع.