Opcode

تريد آنا الدفع لبطرس. تُعدّ محفظتها المعاملة والتوقيعات اللازمة، ثم تتحقق العقد من حقها في إنفاق العملات المختارة. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. العقدة برنامج يتحقق من المعاملات والكتل ويتواصل مع المشاركين الآخرين في الشبكة. Bitcoin Script هي لغة جزء من هذه الفحوص، وopcode تعليمة واحدة فيها، مثل فحص توقيع. لا تكتب آنا التعليمات يدوياً في الدفع العادي. لكن العقدة لا تستطيع الوثوق باسم مالك أو بعبارة «تم التوقيع»؛ عليها تقييم الشروط. وصحة السكربت ليست إلا جزءاً من التحقق من المعاملة كاملة. [1] [4]

قد ترى في عرض مقروء OP_DUP أو OP_CHECKSIG. هذه أسماء تعليمات للبشر، تمثلها في السكربت رموز بطول بايت. البايت وحدة شائعة لقياس حجم البيانات. وتحتوي أجزاء أخرى على بيانات مثل مفتاح عام. يُستخدم المفتاح العام للتحقق من التوقيعات، ولا يلزم إبقاؤه سرياً. تحدد تعليمات عائلة OP_PUSHDATA عدد البايتات التالية التي تُدرج كبيانات. لا تُنفذ البايتات داخل تلك البيانات مرة أخرى كتعليمات. تخيل الفرق بين عبارة «أضف الملح» في وصفة وبين المكوّن الذي تضعه في الوعاء. [1] [2]

تخيل رزمة أوراق تأخذ منها الورقة العليا. هكذا يعمل مكدّس السكربت الأساسي. تنسخ OP_DUP العنصر الأعلى، وتحذفه OP_DROP. إذا نفذت OP_DUP ثم OP_DROP على مكدّس غير فارغ، عاد إلى محتواه الأصلي. لم تضاعف العملات؛ نسخت بيانات عمل فقط. قد يفشل التقييم إن غاب عنصر مطلوب. كما أن ترتيب العناصر وترميزها الدقيق مهمان. [1]

تأخذ OP_EQUAL العنصرين الأعلى، وتقارن بايتاتهما، وتستبدلهما بنتيجة التطابق. تفشل OP_EQUALVERIFY فوراً إن اختلفا؛ وإن تطابقا تتابع دون إبقاء النتيجة في المكدّس. لا تتحقق أي منهما وحدها من توقيع. يستطيع أي شخص تقديم نسختين متطابقتين من مفتاح عام. يلزم فحص التوقيع المناسب لإثبات أن شخصاً استطاع توقيع الرسالة المطلوبة. [1] [4]

تتحقق OP_CHECKSIG من توقيع باستخدام مفتاح عام ورسالة مبنية من المعاملة، دون كشف المفتاح الخاص. المفتاح الخاص قيمة عددية سرية تُستخدم لإنشاء هذا التوقيع. يحدد إعداد sighash الأجزاء التي يغطيها التوقيع؛ ليست كل الأوضاع توقيعاً على كل شيء. تستخدم السكربتات الأقدم وSegWit من النسخة 0 خوارزمية توقيع اسمها ECDSA. أما Tapscript، قواعد سكربتات Taproot، فيستخدم خوارزمية أخرى اسمها Schnorr للمفاتيح المعتادة بطول 32 بايت. لا يكفي اسم التعليمة وحده دون هذا السياق. [1] [3]

قد يسمح الشرط بالإنفاق المعتاد أو بمسار بديل للاستعادة. تختار OP_IF وOP_ELSE فرعاً بحسب قيمة من المكدّس، وتغلق OP_ENDIF الجزء الشرطي. لا تتضمن Bitcoin Script حلقات برمجية عامة تتكرر بصورة اعتباطية. لكن هذا لا يجيز تجاهل كل ما يوجد في فرع غير منفذ. تُفحص بعض التعليمات أثناء قراءة السكربت؛ فنوعها ونسخة القواعد مهمان. [1] [3]

يمكن لـ CLTV، أي OP_CHECKLOCKTIMEVERIFY، فرض حد مطلق مثل ارتفاع كتلة محدد، أي موضعها في السلسلة. وتفرض CSV، أي OP_CHECKSEQUENCEVERIFY، مع قواعد عمر المعاملة تأخيراً نسبياً منذ تأكيد المُخرج المنفق. والمُخرج مبلغ استُلم سابقاً مع شروط إنفاقه. تفحص هذه التعليمات حقول المعاملة؛ لا تبدأ مؤقتاً ولا ترسل المال ولا تحل محل التوقيع. يجب في كل تطبيق جمع القفل الزمني المناسب مع بقية الشروط. [7] [8] [9]

قبل قراءة مثال تقني، حدد هل يستخدم سكربتات أقدم أم SegWit أم Tapscript. يضيف Tapscript التعليمة OP_CHECKSIGADD لجمع فحوص التوقيع. في المقابل تفشل OP_CHECKMULTISIG عند تنفيذها، وتتجاهلها هذه القواعد في الفرع غير المنفذ. ليس ذلك تناقضاً في الأسماء، بل اختلاف في بيئات التحقق. قائمة opcodes ليست قطع بناء عالمية يمكن نقلها بلا تفكير بين التنسيقات. [1] [3] [6]

يحجز BIP 342 عائلة OP_SUCCESSx لتوسعات Tapscript المستقبلية. بعد اجتياز الفحوص السابقة، يكفي ظهور تعليمة منها عند فك الترميز لتجاوز الفحوص اللاحقة للسكربت بنجاح، حتى في فرع غير منفذ. ولا يُحسب بايت مماثل بالمصادفة داخل بيانات أُدرجت. هذه مساحة لتغيير القواعد، وليست حماية جديدة مفعّلة بالفعل. وقد لا يحمي شرط يعتمد على معنى مستقبلي غير محدد الأموال كما يتوقع مؤلفه. [1] [3]

تتحقق Full Node من قواعد الصلاحية باستقلال، لكنها قد تفرض شروطاً أشد لقبول المعاملات غير المؤكدة ومشاركتها. مثلاً، يرفض Bitcoin Core v29.0 افتراضياً تمرير معاملات تستخدم تعليمة OP_SUCCESSx في Tapscript، مع أن الإجماع قد يسمح بها في كتلة. عند قراءة مثال، حدد النسخة والبيانات الأولية وما يغطيه التوقيع وحالات الفشل. الصياغة المقروءة لا تثبت أمان المحفظة؛ وفي الاستخدام العادي توكل هذا العمل لبرنامج خضع للمراجعة. [1] [5]