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, Війна за розмір блока.