Os validadores do XRP Ledger colocaram a emenda BatchV1_1 corrigida num percurso condicional para ativação às 14:06:41 UTC de 29 de setembro. Trinta de 35 validadores de confiança apoiaram a emenda, acima do limiar de 28 votos, com a maioria a surgir pela primeira vez on-ledger a 15 de setembro. Sob as regras do XRPL, o apoio deve manter-se acima de 80% durante duas semanas, pelo que a data permanece condicional. A emenda substitui uma versão anterior retirada depois de investigadores terem descoberto uma falha crítica de autorização em fevereiro, antes de alguma vez chegar à mainnet.
Porque é que isso importa
O episódio validou a firewall de emendas do XRPL. A emenda Batch original ainda estava na sua fase de votação quando os investigadores divulgaram um bug de signer-loop que devolvia sucesso cedo, em vez de verificar os signatários restantes. Caso tivesse entrado em produção, uma entrada forjada poderia ter executado a transação de uma vítima sem as suas chaves, embora a divulgação da XRPL Labs confirme que nenhum fundo esteve alguma vez em risco.
O BatchV1_1 substitui esse percurso por um esquema de autorização reescrito ao abrigo da especificação XLS-56. Cada assinatura BatchSigner agora vincula a conta externa, o seu número de sequência ou ticket, o modo de batch, os hashes ordenados de todas as transações internas e quaisquer signatários aninhados, fechando tanto o bug divulgado como vetores adjacentes de replay.
Impacto no mercado
A correção ao nível do protocolo desloca o risco para a implementação. Um Batch externo pode devolver tesSUCCESS mesmo quando as transações internas falham, pelo que os clientes devem inspecionar cada código de resultado interno. O suporte ao BatchV1_1 chegou no xrpld 3.3.0 a 6 de agosto, e os servidores que não atualizarem ficam amendment-blocked assim que a emenda for ativada. O xrpl.js 5.0.0 construiu assinaturas com o payload antigo e é rejeitado com temBAD_SIGNATURE, chegando o suporte compatível na versão 5.1.0.
A ativação prova a disponibilidade do protocolo, não a adoção nem a procura por XRP. Os sinais a observar depois são se os nós desatualizados ficam bloqueados, se as falhas de assinatura se concentram em versões antigas de clientes e se as wallets e explorers apresentam batches multi-conta de forma compreensível.
Perguntas frequentes
-
Quando será ativada a emenda BatchV1_1 do XRPL?
Condicionalmente às 14:06:41 UTC de 29 de setembro, desde que o apoio dos validadores se mantenha acima de 80% durante o período obrigatório de duas semanas. Trinta de 35 validadores de confiança apoiam atualmente a emenda, acima do limiar de 28 votos.
-
Qual era a falha na emenda Batch original do XRPL?
Um bug de signer-loop devolvia sucesso cedo ao encontrar um signatário de uma conta recém-criada, pelo que uma entrada forjada que alegasse autorizar uma conta vítima poderia ter sido executada sem as chaves da vítima. Nenhum fundo esteve em risco.
-
Porque pode um Batch do XRPL mostrar sucesso enquanto as transações internas falham?
Um Batch externo pode devolver tesSUCCESS mesmo quando uma ou mais transações internas falham, e fora do modo ALLORNOTHING a execução parcial é intencional. Os clientes devem inspecionar os metadados e o código de resultado de cada transação interna.
-
Quais versões de software suportam o BatchV1_1?
O xrpld 3.3.0 incluiu o suporte ao BatchV1_1 a 6 de agosto, e o xrpl.js 5.1.0 adicionou o formato de assinatura revisto. A versão 5.0.0 produz assinaturas que os nós BatchV1_1 rejeitam com temBAD_SIGNATURE, e servidores desatualizados arriscam ficar amendment-blocked.
-
A ativação do BatchV1_1 significa maior procura por XRP?
Não por si só. A votação e os lançamentos de software estabelecem apenas a disponibilidade do protocolo. Sinais úteis surgirão após a ativação, como nós bloqueados, falhas de assinatura em clientes antigos e a forma como as wallets e explorers apresentam os batches.