헤더 체인

노드는 두 가지를 동시에 추적합니다. 자신이 신뢰하는 헤더와 자신이 저장한 블록 본문입니다. 헤더는 하나에 80바이트이므로, 약 52,560개 블록에 해당하는 1년치 헤더는 대략 4.2MB가 됩니다. 이런 크기 차이 덕분에 지갑은 특정 블록 안에 무엇이 들어 있는지 알기 훨씬 전에 체인의 현재 높이와 누적된 총 작업량을 알 수 있습니다.

작동 방식

헤더 체인은 포함된 블록의 수가 아니라 누적된 작업 증명을 기준으로 정렬됩니다.

모든 헤더는 부모를 가리키므로, 노드가 들은 헤더의 모음은 선이 아니라 트리를 이룹니다. 총 작업량이 가장 큰 가지가 최선의 헤더 체인이며, 노드는 나중에 그중 하나가 앞지를 경우에 대비해 진 가지도 기억합니다. Bitcoin Core는 이 트리를 블록 인덱스에 보관하는데, 이는 blocks/index 디렉터리 아래의 작은 LevelDB 데이터베이스로, 트랜잭션을 담은 원시 블록 파일과 완전히 분리되어 있습니다.

트리를 보관하기 때문에 노드는 자신의 불확실성을 설명할 수 있습니다. getchaintips 명령은 자신이 아는 모든 끝단을 상태와 함께 나열합니다. 따르고 있는 가지에는 active, 본문을 한 번도 내려받지 않은 가지에는 headers-only, 경쟁에서 진 완전히 검증된 가지에는 valid-fork, 규칙을 위반한 가지에는 invalid가 붙습니다. 체인 재구성은 노드가 필요한 블록을 확보한 뒤 그 트리를 가로질러 한 끝단에서 다른 끝단으로 이동하는 것에 지나지 않습니다.

헤더는 블록 데이터가 견디지 못하는 일을 견딥니다. 프루닝 노드는 공간을 절약하려고 오래된 블록 파일을 삭제하며, Bitcoin Core가 받아들이는 가장 작은 설정인 prune=550에서도 제네시스 블록부터의 모든 헤더를 보관합니다. 헤더가 없으면 새 블록이 이미 받아들인 체인 위에 쌓이는지 확인할 수 없으므로, 헤더는 결코 버릴 수 없는 부분입니다.

확인할 수 있는 곳

헤더 체인은 노드가 얼마나 뒤처져 있는지 알려줄 때 인용하는 숫자입니다.

getblockchaininfo를 실행하면 blocks와 headers 두 필드가 나옵니다. headers는 최선의 헤더 체인의 높이이고, blocks는 그중 얼마나 내려받아 완전히 검증했는지를 나타내며, 둘의 차이가 아직 남은 작업입니다. 동기화가 끝난 노드에서는 두 값이 일치하며, headers 값이 멈춰 있는 노드는 단지 느린 노드가 아니라 피어와의 연결이 끊어진 노드입니다.

경량 지갑은 그 밖의 것을 보관하지 않습니다. SPV 지갑이나 컴팩트 필터 클라이언트는 헤더만 저장하고, 이를 이용해 자신이 관심 있는 트랜잭션이 실제 작업 증명 아래에 있는지 확인합니다. 난이도도 헤더에서 계산할 수 있습니다. 목표값은 체인에 이미 있는 타임스탬프와 nBits 값만으로 2,016개 블록마다 재설정되므로, 클라이언트는 트랜잭션을 한 번도 보지 않고도 자신이 세는 작업이 진짜인지 검증할 수 있습니다.

헤더 체인 vs 블록 헤더

블록 헤더는 80바이트의 레코드 하나이고, 헤더 체인은 그것들이 2009년 1월 3일의 제네시스 블록까지 연결된 전체입니다. 누군가 경량 클라이언트가 작업 증명을 검증한다고 말할 때 이 구분이 중요합니다. 헤더 하나는 블록 하나를 만들기에 비용이 많이 들었다는 것만 증명합니다. 각 헤더가 부모를 확정하는 헤더들의 연쇄만이 특정 블록이 아무도 몰래 바꾸지 않은 끊김 없는 고비용 작업의 연속 뒤에 있다는 것을 증명합니다.