استكشف العهود: كيفية جلب قابلية البرمجة الأصلية إلى Bitcoin

متكرر:متكرر وغير متكرر

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

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

تصميم بنود تقييد العهد

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

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

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

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

المستند إلى كود التشغيل مقابل المستند إلى التوقيع

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

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

APO

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

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

كما هو موضح في الشكل أعلاه، باستثناء أنه ينطبق على جميع البيانات، بالإضافة إلى الكل، تنطبق طريقة التوقيع NONE فقط على جميع المدخلات وليس على المخرجات؛ ويعتمد SINGLE على ذلك وينطبق فقط على المخرجات التي لها نفس رقم تسلسل الإدخال، بالإضافة إلى ذلك، يمكن أن يكون SIGHASH أيضًا أخيرًا، يتم دمجه وتركيبه مع مُعدِّل ANYONECANPAY، وهو ينطبق فقط على إدخال واحد يمكن إرفاق المعاملات الموقعة في وضع APO بأي UTXO يستوفي الشروط

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

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

يمكن إنشاء توقيع واحد فقط من خلال معلومات المفتاح العام لهذه المعاملات< /p>

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

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

يمكننا أن نفهم بشكل أكبر من خلال مقارنة العقود الذكية لـ 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/#proposed-transaction-output-commitments)

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

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

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

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

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

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

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

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

OP_CAT

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

المثال الأكثر مباشرة هو العمليات المتعلقة بأشجار Merkle. يمكن فهم شجرة Merkle على أنها عنصران يتم ربطهما أولاً ثم تجزئتهما. حاليًا، توجد رموز عمليات تجزئة مثل OP_SHA256 في البرامج النصية للبيتكوين، لذلك إذا كان من الممكن استخدام 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 المقترح أو القيود الأخرى التي يمكن برمجتها بناءً على عدد مخرجات ساتوشي بواسطة المعاملة.

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