التحديث الكبير القادم لعملة البيتكوين؟ تقييم OP_CAT و OP_CTV

المؤلف: جابي باركر، محلل جالاكسي؛ الترجمة: جولدن فاينانس شياوزو

الملخص

• تتخذ عملة البيتكوين موقفًا متحفظًا تجاه ترقيات البروتوكول، مما يجعل تغييرات الإجماع نادرة نسبيًا. ولكن كما أظهرت ترقيات SegWit و Taproot السابقة، يظل المطورون على استعداد لتحسين لغة برمجة Bitcoin ومعلمات الشبكة.

• لا تستطيع لغة برمجة البيتكوين، Bitcoin Script، السماح للمعاملات بحمل حالة عالمية ولديها قدرات استبطانية، مما يحد من قوتها التعبيرية.

• يوجد حاليًا اقتراحان رئيسيان، OP_CAT (BIP 347) وOP_CTV (BIP 119)، يهدفان إلى تحسين قابلية برمجة معاملات Bitcoin وتمكين مخرجات المعاملات من الحصول على المزيد من شروط الإنفاق. قد تعمل هذه المقترحات على تعزيز وظائف Bitcoin Script بشكل كبير، مما يجعلها أكثر مرونة.

• تتضمن سيناريوهات التطبيق الأكثر واعدة لـ OP_CAT و OP_CTV ما يلي:إنشاء جسر عبر سلسلة بلا ثقة بين الطبقة الأولى (L1) والطبقة الثانية (L2) من Bitcoin،تحسين حلول الخزنة الذاتية المتقدمة،وتحسين شبكة Lightning.

• تتضمن عملية حوكمة ترقيات الشوكة الناعمة العديد من أصحاب المصلحة في Bitcoin. في المراحل المبكرة من وضع فكرة البروتوكول والمراجعة الفنية، يتمتع المؤثرون في وسائل الإعلام والمطورون الأساسيون بالتأثير الأكبر. تتوقع شركة Galaxy Research أن مطوري Bitcoin الأساسيين سيتوصلون إلى إجماع بشأن OP_CAT أو OP_CTV في عام 2025، ولكن بسبب تعقيد عملية التنشيط، فقد يستغرق التنفيذ الفعلي من عام إلى عامين. 1. المقدمة

  تتطلب التغييرات التي تطرأ على بروتوكول بيتكوين المناقشة والتعاون بين أصحاب المصلحة المتعددين، بما في ذلك على سبيل المثال لا الحصر مطوري البروتوكول، والعقد الكاملة، والمستخدمين النهائيين، والمعدنين. إن عملية التوافق لتحقيق ترقيات البروتوكول معقدة ومثيرة للجدل. على سبيل المثال، أدت حرب حجم الكتلة في الفترة من 2015 إلى 2017 إلى انقسام مجتمع البيتكوين بين أولئك الذين أرادوا تعديل حجم الكتلة وأولئك الذين عارضوا ذلك. بلغت سنوات من النقاش ذروتها في انقسام دائم في blockchain وإنشاء عملة مشفرة جديدة، Bitcoin Cash، وهي نسخة متشعبة من Bitcoin.

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

  على الرغم من أن تغييرات إجماع Bitcoin نادرة نسبيًا، فقد أظهر مطورو Bitcoin موقفًا منفتحًا تجاه تحسين نصوص Bitcoin ومعلمات الشبكة. في الواقع، أدى تحديث Segregated Witness (SegWit) الذي نشأ عن المناقشة حول حجم الكتلة إلى زيادة حد حجم الكتلة، مما يسمح بتضمين المزيد من المعاملات في كتلة واحدة. يقوم SegWit أيضًا بتحسين تنسيق بيانات المعاملات عن طريق تغيير وحدة قياس بيانات المعاملات من البايتات إلى البايتات الافتراضية (vbytes). يسمح هذا التحول، إلى جانب نقل بيانات التوقيع إلى حقل الشاهد، لكتلة البيتكوين باحتواء ما يصل إلى 4 ملايين وحدة وزن من بيانات المعاملات (حوالي 4 ميجا بايت). كان آخر شوكة ناعمة لعملة البيتكوين هو ترقية Taproot لعام 2021، والتي قدمت لغة برمجة محدثة تسمى Tapscript. يتضمن هذا الإصدار الجديد من Bitcoin Script مخطط توقيع جديد (توقيعات Schnorr) وتجميعًا محسنًا للمفاتيح، من خلال الجمع بين مفاتيح وتوقيعات عامة متعددة في مفتاح توقيع واحد. يؤدي تجميع المفاتيح لتوقيعات Schnorr إلى تقليل كمية بيانات المعاملات التي تتطلب توقيعات متعددة مع تحسين خصوصية المعاملات على شبكة Lightning (أكبر طبقة دفع P2P في Bitcoin، والتي تم بناؤها فوق الطبقة الأساسية لـ Bitcoin). تُظهر هذه النظرة العامة الموجزة على SegWit و Taproot أنه على الرغم من حذر مطوري Bitcoin بشأن التغييرات في إجماع Bitcoin، فإن هذا لا يعني أن الميزات التقنية لـ Bitcoin لن تتغير.

  بعد SegWit و Taproot، يستكشف مطورو Bitcoin الآن تحسين قابلية برمجة معاملات Bitcoin لإضافة منطق العقد الذكي الإضافي إلى المعاملات. تتضمن عقود بيتكوين الذكية استخدام شروط الإنفاق، وهي القدرة على تحديد كيفية إنفاق مخرجات المعاملات غير المنفقة (UTXOs) مستقبلًا والتحكم فيها. أما قيود الإنفاق الأكثر تعقيدًا وصرامةً فتُسمى "العهود" (أو "القيود" أو "العهود"). ستقوم هذه المقالة أولاً بمراجعة Bitcoin Script وكيفية عمله مع نموذج المحاسبة UTXO الخاص بـ Bitcoin. بعد ذلك، سوف نقوم بتحليل رمزين معلقين، OP_CTV وOP_CAT، لتسليط الضوء على كيفية قدرة هذه الرموز على تحسين Bitcoin Script لتضمين ميزات قوية تمكن قابلية برمجة المعاملات بكفاءة. أخيرًا، تسلط الورقة الضوء على أهمية قابلية برمجة المعاملات للبنية التحتية لبيتكوين مثل الجسور والحسابات الضمانة، وتتطلع إلى إمكانية التوصل إلى إجماع بشأن OP_CAT وOP_CTV، بالإضافة إلى المسار لتنفيذ هذه التعليمات البرمجية في ترقية الشوكة الناعمة التالية. 2. نص بيتكوين ونموذج UTXO يستخدم بيتكوين لغة برمجة أصلية لإنشاء المعاملات، تسمى "نص بيتكوين". يتكون البرنامج النصي من مجموعة من التعليمات التي تحدد كيفية قيام المتلقي للمعاملة بإنفاق عملات البيتكوين المرسلة، والمعروفة أيضًا باسم "شروط الإنفاق". يتكون Bitcoin Script من 186 رمزًا تشغيليًا يتم تشغيلها كوظائف أوامر. تُستخدم هذه الرموز لإنشاء قواعد رسمية لكيفية إنفاق أصول Bitcoin ونقلها على الشبكة. على سبيل المثال، تحتوي معاملة التجزئة Pay-to-PubKey على 4 أكواد تشغيلية تفرض شروط الإنفاق على معاملات Bitcoin، حيث يتم إنفاق Bitcoin على مفتاح عام مجزأ ولا يمكن إنفاقها إلا باستخدام المفاتيح العامة والخاصة الصحيحة المرتبطة بالمنفق. تم تصميم البرنامج النصي Bitcoin لمخرجات المعاملات غير المنفقة الخاصة بـ Bitcoin (نموذج UTXO)، والتي تستخدم المدخلات والمخرجات. تتكون كل معاملة بيتكوين من مدخل واحد على الأقل ومخرج واحد، على الرغم من أن معظم المعاملات البسيطة تتكون من مدخل واحد على الأقل ومخرجين اثنين (يتم استخدام جزء من BTC على جانب المدخلات لتمويل المعاملة، ويتم إرسال جزء إلى المستلم، ويتم إرجاع الباقي إلى المنفق على جانب المخرجات). UTXOs هي أجزاء من Bitcoin لم يتم إنفاقها بعد ويمكن إرسالها في معاملات مستقبلية. بمجرد استخدام UTXOs كمدخلات لمعاملة، فإنها لم تعد مخرجات. لذلك، عندما ينفق المستخدمون Bitcoin، يتم إنشاء UTXOs وتدميرها باستمرار. فيما يلي مثال مبسط لنموذج UTXO:

  *إذا كان لدى أليس UTXO بقيمة 1 BTC في محفظتها وأرسلت 0.5 BTC إلى بوب، فسيكون مدخل أليس 1 BTC. *سيكون مخرجاتها 0.49 BTC (يتم إرجاعها إلى أليس) و 0.5 BTC (يتم إرسالها إلى بوب). يمثل الفرق البالغ 0.01 BTC مبلغ BTC المدفوع كرسوم معاملة (ستختلف رسوم المعاملة هذه اعتمادًا على ازدحام الشبكة). *في نهاية هذه المعاملة، ستحصل أليس على مجموعة UTXO جديدة تمثل 0.49 BTC المتبقية لديها. في الخطوة 1، تستخدم أليس UTXO الخاص بها بقيمة 1 BTC كمدخل أول للمعاملة، مما يؤدي إلى تدمير UTXO. في الخطوة 2، تقوم أليس بإنشاء اثنين من UTXOs جديدين، بقيمة 0.5 BTC و0.49 BTC، يتم إرجاع أحدهما إليها كباقي لها، ويتم دفع الآخر إلى بوب. في الخطوة 3، أصبح لدى أليس الآن UTXO جديد بقيمة 0.49 BTC. لاحظ أنه إذا احتاجت أليس إلى دفع 0.5 BTC إلى بوب، فيمكنها أيضًا استخدام عدة UTXOs في الخطوة 1، بإجمالي 0.5 BTC؛ إذا لم يتم إعطاء أي من UTXOs المدخلة بالكامل للمستلم، فقد تتلقى أليس الآن 2 UTXOs جديدين بدلاً من 1. يعد نموذج UTXO ميزة أساسية لشبكة Bitcoin ويلعب دورًا حيويًا في معالجة المعاملات والتحقق منها.

  تم إنشاء مثال UTXO أعلاه بالكامل باستخدام Bitcoin Script. يحتوي كل UTXO على نص برمجي للقفل، والذي يتضمن مجموعة من الشروط التي يمكن بموجبها إنفاق UTXO. عندما يثبت المستخدم ملكيته للمدخلات (يتم إنفاق UTXO) من خلال توفير توقيع المفتاح الخاص الصحيح المرتبط بالمفتاح العام المقابل، يتم إلغاء قفل البرنامج النصي لقفل UTXO. تسمى هذه المعلومات "توقيع البرنامج النصي"، وعندما يتم تضمين توقيع البرنامج النصي الصحيح في الإدخال، يتم استيفاء شروط الإنفاق ويمكن إنفاق البيتكوين. بالعودة إلى مثال UTXO الخاص بـ Alice وBob، في الخطوة 1، يجب على Alice توفير توقيع المفتاح الخاص بها على مدخلاتها لإنفاق UTXO الخاص بها. بعد ذلك، يجب على بوب تقديم نفس المعلومات قبل إنفاق 0.5 BTC التي تلقاها حديثًا. يمكن أن تتضمن لغة برمجة البيتكوين شروط إنفاق أكثر تعقيدًا، مثل طلب توقيعات متعددة أو فتح عملات البيتكوين عند ارتفاع كتلة معين. ومع ذلك، فإن Bitcoin Script ليس متعدد الأغراض ويفتقر إلى القوة التعبيرية للغة البرمجة الأصلية لـ Ethereum، Solidity. لذلك، فإن برمجة منطق العقد الذكي لحلول الجسر والحراسة باستخدام Bitcoin Script يعد أمرًا صعبًا للغاية. 3. العقبات التي تواجه Bitcoin Script اعتبارًا من عام 2025 على الرغم من أن Bitcoin Script أثبتت جدواها للمستخدمين ومقاومتها لهجمات الإنفاق المزدوج على مدار السنوات الـ 16 الماضية، إلا أن لغة البرمجة تفتقر إلى ميزات عامة مثل القدرة على التعبير والقدرة على تخزين الحالة العالمية. Bitcoin Script ليس معبرًا لأنه لغة برمجة تعتمد على المكدس ولا يمكنها إجراء عمليات الضرب والحساب على أعداد كبيرة. لا يمكن لـ Bitcoin Script سوى إجراء عمليات حسابية غير تافهة على قيم بحجم 32 بت. لذلك، يقوم Bitcoin Script بعزل عناصر المكدس التي يزيد حجمها عن 32 بت عن بعضها البعض. يعزل هذا القيد المكون من 32 بت الأوامر التي تتطلب قدرًا كبيرًا من الحساب باستخدام الوظائف التشفيرية والضرب والقسمة والتي تتطلب أحجام نصوص أكبر مما يمكن لمجموعة التعليمات البرمجية الحالية التعامل معه. على الرغم من أنه من الممكن محاكاة الحساب والضرب باستخدام أكواد تشغيل متعددة، إلا أن هذا يتطلب العديد من عناصر المكدس، ويحتوي Bitcoin Script على حد أقصى لحجم المكدس يبلغ 1000 عنصر. ومن ثم، فمن الصعب خلق ظروف إنفاق معقدة على مخرجات المعاملات التي تتجاوز العمليات الحالية.

  أكبر قيود Bitcoin Script هو أن اللغة لا تستطيع قراءة/كتابة وتخزين بيانات المعاملات لأنها لا تستطيع قراءة سوى المدخلات التي يقدمها المنفق. إذا لم تتمكن لغة البرمجة من تخزين حالة عالمية، فلن تتمكن البرامج النصية من التحقق بشكل مستقل من أرصدة الحسابات في التطبيقات أو الجسور. لا يمكن لمنطق نصوص Bitcoin الوصول إلى الحالة العالمية، لأن أي بيانات حالة يجب أن تتناسب مع معاملة واحدة. لذلك، يكاد يكون من المستحيل تطوير وظائف عامة أو بناء جسر لا يحتاج إلى ثقة بين شبكات L2 وطبقة قاعدة Bitcoin.

  كانت الجهود المبذولة للتغلب على قيود Bitcoin Script جارية منذ عام 2020. لسنوات عديدة، بدا أن هناك إجماعًا بين المطورين على أن الطريقة الوحيدة لزيادة قدرة Bitcoin Script على التعبير هي إجراء ترقية شوكة ناعمة، وتنفيذ أكواد تشغيل جديدة لتمكين العهود. في حين يعتقد جزء من مجتمع Bitcoin أن هذه الترقيات تشكل خطرًا على شبكة Bitcoin، يعتقد جزء آخر أن Bitcoin بحاجة إلى المزيد من ميزات البرمجة لتوسيع حالات استخدام Bitcoin. في حين لم يتم تحقيق أي تقدم حقيقي بشأن أي رمز تشغيلي هو الأفضل لتحسين قابلية برمجة معاملات Bitcoin، فإن أنصار العهد يتفقون الآن في الغالب على أن OP_CTV و OP_CAT هما مقترحات تحسين Bitcoin الأساسية (BIPs) لتعزيز قابلية برمجة معاملات Bitcoin. نحن ندرك أن هناك أكثر من حلين لتطبيق العهود على Bitcoin، لكن هذه المقالة ستصف فقط الاقتراحين الأكثر بروزًا، OP_CTV وOP_CAT. 4. BIP 119 (OP_CTV)

  تم اقتراح اقتراح تحسين البيتكوين 119 (BIP 119)، المعروف أيضًا باسم CHECK-TEMPLATE-VERIFY (CTV)، من قبل مطور Bitcoin الأساسي جيريمي روبين في يناير 2020. يقدم الاقتراح رمز تشغيل جديد، OP_CTV، يمكنه فرض شروط الإنفاق العامة، المعروفة باسم العهود، على مخرجات معاملات Bitcoin. فيما يلي مقدمة موجزة عن الخلفية. يشير جزء القالب في "CHECK_TEMPLATE_VERIFY" إلى تنسيق المعاملة الذي يجب اتباعه عند كتابة نصوص Bitcoin. CHECK-TEMPLATE-VERIFY هي ميزة جديدة تمكن البرنامج النصي للقفل لمخرجات المعاملة من الالتزام بشروط الإنفاق المخزنة في البرنامج النصي للقفل كتجزئة، والمعروفة أيضًا باسم تجزئة الالتزام. لذلك، لا يمكن فتح إخراج المعاملة إلا إذا تم استيفاء الشروط المفصلة في تجزئة الالتزام. بمجرد البث على السلسلة، فإن التجزئة الالتزامية المرتبطة بالمعاملة تكون غير قابلة للتغيير. تكمن فائدة OP_CTV في أن مرسل المعاملة يمكنه فرض شروط الإنفاق على المتلقي، وهو تغيير كبير في القواعد الحالية لـ Bitcoin Script، والتي لا يمكنها إلا إنشاء شروط الإنفاق للمرسل.

  هناك نوعان رئيسيان من العهود. يمكن نسخ العقد العام وتطبيقه على UTXOs متعددة. لا تنتهي صلاحية العهود بعد استنفاد UTXO. من ناحية أخرى، يمكن أيضًا تكرار العقود المحسوبة مسبقًا، ولكن فقط لعدد محدود ومحدد مسبقًا من المرات. يجب على المرسل تحديد منطق العقد المحسوب مسبقًا، ويختلف عن العقد العام في أن شروط الإنفاق لا يمكن تكرارها إلى ما لا نهاية. يمكن أن تشكل العقود العامة، المعروفة أيضًا باسم العقود المتكررة، خطرًا على قابلية استبدال UTXO، ولهذا السبب يركز أنصار BIP 119 بشكل عام فقط على حالة استخدام OP_CTV باستخدام العقود المحسوبة مسبقًا، ولهذا السبب لا يدعم BIP 119 العقود العامة. على سبيل المثال، إذا تم تمكين العهود العامة، فقد يتمكن الوصي أو بورصة البيتكوين من معالجة عمليات السحب بشروط إنفاق دائمة، حيث لا يمكن لهذه البيتكوين أبدًا الهروب من إمكانية الرقابة عليها من قبل الحكومة أو أي سلطة أخرى. 5. نشر العهود باستخدام BIP 119

  باستخدام حل الخزانة كمثال، إليك كيفية تنفيذ دالة OP_CTV للعهود:

  تريد أليس إنفاق 0.8 بيتكوين من 1 بيتكوين UTXO الخاص بها إلى بوب وتشارلي (0.4 بيتكوين لكل منهما) على مدى السنوات العشر القادمة. تريد أليس أيضًا إرسال باقيها، والذي يبلغ حوالي 0.2 BTC، إلى خزنة جديدة تقفل BTC لمدة 10 سنوات أخرى.

  الخطوة 1:تنفق أليس UTXO الخاصة بها والتي تساوي 1 BTC إلى بوب وتشارلي، والتفاصيل في البرنامج النصي القفل أن بوب وتشارلي يمكنهما إنفاق BTC بعد 525 ألف كتلة، أي بعد حوالي 10 سنوات. تتضمن أليس أيضًا تعليمات تفصيلية تفيد بأنه سيتم إرسال ناتج التغيير الخاص بها والذي يبلغ حوالي 0.2 BTC إلى عنوان الخزنة الذي تملكه، والذي سيقفل كتل UTXO 525k الخاصة بها، أو ما يقرب من 10 سنوات من الآن.

  الخطوة 2: أنفق بوب وتشارلي عملات UTXO الخاصة بهما والتي تبلغ قيمتها 0.4 BTC بعد 525 ألف كتلة. سيقوم البرنامج النصي للقفل الذي حددته Alice بالتحقق من التزام التجزئة مقابل ارتفاع الكتلة الحالي، وإذا تم استيفاء الشروط، يمكن لـ Bob وCharlie إنفاق UTXO الجديد الخاص بهما.

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

  الخطوة 3:بعد أن يفي تشارلي وبوب بالتزام التجزئة في البرنامج النصي للقفل، يتم إرجاع UTXO (حوالي 0.2 BTC) إلى أليس حيث يتم استخدام التغيير كمدخل إلى العنوان باستخدام المفتاح العام للبرنامج النصي للخزنة المحدد. يتضمن المفتاح العام لبرنامج الخزنة تجزئة تسمح لـ Alice بفتح الخزنة بعد 525 ألف كتلة لإنفاق UTXO الخاص بها بقيمة حوالي 0.2 BTC. تكمن فائدة استخدام مخطط الخزنة في أن أليس يمكنها إضافة تدابير أمنية مفصلة إلى التجزئة، مثل عنوان استرداد سري، في حالة قيام شخص ما بسرقة مفتاحها الخاص ومحاولة فتح UTXO قبل قفل وقت الكتلة 525 كيلو بايت. في المثال السابق، بدون عهود، ستحتاج أليس إلى إنشاء معاملة موقعة مسبقًا لفرض شروط الإنفاق المستقبلية على BTC التي تنفقها على بوب وتشارلي. يمكن أن تكون المعاملة الموقعة مسبقًا عبارة عن معاملة واحدة أو معاملات متعددة يتم توقيعها مسبقًا بواسطة المفتاح الخاص للمرسل ولكنها لا تُبث فعليًا إلى الشبكة للتأكيد والتنفيذ. المعاملات الموقعة مسبقًا ليست قابلة للتوسع لأنها تتطلب من المستخدمين تخزين البيانات لمعاملات متعددة حتى يتم تنفيذها على السلسلة. بالإضافة إلى ذلك، تتطلب المعاملات الموقعة مسبقًا التفاعل بين جميع الأطراف الموقعة قبل أن يتم إنفاق الأموال. ومع ذلك، فإن تنفيذ العهود باستخدام تجزئات الالتزام عبر OP_CTV يخفف من الحاجة إلى قيام المستخدمين بتخزين بيانات المعاملات الموقعة مسبقًا والاعتماد على التفاعل بين جميع الأطراف المشاركة في المعاملة. بشكل عام، يمكن استخدام هذه الوظيفة لإنشاء مجموعة من تصميمات الاستضافة والأمان المعقدة والآمنة للغاية والمرنة، مما يساعد على تحسين الإعدادات المستضافة ذاتيًا أو المُدارة، وإنشاء إعدادات جديدة مبتكرة لحسابات النصاب أو الأعمال، أو إنشاء مخططات تنفيذ أكثر استقلالية مع قدر أكبر من الشفافية والموثوقية. 6. BIP 347 (OP_CAT)

  BIP 347 هو اقتراح آخر لتحسين Bitcoin كتبه Ethan Heilman وArmin Sabouri في أكتوبر 2023، والذي يمكنه أيضًا تنفيذ شروط الإنفاق المحسوبة مسبقًا على ناتج معاملات Bitcoin. يقترح الاقتراح إضافة الكود OP_CAT إلى لغة برمجة Bitcoin، وهي ميزة تسمح لمطوري Bitcoin بـ "ربط" نقطتي بيانات معًا في المكدس ووضع هذه القيم في أعلى المكدس. دعونا نلقي نظرة على مقدمة خلفية موجزة. "الربط" هو عملية دمج سلسلتين أو أكثر من التعليمات البرمجية في سلسلة أكبر من البايتات أو البيانات. Bitcoin Script هي لغة برمجة تعتمد على المكدس والتي تقوم بتقييم كل سلسلة من التعليمات البرمجية بشكل تسلسلي. بالنسبة لمجموعة مكونة من 5 أسطر من التعليمات البرمجية، سيقوم Bitcoin Script بتقييم السطر 1 أولاً والسطر 5 أخيرًا. لسوء الحظ، لا تحتوي لغة برمجة Bitcoin على أكواد تشغيلية تسمح للمطورين بدمج سلاسل متعددة من التعليمات البرمجية عبر المكدس. في الوقت الحالي، يفتقر Bitcoin Script إلى وظائف الحساب والضرب، مما يعوق القدرة على ضغط Bitcoin Script، مما يحد من تفاعل النصوص الكبيرة (أكبر من 32 بت) والنصوص الصغيرة (أقل من 32 بت) في كومة واحدة. بدون القدرة على ضغط البرامج النصية من خلال "التسلسل" والسماح للبرامج النصية الكبيرة بالتواصل مع البرامج النصية الصغيرة، فإن شروط الإنفاق المعقدة على مخرجات المعاملات غير ممكنة. الأمر الحاسم هو أن العناصر المتصلة في Bitcoin Script في أعلى المكدس يمكنها محاكاة وظائف الحساب والضرب، مما يتيح إنشاء نصوص معقدة دون الحاجة إلى كتابة نصوص طويلة كثيفة البيانات وأكثر عرضة للأخطاء. بالإضافة إلى ذلك، تسمح قدرات الاتصال الخاصة بـ OP_CAT للمطورين بإنشاء شروط الإنفاق باستخدام أشجار Merkle وهياكل البيانات المجزأة الأخرى في Tapscript، وهي لغة البرمجة النصية الأصلية المستخدمة لتمكين أنواع المعاملات الجديدة كجزء من مجموعة ترقية Taproot المقرر تنشيطها في نوفمبر 2021.

  من الجدير بالذكر أن ساتوشي ناكاموتو قام بتعطيل OP_CAT وغيره من أكواد العمليات التي تمكن نصوص Bitcoin من إجراء عمليات رياضية معقدة مباشرة داخل النص. قام ساتوشي ناكاموتو بنفسه بحذف OP_CAT لأن هذا الكود يمكن دمجه مع OP_DUP لإنشاء نصوص برمجية كثيفة البيانات عندما كان حد نصوص Bitcoin 2000 بايت في ذلك الوقت. قد تؤدي البرامج النصية بهذا الحجم إلى فرض ضرائب على الموارد الحسابية لعقد Bitcoin وتحميلها بشكل زائد. ومع ذلك، قدم ترقية Taproot حدًا للحجم يبلغ 520 بايتًا لنصوص Taproot في عام 2021، لذلك لم يعد OP_CAT يقدم تكلفة حسابية مفرطة لمشغلي العقد. 7. نشر العهود باستخدام BIP 347 (OP_CAT)

  ستؤدي ترقية Taproot لعام 2021 إلى إدخال توقيعات Schnorr في لغة نص Bitcoin. تدعم توقيعات Schnorr تجميع المفاتيح العامة والخاصة، مما يسمح لأطراف متعددة بالتوقيع بشكل مشترك على معاملة بتوقيع واحد. يؤدي الجمع بين أكواد التحقق المضمنة في توقيعات Schnorr مع OP_CAT إلى إنشاء عقد غير متكرر يولد تجزئات المعاملات. من خلال OP_CAT، يمكن للمستخدمين تقييد أجزاء معينة من المعاملة، مثل عنوان الإرسال أو مبلغ الإرسال، كمتطلبات لنص إلغاء القفل، ويعمل تجزئة المعاملة كمفتاح لإلغاء القفل.

  إذا أخذنا حل الخزنة كمثال، فإن ما يلي هو نظرة عامة حول كيفية تنفيذ وظيفة OP_CAT لـ Covenants. إن التفاصيل الفنية لهذا المثال تقع خارج نطاق هذه المقالة.

  تريد أليس إنشاء قبو يفتح UTXO الخاص بها بعد 100 كتلة:

  *الخطوة 1:تنفق أليس UTXO الخاص بها إلى عنوان قبو وتتضمن تفاصيل شروط الإنفاق الخاصة بنص فتح القبو في حقل الشاهد، بما في ذلك ارتفاع الكتلة.

  *الخطوة 2: في معاملة أليس، يقوم OP_CAT بربط تعليمات فتح الخزنة في حقل الشاهد ويقوم بتجزئتها مرتين للحصول على sighash/txhash.

  *الخطوة 3:بعد تأكيد 100 كتلة، تبدأ أليس عملية إنفاق عملات البيتكوين الموجودة في خزانتها من خلال بث معاملة إنفاق لخزانة UTXO. للتحقق من أن أليس تلبي جميع شروط الإنفاق، تقوم محفظتها بتنفيذ التعليمات البرمجية CheckSig في الخلفية. تنفذ هذه العملية التحقق من صحة أمرين رئيسيين: التحقق من تجزئة المعاملة من معاملة الإعداد الأولية (الخطوة 1)، ومقارنتها بمعاملة الإنفاق الحالية (الخطوة 3). تعمل وظيفة CheckSig على إعادة بناء مكونات معاملة الإعداد والتحقق من توقيع المفتاح العام للمعاملة الحالية للتأكد من استيفاء جميع شروط إنفاق الخزنة.

  *الخطوة 4:بعد التحقق من المفتاح العام لمعاملة أليس بواسطة CheckSig (يعيد CheckSig بناء شروط الإنفاق المخزنة في حقل الشاهد)، تصبح أليس حرة في إنفاق UTXO الخاص بها.

  يوضح المثال أعلاه أن OP_CAT بحد ذاته لا يمكنه تنفيذ شروط الإنفاق على المعاملات، ولكن OP_CAT مع أكواد العمليات الأخرى في نص Bitcoin يمكنه تبسيط كتابة النص وبالتالي تنفيذ العهود. الوظيفة الوحيدة لـ OP_CAT هي ربط العنصرين العلويين للمكدس. على الرغم من أنه يمكن استخدام OP_CAT مع CheckSig لإنشاء العهود، فإن إضافة OP_CAT بمفردها لا توفر وظائف مشابهة لـ Solidity إلى Bitcoin Script. ينطبق هذا القيد أيضًا على إضافة OP_CTV فقط. حتى مع OP_CAT، فإن معاملات Bitcoin قادرة فقط على الحد الأدنى من التأمل، مما يعني أن المعاملات لا تتمتع بالوصول الكامل إلى عناصر أو حالة المعاملات السابقة. لذلك، لا يمكن لـ OP_CAT سوى دعم العهود الدقيقة لمخرجات معاملات Taproot. لا يمكن لـ OP_CAT إصلاح العقد الورقية لإخراج Taproot أو التحقق من المفاتيح الداخلية المستخدمة. ورقة الجذر الرئيسي هي حالة إنفاق واحدة أو نص برمجي يتم إرساله إلى مخرجات الجذر الرئيسي. فكر فيهم باعتبارهم "مسارات" مختلفة أو طرق لإنفاق عملات البيتكوين الخاصة بك - حيث تمثل كل عقدة ورقة طريقة محتملة لإنفاقها. المفتاح الداخلي في معاملة Bitcoin Taproot هو المفتاح العام الرئيسي المستخدم لمسار الإنفاق الأكثر كفاءة. عند إنفاق UTXO باستخدام مفتاح داخلي، فأنت تحتاج فقط إلى توفير توقيع على السلسلة دون الكشف عن أي نصوص أو مسارات Merkle. تجدر الإشارة إلى أنه يمكن معالجة هذه القيود من خلال مقترحات التعليمات البرمجية الأخرى مثل OP_TWEAK_VERIFY وOP_INTERNALKEY. بشكل عام، يمكن اعتبار OP_CAT بمثابة اللبنة الأساسية لتوليد شروط إنفاق معقدة على مخرجات المعاملات، ومع ذلك، فإن اللبنات الأخرى بما في ذلك CheckSig ضرورية لتعزيز تطوير قابلية برمجة معاملات Bitcoin. 8. الميزات الرئيسية التي يمكن أن تضيفها Covenants إلى Bitcoin

  （1） الجسر الخالي من الثقة والخروج من جانب واحد

  أصدرت شركة Starkware (منشئة Starknet zk-rollup على Ethereum) تقريرًا يسلط الضوء على كيفية دعم OP_CAT لإنشاء محققي STARK ومحققي Merkle لتحقيق جسر Bitcoin الخالي من الثقة. يتم إنشاء الجسر الخالي من الثقة من خلال نظام عقد متكرر يحافظ على حالة الجسر من خلال سلسلة من المعاملات المسجلة في شجرة ميركل. إن جوهر هذه الآلية هو حالة الجسر المستمرة المخزنة في إخراج OP_RETURN غير القابل للإنفاق، والذي يحتوي على التجزئة الجذرية لشجرة Merkle التي تمثل رصيد الحساب. يتطلب عهد OP_CAT أن تحتوي كل معاملة إيداع أو سحب جديدة على انتقال حالة صالح يعكس حالة الجسر الحالية. يتفاعل المستخدمون مع الجسر من خلال عهود الإيداع والسحب المتخصصة، والتي تستخدم أشجار ميركل لتجميع المعاملات المتعددة في دفعات للتحقق الفعال. يتم بعد ذلك دمج جذر شجرة Merkle هذه في عقد الجسر الرئيسي، والذي يقوم بالتحقق من صحة كل إيداع أو سحب ومعالجته. أثناء السحب، يتحقق العقد من الملكية من خلال التأكد من أن عنوان السحب يتطابق مع عنوان الإدخال الأول في معاملة الورقة. يستفيد التصميم من أدلة Merkle لتحديثات الحالة الفعالة في Bitcoin Script، مما يؤدي إلى إنشاء نظام لا يحتاج إلى ثقة حيث يتم فرض حالة وقواعد الجسر بالكامل من خلال منطق العقد على السلسلة الذي تم إنشاؤه بواسطة OP_CAT، دون الحاجة إلى أطراف ثالثة موثوقة. الأمر الحاسم هو أنه لكي يتمكن جسر Bitcoin الذي لا يحتاج إلى ثقة من التحقق من انتقالات حالة النظام النهائي، يتطلب Bitcoin Script أدلة تحقق. تعمل OP_CAT على بناء قدرة محققي STARK في نصوص Bitcoin من خلال ربط بيانات التجزئة معًا، مما يتيح لنصوص قفل UTXO التحقق من أدلة zk (أدلة المعرفة الصفرية) لانتقالات حالة النظام النهائي. قام فريق Taproot Wizard بابتكار إطار عمل جديد للجسور بدون ثقة يجمع بين OP_CAT وBitVM. يحقق BitVM تعبيرية تورينج الكاملة من خلال السماح بتقسيم العمليات الحسابية التعسفية وتنفيذها على Bitcoin. يقوم BitVM بتقسيم وقت تشغيل العمليات الحسابية التعسفية باستخدام Bitcoin Script إلى معاملات متعددة على Bitcoin. بدون أي عهود، يتطلب جسر BitVM الذي يقفل Bitcoin معاملة موقعة مسبقًا لإعداد الجسر. إن قدرة OP_CAT على حمل البيانات من المعاملات السابقة تمكن جسر BitVM من قفل وفتح عملات البيتكوين دون الحاجة إلى معاملات موقعة مسبقًا. يمكن لـ OP_CAT حمل البيانات من المعاملات السابقة من خلال خدعة تسمى "CAT على المكدس". تتضمن الحيلة ربط البيانات المجمعة على المكدس لبناء جذر شجرة Merkle، والذي يمكن لـ OP_CAT التحقق منه. لذلك، يضمن جسر CatVM تضمين بيانات المعاملات المحددة من المعاملات والإيداعات والسحوبات السابقة في المعاملة التالية لضمان استمرار جذر Merkle بعد السحب الناجح. وتضمن خدعة CAT على المكدس أيضًا أنه بعد أن يقوم مستخدم واحد بالسحب، يمكن لأي مستخدم مؤهل سحب عملات البيتكوين الجسرية المتبقية.

  (2) الحراسة المتقدمة للخزنة

  Bitcoin Vault هو حل حراسة جديد يتضمن ميزات أمان مثل مسارات الاسترداد، مما يسمح للمستخدمين بسحب Bitcoin إلى عنوان سري في حالة تسرب المفتاح الخاص. BIP 345، المعروف رسميًا باسم OP_VAULT، هو اقتراح تحسين Bitcoin معلق يستخدم OP_CTV لتحسين معايير الأمان الخاصة بحراسة Bitcoin. من المهم ملاحظة أنه يمكن أيضًا استخدام OP_CAT لإنشاء شروط الإنفاق لخزائن Bitcoin دون الحاجة إلى معاملة موقعة مسبقًا. اقترح مطور Bitcoin Core James O’Beirne OP_VAULT في يناير 2023 لتضييق حالات استخدام OP_CTV. يعتمد OP_VAULT على OP_CTV لإنشاء شروط الإنفاق لعملة Bitcoin المخبأة دون مطالبة المودعين بالتوقيع المسبق على معاملات متعددة. تسمح العهود للخزائن بالحصول على تأخير زمني يتم تشغيله عندما يحاول أي شخص إنفاق عملات البيتكوين المخبأة قبل قفل الوقت الأصلي، وعادةً ما يكون هذا مهاجمًا يحاول سرقة الأموال.

  (3) عقد عدم الالتباس

  أُدخل عقد عدم الالتباس إلى شبكة بيتكوين عام ٢٠١٥. وهو ناتج معاملة بيتكوين. في حال إنفاق المُوقّع مبلغًا مضاعفًا، سيتم تسريب مفتاح التوقيع. في الممارسة العملية، يقوم المستخدمون بحجز عملة البيتكوين الأصلية كوديعة أمان قابلة للتخفيض. يتيح هذا الإيداع للمستخدمين إجراء معاملات بدون تأكيد على الطبقة الأساسية، والتي يتم تعدينها لاحقًا في كتلة. معاملات التأكيد 0 هي معاملات بيتكوين فورية يتم التحقق منها وتأمينها بقواعد إجماع بيتكوين. إذا أنفق مرسل معاملة التأكيد 0 المبلغ المدخل قبل استخراج المعاملة، فيمكن للطرف المقابل أن يخسر وديعة تأمين Bitcoin الخاصة به من مفتاح التوقيع المخترق.

  (4) تحسينات على شبكة Lightning

  يمكن لـ OP_CAT تمكين مصانع القنوات، مما يسمح للمستخدمين بفتح قنوات Lightning دون بث معاملة فتح قناة أولاً على طبقة قاعدة Bitcoin. على سبيل المثال، إذا رغبت أليس في إنشاء قناتين ضوئيتين (واحدة مع بوب وأخرى مع تشارلي)، فسوف تبث أليس معاملة فتح قناة مع كل من بوب وتشارلي (معاملتان). تتطلب معاملة فتح القناة من كلا الطرفين إيداع Bitcoin في عنوان متعدد التوقيع 2/2. باستخدام مصنع القنوات، يستطيع بوب وتشارلي فتح قنوات منفصلة مع بعضهما البعض دون الحاجة إلى بث معاملة فتح قناة جديدة. وبالتالي، يمكن لجميع المشاركين في معاملة فتح القناة الأصلية إنشاء قنوات مستقلة مع بعضهم البعض.

  يمكن لـ OP_CTV إنشاء UTXO مشترك، حيث يمثل UTXO واحد مستخدمين متعددين. يتيح استخدام UTXOs المشتركة من CTV لمستخدمين متعددين فتح قنوات Lightning متعددة بمعاملة واحدة على السلسلة. عادةً، تتطلب كل قناة Lightning معاملة على السلسلة. لذلك، إذا قام العديد من المستخدمين بفتح قنوات Lightning، فقد يؤدي هذا إلى ملء مجموعة الذاكرة بالمعاملات المعلقة وزيادة رسوم المعاملات. ورغم أن هذه ليست مشكلة في الوقت الحالي، فسوف تحتاج عملية فتح القنوات إلى التوسع لدعم شبكة Lightning Network لجذب ملايين المستخدمين النشطين. 9. المخاطر المرتبطة بـ OP_CAT وOP_CTV

  تتضمن جميع شوكات البيتكوين الناعمة مخاطر تقنية، مثل الأخطاء في أكواد العمليات الجديدة أو حالات الاستخدام غير المتوقعة. في حين أن الأول نادر، فإن الأخير يتم الكشف عنه في إنشاء النقوش. يتضمن النقش إدخال بيانات عشوائية في حقل الشاهد للمعاملة، والتي تم استخدامها لإنشاء رموز جديدة ومجموعات NFT على Bitcoin. يتيح SegWit وتحديث Taproot معًا للمستخدمين إدخال الصور والبيانات النصية كبيانات سلسلة في حقل الشاهد. على الرغم من أن الفن الرقمي وإنشاء الرموز القابلة للاستبدال لم يكن الهدف من تنشيط SegWit أو Taproot، إلا أن المطورين الأذكياء بعد سنوات اكتشفوا كيفية استخدام هذه الترقيات لأغراض أخرى. عززت Galaxy Research هذا الشعور في تقريرنا Ordinals، مشيرة إلى أن النقوش التي تم إنشاؤها عن طريق الخطأ من خلال SegWit و Taproot يمكن أن يكون لها تأثير سلبي على ترقيات Bitcoin المستقبلية، حيث أن مفاجأة المجتمع من حالات الاستخدام الجديدة هذه يمكن أن تجعله أكثر ترددًا في دعم الشوكات الناعمة الجديدة.

  على الرغم من المشاعر الهبوطية فيما يتعلق بقدرة Bitcoin على الترقية، فقد تم اختبار OP_CAT وOP_CTV وبحثهما على نطاق واسع. كان الانتقاد الأصلي للعهد هو أن الحكومات يمكنها إجبار التطبيقات على فرض شروط إنفاق تسمح فقط لمجموعة من العناوين المعتمدة بإنفاق Bitcoin. هذا الانتقاد غير صحيح لأن الظروف التي يمكن أن يتم الإنفاق بموجبها يحددها المستخدم الذي يملك الأموال. يمكن للمستخدمين إنشاء معاملات تقيد الإنفاق المستقبلي على عناوين محددة، ولكن لا يمكن فرض هذه القيود خارجيًا بواسطة أطراف ثالثة ولا تمتد بشكل دائم بعد إنفاق الأموال المقفولة. ولذلك، لا تستطيع الحكومات فرض كيفية إنفاق الأموال من خلال تطبيق أو جسر الخزانة المستضاف ذاتيا. في حين لا يزال بإمكان أمناء الحفظ وبورصات البيتكوين تقييد كيفية إنفاق المستخدمين للأموال، إلا أنهم لا يستطيعون إضافة شروط إنفاق دائمة لسحب الأموال دون القدرة على فرض العقود العامة، وهو ما لا تسمح به OP_CTV. بشكل عام، OP_CAT وOP_CTV عبارة عن أكواد عمليات بسيطة، كل منها يؤدي وظيفة واحدة بشكل جيد للغاية. يقوم OP_CAT بربط العنصرين في أعلى المكدس، بينما يمكن لـ OP_CTV تجزئة شروط الإنفاق في البرنامج النصي القفل. لا تزال بعض حالات الاستخدام لهذه التعليمات البرمجية، مثل تطوير الجسور التي لا تعتمد على الثقة، تتطلب المزيد من البحث والاختبار الميداني، حيث أن الجسور معرضة للغاية للأخطاء والاختراقات. 10. مسار نشر العهد للترقية التالية للشوكة الناعمة

  يعتبر تحديد إجماع أصحاب المصلحة في Bitcoin بشأن ترقيات البروتوكول المستقبلية عملية معقدة تتطور على مدار دورة حياة الاقتراح، والمعروفة أيضًا باسم عملية BIP (اقتراح تحسين Bitcoin). تقرير BCAP عن تاريخ ترقية Bitcoin عن أدوار أصحاب المصلحة على النحو التالي:

  * العقد الاقتصادية: التبادلات ، الاستثمار في الوصي ، * مشاهير الوسائط: Coindesk ، مجلة Bitcoin ، X المشاهير ، podcasters

  * مطورو التطبيقات: مشاريع L2

  طوال دورة حياة اقتراح تحسين Bitcoin (BIP)، يمارس أصحاب المصلحة المختلفون درجات متفاوتة من التأثير، ويتغير نفوذهم النسبي أثناء عملية بناء الإجماع لتنفيذ الشوكة الناعمة. فيما يلي تفصيل لمستويات تأثير كل صاحب مصلحة، مرتبة من 1 إلى 10. اعتبارًا من مارس 2024، أصبح OP_CAT وOP_CTV في مرحلة تصميم البروتوكول. خلال هذه المرحلة، تتمتع شخصيات وسائل الإعلام بأكبر قدر من التأثير حيث يمكنهم التأثير على الرأي العام وإنشاء الروايات. على سبيل المثال، Taproot Wizards هو فريق من المؤثرين المشهورين في مجال Bitcoin والذين يستخدمون متابعيهم الكبار على وسائل التواصل الاجتماعي لتثقيف مجتمع Bitcoin حول فوائد OP_CAT. لقد عمل فريق Taproot Wizards على إنتاج محتوى تعليمي وأبحاث حول OP_CAT لتعزيز السرد الذي يفيد بأن Bitcoin Script يحتاج إلى أكواد تشغيل جديدة لتحسين إمكانية برمجة المعاملات. نتيجة لذلك، قامت Taproot Wizards بتأسيس مجموعة كبيرة من المؤيدين لـ OP_CAT، وهم يضغطون على المطورين الأساسيين لمراجعة مسودة OP_CAT BIP.

  خلال مرحلة فكرة البروتوكول، يحتل مطورو Bitcoin Core المرتبة الثانية من حيث التأثير، حيث يكون محررو BIP مسؤولين عن مراجعة مسودات BIPs المعلقة، والأهم من ذلك، أنهم الكيان الوحيد الذي يمكنه دمج BIPs في مستودع Bitcoin Core GitHub. بدون دعم من مطوري Bitcoin Core، سيتم حتماً تأجيل BIP ورفضها في النهاية. مطورو Bitcoin Core مسؤولون أيضًا عن صيانة قاعدة بيانات Bitcoin والتأكد من أنها لا تحتوي على أي أخطاء. إن التوصل إلى توافق في الآراء بين مطوري Bitcoin الأساسيين هو عملية صعبة لأن وجهات النظر الإيديولوجية قد تختلف بين مطوري Bitcoin الأساسيين، ويختلف تأثير كل مطور أساسي في عملية صنع القرار اعتمادًا على مساهماته وخلفية.

  

  وصلت OP_CAT وOP_CTV BIPs إلى المرحلة التي يستخدم فيها المشاهير الإعلاميون والمستخدمون ومطورو التطبيقات نفوذهم لإقناع مطوري Bitcoin Core بأن هذه التغييرات الإجماعية ستزيد من قابلية برمجة معاملات Bitcoin. وستتطلب المرحلة التالية من رحلة الإجماع إجراء أبحاث محددة من قبل خبراء التقنية ومطوري التطبيقات والمطورين الأساسيين لتفصيل جميع المخاطر المحتملة لـ OP_CAT و OP_CTV. بدون بحث محدد وحوار مفتوح مع مطوري النواة، لن يكون هناك رأي جماعي حول OP_CAT وOP_CTV من مجتمع مطوري النواة الأوسع.

  بمجرد التوصل إلى توافق في الآراء بين مطوري النواة، سيحتاج OP_CAT وOP_CTV إلى تعيين مسؤول رئيسي لتسهيل الخطوة الأخيرة المتمثلة في تنفيذ BIP في مستودع Bitcoin Core. بعد دمج BIPs لـ OP_CAT و OP_CTV في مستودع Bitcoin Core، يجب اتخاذ قرار بشأن طريقة التنشيط. بمجرد اختيار طريقة التنشيط، تبدأ فترة الإشارة، حيث يتمتع عمال المناجم والمستثمرون والعقد الاقتصادية بأكبر قدر من التأثير. اعتبارًا من مارس 2024، لم يعرب عمال المناجم والمستثمرون الكبار مثل Microstrategy والعقد الاقتصادية مثل Coinbase عن آراء عامة بشأن OP_CAT وOP_CTV. ويحتاج أصحاب المصلحة هؤلاء إلى فهم المخاطر والفوائد المترتبة على OP_CAT وOP_CTV بشكل أكبر قبل تنفيذ BIP. 11. طريقة تنشيط BIP إذا وافق مطورو نواة Bitcoin على تضمين OP_CAT أو OP_CTV في ترقية الشوكة الناعمة التالية، فيجب على المجتمع التوصل إلى إجماع بشأن طريقة تنشيط BIP. تتيح طريقة التنشيط للمعدنين الإشارة إلى استعدادهم للترقية. بشكل عام، هناك طريقتان لإجراء تغييرات على الكود على Bitcoin. أولاً، يمكن إجراء تغييرات على الكود من خلال شوكة ناعمة. الشوكات الناعمة هي ترقيات متوافقة مع الإصدارات السابقة تسمح لمشغلي عقد Bitcoin بالعمل بأمان على شبكة Bitcoin حتى بدون ترقية برنامج العميل الخاص بهم. تتمثل فائدة أخرى للشوك الناعمة المتوافقة مع الإصدارات السابقة في أن أي شخص لا يتفق مع اتجاه Bitcoin Core (عميل Bitcoin الرئيسي) يمكنه اختيار تشغيل إصدار أقدم من برنامج العميل الذي يستبعد تنشيط BIP الجديد، ولكن لا يزال بإمكانه الاتصال بسلسلة blockchain Bitcoin الأساسية. تضيف الشوكة الناعمة وظيفة عن طريق إنشاء شروط جديدة أكثر محدودية من مجموعة القواعد الموجودة، وبالتالي تتناسب مع القواعد الموجودة.

  عندما يتم تنشيط شوكة ناعمة بواسطة المستخدمين (بدلاً من عمال المناجم)، يُطلق عليها اسم شوكة ناعمة يتم تنشيطها بواسطة المستخدم (UASF). كان المثال الأكثر شهرة لـ UASF على Bitcoin هو ما حدث تقريبًا أثناء "حرب حجم الكتلة" في 1 أغسطس 2017، للمساعدة في تسريع اعتماد ترقية SegWit. أثناء النزاع حول حجم الكتلة، قام مستخدمو Bitcoin بترقية عقدهم لدعم ترقية SegWit ثم هددوا برفض الكتل من العقد غير المحدثة. ومن خلال القيام بذلك، يتم تشجيع عمال المناجم الذين لم يقوموا بترقية برنامج عميل Bitcoin الخاص بهم على اعتماد Segwit من أجل جعل كتلهم تنتشر على نطاق أوسع وزيادة فرصهم في تلقي مكافآت الكتل. على الرغم من أن UASF لم يحدث أبدًا أثناء حرب حجم الكتلة، إلا أن التهديد المحتمل لـ UASF أثر على عمال المناجم لتبني SegWit. الطريقة الثانية لتنفيذ تغييرات الكود هي من خلال التفرع الصعب، وهو ترقية غير متوافقة مع الإصدارات السابقة والتي تقسم الإجماع بشكل دائم بين العقد التي تمت ترقيتها وغير التي تمت ترقيتها. لم يقم مطورو Bitcoin Core بتنفيذ شوكة صلبة أبدًا لأن المجتمع يقدر التعزيز والتوافق مع الإصدارات السابقة لكود البروتوكول. قد يواجه البيتكوين انقسامًا في السلسلة إذا قامت أقلية من المستخدمين بإجراء ترقية شوكة صلبة، مثل تغيير حجم الكتلة. هذه هي الطريقة التي تم بها إنشاء Bitcoin Cash في عام 2017 عندما اختلف جزء من مجتمع Bitcoin مع ترقية Segwit وأرادوا بدلاً من ذلك الانقسام من بروتوكول Bitcoin عن طريق تنشيط تغيير كود غير متوافق مع الإصدارات السابقة لزيادة حجم الكتلة ببساطة. بالإضافة إلى التمييز بين تنشيطات الشوكة الصلبة والشوكة الناعمة، هناك طرق مختلفة لقياس مشاعر المجتمع تجاه الترقية قبل حدوث الشوكة. فيما يلي نظرة عامة على أنواع العمليات المختلفة التي اقترحها مجتمع Bitcoin لدعم تنشيط ترقيات الشوكة الناعمة بشكل أفضل:

  *BIP 9: يوفر BIP 9 إطار عمل للمعدنين للإشارة إلى دعمهم لترقيات الشوكة الناعمة عن طريق تعديل حقل بت الإصدار في رأس كتلة Bitcoin. بمجرد انتهاء فترة الإشارة، يمكن لمجتمع Bitcoin تقييم النسبة المئوية للمعدنين الذين يدعمون الترقية والتصويت وفقًا لمعدل تجزئة المعدن. إذا تم تجاوز حد دعم معين، يمكن للترقية أن تنتقل إلى التنشيط في "يوم العلم"، وهو ببساطة ارتفاع كتلة محدد للترقية لتنشيطها.

  *BIP 8:اقترح مطور Bitcoin Core منذ فترة طويلة Luke Dashjr (الذي كان يعمل على تطوير Bitcoin منذ عام 2011) BIP 8 في فبراير 2017 كخليفة لـ BIP 9. يقترح BIP 8 استخدام ارتفاع الكتلة بدلاً من معدل التجزئة لتحديد مدة فترة الإشارة للموافقة على الاقتراح. يقدم BIP 8 أيضًا معلمة شوكة ناعمة جديدة يتم تنشيطها على السلسلة تسمى "LOT". إذا تم تعيين هذه المعلمة على "TRUE"، ستكون هناك حاجة إلى إشارة أثناء فترة الانتهاء للتأكد من قفل الشوكة الناعمة عند ارتفاع مهلة الانتظار. من هنا فصاعدًا، يتم تنشيط الترقية بواسطة العقد في يوم العلم المحدد مسبقًا، بغض النظر عما إذا كان عمال المناجم قد أشاروا إليها أم لا. يسعى BIP 8 إلى تقليل تدخل عمال المناجم في تنشيطات الاقتراح المرغوبة من قبل المجتمع ويجبر عمال المناجم على النظر في عواقب الإيرادات المفقودة من عدم تلقي الكتل من العقد التي تمت ترقيتها إذا تم تعيين معلمة LOT للترقية على TRUE.

  *التجربة السريعة: قدم مطورو Bitcoin الأساسيون AJ Townes و Andrew Chow إصدارًا من BIP 8 يسمى "التجربة السريعة" في أبريل 2021. تحاول Speedy Trial تسريع الجدول الزمني حتى يتمكن عمال المناجم من الإشارة إلى استعدادهم للتنشيط. يعني هذا النهج أن الاقتراح يتم تفعيله بمجرد أن تشير أغلبية الكتل المستخرجة خلال فترة زمنية محددة إلى الجاهزية. تعمل Speedy Trial بشكل مشابه لنشر تنشيط BIP 9، ولكن مع نافذة تنشيط أقصر. تم مؤخرًا تفعيل ترقية Taproot على Bitcoin من خلال Speedy Trial. تتطلب التجربة أن تشير 90% من الكتل المستخرجة إلى الجاهزية خلال فترة أسبوعين قبل أن يتم تنشيط Taproot على الشبكة. وانتهت المحاكمة في 12 يونيو 2021. بعد الوصول إلى عتبة دعم 90% من عمال المناجم، تدخل الشبكة بعد ذلك فترة انتظار مدتها خمسة أشهر لإعطاء عمال المناجم والعقد الوقت الكافي لتحديث برامجهم. تم تفعيل Taproot رسميًا على Bitcoin في 15 نوفمبر 2021.

  *تنشيط الشوكة الناعمة الحديثة:هذه طريقة تنشيط ترقية تجمع بين السمات المختلفة لـ BIP 9 وBIP 8. تم اقتراحه في يناير 2020 من قبل مات كورالو، أحد المساهمين الأكثر إنتاجية في Bitcoin Core. تتضمن الطريقة ثلاث خطوات. الخطوة الأولى هي شوكة ناعمة يتم تنشيطها بواسطة المعدن كما هو موضح في BIP 9. إذا فشل عمال المناجم في تنشيط الترقية، فإن عملية تنشيط الشوكة الناعمة الحديثة التي حددتها شركة Corallo ستنتقل افتراضيًا إلى الخطوة الثانية، وهي فترة انتظار مدتها ستة أشهر للمطورين ومجتمع البيتكوين الأوسع لإعادة النظر في تغيير الكود. بعد ستة أشهر، إذا رغب المطورون والمستخدمون في مواصلة الترقية، فيمكنهم بدء الخطوة الثالثة، والتي تعادل بشكل أساسي BIP 8 مع تعيين معلمة LOT على TRUE. 12. الخاتمة على الرغم من أن OP_CAT (BIP 347) وOP_CTV (BIP 119) قد تلقيا الدعم من العديد من مطوري Bitcoin المعروفين، إلا أن هذه المقترحات لا تزال بحاجة إلى المرور بعملية العناية الواجبة الطويلة قبل أن يتم تنفيذها. يرجع ذلك إلى أن OP_CAT وOP_CTV يتطلبان إجراء تغييرات على طبقة إجماع Bitcoin، وعملية حوكمة BIP لمثل هذه التغييرات واسعة النطاق. على الرغم من أن الجدول الزمني لتفعيل BIP 119 وBIP 347 غير واضح وغير متوقع، فإن فترة المراجعة الطويلة قد تكون مفيدة للمقترحات لأنها توفر للمجتمع الوقت الكافي لفهم فوائد وتأثيرات OP_CTV وOP_CAT. بالإضافة إلى ذلك، سيكون لدى المساهمين في BIP مزيد من الوقت لاختبار OP_CTV وOP_CAT وتأثيرهما المحتمل على الأخطاء المستقبلية في Bitcoin Script. في حين أن الإمكانات الكاملة لـ OP_CAT و OP_CTV لا تزال قيد الاستكشاف، فإن تأثيرها الأكثر مباشرة هو تمكين الجسور غير الموثوقة لـ Bitcoin L2 وخزائن Bitcoin الآمنة المتقدمة. لا يمكن المبالغة في أهمية الجسر الخالي من الثقة لـ Bitcoin L2 المتوافق مع EVM، خاصة في سياق التطوير المستمر لـ Bitcoin DeFi. تمثل هذه الحلول التي لا تعتمد على الثقة تقدمًا كبيرًا مقارنة بالبدائل الحالية مثل WBTC و cbBTC، والتي تعتمد على وسطاء موثوق بهم وتقوض الطبيعة غير المسموح بها لتكنولوجيا blockchain. في حين أن خزائن Bitcoin المستضافة ذاتيًا قد توفر القيمة الأكثر عملية بين حلول الحراسة، فإن إمكانية إنشاء جسور L2 بدون ثقة توضح الاحتمالات الأوسع التي توفرها برمجة المعاملات المحسنة لبيتكوين. لقد حقق مجتمع المطورين تقدمًا كبيرًا في الترويج لهذه المقترحات في عام 2024، ومن المرجح أن يستمر هذا الزخم الجيد حتى عام 2025. مع اتجاه نشاط معاملات Bitcoin إلى الانخفاض ورسوم المعاملات منخفضة تصل إلى 1 sat/VB، يتحول التركيز الآن إلى كيفية استعادة نشاط المعاملات على شبكة Bitcoin. على الرغم من أن تقرير توقعات Galaxy Research 2025 يفترض أن مطوري Bitcoin Core سيتوصلون إلى توافق بين OP_CAT أو OP_CTV، إلا أن عملية التنفيذ والتفعيل النهائية قد تستغرق 1-2 سنة أخرى. ومع ذلك، فإن التبني النهائي لهذه المقترحات سيكون بمثابة معلم رئيسي في تطور Bitcoin Script، مما يضع الأساس لتطبيقات Bitcoin أكثر تطوراً وأماناً في المستقبل. من خلال تحسين قابلية برمجة المعاملات، سوف يكون Bitcoin قادرًا على دعم حالات استخدام أكثر ابتكارًا، مثل الربط عبر السلسلة دون ثقة وحلول الحراسة المتقدمة، مما يعزز بشكل أكبر تطوير نظام Bitcoin البيئي. إن تقديم هذه التقنيات لن يؤدي إلى تحسين وظائف Bitcoin فحسب، بل سيوفر أيضًا للمطورين والمستخدمين المزيد من الأدوات لبناء تطبيقات لامركزية أكثر أمانًا وكفاءة. ورغم أن تحقيق هذه الأهداف سيستغرق وقتًا وجهودًا مشتركة من المجتمع، فإن تأثيرها المحتمل سيضخ بلا شك حيوية جديدة في مستقبل البيتكوين.