뉴트리노(Neutrino) 방식의 경량 지갑은 주소 목록을 서버에 직접 보내지 않습니다. 대신 풀노드가 블록마다 만든 BIP158 압축 필터(compact filter)를 받아 내 기기에서 자기 scriptPubKeys와 맞춰 봅니다. BIP157에 따라 먼저 작업증명 블록 헤더와 필터 헤더 체인을 동기화·검증하고, 필터가 관련 가능성을 보인 블록만 통째로 내려받아 실제 거래를 검사합니다. 필터는 확률적이어서 거짓 양성이 생길 수 있지만, 거짓 음성은 없도록 정해진 원소 집합과 인코딩을 정확히 구현해야 합니다.
필터 생성은 서버가 하고 검색은 클라이언트가 합니다
BIP37 블룸 필터 방식은 클라이언트가 관심 데이터를 피어에게 넘기는 구조라 개인정보 노출과 노드 서비스 거부 공격 문제를 낳았습니다. BIP157은 방향을 거꾸로 바꿔, 풀노드가 결정적인 블록 필터를 만들어 저장하고 모든 클라이언트에 같은 값을 제공합니다. 클라이언트는 자기 지갑 데이터를 내 기기 안에서 조회합니다.
필터가 일치했다고 거래 포함 증명이 되는 것은 아닙니다. 클라이언트는 일치한 전체 블록을 받아 블록 헤더의 머클 루트와 작업증명 체인에 이어지는지 확인하고, 거래의 출력과 입력을 직접 훑어봅니다. 서버 응답만으로 지갑 잔액을 확정하지 않습니다.
뉴트리노는 내 주소를 서버에 물어보는 대신, 서버가 제공한 공통 블록 요약을 내 기기에서 검색합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 필터 생성은 서버가 하고 검색은 클라이언트가 합니다
BIP37 블룸 필터 방식은 클라이언트가 관심 데이터를 피어에게 넘기는 구조라 개인정보 노출과 노드 서비스 거부 공격 문제를 낳았습니다.
- 필터 헤더 체인이 응답 변조를 드러냅니다
각 필터 해시는 직렬화한 필터에 SHA256을 두 번 적용한 값입니다.
- BIP158 기본 필터의 원소 집합을 지킵니다
BIP158 기본 필터에는 블록 안 OP_RETURN이 아닌 출력의 scriptPubKeys와, 그 블록이 소비한 이전 출력의 scriptPubKeys 등이 정해진 규칙대로 들어갑니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
필터 헤더 체인이 응답 변조를 드러냅니다
각 필터 해시는 직렬화한 필터에 SHA256을 두 번 적용한 값입니다. 필터 헤더는 현재 필터 해시와 이전 필터 헤더를 이어 붙여 다시 SHA256을 두 번 적용한 값입니다. 그래서 앞선 필터 하나만 바뀌어도 그 뒤 체인이 모두 달라집니다. 클라이언트는 cfcheckpt와 cfheaders를 여러 피어에서 받아 어긋나는 지점을 찾아낼 수 있습니다.
BIP157은 먼저 블록 헤더 체인 전체를 헤더 우선 방식으로 동기화하라고 요구합니다. 필터 헤더가 어느 블록 해시에 대응하는지 고정한 다음 cfilter를 검증합니다. 작업량이 가장 많은 체인을 판정하지 않은 채 필터부터 믿으면 악성 피어가 가짜 기록을 보여 줄 수 있습니다.
| 단계 | 데이터 | 검증 |
|---|---|---|
| 1 | 블록 헤더 | 작업증명·최선 체인 |
| 2 | 필터 체크포인트 | 피어 간 비교 |
| 3 | 필터 헤더 | 이전 헤더와 연결 |
| 4 | 압축 필터 | 필터 해시 일치 |
| 5 | 일치한 블록 | 머클 검증·거래 검사 |
BIP158 기본 필터의 원소 집합을 지킵니다
BIP158 기본 필터에는 블록 안 OP_RETURN이 아닌 출력의 scriptPubKeys와, 그 블록이 소비한 이전 출력의 scriptPubKeys 등이 정해진 규칙대로 들어갑니다. 코인베이스 입력과 빈 스크립트 같은 예외도 있습니다. 구현이 원소를 임의로 빼면 지갑이 관련 거래를 영영 놓치는 거짓 음성이 생깁니다.
원소는 블록 해시로 만든 SipHash 키로 일정 범위에 대응시키고, 정렬한 값의 차이를 골롬-라이스 부호화로 압축합니다. 매개변수 P와 M은 필터 종류마다 고정돼 있습니다. 일반 블룸 필터 라이브러리로 대신하거나 주소 문자열을 그대로 넣지 않습니다. 지갑이 찾는 대상은 디코딩한 스크립트 데이터입니다.
- 최선 블록 헤더 체인을 먼저 동기화합니다.
- 여러 피어에서 체크포인트와 필터 헤더를 비교합니다.
- 필터 해시와 헤더 체인을 검증합니다.
- 지갑 스크립트를 내 기기에서 맞춰 봅니다.
- 일치한 블록은 무작위 피어에서 받아 직접 검사합니다.
거짓 양성과 요청 패턴을 관리합니다
확률적 필터는 관련 없는 블록도 일치로 표시할 수 있습니다. 클라이언트는 전체 블록을 검사한 뒤 실제 지갑 거래가 없으면 거짓 양성으로 버리고 잔액을 바꾸지 않습니다. 거짓 양성 비율은 대역폭과 맞바꾸는 값일 뿐이며, 사용자가 받는 금액의 정확도와 헷갈려서는 안 됩니다.
일치한 블록만 특정 피어에게 연달아 요청하면 교차 분석으로 지갑의 활동 범위를 짐작할 수 있습니다. BIP157은 블록을 무작위 외부 연결 피어에서 받을 수 있다고 설명합니다. 토르(Tor)만 쓴다고 요청 패턴이 사라지지는 않으며, 미끼 요청이나 묶음 요청 전략은 구현마다 개인정보 보호와 대역폭 비용을 따져 봐야 합니다.
프루닝 노드와 재검색 범위를 확인합니다
풀노드는 필터를 만든 뒤 오래된 블록 데이터를 정리(prune)할 수 있습니다. 필터는 제공해도 일치한 과거 블록 전체는 같은 피어가 주지 못할 수 있어, 클라이언트는 다른 보관 노드나 출처를 찾아야 합니다. 필터 색인 활성화 여부와 보유한 블록 범위는 서로 다른 기능으로 보고 따로 확인합니다.
복구 지갑은 생성 시점 높이 이전을 쓸데없이 검색하지 않되, 생성 시점을 잘못 잡아 입금을 놓치지 않도록 여유를 둡니다. 진행 상태에는 마지막으로 검증한 블록 헤더, 필터 헤더, 검사한 블록을 각각 체크포인트로 남깁니다. 중단 뒤 다시 시작할 때 숫자 하나로 모두 끝난 것으로 처리하지 않습니다.
자주 묻는 질문
필터가 일치하면 내 거래가 반드시 있나요?
아닙니다. 거짓 양성이 있을 수 있어 전체 블록을 받아 실제 스크립트와 거래를 검사해야 합니다.
뉴트리노 노드는 내 주소를 알 수 없나요?
주소를 직접 보내지는 않습니다. 하지만 요청한 블록 패턴과 네트워크 정보로 짐작할 여지는 남습니다.
필터 헤더만 검증하면 거래도 검증한 건가요?
아닙니다. 필터 약정(commitment)을 확인한 것일 뿐이며, 일치한 블록과 거래는 따로 검증해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
