헤더 우선 동기화

내려받기를 둘로 나누는 것이 최초 동기화를 실용적으로 만듭니다. Bitcoin Core는 2015년 2월에 출시된 버전 0.10.0부터 이렇게 작동했으며, 이 버전은 블록 가져오기를 하나의 정렬된 대기열에서 연결된 모든 피어에 분산된 작업으로 바꿨습니다. 자신의 잔액을 검증하려고 직접 노드를 운영한다면, 최초 동기화가 며칠이 아니라 몇 시간 만에 끝나는 이유가 여기에 있습니다.

작동 방식

헤더 우선 동기화는 피어에게 블록이 아니라 헤더를 요청하는 것으로 시작합니다.

노드는 자신이 현재 어디에 있다고 보는지를 설명하는 해시의 간결한 목록인 블록 로케이터를 담은 getheaders 메시지를 보냅니다. 피어는 각각 80바이트인 헤더를 최대 2,000개 담은 headers 메시지로 응답하므로, 응답 하나가 대략 2주 분량의 체인을 포함합니다. 노드는 각 헤더에 대해 그것이 이미 가지고 있는 부모를 가리키는지, 그리고 그 해시가 nBits 필드가 주장하는 난이도를 충족하는지를 확인한 뒤, 어떤 피어도 더 새로운 것을 제시하지 못할 때까지 새로운 끝점에서 다시 요청합니다.

이 골격이 갖춰진 뒤에야 본문 내려받기가 시작됩니다. 노드는 원하는 모든 블록의 해시를 이미 알고 있으므로, 하나의 연결 뒤에 대기하는 대신 여러 피어에 서로 다른 구간을 동시에 요청할 수 있습니다. Bitcoin Core는 피어 하나에 남겨 두는 블록 요청 수를 제한하며, 현재 코드에서는 16개이고, 이 창을 정체시키는 피어는 연결을 끊습니다. 부모보다 먼저 도착한 블록은 그대로 보류되며, 이로써 검증되지 않은 데이터를 디스크에 임시로 두던 예전 관행이 사라졌습니다.

두 가지 안전장치가 헤더와 함께 작동합니다. 소프트웨어는 보유한 헤더의 누적 작업 증명이 릴리스에 컴파일된 최소 수치를 넘을 때까지 체인을 확정하지 않으므로, 피어가 손쉬운 블록으로 만든 값싼 사이드 체인으로 새 노드를 유인할 수 없습니다. 이와 별개로 assumevalid 설정은 각 버전에 포함된 최근 블록 해시를 지정합니다: 그 아래에 묻힌 블록의 서명은 다시 확인하지 않으며, 이는 수 시간의 타원 곡선 연산을 없애 주면서 현재 체인 상태에 의존하는 모든 규칙은 여전히 적용됩니다.

확인할 수 있는 곳

헤더 우선 동기화는 노드가 따라잡는 동안 서로 어긋나는 두 개의 카운터로 나타납니다.

최초 동기화 중에 getblockchaininfo를 호출하면 headers 필드는 blocks 필드보다 훨씬 앞서 있으며, 흔히 수십만 개 차이가 납니다. 그래픽 클라이언트도 같은 내용을 쉬운 말로 알려 줍니다: 헤더가 도착한 뒤에야 완료 시간을 추정할 수 있는데, 그때까지는 남은 거리를 알 수 없기 때문입니다. 이 두 수치가 서로 가까워지는 것을 지켜보는 것이 정직한 진행 표시줄입니다.

경량 소프트웨어는 의도적으로 전반부에서 멈춥니다. SPV 지갑, 컴팩트 필터 클라이언트, 또는 자체 체인 백엔드 없이 실행되는 라이트닝 노드는 헤더만 보관하고 그 위에 머클 증명이나 필터를 얹습니다. 휴대폰 지갑이 모바일 데이터로 자신의 내역을 확인할 수 있는 이유가 바로 이것입니다: 헤더는 작고 크기가 고정되어 있지만, 블록 본문은 그렇지 않습니다.

헤더 우선 동기화 vs 블록 우선 동기화

헤더 우선 동기화는 내용을 내려받기 전에 체인의 형태를 파악하는 반면, 블록 우선 동기화는 두 가지를 한꺼번에 하려고 했습니다. 예전 방식은 getblocks 메시지를 보내고 500개 이하의 블록 해시를 담은 inv를 받아, 응답한 피어로부터 하나씩 가져왔으므로 느린 연결 하나가 그 뒤의 모든 것의 속도를 제한했습니다. 순서가 어긋나 도착한 것은 공격자가 잡동사니로 채울 수 있는 메모리상의 보류 풀 외에는 머물 곳이 없었습니다. Bitcoin Core는 0.10.0 이후로 그런 방식으로 동기화하지 않지만, 구형 소프트웨어가 통신할 수 있도록 해당 메시지는 여전히 이해합니다.