Desenvolvedor Destaca Principais Riscos na Proposta de Soft Fork com Dados Reduzidos do Bitcoin

Revisão dos Dados de Transação Mostra que RDTS Pode Bloquear Casos de Uso Essenciais do Bitcoin

Uma nova proposta de soft fork projetada para reduzir o armazenamento excessivo de dados na blockchain do Bitcoin vem atraindo duras críticas recentemente. Na quarta-feira, o analista independente e desenvolvedor do mempool.space, Mononaut, publicou uma análise detalhando o potencial dano colateral que o conjunto de regras pode causar.

A proposta, conhecida como Softfork Temporário de Dados Reduzidos (RDTS), introduz uma série de restrições de nível de consenso destinadas a reduzir transações pesadas em dados—um esforço que os desenvolvedores dizem ser necessário após a atualização do Bitcoin Core v30 que removeu limites nos dados OP_RETURN.

RDTS seria aplicado por cerca de um ano se ativado, limitando scriptPubKeys a 34 bytes, limitando saídas OP_RETURN a 83 bytes, restringindo blocos de controle Taproot, proibindo versões de testemunha indefinidas e desativando categorias inteiras de lógica Tapscript. Os defensores do BIP argumentam que as medidas atuam como um freio de emergência contra uploads arbitrários de dados que poderiam expor operadores de nós a responsabilidades legais se materiais ilegais fossem incorporados na cadeia.

A avaliação de Mononaut, no entanto, quantifica os impactos práticos dessas restrições revisando a atividade histórica da blockchain para ver quais transações reais teriam violado as regras propostas. Suas descobertas sugerem uma interrupção significativa. Sob o limite de tamanho do scriptPubKey, todas as saídas pay-to-public-key (P2PK) e multisig (P2MS) seriam inválidas. Essa restrição também afeta um pequeno número de saídas não padrão em transações passadas.

Uma das regras mais abrangentes—invalidando operações OP_PUSHDATA com cargas úteis acima de 256 bytes—não afetaria envelopes de inscrição, assumindo que apenas pushes executados se qualificam. Mas Mononaut enfatizou que versões de testemunha indefinidas impactariam mais de 54.000 transações históricas, muitas das quais usaram saídas não convencionais para contornar os limites de dados OP_RETURN. Como os comprimentos de versão de testemunha são rigidamente definidos nos BIPs 141 e 341, a proposta, conforme escrita, bloquearia mesmo alguns formatos modernos válidos, como âncoras P2A.

Leia também: Desenvolvedores do Bitcoin Core Unem Mudanças de Política Controversas: Um Fork Está à Frente?

Mononaut detalhou que RDTS também invalida pilhas de testemunha contendo um anexo Taproot. Embora raro, o desenvolvedor do mempool.space nota que pelo menos 11 transações usaram um anexo para fins pesados em dados. Uma categoria mais significativa, Mononaut enfatizou, são blocos de controle Taproot grandes: cerca de 32.000 gastos passados incluem blocos de controle profundidade-100+ frequentemente usados para incorporação de dados, mas mesmo alguns experimentos não relacionados a dados dependem de configurações menores e legítimas que seriam desativadas. Um endereço ativo gasta consistentemente em profundidade de bloqueio de controle 11, o que seria rejeitado sob RDTS.

Os itens mais rígidos da proposta—proibindo OP_SUCCESS* e qualquer execução do Tapscript de OP_IF ou OP_NOTIF—alcançam bem além dos envelopes de inscrição. Mononaut destaca duas transações históricas de OP_SUCCESS, incluindo a transação de quebra-relâmpago de Burak, e cerca de 70 gastos Taproot baseados em OP_IF sem inscrição. Várias dessas são primitivas financeiras, incluindo modelos decaindo de multisig e designs de contratos bloqueados por tempo e hash (HTLC). Algumas se originam de carteiras que intencionalmente desativaram seu caminho-chave, deixando o gasto por caminho de script como a única maneira de mover fundos.

Os defensores do RDTS argumentam que os usuários com scripts afetados poderiam recorrer ao gasto por caminho-chave. Ainda assim, os dados de Mononaut desafiam essa suposição diretamente: cerca de 560.000 gastos Taproot históricos vêm de saídas cujo caminho-chave foi comprovadamente desativado, tornando OP_IF e funções semelhantes essenciais em vez de opcionais.

Os apoiadores do soft fork temporário sustentam que RDTS é uma medida protetiva de curto prazo projetada para preservar a utilidade monetária do Bitcoin, prevenir riscos legais e reduzir os encargos nos nós limitando o armazenamento de dados. Críticos argumentam que restrições amplas no comportamento do Tapscript correm o risco de introduzir censura de facto, desativar tipos de transações válidas e quebrar aplicações existentes.

O debate espelha disputas anteriores sobre o crescimento de dados impulsionado por inscrições, refletindo discordâncias mais profundas sobre se o Bitcoin deve permanecer estritamente monetário ou continuar a acomodar usos experimentais. Como a proposta permanece em forma de rascunho, a discussão continua entre desenvolvedores, pesquisadores e participantes do ecossistema.

FAQ ❓

• O que é RDTS?
  Uma proposta de soft fork temporário que restringe vários recursos de script e dados do Bitcoin.
• Por que RDTS está sendo debatido?
  Os apoiadores querem conter abusos de dados, enquanto os críticos dizem que ele desativa transações válidas.
• O que Mononaut encontrou?
  Sua análise mostra que muitas transações históricas falhariam sob as regras do RDTS.
• Quanto tempo duraria o RDTS?
  A proposta prevê uma janela de ativação de um ano se adotada.