#xrpledgerpatchesxrpcreationbug
Poucas coisas são mais importantes para um ativo de oferta fixa do que a própria oferta. Por isso, uma vulnerabilidade recém-divulgada no XRP Ledger, que poderia ter permitido a criação não autorizada de XRP, chamou a atenção nesta semana, embora a correção esteja disponível há semanas.
Aqui está a sequência, conforme relatado:
• O relato: Em 22 de setembro, os pesquisadores Cayden Liao e Veria AI relataram o problema pelo programa de recompensas por bugs do XRPL. A RippleX reproduziu o problema em um servidor de testes independente e confirmou que o XRP criado poderia ser gasto. • A falha: Um estouro de inteiro no mecanismo de pagamentos. Se um único pagamento consumisse ofertas suficientes do livro de ordens, um cálculo poderia dar a volta e resultar em um número muito menor, fazendo com que os vendedores recebessem o valor integral enquanto o comprador pagava muito menos. A diferença poderia se transformar em XRP recém-criado. A falha parece remontar a 2015. • A correção: A versão xrpld 3.4.1 foi lançada em 25 de setembro, acrescentando verificações de estouro e um contador de segurança mais amplo. Ela foi disponibilizada como uma correção de emergência, sem a votação habitual de emenda dos validadores, para evitar que a falha permanecesse exposta durante um período de votação pública. A RippleX afirma que, até aquele dia, mais de 80% dos validadores da UNL padrão já usavam a versão corrigida ou uma posterior. • A divulgação: Os detalhes foram publicados em 9 de outubro. A RippleX informa que não há evidências de exploração da falha. Um segundo bug, de menor gravidade e que afetava o recurso Batch, também foi corrigido e não estava ativo na mainnet quando foi identificado.
Por que isso importa: Uma falha na emissão de tokens é diferente de uma falha que permite roubo, pois afeta diretamente a integridade da oferta. Para explorá-la, seria necessário preparar cuidadosamente centenas de ofertas e algumas centenas de XRP em reservas, o que pode ajudar a explicar por que ela passou despercebida. O episódio também mostra dois lados do processo: um programa de recompensas por bugs funcionando como deveria e o equilíbrio entre agir rapidamente para aplicar uma correção e o método descentralizado, baseado em votação, pelo qual a rede normalmente muda.
Quando uma correção crítica precisa ser lançada antes que a comunidade possa votar nela, como as redes devem equilibrar rapidez, transparência e consenso?
