Reorg는 로컬 chainstate의 변경이며 Bitcoin 합의 규칙의 변경이 아닙니다. Full Node는 자체 검증 규칙을 적용하고 이를 통과하는 가지 중 누적 chainwork가 가장 큰 가지를 활성화합니다. 그 가지가 현재 끝 블록보다 앞에서 갈라졌다면 노드는 분리한 블록의 UTXO 변경을 되돌리고 대체 가지를 적용한 뒤 관련 거래를 mempool에 비추어 다시 평가합니다.
Bitcoin Core는 단순히 높이가 가장 크거나 가장 인기 있는 가지를 고르지 않습니다. 후보 체인은 활성화 과정에서 노드의 합의 규칙을 충족해야 하며, chainwork가 더 크다고 무효한 블록이 유효해지지는 않습니다. FindMostWorkChain은 무효하다고 알려지지 않은 후보 중 작업량이 가장 큰 후보를 고릅니다. 이것이 완전한 검증을 뜻하지는 않습니다. ActivateBestChain에서 블록을 연결할 때 추가 검사가 이루어집니다. 무효한 것으로 알려진 가지는 제외됩니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
분기점은 현재 활성 체인과 대체 가지가 공유하는 마지막 블록입니다. Reorg 깊이는 보통 이 공통 조상으로 돌아가기 위해 활성 체인의 끝에서 분리해야 하는 블록 수로 설명합니다. 한 블록 Reorg는 끝 블록을 교체하고, 더 깊은 Reorg는 여러 확인된 블록을 되돌립니다. 깊이는 각 노드의 현재 관점에 따라 달라집니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
DisconnectTip과 관련 검증 로직은 분리한 블록의 효과를 역순으로 되돌립니다. 소비된 UTXO는 복구되고, 제거한 블록이 만든 출력은 확인 상태를 잃습니다. 따라서 Bitcoin Core는 되돌리기 데이터를 보관하여 분기점의 UTXO 집합을 정확히 재구성할 수 있어야 합니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
되돌린 뒤 ConnectTip은 chainwork가 더 큰 가지의 블록을 정방향으로 연결합니다. 각 거래는 복구된 UTXO 집합과 해당 높이에서 적용되는 규칙에 따라 다시 검증됩니다. 결과는 하나의 특정 기록에 대응하는 chainstate이며 두 가지의 거래를 섞은 상태가 아닙니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
분리된 블록의 거래가 반드시 사라지는 것은 아닙니다. Bitcoin Core는 조건을 충족하는 coinbase 이외의 거래를 mempool로 돌려보내려 합니다. 일부는 이미 새 가지에 있거나, 충돌하거나, 입력을 잃거나, 시간 조건 또는 mempool 정책을 충족하지 못할 수 있습니다. 따라서 지갑은 Reorg가 확인을 취소할 수 있음을 고려해야 합니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Coinbase 거래는 예외로, 블록을 분리한 뒤 mempool로 돌아가지 않습니다. 합의 규칙상 높이 h에서 생성한 coinbase 출력은 블록 h + 100에서 처음 사용할 수 있습니다. 끝 블록이 h + 99라면 원래 블록은 100회의 확인을 가지며, 성숙 조건은 다음 블록에 지출 거래를 포함하는 것을 허용합니다. Reorg가 coinbase를 담은 블록을 제거하면 그 블록의 보상은 활성 chainstate에서 사라집니다. 제거된 기록에 의존하던 후속 거래도 무효해질 수 있습니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation] [Bitcoin Core v29.0 — coinbase maturity validation] [Bitcoin Core v29.0 — confirmation depth]
확인 수는 해당 거래가 들어 있는 블록과 그 노드의 현재 활성 체인에서 그 뒤에 이어지는 모든 블록을 포함합니다. 현재 끝 블록에 있는 거래는 한 번 확인된 상태입니다. 블록이 추가될 때마다 일반적으로 기록을 교체하는 데 필요한 작업량이 늘지만, 유한한 확인 수가 수학적으로 절대적인 완결성을 만들지는 않습니다. 거래소와 가맹점은 결제 금액과 위험 모델에 따라 확인 기준을 정합니다. [Bitcoin Core v29.0 — confirmation depth] [Bitcoin whitepaper — Sections 5 and 11]
두 채굴자가 경쟁 블록을 거의 동시에 발견하고 네트워크의 서로 다른 부분이 잠시 다른 끝 블록을 따르면 짧은 Reorg가 자연적으로 생길 수 있습니다. 이후 chainwork가 더 작은 가지는 활성 체인에서 제외됩니다. Double Spend 공격은 같은 메커니즘을 의도적으로 사용합니다. 체인을 선택하는 기술 절차는 같지만 원인과 경제적 목적은 다릅니다. [Bitcoin Developer Guide — Block Chain] [Bitcoin whitepaper — Sections 5 and 11]
Reorg는 하나의 규칙 집합 안에서 발생하며 노드는 유효하다고 판단하는 가지 중에서 선택합니다. Hard Fork는 유효성 규칙을 바꾸므로 이전 소프트웨어와 새 소프트웨어가 블록의 유효성 자체에 대해 서로 다르게 판단할 수 있습니다. 따라서 재구성 자체는 합의를 변경하지 않습니다. [Bitcoin Developer Guide — Block Chain]
Bitcoin Core v29.0의 단계는 명확합니다. FindMostWorkChain은 무효하다고 알려지지 않은 후보 중 chainwork가 가장 큰 후보를 찾고, ActivateBestChainStep은 현재 끝 블록을 분리할 수 있습니다. ConnectTip은 대체 블록을 검증하고 연결하며, MaybeUpdateMempoolForReorg는 분리한 블록의 거래를 다시 검사합니다. 활성화 도중 후보가 무효함을 발견하여 다른 가지를 계속 찾을 수도 있습니다. 큰 Reorg는 더 많은 블록을 분리하고 연결해야 하므로 ActivateBestChain 처리 시간이 길어질 수 있습니다. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 확인, Proof of Work, Stale Block, 이중 지불, Full Node, UTXO. 다음 항목에서도 이 글을 참조합니다 확인, 이중 지불, 코인베이스 트랜잭션, Soft Fork.