요청하지 않은 블록 푸시

대부분의 프로토콜에서 초대받지 않은 푸시는 무례한 일이지만, 이 프로토콜에서는 올바른 일입니다. 블록이 전송 중에 보내는 모든 왕복은 채굴업자가 더 이상 존재하지 않는 체인 끝에서 연산을 낭비하는 시간이므로, BIP152는 이 지름길을 공식화했습니다. 선택된 피어는 최대 3곳까지 새 블록을 손에 넣는 즉시 이용자에게 보낼 수 있습니다. 이용자의 노드는 어차피 처음부터 검증하며, 보낸 쪽에 아무것도 빚지지 않습니다.

작동 방식

요청하지 않은 블록 푸시라는 이름 아래에는 서로 다른 두 가지가 오갑니다. 하나는 오래된 비공식 형태이고, 다른 하나는 명세된 형태입니다.

오래된 형태는 대응하는 getdata가 없는 block 메시지가 도착하는 것에 불과합니다. 프로토콜은 이를 금지한 적이 없고, 수신 측은 항상 이런 블록을 처리해 왔습니다. 다만 조건이 붙습니다. Bitcoin Core는 비용이 큰 작업을 하기 전에 헤더의 작업 증명을 확인하고, 블록이 완전히 검증되어 최선의 체인에 연결되기 전까지는 다음으로 넘기지 않으며, 자신이 아는 어떤 것에도 연결되지 않는 블록은 풀어야 할 퍼즐이 아니라 버릴 대상으로 취급합니다. 이런 규칙이 존재하는 이유는 요청하지 않은 데이터가 보낸 쪽에는 무료이고 받는 쪽에는 비용이 들기 때문이며, 이것이 프로토콜의 모든 서비스 거부 공격이 취하는 형태입니다.

명세된 형태는 BIP152의 고대역폭 모드입니다. 노드는 피어에게 첫 바이트가 1인 sendcmpct 메시지를 보냅니다. 이는 공지하지 말고 그냥 보내라는 뜻입니다. 그러면 그 피어는 새 블록을 듣는 즉시, 어쩌면 아직 검증을 마치기 전에 cmpctblock을 전송할 수 있습니다. BIP152는 이런 피어의 엄격한 상한을 3곳으로 정하고 Bitcoin Core는 정확히 그 한도를 시행하며, 최근 블록을 가장 먼저 전달한 노드를 기준으로 최대 3곳의 목록을 유지합니다. 3곳은 절충안입니다. 느린 피어 한 곳이 이용자를 지체시키지 못할 만큼의 중복성은 충분하고, 이용자가 가진 모든 연결을 통해 같은 블록을 받지는 않을 만큼 적습니다.

고대역폭 공지가 검증보다 앞설 수 있으므로, 받는 노드는 이를 사실이 아니라 주장으로 취급합니다. 작업 증명은 값싸게 위조할 수 없는 블록의 유일한 부분이므로 가장 먼저 확인하고, 나머지는 모두 정상 경로를 따릅니다. 프로토콜 버전 70015가 존재하는 이유는 정확히 노드가 나중에 완전히 확인되지 않은 것으로 밝혀진 블록을 공지했다는 이유로 피어에게 불이익을 주지 않겠다고 알릴 수 있게 하기 위해서입니다.

어디에서 볼 수 있는가

요청하지 않은 푸시는 초가 곧 돈인 곳에 집중됩니다.

채굴 풀은 서로 그리고 FIBRE 같은 중계 네트워크와 직접 연결을 유지하며, 이 네트워크는 물리적 한계가 허용하는 만큼 적은 핸드셰이킹으로 대륙 간에 블록을 옮기도록 만들어졌습니다. 일반적인 기계에서는 getpeerinfo 호출이 피어마다 bip152_hb_to와 bip152_hb_from 두 플래그를 보고하며, 이를 통해 어느 피어에게 블록 푸시를 요청했고 어느 피어가 같은 요청을 했는지 알 수 있습니다. 첫 번째 플래그가 3곳에서 보이는 것은 정상이며, 3곳이 한도입니다.

요청하지 않은 블록 푸시 vs 표준 블록 중계

표준 블록 중계와 요청하지 않은 푸시는 바이트가 이동하기로 누가 결정하는지에서 다릅니다. 표준 중계에서는 받는 쪽이 요청하므로 자신의 대역폭을 스스로 통제하고 이미 가진 것은 무엇이든 거절할 수 있습니다. 푸시에서는 보낸 쪽이 결정하므로 왕복 하나를 아끼는 대신 외부인에게 이용자의 자원을 조종할 수 있는 수단을 넘겨줍니다. 비트코인의 답은 둘 중 하나를 고르는 것이 아닙니다. 푸시를 허용하고, 이용자가 직접 선택한 피어 3곳으로 제한하며, 무엇이든 소비하기 전에 작업 증명을 확인하고, 블록이 아무리 정중하게 도착했더라도 전체를 검증합니다.