Reorgs e confirmações: quantos blocos são seguros?
Todo backend que credita um depósito precisa responder uma pergunta: quando uma transação está final o suficiente para se agir sobre ela? Trate um bloco como final cedo demais e um reorg pode apagar um depósito que você já creditou. Espere demais e você frustra os usuários. A resposta certa é por chain.
Por que reorgs acontecem afinal
Quando dois blocos válidos são produzidos em quase a mesma altura, a rede discorda temporariamente sobre a ponta. Um ramo vence à medida que mais blocos se constroem sobre ele, e as transações no ramo perdedor voltam para o mempool. Isso é comportamento normal de consenso, não um ataque. Reorgs curtos de um a dois blocos acontecem rotineiramente na maioria das chains.
Modelos de finalidade diferem
Chains proof-of-work como Bitcoin têm finalidade probabilística: confirmações mais profundas significam chances exponencialmente menores de reversão, nunca exatamente zero. O Ethereum pós-Merge adiciona finalidade econômica via checkpoints a cada aproximadamente dois epochs (~13 minutes), após os quais a reversão exige slashing de um terço do stake. L2s herdam sua própria superfície de reorg do sequencer mais a camada de liquidação. Um único limiar não serve para todos.
Limiares práticos
Configurações comuns em produção: Bitcoin 3–6 confirmações dependendo do valor, Ethereum 12–32 blocos (ou espere pela tag finalized), chains EVM de alta vazão proporcionalmente mais blocos porque os tempos de bloco são mais curtos. Para qualquer coisa de alto valor, baseie-se na tag finalized/justified em vez de uma contagem crua de blocos, para que você herde a própria garantia de finalidade da chain.
Detectando um reorg no seu backend
Rastreie o hash do bloco contra o qual você creditou, não só a altura. A cada nova head, volte e confirme que os hashes de pai ainda batem com o que você registrou; uma divergência significa um reorg que você precisa tratar revertendo créditos provisórios. Assinar novas heads e reconciliar hashes é mais barato que depurar um crédito duplicado depois do fato.
Perguntas frequentes
Posso só esperar mais para ficar completamente seguro?
Esperar mais reduz o risco mas nunca chega a zero em chains probabilísticas, e prejudica a UX. Usar a tag de finalidade de uma chain onde ela existe é uma alavanca melhor do que simplesmente aumentar uma contagem de blocos.
L2s sofrem reorg?
Sim. Um sequencer centralizado pode reordenar ou descartar transações não confirmadas, e a L2 também depende da sua camada de liquidação. Trate a finalidade de L2 como uma função tanto do sequencer quanto da liquidação em L1.
Relacionados
Recarregue, pegue a chave e publique.
Autoatendimento. Pague em cripto ou cartão. Medido por créditos: primitivas pesadas custam mais, as simples são baratas.
Obter chave de API