ماذا تعني الشوكة الناعمة في العملات المشفرة؟

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

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

تخيل قواعد Bitcoin كدائرة كبيرة، وأي كتلة داخل هذه الدائرة تعتبر صالحة.

ترسم الشوكة الناعمة (Soft Fork) دائرة أصغر داخلها. الآن، تقبل العُقد المُحدّثة فقط الكتل الموجودة داخل الدائرة الأصغر. لكن النقطة الأساسية هي: كل كتلة داخل الدائرة الصغيرة هي أيضًا داخل الدائرة الكبيرة. لذلك، فإن العُقد القديمة، التي لا تزال تستخدم القواعد الأصلية، ترى تلك الكتل المُحدّثة ولا تجد أي مشكلة في قبولها.

هذا هو مفهوم التوافق الرجعي. يمكن للبرمجيات القديمة أن تتبع السلسلة الجديدة دون أن تدرك حتى أن تغييرًا في القواعد قد حدث.

نظرًا لأن الكتل المُحدّثة لا تزال تُلبي القواعد القديمة، فلا يتعين على الشبكة التحول بالكامل دفعة واحدة. يمكن للمعدّنين والمدققين والبورصات والمحافظ الترقية تدريجيًا، طالما أن إنتاج الكتل يتبع القواعد الأكثر صرامة قبل أن تتراكم الكثير من الكتل غير المتوافقة.

العلاقة بين القواعد تعمل على النحو التالي:

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

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

لإلقاء نظرة أعمق على كيفية ترابط السجل الأساسي، فإن شرح البلوكتشين للمبتدئين يستحق القراءة أولاً.

لفهم الفرق الجوهري بين الشوكات الناعمة والصلبة في عالم العملات المشفرة، يمكن تلخيصه في جملة واحدة: الشوكة الناعمة تُشدد القواعد، بينما الشوكة الصلبة تُعيد كتابتها بالكامل.

في سياق الشوكة الناعمة، لا تزال العُقد القديمة قادرة على التحقق من الكتل على السلسلة الجديدة. قد لا تفهم هذه العُقد جميع تفاصيل القواعد الجديدة، لكنها لا ترفض السلسلة. أما في حالة الشوكة الصلبة، فترى العُقد القديمة الكتل الجديدة على أنها غير صالحة، وتبقى بالتالي على سلسلة منفصلة خاصة بها.

يُعد التمييز في السوق أمرًا مهمًا أيضًا. يُعتبر Bitcoin Cash أوضح مثال على شوكة صلبة استمرت: شبكة منفصلة، وأصل رقمي منفصل، ومجتمع منفصل. وقد جعلت Ethereum منذ ذلك الحين الشوكات الصلبة المخطط لها مسار الترقية القياسي الخاص بها. ومع ذلك، لا يزال انقسام Ethereum Classic في عام 2016 يمثل أبرز انقسام في حوكمتها.

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

لا توجد جهة واحدة تتحكم في نجاح الشوكة الناعمة (Soft Fork)؛ بل يتطلب الأمر تعاون جميع الأطراف المعنية.

يقوم المطورون بكتابة ومراجعة الكود، بينما يقرر مشغلو العقد الكاملة (Full-node operators) القواعد التي تفرضها برامجهم. أما المعدّنون، فينتجون الكتل التي إما أن تتوافق مع القواعد الجديدة أو تفشل في ذلك. تتولى المحافظ والبورصات الجانب الذي يواجه المستخدم. ولا ينجح الأمر برمته إلا إذا فرض جزء كافٍ من الشبكة القواعد الأكثر صرامة بالفعل.

بالنسبة لـ Bitcoin تحديدًا، كانت إشارة المعدّنين هي أداة التنسيق الرئيسية. يستخدم BIP-9 versionbits بتات في رأس الكتلة لتتبع الجاهزية عبر فترات تتكون من 2,016 كتلة، أي ما يقرب من أسبوعين لكل فترة. بمجرد أن يشير عدد كافٍ من المعدّنين إلى دعمهم خلال نافذة الجاهزية، تبدأ فترة تثبيت (lock-in period) قبل أن تدخل القواعد الجديدة حيز التنفيذ.

إليك ما تفعله كل مجموعة بالفعل أثناء عملية التفعيل:

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

العقد الكاملة هي المكان الذي يتم فيه التنفيذ الفعلي للقواعد. يمكن للمعدّن أن يجد كتلة، لكن العقدة سترفضها إذا خالفت القواعد التي تفرضها تلك العقدة. هذا الفصل مهم جدًا عندما تشير إشارة المعدّنين وتنفيذ العقدة في اتجاهات مختلفة.

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

لم تكن تحديثات Bitcoin تسير دائمًا بسلاسة. فبعض الترقيات تمت بسرعة وهدوء، بينما استغرقت أخرى سنوات وكادت أن تقسم المجتمع. لكن ما يجمعها هو نفس هيكل التوافق: قواعد جديدة يمكن للعقد القديمة الاستمرار في اتباعها.

إليك ما فعلته كل ترقية رئيسية بالفعل:

• P2SH (BIP-16, 2012): سمح للمستخدمين بإرسال الأموال إلى تجزئة (hash) لبرنامج نصي بدلاً من الكشف عن البرنامج النصي الكامل في مخرجات المعاملة. بالنسبة للعقد القديمة، بدت معاملة P2SH كمعاملة “ادفع لأي شخص” قياسية. أما بالنسبة للعقد المحدثة، فقد فرضت منطقًا أكثر تعقيدًا تحتها. وكانت النتيجة العملية: أصبحت عناوين Multisig أقصر وأسهل بكثير في التعامل.
• فحوصات صحة الكتل والمعاملات (BIP-34, BIP-65, BIP-66): ثلاث ترقيات منفصلة شددت قواعد محددة حول ارتفاع الكتلة في معاملات Coinbase، والمخرجات المقفلة زمنيًا، وترميز التوقيع. أضاف كل منها معايير أكثر صرامة فرضتها العقد المحدثة بينما بقيت العقد القديمة على السلسلة.
• SegWit (BIP-141, 2017): الترقية الأكثر إثارة للانقسام السياسي في Bitcoin حتى الآن. نقلت SegWit توقيعات المعاملات إلى هيكل بيانات منفصل، مما أدى إلى تحرير مساحة الكتلة دون زيادة حد حجم الكتلة. لقد أصلحت قابلية تغيير المعاملات (transaction malleability)، وهو خطأ حيث يمكن تغيير معرفات المعاملات قبل التأكيد، وجعلت قنوات الدفع مثل Lightning Network عملية لأول مرة. نجحت الترقية من الناحية الفنية. لكن من الناحية السياسية، كادت أن تمزق المجتمع وأدت في النهاية إلى التفرع الصلب (hard fork) لـ Bitcoin Cash.
• Taproot (BIP-341 و BIP-342, 2021): جمعت توقيعات Schnorr، وخصوصية البرامج النصية على غرار MAST، و Tapscript في ترقية واحدة. يمكن لمحفظة متوافقة مع Taproot أن تجعل معاملة معقدة متعددة الأطراف تبدو مطابقة لمعاملة بسيطة بتوقيع واحد على السلسلة. وهذا يمثل مكسبًا كبيرًا للخصوصية والكفاءة. تم تفعيل Taproot بسلاسة، لكن التبني في العالم الحقيقي كان بطيئًا لأن المحافظ ومزودي البنية التحتية ومؤلفي البرامج النصية كان عليهم جميعًا التحديث بشكل مستقل.
• Litecoin SegWit (2017): قامت Litecoin بتفعيل SegWit قبل Bitcoin بأشهر، ويرجع ذلك جزئيًا إلى أن مجتمعها كان يضم عددًا أقل من أصحاب المصلحة الذين يتجهون في اتجاهات مختلفة. نفس الترقية الفنية، بيئة سياسية مختلفة، نتيجة أسرع.

تُعد SegWit قصة تحذيرية. فقد كانت متوافقة مع الإصدارات السابقة على مستوى البروتوكول، لكن الصراع المحيط بها حول حجم الكتلة، ورسوم عمال التعدين، والتحكم في التطوير جعلها واحدة من أكثر اللحظات إثارة للجدل في تاريخ Bitcoin. أما Taproot فيُظهر الطرف الآخر من الطيف: دعم واسع، تفعيل سلس، وتبني تدريجي. إن التعريف الفني للتفرع الناعم (soft fork) لا يقول شيئًا عن مدى فوضى السياسات.

إن مصطلح “متوافق مع الإصدارات السابقة” هو وصف تقني بحت، ولا يمثل بأي حال من الأحوال تنبؤًا بكيفية تصرف المجتمع الرقمي.

تكمن المشكلة في أن العقد القديمة (Old nodes) تقبل الكتل التي تتوافق مع القواعد القديمة. ومع ذلك، ليست كل كتلة تقبلها العقدة القديمة ستتوافق مع القواعد الجديدة الأكثر صرامة. عندما ينتج المعدّنون المحدّثون وغير المحدّثين كتلًا متضاربة في نفس الوقت، تحدث انقسامات قصيرة الأجل في السلسلة. هذا بالضبط ما حدث خلال تفعيل BIP-66 لشبكة Bitcoin في عام 2015. ساهم التعدين دون التحقق (Validationless mining)، حيث أنتج المعدّنون كتلًا دون التحقق منها فعليًا، في حدوث انقسامات عرضية في السلسلة قبل أن يصحح المعدّنون مسارهم (تاريخ تفعيل التحديثات اللينة لـ Bitcoin Optech).

تظهر نفس النزاعات في كل عملية تفعيل مثيرة للجدل تقريبًا:

• عتبة التفعيل (Activation threshold): إذا تم تعيينها منخفضة جدًا، فإن الترقية تتحرك بسرعة ولكنها تترك وراءها معارضة كبيرة. وإذا تم تعيينها عالية جدًا، فإنها تتوقف إلى أجل غير مسمى بينما يستنزف المعارضون الوقت.
• إشارة المعدّنين (Miner signaling): من المفترض أن تُظهر الإشارة الاستعداد، لكن المعدّنين يمكنهم استخدامها بشكل استراتيجي لتأخير اقتراح أو انتزاع تنازلات. الإشارة لا تعني التنفيذ.
• فرض المستخدم (User enforcement): يمكن لمشغلي العقد الكاملة (Full-node operators) رفض الكتل التي ينتجها المعدّنون، حتى عندما يشير المعدّنون إلى دعمهم. هذا هو معنى “التحديث اللين الذي ينشطه المستخدم” (user-activated soft fork). المستخدمون، وليس المعدّنون، هم من يقررون.
• الوزن الاقتصادي (Economic weight): تحدد البورصات والتجار والأمناء والمحافظ أي سلسلة يمكن للأشخاص الإنفاق عليها فعليًا. غالبًا ما يحدد هذا الوزن الاقتصادي أي سلسلة ستصمد عندما تتنافس نسختان.
• توسع النطاق (Scope creep): يمكن لتغيير القاعدة أن يحل مشكلة واحدة بينما يستبعد بهدوء خيارات التصميم المستقبلية. غالبًا ما يثير النقاد هذه النقطة، وهم محقون أحيانًا.

يُعد BIP-110 المثال الحي الحالي. يقترح مسودته سقفًا مؤقتًا على مستوى الإجماع لبعض حقول البيانات: حد 34 بايت على مفاتيح scriptPubKeys الإخراجية الجديدة ما لم يكن أول رمز تشغيلي (opcode) هو OP_RETURN، مما سيبقي ما يصل إلى 83 بايت صالحًا. يقول المؤيدون إن هذا تحديث لين (soft fork) مباشر يحمي تكاليف العقد الكاملة وتركيز Bitcoin المالي. بينما يقول النقاد إن التفعيل المثير للجدل يمكن أن يعزل سلسلة أقلية أو يمنع حالات استخدام مشروعة لم يتم اختراعها بعد. يمكن أن تكون كلتا الحجتين صحيحتين في آن واحد. يمكن أن يفي أي اقتراح بكل معايير التعريف التقني للتحديث اللين ومع ذلك يحمل خطر انقسام حقيقي إذا اصطف المشاركون الاقتصاديون على جانبي النزاع قبل بدء التفعيل.

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

يُعد دعم المحافظ أكثر أهمية من عناوين الأخبار المتعلقة بالشوكات، لأن المحافظ المختلفة تستجيب للترقيات بسرعات متفاوتة:

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

بالنسبة لمعظم المستخدمين، فإن قائمة التحقق أثناء أي تفعيل لشوكة ناعمة قصيرة:

• تأكد مما إذا كانت الترقية تؤثر على عمليات الإرسال العادية أو على البرامج النصية المتقدمة فقط.
• تجنب نقل الأموال لمجرد أن وسائل التواصل الاجتماعي تدعي توفر عملة جديدة — فالشوكة الناعمة لا تُنشئ عملة جديدة.
• تحقق من إشعارات المحفظة والبورصة قبل إرسال المعاملات الكبيرة.
• دع التفعيلات المثيرة للجدل تستقر قبل الاعتماد على المدفوعات ذات التأكيدات المنخفضة.
• احتفظ بعبارات الاسترداد (seed phrases) في وضع عدم الاتصال بالإنترنت ولا تدخلها أبدًا في أي موقع يدعي أنه جزء من ترقية.

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

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

مشاريع BIPs هي مجرد مقترحات. رقم BIP لا يعني أنه قاعدة ملزمة.

• حدود البيانات: يندرج BIP-110 ضمن هذا النقاش. يقترح مشروعه أن يقوم عمال التعدين بالإشارة باستخدام البت الرابع (bit 4)، مع عتبة موافقة بنسبة 55% عبر فترة 2,016 كتلة، وارتفاع تفعيل أقصى غير مشروط حوالي 1 سبتمبر 2026. يدور الجدل الأساسي هنا حول ما إذا كان يجب على طبقة إجماع Bitcoin مراقبة البيانات التي تُكتب على السلسلة، ومن يتحمل التكلفة إذا حدث خطأ في ذلك.
• الاستعداد الكمومي: يقترح BIP-360 آلية Pay-to-Merkle-Root، وهو نوع جديد من مخرجات شجرة السكربت. الهدف هو تقليل التعرض طويل الأمد لـ هجمات الكم عن طريق إزالة إنفاق مسار المفتاح الخاص بـ Taproot من تصميم هذا المخرج. هذا ليس إصلاحًا طارئًا لتهديد حالي، بل هو قرار تصميمي حول المدة التي ترغب Bitcoin في توفيرها قبل أن يصبح الحوسبة الكمومية خطيرة حقًا.
• العهود (Covenants): ستسمح مقترحات العهود (Covenants) لـ معاملة Bitcoin بوضع شروط على كيفية إنفاق العملات التي تنشئها في المستقبل. يرى المؤيدون أن هذا يمثل الأساس للخزائن، والتحكم في الازدحام، ومسارات توسع جديدة. بينما يخشى النقاد من القيود غير المقصودة والنزاعات التي قد تتبع تفعيلها.

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