شرح مفصل لحلول برمجة البيتكوين الاستبطان والعهد

المؤلف: Chakra؛ المترجم: 0xjs@金财经

هذه المقالة هي الجزء الثالث من سلسلة من المقالات حول قابلية التوسع في Bitcoin التي نشرتها Chakra.

بالنسبة للجزء الأول، يرجى الرجوع إلى المقالة السابقة لـ Jinse Finance "مراجعة عملة البيتكوين خطة التوسع الأصلية: SegWit وTaproot"،

بالنسبة للجزء الثاني، يرجى الرجوع إلى المقالة السابقة لـ Jinse Finance "قابلية التوسع في عملة البيتكوين: تحليل حلول الطبقة الثانية والمشاريع ذات الصلة".

الجزء الثالث هو هذا المقال، على النحو التالي:

نظرة عامة

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

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

اعتبارًا من الآن، تدعم ثلاثة رموز تشغيل رئيسية فقط الاستبطان في برنامج Bitcoin النصي: CHECKLOCKTIMEVERIFY، وCHECKSEQUENCEVERIFY، وCHECKSIG، ومتغيراتها CHECKSIGVERIFY، وCHECKSIGADD، وCHECKMULTISIG، وCHECKMULTISIGVERIFY.

العهد (الذي يُترجم أيضًا باسم "القيود")، ببساطة، يشير إلى القيود المفروضة على طرق تحويل العملة، مما يسمح للمستخدمين بتحديد طريقة توزيع UTXO. يتم تنفيذ العديد من العقود من خلال رموز تشغيل الاستبطان، وقد تم الآن نقل مناقشة الاستبطان إلى موضوع عقود Bitcoin Optech.

تمتلك Bitcoin حاليًا عقدين، CSV (CheckSequenceVerify) وCLTV (CheckLockTimeVerify). كلا العقدين عبارة عن عقود تعتمد على الوقت وهي أساس العديد من حلول التوسع (مثل Lightning Network). يوضح هذا أن حل التوسع الخاص بالبيتكوين يعتمد بشكل كبير على الاستبطان والعقود.

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

في ما يلي، نوضح اقتراح كود تشغيل العهد الذي تمت مناقشته على نطاق واسع.

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify) هو مقترح ترقية Bitcoin في BIP-119، والذي جذب اهتمامًا واسع النطاق من المجتمع. يسمح CTV للبرامج النصية للمخرجات بتحديد قوالب لصرف الأموال في المعاملات، بما في ذلك nVersion وnLockTime وتجزئة scriptSig وعدد المدخلات وتجزئة التسلسل وعدد المخرجات وتجزئة المخرجات وفهرس الإدخال والحقول الأخرى. يتم تنفيذ قيود القالب هذه عبر وعود التجزئة، وعندما يتم إنفاق الأموال، يتحقق البرنامج النصي مما إذا كان تجزئة الحقل المحدد في معاملة الإنفاق يتطابق مع التجزئة في البرنامج النصي للإدخال. وهذا يحد بشكل فعال من وقت وطريقة ومبلغ المعاملات المستقبلية لـ UTXO.

من الجدير بالذكر أنه يتم استبعاد إدخال TXID من هذا التجزئة. يعد هذا الاستبعاد ضروريًا لأنه في المعاملات التقليدية ومعاملات SegWit، عند استخدام نوع التوقيع الافتراضي SIGHASH_ALL، يعتمد TXID على القيمة الموجودة في scriptPubKey. يؤدي تضمين TXID إلى حدوث تبعية دائرية في وعد التجزئة، مما يجعل من المستحيل بنائها.

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

أساس حلول الطبقة الثانية من Bitcoin (مثل الشبكة المسرّعة) هو المعاملات الموقعة مسبقًا. يشير التوقيع المسبق عادةً إلى إنشاء المعاملات وتوقيعها مسبقًا ولكن لا يتم بثها حتى يتم استيفاء شروط معينة. في الجوهر، تطبق CTV نموذجًا أكثر تقييدًا للتوقيع المسبق، ونشر الالتزامات الموقعة مسبقًا على السلسلة وتقييدها بالقوالب المحددة مسبقًا.

تم اقتراح CTV في الأصل للتخفيف من ازدحام Bitcoin، والذي يمكن أن يسمى أيضًا التحكم في الازدحام. عندما يكون الازدحام شديدًا، يمكن لـ CTV الالتزام بمعاملات مستقبلية متعددة في معاملة واحدة، وتجنب بث معاملات متعددة خلال ساعات الذروة وإكمال المعاملة الفعلية عندما يخف الازدحام. قد يكون هذا مفيدًا بشكل خاص أثناء تشغيل البورصة. بالإضافة إلى ذلك، يمكن استخدام القالب لتنفيذ Vault للحماية من هجمات المتسللين. نظرًا لأن تدفق الأموال محدد مسبقًا، لا يمكن للمتسللين استخدام نصوص CTV لتوجيه UTXOs إلى عناوينهم الخاصة.

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

APO (SIGHASH_ANYPREVOUT) BIP-118

يقدم BIP-118 علامة تجزئة توقيع جديدة لبرنامج Tapscript المصمم لتسهيل منطق إنفاق أكثر مرونة، يُسمى SIGHASH_ANYPREVOUT. هناك العديد من أوجه التشابه بين APO وCTV. يتمثل أسلوب APO في حل مشكلة الحلقة بين scriptPubKeys وTXID في استبعاد معلومات الإدخال ذات الصلة وتوقيع المخرجات فقط، مما يسمح بربط المعاملات ديناميكيًا بكائنات UTXO مختلفة.

من الناحية المنطقية، عملية التحقق من التوقيع OP_CHECKSIG (والمتغيرات) منها) تؤدي ثلاث وظائف:

1. تجميع الأجزاء المختلفة لمعاملة الإنفاق.

2.

3. تحقق من توقيع المفتاح المحدد.

التفاصيل المحددة للتوقيع مرنة للغاية، وتحدد علامة SIGHASH حقول المعاملة التي تم التوقيع عليها. وفقًا لتعريف رموز تشغيل التوقيع في BIP 342، يتم تقسيم علامة SIGHASH إلى SIGHASH_ALL، وSIGHASH_NONE، وSIGHASH_SINGLE، وSIGHASH_ANYONECANPAY. يتحكم SIGHASH_ANYONECANPAY في الإدخال، بينما يتحكم الآخرون في الإخراج.

SIGHASH_ALL هي علامة SIGHASH الافتراضية، وتوقيع كل المخرجات؛ SIGHASH_NONE لا يوقع أي مخرجات؛ SIGHASH_SINGLE يشير إلى مخرجات محددة. يمكن ضبط SIGHASH_ANYONECANPAY مع أعلام SIGHASH الثلاثة الأولى. إذا تم تعيين SIGHASH_ANYONECANPAY، فسيتم توقيع الإدخال المحدد فقط؛ وإلا، يجب توقيع جميع الإدخالات.

من الواضح أن علامات SIGHASH هذه لا تلغي تأثير الإدخال، حتى SIGHASH_ANYONECANPAY، الأمر الذي يتطلب الالتزام بإدخال.

لذلك، اقترح BIP 118 SIGHASH_ANYPREVOUT. لا تتطلب توقيعات APO الالتزام بإدخال UTXO (يسمى PREVOUT) مستهلك، ولكن فقط مخرجات، مما يوفر مرونة أكبر للتحكم في Bitcoin. من خلال إنشاء المعاملة مسبقًا وإنشاء التوقيع المطابق لمرة واحدة والمفتاح العام، يجب استخدام الأصول المرسلة إلى عنوان المفتاح العام هذا من خلال المعاملة التي تم إنشاؤها مسبقًا، وبالتالي استيفاء العقد. يمكن أيضًا استخدام مرونة APO لإصلاح المعاملة؛ إذا كانت المعاملة عالقة في السلسلة لأن الرسوم منخفضة جدًا، فيمكن إنشاء معاملة أخرى بسهولة لزيادة الرسوم دون الحاجة إلى توقيع جديد. بالإضافة إلى ذلك، بالنسبة للمحافظ متعددة التوقيع، فإن عدم الاعتماد على المدخلات المستهلكة يجعل العمليات أكثر ملاءمة.

نظرًا للتخلص من الحلقة بين scriptPubKeys وإدخال TXID، يمكن لـ APO إجراء الاستبطان عن طريق إضافة بيانات الإخراج في Witness، على الرغم من أن هذا لا يزال يتطلب استهلاكًا إضافيًا لمساحة Witness.

بالنسبة للبروتوكولات خارج السلسلة مثل Lightning Network وVaults، يقلل APO الحاجة إلى حفظ الحالة المتوسطة، مما يقلل بشكل كبير من متطلبات التخزين والتعقيد. حالة الاستخدام الأكثر إلحاحًا لـ APO هي Eltoo، التي تعمل على تحسين أداء الشبكة المسرّعة بعدة طرق من خلال تبسيط مصانع القنوات، وبناء أبراج مراقبة خفيفة الوزن ورخيصة الثمن، والسماح بالخروج من جانب واحد دون ترك حالات خطأ. يمكن أيضًا استخدام APO لمحاكاة وظيفة CTV، على الرغم من أنه يتطلب من الأفراد تخزين المعاملات الموقعة والموقعة مسبقًا، وهو أكثر تكلفة وأقل كفاءة من CTV.

يتركز النقد الرئيسي لـ APO على حقيقة أنه يتطلب إصدارًا رئيسيًا جديدًا، وهو ما لا يمكن تحقيقه من خلال التوافق البسيط مع الإصدارات السابقة. بالإضافة إلى ذلك، قد تؤدي أنواع تجزئة التوقيع الجديدة إلى مخاطر محتملة للإنفاق المزدوج. وبعد مناقشة مستفيضة للمجتمع، حصلت APO على رمز BIP-118 عن طريق إضافة توقيعات منتظمة أعلى آلية التوقيع الأصلية لتخفيف المخاوف الأمنية.

OP_VAULT BIP-345

يقترح BIP-345 إضافة اثنين من أكواد التشغيل الجديدة، OP_VAULT وOP_VAULT_RECOVER، والتي، عند استخدامها بالتزامن مع CTV، تنفذ عقودًا متخصصة تسمح للمستخدمين بفرض تأخير استخدام عملة معينة. خلال هذا التأخير، يمكن "التراجع" عن المعاملات التي تم إجراؤها مسبقًا عبر مسار الاسترداد.

يمكن للمستخدمين إنشاء Vault عن طريق إنشاء عنوان Taproot محدد، والذي يجب أن يحتوي على نصين برمجيين على الأقل في MAST: أحدهما بكود التشغيل OP_VAULT لتسهيل عملية السحب المقصودة، والآخر بكود التشغيل OP_VAULT_RECOVER لضمان ذلك يمكن استعادة الرموز المميزة في أي وقت قبل اكتمال عملية السحب.

كيفية تنفيذ OP_VAULT هل تمت مقاطعة سحب القفل المحدد بوقت؟ يقوم OP_VAULT بذلك عن طريق استبدال البرنامج النصي OP_VAULT المستخدم بالبرنامج النصي المحدد، وتحديث صفحة واحدة من MAST بشكل فعال مع ترك العقد الطرفية Taproot المتبقية دون تغيير. هذا التصميم مشابه لـ TLUV، باستثناء أن OP_VAULT لا يدعم تحديثات المفاتيح الداخلية.

يمكن تقييد المدفوعات عن طريق تقديم النماذج أثناء تحديثات البرنامج النصي. يتم تحديد معلمة قفل الوقت بواسطة OP_VAULT، ويحد قالب كود تشغيل CTV من مجموعة المخرجات التي يمكن استخدامها من خلال مسار البرنامج النصي هذا.

تم تصميم BIP-345 خصيصًا لـ Vaults، مع الاستفادة من OP_VAULT وOP_VAULT_RECOVER لتزويد المستخدمين بطريقة ضمان آمنة، باستخدام مفاتيح آمنة للغاية (مثل المحافظ الورقية أو التوقيعات المتعددة الموزعة) كمسارات استرداد، مع توفير يتم تكوين المدفوعات العادية مع تأخير معين. يقوم جهاز المستخدم بمراقبة إنفاق الخزينة بشكل مستمر، وفي حالة حدوث تحويل غير متوقع، يمكن للمستخدم بدء عملية الاسترداد.

يأتي تنفيذ Vault عبر BIP-345 مع اعتبارات التكلفة، خاصة لاستعادة المعاملات. تتضمن الحلول الممكنة CPFP (يدفع الطفل مقابل الوالدين)، والمثبتات المؤقتة، وعلامة التجزئة الموقعة SIGHASH_GROUP الجديدة.

TLUV (TapleafUpdateVerify)

تم تصميم حل TLUV حول Taproot وهو مصمم لحل مشكلة خروج UTXO المشتركة بشكل فعال. المبدأ التوجيهي هو أنه عند استهلاك مخرجات Taproot، يمكن تحديث المفاتيح الداخلية وMAST (محاولة Tapscript) جزئيًا من خلال تحويلات التشفير والبنية الداخلية لعنوان Taproot، كما هو موضح في برنامج TLUV النصي. وهذا يجعل تنفيذ وظائف العهد ممكنًا.

يتمثل مفهوم مخطط TLUV في إنشاء عنوان Taproot جديد استنادًا إلى مدخلات الإنفاق الحالية عن طريق تقديم كود التشغيل الجديد TAPLEAF_UPDATE_VERIFY. يمكن تحقيق ذلك عن طريق تنفيذ واحد أو أكثر من الإجراءات التالية:

• تحديث المفتاح العام الداخلي

< li >

قص مسار Merkle

• حذف البرنامج النصي الذي يتم تنفيذه حاليًا

• أضف خطوة جديدة في نهاية مسار ميركل

  p>

على وجه التحديد، يقبل TLUV ثلاثة مدخلات:

• حدد كيفية تحديث المفتاح العام الداخلي.

• طريقة لتحديد خطوة جديدة لمسار Merkle.

• حدد ما إذا كنت تريد حذف البرنامج النصي الحالي و/أو عدد خطوات مسار Merkle التي سيتم تقليمها.

يقوم كود التشغيل TLUV بحساب scriptPubKey المحدث والتحقق مما إذا كان الإخراج المطابق للإدخال الحالي قد تم إنفاقه على scriptPubKey هذا.

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

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

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

يمتلك TLUV القدرة على أن يكون حلاً لتجمعات الطبقة الثانية اللامركزية، ولكن موثوقيته في تكييف Taproot Trie لا تزال بحاجة إلى تأكيد.

MAT

تهدف MATT (Merkleize All The Things) إلى تحقيق ثلاثة أهداف: Merkleizing الدولة، وMerkleizing النص، وMerkleizing الأداء، وبالتالي تحقيق العقود الذكية العالمية.

• دمج الحالة: يتضمن ذلك بناء Merkle Trie، حيث تمثل كل عقدة طرفية تجزئة لقيمة الحالة، بينما يعكس Merkle Root الوضع العام للعقد.

• Merkleizing البرنامج النصي: يشير هذا إلى استخدام Tapscript لتكوين MAST، حيث تمثل كل عقدة طرفية مسارًا محتملًا لانتقال الحالة.

• Merkleizing الأداء: Merkleizing التنفيذ من خلال الالتزام بالتشفير وآليات تحدي الاحتيال. بالنسبة لأي وظيفة حسابية، يمكن للمشاركين حسابها خارج السلسلة ثم إصدار التزام f(x)=y. إذا اكتشف المشاركون الآخرون النتيجة غير الصحيحة f(x)=z، فيمكنهم بدء التحدي. يتم إجراء التحكيم عبر بحث ثنائي، على غرار مبدأ التراكمي المتفائل.

تنفيذ Merkelized

من أجل تنفيذ MATT، تحتاج لغة Bitcoin النصية إلى الوظائف التالية:

• فرض أن يحتوي الإخراج على برنامج نصي محدد (وترقيمه)

• إلحاق جزء من البيانات إلى الإخراج

• قراءة البيانات من الإدخال الحالي (أو إدخال آخر)

النقطة الثانية هي حاسم: البيانات الديناميكية تعني أنه يمكن حساب الحالة من بيانات الإدخال التي يقدمها المستهلك، حيث يسمح ذلك بمحاكاة آلة الحالة، القادرة على تحديد الحالة التالية والبيانات الإضافية. يحقق نظام MATT ذلك من خلال كود التشغيل OP_CHECKCONTRACTVERIFY (OP_CCV)، وهو عبارة عن دمج لشفرتي التشغيل OP_CHECKOUTPUTCONTRACTVERIFY وOP_CHECKINPUTCONTRACTVERIFY المقترحتين مسبقًا، باستخدام معلمة علامة إضافية لتحديد هدف العملية.

التحكم في مقدار الإخراج: الطريقة الأكثر وضوحًا هي الاستبطان المباشر؛ ومع ذلك، فإن مقدار الإخراج هو رقم 64 بت ويتطلب حسابًا 64 بت، مما يقدم الكثير من التعقيد في نصوص Bitcoin. يستخدم OP_CCV طريقة فحص مؤجلة مثل OP_VAULT، حيث تتم إضافة كميات الإدخال لجميع المدخلات لنفس الإخراج في CCV معًا كحد أدنى لمقدار هذا الإخراج. يرجع التأخير إلى أن هذا الفحص يحدث أثناء المعاملة، وليس أثناء تقييم البرنامج النصي للإدخال.

نظرًا لانتشار أدلة الاحتيال في كل مكان، يجب أن تكون بعض أنواع عقد MATT قادرة على تنفيذ جميع أنواع العقود الذكية أو بنيات الطبقة الثانية، على الرغم من أن المتطلبات الإضافية (مثل تأمين الأموال وتأخير فترة التحدي) تحتاج إلى أن يتم تقييمها بدقة؛ هناك حاجة إلى مزيد من البحث لتقييم التطبيقات التي يمكنها قبول المعاملات. على سبيل المثال، استخدم التزام التشفير وآليات تحدي الاحتيال لمحاكاة وظيفة OP_ZK_VERIFY لتنفيذ عمليات التجميع غير الموثوق بها على Bitcoin.

في الممارسة العملية، حدث هذا بالفعل. قام يوهان توراس هالسيث بتنفيذ Elftrace باستخدام كود التشغيل OP_CHECKCONTRACTVERIFY في اقتراح MATT soft fork، والذي يسمح بالتحقق من أي برنامج تم تجميعه بدعم RISC-V على Bitcoin blockchain، مما يسمح لأحد الأطراف في اتفاقية العقد بتمرير التحقق من العقد للوصول إلى الأموال، سد التحقق الأصلي من Bitcoin.

CSFS (OP_CHECKSIGFROMSTACK)

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

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

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

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

يمكن لـ CSFS تنفيذ أكواد التشغيل مثل CLTV، وCSV، وCTV، وAPO، وما إلى ذلك، مما يجعلها كود تشغيل متعدد الاستخدامات للاستبطان. ولذلك، فهو يساهم أيضًا في حلول قابلية التوسع من الطبقة الثانية للبيتكوين. العيب هو أنه يتطلب إضافة نسخة كاملة من المعاملة الموقعة على المكدس، مما قد يزيد بشكل كبير من حجم المعاملات باستخدام استبطان CSFS. تحتوي أكواد تشغيل الاستبطان ذات الغرض الواحد مثل CLTV وCSV على حمل بسيط بالمقارنة، ولكن إضافة كل كود تشغيل خاص جديد للاستبطان يتطلب تغييرات متفق عليها.

TXHASH (OP_TXHASH)

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

نظرًا لأوجه التشابه بين TXHASH وCTV، كان هناك الكثير من المناقشات حول الاثنين في المجتمع.

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

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

من المتوقع أن يتم توسيع حقل TxFieldSelector المحدد في مواصفات TXHASH ليشمل أكواد تشغيل أخرى، مثل OP_TX.

إن BIP المتعلق بـ TXHASH موجود حاليًا في حالة مسودة على GitHub ولم يتم تعيين رقم له بعد.

OP_CAT

OP_CAT عبارة عن شفرة تشغيل غامضة تم التخلي عنها في الأصل من قبل ساتوشي ناكاموتو لأسباب أمنية، ولكنها أثارت مؤخرًا مناقشات ساخنة بين مطوري Bitcoin الأساسيين، وحتى أنها بدأت ثقافة Meme على إنترنت. في النهاية، تمت الموافقة على OP_CAT بموجب BIP-347، وتم الاستشهاد به باعتباره اقتراح BIP الذي من المرجح أن يتم تمريره في المستقبل القريب.

في الواقع، سلوك OP_CAT بسيط جدًا: فهو يربط عنصرين من المكدس. كيف تنفذ وظيفة العهد؟

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

كما ذكرنا سابقًا، يتيح CSFS حلول العهد العالمي بمساعدة OP_CAT. في الواقع، يمكن لـ OP_CAT نفسه تمكين فحص المعاملات حتى بدون CSFS، مع الاستفادة من بنية توقيعات Schnorr.

في توقيع شنور، تتكون الرسالة المطلوب توقيعها من الحقول التالية:

تحتوي هذه الحقول على العناصر الرئيسية للمعاملة. من خلال وضعها في scriptPubKey أو Witness واستخدام OP_CAT بالتزامن مع OP_SHA256، يمكننا إنشاء توقيع Schnorr والتحقق منه باستخدام OP_CHECKSIG. إذا تم التحقق، فإن المكدس يحتفظ ببيانات المعاملة التي تم التحقق منها، مما يتيح فحص المعاملة. يتيح لنا ذلك استخراج و"فحص" أجزاء مختلفة من المعاملة، مثل مدخلاتها أو مخرجاتها أو عنوان الوجهة أو كمية البيتكوين المعنية.

للتعرف على مبادئ التشفير المحددة، يمكنك الرجوع إلى مقالة Andrew Poelstra "CAT and Schnorr Tricks".

باختصار، فإن تعدد استخدامات OP_CAT يمكّنه من محاكاة أي كود تشغيل خاص بالعهد تقريبًا. تعتمد العديد من أكواد تشغيل العهد على وظيفة OP_CAT، مما يعزز موقعها بشكل كبير في قائمة الدمج. من الناحية النظرية، بالاعتماد فقط على OP_CAT وأكواد تشغيل Bitcoin الحالية، يمكننا أن نأمل في بناء BTC ZK Rollup مع تقليل الثقة. تعمل Starknet وChakra وشركاء النظام البيئي الآخرون بنشاط على الترويج لهذا الهدف.

الاستنتاج

بينما نستكشف استراتيجيات مختلفة لتوسيع نطاق Bitcoin وتعزيز قابليتها للبرمجة، فمن الواضح أن المسار للأمام يتضمن تحسينات أصلية، وحسابات خارج السلسلة، ودمج قدرات البرمجة النصية المتطورة.

بدون طبقة أساسية مرنة، من المستحيل بناء طبقة ثانية أكثر مرونة.

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

ومع ذلك، فإن طبيعة الحوسبة على Bitcoin تختلف اختلافًا جوهريًا عن طبيعة الحوسبة على Ethereum. تدعم Bitcoin فقط "التحقق" كشكل من أشكال الحساب ولا يمكنها إجراء حسابات عامة، في حين أن Ethereum ذو ​​طبيعة حسابية، والتحقق هو منتج ثانوي للحساب. يمكن ملاحظة هذا الاختلاف في نقطة واحدة: تفرض إيثريوم رسوم الغاز على المعاملات التي لا يمكن تنفيذها، في حين أن بيتكوين لا تفرض أي رسوم.

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

يميل APO وOP_VAULT وTLUV إلى التطبيق المباشر. يمكن أن يؤدي اختيار هذه الطرق الثلاثة إلى تحقيق تطبيقات محددة بتكلفة أقل وأكثر كفاءة. سيختار عشاق شبكة Lightning Network APO لتنفيذ LN-Symmetry؛ ومن الأفضل للمستخدمين الذين يرغبون في تنفيذ Vault استخدام OP_VAULT؛ ولإنشاء CoinPool، يمكن لـ TLUV توفير خصوصية وكفاءة أفضل. تعد OP_CAT وTXHASH أكثر ثراءً بالميزات، وأقل احتمالية لوجود ثغرات أمنية، ويمكن دمجهما مع أكواد التشغيل الأخرى لتحقيق المزيد من حالات الاستخدام، ولكن التكلفة قد تزيد من تعقيد البرنامج النصي. يقوم CTV وCSFS بضبط طريقة معالجة blockchain، وينفذ CTV المخرجات المؤجلة، وينفذ CSFS التوقيع المؤجل. تتميز MATT بتنفيذها المتفائل واستراتيجياتها المقاومة للاحتيال، والاستفادة من هيكل Merkle Trie لتنفيذ العقود الذكية ذات الأغراض العامة، لكن وظيفة الاستبطان لا تزال تتطلب أكواد تشغيل جديدة.

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