Os desenvolvedores do XRP Ledger defenderam a correção de segurança emergencial usada para corrigir um bug capaz de criar XRP além da oferta fixa da rede, afirmando que não podiam esperar pela votação habitual dos validadores da rede, que dura duas semanas, sem expor a falha a atacantes.
A correção, lançada em 25 de setembro, chegou três dias após um relatório de um programa de recompensa por bugs e entrou em vigor imediatamente em qualquer servidor que a instalasse. Segundo eles, foi a primeira vez que se contornou deliberadamente o processo normal de alteração desde que o sistema foi introduzido, há mais de dez anos.
“Com uma votação normal de alteração, a correção teria ficado pública por semanas antes de entrar em vigor, colocando em risco a segurança da rede”, disseram os desenvolvedores do XRPL em uma publicação no X no domingo.
A correção emergencial levantou questões sobre o nível de descentralização do XRPL. Em seu site, o XRPL afirma ser uma blockchain pública e totalmente descentralizada — uma caracterização que tem sido central nos argumentos de que seu token nativo, XRP, não é um valor mobiliário.
Correção de segurança do XRPL “levantou muitas questões”
O fundador da Cyber Capital, Justin Bons, afirmou na quinta-feira que promover o XRP a investidores de varejo como descentralizado equivalia a uma “fraude descarada”. Ele argumentou que a versão emergencial lançada em 25 de setembro foi distribuída apenas como binários, teve seu código-fonte temporariamente retido e pressionou os operadores a atualizar.
No entanto, a Fundação XRPL afirmou que a decisão de pular o processo normal de alteração foi tomada em conjunto pela Fundação, pela RippleX, pelos desenvolvedores principais e pelos validadores, após avaliarem a gravidade do bug.
“Nenhuma parte poderia tomar essa decisão sozinha. Cada validador e operador de nó escolhe qual software executar, e a versão 3.4.1 só se tornou obrigatória por meio de uma votação normal de alteração, com o apoio de mais de 80% dos validadores durante duas semanas. As mudanças no protocolo continuam sendo aprovadas por meio de alterações”, afirmou a fundação.
A XRP Kuwait, uma operadora independente de validadores, também rejeitou as alegações de que as atualizações coordenadas indicavam controle centralizado.
“Discordamos da afirmação de que operadores coordenarem uma atualização seja, por si só, prova de controle centralizado”, afirmou. “Coordenação não é o mesmo que controle. Operadores independentes podem avaliar uma situação, comunicar-se entre si e chegar à mesma conclusão sem abrir mão de sua independência.”
Bug poderia ter criado XRP ilimitado
Segundo o relatório de divulgação de vulnerabilidade do projeto, o bug era um estouro de inteiro no mecanismo de pagamentos do XRP Ledger, presente desde 2015.
Os saldos de XRP são armazenados como inteiros de 64 bits, com um limite máximo fixo. Quando uma soma ultrapassava esse limite, o cálculo voltava a um número menor em vez de falhar.
Um invasor poderia explorar isso criando centenas de ofertas com preços especialmente definidos, cada uma solicitando uma quantidade muito grande de XRP, e depois enviando um único pagamento que consumisse todas elas.
O mecanismo creditava a cada proprietário de oferta o valor integral, mas cobrava do comprador apenas o total ínfimo resultante do estouro. A diferença seria XRP recém-criado e disponível para gasto.
Segundo o relatório, o ataque exigia ofertas criadas deliberadamente para esse fim e não podia ser acionado por atividades normais de negociação. Os desenvolvedores afirmaram não ter encontrado evidências de que o problema tivesse sido explorado em nenhuma rede pública.
Revista: ataque ao Ledger se espalha pela UE, IA encontra bug de ‘18 trilhões de XRP’: Hodler’s Digest