O mempool do Bitcoin: Por que temos filtros?
Uma análise sobre os diferentes filtros de política de retransmissão e por que eles sempre fizeram parte do mempool de um nó.
Texto por: Shinobi
No meu artigo anterior sobre o mempool, apresentei uma estrutura conceitual simples para entender a funcionalidade básica do mempool e como ele é usado por diferentes tipos de usuários da rede Bitcoin. Neste texto, analisarei as diferenças entre regras de consenso e políticas de retransmissão, e por que, por padrão, nós do Bitcoin não retransmitem certos tipos de transações, mesmo sendo válidas pelo consenso.
Antes de tudo, independentemente da rede ponto a ponto se recusar a retransmitir certos tipos de transações válidas, se essas transações chegarem ao mempool de um minerador e forem selecionadas para inclusão em um bloco, elas serão recebidas e baixadas pelos nós quando esse bloco for propagado. Nada pode impedir isso, exceto mudanças nas regras de consenso que tornem essas transações inválidas.
Existem diferentes tipos de filtros por razões distintas. As três categorias gerais de filtros são: os que protegem os nós (e, portanto, a rede) contra ataques de negação de serviço (DoS), os que protegem ganchos de atualização para futuros softforks e os que desencorajam suavemente práticas que não causam danos sérios, mas que a comunidade do Bitcoin considera indesejáveis.
Vetor de negação de serviço (DoS)
Nós do Bitcoin são programas de computador, sujeitos a limitações como armazenamento, memória, capacidade de processamento, etc. Isso está na raiz do motivo pelo qual o limite de tamanho de bloco foi introduzido e mantido: para manter os custos de verificação razoáveis em dispositivos comuns.
Essa classe de filtros é projetada para garantir que, mesmo com o limite de espaço em bloco, transações individuais que possam consumir muitos recursos de um nó não consigam fazê-lo.
O exemplo mais simples é a taxa mínima exigida para que uma transação se propague, e as regras de Replace-By-Fee (RBF), que determinam quando uma nova versão de uma transação pode substituir a anterior — ou seja, apenas quando pagar uma taxa maior que a anterior. Uma vez que você assina uma transação com uma taxa, está comprometido. A não ser que você faça um double spend, qualquer minerador que a receba pode incluí-la num bloco e coletar essa taxa. Não há como escapar desse custo a não ser gastando seu UTXO em outra transação antes (o que também exige taxa).
A razão disso é a proteção contra DoS. Sem essa exigência de custo, um usuário poderia criar infinitas variações de uma transação e entupir os mempools de todos os nós da rede, consumindo largura de banda e memória. Isso poderia levar à queda dos nós ou a custos de rede tão altos que se tornariam inviáveis para os usuários.
Outro exemplo são transações caras de validar. É possível criar transações que demandam grande esforço computacional. Já se criaram blocos que levam mais de uma hora para serem verificados por nós rodando em hardware comum, utilizando scripts personalizados que geram a quantidade máxima de verificações de assinatura. Esses scripts foram testados, mas sua estrutura exata não foi revelada publicamente pelos desenvolvedores, por razões óbvias — essas transações poderiam paralisar a rede.
Outro caso é o limite de poeira (dust limit). Transações que criam UTXOs com valor inferior a esse limite não são retransmitidas porque a taxa para gastá-los seria maior que o valor em satoshis. Isso torna o gasto inviável e esses UTXOs provavelmente nunca seriam usados, inchando o conjunto de UTXOs e tornando a validação de blocos mais lenta.
Futuros softforks
Todas as grandes atualizações do protocolo Bitcoin foram feitas via softforks — um tipo de atualização que permite a adição de novas funcionalidades sem invalidar a compatibilidade com versões antigas.
Isso é possível porque o Bitcoin Script inclui opcodes “não definidos”, que são automaticamente considerados válidos por não haver regras de verificação associadas. Quando os nós são atualizados para aplicar novas regras, essas passam a valer apenas para os nós atualizados. Desde que os mineradores não incluam transações que violem essas novas regras antes que a maioria dos nós tenha se atualizado, todos permanecem na mesma blockchain.
Transações que usam esses opcodes indefinidos são filtradas pelas políticas de retransmissão. Isso é feito para preservar a capacidade futura de atualização do protocolo.
Se usuários criarem UTXOs usando opcodes indefinidos, possivelmente combinados com opcodes definidos de forma que ninguém consiga gastá-los, e mais tarde essas operações ganharem regras num softfork, esses UTXOs podem se tornar irrecuperáveis. Confirmar essas transações hoje pode, no futuro, gerar um dilema: atualizar o protocolo e tornar moedas inutilizáveis ou não atualizar e travar o desenvolvimento.
Desencorajamento
Existem tipos de transações que, embora não causem danos técnicos à rede (como travar nós ou usar recursos em excesso), são vistas por parte significativa da comunidade como indesejáveis ou contrárias ao propósito do Bitcoin.
Exemplos incluem transações com grandes campos OP_RETURN, ou inscrições usando o campo Witness para armazenar informações arbitrárias na blockchain. Essas práticas são desencorajadas porque não são consideradas um uso legítimo da rede Bitcoin.
Nem tudo é igual
Essas diferentes categorias de filtros de retransmissão são claramente distintas entre si. Nem todos os filtros existem pelos mesmos motivos, nem todos envolvem os mesmos incentivos para os mineradores. Cada um tem um propósito específico: proteger seu nó ou a blockchain de problemas graves ou apenas desestimular usos questionáveis.
É importante entender essas diferenças. Por exemplo, um minerador pode estar disposto a minerar uma transação indesejável se ela pagar bem, mas nenhum minerador racional criaria um bloco cheio de transações que poderiam travar a rede. Isso destruiria seu próprio investimento.
