بيتكوينLayer 2扩展التحليل الفني：إثبات صحة与دليل على الاحتيال

1 المقدمة

لإنشاء الثقة بين Alice و Bob ، وهما جهات اتصال غير موثوق بهما ، فيمكن استخدام الخوارزمية f التي تعمل بينهما على النحو التالي:

1. أليس تدخل x وتشغل الخوارزمية f وتحصل على النتيجة y. بوب يستخدم أيضًا نفس الإدخال x ويشغل الخوارزمية f ويحصل على y’. إذا كانت y و y’ متساويتين، يعترف بوب بالإدخال x والإخراج y الذي قدمته أليس. هذه هي آلية إثبات صحة شائعة، وتطبق عادة في توافق السلسلة الكتلية، حيث تكون أليس عقدة التعبئة للكتلة وبوب عقدة المشاركة في التوافق. ٢. أليس تدخل x، تقوم بتشغيل برنامج zk.prove، وتحصل على النتيجة y والإثبات proof. بوب يقوم بتشغيل برنامج zk.verify بناءً على f و y و proof. إذا كانت النتيجة صحيحة، يقبل بوب نتيجة أليس y؛ إذا كانت النتيجة خاطئة، فإن بوب لا يقبل نتيجة أليس y. هذا هو نوع من إثبات الصحة، بوب يمكن أن يكون عقدًا داخل السلسلة.
2. إدخال Alice لـ x، تشغيل الخوارزمية f، الحصول على النتيجة y. يستخدم Bob أيضًا إدخال x نفسه لتشغيل الخوارزمية f والحصول على النتيجة y’. إذا كان y و y’ متساويين ، لا يحدث شيء ؛ إذا كان y و y’ غير متساويين ، فسيتحدى Bob Alice ، والتحدي هو برنامج f. يمكن أن يكون التفاعل بين Alice و Bob جولة واحدة أو عدة جولات. يتم التوسط من خلال آلية التحدي والاستجابة. هذا يشكل دليلاً على الاحتيال ، حيث يكون Bob هو المتحدِّي الذي يستمع في الخلفية ويطلق التحدي عبر الإنترنت.
3. يُدخل Alice x ، ويُشغل برنامج zk.prove ، ويحصل على النتيجة y ودليل البرهان proof. يقوم Bob بتشغيل برنامج zk.verify بناءً على f و y و proof. إذا كانت النتيجة صحيحة ، فلن يفعل شيئًا ؛ إذا كانت النتيجة خاطئة ، فسيتحدى Bob Alice ، وبرنامج التحدي هو zk.verify. يمكن أن تكون التفاعلات بين Alice و Bob جولة واحدة أو عدة جولات. يتم التحكيم من خلال آلية التحدي والاستجابة. هذه طريقة لدليل على الاحتيال ، حيث يكون Bob المتحدي ، يراقب في الوضع عبر الإنترنت ويبدأ في التحدي عبر الإنترنت.

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

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

الجدول 1: كيفية بناء الثقة

علاوة على ذلك ، يجب أن نولي اهتمامًا خاصًا للنقاط التالية:

• المفتاح في تمييز دليل الاحتيال عن إثبات الصحة ليس في استخدام أنظمة البرهان مثل SNARK أو STARK. نظم البرهان هي فقط وسيلة للتعبير عن طريقة البرهان المستخدمة، بينما الاحتيال أو الصحة يمثلان محتوى البرهان. لذلك، يشار للسيناريو 1 في الجدول 1 بأنه إثبات صحة.
• إثبات صحة的时效性更好，但داخل السلسلة验证的复杂性较高؛而دليل على الاحتيال的داخل السلسلة验证复杂性较低，但时效性较差。
• بالنسبة للحالات 2 و 4 في الجدول 1، يمكن حساب وضغط العديد من f باستخدام تقنية ZK العودية والتجميع، مما يقلل بشكل كبير من تكلفة التحقق من الحسابات داخل السلسلة بدلاً من خارجها.

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

القيود والاختراقات في سياق بيتكوين 2

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

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

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

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

وعد 2.2 بت: اختراق حد UTXO عديم الجنسية

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

مبدأ وعد البِت نسبياً بسيط. كل بِت يقابل قيمتين مختلفتين للتجزئة، hash0 و hash1. إذا كانت قيمة البِت المراد توقيعها هي 0، فإنه يكشف عن البادئة لـ hash0؛ إذا كانت قيمة البِت هي 1، فإنه يكشف عن البادئة لـ hash1.

على سبيل المثال ، للبِت الفردي m ∈ {0،1} ، يتكون البرنامج النصي المتعهد المقابل فقط من بعض البيانات المسبقة: إذا كانت قيمة البِت تساوي 0 ، فإن البرنامج النصي المتعهد هو preimage0 - ‘0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140’ ؛ إذا كانت قيمة البِت تساوي 1 ، فإن البرنامج النصي المتعهد هو preimage1 - ‘0x47c31e611a3bd2f3a7a42207613046703fa27496’. بالتالي ، يمكن من خلال البرنامج النصي المتعهد بِت تجاوز القيود العديمة للحالة لـ UTXO وتحقيق البرامج النصية BTC ذات الحالة ، مما يتيح تحقيق ميزات جديدة مثيرة للاهتمام.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // هذا هو الهاش1

OP_EQUAL

OP_DUP

OP_ROT

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

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// الآن يتم تعيين قيمة بِت على الستاك. يمكن أن تكون “0” أو “1”.

حالياً، بِت تعد بطريقتين للتنفيذ:

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

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

2.3 Taproot: تجاوز حدود مساحة النص البرمجي

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

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

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

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

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

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

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

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

2.5 العقد: تجاوز القيود المسبقة للتوقيع

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

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

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

3 بيتكوين Layer2 توسيع الطبقة: إثبات صحة ودليل على الاحتيال

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

表2: إثبات صحة ودليل على الاحتيال

بناءً على وعد بِت وتابروت والتوقيع المسبق وإخراج الموصل، يمكن بناء دليل على الاحتيال بناءً على BTC. بالإضافة إلى ذلك، يمكن أيضًا بناء إثبات صحة لـ BTC بناءً على تابروت عن طريق إدخال رموز العقد (مثل OP_CAT). بالإضافة إلى ذلك، يمكن تقسيم دليل على الاحتيال إلى دليل على الاحتيال المرخص ودليل على الاحتيال غير المرخص بناءً على ما إذا كان بوب لديه التوافق مع الفكرة. في دليل على الاحتيال المرخص، يمكن لمجموعات محددة فقط أن تتحدى بوب، بينما في دليل على الاحتيال غير المرخص، يمكن لأي طرف ثالث أن يتحدى بوب. الأمان في دليل على الاحتيال غير المرخص أفضل من دليل على الاحتيال المرخص، لأنه يتجنب مخاطر تآمر المشاركين.

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

الشكل 2: دليل على الاحتيال الفردي ودليل على الاحتيال المتعدد

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

الجدول 3: التفاعل الفردي والتفاعل المتعدد

في Paradigm توسيع Layer2 لـ BTC، يستخدم BitVM1 آلية إثبات الاحتيال متعددة الجولات، بينما يستخدم BitVM2 آلية إثبات الاحتيال لجولة واحدة، بينما يستخدم bitcoin-circle stark إثبات الصحة. من بين هذه الآليات، يمكن لـ BitVM1 و BitVM2 تحقيق ذلك دون تعديل بروتوكول BTC، بينما يتطلب bitcoin-circle stark إدخال رمز عملية جديد OP_CAT.

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

3.1 BTC多轮دليل على الاحتيال

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

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

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

3.2 دليل على الاحتيال من بيتكوين

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

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

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

3.3 استخدام OP_CAT لإثبات صحة بيتكوين

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

OP_CAT الغرض الرئيسي منه هو دمج عنصرين في القرص، ودفع النتيجة الى القرص مرة اخرى. هذه الوظيفة توفر إمكانيات جديدة للعقود على BTC ومدققي التحقق STARK:

• العقد: قدم Andrew Poelstra CAT و Schnorr Tricks I ، واستخدم تقنيات OP_CAT و Schnorr لتحقيق العقود على BTC. Schnorr الخوارزمية هي توقيع رقمي ينطبق على أنواع الإخراج P2TR. بالنسبة لأنواع الإخراج الأخرى ، يمكن استخدام تقنية ECDSA المماثلة ، كما هو موضح في العقد الذي يستخدم CAT و ECDSA. بفضل عقد OP_CAT ، يمكن تفكيك محقق STARK في عدة صفقات والتحقق من البرهان كاملاً تدريجيًا.
• جهاز التحقق STARK: الوظيفة الرئيسية لجهاز التحقق STARK هي ربط البيانات معًا وإجراء التجزئة. على عكس العمليات الجبرية، التجزئة هي عملية أساسية في سكريبت BTC ويمكن أن تقلل بشكل كبير من التكاليف. على سبيل المثال، OP_SHA256 في شكله الأصلي هو رمز عملية مستقل، بينما يتطلب الإصدار المحاكي المئات من رموز العمليات. تشمل العمليات الرئيسية للتجزئة في STARK التحقق من المسارات الميركلية وتحويل فيات-شامير. وبالتالي، فإن OP_CAT يعمل بشكل جيد مع جهاز التحقق STARK.

3.4 تقنية تقسيم سكريبت BTC

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

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

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

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

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

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

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

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

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

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

4 ملخص

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

بيان:

1. تم نشر هذه المقالة مسبقًا على [aicoin]، حقوق الطبع والنشر مملوكة للكاتب الأصلي [mutourend & lynndell، Bitlayer Labs]، إذا كان لديك اعتراض على إعادة النشر، يرجى الاتصال بفريق Gate Learn (https://www.gate.io/questionnaire/3967)، حيث سيقوم الفريق بمعالجة الأمر وفقًا للإجراءات ذات الصلة في أقرب وقت ممكن.
2. إخلاء المسؤولية: تعبر وجهات النظر والآراء المعبر عنها في هذه المقالة فقط عن وجهة نظر الكاتب الشخصية ولا تشكل أي توصية استثمارية.
3. تُترجم النسخ الأخرى للمقالات إلى لغات أخرى من قبل فريق Gate Learn، ولا يُسمح بنسخ أو نشر أو اقتباس المقالات المترجمة دون ذكر Gate.io.