الكأس المقدسة لشبكة الطبقة الثانية من البيتكوين: الاستبطان والعهود

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

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

يوجد حاليًا ثلاثة رموز عمليات رئيسية فقط في نصوص البيتكوين البرمجية التي تدعم الاستبطان: CHECKLOCKTIMEVERIFY و CHECKSEQUENCEVERIFY و CHECKSIG. يحتوي CHECKSIG على العديد من المتغيرات، بما في ذلك CHECKSIGVERIFY و CHECKSIGADD و CHECKMULTISIG و CHECKMULTISIGVERIFY.

العهود هي قيود على كيفية نقل الرموز المميزة. يمكن للمستخدمين تحديد كيفية توزيع رموز UTXOs من خلال العهود، والتي يتم تنفيذ العديد منها باستخدام رموز عمليات الاستبطان. في الوقت الحالي، تصنف Bitcoin Optech الاستبطان تحت إدخالات العهد.

تحتوي البيتكوين حاليًا على عهدين: CSV (CheckSequenceVerify) و CLTV (CheckLockTimeVerify)، وكلاهما عهدان يعتمدان على الوقت ويشكلان أساس العديد من حلول التوسع، مثل شبكة Lightning Network. يشير هذا إلى أن حلول التوسع في البيتكوين تعتمد بشكل كبير على الاستبطان والعهود.

كيفية إضافة شروط إلى التحويلات الرمزية

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

فيما يلي مقترحات رمز العهد التي تمت مناقشتها على نطاق واسع:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify)، المضمنة في BIP-119، هي ترقية بيتكوين محل جدل كبير. تسمح CTV للنصوص البرمجية للمخرجات بتحديد قوالب لإنفاق المعاملات، بما في ذلك حقول مثل nVersion وnLockTime و scriptSig hash و scriptSig hash وعدد المدخلات وتجزئة التسلسلات وعدد المخرجات وتجزئة المخرجات وفهرس المدخلات. يتم تنفيذ قيود القوالب هذه من خلال التزام التجزئة، وستتحقق البرامج النصية للإنفاق المستقبلي مما إذا كانت قيم التجزئة للحقول المحددة في معاملة الإنفاق تتطابق مع تلك الموجودة في البرنامج النصي للإدخال. تحدد هذه القوالب بشكل أساسي وقت وطريقة ومقدار معاملات UTXO المستقبلية.

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

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

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

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

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

أبو ظبي (سيغاش_أنا بريفوت) bip-118

يقترح BIP-118 علامة تجزئة توقيع جديدة لـ tapscript، تسمى SIGHASH_ANYPREVOUT، لتسهيل كتابة منطق إنفاق أكثر مرونة. تتشابه APO و CTV من عدة نواحٍ. ولمعالجة التبعية الدائرية بين مفاتيح البرمجة النصية العامة ومعرّفات TXID، يتمثل حل APO في استبعاد معلومات الإدخال ذات الصلة وتوقيع المخرجات فقط، مما يسمح للمعاملات بالارتباط ديناميكيًا بمعرّفات UTXOs مختلفة.

من الناحية المنطقية، فإن عملية التحقق OP_CHECKSIG (ورموز العمليات المرتبطة بها) لها ثلاث وظائف:

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

يمكن تعديل المحتوى المحدد للتوقيع بشكل كبير، ويتم تحديد حقول المعاملة التي يتم توقيعها بواسطة علامة SIGHASH. وفقًا لتعريف رموز عمليات التوقيع BIP 342، تتضمن علامات SIGHASH_ALL و SIGHASH_NONE و SIGHASH_SINGLE و SIGHASH_SINGLE و SIGHASH_ANYONECANPAY وغيرها. يتحكم SIGHASH_ANYONECANPAY في الإدخال، بينما تتحكم العلامات الأخرى في الإخراج.

SIGHASH_ALL هي علامة SIGHASH الافتراضية التي توقع جميع المخرجات. لا توقع SIGHASH_NONE على أي مخرجات، وتوقع SIGHASH_SINGLE على مخرجات محددة فقط. يمكن تعيين SIGHASH_ANYONYONECANPAY مع الأعلام الثلاثة الأخرى، وإذا تم تعيينها، فإنها توقع على المدخلات المحددة فقط؛ وإلا يجب توقيع جميع المدخلات.

لا يمكن لأي من علامات SIGHASH هذه أن تلغي تأثير المدخلات. حتى علامة SIGHASH_ANYONECANPAY تتطلب الالتزام بمدخل واحد.

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

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

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

بالنسبة للبروتوكولات خارج السلسلة مثل شبكة Lightning Network والأقبية، يقلل APO من الحاجة إلى تخزين الحالة الوسيطة، مما يقلل بشكل كبير من متطلبات التخزين والتعقيد. أكثر حالات الاستخدام المباشر لـ APO هي حالة استخدام APO هي Eltoo، مما يبسّط مصانع القنوات، وبناء أبراج مراقبة خفيفة الوزن وغير مكلفة، والسماح بالخروج من جانب واحد دون ترك حالات خاطئة، مما يعزز أداء شبكة Lightning Network. تستطيع APO محاكاة وظائف CTV، على الرغم من أنها تتطلب تخزينًا شخصيًا للتوقيعات والمعاملات الموقعة مسبقًا، مما يجعلها أكثر تكلفة وأقل كفاءة من CTV.

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

op_vault bip-345

يقترح BIP-345 رمزين تشفيريين جديدين هما OP_VAULT و OP_VAULT_RECOVER، للعمل مع CTV وتنفيذ عهد مخصص يفرض فترة تأخير على إنفاق الرموز المحددة، يمكن خلالها “إبطال” الإنفاق عبر مسار استرداد.

يمكن للمستخدمين إنشاء خزنة عن طريق إعداد عنوان Taproot محدد، بما في ذلك نصين برمجيين على الأقل في MAST: نص برمجي OP_VAULT لتسهيل عملية السحب المتوقعة ونص OP_VAULT_RECOVER لضمان استرداد العملات قبل اكتمال السحب.

كيف تحقق OP_VAULT عمليات السحب الموقوتة القابلة للمقاطعة؟

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

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

تم تصميم BIP-345 للخزائن، مما يتيح للمستخدمين الحصول على مسار استرداد آمن للغاية (محفظة ورقية، وتوقيعات متعددة موزعة) مع تكوين تأخير في الإنفاق للمدفوعات الروتينية. يراقب جهاز المستخدم إنفاق الخزنة باستمرار، مما يسمح بالاسترداد في حالة حدوث تحويل غير مصرح به.

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

TLUV (TapleafUpdateVerify)

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

تتمثل فكرة مخطط TLUV في إنشاء عنوان Taproot جديد بناءً على مدخلات الإنفاق الحالية من خلال رمز تشغيل جديد TAPLEAF_UPDATE_VERIFY، والذي يمكنه تنفيذ واحدة أو أكثر من العمليات التالية:

• تحديث المفتاح العام الداخلي
• تقليم مسار ميركل
• إزالة عقدة الورقة المنفذة حالياً
• إضافة عقدة ورقية جديدة إلى نهاية مسار ميركل

على وجه التحديد، تأخذ TLUV ثلاثة مدخلات:

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

يقوم رمز التشغيل TLUV بحساب مفتاح النص البرمجي النصي المحدّث ويتحقق مما إذا كان الإخراج المطابق للإدخال الحالي قد تم إنفاقه على مفتاح النص البرمجي النصي هذا.

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

يحقق رمز التشغيل TLUV قيود الإنفاق الجزئي من خلال تحديث MAST الأصلي. ومع ذلك، فإنه لا يحقق استبطان كميات المخرجات. لذلك، هناك حاجة إلى رمز تشغيل جديد IN_OUT_AMOUNT، والذي يدفع قطعتين من البيانات إلى المكدس: مبلغ UTXO لهذا المدخل ومبلغ الإخراج المقابل. من المتوقع بعد ذلك أن يستخدم الشخص الذي يستخدم TLUV المشغلات الرياضية للتحقق مما إذا كانت الأموال محفوظة بشكل صحيح في مفتاح البرنامج النصي المحدّث.

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

من المتوقع أن توفر TLUV حلولاً لمجمعات عملات الطبقة الثانية اللامركزية، على الرغم من أن الموثوقية من حيث تعديل مفاتيح Taproot العامة تحتاج إلى مزيد من التأكيد.

مات

تهدف MATT (Merkleize All The Things) إلى تحقيق ثلاثة أهداف: حالة Merkleizing، وحالة Merkleizing، ونصوص Merkleizing، وتنفيذ Merkleizing، وبالتالي تحقيق عقود ذكية عامة.

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

لتحقيق MATT، تحتاج البرامج النصية لبرمجة البيتكوين إلى أن تتمتع بالوظائف التالية:

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

أما النقطة الثانية فهي حاسمة حيث تسمح البيانات الديناميكية بحساب الحالة من خلال بيانات الإدخال التي يقدمها المنفق، ومحاكاة آلة الحالة وتحديد الحالة التالية والبيانات المرفقة. يقترح MATT رمز التشغيل OP_CHECKKCONTRACTVERIFY (OP_CCV)، وهو مزيج من رمزي التشغيل OP_CHECKOUTPUTCONTRACTVERIFY و OP_CHECKINPUTCONTRACTVERIFY المقترحين سابقًا، مع مع معلمة أعلام إضافية لتحديد هدف العملية.

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

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

من الناحية العملية، تحدث الأمور بالفعل. قام يوهان توراس هالسيث بتنفيذ elftrace باستخدام رمز التشغيل OP_CHECKCONTRACTVERIFY من اقتراح الشوكة اللينة MATT، مما يسمح بالتحقق من جميع البرامج التي يدعمها تجميع RISC-V على سلسلة البيتكوين، مما يتيح جسور التحقق الأصلية من البيتكوين لبروتوكولات العقود.

csfs (op_checksigfromstack)

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

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

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

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

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

تجزئة التجزئة (op_txhash)

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

ونظرًا للتشابه بين TXHASH وCTV، فقد كان هناك نقاش مستفيض في المجتمع حول الاثنين.

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

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

من المتوقع أن يتم توسيع حقل TxFieldSelector المعرّف في مواصفات TXHASH ليشمل رموز عمليات أخرى، مثل OP_TX.

إن BIP المتعلقة ب TXHASH هي حاليًا في حالة مسودة على Github ولم يتم تعيين رقم لها بعد.

OP_CAT

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

في الواقع، سلوك OP_CAT بسيط للغاية: فهو يربط عنصرين على المكدس في عنصر واحد. ولكن كيف يمكّن هذا من تمكين وظيفة العقد؟

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

وكما ذكرنا سابقاً، يمكن لـ CSFS استخدام OP_CAT لتحقيق مخطط عام للعقود. في الواقع، حتى من دون CSFS، فإن بنية توقيعات Schnorr تسمح لـ OP_CAT نفسها بتحقيق استبطان المعاملات.

في توقيع شنور، تتكون الرسالة المراد توقيعها من الحقول التالية:

• الإصدار
• لوك تايم
• عدد المدخلات
• عدد المخرجات
• قائمة المدخلات (تتضمن كل منها تجزئة المعاملة السابقة والفهرس وطول النص البرمجي والبرنامج النصي والتسلسل)
• قائمة المخرجات (كل منها يتضمن القيمة وطول النص البرمجي والسيناريو)

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

لمزيد من مبادئ التشفير التفصيلية، راجع مقال أندرو بويلسترا “حيل القط وشنور”.

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

الخاتمة

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

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

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

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

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

تميل APO و OP_VAULT و TLUV نحو التطبيقات المباشرة. يمكن باختيارها تنفيذ تطبيقات محددة بشكل أرخص وأكثر كفاءة. يفضل المتحمسون لشبكة Lightning Network APO لأنها تحقق تناظر LN-Symmetry؛ إذا كنت ترغب في إنشاء خزنة، فمن الأفضل استخدام OP_VAULT؛ لبناء CoinPool، TLUV أكثر خصوصية وكفاءة. تعتبر OP_CAT و TXHASH أكثر عمومية، مع وجود ثغرات أمنية أقل، ويمكنها تحقيق المزيد من حالات الاستخدام من خلال التوليفات مع رموز العمليات الأخرى، وإن كان ذلك على الأرجح على حساب تعقيد النص البرمجي. قامت CTV و CSFS بتعديل نهج معالجة سلسلة الكتل: تقوم CTV بتنفيذ مخرجات متأخرة، وتقوم CSFS بتنفيذ توقيعات متأخرة. تُعد MATT فريدة نسبيًا، حيث تستخدم التنفيذ المتفائل وإثباتات الاحتيال، وتعتمد على بنية Merkle Trie لتحقيق عقود ذكية عامة، على الرغم من أنها لا تزال تتطلب رموز تشغيل جديدة لتوفير قدرات الاستبطان.

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