O limite de emissão dos livros-razão das quatro redes é garantido, em cada uma, por uma camada diferente. O total de XRP fica fixado em 100 bilhões, protegido por um invariante que impede a criação de moedas do nada; o limite de 21 milhões de bitcoins está codificado na fórmula de halving da camada de consenso, com cortes a cada quatro anos determinados pelo protocolo; o Ethereum não tem um limite fixo, e sua taxa anual de emissão é ajustada pela governança da comunidade; a taxa de inflação da Solana também é um parâmetro sujeito a votação, que cai gradualmente em direção a 1,5%. O que distingue as quatro redes é o que garante o limite e quem percebe primeiro quando algo dá errado.
Desta vez, o que falhou foi justamente aquele invariante do XRP. Ao somar as ordens no mecanismo de pagamentos da plataforma integrada, foi usado um contador de 64 bits; o «XRPNotCreated», adicionado em 2017, também dependia desse mesmo contador de 64 bits. Quando o contador transbordou, tanto a soma anterior quanto o invariante seguinte falharam. Em 25 de setembro, a RippleX lançou o patch emergencial xrpld 3.4.1, contornando a «votação de duas semanas por 80% dos validadores» — algo inédito desde a implementação desse mecanismo.
Segui esse invariante para trás e vi que ele compartilhava um contador de 64 bits com a lógica responsável por somar as ordens. O patch apenas ampliou a largura de 64 para 128 bits; não separou os dois em contadores distintos. O transbordamento foi bloqueado, mas o contador que garante o limite e a soma usada pela operação continuam acoplados. Se o problema voltar de outra forma, talvez não termine em silêncio como desta vez.
Na verdade, o custo da falha não foi alto. Reproduzi-la exigiu apenas algumas centenas de XRP, e não há registros públicos de criação de moedas. Há ainda um segundo ponto nesta rodada: o processamento em lote fixBatchV1_2 foi ativado em 9 de outubro. O patch emergencial contornou a votação habitual e separou a resposta de segurança da governança descentralizada: a equipe decide o que precisa ser rápido; a votação dos validadores fica para o que pode esperar.
A falha desta vez ocorreu na camada que serve de salvaguarda, não no limite em si — o limite apenas diz que não se pode ultrapassá-lo, mas o contador que o garante e a soma operacional compartilham o mesmo lugar. O que falhou nunca foi um número isolado, mas aquele contador. Se, no futuro, outro livro-razão com um contador independente apresentar um transbordamento semelhante, ou se a oferta de XRP se desviar do limite de 100 bilhões, terei de rever completamente esta avaliação; enquanto nada mudar nesses dois pontos, vou mantê-la como está. Essa contagem pode ser acompanhada na série diária do XRP; no Binance, fica clara em qual seção — os valores diários da linha do mercado à vista estão todos disponíveis, e é possível conferi-los voltando pelas datas do reparo. Este texto registra uma opinião e não constitui recomendação de investimento.$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞
Desta vez, o que falhou foi justamente aquele invariante do XRP. Ao somar as ordens no mecanismo de pagamentos da plataforma integrada, foi usado um contador de 64 bits; o «XRPNotCreated», adicionado em 2017, também dependia desse mesmo contador de 64 bits. Quando o contador transbordou, tanto a soma anterior quanto o invariante seguinte falharam. Em 25 de setembro, a RippleX lançou o patch emergencial xrpld 3.4.1, contornando a «votação de duas semanas por 80% dos validadores» — algo inédito desde a implementação desse mecanismo.
Segui esse invariante para trás e vi que ele compartilhava um contador de 64 bits com a lógica responsável por somar as ordens. O patch apenas ampliou a largura de 64 para 128 bits; não separou os dois em contadores distintos. O transbordamento foi bloqueado, mas o contador que garante o limite e a soma usada pela operação continuam acoplados. Se o problema voltar de outra forma, talvez não termine em silêncio como desta vez.
Na verdade, o custo da falha não foi alto. Reproduzi-la exigiu apenas algumas centenas de XRP, e não há registros públicos de criação de moedas. Há ainda um segundo ponto nesta rodada: o processamento em lote fixBatchV1_2 foi ativado em 9 de outubro. O patch emergencial contornou a votação habitual e separou a resposta de segurança da governança descentralizada: a equipe decide o que precisa ser rápido; a votação dos validadores fica para o que pode esperar.
A falha desta vez ocorreu na camada que serve de salvaguarda, não no limite em si — o limite apenas diz que não se pode ultrapassá-lo, mas o contador que o garante e a soma operacional compartilham o mesmo lugar. O que falhou nunca foi um número isolado, mas aquele contador. Se, no futuro, outro livro-razão com um contador independente apresentar um transbordamento semelhante, ou se a oferta de XRP se desviar do limite de 100 bilhões, terei de rever completamente esta avaliação; enquanto nada mudar nesses dois pontos, vou mantê-la como está. Essa contagem pode ser acompanhada na série diária do XRP; no Binance, fica clara em qual seção — os valores diários da linha do mercado à vista estão todos disponíveis, e é possível conferi-los voltando pelas datas do reparo. Este texto registra uma opinião e não constitui recomendação de investimento.$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞