No meu artigo anterior sobre o Mempool, criei uma estrutura conceitual simples para raciocinar sobre a funcionalidade básica do Mempool e como ela foi usada por diferentes tipos de usuários da rede Bitcoin. Nesta peça, analisarei as diferenças entre a política de relé e as regras de consenso e por que, por padrão, os nós do Bitcoin não transmitem alguns tipos de transações de bitcoin, apesar de serem um consenso válido.
Em primeiro lugar, independentemente da rede ponto a ponto se recusar a transmitir certos tipos de transações válidas de consenso, se essas transações acabarem no Mempool de um mineiro e serem selecionadas para inclusão em um bloco, elas serão recebidas e baixadas por nós quando receberem esse bloco. Nada pode impedir que isso não tenha mudanças de consenso para tornar essas classes de transações inválidas sob regras de consenso.
Existem diferentes tipos de filtros por diferentes razões. Os três tipos gerais de filtros são aqueles que protegem os nós (e, portanto, a rede) da negação de serviço (DOS), aqueles que protegem ganchos de atualização para futuros softforks e aqueles que desencorajam suavemente as coisas que os bitcoiners podem não gostar, mas não apresentam danos graves a nós individuais ou à rede.
Negação de vetores de serviço
Os nós Bitcoin são programas de computador em execução em computadores. Isso significa que eles têm todas as restrições técnicas de qualquer programação em execução em qualquer computador, limitações para armazenamento, memória, potência de processamento etc. Essa é a raiz do motivo pelo qual o limite de tamanho de blocos foi introduzido e mantido, de modo a criar uma restrição global, mantendo os custos de verificação razoáveis para dispositivos normais.
Essa classe de filtros foi projetada especificamente para garantir que, mesmo com as transações individuais do BlockSpace, que possam ser criadas que possam consumir muitos recursos de um nó não o fazem.
O exemplo mais simples desse filtro é o mínimo necessário para uma transação para propagar, e as regras de substituição por taxa (RBF) ditam quando uma versão diferente da mesma transação pode substituir a anterior, ou seja, apenas quando paga uma taxa mais alta que a última versão. Depois de assinar uma transação com uma taxa, você está no gancho. A menos que você duplique, qualquer mineiro que obtenha essa transação possa minerá -lo e coletar essa taxa. Não há como escapar do pagamento desse custo além de gastar seu UTXO em uma transação diferente primeiro (que também requer uma taxa).
A razão para isso é a proteção do DOS. Sem ter que se colocar no gancho por uma taxa que eles não podem escapar do pagamento, um usuário pode simplesmente criar variações infinitas de uma única transação e spam as mempiools de todos os nó da rede, comer largura de banda e memória no processo. Nada os impediria de fazer isso para sempre. Os nós da rede faria, ou os custos de largura de banda se tornam tão exorbitantes que os usuários não podiam pagar.
Outro exemplo de transações filtradas pela política de relé são caras para validar transações. É possível criar transações incrivelmente caras de verificar. Alguns blocos podem ser criados que levarão um nó Bitcoin em execução no hardware normal do consumidor durante uma hora para verificar. Isso é feito criando grandes scripts personalizados projetados para criar a quantidade máxima de verificações de assinatura que podem ser e enchendo um bloco cheio de nada além dessas transações.
Tais estruturas de script foram construídas antes e os tempos de verificação testados em diferentes tipos de máquinas, mas a estrutura exata desses scripts não foi revelada publicamente pelos desenvolvedores que o fizeram por razões óbvias. Essas são transações que podem literalmente impedir toda a rede.
Um último exemplo de proteção do DOS seria o limite de poeira. As transações criando UTXOS com um valor de Satoshi abaixo do limite de poeira não são transmitidas porque a taxa para gastar que o UTXO seria maior que o valor de Satoshi da saída. Isso o torna inacômico e improvável que seja gasto, o que significa que o conjunto do UTXO teria que armazenar esses resultados para sempre. Isso pode criar um conjunto UTXO inchado que torne a validação de bloco mais intensiva computacionalmente.
Future Softforks
Todas as principais atualizações do protocolo Bitcoin foram feitas com o Softforks, um mecanismo de atualização que permite que a nova funcionalidade de script seja adicionada ao protocolo de uma maneira que os nós não atualizados ainda aceitem como válidos.
Isso é possível porque o script de bitcoin inclui códigos opciais “indefinidos”, o que significa que qualquer uso deles é considerado automaticamente válido porque não há regras de verificação atualmente definidas para eles. Quando as pessoas atualizam seus nós para fazer cumprir as novas regras, os nós atualizados aplicarão as novas regras contra esse código OPC, e as mais antigas simplesmente aceitarão qualquer uso deles. Enquanto os mineradores não atribuem transações violando as novas regras antes da atualização da rede de nós, todos permanecem na mesma blockchain e tudo é compatível com versões anteriores.
As transações usando esses códigos OPCs indefinidos são filtrados pela política de relé. Isso é feito para preservar a atualização do protocolo Bitcoin no futuro.
Se os usuários fizessem UTXOs usando esses códigos opcorais indefinidos, digamos em combinação com os definidos, para que não fossem gastados por ninguém, se esse código de operação indefinido recebesse regras de verificação em um softfork, que o UTXO se tornaria indispensável. A estrutura do script não seria capaz de atender às novas regras de verificação aplicadas durante o softfork.
Permitir que eles se propagem e sejam confirmados, poderia permitir que o UTXOS usando o OPCode indefinido transforme qualquer atualização potencial da Softfork no futuro em um dilema filosófico de não atualizar ou tornar inestimável as moedas de algumas moedas.
Desânimo
Existem alguns tipos de transações que, embora não causem danos reais aos nós na rede, ou seja, nós de travamento, usando memória ou recursos excessivos, um grande segmento de usuários de rede acham indesejável ou contrário ao objetivo principal do Bitcoin.
Exemplos dessas transações seriam aqueles que usavam grandes saídas de op_return ou inscrições que usam o campo da testemunha para escrever informações arbitrárias na blockchain. Eles são desencorajados porque não são vistos como um caso de uso primário da rede Bitcoin.
Nem tudo é o mesmo
Essas diferentes classes de filtros na política de relé são coisas claramente claramente diferentes. Nem todos os filtros de revezamento existem pelo mesmo motivo, nem todos envolvem os mesmos incentivos para os mineiros minerem (ou não os meus). Cada um deles existe com um objetivo específico de proteger seu nó, ou a blockchain, de diferentes tipos de coisas que são legitimamente prejudiciais ou apenas indesejáveis.
Todos os filtros não são os mesmos, e a diferença entre as coisas que estão filtrando é enorme. Tudo, desde transações problemáticas que podem travar a rede (que deve ser corrigida no nível do consenso), para desencorajar transações inofensivas que as pessoas acham indesejável.
É importante perceber a diferença entre essas coisas. Por exemplo, um mineiro pode minerar uma transação simplesmente indesejável se um usuário pagar por isso, mas nenhum mineiro racional construiria e minaria um bloco cheio de transações que travariam toda a rede. Isso prejudicaria seu investimento.
Fonte: bitcoinmagazine.com
