Hard Fork تغيير في الإجماع لا تكون فيه مجموعة الصلاحية الجديدة مجموعة فرعية من القديمة. والحالة المعتادة هي التوسيع: تسمح V(new) بحالة خارج V(old)، مثل كتلة أكبر مما تسمح به العقدة القديمة أو بنية يعتبرها برنامجها غير صالحة. تفعيل القواعد الجديدة لا يجبر العقد القديمة على الانتقال؛ فهي تواصل إنفاذ قواعدها، ولذلك تعتمد استمرارية السلسلة على التنسيق الطوعي.
لنرمز بـ V(old) إلى جميع الكتل التي تقبلها القواعد الأصلية. يكون التغيير Hard Fork عندما يقبل البرنامج الجديد كتلة واحدة على الأقل خارج تلك المجموعة. غالبًا ما يتسع نطاق الصلاحية، لكن المعيار الحاسم هو التوافق: إذا أمكن أن تكون كتلة صالحة للعقدة الجديدة وغير صالحة للقديمة، فلا تستطيع العقدة القديمة متابعة السلسلة الجديدة مع الاحتفاظ بقواعدها. [Bitcoin Developer Guide — Consensus rule changes]
لا تعرف العقدة الكاملة القديمة القاعدة الجديدة ولا تعتمدها. عندما ينتج المعدنون المحدّثون كتلة تتجاوز الحد القديم أو تستخدم بنية أصبحت مسموحة، تبقى العقدة القديمة عند آخر كتلة تعتبرها صالحة وترفض الفرع اللاحق. لم تُهزم في تصويت؛ إنها تنفذ برنامج إجماع مختلفًا بصورة حتمية. [Bitcoin Developer Guide — Consensus rule changes]
قد ينسق تاريخ محدد أو ارتفاع كتلة أو إشارة من المعدنين بين من اعتمدوا التحديث، لكنه لا يغيّر برنامج عقدة لم تعتمده. وإذا بقي مشاركون ذوو أهمية اقتصادية على كل من مجموعتي القواعد، فقد تستمر السلسلتان. لذلك تكون خطة تفعيل Hard Fork خطة انتقال تتضمن خطر الانقسام. [Bitcoin Developer Guide — Consensus rule changes]
عند الانقسام يرث الفرعان تاريخ UTXO السابق نفسه. وبعده قد يؤكدان معاملات مختلفة، ويطبقان حدودًا مختلفة، ويراكم كل منهما عملًا تراكميًا مختلفًا، أي chainwork. إذا استمر الفرعان، فعادة تكون للحامل عملات مقابلة على السلسلتين، مع مراعاة قواعدهما اللاحقة وحماية replay ودعم المحافظ. لم يعد الأمر قيدًا واحدًا في دفتر واحد. [BCHN Technical Bulletin — shared history and 2017 split]
يفاضل Proof of Work بين الفروع بعد أن تتحقق العقدة من صلاحية كتلها. لا تقارن العقدة القديمة chainwork لفرع يحتوي كتلة تخالف قواعدها بعمل سلسلتها الصالحة؛ بل تستبعد ذلك المرشح أولًا. لذا فإن عبارة «السلسلة ذات أعلى hashrate تفوز» ناقصة ما لم تحدد قواعد التحقق التي تسبق المقارنة. [Bitcoin Developer Guide — Consensus rule changes]
قد يجعل تنسيق التوقيع والمعاملة المشترك معاملة موقعة واحدة صالحة على الشبكتين بعد الانقسام؛ وهذا خطر replay، أي إعادة بث المعاملة على السلسلة الأخرى. قد يضيف الفرع حماية أو قواعد sighash مختلفة أو تنسيق عناوين آخر، لكنها تدابير مستقلة. يجب التمييز بين الشبكات والأرصدة والعناوين المشتقة وسياسات منصات التداول الخاصة بقيد الإيداعات والسحب. [Bitcoin Cash upgrade specification — 2017 hard fork]
انفصل Bitcoin Cash عن Bitcoin عند ارتفاع الكتلة 478559 في 1 أغسطس 2017. اعتمد قواعد تسمح بكتل أكبر مما كانت عقد Bitcoin تقبله، وأنشأ سلسلة مستمرة خاصة به. رفضت عقد Bitcoin الكتل الصالحة لـ BCH فقط، وتابعت عقد BCH تاريخها الصالح وفق قواعدها. هذا مثال على Hard Fork أنشأ شبكة مستقلة بدل تحديث Bitcoin داخل الشبكة نفسها. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
ليس كل انقسام غير متوافق مشروعًا نقديًا جديدًا مقصودًا. قد يسبب خطأ برمجي خلافًا مؤقتًا بين التطبيقات، وقد تعيد إصدارات طارئة المشاركين إلى مجموعة قواعد واحدة. نشأ انقسام Bitcoin في مارس 2013 من اختلاف سلوك الإصدارات المتعلق بقاعدة البيانات وحدودها، وحُلّ بعودة منسقة للمعدنين إلى الفرع الذي تقبله عقد 0.7 القديمة؛ وهو يختلف عن إبقاء BCH شبكة مستقلة على المدى الطويل. [BIP 50 — March 2013 chain fork post-mortem]
يضيّق Soft Fork مجموعة الصلاحية بحيث تبقى V(new) داخل V(old)؛ تستطيع العقدة القديمة متابعة الكتل المتوافقة، لكنها لا تنفذ القيد الإضافي. لا يملك Hard Fork هذا التوافق أحادي الاتجاه: قد تكون الكتلة الصالحة حديثًا غير صالحة للعقدة القديمة. قد ينقسم Soft Fork أيضًا عند ضعف التنسيق، لكن Hard Fork يتطلب الانتقال إلى القواعد الجديدة بحكم تعريفه. [Bitcoin Developer Guide — Consensus rule changes]
يمكن للمطورين إصدار الشيفرة، وللمعدنين توجيه hashrate، وللشركات اختيار رموز التداول وسياسات الإيداع، وللمستخدمين اختيار البرنامج. لا يغيّر شيء من ذلك تلقائيًا إجماع الآخرين. قد يستمر الانقسام إذا حافظ عدد كاف من المشاركين المستقلين طوعًا على مجموعتي القواعد وقدّروهما؛ لكن ليس كل تغيير غير متوافق ينتج شبكتين حيتين بصورة دائمة. تسمية أحد الفرعين «تحديثًا» وصف اجتماعي، لا قاعدة إجماع. [Bitcoin Developer Guide — Consensus rule changes]
على المشغل التحقق من معرّفات الشبكة والإصدار المحدد ومعلمات الإجماع والعقد النظيرة ورأس السلسلة وهاش الكتلة عند نقطة الانقسام، مع ملاحظات الإصدار أو نقاط التحقق المقابلة. عند التعامل مع مبالغ كبيرة، يُستحسن فصل المحافظ ومسارات العمل قبل إنفاق عملات الفروع. يساعد مستكشف الكتل أو رمز التداول، لكنه لا يحل محل عقدة المشغل التي تتحقق من القواعد بنفسها. [Bitcoin Core v29.0: getblockchaininfo]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Soft Fork, قواعد الإجماع, Full Node, Reorg, حرب حجم الكتلة, UTXO. تشير إلى هذا المدخل أيضًا Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, حرب حجم الكتلة.