XRPL corrige falha crítica pré-mainnet, mas aplicativos clientes continuam em risco

Os validadores do XRP Ledger (XRPL) colocaram o BatchV1_1 em um caminho condicional para ativação às 14:06:41 UTC em 29 de setembro, transformando um quase erro de segurança em um teste ao vivo do processo de emenda da rede e seu software circundante.

Em 22 de setembro, o xrpldashboard mostrou 30 dos 35 validadores confiáveis apoiando a emenda, acima do seu limite de 28 votos exibido. A maioria apareceu pela primeira vez no livro-razão em 15 de setembro.

De acordo com as regras de emenda do XRPL, o apoio deve permanecer acima de 80% por duas semanas. Uma queda para 80% ou menos encerra o período de maioria, portanto, a data de ativação permanece condicional.

29 de setembro é o primeiro teste de produção para verificar se o processo de validação do XRPL, a implementação de referência e o ecossistema de clientes converteram uma perigosa falha pré-mainnet em uma infraestrutura de transação atômica utilizável.

O firewall do validador funcionou antes da mainnet

A emenda Batch original nunca foi ativada na mainnet do XRP Ledger. Em fevereiro, pesquisadores encontraram uma falha crítica de autorização enquanto a emenda ainda estava em sua fase de votação, e os validadores foram aconselhados a rejeitá-la.

A divulgação oficial de vulnerabilidade da XRPL Labs afirma que nenhum fundo estava em risco.

A falha estava no loop que verificava as contas autorizando um lote. Se o código encontrasse um signatário para uma conta recém-criada cuja chave correspondesse a essa conta, ele retornava sucesso imediatamente em vez de continuar através dos signatários restantes.

Um atacante poderia colocar esse signatário válido primeiro e, em seguida, adicionar uma entrada forjada que supostamente autorizasse uma conta vítima. Se a emenda tivesse sido ativada, a transação da vítima não verificada poderia ter sido executada sem as chaves da vítima.

A resposta da XRPL veio em duas etapas. A versão 3.1.1 marcou as emendas Batch e fixBatchInnerSigs como não suportadas, bloqueando sua ativação. O BatchV1_1 posteriormente as substituiu por um caminho de autorização reescrito e defesas adicionais.

O episódio foi uma falha capturada na fronteira entre o lançamento de software e a ativação do protocolo.

A especificação final XLS-56 da XRPL Foundation agora exige que um lote de múltiplas contas contenha o conjunto exato e completo de BatchSigners cuja autorização as transações internas normalmente precisariam, além da conta cuja assinatura normal autoriza a transação externa.

Entradas ausentes, extras, duplicadas ou incorretamente ordenadas causam rejeição.

Cada BatchSigner também assina mais do que uma coleção solta de transações internas. A carga útil vincula a assinatura à conta externa, seu número de sequência ou bilhete, o modo de lote selecionado, os hashes ordenados de cada transação interna e a conta BatchSigner.

Uma entrada multi-assinada também vincula cada conta de signatário aninhada. Isso impede que uma assinatura válida seja transferida para uma transação externa diferente ou reatribuída a outro participante.

A implementação de referência mesclada adiciona aplicação em torno desse design, incluindo verificação de ordem e unicidade dos signatários, limites de contagem de transações, rejeição de transações internas enviadas diretamente e proteções contra replay de livro-razão.

Juntas, essas mudanças abordam tanto o bug de sucesso prematuro divulgado quanto maneiras adjacentes que dados de lote malformados ou reproduzidos poderiam cruzar limites de autorização.

Um Batch contém de duas a oito transações internas. Cada transação interna não carrega assinatura ou taxa e é marcada para que não possa ser enviada independentemente. O Batch externo seleciona exatamente um dos quatro modos:

• ALLORNOTHING: cada transação interna deve ter sucesso ou nenhuma de suas mudanças de estado é confirmada.
• ONLYONE: a primeira transação interna bem-sucedida é a única aplicada.
• UNTILFAILURE: as transações são aplicadas em ordem até que uma falhe.
• INDEPENDENT: cada transação interna é tentada independentemente dos resultados das outras.

O BatchV1_1 pode suportar fluxos atômicos de tudo ou nada, mas nem todo lote é atômico nesse sentido restrito. Os desenvolvedores também podem usá-lo para fallback ordenados ou pacotes independentes.

A ativação transfere risco para a implementação

A armadilha de integração mais imediata é que um Batch externo pode retornar tesSUCCESS mesmo quando uma ou mais transações internas falham. Os clientes devem inspecionar os metadados e o código de resultado de cada transação interna para determinar o que aconteceu.

Essa distinção é importante fora do modo ALLORNOTHING, onde a execução parcial ou independente é intencional.

O suporte ao BatchV1_1 foi enviado no xrpld 3.3.0 em 6 de agosto. Uma vez que a emenda é ativada, um servidor que não entende as novas regras fica bloqueado por emenda. Ele não pode mais validar o livro-razão de forma confiável ou participar do consenso até que seja atualizado.

Um problema registrado contra o xrpl.js documentou que a versão 5.0.0 construía assinaturas de Batch usando a carga útil mais antiga, omitindo a conta externa, a sequência e a vinculação de participantes. Nós habilitados para BatchV1_1 rejeitaram essas assinaturas com temBAD_SIGNATURE.

O histórico de lançamentos do xrpl.js registra suporte compatível na versão 5.1.0.

A emenda reparada do BatchV1_1 do XRPL se aproxima de um teste de ativação condicional após os validadores rejeitarem um design anterior de loop de assinante.

As linhas de carteiras e indexadores refletem a orientação de integração nas regras detalhadas do XLS-56. O protocolo pode rejeitar uma assinatura malformada, mas não pode forçar uma carteira a explicar um pacote complexo de forma clara ou um explorador a apresentar cada resultado interno em contexto.

A especificação também sinaliza a corrida à frente como uma área ainda sob investigação. Autorizações mais fortes impedem que uma parte forje a aprovação de outra conta, mas não eliminam todos os riscos criados ao agrupar várias ações voltadas para o mercado em uma única submissão ordenada.

O que 29 de setembro provará

Se a maioria se mantiver, a ativação mostrará que o processo de validação do XRPL pode parar uma emenda perigosa, direcionar operadores para uma versão desativada e, posteriormente, mover uma substituição reparada através da mesma maquinaria de governança.

Isso também começará um teste no mundo real de se servidores, bibliotecas de assinatura, carteiras e infraestrutura de dados concordam sobre o novo formato de transação e seus resultados.

Não provará que os aplicativos adotaram o BatchV1_1, que os usuários desejam o recurso ou que a demanda de transações na rede aumentará. O voto da emenda e os lançamentos de software estabelecem a disponibilidade do protocolo, mas não fornecem evidências de compra adicional de XRP.

Os sinais úteis virão após a ativação: se nós desatualizados ficarem bloqueados, se falhas de assinatura se agruparem em torno de versões antigas de clientes, se carteiras apresentarem pacotes de várias contas de forma inteligível e se exploradores relatarem resultados internos sem confundir o sucesso externo com a execução completa.

Os validadores do XRPL passaram no primeiro teste ao impedir que a falha original do Batch chegasse à mainnet. A ativação condicional de 29 de setembro questiona se o ecossistema aprendeu o suficiente com essa quase falha para operar a substituição com segurança.

Este conteúdo é fornecido apenas para fins informativos gerais e não constitui aconselhamento financeiro, de investimento, jurídico ou tributário. Quaisquer eventos, recompensas, promoções online ou informações relacionadas mencionadas neste documento não devem ser consideradas uma recomendação, solicitação ou convite para comprar, vender, negociar ou realizar qualquer outra transação com criptoativos. Criptoativos são altamente voláteis e podem resultar em perdas. A disponibilidade dos serviços, produtos e eventos relacionados da WEEX pode variar conforme a região. É de sua responsabilidade garantir que sua participação esteja em conformidade com as leis e regulamentações locais aplicáveis.