IBD는 단순한 파일 다운로드가 아니다. Full Node는 역사에서 검증된 UTXO 집합을 구축하며, 오래된 스크립트 검사는 assumevalid 설정에도 영향을 받는다.
노드는 피어 주소를 발견하고 헤더를 동기화한다. 헤더는 역사를 연결하고 Proof of Work를 포함하지만 블록 안 모든 거래의 유효성을 혼자 증명하지 않는다. [Bitcoin Developer Guide — Initial Block Download] [Satoshi Nakamoto — Bitcoin whitepaper]
누적 작업량은 검증할 후보 분기를 정한다. 가장 많은 헤더 수나 피어의 주장은 작업량과 완전한 블록 검사를 대신하지 못한다. [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — validation] [Satoshi Nakamoto — Bitcoin whitepaper]
여러 피어에서 블록을 병렬로 받을 수 있다. 유효한 체인에 연결할 때는 이전 상태를 따라야 하므로 필요한 역사 없이 거래 출력을 검증할 수 없다. [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — validation]
Full Node는 구조, Merkle root, 지출 규칙, 발행 제한 등을 검사한다. 합의 규칙은 높이와 활성화에 따라 적용되며 헤더만으로는 완전한 검증이 아니다. [Bitcoin Core — validation] [Bitcoin Core — chainstate]
블록을 연결하면 사용된 출력이 제거되고 새 UTXO가 추가된다. 이 데이터베이스는 현재 지출 가능성을 나타내며 모든 과거 거래나 주소 잔액 장부가 아니다. [Bitcoin Core — validation] [Bitcoin Core — chainstate]
알려진 역사가 충분히 깊다는 등의 조건에서 assumevalid는 오래된 스크립트 검사를 생략할 수 있다. 임의의 역사를 무검사로 수락하는 것이 아니며 assumevalid=0은 이 최적화를 끈다. [Bitcoin Core — validation]
가지치기는 처리한 오래된 블록 파일을 지우고 UTXO 집합과 필요한 메타데이터를 남긴다. 영구 저장 공간을 아끼지만 보통의 IBD에서 역사를 확보하고 처리할 필요는 없애지 않는다. [Bitcoin Core — validation] [Bitcoin Core — chainstate]
Bitcoin Core v29.0은 선단의 나이, 최소 작업량, 로딩 상태를 사용한다. 완료 후 같은 프로세스에서 플래그가 true로 돌아가지 않는다. 이는 운영상 추정 기준이지 전 세계 최신 선단의 증명이 아니다. [Bitcoin Core — validation] [Bitcoin Core — getblockchaininfo]
시간은 CPU, 메모리, 디스크, 네트워크, 피어 가용성에 달려 있다. getblockchaininfo의 verificationprogress는 검증 작업 추정치이며 완료 시각 보장이나 단순한 다운로드 바이트 비율이 아니다. [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — getblockchaininfo]
AssumeUTXO는 지원되는 UTXO 스냅샷으로 선단에서 더 일찍 운영하게 할 수 있다. 역사는 백그라운드에서 검증되고 결과를 스냅샷과 비교하므로 빠른 사용 가능성이 역사 검증 완료를 뜻하지 않는다. [Bitcoin Core — validation] [Bitcoin Core — AssumeUTXO design]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Pruned node, AssumeUTXO, Block propagation, Compact block relay. 다음 항목에서도 이 글을 참조합니다 Pruned node, AssumeUTXO.