A RippleX espera a próxima versão do software do servidor principal do XRP Ledger, xrpld 3.3.0, já na próxima semana. O lançamento reintroduziria as emendas Batch e Permission Delegation reescritas no processo de validação, após falhas de autorização levarem operadores a bloquear suas versões anteriores antes da ativação do mainnet.
A implementação permanece na fase de pré-lançamento. xrpld 3.2.1 ainda era a versão estável mais recente em 1º de ago., enquanto as tags oficiais beta e release-candidate para a 3.3.0 estavam públicas. A contagem regressiva da maioria do mainnet ainda não havia começado para nenhuma das emendas de substituição.
O chefe do produto RippleX, Jazzi Cooper, listou cinco funcionalidades propostas para o XRP Ledger 3.3.0: MPT Confidencial, Lote, Delegação de Permissões, Taxas e Reservas Patrocinadas e MPT Dinâmico. Cooper disse que todas as cinco ainda exigem aprovação dos validadores antes da ativação.
Por que os validadores pararam os recursos originais
A alteração original do lote continha uma falha de autorização que poderia ter permitido a um atacante executar transações internas para contas de vítimas arbitrárias sem suas chaves privadas, incluindo pagamentos não autorizados e alterações no livro-razão.
A divulgação oficial afirmou que os pesquisadores encontraram o problema enquanto a emenda ainda estava em votação. Os validadores bloquearam a ativação, e nenhum fundo foi colocado em risco. O CryptoSlate relatou sobre essa intervenção em fevereiro.
A delegação de permissão expôs um caminho diferente para perda. Uma transação assinada offline inválida ainda poderia cobrar uma taxa de transação da conta da vítima antes de falhar na autorização, permitindo envios repetidos para esvaziar XRP por meio de taxas. A divulgação do XRPL afirmou que o recurso nunca foi ativado no mainnet, e os validadores desativaram o suporte para a emenda afetada.
O 3.3 development registry agora marca BatchV1_1 e PermissionDelegationV1_1 como suportados com votos padrão Não. “Suportado” nesse registro significa que o código do servidor compreende as alterações; a aprovação e ativação pelos validadores permanecem como etapas separadas.
As alterações XRPL só podem ser ativadas após a implantação do código compatível e o suporte permanecer acima de 80% dos validadores confiáveis por duas semanas. Se o suporte cair para 80% ou menos antes da ativação, o período reinicia.
Em 1º de ago., o objeto Amendments validado no ledger 105.997.300 não continha o campo Majorities nem nenhuma substituição entre as emendas ativadas. O campo registra emendas pendentes que cruzaram o limiar da maioria, estabelecendo que nenhum cronômetro de duas semanas estava ativo. O objeto do ledger registra apenas cronômetros de maioria ativos, deixando o suporte exato abaixo do limiar não divulgado.
A ativação também imporia um prazo operacional. As regras de emenda do XRPL afirmam que um servidor que não compreenda uma emenda ativada pode tornar-se bloqueado por emenda, perdendo a capacidade de determinar a validade do ledger, processar transações, participar do consenso ou votar. Se qualquer uma das substituições for ativada, os operadores precisarão de software compatível, independentemente de como votaram pessoalmente.
O próximo marco mensurável do XRPL é uma versão estável, seguida por uma supermaioria sustentada de validadores para qualquer emenda. Até lá, as reescritas permanecem como propostas de recursos interrompidos antes da ativação, sem exploração ou perda no mainnet para recuperar.
A postagem Como os validadores do XRPL mataram silenciosamente uma exploração silenciosa que poderia ter esvaziado contas de vítimas apenas por meio de taxas de transação apareceu primeiro no CryptoSlate.