BIP152는 새 블록을 전할 때 이미 멤풀에 있을 거래를 다시 보내지 않도록 헤더와 6바이트 짧은 거래 ID만 보내는 P2P 방식입니다. 목표는 대역폭 절감이며 지연 시간 단축은 부수 효과라고 원문이 밝힙니다. 이 글은 2026-10-27에 연 BIP152 원문(상태 Deployed)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
짧은 거래 ID는 어떻게 만들까?
블록 헤더 뒤에 8바이트 nonce를 붙여 SHA256을 한 번 계산합니다. 결과의 앞 두 개 64비트 정수를 SipHash-2-4의 키 k0, k1로 쓰고 거래 ID를 입력해 얻은 값에서 상위 2바이트를 버려 6바이트로 만듭니다. 이는 버전 1이며, 버전 2는 세그윗 거래를 지원하면서 txid 대신 wtxid로 계산합니다. 거래 식별자의 일반 개념은 트랜잭션 해시 확인 글에 있습니다.
| 메시지 | 원문이 정하는 역할 |
|---|---|
| sendcmpct | 1바이트 값(1 고대역, 0 저대역)과 8바이트 버전, 현재 버전 1 |
| cmpctblock | 헤더, nonce, 짧은 ID 목록, 미리 채운 거래(HeaderAndShortIDs) |
| getblocktxn | 없는 거래의 번호를 차등 인코딩해 요청 |
| blocktxn | 요청한 거래를 요청 순서대로 전달 |
고대역과 저대역 모드는 무엇이 다를까?
고대역에서는 상대가 새 블록을 완전히 검증하기 전에도 cmpctblock으로 바로 알립니다. 저대역에서는 기존 inv나 헤더 알림(BIP130)을 쓰고, 받는 쪽이 MSG_CMPCT_BLOCK을 getdata로 요청합니다. sendcmpct의 둘째 값이 1이 아니면 그 메시지를 받지 않은 것으로 취급합니다. 저대역에서 누락 거래가 없으면 현재와 같은 1.5*RTT, 있으면 getblocktxn 왕복이 더해져 2.5*RTT 이상이라고 원문이 적습니다.
고대역 모드는 몇 개 피어까지일까?
충분한 수신 대역이 있는 노드는 최대 3개 피어에 첫 값을 1로 보내는 것이 권장되고, 3개를 넘겨 보내서는 안 됩니다. 원문은 이를 송신 대역폭 낭비를 부추기기 때문이라고 설명합니다. 피어는 과거 성능으로 고르길 권하며, 최근 블록을 가장 빨리 준 세 피어가 예입니다. 그런 피어의 블록은 0.5*RTT 만에 받을 수 있다고 적습니다.
보내기 전에 무엇을 검증해야 할까?
헤더가 블록의 모든 거래에 커밋하고 유효한 작업 증명 위에 쌓인다는 점은 확인해야 하지만, 거래가 UTXO를 올바르게 쓰는지는 검증 전에도 보낼 수 있습니다. 받는 쪽은 도착한 cmpctblock의 짧은 ID를 멤풀 거래마다 계산한 짧은 ID와 비교합니다. 그래서 헤더만 유효하고 블록이 무효인 cmpctblock을 알린 피어를 차단하지 말라고 권고합니다. 헤더와 거래를 잇는 구조는 머클 증명 글에 정리되어 있습니다.
자주 묻는 질문
짧은 ID가 충돌하면 피어에게 불이익이 있나요?
원문은 짧은 ID가 가끔 충돌하리라 보며 충돌을 이유로 노드를 처벌해서는 안 된다고 적습니다.
sendcmpct를 보내려면 어떤 프로토콜 버전이어야 하나요?
보내기 전에 프로토콜 버전이 70014 이상인지 확인하도록 권고합니다. 검증 전 알림을 처벌하지 않겠다는 신호로는 70015 이상을 권고합니다.
누락 거래는 어떻게 받나요?
받는 쪽이 getblocktxn으로 필요한 번호를 요청하면 상대가 blocktxn으로 정확히 그 거래만 순서대로 보내거나 전체 블록을 보냅니다.
