BIP152 compact block relay는 새 block header와 6바이트 short transaction IDs, 수신자가 없을 가능성이 큰 일부 prefilled transactions를 보냅니다. 수신 node는 이미 mempool에 있는 거래를 short ID와 맞춰 원래 순서의 block을 재구성하고, 빠진 항목만 getblocktxn으로 요청합니다. Mempool 겹침이 높으면 전체 block을 다시 받는 것보다 bytes와 지연을 줄이지만 short ID 충돌이나 누락이 있으면 추가 round trip 또는 full block fallback이 필요합니다.
피어의 mempool 중복을 이용합니다
새 block의 대부분 거래는 이미 network를 통해 각 node mempool에 전파됐을 가능성이 큽니다. 전체 serialized transactions를 다시 보내는 대신 수신자가 가진 거래를 식별할 짧은 표지만 보내면 bandwidth를 줄일 수 있습니다. 이는 transaction relay가 먼저 잘 퍼졌다는 조건에서 가장 효과적입니다.
BIP152 HeaderAndShortIDs에는 80바이트 header, 8바이트 nonce, shortids와 prefilled transactions가 들어갑니다. Short IDs는 block 순서를 복원할 배열이며 txid 목록의 영구 식별자가 아닙니다. 매 compact block의 key가 달라 다른 block·session에서 그대로 재사용하지 않습니다.
Compact block은 거래를 압축하는 파일 형식이 아니라, 상대가 이미 가진 거래를 짧은 ID로 다시 조립하게 하는 relay protocol입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 피어의 mempool 중복을 이용합니다
새 block의 대부분 거래는 이미 network를 통해 각 node mempool에 전파됐을 가능성이 큽니다.
- Short ID는 충돌을 전제로 처리합니다
Sender는 header와 nonce에서 SipHash keys를 만들고 각 transaction의 wtxid 또는 txid 조건에 따라 6바이트 short ID를 계산합니다.
- Prefilled 항목은 index 차이로 인코딩됩니다
Coinbase transaction은 mempool에 없으므로 보통 prefilledtxn에 들어갑니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Short ID는 충돌을 전제로 처리합니다
Sender는 header와 nonce에서 SipHash keys를 만들고 각 transaction의 wtxid 또는 txid 조건에 따라 6바이트 short ID를 계산합니다. 48비트라서 드물게 서로 다른 거래가 같은 ID를 만들 수 있습니다. Receiver는 일치 후보가 하나인지 확인하고 모호한 position을 missing으로 취급합니다.
공격자가 collision을 만들거나 mempool 차이를 키우면 reconstruction 비용과 요청 횟수가 늘 수 있습니다. Node는 compact block만 믿고 consensus 검증을 생략하지 않습니다. 모든 거래를 복원한 뒤 Merkle root, transaction validity와 block rules를 정상 block처럼 검증합니다.
| 단계 | 메시지·데이터 | 목적 |
|---|---|---|
| 협상 | sendcmpct | 버전·high bandwidth 선택 |
| 초기 전파 | cmpctblock | header·short IDs·prefilled tx |
| 로컬 재구성 | mempool lookup | 기존 transactions 매칭 |
| 누락 요청 | getblocktxn | missing indexes 요청 |
| 보완 응답 | blocktxn | 필요 transactions 전달 |
Prefilled 항목은 index 차이로 인코딩됩니다
Coinbase transaction은 mempool에 없으므로 보통 prefilledtxn에 들어갑니다. Sender가 상대에게 없을 것으로 예상하는 다른 거래도 추가할 수 있습니다. Index는 이전 prefilled index와의 차이에서 1을 뺀 differential encoding이라 decoder가 raw index로 오해하면 block 순서를 깨뜨립니다.
Receiver는 short IDs와 prefilled indexes를 합쳐 정확한 transaction count와 positions를 만듭니다. Duplicate index, 범위를 넘는 값, minimally encoded가 아닌 CompactSize 같은 malformed 입력을 거부합니다. Parsing 단계의 bounds check가 peer DoS 방어에 중요합니다.
- sendcmpct version과 mode를 협상합니다.
- header·nonce에서 short-ID keys를 계산합니다.
- prefilled differential indexes를 복원합니다.
- mempool 후보의 충돌·누락을 분류합니다.
- 누락 거래를 요청하고 완성 block을 검증합니다.
High bandwidth와 low bandwidth가 전파 시점을 바꿉니다
High bandwidth mode에서는 peer가 block announcement 요청을 기다리지 않고 compact block을 직접 보낼 수 있어 한 round trip을 줄입니다. 모든 peer를 high bandwidth로 두면 duplicate traffic과 공격 면이 커질 수 있어 node는 제한된 peers를 선택합니다. Low bandwidth는 announcement 후 요청하는 흐름입니다.
Compact relay는 block propagation latency를 줄여 stale block 위험을 낮추는 데 도움을 주지만 consensus finality를 바꾸지 않습니다. Mining node 사이 network topology와 mempool 차이가 효과를 좌우합니다. 측정은 bytes만이 아니라 reconstruction success, extra round trips, full-block fallback 비율을 함께 봅니다.
SegWit relay 버전과 peer 능력을 확인합니다
BIP152의 version 협상은 short IDs가 txid 또는 wtxid에 기반하는지와 관련됩니다. Modern implementation은 witness-aware compact block을 사용해야 malleated identifiers와 witness 데이터 누락을 올바르게 처리합니다. 상대가 지원한 version 이상을 임의로 가정하지 않습니다.
장애 로그에는 peer, negotiated version, short ID count, prefilled count, missing indexes, fallback reason을 남깁니다. Raw transactions나 사용자 관계를 불필요하게 영구 저장하지 않습니다. 구현 변경은 Bitcoin Core 상호운용 test와 malformed message fuzzing으로 확인합니다.
자주 묻는 질문
Compact block은 거래 내용을 압축 알고리즘으로 줄이나요?
주로 상대 mempool에 이미 있는 거래를 short ID로 가리켜 중복 전송을 줄입니다.
Short ID 충돌이면 잘못된 block을 승인하나요?
아닙니다. 모호한 거래를 다시 요청하고 완성 block의 Merkle root와 consensus 규칙을 검증합니다.
모든 peer를 high bandwidth로 두면 가장 빠른가요?
중복 traffic과 공격 면이 커질 수 있어 구현은 제한된 peers를 선택합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
