#xrpledgerpatchesxrpcreationbug
E se uma falha pudesse ter criado XRP do nada e passado despercebida por cerca de uma década? Essa é a questão por trás da divulgação mais recente da XRPL. 🔍
Em 9 de outubro, a XRP Ledger divulgou uma vulnerabilidade crítica no mecanismo de pagamentos, corrigida semanas antes. Veja a linha do tempo:
22 de setembro: os pesquisadores Cayden Liao e Veria AI relataram uma falha de estouro de inteiro por meio do programa de recompensas por bugs.
25 de setembro: a versão xrpld 3.4.1 foi lançada com verificações contra estouro, como correção emergencial, sem a votação habitual de emenda dos validadores, para evitar que a falha ficasse exposta durante um período de votação pública.
No mesmo dia: segundo relatos, mais de 80% dos validadores padrão já estavam executando a versão corrigida.
Segundo a divulgação, um invasor precisaria de centenas de ofertas com preços cuidadosamente calculados e de um único pagamento para, potencialmente, criar XRP utilizável além do limite de 100 bilhões. A RippleX reproduziu o problema em um servidor independente e afirma não ter encontrado evidências de exploração. Uma segunda falha, de menor gravidade, afetava o recurso Batch, que ainda não havia sido ativado na mainnet.
Por que isso importa: o XRP tem uma oferta fixa, pré-criada, então qualquer criação inesperada abalaria uma premissa fundamental. A resposta rápida e a descoberta por meio do programa de recompensas são sinais tranquilizadores para a segurança da rede, enquanto a decisão de ignorar o processo normal de votação pode levantar questões sobre governança.
Ainda assim, “não há evidências” não é uma prova, e a divulgação ocorreu depois da correção. Quanta transparência as redes devem oferecer — e em que momento — em situações como essa?
$MAGIC $LUMIA $XRP
E se uma falha pudesse ter criado XRP do nada e passado despercebida por cerca de uma década? Essa é a questão por trás da divulgação mais recente da XRPL. 🔍
Em 9 de outubro, a XRP Ledger divulgou uma vulnerabilidade crítica no mecanismo de pagamentos, corrigida semanas antes. Veja a linha do tempo:
22 de setembro: os pesquisadores Cayden Liao e Veria AI relataram uma falha de estouro de inteiro por meio do programa de recompensas por bugs.
25 de setembro: a versão xrpld 3.4.1 foi lançada com verificações contra estouro, como correção emergencial, sem a votação habitual de emenda dos validadores, para evitar que a falha ficasse exposta durante um período de votação pública.
No mesmo dia: segundo relatos, mais de 80% dos validadores padrão já estavam executando a versão corrigida.
Segundo a divulgação, um invasor precisaria de centenas de ofertas com preços cuidadosamente calculados e de um único pagamento para, potencialmente, criar XRP utilizável além do limite de 100 bilhões. A RippleX reproduziu o problema em um servidor independente e afirma não ter encontrado evidências de exploração. Uma segunda falha, de menor gravidade, afetava o recurso Batch, que ainda não havia sido ativado na mainnet.
Por que isso importa: o XRP tem uma oferta fixa, pré-criada, então qualquer criação inesperada abalaria uma premissa fundamental. A resposta rápida e a descoberta por meio do programa de recompensas são sinais tranquilizadores para a segurança da rede, enquanto a decisão de ignorar o processo normal de votação pode levantar questões sobre governança.
Ainda assim, “não há evidências” não é uma prova, e a divulgação ocorreu depois da correção. Quanta transparência as redes devem oferecer — e em que momento — em situações como essa?
$MAGIC $LUMIA $XRP