فهم TXHASH: بروتوكول العهد المتقدم لبيتكوين

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

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

بنية المعاملة: فهم مكونات بيتكوين الأساسية

قبل استكشاف كيفية عمل )، من الضروري فهم المكونات الأساسية للبيانات التي تتكون منها أي معاملة بيتكوين.

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

يساهم كل مدخل بمعلومات محددة للمعاملة. يشير إلى معاملة سابقة عبر TXID ويحدد أي مخرج معين يتم إنفاقه عبر فهرس VOUT. يحمل المدخل أيضًا رقم تسلسل، والذي يخدم غرضين—الإشارة إلى ما إذا كان Replace-by-Fee (RBF) مسموحًا، والتحكم في قيود التوقيت النسبي.

تتبع المخرجات هيكلها الخاص. كل منها يخصص مبلغ ساتوشي معين للمستلم، ويشمل تحديد حجم سكربت القفل، ويحتوي على ScriptPubkey—اللغز التشفيري الفعلي الذي يجب على المنفقين المستقبليين حله للوصول إلى تلك الأموال.

حقل الشاهد (أو ScriptSig للمعاملات غير-SegWit الأقدم) يحتوي على توقيعات الإنفاق لكنه يعمل بشكل منفصل عن قضايا التحقق من (. يثبت هذا التمييز أهميته لفهم سبب تقديم ) لمثل هذا التحقق المرن من المعاملات.

كيف يتيح آلية ( استبطان المعاملة

الابتكار الأساسي في ) يكمن في استبدال نهج CTV الكل أو لا شيء بتحكم دقيق. حيث يلتزم CHECKTEMPLATEVERIFY (CTV) بهيكل معاملة محدد مسبقًا عبر تجزئة واحدة، يقدم ( آلية تسمى TxFieldSelector—وهي آلية تتواصل بدقة حول مكونات المعاملة التي يتم الالتزام بها عبر التجزئة وتلك التي تظل غير مقيدة.

فكر في TxFieldSelector على أنه قناع متطور يُطبق على بيانات المعاملة. كل بت في هذا التسلسل من البايتات ذات الطول المتغير يتوافق مع حقول معينة في المعاملة—أرقام الإصدار، قيم nLocktime، معلمات التسلسل، وهكذا. على مستوى المدخلات، يمكن للمطورين اختيار الالتزام بمعرف المخرج السابق، رقم التسلسل، أو ملحق التابروت. وعلى مستوى المخرجات، يقررون ما إذا كانوا يقيدون ScriptPubkey، أو قيم المبلغ، أو كلاهما، أو لا شيء.

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

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

لماذا يتفوق ( على مقاربات العهد السابقة

يحافظ ) على كل قدرات CTV—تمكين جميع تحسينات المعاملات الموقعة مسبقًا الحالية مع تقليل عبء التنسيق. لكن البروتوكول يوسع هذا الأساس بشكل كبير من خلال مزايا عملية متعددة.

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

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

عند دمجه مع CHECKSIGFROMSTACK (CSFS)، يتيح للمطورين بناء نظام SIGHASH شامل داخل السكربت نفسه. تظل أعلام SIGHASH الحالية في بيتكوين محدودة—SIGHASH_ALL يوقع جميع المدخلات والمخرجات، SIGHASH_NONE يوقع المدخلات بدون مخرجات، وSIGHASH_SINGLE يوقع أزواج المدخلات والمخرجات المطابقة. ولا يسمح أي منها بإضافة مدخلات جديدة دون إبطال التوقيعات. نسخ ANYONECANPAY تقلص النطاق إلى مدخل واحد لكنها لا تزال تقيد مرونة المخرجات.

من خلال “تحميل جانب” TxFieldSelectors مخصصة عبر CSFS، يمكن للمطورين محاكاة أنظمة SIGHASH التي تلتزم التوقيعات بمكونات المعاملة التي يحددونها، دون الاضطرار إلى قبول صرامة نهج SIGHASH التاريخي.

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

فحص التداعيات من الدرجة الثانية ومخاطر البروتوكول

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

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

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

لا يزال التحليل الدقيق لتداعيات من الدرجة الثانية ضروريًا مع استمرار هذا المقترح في رحلته نحو التنفيذ المحتمل.