블록체인/레벨 III · 네트워크/3.1 노드/수업 4
프루닝 노드와 라이트 클라이언트(SPV)
신뢰의 아키텍처: 완전한 검증에서 메르클 프루프까지
준비물prune=550으로 설정된 비트코인 코어 노드(선택 사항)라이트 지갑블록 탐색기
호기심
- 노드는 모든 블록을 영구적으로 저장하지 않고도 비트코인의 전체 이력을 어떻게 검증할 수 있을까요?
- 수백 기가바이트에 달하는 데이터를 다운로드하지 않고도 스마트폰 지갑이 잔액을 확인할 수 있게 해주는 구체적인 암호화 메커니즘은 무엇인가요?
- 라이트 지갑을 위한 초기의 프라이버시 보호 필터는 왜 사용자 신원을 노출했으며, 그 결함은 어떻게 해결되었나요?
탐구
- 완전한 검증과 완전한 저장은 분리할 수 있습니다. 검증하는 모든 노드는 현재의 미사용 출력 집합을 구성하기 위해 모든 블록을 한 번씩 처리해야 하지만, 그 이후에 오래된 블록을 보관할 필요는 없습니다. 일부 클라이언트는 더 나아가 검증을 아예 생략하고, 트랜잭션이 충분한 작업증명을 가진 블록에 포함되어 있는지만 확인합니다. 이러한 선택은 디스크 공간, 대역폭, 프라이버시를 독립성과 맞바꾸는 것입니다.
- 프루닝 노드는 제네시스 블록부터 모든 블록에 대해 동일한 초기 검증을 수행하지만, 이후 디스크 공간을 절약하기 위해 오래된 블록 데이터를 삭제합니다. 비트코인 코어의 `prune` 설정은 최근 블록을 최소 550MB 유지하면서, 검증이 끝난 오래된 블록은 버립니다. 이 노드는 여전히 완전한 검증자로서 합의 규칙을 집행하고, 독립적으로 확인한 진실로 소유자의 지갑을 보호할 수 있습니다. 하지만 다른 피어에게 과거 블록 데이터를 제공하거나, `txindex`처럼 체인을 깊이 조회해야 하는 기능은 더 이상 지원할 수 없습니다.
- 라이트 클라이언트, 즉 SPV 노드는 전체 규칙을 검증하지 않는 다른 방식을 택합니다. 이들은 해당 블록의 모든 트랜잭션에 대한 메르클 루트가 담긴 블록 헤더만 다운로드합니다. 특정 트랜잭션이 포함되었는지 확인하려면, 클라이언트는 피어에게 메르클 프루프를 요청해 헤더의 루트와 대조합니다. 이 방식은 누적 작업량이 가장 많은 체인이 유효하다는 가정에 의존하며, 독립적인 규칙 집행을 포기하는 대신 저장 공간과 대역폭 요구량을 대폭 줄입니다.
- 초기 SPV 구현에서는 지갑이 피어로부터 관련 있는 거래만 요청할 수 있도록 BIP37 블룸 필터가 사용되었습니다. 지갑은 자신의 주소들을 설명하는 필터를 전송하고, 피어들은 자신의 멤풀을 스캔하여 일치하는 거래들을 보내주었습니다. 하지만 이러한 설계는 프라이버시 문제를 야기했습니다. 악의적인 피어가 필터를 관찰함으로써 사용자의 주소가 무엇인지 추론하고 그들의 활동을 추적할 수 있었던 것입니다. 비트코인 코어는 2019년(버전 0.19)부터 기본적으로 블룸 필터 제공을 중단했습니다.
- 컴팩트 블록 필터(BIP157/158)는 프라이버시를 되찾기 위해 이 흐름을 뒤집었습니다. 지갑이 자신의 주소를 드러내는 대신, 풀노드가 각 블록에 대한 컴팩트 필터를 공개하고, 클라이언트는 이 필터를 다운로드해 로컬에서 자신의 키와 대조합니다. 필터가 일치하면 클라이언트는 블록 전체를 다운로드하는데, 단일 트랜잭션만 요청하면 피어에게 그 트랜잭션이 드러나기 때문입니다. 이 방식은 지갑이 어떤 주소를 모니터링하는지 피어가 알 수 없게 하여, 효율적인 동기화를 유지하면서 사용자 프라이버시를 크게 향상시킵니다.
- 많은 모바일 지갑은 메르클 프루프는 블록 헤더와 대조해 직접 확인하면서도, 데이터는 Electrum 서버 같은 제3자 서버에 의존합니다. 트레이드오프는 분명합니다. 편의성과 낮은 리소스 사용량이냐, 독립적인 검증과 프라이버시냐입니다. 프루닝 노드를 운영하는 사용자는 완전한 검증 능력을 유지하지만 과거 데이터 제공은 제한됩니다. SPV 지갑은 차지하는 자원이 최소한이지만, 관련된 모든 트랜잭션을 보여 줄 것이라고 피어에 의존하며, 작업량이 가장 많은 체인이 유효하다고 확인 없이 가정합니다.
핵심 사실
- 프루닝 노드는 제네시스 블록부터 모든 블록을 검증하지만 오래된 데이터는 삭제하고, 최근 블록을 최소 550MB 유지합니다.
- SPV 클라이언트는 블록 헤더만 다운로드하고, 헤더의 루트 해시를 기반으로 한 메르클 프루프를 사용하여 거래를 검증합니다.
- BIP37 블룸 필터는 지갑이 어떤 주소를 모니터링하는지 피어에게 드러내 사용자 프라이버시를 침해했습니다.
- 컴팩트 블록 필터(BIP157/158)를 통해 클라이언트는 주소의 프라이버시를 보호하면서 서버가 제공하는 필터를 로컬에서 테스트할 수 있습니다.
- SPV 지갑은 모든 합의 규칙을 독립적으로 집행하는 대신, 누적 작업증명이 가장 많은 체인이 유효하다고 신뢰합니다.
- 프루닝 노드는 여전히 완전한 검증자로서 소유자의 자금을 보호할 수 있지만, 다른 피어에게 과거 블록 데이터를 제공할 수는 없습니다.
연습 아홉, 여섯, 셋, 하나
9모으기비트코인 노드 또는 클라이언트 구현체 9가지 유형을 나열하십시오. 각각에 대해 저장 공간 요구 사항, 검증 능력(전체 검증 vs. SPV), 주요 사용 사례를 기재하십시오.
6묶기9가지를 독립적 검증 수준과 데이터 보존 정도에 따라 6개 범주로 분류하십시오.
3추리기6개 그룹을 프라이버시, 보안, 리소스 소비 사이의 서로 다른 3가지 트레이드오프로 압축하십시오.
1결정화라이트 클라이언트의 신뢰 모델이 풀노드의 신뢰 모델과 근본적으로 다른 이유를 한 문장으로 설명하십시오.
팩트 체크
날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.
- Satoshi Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008), Section 8
- BIP37: Connection Bloom filtering
- BIP157: Client Side Block Filtering
- BIP158: Compact Block Filters for Light Clients
- Bitcoin Core release notes 0.11.0 (pruning)
- A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10