45 / 736REORG

Reorg

체인 재구성

확인된 결제도 일시적으로 확인을 잃을 수 있습니다. 노드가 비트코인 기록의 다른 유효한 분기를 받아들여 기존에 따르던 마지막 블록들을 교체할 때 Reorg가 일어납니다.

비트코인 노드는 블록과 거래를 검증하는 프로그램입니다. Reorg는 비트코인 노드가 누적 Proof of Work가 더 많은 다른 유효한 분기로 전환하는 것입니다. Proof of Work는 채굴로 입증한 작업량을 뜻합니다. 노드는 최근 블록과 그 안의 결제를 다시 평가하지만, 비트코인 규칙을 바꾸거나 누군가에게 타인의 결제를 취소할 버튼을 주지는 않습니다.

안나가 비트코인의 작은 단위인 20,000 satoshi를 받습니다. 지갑에는 확인 1회가 표시됩니다. 자신의 노드가 받아들인 블록에 결제가 들어 있다는 뜻입니다. 그런데 노드가 그 결제를 아직 포함하지 않은 다른 유효한 경쟁 분기를 알게 됩니다. 그 분기의 누적 채굴 작업량이 더 많아지면 노드는 그쪽으로 전환합니다. 이렇게 기록 일부를 교체하는 것이 Reorg입니다. 누군가 안나의 키를 훔치거나 서명을 바꾸지 않아도 결제가 다시 확인 대기 상태가 될 수 있습니다. 기준은 투표나 단순한 블록 수가 아니라 chainwork입니다. 각 블록이 난이도에 따라 입증한 작업량의 합을 말합니다. 유효하지 않은 분기는 작업량이 더 많아도 거부합니다. [1] [4]

이후 상태는 새 분기에 달려 있습니다. 새 분기에도 안나의 결제가 있다면 확인 수가 달라질 수는 있어도 확인된 상태는 유지됩니다. 없다면 Bitcoin Core는 결제를 Mempool로 되돌리려 할 수 있습니다. Mempool은 블록에 포함되기를 기다리는 미확인 거래의 임시 목록입니다. 하지만 복귀가 보장되지는 않습니다. 이전 거래의 출력에는 금액과 그 금액을 지출할 조건이 기록되어 있습니다. 새 분기에서 같은 자금을 다른 거래로 이미 썼을 수 있고, 사용하려는 이전 출력이 없거나 시간 조건 등 다른 수용 조건을 충족하지 못할 수도 있습니다. 다시 기다리는 결제와 새 기록에서 더 이상 허용되지 않는 결제는 구분해야 합니다. [1]

확인 1회는 결제가 들어 있는 블록을 뜻합니다. 그 뒤에 블록이 하나씩 추가될 때마다 확인이 늘고, 경쟁 분기가 넘어야 할 작업량도 늘어납니다. 따라서 최신 블록의 결제는 확인 1회이며, 받아들여진 기록 안에 깊이 자리할수록 그 부분을 교체하기가 대체로 어려워집니다. 하지만 유한한 확인 수만으로 교체가 절대 불가능하다는 수학적 보장을 얻지는 못합니다. 상점과 거래소는 결제 금액과 감수할 위험에 맞춰 대기 기준을 정합니다. [3] [5]

Reorg만으로 공격이 있었다고 단정할 수는 없습니다. 두 채굴자가 같은 이전 블록을 잇는 블록을 거의 동시에 찾을 수 있습니다. 정보는 즉시 전달되지 않으므로 노드들이 잠시 서로 다른 체인 끝을 따릅니다. 한 유효한 분기가 더 많은 작업량을 쌓으면 노드들은 그쪽으로 옮기고, 채택되지 않은 블록은 Stale Block이 됩니다. 다만 Double Spend 공격자는 같은 원리를 악용해 동일한 자금을 다른 곳에 지불한 기록을 받아들이게 하려 합니다. 따라서 전환 원인과 어떤 결제가 달라졌는지를 살펴야 합니다. [4] [5]

Reorg에서 노드는 같은 규칙을 유지하며 그 규칙을 만족하는 기록 중에서 고릅니다. Hard Fork는 유효성 규칙을 바꿔 구버전과 신버전 소프트웨어가 같은 블록을 다르게 판단할 수 있게 합니다. 재구성 자체가 새 화폐를 만들거나 비트코인 규칙을 다시 쓰는 것은 아닙니다. 다음 절에서는 노드가 이 기록 전환을 기술적으로 어떻게 수행하는지 설명합니다. [4]

Tip은 현재 받아들인 분기의 마지막 블록입니다. 분기점은 현재 활성 체인과 대체 분기가 공유하는 마지막 블록입니다. Reorg 깊이는 보통 이 공통 조상으로 돌아가기 위해 활성 체인의 끝에서 분리해야 하는 블록 수로 설명합니다. 한 블록 Reorg는 끝 블록을 교체하고, 더 깊은 Reorg는 여러 확인된 블록을 되돌립니다. 깊이는 각 노드의 현재 관점에 따라 달라집니다. [1]

Full Node는 규칙을 스스로 검사합니다. 아래 함수 이름은 Bitcoin Core의 구현을 가리킵니다. Bitcoin Core는 단순히 높이가 가장 크거나 가장 인기 있는 분기를 고르지 않습니다. 후보 체인은 활성화 과정에서 노드의 합의 규칙을 충족해야 하며, chainwork가 더 크다고 무효한 블록이 유효해지지는 않습니다. FindMostWorkChain은 무효하다고 알려지지 않은 후보 중 작업량이 가장 큰 후보를 고릅니다. 이것이 완전한 검증을 뜻하지는 않습니다. ActivateBestChain에서 블록을 연결할 때 추가 검사가 이루어집니다. 무효한 것으로 알려진 분기는 제외됩니다. [1]

UTXO는 아직 쓰지 않은 거래 출력이며 UTXO 집합은 이런 사용 가능한 출력의 모음입니다. undo 데이터에는 블록의 영향을 되돌리는 데 필요한 정보가 저장됩니다. DisconnectTip과 관련 검증 로직은 분리한 블록의 효과를 역순으로 되돌립니다. 소비된 UTXO는 복구되고, 제거한 블록이 만든 출력은 확인 상태를 잃습니다. 따라서 Bitcoin Core는 되돌리기 데이터를 보관하여 분기점의 UTXO 집합을 정확히 재구성할 수 있어야 합니다. [1]

여기서 rollback은 분리한 블록 이전 상태로 돌아가는 것이고, chainstate는 채택한 기록에 대응하는 노드의 작업 상태입니다. 되돌린 뒤 ConnectTip은 chainwork가 더 큰 분기의 블록을 정방향으로 연결합니다. 각 거래는 복구된 UTXO 집합과 해당 높이에서 적용되는 규칙에 따라 다시 검증됩니다. 결과는 하나의 특정 기록에 대응하는 chainstate이며 두 분기의 거래를 섞은 상태가 아닙니다. [1]

Coinbase Transaction은 블록의 첫 거래로 채굴자에게 보상을 배정합니다. 높이 h는 체인에서 블록의 위치를 뜻합니다. Coinbase 거래는 예외로, 블록을 분리한 뒤 mempool로 돌아가지 않습니다. 합의 규칙상 높이 h에서 생성한 coinbase 출력은 블록 h + 100에서 처음 사용할 수 있습니다. 끝 블록이 h + 99라면 원래 블록은 100회의 확인을 가지며, 성숙 조건은 다음 블록에 지출 거래를 포함하는 것을 허용합니다. Reorg가 coinbase를 담은 블록을 제거하면 그 블록의 보상은 활성 chainstate에서 사라집니다. 제거된 기록에 의존하던 후속 거래도 무효해질 수 있습니다. [1] [2] [3]

다음은 특정 프로그램 버전의 함수 이름이며 지갑 사용자가 추가로 해야 할 작업이 아닙니다. Bitcoin Core v29.0의 단계는 명확합니다. FindMostWorkChain은 무효하다고 알려지지 않은 후보 중 chainwork가 가장 큰 후보를 찾고, ActivateBestChainStep은 현재 끝 블록을 분리할 수 있습니다. ConnectTip은 대체 블록을 검증하고 연결하며, MaybeUpdateMempoolForReorg는 분리한 블록의 거래를 다시 검사합니다. 활성화 도중 후보가 무효함을 발견하여 다른 분기를 계속 찾을 수도 있습니다. 큰 Reorg는 더 많은 블록을 분리하고 연결해야 하므로 ActivateBestChain 처리 시간이 길어질 수 있습니다. [1]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 확인, Proof of Work, Stale Block, 이중 지불, Full Node, UTXO. 다음 항목에서도 이 글을 참조합니다 확인, 이중 지불, 코인베이스 트랜잭션, Soft Fork.

DOC · 001Bitcoin Core v29.0 — chain activation and mempool reconciliation1차 출처 DOC · 002Bitcoin Core v29.0 — coinbase maturity validation1차 출처 DOC · 003Bitcoin Core v29.0 — confirmation depth1차 출처 DOC · 004Bitcoin Developer Guide — Block Chain문서 DOC · 005Bitcoin whitepaper — Sections 5 and 111차 출처
개정일: 1차 출처 우선 · 투자 조언이 아닙니다