Finality는 결제의 최종성, 즉 완료된 이전이 그대로 유지될 것이라고 얼마나 믿을 수 있는지를 뜻합니다. Bitcoin은 추가되는 유효한 작업에 따라 강해지는 확률적 보장을 제공합니다. 어떤 보편적인 확인 횟수도 그 자체만으로 체인 가지의 변경을 배제하거나 전체 계약의 법적 이행을 결정하지는 않습니다.
처음에 폴이 알 수 있는 것은 지갑이 해당 거래를 인식했다는 사실뿐입니다. 이는 거래가 블록에 포함되었다는 뜻이 아닙니다. 블록이 만들어지고 뒤에 다른 블록이 이어질수록, 그 기록을 대체하려면 넘어야 하는 작업량이 늘어납니다. 실제 Finality는 이렇게 강해집니다. 다만 잠재적 공격자의 자원과 네트워크 상태도 중요합니다. 프로토콜이 수학적인 불가역성 인증서를 발급하는 것은 아닙니다. 수취인은 그 결제를 받아들일 근거가 얼마나 탄탄한지 판단해야 합니다. [1] [2]
Full Node는 Bitcoin 규칙을 독립적으로 검증하는 노드입니다. 기록이 길다는 이유만으로 받아들이지 않습니다. 먼저 유효성을 검사하고, 유효한 가지 중 누적 작업량이 가장 큰 가지를 선택합니다. 이는 블록으로 입증된 작업량이지, 사람 수나 보유 코인 수에 따른 투표가 아닙니다. 작업이 더 많다고 무효한 거래가 유효해지지는 않습니다. 폴은 결제가 규칙에 맞는지와 현재 사용하는 유효한 기록 속에 얼마나 깊이 들어 있는지, 두 가지를 모두 확인해야 합니다. [1]
이 예에서 폴의 거래는 높이 800000인 블록에 있고, 같은 가지의 현재 끝은 높이 800005입니다. 높이는 시간 대신 블록의 위치를 나타냅니다. 계산은 800005 − 800000 + 1 = 6회 확인이며, 거래가 들어 있는 블록 자체도 포함합니다. 뒤에 추가된 블록만 세는 것이 아닙니다. 결제가 해당 노드의 미확인 거래 모음인 mempool에만 있다면 확인 횟수는 0입니다. 시간이 흐르기만 해서는 횟수가 늘지 않습니다. [2] [3]
네트워크가 잠시 경쟁하는 블록들을 알게 된 뒤, 작업량이 더 큰 다른 유효한 가지를 따라갈 수 있습니다. 이렇게 활성 기록이 바뀌는 것을 재구성이라고 합니다. Bitcoin Core 28.0 문서에서 블록 헤더 조회 getblockheader는 그 블록이 활성 체인 밖에 있으면 confirmations = -1을 반환합니다. 이는 블록의 상태이지, 그 안의 모든 결제가 사라졌다는 뜻이 아닙니다. 폴의 거래는 새 가지에도 포함되어 있거나, 미확인 상태로 기다리거나, 다른 거래와 충돌할 수 있습니다. 해당 거래의 상태를 다시 확인해야 합니다. [1] [3]
개발자 안내서는 가치가 큰 결제에 흔히 쓰는 기준으로 6회 확인을 언급하면서 위험 평가의 필요성도 설명합니다. 이는 수취인의 수락 규칙이지 Bitcoin 합의가 바뀌는 지점이 아닙니다. 폴은 자전거의 가치, 가능한 손실, 검증의 신뢰성을 고려해야 합니다. 숫자가 대신 결정해 주지는 않습니다. 평균이 대략 한 시간이라고 해서 블록 여섯 개가 언제나 한 시간 안에 나오는 것도 아닙니다. 채굴에는 고정 시간표가 없으며, 오래된 일반 지침이 모든 상황을 보장하지는 않습니다. [2]
폴은 확인된 BTC를 받고도 자전거의 인도나 상태를 두고 다툴 수 있습니다. 금융시장 인프라에 관한 국제 원칙인 PFMI는 최종 결제 시점과 참여자가 지시를 철회할 수 없게 되는 경계를 명확히 정하도록 요구합니다. 이는 Bitcoin 블록 수를 세는 것과 다른 틀입니다. 확인만으로 계약의 법적 효과, 은행 결제의 최종성, 판매 물품의 소유권 이전이 결정되지는 않습니다. 결제 검증은 중요하지만 거래의 다른 조건을 대신하지 않습니다. [4]
폴과 구매자가 환불에 합의하면, 보통 원래 결제의 수취인이 새로운 거래를 보냅니다. 최초 송금은 기록에 남습니다. Bitcoin에는 요청을 받고 버튼 하나로 확인된 결제를 취소하는 중앙 고객센터가 없습니다. 재구성은 네트워크의 활성 기록을 바꾸는 현상이지, 실수를 고쳐 주는 고객 서비스가 아닙니다. 따라서 보내기 전에 수취인과 금액을 확인해야 합니다. 확인을 더 기다려도 잘못 입력한 결제가 바로잡히지는 않습니다. [5]
결제 앱 운영자의 일은 결제를 수락했다고 끝나지 않습니다. 거래와 해당 블록, 검증 출처를 기록하고 노드가 네트워크보다 뒤처졌는지 알아내야 합니다. confirmations 값은 조회 시점의 상태이며 영구 인증서가 아닙니다. 횟수가 줄거나 충돌이 생기면 미리 정한 처리 규칙에 따라 활성 가지를 다시 확인해야 합니다. 오래된 화면 캡처는 새로운 증거가 아닙니다. 폴에게도 핵심은 예전에 지갑에 보였던 내용만이 아니라 지금 결제 상태를 바탕으로 결정하는 것입니다. [2] [3]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 확인, Proof of Work, Settlement risk, Delivery versus payment. 다음 항목에서도 이 글을 참조합니다 Byzantine Generals Problem, Delivery versus payment.