MSG_BLOCK

4바이트의 유형 태그가 여러 블록 형식 가운데 어느 것이 도착할지를 결정합니다. 유형 2는 원래 형식을 뜻합니다. 80바이트 헤더 뒤에 모든 트랜잭션이 전체로 이어지고, 위트니스 데이터는 제거되며, 블록이 담을 수 있는 400만 가중치 단위까지 이어집니다. 체인을 따라잡는 노드는 이런 요청을 수천 건 보내고 그 밖에는 거의 보내지 않습니다.

작동 방식

MSG_BLOCK는 메시지가 아니라 숫자이며, inv 메시지와 getdata 메시지를 구성하는 36바이트 항목 안에서만 의미를 지닙니다.

항목은 4바이트 유형 뒤에 32바이트 해시가 이어지는 구조이며, 유형은 해시가 무엇을 가리키는지 수신자에게 알려 줍니다. 유형 2 항목을 담은 getdata를 보내는 것은 이 블록의 해시를 가지고 있으니 블록을 보내 달라는 뜻입니다. 피어는 블록 메시지 하나로 응답하거나, 제공할 수 없으면 notfound로 응답합니다. 프루닝된 노드는 이미 삭제한 대상에 대해 notfound를 반환하며, 그래서 프루닝된 피어는 처음부터 동기화하는 사람에게 쓸모가 없습니다.

유형 2 단독은 이제 예전보다 좁은 의미를 가집니다. 세그윗이 2017년에 활성화된 이후로, 이 방식으로 요청한 블록은 위트니스 데이터가 제거된 옛 직렬화 형식으로 돌아오며, 이는 오래된 소프트웨어에도 계속 서비스하려면 필요했습니다. 블록을 검증하려는 노드는 그 위트니스가 필요하므로 0x40000000 비트를 설정하고 대신 위트니스 변형을 요청합니다. 현대적인 피어 두 곳 사이에서는 단순 코드가 주로 아무도 업데이트하지 않은 소프트웨어의 요청에서 나타납니다.

공지 방식도 달라졌습니다. BIP130은 헤더 직접 공지를 도입했고, Bitcoin Core 0.12.0 이후로 새 블록은 보통 inv가 아니라 headers 메시지로 공지되므로, 이 유형 코드는 이제 대부분 대화의 요청하는 쪽에 남아 있습니다.

Bitcoin Core는 다운로드 중에 한도 없이 앞서 나가지 않습니다. 마지막으로 검증한 블록에서 1,024개 블록의 윈도를 유지하므로, 피어 하나가 멈춰도 노드가 연결할 방법이 없는 블록의 끝없는 대기열을 안고 있게 되지는 않습니다.

확인할 수 있는 곳

블록 요청은 노드 트래픽을 정확히 한 번, 첫 동기화 동안 지배하며 그 뒤로는 거의 다시 나타나지 않습니다.

체인은 2024년 4월 20일의 반감기에서 840,000개 블록을 넘어섰고 하루에 대략 144개 블록씩 늘어나므로, 새로 시작한 기기는 최신 상태가 되기 전에 거의 100만 개를 내려받습니다. 이는 피어마다 메시지 유형별 바이트를 세는 getpeerinfo로 확인하거나 -debug=net을 붙인 로그에서 확인할 수 있습니다. 노드가 최신 끝에 도달하면 그 카운터는 조용해지고 컴팩트 블록 트래픽이 그 자리를 차지합니다.

MSG_BLOCK vs MSG_CMPCT_BLOCK

MSG_BLOCK와 MSG_CMPCT_BLOCK는 무엇을 가져오는지뿐 아니라 어디에서 허용되는지에서도 다릅니다. 유형 2는 inv와 getdata에서 모두 허용되며, 사전 합의 없이 어떤 피어에게든 보낼 수 있고, 어떤 시기의 블록에도 쓸 수 있습니다. 유형 4는 getdata에서만 허용되며, sendcmpct 메시지로 이미 컴팩트 블록을 제안한 피어에게만 보낼 수 있고, Bitcoin Core에서는 가장 최근 5개 블록에 대해서만 서비스됩니다. 유형 4로 그보다 깊은 블록을 요청하면 그래도 전체 블록 메시지가 돌아옵니다.