Compact Block Filters

안나가 오랜만에 휴대전화 지갑을 엽니다. 앱은 마지막 접속 이후 입금이 있었는지, 자금 일부가 쓰였는지 알아야 합니다. 모든 거래 대신 작은 필터를 내려받아 감시하는 출력의 조건과 비교합니다. 출력은 금액과 그 돈을 다음에 쓸 조건을 정하는 거래의 일부입니다. 일치하면 블록 전체를 요청하고 실제 거래를 찾습니다. 필터가 일치했다는 이유만으로 잔액을 늘려서는 안 됩니다. 필터는 계좌 명세서도 소유 증명도 아닙니다. 검색에 앞서 클라이언트는 블록을 식별하는 짧은 정보인 블록 헤더와 연결된 필터 헤더를 동기화합니다. [1]

예전 BIP 37 방식에서는 클라이언트가 감시할 데이터로 필터를 만들어 연결 상대인 피어에게 보냈습니다. 여기서는 방향이 반대입니다. 서버가 블록 필터를 보내고 안나는 지갑 안에서 검색합니다. 같은 블록과 필터 종류라면 각 클라이언트가 받는 내용도 같습니다. 따라서 찾는 스크립트를 서버마다 직접 알릴 필요가 없습니다. 그렇다고 익명성이 보장되지는 않습니다. 피어는 IP 주소와 접속 시점, 지갑이 뒤이어 요청하는 전체 블록을 볼 수 있습니다. 여러 피어에게 나누어 받으면 한 곳에 모이는 정보는 줄지만 모든 연관 분석을 없애지는 못합니다. [1]

Compact Block Filters는 살펴볼 블록을 고릅니다. BIP 152의 Compact Blocks는 다른 문제를 해결합니다. 수신자가 이미 아는 경우가 많은 거래를 짧은 식별자로 표현해 블록 전송량을 줄입니다. 수신자는 미확인 거래를 모아 둔 자신의 Mempool에서 거래를 찾고 빠진 거래를 요청합니다. 어느 도구도 단독으로 Bitcoin의 모든 규칙을 검사하지는 않습니다. Full Node, 즉 전체 노드는 네트워크 규칙에 따라 블록과 거래를 독립적으로 검증합니다. 헤더와 자기 거래의 포함 여부만 보는 가벼운 지갑은 더 좁은 범위를 확인합니다. 데이터 절약과 완전한 검증은 서로 다른 속성입니다. [1] [5]

BIP 158이 형식을 정합니다. basic 필터에는 새 출력의 지출 조건을 정하는 스크립트인 scriptPubKey가 들어가되, OP_RETURN으로 시작하는 출력은 제외됩니다. 블록에서 소비하는 이전 출력의 스크립트도 포함됩니다. 입력에 대한 예외는 coinbase입니다. 블록의 첫 거래로 채굴자 보상을 분배하며 일반적인 이전 출력을 소비하지 않습니다. coinbase의 새 출력은 다른 새 출력과 같은 포함 규칙을 따릅니다. 빈 항목도 생략합니다. 지갑은 주소를 올바른 스크립트로 변환해야 하며, 인쇄된 주소 문자열을 검색하는 것만으로는 부족합니다. 이 필터는 거래 식별자인 txid, 서명 같은 witness 데이터나 임의의 메모를 찾는 범용 검색 도구가 아닙니다. [2] [3]

블록을 받은 안나가 자기와 관련된 내용이 없음을 발견할 수도 있습니다. 이런 잘못된 일치는 작은 필터를 위한 정상적인 절충이며 그 자체로 오류를 증명하지는 않습니다. 기술적으로 항목을 숫자 지문으로 바꾸어 정렬하고, 차이를 Golomb-Rice 부호화로 작게 저장합니다. basic의 값은 P=19, M=784931입니다. 없는 항목 하나를 조회했을 때 일치할 확률은 약 1/M이며, 감시 항목이 많으면 일치할 기회도 늘어납니다. 지갑 전체에 고정된 오류율은 아닙니다. 올바르게 만든 필터는 포함된 항목을 놓치지 않습니다. 다만 부정 결과를 신뢰하려면 필터가 정확하고 데이터 종류가 대상에 속하며 조회도 올바라야 합니다. [2]

BIP 157은 필터 전송과 연결된 헤더를 정의합니다. 각 헤더는 현재 필터의 암호학적 지문인 hash와 이전 헤더를 연결합니다. 필터가 바뀌면 예상한 연결이 깨집니다. 그러나 이 연결 사슬은 Bitcoin 블록 헤더에 들어 있지 않으며 채굴이 그 내용을 직접 확정하지 않습니다. 부정직한 피어는 가짜 필터와 계산상 올바른 연결 지문을 함께 만들 수 있습니다. Bitcoin 자체를 바꾸지는 못해도 고립된 클라이언트에게 정보를 숨길 수 있습니다. 따라서 수학적 연결 확인에는 바탕 데이터의 정확성 확인도 따라야 합니다. [1]

BIP 157은 여러 피어를 비교하며 그중 적어도 하나가 정직한 정보원이라는 조건에 의존합니다. 서로 다르면 클라이언트는 처음 어긋난 지점을 찾고 원자료로 필터를 확인할 수 있습니다. basic을 만들 때 새 블록만으로 부족할 수 있습니다. 그 거래들이 소비하는 이전 출력의 스크립트도 필요하기 때문입니다. 재구성도 별도로 처리해야 합니다. 네트워크가 누적 작업량이 더 큰 유효한 블록의 다른 가지로 바뀌는 상황입니다. 지갑은 필터를 새 가지에 연결하고 기록과 잔액을 갱신해야 합니다. 같은 높이, 즉 체인의 같은 순서라도 동일한 블록은 아닐 수 있습니다. [1] [3]

지갑에는 필터와 선택한 전체 블록을 얻을 경로가 모두 필요합니다. 노드가 필터를 만든 뒤 오래된 블록을 지웠다면 다른 정보원이 제공해야 합니다. Bitcoin Core에서 getblockfilter는 해당 인덱스가 활성화된 경우 지정 블록의 필터와 헤더를 반환합니다. 이 명령을 쓸 수 있다는 사실만으로 다른 노드에 공개 P2P 서비스를 제공하거나 전체 기록을 보관한다고 볼 수는 없습니다. 기존 블록의 필터는 Mempool의 미확인 거래도 알리지 않습니다. 대기 중인 결제를 표시하려면 별도 방식이 필요합니다. 이런 운영 세부 사항이 가벼운 지갑의 실제 작동 품질을 결정합니다. [1] [4]