OP_RETURN

تريد يانا إرفاق معلومة بمعاملتها، لا إرسال مبلغ إضافي إلى شخص آخر. لذلك تبدأ أحد المخرجات بتعليمة OP_RETURN. عند محاولة إنفاقه، يؤدي تنفيذ التعليمة إلى فشل التحقق من الشيفرة مهما كان التوقيع. وتسمى شيفرة المخرج تقنيًا scriptPubKey. موضع التعليمة وتنفيذها مهمان: البايت نفسه داخل البيانات المرفقة ليس أمرًا يجري تنفيذه. ووجود OP_RETURN في فرع لم ينفذ لا يعادل وجوده في البداية. لذا لا يكفي العثور على الاسم أو البايت في أي موضع من المعاملة. [1] [5]

يصنف Bitcoin Core الشكل المعتاد ضمن NULL_DATA. ولا يعني الاسم أن المخرج خالٍ من البيانات. تشترط الدالة Solver وجود OP_RETURN في البداية، ثم اجتياز الباقي فحص IsPushOnly، أي احتواءه على تعليمات إدخال البيانات فقط. يمكن بذلك حمل نص أو hash، وهو بصمة قصيرة محسوبة، أو سجل لبروتوكول آخر. لكن التصنيف لا يصادق على معنى الرسالة ولا يضمن وحده قبول المعاملة في قائمة انتظار العقدة. كما لا يمنح السجل تلقائيًا ملكية الملف أو صفة مؤلفه أو أثرًا قانونيًا؛ فتلك ادعاءات تحتاج قواعد وأدلة إضافية. [3]

تحتفظ العقد بمجموعة UTXO، وهي المخرجات التي لم تنفق بعد وما زال استخدامها ممكنًا. عندما يبدأ المخرج بـ OP_RETURN، تعرف مسبقًا أن أحدًا لن ينفقه. يتعرف عليه IsUnspendable ولا تضيفه الدالة AddCoin إلى ذاكرة UTXO المؤقتة. هذا يخفف إدارة الحالة الحالية، ولا يوفر مساحة السجل التاريخي كله: فالمعاملة المؤكدة تبقى في الكتلة، وتنقل بياناتها وتحفظ في النسخ التاريخية. استبعاده من UTXO لا يمحو البيانات. وإذا خصص له أحد مبلغًا، فلا يصبح مكافأة للمعدّن. المبلغ غير قابل للإنفاق، ولا يستعيده توقيع لاحق. [2] [6] [1]

تحدد قواعد الإجماع الكتل التي تعدّها العقدة صحيحة. أما السياسة المحلية فتحدد ما تقبله في mempool، أي قائمة انتظار المعاملات غير المؤكدة، وما تمرره أو تقترحه للتعدين، حمايةً لمواردها. وقد يختار المشغلون إعدادات مختلفة: رفض تمرير معاملة لا يعني أن الكتلة التي تتضمنها تخالف الإجماع. كذلك لا يَعِد قبولها في mempool بتأكيدها. يحدد خيار datacarriersize الحد المحلي لحجم بيانات هذه المخرجات؛ ولا يعيد بمفرده كتابة قواعد صحة الكتل أو يمحو محتوى سبق تأكيده. [8]

كان الإعداد الافتراضي الأقدم، الذي يكثر الاستشهاد به، يسمح بعدد 1 من مخرجات البيانات وبشيفرة حتى 83 بايتًا، عادةً 80 بايتًا للمحتوى والباقي للتعليمات. رفع Bitcoin Core 30.0 القيمة الافتراضية لـ datacarriersize إلى 100000 وسمح بمخرجات بيانات متعددة. يخصم البرنامج طول scriptPubKey كاملًا لكل مخرج من حد مشترك. فهو لا يحسب محتوى الرسالة وحده، ولا يشمل الحقل الخارجي الذي يسجل طول الشيفرة. وتظل قيود المعاملة الأخرى سارية. لذا تعيد القيمة 83 حد الحجم، لا القاعدة السابقة التي سمحت بمخرج واحد فقط. هذه أرقام لتغيير إصدار معين، وليست قانونًا ثابتًا للشبكة كلها. [7] [4] [8]

يمكن ليانا وضع hash المستند في OP_RETURN بدل المستند نفسه. وعندما تعرض الملف الأصلي لاحقًا، يمكن حساب بصمته بالطريقة نفسها ومقارنتها بالسجل. لكن عليها حفظ بايتات الملف الدقيقة وطريقة الحساب؛ فالبصمة لا تحل محل المستند. والتطابق لا يثبت صحة المحتوى أو أن يانا كتبته أو الوقت الدقيق لإنشائه. وقد يربط السجل العام بين هويات، ولا تصبح المعلومات خاصة تلقائيًا بمجرد حساب hash لها. وتعتمد التكلفة على المعاملة كلها والطلب على مساحة الكتل، لا على طول الرسالة وحده. [1] [8]

ثمة استثناء مهم ومحدد بدقة لرسائل التطبيقات المعتادة. يستخدم BIP 141 تعليمة OP_RETURN في coinbase، أول معاملة في الكتلة، لتسجيل witness commitment: ارتباط تشفيري بالبيانات المصاحبة اللازمة للتحقق من المعاملات. يبلغ طول scriptPubKey المطابق 38 بايتًا على الأقل ويبدأ بـ 0x6a24aa21a9ed. إذا تطابقت مخرجات متعددة، يختار صاحب أعلى فهرس، أي آخر مخرج مطابق حسب ترتيبها. وإذا خلت الكتلة من بيانات witness، كان إدراج witness commitment اختياريًا. تتحقق الشبكة هنا من بنية محددة؛ ولا يعني ذلك التحقق من صدق أي نص يأتي بعد OP_RETURN. [9]

اسأل أولًا عن البرنامج والإصدار والإعدادات التي يخصها الحد. ثم ينبغي فك ترميز المعاملة الفعلية وتمييز scriptPubKey عن الحقول المحيطة به في التمثيل بالبايتات. يوضح اختبار mempool_datacarrier.py حالات الحدود في التنفيذ؛ ولا يجري هذا المقال الاختبار بنفسه. اقترح BIP 110 قيودًا إضافية على مستوى الإجماع، لكنه مقترح مغلق، وليس قاعدة يشغّلها خيار datacarriersize. كذلك لا يَعِد وصف إصدار أقدم بتصرف مطابق لكل العقد أو الإصدارات المقبلة. الإعداد المحدد والتأكيد الفعلي للمعاملة معلومتان مختلفتان. [10] [8] [11]