Os desenvolvedores do XRP Ledger aposentaram cinco emendas antigas do protocolo na versão xrpld 3.3.0, mas a mudança não elimina suas funcionalidades nem exige qualquer ação específica dos detentores de XRP.
As cinco emendas são Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve e fixUniversalNumber.
O termo “aposentar” pode gerar confusão.
Nesse contexto, ele não significa que as funções foram retiradas da rede.
Significa que o comportamento introduzido por essas emendas se tornou uma parte permanente e incondicional do protocolo XRP Ledger.
A rede está apenas removendo o código antigo que descrevia como ela funcionava antes da ativação dessas regras.
A aposentadoria torna as novas regras permanentes
O sistema de emendas do XRP Ledger permite introduzir mudanças sem impor imediatamente novas regras à Mainnet.
Os validadores votam em cada proposta.
Para ser ativada, uma emenda precisa manter apoio de mais de 80% dos validadores confiáveis durante duas semanas consecutivas.
Depois da ativação, a nova regra passa a ser aplicada pelo protocolo.
Durante algum tempo, porém, o software xrpld mantém parte do comportamento antigo.
Isso permite que desenvolvedores reproduzam condições históricas ao investigar transações anteriores.
Por que o código antigo é mantido por alguns anos
Após a ativação, a implementação anterior ainda pode ser útil para depuração.
Desenvolvedores podem precisar reproduzir exatamente as condições em que determinada transação antiga foi processada.
Por outro lado, manter durante anos várias ramificações obsoletas aumenta a complexidade do código.
A documentação do XRP Ledger permite, por isso, que uma emenda seja aposentada depois de permanecer ativa na Mainnet por pelo menos dois anos.
Nesse estágio, o caminho antigo pode ser removido e a nova regra passa a fazer parte do protocolo de forma incondicional.
Mudança é uma limpeza do código
Mayukha Vadari, engenheira de software da RippleX, descreveu o processo como uma limpeza da base de código.
Segundo sua explicação, os usuários não devem perceber qualquer mudança no funcionamento normal da rede.
O comportamento criado pelas emendas continua ativo.
O que desaparece é apenas a lógica referente ao estado anterior do XRP Ledger.
Essa diferença é especialmente importante no caso da Clawback.
Clawback continua disponível
A aposentadoria da Clawback não significa que a função foi removida.
Ela está ativa na Mainnet desde 8 de fevereiro de 2024.
A funcionalidade permite que determinados emissores recuperem tokens que eles próprios emitiram quando a conta emissora possui a configuração necessária.
Ela não permite recuperar XRP nativo.
Depois da aposentadoria da emenda, essa regra continua funcionando normalmente.
A única mudança é que o software não precisa mais manter a lógica de uma versão da rede em que a Clawback ainda não existia.
As outras quatro emendas seguem o mesmo princípio
fixDisallowIncomingV1 corrigiu uma questão relacionada à autorização de trust lines.
fixInnerObjTemplate solucionou erros envolvendo determinados objetos internos de AMM.
fixNFTokenReserve adicionou verificações de reserva quando ofertas de NFT são aceitas.
fixUniversalNumber unificou partes dos cálculos decimais em ponto flutuante do XRP Ledger.
Em todos os casos, as regras introduzidas continuam ativas.
Somente os caminhos antigos do código estão sendo removidos.
Processo já foi utilizado antes
A versão 3.3.0 não é a primeira a aposentar emendas antigas.
O XRP Ledger já aplicou o mesmo processo em atualizações anteriores.
A versão 3.2.0, por exemplo, aposentou mudanças mais antigas relacionadas a Checks, Deposit Authorization, exclusão de contas e outras funções.
A aposentadoria faz parte, portanto, do ciclo normal de vida de uma emenda depois que ela se torna estável e amplamente estabelecida.
Versão 3.3.0 inicia novo ciclo de emendas
Enquanto cinco emendas antigas deixam o status condicional, a versão xrpld 3.3.0 adiciona seis novas propostas.
Elas são BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor e fixCleanup3_3_0.
A presença dessas funções no software não significa que elas já estejam ativas na Mainnet.
Cada uma ainda precisa passar pelo processo de votação dos validadores.
Novas funções dependem de aprovação
Cada proposta deve conseguir apoio superior a 80% durante duas semanas consecutivas.
Caso o suporte caia abaixo do limite, o período é reiniciado.
Por isso, nenhuma das novas funções deve ser tratada como definitivamente ativa apenas porque seu código está incluído na versão 3.3.0.
A diferença em relação às cinco emendas aposentadas é clara.
As novas ainda aguardam aprovação.
As antigas já passaram pelo processo anos atrás e agora se tornam regras permanentes.
ConfidentialTransfer pode ampliar a privacidade
ConfidentialTransfer é uma das propostas mais relevantes entre as novidades.
Ela poderia permitir transferências de Multi-Purpose Tokens com maior preservação de privacidade.
A função se relaciona aos esforços para ampliar o uso do XRP Ledger em ativos tokenizados e aplicações institucionais.
Ainda assim, sua ativação depende dos validadores.
A inclusão em xrpld 3.3.0 representa apenas a preparação técnica para uma possível aprovação futura.
BatchV1_1 permitiria agrupar transações
BatchV1_1 permitiria que uma conta enviasse até oito transações internas de forma agrupada.
Isso poderia tornar algumas operações mais eficientes quando várias ações precisam ocorrer em conjunto.
Como ocorre com as demais propostas, a função não entra automaticamente na Mainnet.
Ela precisa primeiro atingir o nível necessário de apoio.
Sponsor pode alterar a forma como custos são pagos
A emenda Sponsor permitiria que terceiros cobrissem determinadas taxas e exigências de reserva para outros usuários.
Essa funcionalidade poderia facilitar a experiência de uso em aplicações nas quais empresas ou plataformas assumem parte dos custos técnicos dos clientes.
A proposta, contudo, ainda depende de aprovação.
Seu código estar presente no software não significa que a regra já esteja em funcionamento.
DynamicMPT busca mais flexibilidade
DynamicMPT pretende oferecer mais flexibilidade em determinadas propriedades dos Multi-Purpose Tokens.
Esses ativos fazem parte das ferramentas de tokenização do XRP Ledger.
Uma gestão mais dinâmica de algumas características pode beneficiar aplicações financeiras ou institucionais.
O efeito real, porém, dependerá da aprovação da emenda pelos validadores.
Nenhuma ação é necessária para usuários de XRP
Para os detentores comuns de XRP, a aposentadoria das cinco emendas não exige migração.
Não é necessário mover os ativos.
Nenhuma transação especial precisa ser realizada.
Carteiras também não precisam ser atualizadas especificamente por causa dessas aposentadorias.
Clawback e as demais regras continuam funcionando normalmente.
A mudança ocorre principalmente no código dos servidores.
Operadores de nós devem atualizar o software
Para operadores de servidores, a situação é diferente.
O aviso da versão 3.3.0 recomenda a atualização para xrpld 3.3.0 o quanto antes.
Os servidores precisam manter código compatível com emendas que podem entrar em vigor no futuro.
Caso um nó permaneça em uma versão antiga e uma nova emenda seja ativada, ele pode ficar “amendment blocked”.
Nesse estado, deixa de participar normalmente da rede até ser atualizado.
Precedente recente mostra importância da atualização
A fonte lembra que, em julho, a ativação da fixCleanup3_2_0 deixou nós antigos e incompatíveis bloqueados por emenda.
O episódio demonstra por que operadores precisam acompanhar as novas versões.
A atualização para xrpld 3.3.0 não serve apenas para remover código antigo.
Ela também prepara os servidores para possíveis ativações futuras.
Aposentadoria simplifica o protocolo
Eliminar caminhos antigos oferece várias vantagens para os desenvolvedores.
Uma base de código menor tende a ser mais simples de manter.
Também reduz a quantidade de comportamentos históricos que precisam continuar presentes nas versões atuais.
Isso pode diminuir o risco de erros relacionados a trechos de lógica que já não têm função prática.
O principal compromisso é que algumas reproduções históricas podem exigir versões anteriores do software.
Transações antigas podem exigir versões antigas
A documentação de testes do XRP Ledger alerta que reproduzir com precisão determinadas transações históricas pode exigir a versão do xrpld que originalmente as processou.
Depois que uma emenda é aposentada, versões modernas podem não manter todas as condições anteriores.
Isso não cria problema para transações atuais.
Mas desenvolvedores e pesquisadores interessados em reproduções históricas exatas podem precisar manter acesso a versões antigas.
Próximo foco passa para as seis novas propostas
A atenção agora se desloca para as emendas introduzidas na versão 3.3.0.
Os validadores precisarão decidir quais devem ser ativadas.
ConfidentialTransfer pode receber atenção especial por seu potencial para ativos tokenizados institucionais.
BatchV1_1, Sponsor e DynamicMPT também podem alterar de maneira relevante algumas utilizações da rede.
Seu futuro, porém, depende integralmente do processo de governança do XRP Ledger.
Conclusão
O XRP Ledger 3.3.0 aposenta cinco emendas antigas sem remover suas funcionalidades.
Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve e fixUniversalNumber continuam integradas ao funcionamento da rede.
A aposentadoria significa apenas que seus comportamentos agora são permanentes e que o código anterior às emendas pode ser removido.
Para os detentores de XRP, nenhuma ação é necessária.
Operadores de nós, por outro lado, devem manter o software atualizado para permanecer compatíveis com futuras mudanças.
Ponto-chave final
A aposentadoria das cinco emendas em xrpld 3.3.0 é uma simplificação técnica, não uma redução de funcionalidades. As regras continuam ativas e passam a integrar permanentemente o protocolo, enquanto o foco da rede se desloca para seis novas emendas que ainda dependem da aprovação dos validadores.