بيتكوين限制条款:实现 قابلية البرمجة的新方向

شهدت مجتمع بيتكوين مؤخرًا مناقشات حماسية حول إعادة تفعيل العمليات البرمجية مثل OP_CAT. جذب Taproot Wizard الكثير من الانتباه من خلال إطلاق Quantum Cats NFT وادعاء الحصول على رقم BIP-420. ويقول المؤيدون إن تفعيل OP_CAT يمكن أن يحقق "شروط مقيدة"، مما يجلب للبيتكوين العقود الذكية وقابلية البرمجة.

"قيود الشروط"(covenants) هذا المفهوم أثار مناقشات المطورين لعدة سنوات. بالإضافة إلى OP_CAT، هناك أيضًا OP_CTV وAPO وOP_VAULT وغيرها من الحلول التقنية لتنفيذ قيود الشروط. إذن، ما هي "قيود الشروط" في بيتكوين؟ لماذا أثارت مثل هذا الاهتمام الواسع والدائم؟ ما هي قابلية البرمجة التي يمكن أن تقدمها لبيتكوين؟ ما هي مبادئ التصميم الكامنة وراءها؟ ستقوم هذه المقالة بتقديم نظرة عامة ومناقشة لهذه الأسئلة.

ما هو "شرط القيد"

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

وقد أضافت القيود شروطًا إضافية، مثل تحديد وجهة الإنفاق التالية لـ UTXO، لتحقيق تأثير "استخدام الأموال المخصصة"؛ أو تقييد شروط المدخلات الأخرى في معاملة واحدة.

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

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

لذلك، يمكن أن تؤدي بنود القيود بشكل غير بديهي إلى فتح المزيد من سيناريوهات التطبيق.

سيناريوهات التطبيق

تأكد من عقوبة Staking

مثال بديهي على شروط التقييد هو عملية الشطب في Bitcoin staking الخاصة بـ Babylon.

عملية Staking بيتكوين في Babylon هي أن يقوم المستخدمون بإرسال أصول BTC إلى نص خاص على السلسلة الرئيسية، وتشمل شروط الإنفاق نوعين:

1. إنهاء طبيعي: بعد مرور فترة معينة، يمكن للمستخدم استخدام توقيعه الخاص لفك القفل، واستكمال عملية إلغاء الرهان.

2. انتهاء العقوبة: إذا كان لدى المستخدم سلوكيات ضارة مثل التوقيع المزدوج على سلسلة PoS الخاصة بإيجار الأمان في Babylon، يمكن من خلال EOTS( استخراج توقيع لمرة واحدة ) لفتح الأصول، وسيقوم الدور التنفيذي في الشبكة بإرسال جزء من الأصول بشكل قسري إلى عنوان الحرق (slash).

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

بعد تنفيذ شروط مثل OP_CTV، يمكن إضافة تعليمات برمجية ذات صلة في فرع "انتهاء العقوبة" في نص المراهنة لتنفيذ القيود.

وقبل تفعيل OP_CTV، تحتاج Babylon إلى تنفيذ طريقة بديلة من خلال المستخدمين واللجنة لمحاكاة تأثير تنفيذ القيود.

التحكم في الازدحام

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

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

عندما يكون الطلب على مساحة الكتلة مرتفعًا، تصبح المعاملات مكلفة. باستخدام OP_CHECKTEMPLATEVERIFY، يمكن لمزودي معالجة المدفوعات بالجملة تجميع جميع المدفوعات في معاملة واحدة O(1) للتأكيد. بعد ذلك، عندما ينخفض الطلب على مساحة الكتلة، يمكن توسيع المدفوعات من تلك UTXO.

هذا أحد التطبيقات النموذجية التي قدمتها شروط القيد OP_CTV.

خزنة

الخزنة (vault) هي سيناريو يتم مناقشته على نطاق واسع في تطبيقات بيتكوين، خاصة في مجال الشروط المقيدة. تتطلب العمليات اليومية تحقيق التوازن بين الحفاظ على الأموال واحتياجات الاستخدام، حيث يأمل الناس في وجود نوع من تطبيقات خزائن الأموال: يمكنها ضمان أمان الأموال، حتى في حالة تعرض الحساب للاختراق ( أو تسرب المفتاح الخاص )، يمكن أن تقيد استخدام الأموال.

بناءً على تقنية شروط القيود، يمكن بسهولة بناء تطبيقات من نوع الخزائن.

باستخدام خطة OP_VAULT كمثال: عند إنفاق أموال الخزينة، تحتاج أولاً إلى إرسال معاملة لتسجيل النية ("trigger")، وتحديد الشروط:

• في الظروف العادية: المعاملة الثانية هي معاملة السحب النهائية. بعد انتظار N كتلة، يمكن إنفاق الأموال بشكل إضافي إلى أي عنوان.

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

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

قناة حالة أكثر قوة ومرونة

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

إل تو( يُعرف أيضًا باسم LN-Symmetry) وهو مثال نموذجي. يقدم طبقة تنفيذ لشبكة البرق، مما يسمح لأي حالة قناة لاحقة باستبدال الحالة السابقة دون الحاجة إلى آلية عقوبة، وبالتالي يمكن تجنب حاجة عقد شبكة البرق للاحتفاظ بالعديد من الحالات السابقة تحسبًا لأساليب الخصم. اقترح إل تو طريقة توقيع SIGHASH_NOINPUT، أي APO(BIP-118) لتحقيق هذا التأثير.

تهدف Ark إلى تقليل صعوبة السيولة الداخلة وإدارة القنوات في شبكة Lightning. إنها بروتوكول على شكل joinpool، حيث يمكن لعدة مستخدمين قبول مزود خدمة واحد كطرف مقابل لفترة معينة، وإجراء معاملات vUTXO( خارج السلسلة، ولكنهم يشتركون في UTXO واحد على السلسلة لتقليل التكاليف. مشابهة لبركة الأمان، يمكن أيضًا تنفيذ Ark على شبكة بيتكوين الحالية؛ ولكن بعد إدخال شروط التقييد، يمكن لـ Ark تقليل كمية التفاعل المطلوبة بناءً على قوالب المعاملات، مما يتيح خروجًا أحادي الجانب أكثر عدم ثقة.

![شرح مفصل حول العهود: كيف يمكن تحقيق قابلية برمجة بيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(

نظرة عامة على الشروط المحدودة

من التطبيقات المذكورة أعلاه، يمكن أن نرى أن شروط القيود تشبه تأثيرًا أكثر من كونها تقنية معينة، وبالتالي هناك عدة طرق للتنفيذ. يمكن تصنيفها من عدة أبعاد كما يلي:

• النوع: عام، خاص
• طريقة التنفيذ: تعتمد على التعليمات البرمجية، تعتمد على التوقيع
• التكرارية: التكرار، غير التكرار

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

التصميم الرئيسي لشروط القيود يشمل:

• OP_CTV: نوع عام، يعتمد على رمز التشغيل، غير تكراري
• APO: نوع عام، يعتمد على التوقيع، غير متكرر
• OP_VAULT: نوع مخصص، قائم على شفرة العملية، غير تكراري
• OP_CAT: نوع عام، قائم على تعليمات التشغيل، تكراري ) إذا تم دمجه مع OP_CAT (

![شرح مفصل عن العهود: كيف يمكن تحقيق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(

تصميم شروط القيد

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

السبب الرئيسي هو أن سكربت بيتكوين الحالي لا يمكنه قراءة محتوى المعاملة نفسها، أي "الاستبطان")introspection(.

إذا كان من الممكن تحقيق تدقيق المعاملات - فحص أي شيء في المعاملات ) بما في ذلك المخرجات (، يمكن تحقيق شروط التقييد.

لذلك فإن تصميم شروط التقييد يدور بشكل رئيسي حول كيفية تحقيق الاستبطان.

![شرح العهود: كيف نحقق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-07087bfb6a80b962d13965a8a89b6c6d.webp(

) بناءً على التعليمات البرمجية مقابل بناءً على التوقيع

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

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

![شرح العهود: كيف تحقق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-5eacb98269f8d7e5b02fe936ac208702.webp(

) APO

SIGHASH_ANYPREVOUT###APO( هي طريقة توقيع مقترحة لبيتكوين. أسهل طريقة للتوقيع هي الالتزام بكل من مدخلات ومخرجات المعاملة، ولكن بيتكوين لديها طريقة أكثر مرونة، وهي SIGHASH، التي تتيح الالتزام بشكل انتقائي بمدخلات أو مخرجات المعاملة.

توقيع SIGHASH الخاص بـ APO يوقع فقط على المخرجات، ولا يوقع على جزء المدخلات. هذا يعني أن المعاملات الموقعة بطريقة APO يمكن إضافتها لاحقًا إلى أي UTXO تفي بالشروط.

هذه المرونة هي الأساس النظري لقيود تنفيذ شروط APO:

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

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

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

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

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

! [العهود بالتفصيل: كيفية تحقيق قابلية برمجة البيتكوين؟] ](https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp)

( OP_CTV

OP_CHECKTEMPLATEVERIFY)CTV###، وهو BIP-119، اعتمد على تحسين رمز العملية