لغة «بيتكوين سكريبت» هي لغة البرمجة التي تتحكم في كل معاملة على شبكة البيتكوين. وهي لغة بسيطة تعتمد على المكدس، وتحدد الشروط الدقيقة التي يمكن في ظلها إنفاق البيتكوين، وتقوم كل عقدة كاملة على الشبكة بتشغيلها في كل مرة يتم فيها التحقق من صحة معاملة ما. وبدونها، لكان البيتكوين مجرد سجل من الأرقام دون أي آلية لضمان تحديد ملكية كل شيء.
لا يرى معظم المستخدمين لغة البرمجة الخاصة بالبيتكوين بشكل مباشر أبدًا. فمحافظهم تتولى التعامل معها بشكل خفي. ولكن في كل مرة ترسل فيها عملة بيتكوين أو تستلمها، يتم تنفيذ برنامجين صغيرين على آلاف أجهزة الكمبيوتر في وقت واحد، للتحقق من استيفاء شروط الإنفاق. إن فهم كيفية عمل ذلك يفسر الكثير عن سبب تصميم بيتكوين بهذه الطريقة، وما يمكنها وما لا يمكنها فعله مقارنةً بمنصات مثل إيثريوم.
يتناول هذا المقال كيفية عمل «بيتكوين سكريبت»، ويستعرض أنواع المعاملات الرئيسية التي تتيحها، ويشرح ترقية «تابروت» التي أدت إلى تحديث طبقة البرمجة النصية في عام 2021، كما يتناول آخر المستجدات في الجدل الدائر حول رمز التشغيل «covenant» حتى يونيو 2026.
قم بإدارة عملات البيتكوين الخاصة بك بأمان من خلال الحفظ الذاتي تطبيق محفظة Bitcoin.com.
النقاط الرئيسية
- لغة «بيتكوين سكريبت» هي لغة برمجة قائمة على المكدس ومُدمجة في بروتوكول البيتكوين، وتحدد الشروط التي يمكن بموجبها إنفاق أي مخرج بيتكوين.
- تتضمن كل معاملة بيتكوين نصين برمجيين: نص برمجي للقفل (ScriptPubKey) يحدده المستلم، ونص برمجي لفتح القفل (ScriptSig) يقدمه المُصرف. ويجب أن يتم تنفيذ كلا النصين بنجاح حتى تكون المعاملة صالحة.
- تم تصميم «بيتكوين سكريبت» عمدًا بحيث لا يكون كاملاً من منظور تورينج. فهو يخلو من الحلقات، ولا يحتفظ بحالة ثابتة بين عمليات التنفيذ، كما يفرض قيودًا صارمة على حجم النص البرمجي. وهذا يضمن إنهاء كل نص برمجي، وهو ما يُعد ميزة أمنية، وليس قيدًا.
- تطورت لغة البرمجة عبر خمسة تنسيقات رئيسية: P2PK، وP2PKH، وP2SH، وSegWit (P2WPKH/P2WSH)، وTaproot (P2TR)، حيث وسّع كل منها نطاق الإمكانيات مع الحفاظ على التوافق مع الإصدارات السابقة.
- قدمت نسخة «Taproot» (نوفمبر 2021) توقيعات «Schnorr»، ومسارات الإنفاق القائمة على تقنية «MAST» لحماية الخصوصية، ولغة البرمجة النصية «Tapscript» كنسخة محدثة مزودة بآلية مدمجة تتيح إجراء ترقيات مستقبلية بشكل أكثر سلاسة.
- تشمل حالات الاستخدام العملية المبنية على لغة «بيتكوين سكريبت» المحافظ ذات التوقيعات المتعددة، والمعاملات المقفلة زمنياً، وعقود «هاش تايم-لوك» (التي تشكل أساس شبكة «لايتنينغ»)، وخدمات الضمان، وعقود السجلات السرية.
- على عكس العقود الذكية في إيثريوم، فإن «بيتكوين سكريبت» لا تعتمد على الحالة: فكل سكريبت يعمل في عزلة تامة دون أي علم بأي معاملة أخرى. وهذا اختيار هندسي متعمد.
- تعد رموز التشغيل الخاصة بالعقود (covenant opcodes) المجال الأكثر نشاطًا في تطوير «بيتكوين سكريبت» في عام 2026، ولا سيما OP_CTV (BIP-119) وOP_CAT (BIP-347)، والتي ستسمح للبرامج النصية بتحديد الشكل الذي يجب أن تتخذه معاملة الإنفاق. ولم يتم تفعيل أي منهما على الشبكة الرئيسية حتى الآن.
ما هو «بيتكوين سكريبت»؟
لغة Bitcoin Script هي لغة برمجة نصية قائمة على المكدس وخالية من الحالة، مدمجة في بروتوكول البيتكوين. تحتوي كل مخرجات المعاملات على شبكة البيتكوين على نص برمجي للقفل (يُسمى ScriptPubKey) يحدد شروط إنفاق الأموال. ويجب على أي شخص يرغب في إنفاق تلك الأموال تقديم نص برمجي لفتح القفل (يُسمى ScriptSig، أو في معاملات SegWit وTaproot، يُسمى بيانات الشاهد) يستوفي تلك الشروط.
تستمد هذه اللغة بنيتها من لغة «فورث» (Forth)، وهي لغة برمجة بسيطة تعتمد على المكدس تم تطويرها في ستينيات القرن الماضي. وعلى غرار لغة «فورث»، تُقرأ لغة «بيتكوين سكريبت» من اليسار إلى اليمين، وتعمل على بنية بيانات تُسمى المكدس، وتستخدم «التدوين البولندي العكسي» (RPN)، حيث تأتي العوامل بعد المعاملات بدلاً من أن تسبقها. وهي تُنفذ تعليمة واحدة في كل مرة، ولا تحتوي على حلقات، ولا تحتفظ بأي ذاكرة دائمة بين عمليات التنفيذ.
هذه النقطة الأخيرة هي أول ما يلاحظه معظم الناس عند التعرف على لغة «بيتكوين سكريبت» من منظور البروتوكول: فاللغة غير كاملة من حيث تورينج عن قصد. فاللغة الكاملة من حيث تورينج قادرة على إجراء أي عملية حسابية شريطة توفر الوقت والموارد الكافيين. أما لغة «بيتكوين سكريبت»، فهي غير قادرة على ذلك بحكم تصميمها، وتُعد أسباب هذا الاختيار ذات أهمية كبيرة في كيفية عمل الشبكة.
كيفية عمل لغة برمجة «بيتكوين سكريبت»: نموذج المكدس
لفهم كيفية عمل «بيتكوين سكريبت»، عليك فهم مفهوم «المكدس». المكدس هو بنية بيانات تعمل وفقًا لمبدأ «آخر ما يدخل، أول ما يخرج» (LIFO). تخيل كومة من الأطباق: لا يمكنك إضافة أو إزالة أي شيء إلا من الأعلى. في «بيتكوين سكريبت»، يتم دفع البيانات إلى المكدس، وتقوم رموز العمليات (opcodes) بمعالجة ما يوجد في قمة المكدس.
عندما تقوم إحدى عقدات البيتكوين بالتحقق من صحة معاملة ما، فإنها تُشغِّل نصين برمجيين بالتتابع:
- نص برمجي لإلغاء التشفير (ScriptSig أو الشاهد) التي يقدمها الشخص الذي ينفق العملات. ويؤدي ذلك إلى إدراج البيانات في المكدس، وعادةً ما تكون هذه البيانات عبارة عن توقيع رقمي ومفتاح عام.
- نص القفل (ScriptPubKey) مرتبطة بإنفاق المخرجات. ويحتوي هذا على رموز العمليات التي تعمل على بيانات المكدس وتتحقق من استيفاء شروط الإنفاق.
إذا تم تنفيذ البرنامج النصي دون أخطاء وترك قيمة غير صفرية (TRUE) في المكدس في النهاية، فإن المعاملة تكون صالحة. أما إذا فشل التنفيذ أو ترك قيمة FALSE، فإن العقدة ترفض المعاملة ولا يتم إدراجها أبدًا في كتلة.
يتم تنفيذ هذا البرنامج النصي بشكل لا يعتمد على الحالة على الإطلاق. فالبرنامج النصي لا يملك أي معلومات عن أي معاملة سابقة، ولا يدرك الأرصدة الحالية، ولا يحتفظ بأي ذاكرة تستمر بعد انتهاء تشغيله. يتم تشغيل كل برنامج نصي من الصفر، وبشكل منعزل، في كل مرة.
خطوة بخطوة: معاملة P2PKH قياسية
يُعد «الدفع إلى تجزئة المفتاح العام» (P2PKH) النوع الأصلي لمعاملات البيتكوين، وهو قيد الاستخدام منذ عام 2009. تبدأ عناوين P2PKH بالرقم «1». وفيما يلي شكل كل من ScriptPubKey وScriptSig في الواقع العملي:
نص برمجي لإلغاء التشفير (ScriptSig):
<التوقيع> <المفتاح العام>
نص التشفير (ScriptPubKey):
OP_DUP OP_HASH160 <تجزئة المفتاح العام> OP_EQUALVERIFY OP_CHECKSIG
عندما تقوم العقدة بضم العمليتين وتنفيذهما معًا، تسير عمليات المكدس خطوة بخطوة:
- يتم إدراج التوقيع والمفتاح العام من ScriptSig في المكدس
OP_DUPيُكرر المفتاح العام الموجود في أعلى المكدسOP_HASH160يقوم بحساب التجزئة للنسخة المكررة (SHA-256 متبوعًا بـ RIPEMD-160)، مما ينتج عنه تجزئة بحجم 20 بايت- يتم إدراج تجزئة المفتاح العام المستمدة من البرنامج النصي الخاص بالقفل في المكدس
OP_EQUALVERIFYيتحقق من تطابق التجزئتين. وفي حالة عدم تطابقهما، يتوقف التنفيذ وتفشل المعاملة.OP_CHECKSIGيتحقق من صحة التوقيع بالنسبة للمفتاح العام
إذا تم اجتياز جميع الخطوات بنجاح، تنتهي المكدس بقيمة TRUE ويتم تحرير الأموال. تستغرق العملية برمتها أجزاء من الألف من الثانية، وتُنفَّذ بنفس الطريقة على كل عقدة في الشبكة.
شرح أكواد التشغيل في بيتكوين
رموز التشغيل الخاصة بالبيتكوين هي الأوامر الفردية التي يتكون منها البرنامج النصي. يتكون كل رمز من بايت واحد، مما يوفر 256 خانة ممكنة لرموز التشغيل. ومن بين هذه الخانات، هناك حوالي 80 خانة نشطة حاليًا على الشبكة الرئيسية. أما البقية فهي إما محجوزة أو معطلة أو مخصصة لآلية التوافق مع الإصدارات المستقبلية OP_SUCCESS التي تم تقديمها مع Tapscript.
تنقسم رموز التشغيل إلى عدة فئات:
- رموز العمليات الخاصة بدفع البيانات إدراج قيم مثل المفاتيح العامة والتوقيعات والتجزئات في المكدس
- رموز العمليات الحسابية إجراء عمليات الجمع والطرح والمقارنة. وتجدر الإشارة إلى أن عمليتي الضرب والقسمة معطلتان.
- رموز العمليات التشفيرية تشمل OP_SHA256 وOP_HASH160 وOP_SHA1 لعملية التجزئة، وOP_CHECKSIG للتحقق من التوقيع
- رموز العمليات الخاصة بالتحكم في التدفق تمكين المنطق الشرطي: OP_IF، OP_ELSE، OP_ENDIF، OP_NOTIF
- رموز العمليات الخاصة بمعالجة المكدس وتشمل OP_DUP (نسخ العنصر العلوي)، وOP_DROP (إزالة العنصر العلوي)، وOP_SWAP (تبديل العنصرين العلويين)
قام ساتوشي ناكاموتو بتعطيل العديد من رموز العمليات (opcodes) في عام 2010 بعد اكتشاف ثغرات أمنية في تطبيقاتها الأصلية. وتشمل هذه الرموز OP_CAT (ربط عنصرين في المكدس)، وOP_MUL (الضرب)، وOP_DIV (القسمة). وقد كان لغيابها عواقب دائمة على ما يمكن لـ «بيتكوين سكريبت» التعبير عنه، وتشمل العديد من مقترحات تحديث البيتكوين التي كانت موضع نقاش نشط في عام 2026 مسألة إعادة تمكين بعض هذه الأوامر.
للاطلاع على مرجع أكواد التشغيل الكامل، بما في ذلك القيم السداسية العشرية والأوصاف، يرجى الرجوع إلى صفحة «Bitcoin Wiki Script» هو المصدر الموثوق.
لماذا يُعد عدم الاكتمال التورينجي ميزة
التفسير المعتاد هو أن لغة «بيتكوين سكريبت» لا تحتوي على حلقات، وبالتالي يُضمن انتهاء عمل البرامج النصية، مما يحمي الشبكة من التنفيذ اللانهائي. وهذا صحيح، لكنه لا يعبر عن جوهر الموضوع بشكل كافٍ.
الحجة الأعمق تتعلق بـ«مساحة الهجوم». فاللغة الكاملة من حيث تورينج قادرة على التعبير عن أي عملية حسابية. وهذه القدرة التعبيرية هي أيضًا المساحة التي تكمن فيها الأخطاء البرمجية. وقد تسببت لغة «سوليديتي» (Solidity) الخاصة بشبكة إيثريوم في بعض أكثر الثغرات البرمجية تكلفةً في التاريخ. استغل اختراق DAO عام 2016 ثغرة «إعادة الدخول» في عقد ذكي وتسبب في خسائر بلغت حوالي 60 مليون دولار بالأسعار السائدة آنذاك، مما أدى في النهاية إلى انقسام صعب مثير للجدل في شبكة إيثريوم. وقد شهد النظام البيئي الأوسع للتمويل اللامركزي (DeFi) استنزاف مئات الملايين من الدولارات من خلال استغلال الثغرات في العقود الذكية على مدى عدة سنوات.
تجعل لغة برمجة «بيتكوين سكريبت» هذه الفئة من الهجمات مستحيلة من الناحية الهيكلية. فلا يمكنك كتابة سكريبت بيتكوين يستدعي سكريبتات أخرى، أو يدور في حلقة حتى يتغير شرط ما، أو يخزن الحالة بين المعاملات. كل سكريبت هو برنامج محدود النطاق وقابل للتنفيذ وقابل للفحص. يبلغ الحد الأقصى لحجم السكريبت 10,000 بايت. ويبلغ الحد الأقصى لعدد رموز العمليات غير المتعلقة بـ«push» في كل سكريبت 201 رمزًا. ويمكن للمُصادق دائمًا حساب تكلفة التنفيذ في أسوأ الحالات قبل تشغيل السكريبت.
بالنسبة لشبكة تبلغ قيمتها مئات المليارات من الدولارات، فإن هذه القدرة على التنبؤ تساوي أكثر من المرونة التي تتنازل عنها. تحل «إيثريوم» مشكلة الحساب غير المحدود من خلال «حدود الغاز»، حيث تفرض رسومًا على المستخدمين مقابل كل رمز تشغيل يتم تنفيذه، وتوقف البرامج النصية التي تنفد ميزانيتها. وهذا الأسلوب فعال، لكنه يجلب معه تعقيداته الخاصة وأنماط الفشل الخاصة به. أما «بيتكوين» فتتجنب هذه المشكلة تمامًا بحكم تصميمها.
ومع ذلك، فإن عبارة «غير كاملة من منظور تورينج» لا تعني «غير قادرة على التعامل مع المنطق المعقد». تدعم لغة «بيتكوين سكريبت» متطلبات الإنفاق متعدد الأطراف، والشروط المرتبطة بالزمن، وكشف الصور الأصلية للتجزئة، بالإضافة إلى مزيج من كل هذه العناصر. وشبكة «لايتنينغ»، التي توجه ملايين المدفوعات يوميًا، مبنية بالكامل على العناصر الأساسية للغة «بيتكوين سكريبت».
أنواع البرامج النصية: التطور من P2PKH إلى Taproot
شهدت طبقة البرمجة النصية في البيتكوين تطوراً كبيراً منذ عام 2009، حيث أدخلت كل ترقية تنسيقاً جديداً للمعاملات مع الحفاظ على التوافق مع جميع الإصدارات السابقة.
P2PK (الدفع إلى المفتاح العام، 2009)
الصيغة الأصلية، التي استُخدمت في أول معاملات البيتكوين، بما في ذلك الدفعة التي أرسلها ساتوشي إلى هال فيني في الكتلة رقم 170. حيث كانت الأموال تُربط مباشرةً بمفتاح عام كامل بدلاً من هاش المفتاح. نادرًا ما يُستخدم هذا التنسيق في المعاملات الحديثة اليوم لأنه يكشف عن المفتاح العام على السلسلة قبل الإنفاق، وهو ما يُعتبر إجراءً أمنيًا أضعف مقارنةً بتجزئة المفتاح أولاً.
P2PKH (الدفع إلى تجزئة المفتاح العام، 2009)
الصيغة القياسية منذ أكثر من عقد من الزمن. تعمل صيغة P2PKH على ربط الأموال بقيمة تجزئة للمفتاح العام بدلاً من المفتاح نفسه، مما يحافظ على سرية المفتاح العام حتى لحظة الإنفاق، وينتج عنوانًا أقصر يبلغ 20 بايت، ويشكل الأساس لجميع العناوين التي تبدأ بـ «1». وفقًا لبيانات السلسلة الصادرة عن Unchained (أبريل 2026)، تحتفظ عناوين P2PKH حاليًا بنحو 43% من إجمالي المعروض من البيتكوين المُعدن.
P2SH (Pay-to-Script-Hash، 2012، BIP 16)
تم طرح P2SH عبر «فورك ناعم» في 1 أبريل 2012، حيث نقل عبء نصوص الإنفاق المعقدة من المرسل إلى المستلم. فبدلاً من تضمين نص قفل كامل في المخرجات، تلتزم مخرجات P2SH بتجزئة مكونة من 20 بايت لـ«نص الاسترداد». ولا يتم الكشف عن النص الكامل إلا عند إنفاق العملات. وقد جعل هذا نظام التوقيعات المتعددة عمليًّا للمستخدمين العاديين: فلم يعد إعداد التوقيعات المتعددة بنظام 2 من 3 يتطلب أن تكون جميع المفاتيح العامة الثلاثة مرئية للمرسل وقت الدفع. تبدأ عناوين P2SH بالرقم «3».
للحصول على شرح تفصيلي لكيفية عمل التحقق من صحة P2SH على مستوى البروتوكول، دليل المعاملات على موقع developer.bitcoin.org يشرح آلية عمل «Redeem Script» خطوة بخطوة.
P2WPKH و P2WSH (SegWit الأصلي، 2017، BIP 141)
تم تفعيل ميزة «الشاهد المنفصل» (Segregated Witness) في أغسطس 2017 عند الكتلة رقم 481,824، حيث تم نقل بيانات التوقيع من داخل نص المعاملة الرئيسي إلى بنية «شاهد» منفصلة. وتخضع بيانات «الشاهد» لتخفيض في الوزن بنسبة 75٪، مما يجعل معاملات SegWit أرخص بشكل ملحوظ. تبلغ وزن معاملة P2WPKH القياسية ذات المدخل الواحد والمخرجين حوالي 141 بايت افتراضي، مقارنة بـ 226 بايت افتراضي للمعاملة المكافئة من نوع P2PKH، وفقًا لـ تحليل أنواع عناوين البيتكوين الذي أجرته شركة «سبارك» اعتبارًا من مارس 2026. كما عالج SegWit مشكلة قابلية التلاعب بالمعاملات، والتي كانت شرطًا أساسيًّا لإنشاء شبكة Lightning Network. تبدأ عناوين SegWit الأصلية بـ "bc1q."
P2TR (Pay-to-Taproot، 2021، BIPs 340/341/342)
تم تفعيل Taproot في نوفمبر 2021 عند الكتلة رقم 709,632، وهو أهم تحديث لطبقة البرمجة النصية في بيتكوين منذ SegWit. وقد أدخل هذا التحديث توقيعات Schnorr، ونوعًا جديدًا من المخرجات يدعم MAST، ولغة البرمجة النصية Tapscript كنسخة محدثة. تبدأ عناوين Taproot بـ «bc1p».
Taproot و Tapscript: كيف تغيرت لغة البرمجة «سكريبت» الخاصة ببيتكوين في عام 2021
لا يُعد «Taproot» تغييرًا واحدًا. بل هو ثلاثة مقترحات لتحسين البيتكوين تم تصميمها معًا وتفعيلها في وقت واحد.
BIP 340: توقيعات شنور
استخدمت عملة البيتكوين في البداية خوارزمية ECDSA (خوارزمية التوقيع الرقمي للمنحنى الإهليلجي). وقد اختار ساتوشي هذه الخوارزمية جزئيًا لأن توقيعات شنور كانت محمية ببراءة اختراع في ذلك الوقت. وقد انتهت صلاحية تلك البراءة في عام 2008، وأدخلت تحديث «تابروت» أخيرًا توقيعات شنور إلى البروتوكول.
تتميز توقيعات شنور بحجم أصغر يبلغ 64 بايت، مقارنةً بـ 71-73 بايت في حالة ECDSA. والأهم من ذلك، أنها تدعم تجميع المفاتيح من خلال مخطط يُسمى MuSig2. يتيح تجميع المفاتيح لعدة موقّعين دمج مفاتيحهم وتوقيعاتهم الفردية في مفتاح وتوقيع مجمّعين واحدين لا يمكن تمييزهما على السلسلة عن عملية دفع عادية ذات توقيع واحد. يبدو الإنفاق من محفظة متعددة التوقيعات بنظام «2 من 3» عبر مسار المفتاح التعاوني في Taproot مطابقًا للدفع القياسي على البلوكشين. وهذا يمثل مكسبًا حقيقيًّا في الخصوصية لأي شخص يحتفظ بعملة البيتكوين في ترتيب حفظ معقد.
BIP 341: الدفع مقابل التبني لـ Taproot و MAST
تقدم P2TR نوعًا جديدًا من المخرجات يتضمن مسارين للإنفاق:
- أ المسار الرئيسي الإنفاق باستخدام توقيع شنور، الذي يُستخدم عندما تتفق جميع الأطراف وترغب في اتباع المسار الأبسط والأرخص
- أ مسار البرنامج النصي الإنفاق باستخدام MAST (شجرة النحو المجردة المُمركلية، وهي تطبيق Taproot لهذا المفهوم)
تتيح تقنية MAST لمخرج واحد أن يرتبط بشجرة تضم عدة نصوص إنفاق عبر جذر ميركل. وعند الإنفاق، لا يُكشف على السلسلة سوى الشرط المحدد الذي تم استخدامه فعليًّا. أما جميع مسارات الإنفاق المحتملة الأخرى في الشجرة، فتظل مخفية بشكل دائم. بالنسبة للمستخدم الذي قام بتكوين سياسة إنفاق معقدة، على سبيل المثال «يمكنني الإنفاق بشكل عادي، أو يمكن لاثنين من أصل ثلاثة أمناء الإنفاق بعد ستة أشهر، أو يمكن لمفتاح الاسترداد الإنفاق بعد عامين»، فإن المسار الذي يتم تنفيذه فعليًّا هو الوحيد الذي يظهر على سلسلة الكتل.
بحلول عام 2024، ارتفعت حصة Taproot من معاملات البيتكوين إلى حوالي 42٪، مدفوعةً بشكل كبير بأنشطة التسجيل في Ordinals وBRC-20 وفقًا لبيانات Glassnode التي استشهدت بها Spark في مارس 2026. وقد تقلبت هذه الحصة تبعًا لظروف السوق منذ ذلك الحين، لكن البنية التحتية أصبحت الآن معيارًا قياسيًا في جميع المحافظ والبورصات الرئيسية. صفحة موضوع «Taproot» على موقع Bitcoin Optech يتتبع التطورات الجارية في البروتوكول المتعلق بـ Taproot.
BIP 342: نص البرنامج
Tapscript هي لغة البرمجة النصية المُحدَّثة المستخدمة في عمليات الإنفاق عبر مسار البرنامج النصي (script-path) ضمن Taproot. وهي تشترك في معظم رموز العمليات (opcodes) مع لغة Bitcoin Script القديمة، لكنها تُدخل عليها عدة تغييرات مهمة:
OP_CHECKMULTISIGوOP_CHECKMULTISIGVERIFYأصبحت قديمة. كان رمز التشغيل القديم الخاص بالتوقيعات المتعددة (multisig) يعاني من خلل فني كان يتطلب دفع عنصر وهمي إلى المكدس كحل بديل. وقد أزال Tapscript هذا الخلل واستبدله بـOP_CHECKSIGADD، والتي تتحقق من توقيعات شنور واحدًا تلو الآخر وتقوم بتجميع العدد الإجمالي. وبذلك تصبح مخططات التوقيعات المتعددة ذات العتبة أكثر بساطة وأقل تكلفة في التنفيذ.- تم إلغاء حدود حجم البرامج النصية لكل ورقة MAST. ويمكن أن يكون حجم البرامج النصية الفردية داخل فرع Taproot كبيرًا بقدر ما تشاء.
- رموز التشغيل OP_SUCCESS تُعد التغييرات الأكثر تطلعًا للمستقبل. ففي لغة البرمجة القديمة (Legacy Script)، يؤدي مواجهة رمز تشغيل غير مُعرَّف إلى فشل البرنامج النصي. أما في Tapscript، فإن رموز التشغيل ضمن نطاق OP_SUCCESS تؤدي إلى نجاح البرنامج النصي دون شروط. يمكن للـ«الشوكات اللينة» المستقبلية أن تُعيّن سلوكًا فعليًّا لهذه الرموز التشغيلية من خلال إضافة قيود على ظروف نجاحها، دون الحاجة إلى إصدار جديد من البرنامج النصي أو دورة إعادة نشر كاملة عبر النظام البيئي. يمكن إضافة قدرات جديدة إلى طبقة البرمجة النصية في بيتكوين بطريقة أكثر سلاسة من أي وقت سابق في تاريخ البروتوكول.
مينيسكريبت
إلى جانب Tapscript، أصبح مشروع ذو صلة يُدعى Miniscript يكتسب أهمية متزايدة بالنسبة للمطورين. Miniscript هو أسلوب منظم لكتابة مجموعة فرعية من لغة Bitcoin Script يمكن تحليلها وتركيبها وتوقيعها بشكل عام. فبينما تتطلب لغة Script الأولية إنشاءً يدويًّا ويصعب تدقيقها، يمكن التحقق من صحة نصوص Miniscript تلقائيًّا ودمجها في سياسات أكبر. ولا يوسع هذا نطاق ما يمكن لـ Script القيام به، بل يجعل ما تقوم به بالفعل أكثر سهولةً بشكل ملحوظ للمطورين الذين يعملون على إنشاء المحافظ وأدوات الحفظ.
ما تتيحه لغة «بيتكوين سكريبت»: حالات الاستخدام في العالم الواقعي
أنواع المعاملات التالية نشطة اليوم على الشبكة الرئيسية لبيتكوين، وجميعها مبنية على عناصر «بيتكوين سكريبت» الأساسية:
محافظ التوقيعات المتعددة (multisig) تتطلب «M من N» مفتاحًا خاصًا للموافقة على عملية إنفاق. قد تتطلب خزانة الشركة موافقة 3 من أصل 5 لإجراء أي سحب. وقد يستخدم الزوجان نظام «2 من أصل 2» للمدخرات المشتركة. وبفضل تقنية Taproot وتجميع مفاتيح Schnorr، أصبحت عمليات الإنفاق التعاونية متعددة التوقيعات على السلسلة لا يمكن تمييزها عن المعاملات القياسية ذات التوقيع الفردي.
المعاملات المقيدة زمنياً استخدم OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify، أو CLTV) و OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify، أو CSV) لمنع تحويل الأموال قبل بلوغ ارتفاع معين للكتلة أو انقضاء فترة زمنية معينة. وتشمل التطبيقات التخطيط للوراثة، وجداول استحقاق الرموز المميزة للموظفين، وآليات الادخار الإجباري، ومعاملات الغرامات المستخدمة داخل قنوات شبكة Lightning Network.
عقود التشفير المقفلة زمنياً (HTLCs) الجمع بين شرط الصورة الأصلية للتجزئة وقفل زمني. وتعمل شروط الإنفاق على النحو التالي: يجب الكشف عن الصورة الأصلية لهذه التجزئة قبل بلوغ ارتفاع الكتلة هذا، وإلا تعود الأموال إلى المرسل. وتُعد HTLCs العنصر الأساسي لشبكة Lightning Network، حيث تتيح توجيه المدفوعات دون الحاجة إلى الثقة عبر سلاسل القنوات بين الأطراف التي لا تربطها علاقة مباشرة.
الحساب المعلق تعمل هذه الترتيبات على تجميد الأموال في نصوص P2SH أو Taproot، مما يتطلب موافقة عدة أطراف قبل الإفراج عنها، وعادةً ما يكون هناك وسيط خارجي يمتلك مفتاح الفصل في حالة التعادل.
عقود السجلات السرية (DLCs) استخدام توقيعات محول شنور القائمة على أوراكل لتمكين تسوية العقود المالية باستخدام بيانات من العالم الحقيقي، مثل بيانات الأسعار أو نتائج الأحداث، دون الحاجة إلى أن تتولى أوراكل حراسة أي أموال. تعمل عقود DLC حاليًا على الشبكة الرئيسية لبيتكوين، وتُستخدم في منتجات الخيارات والعقود الآجلة التي تتم تسويتها بعملة البيتكوين.
نصوص بيتكوين مقابل العقود الذكية في إيثريوم
يحدد كل من «بيتكوين سكريبت» و«سوليديتي» الخاص بـ«إيثريوم» الشروط التي يمكن في ظلها تحويل الأموال، لكنهما يمثلان خيارات معمارية مختلفة جذريًّا. ومن المفيد إجراء المقارنة بشكل مباشر لأن هذه الاختلافات تفسر الكثير عن التنازلات التي قبلت بها كل شبكة.
الخط الفاصل الأساسي هو «الحالة» (statefulness). تعمل عقود «إيثريوم» على تخزين وتعديل البيانات التي تستمر عبر المعاملات، مما يجعل بروتوكولات الإقراض، والبورصات اللامركزية، والحوكمة على السلسلة، ومعايير الرموز الرقمية أمراً ممكناً. أما «بيتكوين سكريبت» فلا يوجد له ما يعادله. فكل برنامج نصي يعمل في فراغ تام دون أي علم بأي معاملة أخرى.
هذا اختيار معماري متعمد، وليس ثغرة تنتظر من يسدها. فقد صُممت طبقة البرمجة النصية في بيتكوين لغرض محدد واحد: فرض شروط إنفاق البيتكوين، بطريقة يمكن التنبؤ بها وآمنة، وعلى نطاق واسع. وبالنسبة لهذه المهمة، يُعد عدم وجود حالة ميزةً قوية. فمساحة التعرض للهجمات أصغر، والتنفيذ حتمي عبر ملايين المُصدقين المستقلين، ولا توجد أي فئة من استغلالات العقود الذكية على مستوى البروتوكول، نظرًا لعدم وجود عقود ذات حالة على مستوى البروتوكول.
المشاريع التي تسعى إلى توفير مزيد من قابلية البرمجة فوق شبكة بيتكوين تقوم ببناءها على شكل طبقات. تتولى شبكة «لايتنينغ» (Lightning Network) معالجة المدفوعات. أما بروتوكولات DLC فتتولى إدارة العقود المالية المرتبطة ببيانات خارجية. وتستهدف أنظمة الطبقة الثانية، مثل «آرك» (Ark) وشبكة «ليكويد» (Liquid Network)، أنماطًا مختلفة من قابلية التوسع. ولا يتطلب أي من ذلك تعديل نموذج البرمجة النصية للطبقة الأساسية.
النقاش حول «العهد»: ما الذي قد يتغير في لغة «سكريبت» الخاصة بالبيتكوين
لطالما كان تطور لغة «بيتكوين سكريبت» بطيئًا ومحافظًا. ويُعد مجال «رموز التشغيل التعاقدية» (covenant opcodes) أكثر مجالات التطوير نشاطًا في الوقت الحالي، وهي عبارة عن مقترحات من شأنها أن تسمح للغة «سكريبت» بتحديد ليس فقط من يمكنه إنفاق أحد المخرجات، بل أيضًا الشكل الذي يجب أن تتخذه المعاملة الناتجة. ويُعد هذا توسعًا مهمًا في قدرة لغة «سكريبت» على التعبير.
المقترحات الرائدة حتى يونيو 2026 هي:
- OP_CTV (BIP-119، CheckTemplateVerify)، الذي أعده جيريمي روبين، يضيف رمز تشغيل واحدًا يربط UTXO بنموذج إنفاق محدد ومحدد مسبقًا، يشمل إصدار المعاملة، ووقت القفل، وعدد المدخلات، والتسلسلات، وعدد المخرجات، والمخرجات نفسها. وهي غير تكرارية بحكم تصميمها، وتُعتبر الاقتراح الرئيسي الأكثر تحفظًا، وتستهدف في المقام الأول الخزائن، والتحكم في الازدحام، وبعض تحسينات شبكة Lightning. اعتبارًا من أبريل 2026، أصبح لدى OP_CTV معايير نشر محددة على الطاولة تحدد نافذة إشارات «التجربة السريعة» (Speedy Trial)، لكنها لم تحقق الإجماع المجتمعي الواسع المطلوب لتفعيلها، وفقًا لـ تحليل شروط اتفاقية BlockEden لشهر أبريل 2026.
- OP_CAT (BIP-347)، الذي اقترحه إيثان هيلمان وأرمين صابوري، سيعيد تفعيل رمز تشغيل كان ساتوشي قد عطلته في عام 2010. يعمل OP_CAT على ربط عنصرين من عناصر المكدس، وهو أمر بسيط في الوصف ولكنه واسع النطاق في آثاره. وعند دمجه مع توقيعات شنور، فإنه يتيح إمكانية فحص المعاملات بشكل مشابه لـ«العهد» (covenant). على شبكة اختبار «بيتكوين سيغنت»، ولّد OP_CAT عددًا أكبر بكثير من معاملات المطورين مقارنةً بـ APO أو CTV، وفقًا لتحليل sCrypt على السلسلة الذي أُجري في أواخر عام 2024. OP_CAT نشط بالفعل على شبكة «ليكويد» و«فركتال بيتكوين» دون أن تُسجَّل أي استغلالات تُعزى إليه. يتمتع BIP-347 برقم اقتراح رسمي وبأبحاث جارية تدعمه، لكن تفعيله على الشبكة الرئيسية يتطلب إجماعًا من المجتمع لم يتحقق بعد.
- LNHANCE تجمع بين OP_CTV و OP_CHECKSIGFROMSTACK (CSFS) و OP_INTERNALKEY، بهدف تحقيق تحسينات محددة في إنشاء قنوات شبكة Lightning Network، بما في ذلك فتح القنوات غير التفاعلية وإدارة القنوات متعددة الأطراف بشكل أكثر كفاءة.
لم يتم تفعيل أي من هذه الميزات على الشبكة الرئيسية لبيتكوين حتى يونيو 2026. والخلافات الفنية بينها قابلة للحل إلى حد كبير. أما المشكلة الأصعب فهي آليات التفعيل. تتطلب عملية «الشوك الناعم» (soft fork) في بيتكوين إجماعًا واسعًا، ولا يزال الجدل حول «العهد» يحمل توترات متبقية من التحديثات المثيرة للخلاف في الماضي. ما يتضح من هذا الجدل هو أن طبقة البرمجة النصية في بيتكوين تتمتع بمساحة كبيرة للنمو ضمن إطارها المحافظ. والسؤال الذي يجري العمل على حله هو التسلسل والتوافق المجتمعي، وليس ما إذا كانت لغة البرمجة النصية لها مستقبل أم لا.
الخلاصة
يُعد «Bitcoin Script» البنية التحتية غير المرئية التي تقع وراء كل معاملة على الشبكة. ولا يواجهها معظم المستخدمين بشكل مباشر أبدًا. فالمحافظ تقوم بإنشاء نصوص برمجية صالحة وتوقيعها وبثها دون الكشف عن آليات عملها أبدًا. لكن كل عملية دفع، وكل قناة Lightning، وكل خطة محددة زمنيًا، وكل خزينة متعددة التوقيعات تعمل من خلال نفس لغة البرمجة النصية لبيتكوين القائمة على المكدس والتي تم تضمينها مع البروتوكول في عام 2009.
وقد شهدت طبقة البرمجة نمواً كبيراً منذ ذلك الحين، حيث ساهمت تقنية P2SH في تسهيل عمليات الإنفاق المعقدة، وساهمت تقنية SegWit في خفض الرسوم وتمكين شبكة Lightning، كما أدخلت تقنية Taproot توقيعات Schnorr، والخصوصية القائمة على MAST، وتصميم رموز العمليات (opcode) المتوافق مع الإصدارات المستقبلية في Tapscript. تمثل مقترحات «العهد» التي تجري مناقشتها حاليًّا الفصل المحتمل التالي. وما زال من غير المؤكد تمامًا، حتى منتصف عام 2026، ما إذا كان أي منها سيُفعَّل، ومتى سيحدث ذلك.
لا يتطلب فهم لغة «سكريبت» أن تكون مطورًا. لكنه يتطلب إدراك أن نهج البيتكوين المحافظ، والقيود المتعمدة، ووتيرة التحديث البطيئة، وعدم اكتمال تورينج، ليست عيوبًا. فالخصائص التي تجعل لغة «سكريبت» الخاصة بالبيتكوين قابلة للتنبؤ هي نفس الخصائص التي حافظت على نقاء طبقة التوافق لمدة ستة عشر عامًا.
