Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
XRPL se recupera da lentidão da rede, pois a atualização crítica de segurança enfrenta um atraso de duas semanas
O XRP Ledger (XRPL) se recuperou de atrasos intermitentes no processamento de transações, embora os desenvolvedores ainda estejam preparando uma correção permanente de software.
Em 22 de outubro, operações de razão XRP confirmado que os tempos de fechamento do razão voltaram ao normal após uma alteração de configuração recomendada às operadoras de rede.
A interrupção coincidiu com um revés separado para uma alteração do protocolo projetada para corrigir vulnerabilidades que afetam permissões de tokens, empréstimos e outras aplicações financeiras. Sua ativação foi adiada para novembro depois que o suporte do validador enfraqueceu brevemente.
Os desenvolvimentos surgem como XRPL expande seu papel em pagamentos institucionaisstablecoins e ativos tokenizados, aumentando a importância de uma infraestrutura de liquidação confiável e de salvaguardas que regem as transações financeiras.
A desaceleração do XRP Ledger expõe desafios de processamento de transações
O problema operacional surgiu em 21 de outubro, quando alguns livros começaram a demorar mais do que o normal para fechar, interrompendo o ritmo típico de liquidação de três a cinco segundos do blockchain.
Operações XRPL disse a maioria dos livros-razão continuou fechando normalmente, mas atrasos intermitentes levaram os desenvolvedores a investigar o comportamento da rede e a preparar uma correção de software.
Como os atrasos persistiram, a equipe distribuiu uma recomendação xrpld alteração de configuração para hub, validador e operadores de nó.
O ajuste restaurou os horários normais de fechamento até 22 de outubro, de acordo com a equipe de operações, embora os desenvolvedores continuassem testando um lançamento pontual destinado a resolver a causa subjacente.
David Schwartzum dos Arquitetos originais do XRPL e Ondulação ex-diretor de tecnologia, ofereceu informações adicionais sobre o que pode ter contribuído para o incidente.
Ele disse que seu próprio hub continuou operando normalmente após um incidente anterior que ele acreditava não estar relacionado, mas o reiniciou com a alteração de configuração recomendada.
Schwartz disse:
“Suponho que o problema estava relacionado aos servidores que se esforçavam demais para colocar muitas transações em cada livro-razão.”
Questionado se isso sugeria que o XRPL havia encontrado um limite prático em sua capacidade de processamento de transações, Schwartz reconheceu uma conexão entre o volume de transações e a frequência de fechamento.
Ele acrescentou:
“Sim e não. Não podemos fechar um livro-razão com mais frequência do que a cada 4 segundos. Portanto, limitar o número de transações por livro-razão não impõe necessariamente um limite de TPS.”
As suas observações apontam para um potencial compromisso entre processar mais transações em cada livro razão e manter tempos de liquidação consistentes.
No entanto, os desenvolvedores não estabeleceram se o incidente refletiu uma restrição mais ampla de capacidade da rede ou um comportamento de software que pode ser corrigido sem afetar o rendimento.
A distinção tem implicações comerciais, uma vez que XRPL atrai aplicativos que exigem liquidação previsível, incluindo Transferências de stablecoin RLUSDtítulos tokenizados e serviços de pagamento institucional.
Outras perturbações poderão complicar o processamento de transações para serviços que dependem da rápida movimentação de fundos ou garantias.
A próxima versão do software será, portanto, importante para determinar se a mudança na configuração fornece uma solução duradoura ou se ajustes adicionais são necessários para manter o desempenho sob cargas de transações mais pesadas.
Revés na votação do validador atrasa salvaguardas financeiras
Separadamente, XRPLs fixCleanup3_4_0 alteração encontrou um revés de governação que prolongará a ativação de várias correções na sua infraestrutura financeira.
A alteração, introduzida em Setembro versão xrpld 3.4.0aborda questões técnicas envolvendo permissões de tokens, criadores de mercado automatizados, cofres de ativos, operações de empréstimo e transações de garantia.
Entre as mudanças está uma correção para uma falha de delegação de permissão que poderia permitir que uma conta autorizada a destruir certos tokens fungíveis criasse tokens adicionais em circunstâncias específicas.
O documentação da rede aconselha os emitentes a não delegarem os PaymentBurn permissão até que a correção se torne ativa.
Outras mudanças melhoram a precisão na contabilidade do cofre, impõem salvaguardas de saldo de tokens e corrigem o comportamento de tratamento de transações em funções descentralizadas de negociação e empréstimo.
As proteções propostas estavam caminhando para uma ativação em 23 de outubro antes que o apoio do validador caísse brevemente abaixo da maioria absoluta necessária para alterar as regras do protocolo XRPL.
O XRPL exige que o suporte de mais de 80% dos validadores confiáveis permaneça ininterrupto por 14 dias antes que uma alteração possa ser ativada.
A perda temporária de apoio em 21 de outubro apagou o período acumulado de aprovação da alteração, apesar de o apoio ter posteriormente recuperado acima do limite exigido.
O Rastreador de alteração XRPLWin agora coloca a primeira ativação em 4 de novembro, desde que a maioria renovada permaneça intacta.
Veterinário contribuidor XRPL confirmado que votos adicionais de validadores restauraram a contagem regressiva de ativação da alteração. Ele também esclareceu que fixCleanup3_4_0 aborda problemas de protocolo mais antigos e não está relacionado aos últimos atrasos no fechamento do razão.
O adiamento estende o período antes que as salvaguardas de permissão de token afetadas se tornem aplicáveis. Também atrasa correções destinadas a melhorar a contabilidade e o tratamento de transações na infraestrutura de empréstimos em desenvolvimento do XRPL.
Essa infraestrutura ainda precisa de aprovações de protocolo adicionais antes que os serviços de empréstimo nativos possam entrar em operação.
Um declínio adicional no apoio ao validador redefiniria novamente o período de espera da alteração, potencialmente empurrando a ativação para além de 4 de novembro.
