Debate sobre a Segurança do XRP Ledger Intensifica-se Após o Medo BatchGate

Conteúdo editorial confiável, revisado por especialistas líderes na indústria e editores experientes. Divulgação de publicidade As consequências do susto do XRP Ledger com o BatchGate estão se transformando numa discussão mais ampla sobre quem é realmente responsável pela segurança do protocolo e quanta fiscalização as principais alterações devem passar antes de chegarem à mainnet. Em uma declaração publicada na segunda-feira, o operador de validadores de longa data Daniel Keller afirmou que a quase-falha relacionada ao XLS-56 expôs “uma falha sistêmica nos processos de revisão” e o levou a retirar o apoio a todas as alterações atualmente em consideração.

A publicação de Keller foi apresentada como uma clarificação do que os validadores dUNL devem fazer, após o que ele descreveu como uma confusão generalizada após o incidente do Batch. Seu ponto central foi que os validadores são participantes de governança, não auditores não remunerados. “O papel dos validadores dUNL é específico e limitado: coordenamos a ativação (ou rejeição) de alterações votando ‘Sim’ ou ‘Não’ assim que uma alteração é proposta”, escreveu. “Devemos julgar as alterações pendentes. Essa é nossa principal função de governança.”

Leitura relacionada: XRP espelha o Russell 2000, o que isso significa e por que é importante. Essa distinção importa porque o XLS-56, também conhecido como Batch, foi interrompido apenas após a descoberta de uma falha lógica na validação de assinaturas pouco antes da ativação na mainnet. O bug poderia ter permitido a execução não autorizada de transações e potencialmente colocado bilhões de XRP em risco antes que a alteração fosse pausada e corrigida na rippled 3.1.1.

Preocupações com a Governança do XRP Ledger, com Ripple em Foco

Para Keller, o episódio não foi um erro isolado, mas o mais recente exemplo de um problema estrutural mais profundo. “O dUNL não é um corpo de revisão de código livre ou auditoria de protocolo. Esperar que os validadores gastem dezenas de horas não remuneradas revisando códigos complexos de alterações nunca fez parte do projeto e nunca fará,” escreveu. “Em vez disso, as partes que propõem alterações devem ser obrigadas a fornecer documentação completa, suítes de testes, análises de segurança e provas formais sob solicitação. Se quiser meu voto, prove que a mudança é segura e benéfica.”

Ele argumentou que agora a responsabilidade recai sobre a Ripple para financiar esse processo de forma mais agressiva. “Não votarei a favor de futuras alterações até que a Ripple faça um compromisso credível e concreto de aumentar substancialmente o investimento na engenharia do protocolo central do XRPL, na revisão de segurança e na sustentabilidade a longo prazo,” disse Keller. “Se o XRP é realmente a ‘Estrela do Norte’ da Ripple, como foi reiteradamente declarado, então a segurança fundamental e a descentralização da rede devem receber a atenção e os recursos que merecem.”

A resposta imediata de Keller foi direta: retirar todos os votos de “Sim” atuais, exceto para correções pendentes, e recusar-se a atualizar para rippled 3.1.1, a menos que permanecer na versão anterior arrisque a remoção da rede. Ele também afirmou que o fato de um pesquisador independente e uma ferramenta de IA terem sido necessários para evitar danos reforça o quão tênue se tornou a rede de segurança atual.

Outras vozes proeminentes do XRPL concordaram que o processo precisa mudar, embora nem todos apoiem uma desaceleração. Vet, um validador bem conhecido do XRPL, chamou o incidente do Batch de “uma oportunidade enorme” para a comunidade e a Fundação XRPL repensar como o protocolo evolui. Ele defendeu um cronograma de alterações mais lento, mais revisões pagas, múltiplas auditorias para mudanças maiores, “attackathons” na testnet e um programa de recompensas por bugs grande o suficiente para atrair pesquisadores de elite.

Leitura relacionada: Financiamento de construtores do XRP muda em 2026 enquanto Ripple apoia novo modelo. Keller, no entanto, rejeitou a ideia de que a solução é simplesmente desacelerar. “A curto prazo, precisamos de algum tipo de acordo com a Cantina. Eles se provaram e é o melhor que temos agora,” escreveu. “A médio prazo, as recompensas por bugs precisam ser elevadas e pagar dinheiro sério. Primeiro, as pessoas precisam ser incentivadas a analisar o código; segundo, deve compensar fazer uma divulgação responsável.”

Ele foi mais longe em uma continuação que capturou o clima do debate: “Não quero desacelerar nossa velocidade de desenvolvimento; levamos anos para chegar ao nível atual, e ainda somos lentos. Mais recursos precisam ser alocados, e o processo precisa começar ontem.”

Isso deixa o XRP Ledger numa posição tensa, mas familiar: uma rede tentando adicionar funcionalidades sem comprometer a credibilidade de sua camada base. BatchGate não se tornou uma exploração ao vivo. Mas forçou uma questão mais aguda a ser colocada em aberto: o pipeline de alterações do XRPL ainda opera com profundidade de revisão suficiente para a escala de mudanças que estão sendo propostas.

No momento da publicação, o XRP era negociado a $1.3566.

XRP cai abaixo da EMA de 200 semanas novamente, gráfico de 1 semana | Fonte: XRPUSDT no TradingView.comImagem em destaque criada com DALL.E, gráfico do TradingView.com Processo Editorial do bitcoinist é centrado em fornecer conteúdo cuidadosamente pesquisado, preciso e imparcial. Mantemos padrões rigorosos de fontes, e cada página passa por uma revisão diligente por nossa equipe de especialistas em tecnologia e editores experientes. Esse processo garante a integridade, relevância e valor do nosso conteúdo para nossos leitores.