블록체인/레벨 III · 네트워크/3.1 노드/수업 3
초기 블록 다운로드
처음부터 역사를 재구성하기: 독립적 검증의 비용
준비물RAM이 최소 8GB 이상이고 SSD가 장착된 컴퓨터비트코인 코어 소프트웨어(최신 안정 버전)`bitcoin-cli` 터미널 접근
호기심
- 새로운 노드는 어떤 블록도 다운로드하기 전에 왜 블록 헤더를 먼저 다운로드할까요?
- ‘assumevalid’가 활성화되면 어떤 특정 검사들이 생략되며, 왜 그것이 안전한 것인가요?
- 대역폭이 드라이브를 몇 분 만에 채울 만큼 빠른데도, 초기 동기화에 여전히 며칠이 걸릴 수 있는 이유는 무엇일까요?
탐구
- 새로 설치한 비트코인 코어 인스턴스에는 소스 코드에 하드코딩된 제네시스 블록만 들어 있습니다. 이 인스턴스는 체인의 길이나 유효성에 대해 아무것도 알지 못합니다. 피어와 연결되면 초기 블록 다운로드(Initial Block Download, IBD)를 시작하는데, 이는 2009년 1월 3일부터 현재의 체인 끝(팁)까지 전체 역사를 재구성하는 과정입니다. 이는 수동적인 복사가 아니라, 아래에서 설명할 지름길을 제외하면 각 블록을 받아들이기 전에 합의 규칙에 따라 검사하는 능동적인 재구성입니다.
- 버전 0.10(2015년)부터 IBD는 2단계 전략을 따릅니다. 먼저 노드는 용량이 작아 빠르게 전송되는 모든 블록 헤더를 다운로드합니다. 이 헤더들의 작업증명을 검증해 난이도 목표를 충족하는지 확인하고, 아직 트랜잭션 유효성은 검사하지 않은 채 작업량의 체인을 구축합니다. 헤더 체인이 확립되면 노드는 여러 피어에게 전체 블록을 병렬로 요청하고, 도착하는 대로 순차적으로 검증합니다.
- 트랜잭션 검증은 암호학적 서명 검사 때문에 계산 비용이 큽니다. 동기화 속도를 높이기 위해 버전 0.14(2017년)에서 'assumevalid'가 도입되었습니다. 이 파라미터는 널리 검토된 블록의 하드코딩된 해시보다 아래에 묻힌 모든 블록에 대해 서명 검증을 건너뜁니다. 노드는 작업증명, 금액, UTXO 세트를 포함한 나머지 모든 항목을 여전히 검사하며, 그 깊은 과거 구간에 대해서만 스크립트와 서명 검사를 생략합니다. 사용자는 이 기능을 비활성화해 제네시스 블록부터 모든 서명을 하나하나 검증할 수 있지만, 그 대가로 동기화 시간이 크게 늘어납니다.
- 최신 버전에는 실험적 기능인 'assumeUTXO'가 있어, 노드가 미리 계산된 현재 UTXO 세트의 스냅샷으로 시작할 수 있습니다. 노드는 백그라운드에서 전체 이력을 검증하는 동안에도 빠르게 사용 가능한 상태가 됩니다. 이 검증이 끝날 때까지는 해시가 소프트웨어에 하드코딩된 스냅샷을 신뢰하며(파일 자체는 어디서든 받을 수 있음), 검증이 끝난 뒤에는 완전히 독립적으로 작동합니다.
- IBD에 걸리는 시간은 하드웨어에 따라 크게 달라집니다. 빠른 SSD와 8GB RAM을 갖춘 최신 컴퓨터에서는 동기화에 몇 시간이 걸릴 수 있습니다. Raspberry Pi 같은 제약이 많은 장치에서는 며칠 이상 걸릴 수도 있습니다. 병목은 대역폭인 경우가 드물며, UTXO 캐시(dbcache)를 위한 디스크 쓰기 속도와 스크립트 검증을 위한 CPU 성능이 병목이 됩니다. 노드는 상태를 끊임없이 읽고 써야 하므로, 느린 하드 드라이브를 쓰면 기가비트 인터넷이 있어도 과정이 정체됩니다.
- 동기화가 끝나면 노드는 작업량이 가장 많은 유효 체인의 끝(팁)에 도달합니다. 이제 노드는 관찰자에서 완전한 참여자로 전환되어, 피어들에게 트랜잭션과 블록을 전달할 수 있게 됩니다. `bitcoin-cli getblockchaininfo` 명령의 `verificationprogress` 필드로 이 진행 상황을 확인할 수 있으며, 과거 체인이 검증될수록 이 값은 1.0에 가까워집니다. 그 시점에 노드는 독립적으로 검증한, 화폐의 전체 역사에 대한 완전한 사본을 보유하게 됩니다.
핵심 사실
- 비트코인 코어 버전 0.10(2015)은 초기 블록 다운로드를 최적화하기 위해 헤더 우선 동기화 방식을 도입했습니다.
- 버전 0.14의 'assumevalid' 파라미터는 동기화 속도를 높이기 위해 하드코딩된 해시보다 아래에 있는 블록의 서명 검사를 생략합니다.
- 'assumeUTXO'는 노드가 UTXO 스냅샷에서 시작해 백그라운드에서 이력을 검증할 수 있게 해 주며, 최근 버전에 실험적으로 도입되었습니다.
- IBD 중에는 UTXO 캐시의 디스크 쓰기 속도와 메모리 할당이 대역폭보다 더 큰 병목 요인이 되는 경우가 많습니다.
- 새로운 노드는 여러 피어로부터 블록을 병렬로 다운로드하더라도 순차적으로 검증합니다.
- `bitcoin-cli getblockchaininfo`는 체인의 얼마나 많은 부분이 검증되었는지를 나타내는 `verificationprogress` 값을 표시합니다.
연습 아홉, 여섯, 셋, 하나
9모으기비트코인 노드를 운영하는 데 사용되는 9가지 서로 다른 하드웨어 구성(CPU, RAM, 스토리지 유형)을 나열하십시오. 새로 설치했을 때 각 구성에서 보고되는 일반적인 동기화 시간도 함께 기재해 주십시오.
6묶기이 9가지 구성을 주요 병목 요인에 따라 CPU 제한형, RAM 제한형, 디스크 I/O 제한형, 대역폭 제한형, 혹은 균형형의 6개 카테고리로 분류하십시오.
3추리기6가지를 초기 동기화에 걸리는 시간을 가장 크게 좌우하는 3가지 요인으로 압축하십시오.
1결정화초기 블록 다운로드에서 동기화 속도와 암호학적 독립성 사이의 트레이드오프를 한 문장으로 설명하십시오.
팩트 체크
날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.