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

مشتركة في الكتابة بواسطةجيفري هووهاربر لي

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

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

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

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

ما هي "العهود"؟

العهد هو آلية يمكن أن تحدد الشروط على المعاملات المستقبلية للبيتكوين.

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

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

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

لذلك، على نحو مضاد للتوقعات، يجلب هذا المزيد من سيناريوهات التطبيق.

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

ضمان عقوبات الرهن

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

عملية حصة بيتكوين في بابل تتضمن إرسال مستخدميهم لبيتكوين إلى سكريبت خاص على السلسلة الرئيسية مع شرطين للإنفاق:

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

المصدر: تعويض بيتكوين: فتح 21 مليون بيتكوين لتأمين اقتصاد دليل الحصة

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

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

قبل تمكين OP_CTV، سيحتاج Babylon إلى حل مؤقت لتقليد تأثير فرض العهود من خلال جمع العميل والمستخدم معًا.

تحكم الازدحام / التوسيع

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

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

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

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

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

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

صومعة

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

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

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

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

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

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

الخزائن المحسوبة مُسبقًا و OP_VAULT ، المصدر: BIP-345

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

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

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

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

نظرة عامة على العهود

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

• النوع: عام، مقيد
• التنفيذ: استنادا إلى الشفرة العملية، استنادا إلى التوقيع
• التكرار: تكراري، غير تكراري

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

تشمل بعض تصاميم العهود الشهيرة:

تصاميم العهود

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

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

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

لذا تتمحور تصميم العهود أيضًا حول كيفية تنفيذ الاستقراء.

قائم على الشفرة التشغيلية مقابل قائم على التوقيع

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

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

APO

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

نطاق SIGHASH الحالي وتركيباته من التواقيع للمداخل والمخرجات للمعاملات (المصدر: Mastering Bitcoin، الإصدار الثاني)

كما هو موضح أعلاه، بالإضافة إلى ALL، الذي ينطبق على جميع البيانات، يتم توقيع NONE بطريقة تجعله ينطبق فقط على جميع المداخل وليس على المخرجات، ويقوم SINGLE بالاعتماد على ذلك من خلال تطبيقه فقط على المخرجات التي تحمل نفس رقم المدخل. بالإضافة إلى ذلك، يمكن دمج SIGHASH مع معدل ANYONECANPAY المتراكب، لينطبق فقط على مدخل واحد.

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

هذه المرونة هي السبب وراء تنفيذ APO للعهود:

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

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

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

المشكلة في العملية أعلاه، ومع ذلك، هو أن هناكdev@lists.linuxfoundation.org/msg08075.html">تبعية دائرية في الحساب، حيث يحتاج الشخص إلى معرفة الإدخال لتوقيع مُسبق وإنشاء المعاملة.

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

OP_CTV

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OP_CAT

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

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

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

تشمل التطبيقات الأخرى لـ OP_CAT Bistream,توقيعات الشجرة, التواقيع لامبورت المقاومة للكم، الخزائن، وأكثر من ذلك.

OP_CAT نفسه ليس ميزة جديدة، حيث كان موجودًا في أقدم الإصدارات من بيتكوين، ولكن كانمُعَطَّلفي عام 2010 بسبب إمكانية استغلالها من قبل المهاجمين. على سبيل المثال، يمكن أن يتسبب الاستخدام المتكرر لأوب_DUP واوب_CAT بسهولة في تفجير كامل للكأس المكدس عند معالجة مثل هذه السكريبتات، كما هو موضح في هذا عرض.

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

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

استنتاج

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

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

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

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

الشكر الخاص

شكرا Ajian, فيشروبنلمراجعة والاقتراحات!

المراجع

• 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-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/en/topics/op_cat/
• OP_CAT: https://github.com/بيتكوين-inquisition/binana/blob/master/2024/BIN-2024-0001.md
• CAT وحيلة Schnorr: https://medium.com/blockstream/القط-والخدع-سنور-i-faf1b59bd298

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

ابق على اطلاع على آخر أخبار هاشكي كابيتال -

الموقع — https://hashkey.capital/

تويتر — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

بيان:

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

2. تنويه: الآراء والآراء المعبر عنها في هذه المقالة تمثل فقط آراء الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.

3. الإصدارات بلغات أخرى للمقال تمت ترجمتها بواسطة فريق Gate Learn ولم يتم ذكرها في Gate.io، قد لا يُعاد توليف المقال المترجم أو توزيعه أو سرقته.