Bitcoin Script

تتلقى أليس 20 000 sat، أي عشرين ألفًا من أصغر وحدات البيتكوين. لا تفتح الشبكة حسابًا باسمها، بل تنشئ مخرج معاملة: مبلغًا وشرطًا لإنفاقه لاحقًا. وما دام المخرج لم يُنفق، يُسمى UTXO. في الدفعة المعتادة، يتطلب الشرط توقيعًا بالمفتاح المطابق. وعندما تدفع أليس لاحقًا، تختار محفظتها هذا المخرج وتشير إليه بمدخل في معاملة جديدة، ثم تنشئ توقيعًا رقميًا. تستخدم المحفظة المفتاح الخاص دون إرساله إلى أي جهة، ويتحقق الآخرون من التوقيع بالمفتاح العام. معرفة عنوان أليس لاستقبال الأموال لا تكفي. تُسجّل شروط المخرج الأصلي في حقل scriptPubKey، ويحدد Bitcoin Script كيفية التحقق من استيفائها. والعقدة ليست موظفًا يتعرف على أليس، بل حاسوبًا يفحص القواعد. إلى جانب التوقيع، يجب أن تتحقق مثلًا من أن المخرج نفسه لم يُنفق من قبل. ولا تكون المعاملة صالحة إلا بعد استيفاء جميع القواعد المطبقة عليها. [4] [2]

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

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

يأخذ المخرج في P2PKH (Pay to Public Key Hash) عادةً الصيغة OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. ويقدم المدخل التوقيع والمفتاح العام في scriptSig. يفحص التحقق ما إذا كان هاش المفتاح العام يطابق القيمة الموجودة في المخرج، ثم يتحقق من التوقيع. لذلك لا تكفي معرفة العنوان أو المفتاح العام وحدها للإنفاق بهذه الطريقة. تستخدم المفتاح الخاص المحفظة التي توقّع، وليس العقدة التي تفحص المعاملة. [1]

يحفظ P2SH وفق BIP16 هاش السكربت في المخرج. ويقدم المدخل الذي ينفقه redeemScript المطابق، أي السكربت الذي يُكشف عند الإنفاق، مع البيانات المطلوبة. ولا يجوز أن يحتوي scriptSig الخاص به إلا على تعليمات تُدخل البيانات إلى المكدس. تتحقق العقدة أولًا من تطابق الهاش، ثم تقيّم redeemScript مع عناصر المكدس المتبقية. الهاش الصحيح وحده لا يكفي للإنفاق؛ فلا بد أيضًا من استيفاء شروط هذا السكربت. [5]

في SegWit الإصدار 0، تنتقل بيانات التحقق إلى جزء من المعاملة يسمى witness. وهو قائمة من عناصر البيانات، وليس سكربتًا بحد ذاته. يستخدم P2WPKH توقيعًا ومفتاحًا عامًا؛ ويحتوي P2WSH أيضًا على witnessScript يجب أن يطابق هاش SHA256 الخاص به المخرج. في SegWit غير المغلف، يكون scriptSig فارغًا. وعند تغليفه داخل P2SH، لا يحتوي إلا على إدراج برنامج witness المعني؛ أما بيانات التحقق الفعلية فتبقى في witness. [6]

يعتمد التحقق من التوقيع على رسالة تُشتق من المعاملة وفق إجراء محدد. يحدد نمط SIGHASH أجزاء المعاملة التي يحميها التوقيع من التغيير. لذلك لا يصح افتراض أن كل توقيع يغطي المعاملة كلها بالضرورة. يتضمن BIP143 دائمًا مبلغ المخرج الجاري إنفاقه ضمن عمليات التوقيع في SegWit الإصدار 0. يجب أن تعرف المحفظة البيانات الصحيحة والنمط المختار؛ ولا يقيّم Script عند الفحص نية الشخص الموقّع. [7]

يتيح Taproot وفق BIP341 إنفاق مخرج P2TR (Pay to Taproot) بطريقتين. يتحقق مسار المفتاح من توقيع Schnorr بالرجوع إلى المفتاح العام للمخرج، دون كشف سكربت. أما مسار السكربت فيكشف السكربت المختار وكتلة التحكم، المسماة control block، التي تثبت ارتباطه بالمخرج. ولا يلزم كشف السكربتات الأخرى الموجودة في الشجرة. وتعتمد قواعد السكربت المكشوف أيضًا على إصدار الورقة المعنية. [8]

يعرّف BIP342 لغة Tapscript لأوراق Taproot من الإصدار 0xc0. تستخدم تعليمات التوقيع هنا توقيعات Schnorr، ويتيح OP_CHECKSIGADD بناء شرط يتطلب عدة توقيعات. أما OP_CHECKMULTISIG القديم فلا يُسمح بتنفيذه. لا يُطبّق هنا الحد السابق لطول السكربت البالغ 10 000 بايت، ولا حد 201 رمز عملية محسوب وفق القواعد القديمة. يُقيَّد عدد عمليات التوقيع بسقف يُشتق من حجم witness، وتظل حدود المكدس قائمة. لذلك لا يجوز عرض حدود إصدار واحد بوصفها خصائص عامة للغة Script كلها. [9]

تحدد قواعد الإجماع صلاحية الإنفاق داخل الكتلة. والمقصود بمعيارية المعاملة قواعد محلية إضافية لدى العقدة لقبول المعاملات غير المؤكدة في Mempool وتمريرها، وليس عملية وضع المعايير. لذلك قد تكون المعاملة صالحة وفق الإجماع ولا يجري تمريرها عادةً. يستدعي OP_SUCCESSx في Tapscript انتباهًا خاصًا: بعد نجاح الفحوص السابقة، يؤدي التعرف عليه أثناء فك الترميز إلى إنهاء التحقق من السكربت بنجاح قبل التنفيذ المعتاد وفحوص المكدس. هذا مجال مخصص للتوسعات المستقبلية، وليس شرط إنفاق عاديًا وآمنًا. [10] [9]