BIP152 압축 블록 중계(compact block relay)는 새 블록 헤더와 6바이트 짧은 거래 ID(short transaction ID), 그리고 수신자에게 없을 가능성이 큰 일부 거래를 미리 채운 항목(prefilled transaction)으로 보냅니다. 받는 노드는 이미 멤풀(mempool)에 있는 거래를 짧은 ID와 맞춰 원래 순서대로 블록을 다시 조립하고, 빠진 항목만 getblocktxn으로 요청합니다. 멤풀이 많이 겹치면 블록 전체를 다시 받는 것보다 전송량과 지연이 줄어듭니다. 다만 짧은 ID가 충돌하거나 거래가 빠져 있으면 왕복 요청을 한 번 더 하거나 전체 블록으로 되돌아가야 합니다.
피어의 멤풀에 이미 있는 거래를 활용합니다
새 블록에 담긴 거래 대부분은 네트워크를 거쳐 이미 각 노드의 멤풀에 퍼져 있을 가능성이 큽니다. 직렬화한 거래 전체를 다시 보내는 대신, 받는 쪽이 가진 거래를 알아볼 짧은 표지만 보내면 대역폭을 아낄 수 있습니다. 이 방식은 거래 중계가 먼저 잘 퍼졌을 때 가장 효과가 큽니다.
BIP152의 HeaderAndShortIDs에는 80바이트 헤더, 8바이트 논스, 짧은 ID 목록, 미리 채운 거래가 들어갑니다. 짧은 ID는 블록 순서를 되살리기 위한 배열이며 거래 ID 목록을 대신하는 영구 식별자가 아닙니다. 압축 블록마다 키가 달라서 다른 블록이나 세션에서 그대로 다시 쓰지 않습니다.
압축 블록은 거래를 줄이는 파일 형식이 아니라, 상대가 이미 가진 거래를 짧은 ID로 다시 조립하게 하는 중계 규약입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 피어의 멤풀에 이미 있는 거래를 활용합니다
새 블록에 담긴 거래 대부분은 네트워크를 거쳐 이미 각 노드의 멤풀에 퍼져 있을 가능성이 큽니다.
- 짧은 ID는 충돌이 일어난다고 보고 처리합니다
보내는 쪽은 헤더와 논스로 SipHash 키를 만들고, 각 거래의 wtxid 또는 txid를 조건에 맞게 써서 6바이트 짧은 ID를 계산합니다.
- 미리 채운 항목은 위치 차이로 인코딩합니다
코인베이스 거래는 멤풀에 없으므로 보통 prefilledtxn에 들어갑니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
짧은 ID는 충돌이 일어난다고 보고 처리합니다
보내는 쪽은 헤더와 논스로 SipHash 키를 만들고, 각 거래의 wtxid 또는 txid를 조건에 맞게 써서 6바이트 짧은 ID를 계산합니다. 48비트밖에 안 되므로 드물게 서로 다른 거래가 같은 ID를 만들 수 있습니다. 받는 쪽은 일치하는 후보가 하나뿐인지 확인하고, 애매한 자리는 빠진 것으로 취급합니다.
공격자가 일부러 충돌을 만들거나 멤풀 차이를 키우면 재조립 비용과 요청 횟수가 늘 수 있습니다. 노드는 압축 블록만 믿고 합의 검증을 건너뛰지 않습니다. 모든 거래를 복원한 뒤 머클 루트, 거래 유효성, 블록 규칙을 일반 블록과 똑같이 검증합니다.
| 단계 | 메시지·데이터 | 목적 |
|---|---|---|
| 협상 | sendcmpct | 버전·고대역폭 방식 선택 |
| 초기 전파 | cmpctblock | 헤더·짧은 ID·미리 채운 거래 |
| 로컬 재조립 | 멤풀 조회 | 이미 가진 거래와 맞추기 |
| 누락 요청 | getblocktxn | 빠진 위치 번호 요청 |
| 보완 응답 | blocktxn | 필요한 거래 전달 |
미리 채운 항목은 위치 차이로 인코딩합니다
코인베이스 거래는 멤풀에 없으므로 보통 prefilledtxn에 들어갑니다. 보내는 쪽은 상대에게 없을 것 같은 다른 거래도 추가할 수 있습니다. 위치 번호는 직전 항목의 위치와의 차이에서 1을 뺀 차분 인코딩(differential encoding)이어서, 디코더가 이를 실제 위치로 잘못 읽으면 블록 순서가 깨집니다.
받는 쪽은 짧은 ID와 미리 채운 항목의 위치를 합쳐 정확한 거래 수와 각 자리를 만듭니다. 중복된 위치, 범위를 넘는 값, 최소 길이로 인코딩되지 않은 CompactSize 같은 잘못된 입력은 거부합니다. 해석 단계의 경계 검사는 피어의 서비스 거부 공격을 막는 데 중요합니다.
- sendcmpct로 버전과 방식을 협상합니다.
- 헤더와 논스로 짧은 ID 키를 계산합니다.
- 미리 채운 항목의 차분 위치를 복원합니다.
- 멤풀 후보에서 충돌과 누락을 가려냅니다.
- 빠진 거래를 요청하고 완성된 블록을 검증합니다.
고대역폭과 저대역폭 방식은 전파 시점이 다릅니다
고대역폭 방식에서는 피어가 블록 알림 뒤의 요청을 기다리지 않고 압축 블록을 바로 보낼 수 있어 왕복 한 번을 줄입니다. 모든 피어를 고대역폭으로 두면 중복 전송과 공격 표면이 커질 수 있어, 노드는 제한된 수의 피어만 고릅니다. 저대역폭 방식은 알림을 먼저 받은 뒤 요청하는 흐름입니다.
압축 중계는 블록 전파 지연을 줄여 버려지는 블록이 생길 위험을 낮추는 데 도움이 되지만, 합의의 최종성을 바꾸지는 않습니다. 효과는 채굴 노드 사이의 네트워크 구조와 멤풀 차이에 달려 있습니다. 측정할 때는 전송량뿐 아니라 재조립 성공률, 추가 왕복 횟수, 전체 블록으로 되돌아간 비율을 함께 봅니다.
세그윗 중계 버전과 피어의 지원 범위를 확인합니다
BIP152의 버전 협상은 짧은 ID가 txid와 wtxid 중 무엇을 바탕으로 하는지와 관련이 있습니다. 요즘 구현은 증인 데이터를 고려한 압축 블록을 써야 변형된 식별자와 증인 데이터 누락을 제대로 처리합니다. 상대가 지원한다고 밝힌 버전보다 높은 버전을 멋대로 가정하지 않습니다.
장애 기록에는 피어, 협상된 버전, 짧은 ID 개수, 미리 채운 항목 개수, 빠진 위치, 되돌아간 이유를 남깁니다. 원본 거래나 사용자 관계 정보를 쓸데없이 오래 저장하지 않습니다. 구현을 바꿀 때는 Bitcoin Core와의 상호 운용 시험과 잘못된 메시지 퍼징으로 확인합니다.
자주 묻는 질문
압축 블록은 거래 내용을 압축 알고리즘으로 줄이나요?
주로 상대 멤풀에 이미 있는 거래를 짧은 ID로 가리켜 같은 데이터를 두 번 보내지 않도록 합니다.
짧은 ID가 충돌하면 잘못된 블록을 승인하나요?
아닙니다. 애매한 거래는 다시 요청하고, 완성된 블록의 머클 루트와 합의 규칙을 검증합니다.
모든 피어를 고대역폭으로 두면 가장 빠른가요?
중복 전송과 공격 표면이 커질 수 있어서 구현은 제한된 수의 피어만 고릅니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
