표준 블록 중계

수신자가 대부분 이미 가지고 있던 데이터를 위해, 중계 구간마다 왕복 두 번과 한 메가바이트 이상의 데이터가 오갑니다. 2013년 측정 연구에서는 새 블록이 발견된 뒤 노드가 그 사실을 알게 되는 시간의 중앙값을 6.5초, 평균을 12.6초로 측정했습니다. Bitcoin Core는 2016년 8월 23일에 버전 0.13.0에서 컴팩트 블록 중계를 선보였고, 표준 중계는 대체 경로가 되었습니다.

작동 방식

표준 블록 중계는 세 가지 메시지를 사용하며, 수신 노드가 이미 무엇을 보유하고 있는지에 대해 아무것도 가정하지 않습니다.

블록을 찾은 노드는 새 블록의 해시를 지정한 inv 메시지를 보내거나, BIP130이 Bitcoin Core 0.12.0에 도입된 이후에는 80바이트 헤더를 직접 담은 headers 메시지를 보내며, 이로써 상대 노드는 별도의 getheaders 왕복을 거치지 않습니다. 수신자는 해당 블록을 보유하고 있는지 확인합니다. 없다면 getdata로 응답합니다. 그러면 발신자는 header 뒤에 모든 트랜잭션을 완전한 직렬화 형태로 이어 붙인 block 메시지를 전송하며, 블록의 상한인 400만 가중치 단위 예산까지 담습니다.

낭비는 말로 하면 분명합니다. 몇 시간 동안 실행된 노드는 이미 해당 블록의 거의 모든 트랜잭션을 멤풀에 보유하고 있으며, 각 트랜잭션이 브로드캐스트될 때 개별적으로 받은 것입니다. 표준 중계는 이 모두를 두 번째로 전송합니다. 일반 결제로 가득한 블록이라면 상대 노드마다, 블록마다 한 메가바이트를 훨씬 넘는 중복 전송이 발생합니다.

그 결과는 단지 미적인 문제가 아니었습니다. 전파가 느리면 스테일 블록의 비율이 높아지는데, 새 블록을 아직 알지 못한 채굴업자는 이전 체인 끝에서 계속 채굴하기 때문입니다. 스테일 블록은 대규모 채굴업자보다 소규모 채굴업자에게 더 큰 비용이 되는데, 대형 풀은 자기 블록을 즉시 알게 되기 때문입니다. 따라서 더 빠른 중계는 효율성만큼이나 탈중앙화의 문제였고, BIP152와 대형 풀이 서로 간에 운영하는 전용 중계 네트워크 모두를 이끌었습니다.

표준 중계가 사라진 것은 아닙니다. 상대 노드가 컴팩트 블록을 협상한 적이 없을 때, 컴팩트 재구성에 실패해 누락된 트랜잭션을 채울 수 없을 때, 그리고 초기 블록 다운로드 전반에서 일어나며, 동기화 중인 노드는 여러 상대 노드에 getdata로 전체 블록을 동시에 요청하고 Bitcoin Core에서는 상대 노드마다 최대 16개가 처리 중입니다.

확인하는 곳

표준 블록 중계는 노드가 따라잡은 뒤보다 따라잡는 중에 가장 잘 보입니다.

초기 동기화 중에는 블록에 대한 getdata가 트래픽을 지배하며, getpeerinfo의 메시지별 카운터에 그것이 그대로 나타납니다. 노드가 체인 끝에 도달하면 그 카운터는 조용해지고 컴팩트 블록 카운터가 그 자리를 대신합니다. 느린 회선을 쓰거나 상대 노드가 적은 기기는 표준 중계로 더 자주 되돌아가며, 증상은 공개 탐색기가 보여 주는 것보다 체인 끝이 한두 분 뒤처지는 것입니다.

표준 블록 중계 vs 컴팩트 블록 중계

표준 중계는 블록을 전송하고, 컴팩트 중계는 블록에 대한 설명을 전송해 수신자가 나머지를 재구성하게 합니다. cmpctblock은 header, nonce, 그리고 트랜잭션마다 6바이트 짧은 식별자를 담으므로, 수천 건의 결제를 담은 블록도 한 메가바이트를 훨씬 넘는 대신 20킬로바이트 미만으로 설명할 수 있습니다. 수신자는 그 식별자를 자기 멤풀과 대조하고, 누락된 것은 getblocktxn으로 요청하며, 블록을 로컬에서 조립합니다. 이후의 검증은 동일합니다. 컴팩트 중계는 바이트가 도착하는 방식을 바꿀 뿐, 유효한 블록의 기준을 바꾸지 않습니다.