نظرة عامة

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

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

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

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

بيتكوين يحتوي حاليًا على اتفاقيتين ، CSV (التحقق من التسلسل) و CLTV (التحقق من وقت القفل) ، وكلاهما اتفاقيات تعتمد على الوقت وهي أساسية للعديد من حلول التوسع مثل شبكة البرق. يوضح ذلك كيف تعتمد حلول توسع بيتكوين بشكل كبير على الاستدراك والاتفاقيات.

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

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

ctv (checktemplateverify) bip-119

ctv (checktemplateverify) هو اقتراح ترقية بيتكوين يتضمن في BIP-119 الذي حظي بالاهتمام الكبير من المجتمع. يتيح ctv لبرنامج الإخراج تحديد قالب لإنفاق الأموال في صفقة ، بما في ذلك الحقول مثل nversion و nlocktime و scriptsig hash و input count و sequences hash و output count و outputs hash و input index. يتم تنفيذ هذه القيود القالبية عن طريق التزام الهاش ، وعندما تتم إنفاق الأموال ، يتحقق البرنامج من مطابقة قيم الهاش للحقول المحددة في صفقة الإنفاق مع قيم الهاش في البرنامج النصي للمدخلات. يحد من الوقت والطريقة والمبلغ المستقبلي لتلك UTXO.

لاحظ أنه يتم استبعاد معرف txid المدخل من هذا التجزئة. هذا الاستبعاد ضروري، حيث يعتمد معرف txid على القيم في scriptpubkey عند استخدام نوع التوقيع sighash_all الافتراضي في كل من المعاملات التقليدية والمعاملات segwit. سيؤدي تضمين معرف txid إلى وجود تبعية دائرية في التزام التجزئة، مما يجعل من المستحيل بناؤها.

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

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

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

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

apo (sighash_anyprevout) bip-118

يقدم bip-118 نوعًا جديدًا من علم تجزئة التوقيع لـ tapscript، بهدف تسهيل منطق الإنفاق المرن المعروف باسم sighash_anyprevout. يشترك apo و ctv في العديد من التشابهات. عند معالجة المشكلة الدورية بين scriptpubkeys و txids، يقوم النهج apo بتحريض المعلومات الإدخال ذات الصلة وتوقيع الفقرات فقط، مما يسمح للمعاملات بالربط بشكل ديناميكي بمختلف utxos.

منطقيا، عملية التحقق من التوقيع op_checksig (ومشتقاته) تقوم بثلاث وظائف:

1. تجميع أجزاء عملية الإنفاق.
2. تجزئتها.
3. التحقق من أن التجزئة قد تم توقيعها بواسطة مفتاح معين.

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

sighash_all هو علامة sighash الافتراضية ، وهي توقيع جميع النواتج ؛ sighash_none لا يوقع أي نواتج ؛ sighash_single يوقع ناتجًا محددًا. يمكن تعيين sighash_anyonecanpay مع العلامات الثلاثة الأولى لـ sighash. إذا تم تعيين sighash_anyonecanpay ، فسيتم توقيع المدخل المحدد فقط ؛ وإلا ، يجب توقيع جميع المدخلات.

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

وبالتالي، يقترح BIP 118 SIGHASH_ANYPREVOUT. لا يحتاج توقيع APO إلى الالتزام بالإخراج المستهلك UTXO (المعروف بـ prevout) ولكن يحتاج فقط إلى توقيع الإخراجات، مما يوفر مرونة أكبر في التحكم في Bitcoin. من خلال بناء المعاملات مسبقًا وإنشاء التواقيع والمفاتيح العامة للاستخدام مرة واحدة المقابلة، يجب أن تُنفق الأصول المُرسلة إلى تلك العنوان العام للمفتاح من خلال المعاملة المُبنية مسبقًا، مما ينفذ عهدًا. يمكن أيضًا استخدام مرونة APO لإصلاح المعاملة؛ إذا تعثرت معاملة على السلسلة بسبب الرسوم المنخفضة، يمكن إنشاء معاملة أخرى بسهولة لزيادة الرسوم دون الحاجة إلى توقيع جديد. علاوة على ذلك، بالنسبة لمحافظ التوقيع المتعدد، عدم الاعتماد على المداخل المنفقة يجعل العمليات أكثر ملاءمة.

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

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

تتمحور الانتقادات الرئيسية لـ apo حول حاجتها لإصدار مفتاح جديد ، الذي لا يمكن تنفيذه عن طريق التوافق مع الإصدارات السابقة. بالإضافة إلى ذلك ، قد يؤدي نوع تجزئة التوقيع الجديد إلى مخاطر محتملة للإنفاق المزدوج. بعد مناقشات مجتمعية مكثفة ، أضافت apo توقيعات منتظمة فوق آلية التوقيع الأصلية لتخفيف المخاوف الأمنية ، وبالتالي الحصول على رمز bip-118.

op_vault bip-345

يقترح BIP-345 إضافة اثنين من رموز التشغيل الجديدة ، op_vault و op_vault_recover ، والتي عند دمجها مع CTV ، تنفذ عهدا متخصصا يسمح للمستخدمين بفرض تأخير في إنفاق عملات محددة. خلال هذا التأخير ، يمكن "عكس" معاملة تم إجراؤها مسبقا عبر مسار استرداد.

يمكن للمستخدمين إنشاء خزانة عن طريق إنشاء عنوان taproot محدد يجب أن يحتوي على ما لا يقل عن اثنين من البرامج النصية في شجرته: برنامج واحد يحتوي على تعليمة op_vault لتيسير عملية السحب المتوقعة، وبرنامج آخر يحتوي على تعليمة op_vault_recover لضمان استرداد العملات في أي وقت قبل اكتمال عملية السحب.

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

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

تم تصميم bip-345 خصيصًا للأنظمة الخزانة، بالاستفادة من op_vault و op_vault_recover لتوفير وسيلة إيداع آمنة للمستخدمين تستخدم مسار استرداد مؤمن للغاية (مثل محفظة ورقية أو متعددة التوقيعات) كمسار استرداد، مع تكوين تأخير معين للمدفوعات العادية. تراقب أجهزة المستخدمين بشكل مستمر الإنفاق من الخزانة، وإذا حدث تحويل غير متوقع، يمكن للمستخدمين بدء عملية الاسترداد.

يتطلب تنفيذ Vault عبر BIP-345 النظر في مشكلات التكلفة ، خاصة بالنسبة لمعاملات الاسترداد. تشمل الحلول الممكنة CPFP (الطفل يدفع للوالدين) ، والمراسي المؤقتة ، وعلامات تجزئة توقيع sighash_group الجديدة.

tluv (tapleafupdateverify)

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

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

1. تحديث المفتاح العام الداخلي
2. تقليم مسار ميركل
3. إزالة النص الذي يتم تنفيذه حاليًا
4. إضافة خطوة جديدة في نهاية مسار ميركل

تحديدًا، يقبل تلوف ثلاثة مداخل:

1. واحد يحدد كيفية تحديث المفتاح العام الداخلي.
2. واحد يحدد خطوة جديدة لمسار ميركل.
3. واحد يحدد ما إذا كان سيتم إزالة البرنامج النصي الحالي و/أو كم عدد خطوات من مسار ميركل لتقليمه.

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

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

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

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

تُعتبر tluv حلاً محتملاً كحل لحمامات التمويل للطبقة 2 المركزية، على الرغم من أن الاعتمادية في ضبط شجرة التابروت لا تزال تحتاج إلى تأكيد.

مات

يهدف مات (Merkleize جميع الأشياء) إلى تحقيق ثلاثة أهداف: Merkleizing حالة النظام، و Merkleizing البرنامج النصي، و Merkleizing التنفيذ، مما يتيح العقود الذكية العالمية.

1. تحويل الحالة إلى شكل ميركل: يتضمن ذلك بناء شجرة ميركل، حيث يمثل كل عقدة ورقة تجمع القيمة المجمعة لحالة معينة، مع جذر ميركل يجسد الحالة الشاملة للعقد.
2. دمج البرنامج النصي: يشير هذا إلى تكوين صاري باستخدام tapscript ، حيث تمثل كل عقدة ورقة مسارا انتقاليا محتملا للحالة.
3. تنفيذ تقنين: يتم تقنين التنفيذ من خلال الالتزامات التشفيرية وآلية تحدي الاحتيال. بالنسبة لأي وظيفة حسابية، يمكن للمشاركين حساب خارج السلسلة ثم نشر الالتزام، f(x)=y. إذا وجد المشاركون الآخرون نتيجة خاطئة، f(x)=z، فيمكنهم بدء تحدي. يتم إجراء الوساطة من خلال البحث الثنائي، على غرار مبدأ التراكم المتفائل.

تحويل تنفيذ

لتنفيذ مات، يحتاج لغة برمجة البيتكوين إلى الوظائف التالية:

1. فرض إخراج له نص معين (ومبالغها)
2. ربط قطعة من البيانات بمخرج
3. اقرأ البيانات من المدخل الحالي (أو مدخل آخر)

النقطة الثانية حاسمة: البيانات الديناميكية تعني أن يمكن حساب الحالة من خلال بيانات الإدخال التي يقدمها المنفق، حيث يسمح هذا بمحاكاة آلة حالة، قادرة على تحديد الحالة التالية والبيانات الإضافية. ينفذ مخطط مات هذا من خلال العملية المشفرة op_checkcontractverify (op_ccv)، وهو دمج لعمليتي op_checkoutputcontractverify و op_checkinputcontractverify المقترحة سابقًا، باستخدام معلمة العلامات الإضافية لتحديد هدف العملية.

التحكم في مقدار الإخراج: الطريقة الأكثر بساطة هي الانطلاق المباشر؛ ومع ذلك، مقادير الإخراج هي أرقام عشرية بـ 64 بت تتطلب حسابات بـ 64 بت، مما يشكل تعقيدًا كبيرًا في البرمجة النصية لبيتكوين. يعتمد وحدة op_ccv نهجًا للتحقق المؤجل، مثل وحدة op_vault، حيث يتم إضافة جميع المدخلات إلى نفس الإخراج بـ ccv، ويتم جمع مقادير المدخلات معًا كحد أدنى لمقدار هذا الإخراج. يتم تأجيل هذا التحقق لأن هذا التحقق يحدث أثناء عملية المعاملة بدلاً من التقييم النصي للمدخلات.

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

في التطبيق، الأمور بالفعل تحدث. استخدم يوهان توراس هالسيث نصيب op_checkcontractverify من مقترح فرعي مات سوفت لتنفيذelftrace، الذي يسمح لأي برنامج يدعم تجميع risc-v بالتحقق على سلسلة كتل بيتكوين، مما يتيح للطرف داخل بروتوكول العقد الوصول إلى الأموال من خلال التحقق من العقد، مما يجسر بين التحقق الأصلي من بيتكوين.

csfs (op_checksigfromstack)

منذ مقدمة تعليمات apo، تعلمنا أن op_checksig (وعملياته ذات الصلة) مسؤولة عن تجميع المعاملات وتجزئتها والتحقق من التواقيع. ومع ذلك، يُستخلص الرسالة التي يتم التحقق منها من هذه العمليات من تسلسل المعاملة باستخدام التعليمة، ولا يُسمح بتحديد أي رسالة أخرى. بمعنى بسيط، تخدم op_checksig (وعملياته ذات الصلة) للتحقق من خلال آلية التوقيع ما إذا كانت utxo التي يتم إنفاقها كمدخل للمعاملة قد تمت الموافقة على إنفاقها من قبل حامل التوقيع، مما يحمي أمان بيتكوين.

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

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

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

يمكن لـ CSFS تنفيذ أوب كودات مثل CLTV و CSV و CTV و APO وما إلى ذلك، مما يجعلها أوب كود تفتيح متعدد الاستعمالات. وبالتالي، يساعد أيضًا في حلول التوسع لطبقة بيتكوين2. العيب في ذلك هو أنه يتطلب إضافة نسخة كاملة من المعاملة الموقعة على العامود، مما يمكن أن يزيد بشكل كبير من حجم المعاملات المخصصة للتفتيح باستخدام CSFS. وبالمقابل، تحتوي أوب كودات التفتيح ذات الغرض الواحد مثل CLTV و CSV على أدنى حد من التكاليف الإضافية، ولكن إضافة كل أوب كود تفتيح جديد خاص يتطلب تغييرات الإجماع.

txhash (op_txhash)

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

نظرًا للتشابه بين txhash و ctv، فقد نشأت كمية كبيرة من المناقشات داخل المجتمع بشأن الاثنين.

يمكن اعتبار Txhash ترقية عالمية ل CTV ، حيث تقدم نموذجا أكثر تقدما للمعاملات يسمح للمستخدمين بتحديد أجزاء من معاملة الإنفاق بشكل صريح ، ومعالجة العديد من المشكلات المتعلقة برسوم المعاملات. على عكس مدونات العهد الأخرى ، لا تتطلب TXHASH نسخة من البيانات الضرورية في الشاهد ، مما يقلل من متطلبات التخزين ؛ على عكس CTV ، فإن Txhash غير متوافق مع NOP ولا يمكن تنفيذه إلا في tapscript. يمكن أن يكون الجمع بين Txhash و CSFS بمثابة بديل ل CTV و APO.

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

يتوقع توسيع حقل txfieldselector المحدد في مواصفة txhash إلى عمليات التشفير الأخرى ، مثل op_tx.

المقترح المتعلق بـ txhash حاليًا في وضع المسودة على جيثب ولم يتم تعيين رقم له.

op_cat

op_cat هو عملية تشفيرية ملفوفة بالغموض، تم التخلي عنها أصلاً من قبل ساتوشي ناكاموتو بسبب مخاوف أمان، لكنها أثارت حديثًا شديد الاندفاع بين مطوري بيتكوين الأساسيين وحتى دعت ثقافة الميمات على الإنترنت. في النهاية، تمت الموافقة على op_cat تحت bip-347 وقد دعيت الاقتراح bip الأكثر احتمالًا للموافقة في الآونة الأخيرة.

في الواقع ، سلوك op_cat بسيط جدًا: إنه يقوم بدمج عنصرين من الكومة. كيف يمكنه تمكين وظيفة العهد؟

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

كما ذكر سابقا، يمكن لـ csfs، بمساعدة op_cat، تنفيذ مخطط عهد عالمي. في الواقع، بدون csfs، يمكن لـ op_cat ذاتها الاستفادة من هيكل توقيعات شنور لتحقيق استعراض المعاملات.

في توقيعات شنور، الرسالة التي يجب توقيعها تتألف من الحقول التالية:

تحتوي هذه الحقول على العناصر الرئيسية للمعاملة. من خلال وضعها في scriptpubkey أو Witness واستخدام op_cat جنبا إلى جنب مع op_sha256 ، يمكننا إنشاء توقيع Schnorr والتحقق منه باستخدام op_checksig. إذا نجح التحقق، يحتفظ المكدس ببيانات المعاملة التي تم التحقق منها، مما يحقق استبطان المعاملة. يتيح لنا ذلك استخراج أجزاء مختلفة من المعاملة و "التحقق منها" ، مثل مدخلاتها أو مخرجاتها أو عناوينها المستهدفة أو مبالغ Bitcoin المعنية.

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

على النحو الموجز، تسمح لها قابلية التعليم بتقليد أي تعليمات Covenant. تعتمد العديد من تعليمات Covenant على وظيفة op_cat، مما يعزز موقفها بشكل كبير في قائمة الدمج. في النظرية، والاعتماد فقط على op_cat وتعليمات Bitcoin الحالية، نحن متفائلون ببناء BTC ZK Rollup منخفض الثقة. Starknet و Chakra وشركاء النظام البيئي الآخرين يعملون بنشاط على تحقيق هذا الهدف.

استنتاج

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

من غير الممكن بناء طبقة ثانية أكثر مرونة بدون طبقة أساسية مرنة.

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

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

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

يميل apo، op_vault، وtluv نحو التطبيقات المباشرة، ويمكن اختيارهم لتحقيق تطبيقات محددة بطريقة أرخص وأكثر كفاءة. سيفضل محبو شبكة البرق apo لتحقيق التناظر في شبكة البرق؛ أما الراغبون في تنفيذ الخزنة، فسيخدمهم op_vault بشكل أفضل؛ بينما tluv يقدم مزيدًا من الخصوصية والكفاءة لبناء coinpool. op_cat وtxhash أكثر تنوعًا، مع احتمالية أقل للثغرات الأمنية، ويمكن تنفيذ المزيد من حالات الاستخدام عند دمجهم مع أوامر التشغيل الأخرى، ربما على حساب تعقيد النص. قام ctv وcsfs بضبط معالجة سلسلة الكتل، حيث يقوم ctv بتنفيذ المخرجات المؤجلة ويقوم csfs بتنفيذ التواقيع المؤجلة. يبرز matt بإستراتيجيته للتنفيذ التفاؤلي وبراهين الاحتيال، باستخدام هيكل شجرة ميركل لتنفيذ العقود الذكية العالمية، على الرغم من أنه ما زال يتطلب أوامر تشغيل جديدة للقدرات الداخلية.

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

تنصيص:

1. تمت إعادة طبع هذه المقالة من [مرآة]. جميع حقوق النشر مملوكة للمؤلف الأصلي [شاكرا]. إذا كانت هناك اعتراضات على هذه النسخة المعادة طباعتها، يرجى التواصل معبوابة التعلمالفريق وسيتعاملون معه بسرعة.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالات إلى لغات أخرى من خلال فريق تعلم Gate.io. إذا لم يتم الإشارة إليه، فإن نسخ أو توزيع أو نسب المقالات المترجمة ممنوع.