주제별 원본 삽화: ChainView BTC866 주제별 원본 도해 · ChainView BTC866 Editorial · CC BY 4.0
필터가 하는 일
압축 블록 필터는 지갑이 관심을 갖는 스크립트가 특정 블록에 들어 있을 가능성을 빠르게 찾도록 돕습니다. 모든 블록 본문을 먼저 내려받는 대신 필터를 검사하고 관련 가능성이 있는 블록을 가져오는 구조입니다. BIP157은 제공 프로토콜과 필터 헤더 등을, BIP158은 압축 필터 구성을 설명합니다. 필터를 받았다고 지갑이 이미 거래 본문을 검증한 것은 아닙니다.
거짓 양성의 의미
확률적 구조인 필터에서는 관련 항목이 없어도 일치한다고 나오는 거짓 양성이 생길 수 있습니다. 따라서 일치 결과는 해당 블록을 받아 살펴볼 이유일 뿐 잔고 증가나 입금 확정의 증거가 아닙니다. 거래를 찾으면 출력의 스크립트와 금액을 실제로 대조하고 체인의 유효성과 확인 상태도 따로 판단해야 합니다. UI는 필터 일치, 거래 발견과 결제 확인을 서로 다른 단계로 보여 주는 편이 명확합니다.
지갑 쿼리의 변화
주소를 서버에 직접 질문하는 방식보다 필터 다운로드는 관심 주소를 곧바로 알리는 일을 줄일 수 있습니다. 그러나 특정 블록 요청과 연결 시각, 네트워크 주소 같은 메타데이터는 여전히 단서가 됩니다. 중계 서버나 여러 피어 사용이 어떤 정보를 누구에게 숨기는지 구체적으로 생각해야 합니다. 개인정보 보호 기능이 있다는 설명을 완전한 익명성 보증으로 읽으면 안 됩니다.
피어와 검증 가정
악성 피어가 자료를 누락하거나 지연할 수 있는 상황을 고려하고 클라이언트가 필터 헤더와 체인 일관성을 어떻게 확인하는지 읽습니다. 경량 지갑이 전체 검증 노드와 같은 검증 범위를 제공한다고 단정할 수 없습니다. 구현 버전과 연결 정책, 대체 피어를 확인하세요. 블록을 받지 못한 상태를 관련 거래가 없다는 결론으로 바꾸면 데이터 가용성 문제를 잔고 문제로 오해할 수 있습니다.
작은 실습과 기록
테스트넷의 알려진 거래가 들어 있는 블록으로 필터 조회, 일치, 블록 다운로드와 출력 확인을 순서대로 기록해 보세요. 무관한 필터의 우연한 일치가 있어도 지갑 잔고에는 반영하지 않아야 합니다. 로그를 공유할 때 주소와 연결 정보가 노출되는지도 점검합니다. 속도와 다운로드 절감 효과를 측정할 때는 전체 블록 크기, 필터 수량과 다시 받은 자료까지 포함해야 비교가 공정합니다.
관심 블록의 재확인
필터가 일치한 뒤 받은 블록에서 실제 관심 출력을 찾지 못했다면 거짓 양성일 수 있습니다. 이런 경우를 거래 실패나 자산 손실로 표시하면 안 됩니다. 반대로 블록을 받지 못했을 때는 확인을 완료한 것이 아니므로 자료 조회 상태로 남겨 둡니다. 피어가 제공한 필터의 연속성과 다른 자료의 일관성을 구현이 어떻게 다루는지 확인하세요. 여러 피어를 사용하더라도 접속과 요청의 패턴이 한 관찰자에게 연결될 수 있어 프라이버시 가정을 구체적으로 남겨야 하며 지갑 주소 목록을 디버그 보고서에 그대로 첨부하지 않습니다.
