블록 헤더

호기심

1. 단 80바이트짜리 구조가 어떻게 수백만 달러 규모의 트랜잭션 데이터에 암호학적으로 커밋할 수 있을까요?
2. 채굴자가 이점을 얻기 위해 타임스탬프 필드를 조작하는 것을 막는 구체적인 규칙은 무엇인가요?
3. 스마트폰이 비트코인 네트워크의 전체 이력을 다운로드하지 않고도 그 보안을 검증할 수 있는 이유는 무엇일까요?

탐구

1. 모든 비트코인 블록은 80바이트 헤더로 시작하며, 그 뒤에 길이가 가변적인 트랜잭션 목록이 이어집니다. 트랜잭션 목록은 블록당 약 400만 바이트에 이를 수 있지만, 작업증명(PoW) 해싱과 체인 식별에는 헤더만 사용됩니다. 이처럼 크기 차이가 극단적이기 때문에 헤더는 블록 전체를 대표하는 압축된 지문 역할을 하며, 노드는 대용량 데이터를 다운로드하기 전에 메타데이터를 먼저 처리할 수 있습니다.
2. 첫 번째 필드는 4바이트를 차지하는 ‘version’입니다. 원래는 소프트웨어 버전을 추적하기 위한 용도였지만, 현재는 BIP9에 따른 소프트 포크 시그널링 비트를 담고 있습니다. 채굴자들은 새로운 합의 규칙이 활성화되기 전에 해당 규칙을 지지한다는 뜻을 나타내기 위해 특정 버전 번호를 설정합니다. 이 필드에는 제약 조건도 따르는데, 예를 들어 BIP34는 version-2 블록이 코인베이스 트랜잭션 스크립트에 블록 높이를 포함하도록 요구했습니다. 이는 헤더가 네트워크 전반에 구조적 변경을 어떻게 강제하는지 보여줍니다.
3. ‘이전 블록 해시’(32바이트)는 직전 헤더의 이중 SHA-256 해시를 담음으로써 각 블록을 부모 블록과 연결합니다. 과거 블록의 바이트 하나만 바꿔도 그 블록의 해시가 달라지고, 그 결과 이후 모든 블록과의 연결이 끊어집니다. 이러한 해시 체인 덕분에 이후 모든 블록의 연산 작업을 다시 수행하지 않는 한 과거 데이터를 변경할 수 없습니다.
4. ‘머클 루트’(32바이트)는 블록 안의 모든 트랜잭션에 대한 암호학적 지문 역할을 합니다. 머클 루트는 트랜잭션 ID 쌍을 재귀적으로 해시하여 하나의 값만 남을 때까지 계산해 얻습니다. 이 구조는 단순 지불 검증(SPV)을 가능하게 합니다. 즉, 라이트 클라이언트는 전체 블록을 다운로드하지 않고도 이 루트와 소수의 형제 해시만으로 특정 트랜잭션이 블록에 포함되었음을 증명할 수 있습니다.
5. ‘타임스탬프’(4바이트)는 유닉스 에포크 초 단위로 블록 생성 시간을 기록합니다. 조작을 방지하기 위해 합의 규칙에 따라 이 값은 이전 11개 블록의 중앙값보다 커야 하며, 해당 노드의 자체 시계보다 2시간 이상 앞선 경우에는 거부됩니다(비트코인 코어 27부터는 노드의 시스템 시간을 사용하며, 이전 버전에서는 피어들이 조정한 시간을 사용했습니다). 이러한 제약 조건들 덕분에 난이도 계산에 필요한 정확도를 유지할 수 있으면서도 네트워크 전파 지연으로 인한 약간의 변동은 허용됩니다.
6. 나머지 필드는 작업증명 목표값을 압축해 인코딩한 ‘nBits’(4바이트)와, 유효한 해시를 찾기 위해 채굴자들이 바꿔 가며 대입하는 임의의 숫자인 ‘nonce’(4바이트)입니다. 헤더는 크기가 작기 때문에 2009년 이후의 모든 헤더를 저장하는 데 필요한 공간은 100MB 미만입니다. 라이트 클라이언트는 이 전체 이력을 보관하면서 모든 작업증명 조건을 독립적으로 검증할 수 있고, 트랜잭션을 확인하지 않고도 누적 작업량이 가장 많은 체인이 유효하다고 간주할 수 있습니다.

핵심 사실

연습 아홉, 여섯, 셋, 하나

팩트 체크

날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.

• Bitcoin Developer Reference: Block Headers
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 11
• BIP9: Version bits-based consensus signalling (GitHub)