شرح تفصيلي لشروط القيود: تحقيق قابلية برمجة بيتكوين
شهد مجتمع بيتكوين مؤخراً نقاشاً حول إعادة تفعيل أوامر التشغيل مثل OP_CAT. جذب Taproot Wizard الانتباه بعد إطلاقه لـ Quantum Cats NFT وادعائه الحصول على رقم BIP-420. يدعي المؤيدون أن تفعيل OP_CAT يمكن أن يحقق "شروط محدودة"، مما يمكّن من عقود بيتكوين الذكية أو قابلية البرمجة.
إذا كنت قد لاحظت كلمة "شروط التقييد" وقمت ببحث بسيط، فستجد أنها جحر أرنب كبير آخر. لقد ناقش المطورون لسنوات عديدة، بالإضافة إلى OP_CAT، تقنيات تنفيذ شروط التقييد مثل OP_CTV وAPO وOP_VAULT.
إذن، ما هو "شرط القيود" لبيتكوين؟ ولماذا يجذب هذا العدد الكبير من المطورين للاهتمام والنقاش المستمر لعدة سنوات؟ ما هي قابلية البرمجة التي يمكن تحقيقها في بيتكوين؟ ما هي المبادئ التصميمية الكامنة وراء ذلك؟ ستقوم هذه المقالة بتقديم نظرة عامة ومناقشة.
ما هو "شرط القيود"
قيود ( التعهدات ) هي آلية يمكنها وضع شروط لمعاملات بيتكوين المستقبلية.
تتضمن سكريبت البيتكوين الحالي أيضًا شروطًا مقيدة، مثل ضرورة إدخال توقيع قانوني عند الإنفاق، وإدخال سكريبت متوافق، وما إلى ذلك. ولكن طالما يمكن للمستخدم فتح القفل، يمكنه إنفاق تلك UTXO في أي مكان يريده.
أما شروط القيود فهي فرض المزيد من القيود على أساس كيفية فك القيد، مثل تقييد الإنفاق بعد UTXO، مما يحقق تأثيرًا مشابهًا لـ "تخصيص الأموال"؛ أو الشروط الأخرى المدخلة في صفقة واحدة.
بشكل أكثر دقة، يحتوي نص بيتكوين الحالي أيضًا على بعض شروط القيود، مثل قفل الوقت القائم على تعليمات التشغيل، والذي يتم تنفيذه من خلال حقول nLock أو nSequence في المعاملات للتقييد الزمني قبل إنفاق المعاملة، ولكنه يقتصر أساسًا على القيود الزمنية فقط.
إذن، لماذا يجب على المطورين والباحثين تصميم هذه الفحوصات المحدودة؟ لأن شروط القيود ليست مجرد قيود من أجل القيود، بل هي قواعد لتنفيذ المعاملات. بهذه الطريقة، يمكن للمستخدمين تنفيذ المعاملات فقط وفقًا للقواعد المحددة مسبقًا، وبالتالي إكمال العمليات التجارية المحددة.
لذا فإن الأمر غير بديهي إلى حد ما، لكن هذا يمكن أن يفتح المزيد من سيناريوهات الاستخدام.
سيناريوهات التطبيق
تأمين عقوبة Staking
أحد الأمثلة الأكثر وضوحًا لشروط التقييد هو صفقة الخصم في عملية رهان بيتكوين الخاصة بـ Babylon.
عملية تخزين بيتكوين في Babylon هي أن يقوم المستخدمون بإرسال أصول BTC الخاصة بهم إلى نص خاص على السلسلة الرئيسية، وتشمل شروط الإنفاق نوعين:
الحالة الطبيعية: بعد فترة معينة, يمكن للمستخدم باستخدام توقيعه الخاص فتح القفل, مما يعني إكمال عملية unstake
حالات استثنائية: إذا كان لدى المستخدم سلوك غير قانوني مثل التوقيع المزدوج على سلسلة PoS المستأجرة من Babylon، فإنه يمكن من خلال EOTS(التوقيعات القابلة للاستخراج لمرة واحدة، فتح هذه الأصول، وسيقوم الأدوار التنفيذية في الشبكة بإرسال جزء من الأصول قسراً إلى عنوان الحرق)slash(
لاحظ هنا "الإرسال الإجباري"، مما يعني أنه حتى لو كان بإمكانك فتح قفل هذا UTXO، لا يمكن إرسال هذا الأصل إلى أي مكان آخر بشكل عشوائي، بل يمكن حرقه فقط. فقط بهذه الطريقة يمكن ضمان عدم تمكن المستخدمين الذين يقومون بأعمال سيئة من استخدام توقيعاتهم المعروفة لنقل الأصول لأنفسهم للهروب من العقوبة.
يمكن إضافة أوامر OP_CTV وغيرها من الأوامر في فرع "الحالات الاستثنائية" لبرنامج staking بعد تنفيذ شروط القيود مثل OP_CTV.
قبل تفعيل OP_CTV، يحتاج بابل إلى تنفيذ طرق بديلة، حيث يتم تنفيذها من قبل المستخدم + اللجنة بشكل مشترك لمحاكاة تحقيق تأثير تنفيذ الشروط التقييدية.
![شرح العهود: كيف تحقق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(
) التحكم في الازدحام
بشكل عام، يشير الازدحام إلى الوقت الذي تكون فيه رسوم المعاملات على شبكة بيتكوين مرتفعة جداً، وتكون هناك معاملات متراكمة في مجموعة المعاملات تنتظر التعبئة، لذا إذا أراد المستخدم تأكيد المعاملة بسرعة، فإنه يحتاج إلى زيادة رسوم المعاملات.
وفي هذه الحالة، إذا كان على المستخدم إرسال عدة معاملات إلى عدة مستلمين، فسيتعين عليه رفع الرسوم، مما يتحمل تكلفة أعلى. في الوقت نفسه، سيؤدي ذلك أيضًا إلى زيادة معدل الرسوم في الشبكة بأكملها.
إذا كانت هناك شروط محددة، فإن إحدى الحلول هي أن يلتزم المرسل أولاً بإجراء صفقة إرسال جماعي. يمكن أن يمنح هذا الالتزام جميع المستلمين الثقة بأن الصفقة النهائية ستتم، ويمكنهم الانتظار حتى تكون رسوم المعاملات منخفضة لإرسال الصفقة المحددة.
عندما تكون الطلبات على مساحة الكتلة مرتفعة، تصبح المعاملات باهظة الثمن للغاية. من خلال استخدام OP_CHECKTEMPLATEVERIFY، يمكن لمعالجات الدفع بكميات كبيرة تجميع جميع مدفوعاتها في معاملة واحدة O###1( لتأكيدها. ثم، بعد فترة من الوقت، عندما يقل الطلب على مساحة الكتلة، يمكن توسيع المدفوعات من تلك UTXO.
هذا السيناريو هو حالة تطبيقية نموذجية فرضتها شرط القيود OP_CTV.
) خزينة
保管库###vault( هو نوع من التطبيقات التي يتم مناقشتها على نطاق واسع في تطبيقات بيتكوين، خاصة في مجال الشروط المحدودة. نظرًا لأن العمليات اليومية لا مفر منها في تحقيق التوازن بين احتياجات حفظ الأموال واستخدام الأموال، فإن الناس يأملون في وجود نوع من تطبيقات خزائن الأموال: يمكن أن يضمن سلامة الأموال، وحتى إذا تم اختراق الحساب) وتسرب المفتاح الخاص(، يمكن أن يحد من استخدام الأموال.
استنادًا إلى التقنيات التي تحقق شروط القيود، يمكن بناء تطبيقات من نوع المحفظة بسهولة نسبية.
باستخدام تصميم OP_VAULT كمثال: عند إنفاق الأموال في خزينة الحفظ، يجب أولاً إرسال معاملة على السلسلة. تشير هذه المعاملة إلى النية في إنفاق خزينة الحفظ، أي "trigger"، وتحدد الشروط فيها:
إذا سارت الأمور على ما يرام، فإن المعاملة الثانية هي معاملة السحب النهائية. بعد الانتظار لعدد N من الكتل، يمكن إنفاق الأموال في أي مكان.
إذا تم اكتشاف أن هذه المعاملة هي عملة مسروقة ) أو تم تهديدها بـ "هجوم العتلة" (، يمكن إرسالها فورًا إلى عنوان آمن آخر ) قبل إرسال معاملات السحب في N كتلة، مما يجعل حفظها أكثر أمانًا للمستخدم (.
من المهم ملاحظة أنه في غياب شروط القيود، يمكن أيضًا بناء تطبيق خزنة، إحدى الطرق القابلة للتطبيق هي إعداد توقيع الإنفاق المستقبلي باستخدام المفتاح الخاص، ثم تدمير هذا المفتاح الخاص. لكن لا تزال هناك قيود كثيرة، مثل الحاجة إلى التأكد من أن هذا المفتاح الخاص قد تم تدميره )، وهو مشابه لعملية الإعداد الموثوق في الإثباتات ذات المعرفة الصفرية (، والمبالغ والرسوم يجب أن تحدد مسبقًا ) بسبب الحاجة إلى التوقيع المسبق ( مما يسبب نقصًا في المرونة.
![شرح العقود: كيفية تحقيق قابلية برمجة البيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(
) حالة قناة أكثر قوة ومرونة
يمكن اعتبار أن قنوات الحالة، بما في ذلك شبكة البرق، تمتلك أمانًا يكاد يكون مماثلاً للسلسلة الرئيسية ### بشرط أن تكون العقد قادرة على ملاحظة الحالة الأخيرة، وأن تكون قادرة على نشر الحالة الأخيرة على السلسلة بشكل طبيعي (. ومع ذلك، بعد وجود شروط محدودة، يمكن أن تكون بعض أفكار تصميم قنوات الحالة الجديدة أكثر قوة أو مرونة فوق شبكة البرق. ومن بين هذه الأفكار المعروفة Eltoo و Ark.
إل تو ) يُعرَف أيضًا باسم LN-Symmetry(، وهو مثال نموذجي من بين أمور أخرى. تستند هذه التقنية على صوت "L2"، حيث تقدم مستوى تنفيذ لشبكة البرق، مما يسمح لأي حالة قناة لاحقة باستبدال الحالة السابقة دون الحاجة إلى آلية عقابية، وبالتالي يمكنها أيضًا تجنب الحاجة إلى حفظ حالات سابقة متعددة مثل عقد شبكة البرق لمنع سوء التصرف. لتحقيق هذا التأثير، اقترح إل تو طريقة توقيع SIGHASH_NOINPUT، أي APO)BIP-118(.
وتهدف Ark إلى تقليل صعوبة تدفق السيولة الواردة وإدارة القنوات في شبكة الضوء. إنها بروتوكول على شكل joinpool، حيث يمكن للعديد من المستخدمين قبول مزود خدمة كطرف مقابل لمدة معينة، وإجراء معاملات افتراضية UTXO)vUTXO( خارج السلسلة، ولكن بمشاركة UTXO واحد على السلسلة مما يقلل التكاليف. مثل خزنة، يمكن أيضًا تنفيذ Ark على شبكة البيتكوين الحالية؛ ولكن بعد إدخال شروط محدودة، يمكن لـ Ark تقليل كمية التفاعل المطلوبة بناءً على قوالب المعاملات، لتحقيق خروج أحادي الجانب أكثر موثوقية.
![شرح التفصيل: كيف يمكن تحقيق قابلية برمجة البيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
نظرة عامة على الشروط القيود التقنية
من التطبيقات المذكورة أعلاه، يمكن أن نرى أن شروط التقييد تشبه تأثيرًا أكثر من كونها تقنية معينة، لذا توجد العديد من الطرق التقنية لتحقيقها. إذا تم تصنيفها، فيمكن أن تشمل:
النوع: عام، خاص
طريقة التنفيذ: بناءً على Opcode، بناءً على التوقيع
الاسترجاع: الاسترجاع، غير الاسترجاع
ومن بين ذلك، تشير الاستدعاءات إلى: يمكن تنفيذ بعض شروط القيود من خلال تقييد الناتج التالي لتقييد الناتج الذي يليه، ويمكن أن تحقق القيود المضافة تجاوز معاملة واحدة، مما يصل إلى عمق تداول أعلى.
بعض تصميمات شروط القيود السائدة تشمل:
OP_CTV: نوع عام، يعتمد على Opcode، غير تكراري
OP_VAULT: نوع خاص, قائم على Opcode, غير تكراري
APO: نموذج عام، قائم على التوقيع، غير تكراري
OP_CAT: نوع عام، بناءً على Opcode، تكراري*
OP_CSFS:عام, قائم على التوقيع, متكرر
*إذا تم الجمع بين OP_CAT
![شرح العهود: كيف تحقق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
تصميم شروط التقييد
من المقدمة السابقة يمكننا أن نرى أن نصوص البيتكوين الحالية تقيد فقط شروط فك القفل، ولا تحدد كيفية إنفاق هذه UTXO بشكل أكبر. لتحقيق قيود، يجب أن نفكر في الاتجاه المعاكس: لماذا لا تستطيع نصوص البيتكوين الحالية تحقيق قيود؟
السبب الرئيسي هو أن سكربت بيتكوين الحالي لا يمكنه قراءة محتوى المعاملات نفسها، أي "الاستقصاء" )introspection(.
إذا استطعنا تحقيق التأمل في المعاملات - فحص أي شيء في المعاملة ) بما في ذلك المخرجات (، فإنه يمكن تحقيق شروط التقييد.
لذلك فإن فكرة تصميم شروط القيود تدور أساسًا حول كيفية تحقيق الاستبطان.
![شرح مفصل عن Covenants: كيف يمكن تحقيق قابلية برمجة بيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(
) قائمة على أوامر التشغيل مقابل قائمة على التوقيع
أبسط فكرة هي إضافة رمز عملية واحد أو أكثر ### أي رمز عملية + مجموعة متنوعة من المعلمات، أو عدة رموز عملية مختلفة (، لقراءة محتوى المعاملة مباشرة. هذه هي الفكرة القائمة على رمز العملية.
وأما الفكرة الأخرى، فهي أنه يمكن عدم قراءة وفحص محتوى المعاملة نفسها مباشرة في البرنامج النصي، بل يمكن استخدام تجزئة محتوى المعاملة - إذا تم توقيع هذه التجزئة بالفعل، فكل ما عليك هو تعديل مثل OP_CHECKSIG في البرنامج النصي لتحقيق فحص هذا التوقيع، مما يتيح تحقيق استبصار المعاملة وفرض الشروط بشكل غير مباشر. هذه الفكرة تعتمد على تصميم مستند إلى التوقيع. وتشمل بشكل رئيسي APO و OP_CSFS وغيرها.
) APO
SIGHASH_ANYPREVOUT###APO( هو نوع مقترح من طرق توقيع البيتكوين. أبسط طريقة للتوقيع هي الالتزام بكل من المدخلات والمخرجات للمعاملة، ولكن البيتكوين لديه طرق أكثر مرونة، وهي SIGHASH، التي تسمح بالالتزام بشكل انتقائي بمدخلات أو مخرجات معينة في معاملة.
و SIGHASH الخاص بـ APO يقوم بالتوقيع فقط على المخرجات، وليس على جزء المدخلات. وهذا يعني أنه بعد توقيع الصفقة بطريقة APO، يمكن أن تكون في
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تفصيل شروط قيود البيتكوين: بدء عصر جديد من قابلية البرمجة
شرح تفصيلي لشروط القيود: تحقيق قابلية برمجة بيتكوين
شهد مجتمع بيتكوين مؤخراً نقاشاً حول إعادة تفعيل أوامر التشغيل مثل OP_CAT. جذب Taproot Wizard الانتباه بعد إطلاقه لـ Quantum Cats NFT وادعائه الحصول على رقم BIP-420. يدعي المؤيدون أن تفعيل OP_CAT يمكن أن يحقق "شروط محدودة"، مما يمكّن من عقود بيتكوين الذكية أو قابلية البرمجة.
إذا كنت قد لاحظت كلمة "شروط التقييد" وقمت ببحث بسيط، فستجد أنها جحر أرنب كبير آخر. لقد ناقش المطورون لسنوات عديدة، بالإضافة إلى OP_CAT، تقنيات تنفيذ شروط التقييد مثل OP_CTV وAPO وOP_VAULT.
إذن، ما هو "شرط القيود" لبيتكوين؟ ولماذا يجذب هذا العدد الكبير من المطورين للاهتمام والنقاش المستمر لعدة سنوات؟ ما هي قابلية البرمجة التي يمكن تحقيقها في بيتكوين؟ ما هي المبادئ التصميمية الكامنة وراء ذلك؟ ستقوم هذه المقالة بتقديم نظرة عامة ومناقشة.
ما هو "شرط القيود"
قيود ( التعهدات ) هي آلية يمكنها وضع شروط لمعاملات بيتكوين المستقبلية.
تتضمن سكريبت البيتكوين الحالي أيضًا شروطًا مقيدة، مثل ضرورة إدخال توقيع قانوني عند الإنفاق، وإدخال سكريبت متوافق، وما إلى ذلك. ولكن طالما يمكن للمستخدم فتح القفل، يمكنه إنفاق تلك UTXO في أي مكان يريده.
أما شروط القيود فهي فرض المزيد من القيود على أساس كيفية فك القيد، مثل تقييد الإنفاق بعد UTXO، مما يحقق تأثيرًا مشابهًا لـ "تخصيص الأموال"؛ أو الشروط الأخرى المدخلة في صفقة واحدة.
بشكل أكثر دقة، يحتوي نص بيتكوين الحالي أيضًا على بعض شروط القيود، مثل قفل الوقت القائم على تعليمات التشغيل، والذي يتم تنفيذه من خلال حقول nLock أو nSequence في المعاملات للتقييد الزمني قبل إنفاق المعاملة، ولكنه يقتصر أساسًا على القيود الزمنية فقط.
إذن، لماذا يجب على المطورين والباحثين تصميم هذه الفحوصات المحدودة؟ لأن شروط القيود ليست مجرد قيود من أجل القيود، بل هي قواعد لتنفيذ المعاملات. بهذه الطريقة، يمكن للمستخدمين تنفيذ المعاملات فقط وفقًا للقواعد المحددة مسبقًا، وبالتالي إكمال العمليات التجارية المحددة.
لذا فإن الأمر غير بديهي إلى حد ما، لكن هذا يمكن أن يفتح المزيد من سيناريوهات الاستخدام.
سيناريوهات التطبيق
تأمين عقوبة Staking
أحد الأمثلة الأكثر وضوحًا لشروط التقييد هو صفقة الخصم في عملية رهان بيتكوين الخاصة بـ Babylon.
عملية تخزين بيتكوين في Babylon هي أن يقوم المستخدمون بإرسال أصول BTC الخاصة بهم إلى نص خاص على السلسلة الرئيسية، وتشمل شروط الإنفاق نوعين:
لاحظ هنا "الإرسال الإجباري"، مما يعني أنه حتى لو كان بإمكانك فتح قفل هذا UTXO، لا يمكن إرسال هذا الأصل إلى أي مكان آخر بشكل عشوائي، بل يمكن حرقه فقط. فقط بهذه الطريقة يمكن ضمان عدم تمكن المستخدمين الذين يقومون بأعمال سيئة من استخدام توقيعاتهم المعروفة لنقل الأصول لأنفسهم للهروب من العقوبة.
يمكن إضافة أوامر OP_CTV وغيرها من الأوامر في فرع "الحالات الاستثنائية" لبرنامج staking بعد تنفيذ شروط القيود مثل OP_CTV.
قبل تفعيل OP_CTV، يحتاج بابل إلى تنفيذ طرق بديلة، حيث يتم تنفيذها من قبل المستخدم + اللجنة بشكل مشترك لمحاكاة تحقيق تأثير تنفيذ الشروط التقييدية.
![شرح العهود: كيف تحقق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(
) التحكم في الازدحام
بشكل عام، يشير الازدحام إلى الوقت الذي تكون فيه رسوم المعاملات على شبكة بيتكوين مرتفعة جداً، وتكون هناك معاملات متراكمة في مجموعة المعاملات تنتظر التعبئة، لذا إذا أراد المستخدم تأكيد المعاملة بسرعة، فإنه يحتاج إلى زيادة رسوم المعاملات.
وفي هذه الحالة، إذا كان على المستخدم إرسال عدة معاملات إلى عدة مستلمين، فسيتعين عليه رفع الرسوم، مما يتحمل تكلفة أعلى. في الوقت نفسه، سيؤدي ذلك أيضًا إلى زيادة معدل الرسوم في الشبكة بأكملها.
إذا كانت هناك شروط محددة، فإن إحدى الحلول هي أن يلتزم المرسل أولاً بإجراء صفقة إرسال جماعي. يمكن أن يمنح هذا الالتزام جميع المستلمين الثقة بأن الصفقة النهائية ستتم، ويمكنهم الانتظار حتى تكون رسوم المعاملات منخفضة لإرسال الصفقة المحددة.
عندما تكون الطلبات على مساحة الكتلة مرتفعة، تصبح المعاملات باهظة الثمن للغاية. من خلال استخدام OP_CHECKTEMPLATEVERIFY، يمكن لمعالجات الدفع بكميات كبيرة تجميع جميع مدفوعاتها في معاملة واحدة O###1( لتأكيدها. ثم، بعد فترة من الوقت، عندما يقل الطلب على مساحة الكتلة، يمكن توسيع المدفوعات من تلك UTXO.
هذا السيناريو هو حالة تطبيقية نموذجية فرضتها شرط القيود OP_CTV.
) خزينة
保管库###vault( هو نوع من التطبيقات التي يتم مناقشتها على نطاق واسع في تطبيقات بيتكوين، خاصة في مجال الشروط المحدودة. نظرًا لأن العمليات اليومية لا مفر منها في تحقيق التوازن بين احتياجات حفظ الأموال واستخدام الأموال، فإن الناس يأملون في وجود نوع من تطبيقات خزائن الأموال: يمكن أن يضمن سلامة الأموال، وحتى إذا تم اختراق الحساب) وتسرب المفتاح الخاص(، يمكن أن يحد من استخدام الأموال.
استنادًا إلى التقنيات التي تحقق شروط القيود، يمكن بناء تطبيقات من نوع المحفظة بسهولة نسبية.
باستخدام تصميم OP_VAULT كمثال: عند إنفاق الأموال في خزينة الحفظ، يجب أولاً إرسال معاملة على السلسلة. تشير هذه المعاملة إلى النية في إنفاق خزينة الحفظ، أي "trigger"، وتحدد الشروط فيها:
من المهم ملاحظة أنه في غياب شروط القيود، يمكن أيضًا بناء تطبيق خزنة، إحدى الطرق القابلة للتطبيق هي إعداد توقيع الإنفاق المستقبلي باستخدام المفتاح الخاص، ثم تدمير هذا المفتاح الخاص. لكن لا تزال هناك قيود كثيرة، مثل الحاجة إلى التأكد من أن هذا المفتاح الخاص قد تم تدميره )، وهو مشابه لعملية الإعداد الموثوق في الإثباتات ذات المعرفة الصفرية (، والمبالغ والرسوم يجب أن تحدد مسبقًا ) بسبب الحاجة إلى التوقيع المسبق ( مما يسبب نقصًا في المرونة.
![شرح العقود: كيفية تحقيق قابلية برمجة البيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(
) حالة قناة أكثر قوة ومرونة
يمكن اعتبار أن قنوات الحالة، بما في ذلك شبكة البرق، تمتلك أمانًا يكاد يكون مماثلاً للسلسلة الرئيسية ### بشرط أن تكون العقد قادرة على ملاحظة الحالة الأخيرة، وأن تكون قادرة على نشر الحالة الأخيرة على السلسلة بشكل طبيعي (. ومع ذلك، بعد وجود شروط محدودة، يمكن أن تكون بعض أفكار تصميم قنوات الحالة الجديدة أكثر قوة أو مرونة فوق شبكة البرق. ومن بين هذه الأفكار المعروفة Eltoo و Ark.
إل تو ) يُعرَف أيضًا باسم LN-Symmetry(، وهو مثال نموذجي من بين أمور أخرى. تستند هذه التقنية على صوت "L2"، حيث تقدم مستوى تنفيذ لشبكة البرق، مما يسمح لأي حالة قناة لاحقة باستبدال الحالة السابقة دون الحاجة إلى آلية عقابية، وبالتالي يمكنها أيضًا تجنب الحاجة إلى حفظ حالات سابقة متعددة مثل عقد شبكة البرق لمنع سوء التصرف. لتحقيق هذا التأثير، اقترح إل تو طريقة توقيع SIGHASH_NOINPUT، أي APO)BIP-118(.
وتهدف Ark إلى تقليل صعوبة تدفق السيولة الواردة وإدارة القنوات في شبكة الضوء. إنها بروتوكول على شكل joinpool، حيث يمكن للعديد من المستخدمين قبول مزود خدمة كطرف مقابل لمدة معينة، وإجراء معاملات افتراضية UTXO)vUTXO( خارج السلسلة، ولكن بمشاركة UTXO واحد على السلسلة مما يقلل التكاليف. مثل خزنة، يمكن أيضًا تنفيذ Ark على شبكة البيتكوين الحالية؛ ولكن بعد إدخال شروط محدودة، يمكن لـ Ark تقليل كمية التفاعل المطلوبة بناءً على قوالب المعاملات، لتحقيق خروج أحادي الجانب أكثر موثوقية.
![شرح التفصيل: كيف يمكن تحقيق قابلية برمجة البيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
نظرة عامة على الشروط القيود التقنية
من التطبيقات المذكورة أعلاه، يمكن أن نرى أن شروط التقييد تشبه تأثيرًا أكثر من كونها تقنية معينة، لذا توجد العديد من الطرق التقنية لتحقيقها. إذا تم تصنيفها، فيمكن أن تشمل:
ومن بين ذلك، تشير الاستدعاءات إلى: يمكن تنفيذ بعض شروط القيود من خلال تقييد الناتج التالي لتقييد الناتج الذي يليه، ويمكن أن تحقق القيود المضافة تجاوز معاملة واحدة، مما يصل إلى عمق تداول أعلى.
بعض تصميمات شروط القيود السائدة تشمل:
*إذا تم الجمع بين OP_CAT
![شرح العهود: كيف تحقق قابلية البرمجة لبيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
تصميم شروط التقييد
من المقدمة السابقة يمكننا أن نرى أن نصوص البيتكوين الحالية تقيد فقط شروط فك القفل، ولا تحدد كيفية إنفاق هذه UTXO بشكل أكبر. لتحقيق قيود، يجب أن نفكر في الاتجاه المعاكس: لماذا لا تستطيع نصوص البيتكوين الحالية تحقيق قيود؟
السبب الرئيسي هو أن سكربت بيتكوين الحالي لا يمكنه قراءة محتوى المعاملات نفسها، أي "الاستقصاء" )introspection(.
إذا استطعنا تحقيق التأمل في المعاملات - فحص أي شيء في المعاملة ) بما في ذلك المخرجات (، فإنه يمكن تحقيق شروط التقييد.
لذلك فإن فكرة تصميم شروط القيود تدور أساسًا حول كيفية تحقيق الاستبطان.
![شرح مفصل عن Covenants: كيف يمكن تحقيق قابلية برمجة بيتكوين؟])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(
) قائمة على أوامر التشغيل مقابل قائمة على التوقيع
أبسط فكرة هي إضافة رمز عملية واحد أو أكثر ### أي رمز عملية + مجموعة متنوعة من المعلمات، أو عدة رموز عملية مختلفة (، لقراءة محتوى المعاملة مباشرة. هذه هي الفكرة القائمة على رمز العملية.
وأما الفكرة الأخرى، فهي أنه يمكن عدم قراءة وفحص محتوى المعاملة نفسها مباشرة في البرنامج النصي، بل يمكن استخدام تجزئة محتوى المعاملة - إذا تم توقيع هذه التجزئة بالفعل، فكل ما عليك هو تعديل مثل OP_CHECKSIG في البرنامج النصي لتحقيق فحص هذا التوقيع، مما يتيح تحقيق استبصار المعاملة وفرض الشروط بشكل غير مباشر. هذه الفكرة تعتمد على تصميم مستند إلى التوقيع. وتشمل بشكل رئيسي APO و OP_CSFS وغيرها.
) APO
SIGHASH_ANYPREVOUT###APO( هو نوع مقترح من طرق توقيع البيتكوين. أبسط طريقة للتوقيع هي الالتزام بكل من المدخلات والمخرجات للمعاملة، ولكن البيتكوين لديه طرق أكثر مرونة، وهي SIGHASH، التي تسمح بالالتزام بشكل انتقائي بمدخلات أو مخرجات معينة في معاملة.
و SIGHASH الخاص بـ APO يقوم بالتوقيع فقط على المخرجات، وليس على جزء المدخلات. وهذا يعني أنه بعد توقيع الصفقة بطريقة APO، يمكن أن تكون في