XRPL v3.2.0 supera limite da UNL, mas adoção é lenta
A prontidão dos validadores já está acima da barra de ativação de 80%, enquanto fixCleanup3_2_0 continua sendo um catalisador separado e mais lento.
O lançamento do servidor v3.2.0 do XRP Ledger alcançou aproximadamente 89% de adoção entre os validadores UNL padrão, ultrapassando o limite necessário para ativação se mantido por duas semanas consecutivas. A base de nós mais ampla ainda está inclinada para v3.1.3, e uma emenda separada focada em segurança ligada ao lançamento está com índices de votação bem abaixo da taxa de atualização do software.
Principais Conclusões
- O software do servidor XRPL v3.2.0 foi lançado em 15 de junho com os objetivos declarados de custos operacionais mais baixos, maior estabilidade e maior apelo institucional.
- O snapshot do XRPSCAN mostrou cerca de 833 nós XRPL ativos, com aproximadamente 43% na v3.2.0 em comparação com cerca de 51% ainda executando a v3.1.3.
- Os validadores UNL padrão estão mais avançados do que a base de nós: 31 dos 35 validadores estavam na v3.2.0, cerca de 89%.
- A emenda fixCleanup3_2_0 no livro-razão, que agrupa correções de segurança e melhorias para novos recursos do XRPL, permaneceu sob votação e foi descrita como tendo índices de votação muito abaixo do lançamento do software.
V3.2.0 ultrapassa a barreira UNL padrão, aguardando a janela de duas semanas
O software do servidor v3.2.0 do XRPL foi lançado em 15 de junho com uma proposta operacional: mais barato para operar, mais estável e mais atraente para uso institucional. Em 8 de julho, a atualização já havia cruzado o limite chave da camada de validadores na lista única de nós padrão.
Os mecanismos de ativação do XRPL são binários e limitados pelo tempo. "Para uma nova versão de software ou emenda ser ativada, precisa de apoio sustentado de mais de 80% dos validadores nessa lista por duas semanas consecutivas." Na UNL padrão de 35 validadores, 31 estavam executando a v3.2.0, cerca de 89%, que está acima do requisito de >80%. A questão em aberto é a duração, uma vez que a condição de duas semanas não está confirmada como atendida.
Para os traders, essa divisão importa porque enquadra o lançamento como mais próximo da conclusão na camada de consenso do que a distribuição mais ampla da rede implica.
FixCleanup3_2_0: A Emenda de Segurança em uma Trilha Separada e Mais Lenta
O risco material maior está na segunda via. Juntamente com o lançamento do software, o XRPL possui uma emenda on-ledger, fixCleanup3_2_0, ainda sob votação formal em 8 de julho.
A emenda agrupa correções de segurança e melhorias relacionadas a novos recursos do XRPL, incluindo único-ativocofres, com permissãotrocas descentralizadastokens multiuso (MPTs) e o protocolo de empréstimo. Também adiciona verificações internas destinadas a impedir que contas deletadas deixem dados residuais.
Crucialmente, a emenda não está avançando em sincronia com a atualização do software. Foi descrita como tendo uma taxa de adesão muito inferior à da v3.2.0, reforçando que “atualizar um validador e votar a emenda são dois passos distintos.” A Ripple votou a favor do fixCleanup3_2_0.
Operacionalmente, a emenda introduz uma penalidade severa para os atrasados. “Validadores que não atualizarem antes da ativação da emenda correm o risco de serem desconectados do livro-razão em um estado que o livro-razão chama de estado bloqueado por emenda.” Isso transforma a defasagem de versão de uma divisão cosmética em um potencial evento de conectividade se a votação eventualmente for aprovada.
Sinais que Podem Acelerar—ou Estender—o Cronograma de Atualização
O primeiro temporizador é o suporte à persistência do validador. O limite que importa é se o suporte padrão do UNL para v3.2.0 permanece acima de 80% durante as duas semanas necessárias, pois essa é a condição de ativação.
O segundo temporizador é a limpeza da distribuição. A mistura de nós do XRPSCAN ainda está inclinada para v3.1.3, então os traders estarão observando se a participação do v3.2.0 aumenta em direção a, e depois ultrapassa, a participação de aproximadamente 51% da versão mais antiga à medida que os operadores se atualizam.
O terceiro temporizador é a emenda em si. A contagem exata de votos do fixCleanup3_2_0 não foi especificada, apenas que está bem abaixo da adoção do software, então qualquer porcentagem publicada ou aceleração visível na votação se torna o próximo catalisador concreto.
Comunicações de operadores que mencionam explicitamente evitar um estado bloqueado por emenda também seriam um sinal de que a urgência da atualização está mudando de opcional para obrigatória.
Divisão de Adoção: Validadores Atualizados, a Base de Nós Mais Ampla Não Atualizou
O XRPSCAN mostrou cerca de 833 nós ativos no momento da captura, com aproximadamente 43% em v3.2.0 e cerca de 51% ainda em v3.1.3. Isso parece uma implementação lenta se o único critério for a contagem bruta de nós.
Mas a camada de validadores está contando uma história diferente. No UNL padrão, 31 de 35 validadores já estavam em v3.2.0, cerca de 89%. Na estrutura de mercado do XRPL, essa é a métrica mais acionável porque governa se as atualizações e emendas podem realmente se transformar em um estado ativo.
É por isso que os traders tendem a pesar a prontidão do UNL em relação à ampla distribuição de nós. Uma rede pode parecer "atrasada" pela contagem de nós enquanto ainda está próxima de uma transição de camada de consenso, e essas transições são onde o risco operacional e a narrativavolatilidadetendem a se concentrar.
O Risco de Ativação em Duas Trilhas É o Verdadeiro Sinal de Negociação Aqui
Eu trato isso como dois catalisadores separados que podem ocorrer em relógios diferentes. A versão 3.2.0 já está acima do limite padrão da UNL, então o verdadeiro teste é se esse suporte permanece fixo durante toda a janela de duas semanas, porque é isso que transforma "implementado" em "ativado."
A maior incerteza é o fixCleanup3_2_0. Se essa emenda eventualmente alcançar a ativação enquanto a votação ainda está atrasada, a configuração começa a parecer estrutural em vez de impulsionada por narrativas, porque o risco bloqueado pela emenda força operadores tardios a agir.
Isso parece mais um catalisador de sentimento do que uma mudança fundamental até que a votação da emenda se estreite e a longa cauda de nós da rede feche a lacuna de versão de uma maneira que reduza o risco de tempo de inatividade inesperado.
