HashKey Capital: "المواثيق" قابلية برمجة البيتكوين

المؤلف الأصلي: رئيس قسم أبحاث الاستثمار لدى HashKey Capital جيفري هو، مدير استثمار HashKey Capital Harper LI

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

إذا لاحظت كلمة "قيود" وأجريت القليل من البحث، فستجد أن هذا يمثل حفرة أرنب كبيرة أخرى. لقد ناقش المطورون لسنوات، بالإضافة إلى OP_CAT، هناك أيضًا OP_CTV وAPO وOP_VAULT وتقنيات أخرى لتنفيذ الشروط المقيدة.

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

ما هي "القيود"

العهود، تُترجم إلى الصينية على أنها "قيود"، أحيانًا تُترجم أيضًا باسم "العقد"، وهي آلية يمكنها تحديد شروط معاملات البيتكوين المستقبلية.

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

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

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

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

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

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

التأكد من عقوبة التوقيع المساحي

أحد الأمثلة الأكثر بديهية للبنود المقيدة هو معاملة Babylon المائلة في عملية التوقيع المساحي للبيتكوين.

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

المصدر: تخزين البيتكوين: فتح 21 مليونًا عملات البيتكوين لتأمين اقتصاد إثبات الحصة

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

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

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

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

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

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

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

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

المصدر: https://utxos.org/uses/scaling/

هذا السيناريو هو حالة تطبيق نموذجية مقترحة بواسطة شرط تقييد OP_CTV. يمكن العثور على المزيد من حالات التطبيق على https://utxos.org/uses/. بالإضافة إلى التحكم في الازدحام أعلاه، تسرد الصفحة رهانات الشوكة الناعمة والخيارات اللامركزية وسلاسل القيادة وقنوات الدفعات والقنوات غير التفاعلية والتعدين الخالي من التنسيق غير الموثوق. المجمعات، والخزائن، وحدود العقود المقفلة ذات الوقت المجزأ الأكثر أمانًا (HTLCS)، وما إلى ذلك.

Vault

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

استنادًا إلى تقنية تنفيذ شروط التقييد، يمكن إنشاء تطبيقات فئة vault بسهولة نسبية.

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

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

• إذا تبين أن هذه المعاملة قد سُرقت (أو تم إكراهها) عن طريق "هجوم مفتاح الربط")، قبل إرسال معاملة سحب كتل N، يمكن إرسالها على الفور إلى عنوان آمن آخر (تخزين أكثر أمانًا للمستخدم)

عملية OP_VAULT، المصدر: BIP-345

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

مقارنة بين OP_VAULT وعمليات المخزن الموقعة مسبقًا، المصدر: BIP-345 

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

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

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

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

نظرة عامة فنية على الشروط المقيدة

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

• النوع: النوع العام، النوع الخاص

• طريقة التنفيذ: بناءً على كود التشغيل، بناءً على التوقيع

• العودة: عودية وغير عودية

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

تتضمن بعض تصميمات الجمل المقيدة السائدة ما يلي:

* متكرر: إذا تم دمجه OP_CAT 

تصميم الجمل المقيدة

كما يتبين من المقدمة السابقة، فإن نص Bitcoin الحالي يحد بشكل أساسي شروط إلغاء القفل ولا تحد من كيفية إنفاق UTXO بشكل أكبر. لتنفيذ القيود، علينا أن نفكر بشكل عكسي: لماذا لا يستطيع نص Bitcoin الحالي تنفيذ القيود؟

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

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

لذلك، تركز الأفكار التصميمية لشروط التقييد بشكل أساسي على كيفية تحقيق الاستبطان.

القائمة على كود التشغيل مقابل القائمة على التوقيع

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

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

APO

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

نطاق التوقيع الحالي لـ SIGHASH ومجموعاته لإدخال وإخراج المعاملات (المصدر "إتقان Bitcoin , 2 nd》

كما هو موضح في الشكل أعلاه، بالإضافة إلى ALL الذي ينطبق على جميع البيانات، فإن طريقة التوقيع NONE تنطبق فقط على جميع المدخلات بدون For الإخراج؛ SINGLE يعتمد على هذا، وينطبق فقط على المخرجات التي لها نفس رقم تسلسل الإدخال. بالإضافة إلى ذلك، يمكن أيضًا دمج SIGHASH، وبعد تركيب معدل ANYONECANPAY، فإنه ينطبق فقط على إدخال واحد p style=" text-align: left;">يشير SIGHASH الخاص بـ APO إلى المخرجات فقط، وليس جزء الإدخال. وهذا يعني أنه يمكن إلحاق المعاملات الموقعة مع APO بأي UTXO يستوفي الشروط style="text-align:center">

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

p>

• واحد أو أكثر يمكن إنشاء الحدود مسبقًا للمعاملة

• إنشاء مفتاح عام يمكنه الحصول على توقيع واحد فقط من خلال معلومات هذه المعاملات

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

< p style="text-align: left;">من الجدير بالذكر أنه نظرًا لأن هذا المفتاح العام لا يحتوي على مفتاح خاص مطابق، فمن المؤكد أنه لا يمكن إنفاق هذه الأصول إلا من خلال المعاملات التي تم إنشاؤها مسبقًا. بعد ذلك، يمكننا تحديد وجهة الأصول في هذه المعاملات المنشأة مسبقًا لتنفيذ الشروط المقيدة.

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

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

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

OP_CTV

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

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

في حالة استخدام التحكم في الازدحام المذكورة أعلاه، يمكن للمرسل Alice إنشاء 10 مخرجات وتجزئة هذه المخرجات العشرة، واستخدام الملخص الذي تم إنشاؤه لإنشاء برنامج نصي لصفحة Tapleaf يحتوي على COSHV. يمكن لأليس أيضًا استخدام المفاتيح العامة للمشاركين لتشكيل مفاتيح Taproot الداخلية، مما يسمح لهم بالتعاون في الإنفاق دون الكشف عن مسار البرنامج النصي Taproot.

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

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



المصدر: https://bitcoinops.org/en/newsletters/2019/05 /29 /#propose-transaction-output-commitments

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



المصدر: https://twitter.com/OwenKemeys/status/1741575353716326835

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

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



المصدر: https://twitter.com/OwenKemeys/status/1741575353716326835

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



المصدر: https://twitter.com/OwenKemeys/status/1744181234417140076

منذ تقديمها، شهدت CTV تغيير الاسم من COSHV في عام 2019، وتم تعيينها BIP-119 في عام 2020، وظهرت كلغة برمجة Sapio لإنشاء عقود CTV في عام 2022 بحلول عام 2023، تلقت الكثير من المناقشات والتحديثات والمناقشات حول خطة التنشيط الخاصة بها من المجتمع، ولا تزال واحدة من مقترحات ترقية الشوكة الناعمة التي تتم مناقشتها بشكل متكرر في المجتمع.

OP_CAT

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

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

تتضمن أسس التنفيذ الأخرى أيضًا تحسينات على توقيعات Schnorr: يمكن ضبط شروط توقيع إنفاق البرنامج النصي على الربط بين المفتاح العام للمستخدم والمفتاح العام، ثم if يريد الموقع التوقيع على معاملة أخرى لإنفاق الأموال في مكان آخر، وعليه استخدام نفس الرقم وتسريب المفتاح الخاص. أي أن الالتزام بالـ nonce يتحقق من خلال OP_CAT، وبالتالي ضمان صحة المعاملة الموقعة.

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

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

ولكن هل لن تحدث مشكلة انفجار المكدس المذكورة أعلاه إذا تمت إعادة تمكين OP_CAT الآن؟ نظرًا لأن اقتراح OP_CAT الحالي يتضمن فقط تمكينه في برنامج Tapscript، مما يحد من حجم كل عنصر مكدس بما لا يزيد عن 520 بايت، فلن تنشأ مشكلة انفجار المكدس السابقة. يعتقد بعض المطورين أيضًا أن الحظر المباشر الذي فرضه ساتوشي على OP_CAT قد يكون قاسيًا للغاية. ومع ذلك، نظرًا لمرونة OP_CAT، لا يمكن حاليًا استنفاد بعض سيناريوهات التطبيق التي قد تؤدي إلى ثغرات أمنية.

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

الاستنتاج

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

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

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

شكرًا لأجيان وفيشر وبن لمراجعتهم واقتراحاتهم بشأن هذه المقالة!

المواد المرجعية
https://utxos.org/

https:/ /bitcoincovenants.com/

مجموعة من الموارد المتعلقة بالعهود:

https:/ /Gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

https://anyprevout.xyz/

BIP 345 : اقتراح OP_VAULT:https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/

https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf

https: //maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/

OP_CAT:

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN- 2024-0001.md

خدع CAT وSchnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298