شرح OP_RETURN في Bitcoin: بيانات nulldata والمخرجات غير القابلة للإنفاق

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

OP_RETURN رمز يفشل التنفيذ عند الوصول إليه. لذلك لا يمكن لمعاملة إنفاق مخرج يبدأ نص قفله بهذا الرمز أن تستوفي النص. يصنف Bitcoin Core هذا المخرج على أنه غير قابل للإنفاق، ويمكنه استبعاده مباشرة من مجموعة UTXO بدلاً من الاحتفاظ بعملة لن يمكن استعمالها. راجع تنفيذ النص في Bitcoin Core 31.1. Bitcoin Core 31.1 script implementation.

عندما تطبق العقدة حداً لناقل البيانات، قد لا يكون القياس لبايتات التطبيق وحدها. يتضمن نص المخرج الخام رمز OP_RETURN وتعليمة دفع البيانات وترميز طولها، إضافة إلى البيانات. قد تنتج عن 80 بايتاً من البيانات سلسلة نصية بحجم 83 بايتاً: بايت للرمز، وبايتان لترويسة OP_PUSHDATA1، و80 بايتاً للمحتوى. لذا تشير إرشادات قديمة عن «80 بايتاً» غالباً إلى البيانات، بينما تقيس الإعدادات الأحدث النص كاملاً.

يفعّل Bitcoin Core 31.1 الخيار -datacarrier افتراضياً، ويضبط -datacarriersize افتراضياً على 100,000 بايت. يجمع هذا الخيار أحجام scriptPubKey الخام لكل مخرجات ناقل البيانات في المعاملة الواحدة. تتشارك مخرجات NULL_DATA المتعددة في السقف نفسه، وتدخل الرموز وترميز الدفع في الحساب. غيّر Core 30.0 الحد القديم البالغ 83 بايتاً للنص إلى 100,000 بايت مجمعة وسمح بمخرجات متعددة؛ وأبقى Core 31.1 ذلك الإعداد. راجع خيارات Core 31.1 وتنفيذ السياسة وملاحظات إصدار 30.0.

يمكن لكل عقدة تعطيل ترحيل ناقل البيانات أو خفض الحد المحلي؛ وقد تستخدم العقد والإصدارات الأخرى إعدادات مختلفة. إذا رفضت عقدة إدراج معاملة في mempool، فقد يعني ذلك فقط أن سياستها المحلية لا ترحّلها، لا أن الإجماع يمنعها. يطبق Bitcoin Core حد البيانات في فحص المعاملات القياسية، ويتحقق من قواعد الإجماع بصورة منفصلة عند التحقق من الكتل. Core consensus transaction checks. See Bitcoin Core 31.1 mempool standardness implementation.

يمكن تخصيص مبلغ لمخرج OP_RETURN، لكنه لا يمكن استعادته ويظل غير قابل للإنفاق. وغالباً ما تخصص المحافظ له قيمة صفرية. إذا خصصت له 1,000 ساتوشي، فلن يتحول ذلك تلقائياً إلى رسم للمعدّن. تظل الرسوم مساوية لمجموع المدخلات مطروحاً منه مجموع كل المخرجات. تستهلك بايتات النص وزن المعاملة وقد تزيد الرسوم عند معدل sat/vB نفسه. راجع دليل رسوم معاملات Bitcoin.

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

توجد بيانات OP_RETURN في scriptPubKey للمخرج عند إنشاء المعاملة. أما بيانات SegWit witness فتسلسل بصورة منفصلة لكل مدخل؛ ويصفها BIP 141 بأنها بيانات مكدس مرتبطة بكل مدخل. وقد يكشف الإنفاق عبر مسار نص Taproot النص وكتلة التحكم في witness المدخل. ويمكن لبرنامج Ordinals تفسير صيغة معينة هناك كنقش وفق اصطلاح تطبيقي، لكن ذلك يختلف عن مخرج nulldata. راجع BIP 141 وBIP 341 و[دليل Ordinals ونقوش Bitcoin](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained).

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