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는 2017년 8월 1일 블록 높이 478559에서 Bitcoin과 분리됐다. 당시 Bitcoin 노드가 받아들이는 크기보다 큰 블록을 허용하는 규칙을 채택하고 자체적으로 이어지는 체인을 만들었다. Bitcoin 노드는 BCH 규칙에서만 유효한 블록을 거부했고, BCH 노드는 자체 규칙에 따른 유효한 역사를 따랐다. 이는 같은 네트워크 안에서 Bitcoin을 업데이트로 대체한 것이 아니라 별도 네트워크를 만든 Hard Fork의 사례다. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
호환되지 않는 모든 분리가 의도적인 새 화폐 프로젝트는 아니다. 소프트웨어 오류로 구현들이 일시적으로 서로 다른 판단을 내릴 수 있고, 긴급 버전으로 공통 규칙 복귀를 조정할 수도 있다. 2013년 3월 Bitcoin 분리는 데이터베이스와 한도에 관한 버전별 동작 차이에서 발생했다. 채굴자들이 구형 버전 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, 블록 크기 전쟁.