인벤토리

먼저 알리고, 요청이 오면 전달합니다. 이러한 방식 덕분에 네트워크가 중복으로 넘치지 않습니다. 항목 하나는 36바이트, 즉 4바이트 유형 태그와 32바이트 해시로 이루어지며, inv 메시지 하나에는 최대 50,000개의 항목이 실릴 수 있습니다. 해당 객체를 이미 보유한 피어는 요청하지 않으므로 대역폭이 낭비되지 않습니다.

작동 방식

인벤토리 항목은 두 가지의 쌍입니다. 무엇인지 나타내는 숫자와 그것을 식별하는 해시입니다.

유형 코드는 작은 정수입니다. 1은 트랜잭션, 2는 블록, 3은 예전 블룸 필터 방식의 필터링된 블록, 4는 컴팩트 블록, 5는 위트니스 해시로 식별되는 트랜잭션입니다. 유형 위에 0x40000000 비트를 설정하면 위트니스를 담은 변형임을 표시하므로, segwit을 지원하는 피어는 예전 피어가 일반 블록을 요청했을 자리에서 MSG_WITNESS_BLOCK를 요청합니다.

교환은 세 단계로 진행됩니다. 노드가 새로 생긴 것을 나열한 inv를 보냅니다. 피어는 목록을 훑어 인식하는 것은 모두 무시하고, 자신에게 없는 것만 지정한 getdata로 응답합니다. 노드는 해당 객체를 하나씩 메시지로 보내거나, 그 사이에 폐기된 것이 있으면 notfound를 보냅니다. 50,000 한도의 배경이 되는 산술은 눈여겨볼 만합니다. 36바이트 항목 50,000개는 1,800,000바이트로, 메시지 하나의 상한인 4,000,000바이트 안에 넉넉히 들어가며, Bitcoin Core에는 이 두 상수가 서로 일치하도록 유지하는 컴파일 시점 단언이 들어 있습니다.

시점은 구현 세부 사항이 아니라 프라이버시 통제 수단입니다. Bitcoin Core는 트랜잭션을 알게 된 즉시 알리지 않습니다. 알림은 묶음으로 처리되어 무작위 타이머에 따라 나가며, 아웃바운드 피어에는 평균 2초, 인바운드 피어에는 평균 5초가 걸립니다. 따라서 여러 노드에 연결된 관찰자가 도착 순서로 결제가 시작된 곳을 알아낼 수 없습니다. 블록은 지연을 전혀 적용하지 않습니다. 숨길 것이 없고 초가 곧 비용이기 때문입니다.

모든 해시를 모든 피어에게 외치는 것은 비용이 크며, Erlay가 제안된 해결책입니다. 피어들이 식별자를 사방으로 쏟아 내는 대신 서로 보유한 것의 짧은 스케치를 주기적으로 조정합니다.

확인할 수 있는 곳

인벤토리는 노드의 네트워크 인터페이스에서 가장 시끄러운 부분이며 관찰하기 가장 쉬운 부분입니다.

getpeerinfo 호출은 트래픽을 메시지 유형별로 분석하며, inv는 거의 항상 가장 큰 카운터 가운데 하나입니다. 연결이 잘 된 노드는 결국 아무도 필요로 하지 않은 해시를 알리는 데 대역폭의 상당 부분을 실제로 씁니다. 한 결제가 한 블록 탐색기에는 다른 탐색기보다 몇 초 먼저 나타나는 것도 이 때문입니다. 이들은 네트워크의 서로 다른 부분에서 서로 다른 알림을 듣는 별개의 관찰자입니다.

버려야 할 습관이 하나 있습니다. inv는 약속이 아닙니다. 노드는 트랜잭션을 알린 뒤 몇 분 후 멤풀이 가득 차면 그것을 제거할 수 있으며, 누구에게도 정정을 해 줄 의무가 없습니다.

인벤토리 vs 멤풀

인벤토리는 메시지이고 멤풀은 저장소이며, 둘 가운데 하나만 그 순간 이후로 남습니다. inv는 해시가 어딘가에 존재한다고 피어에게 알려 줍니다. 멤풀은 노드가 실제로 검증하고 메모리에 보관하며 전달하거나 채굴할 의사가 있는 미확인 트랜잭션의 집합으로, 기본 크기는 300MB이고 가장 싼 것부터 먼저 버리는 제거 정책을 따릅니다. 자신의 txid가 inv 알림을 통해 퍼지는 모습을 보는 것은 네트워크가 해당 결제에 대해 들었다는 뜻입니다. 한 시간 뒤에도 누군가 그것을 여전히 가지고 있다는 뜻은 아닙니다.