블록 우선 동기화

지금은 아무도 이 방식으로 동기화하지 않으며, 그 이유는 산술에 있습니다. 엄격하게 순차적인 다운로드는 피어 한 곳의 업로드 속도 이상을 활용할 수 없고, 2015년에 이르러서는 체인이 이미 너무 커져 이 방식으로 합리적인 시간 안에 완료할 수 없었습니다. 이 기법은 프로토콜의 대체 수단으로, 그리고 오래된 문서에서 혼란의 원천으로 남아 있습니다.

작동 방식

상태: 블록 우선 동기화는 Bitcoin Core 0.10.0에서 헤더 우선 동기화로 대체되었으며, 해당 버전은 2015년 2월 16일에 공개되었습니다. 이 방식이 사용하던 메시지는 여전히 피어 간 프로토콜의 일부이며 여전히 응답되지만, 현재의 어떤 클라이언트도 동기화를 위해 이 메시지에 의존하지 않습니다.

교환은 두 기계 사이의 반복이었습니다. 사용자의 노드는 이미 보유한 블록의 해시를 담은 getblocks 메시지를 보냈습니다. 피어는 그 뒤에 오는 최대 500개의 블록 해시를 나열한 목록으로 응답했습니다. 사용자의 노드는 getdata로 해당 블록을 요청하고, 수신하고, 각 블록을 완전히 검증한 뒤 다음에 무엇이 오는지 묻기 위해 다시 getblocks를 보냈습니다. 이를 수천 번 반복했습니다.

이 설계에서 세 가지 문제가 나왔습니다. 병렬성이 없었는데, 아직 존재한다는 통보조차 받지 못한 블록을 두 번째 피어에게 요청하는 것은 합리적이지 않았기 때문에 전체 동기화는 당시 대화 중이던 피어의 속도로 진행되었습니다. 얼마나 남았는지 알 방법도 없었는데, 체인이 한 번에 500개의 해시씩 드러났기 때문이며, 그래서 오래된 클라이언트는 의미 있는 진행 표시줄을 보여줄 수 없었습니다. 또한 느리거나 적대적인 피어가 블록을 조금씩 흘려보낼 수 있었고, 사용자의 노드가 다른 곳에 더 나은 체인이 있다는 사실을 저렴하게 알아낼 방법이 없었습니다.

헤더 우선 방식은 저렴한 증거와 비싼 증거를 분리하여 세 가지 문제를 모두 해결했습니다. 먼저 헤더 체인을 가져와 검증하면, 2014년 12월 기준 전체 이력을 27메가바이트로 확인할 수 있고, 트랜잭션을 하나도 다운로드하기 전에 최선 체인의 형태와 길이를 모두 알 수 있습니다. 그런 다음 블록 본문은 여러 피어에게 동시에 요청할 수 있습니다. 부작용은 블록이 순서 없이 도착하여 순서 없이 디스크에 기록되기 시작했다는 점이며, 그래서 0.10.0 버전이 만든 데이터 디렉터리는 그보다 오래된 어떤 소프트웨어도 읽을 수 없습니다.

접하는 곳

블록 우선 동기화는 소프트웨어보다는 문서에서 접하게 됩니다.

2015년 이전에 작성된 참고 자료, 여전히 유통되는 개발자 자료의 상당 부분을 포함하여, 순차 반복을 마치 비트코인이 그렇게 작동하는 것처럼 설명합니다. 그렇지 않으며, 최초 동기화를 단일 피어의 순차 다운로드로 설명하는 문서는 단순히 오래된 것입니다. Bitcoin Core는 매우 오래되었거나 특이한 클라이언트를 위해 getblocks 요청에 계속 응답하므로, 이 메시지는 패킷 캡처와 프로토콜 명세에 나타납니다.

오늘날 노드를 운영하는 사람에게는 설정할 것도 선택할 것도 없습니다. 유지 관리되는 모든 구현이 그렇듯 사용자의 클라이언트도 헤더를 먼저 가져옵니다.

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

블록 우선 동기화와 헤더 우선 동기화는 먼저 무엇을 요청하는지에서 다르고, 나머지는 모두 그로부터 따라옵니다. 블록 우선 방식은 전체 블록을 순서대로 요청하고 그 과정에서 체인의 형태를 파악했기 때문에, 최선 체인을 발견하는 일과 다운로드하는 일을 같은 느린 과정에서 수행했습니다. 헤더 우선 방식은 작업을 나눕니다. 블록당 80바이트를 사용하여 어느 체인이 가장 많은 작업 증명을 담고 있는지 확인한 다음, 본문은 보내려는 피어들로부터 병렬로 수집합니다. 각 블록에 적용되는 검증은 두 방식에서 동일합니다. 바뀐 것은 작업 순서뿐이며, 그것만으로 최초 동기화가 몇 주에서 몇 시간으로 줄었습니다.