Compact Block Filters

Anna abre a carteira do celular após algum tempo sem usá-la. O aplicativo precisa descobrir se alguém lhe pagou desde a última conexão ou se parte dos fundos foi gasta. Em vez de todas as transações, baixa pequenos filtros e os compara às condições das saídas acompanhadas. Uma saída é a parte de uma transação que define um valor e as regras para gastá-lo depois. Havendo correspondência, o aplicativo pede o bloco inteiro e procura a transação real. Não deve aumentar o saldo apenas pelo resultado do filtro. O filtro não é extrato de conta nem prova de propriedade. Antes da busca, o cliente sincroniza cabeçalhos, dados resumidos que identificam blocos, e os cabeçalhos encadeados dos filtros. [1]

Na abordagem anterior BIP 37, o cliente enviava a outro nó um filtro formado pelos dados que queria acompanhar. Aqui o sentido se inverte: o servidor fornece um filtro do bloco e Anna pesquisa localmente. Para o mesmo bloco e tipo de filtro, os clientes recebem conteúdo igual. Assim, não precisam revelar diretamente a cada servidor os scripts procurados. Isso não garante anonimato: o outro nó ainda pode observar endereço IP, horários e quais blocos completos a carteira pede depois. Distribuir os downloads entre vários nós reduz a informação reunida por um só, mas não elimina toda possibilidade de correlação. [1]

Os Compact Block Filters selecionam blocos que merecem exame. Compact Blocks, definido no BIP 152, resolve outro problema: economizar dados na transmissão de blocos usando identificadores curtos de transações que o destinatário frequentemente já conhece. Ele as busca no seu Mempool, conjunto local de transações não confirmadas, e solicita as ausentes. Nenhuma dessas ferramentas verifica sozinha todas as regras do Bitcoin. Um Full Node, ou nó completo, valida blocos e transações de forma independente segundo as regras da rede. Uma carteira leve que confere apenas cabeçalhos e a inclusão de sua transação faz uma verificação mais restrita. Economizar dados e validar tudo são propriedades diferentes. [1] [5]

O BIP 158 especifica o formato. O filtro basic inclui o scriptPubKey, o script que define condições de gasto, das novas saídas, exceto as iniciadas por OP_RETURN. Também inclui scripts de saídas anteriores gastas dentro do bloco. Para as entradas, a exceção é a coinbase, primeira transação do bloco que distribui a recompensa do minerador e não gasta saídas anteriores comuns. Suas novas saídas seguem as mesmas regras de inclusão que as demais saídas novas. Elementos vazios são omitidos. A carteira deve converter o endereço no script correto; procurar seu texto impresso não basta. O filtro não é um buscador geral de txid, os identificadores de transações, de dados witness como assinaturas, ou de anotações arbitrárias. [2] [3]

Depois de baixar um bloco, Anna pode descobrir que nada ali lhe diz respeito. Essa correspondência falsa é o custo normal de um filtro pequeno, não uma prova de falha por si só. Tecnicamente, os elementos viram impressões numéricas, são ordenados e suas diferenças são armazenadas de forma compacta com codificação Golomb-Rice. Para basic, P=19 e M=784931. Uma consulta sobre um elemento ausente tem probabilidade aproximada de correspondência de 1/M; acompanhar mais elementos cria mais oportunidades. Não é uma taxa fixa de erro para toda a carteira. Um filtro corretamente construído não deixa passar um elemento incluído. Um resultado negativo exige filtro correto, tipo de dado coberto e consulta adequada. [2]

O BIP 157 define o transporte dos filtros e seus cabeçalhos encadeados. Cada cabeçalho liga o hash, uma impressão criptográfica do filtro atual, ao cabeçalho anterior. Alterar o filtro rompe o vínculo esperado. Essa cadeia, porém, não faz parte do cabeçalho do bloco Bitcoin, e a mineração não firma diretamente um compromisso com seu conteúdo. Um nó desonesto pode preparar filtros falsos acompanhados de impressões encadeadas matematicamente corretas. Isso não muda o Bitcoin, mas pode ocultar informações de um cliente isolado. A verificação dos vínculos deve, portanto, vir acompanhada da verificação dos dados. [1]

O BIP 157 pressupõe a comparação de nós com pelo menos uma fonte honesta. Se houver divergência, o cliente pode localizar o primeiro ponto de desacordo e conferir o filtro com os dados originais. Construir basic pode exigir mais que o novo bloco: também são necessários scripts das saídas anteriores gastas por suas transações. Uma reorganização requer cuidado especial: a rede passa a outro ramo de blocos válidos com maior trabalho acumulado. A carteira precisa ligar os filtros ao novo ramo e atualizar histórico e saldo. A mesma altura, ou posição na cadeia, não identifica necessariamente o mesmo bloco. [1] [3]

A carteira precisa de filtros disponíveis e de uma maneira de obter os blocos completos selecionados. Um nó pode apagar blocos antigos depois de criar seus filtros; outra fonte terá de fornecê-los. No Bitcoin Core, getblockfilter retorna o filtro e seu cabeçalho para um bloco específico quando o índice correspondente está ativo. A disponibilidade do comando não prova a existência de serviço público P2P para outros nós nem acesso a todo o histórico. Filtros de blocos existentes também não anunciam transações não confirmadas no Mempool. Para mostrar pagamentos pendentes, o aplicativo precisa de outro mecanismo. Esses detalhes determinam se uma carteira leve funciona bem de fato. [1] [4]