Reorg (reorganização da chain)

O que é um reorg em cripto?

Um reorg, abreviação de Chain Reorganization, ocorre quando um nó de blockchain substitui parte do histórico atual da chain por outra ramificação válida.Em termos simples, a blockchain seguiu temporariamente um caminho e depois mudou para outro que a rede aceitou como a chain melhor ou canônica.Um reorg pode remover um ou mais blocos adicionados recentemente à chain ativa e substituí-los por blocos diferentes.As transações nos blocos removidos podem voltar ao mempool, aparecer novamente como pendentes, ser incluídas em um bloco posterior ou se tornar inválidas caso transações conflitantes sejam confirmadas na nova chain.Os reorgs são mais discutidos em redes Proof of Work, redes Proof of Stake, sistemas Layer 2, bridges, carteiras, processadores de pagamento e plataformas de negociação que precisam decidir quando é seguro considerar uma transação final.

A documentação da Ethereum sobre ataques e defesa em Proof of Stake define um reorg como uma reorganização dos blocos em uma nova ordem, possivelmente com blocos adicionados ou removidos da chain canônica.

A documentação para desenvolvedores do Bitcoin explica que as confirmações medem quantos blocos precisariam ser modificados para remover ou alterar uma transação. Essa é a razão prática pela qual os usuários esperam antes de considerar pagamentos finais.Um reorg não é automaticamente um ataque, mas pode se tornar perigoso quando reverte transações importantes, permite gastos duplos, interrompe aplicativos ou afeta sistemas cross-chain.

Definição simples de reorg

Um reorg ocorre quando uma blockchain altera quais blocos recentes considera parte da chain principal.Os blocos recentes antigos se tornam obsoletos, órfãos ou não canônicos, dependendo da terminologia usada pela rede.Os novos blocos passam a ser o histórico aceito que nós, carteiras, exploradores e aplicativos devem seguir.Isso pode acontecer porque diferentes validadores ou mineradores criaram brevemente blocos concorrentes na mesma altura.Também pode ocorrer porque a latência da rede fez alguns nós receberem um bloco primeiro e outros receberem outro bloco primeiro.Em casos mais graves, um reorg pode acontecer porque um invasor ou um grande grupo de validadores tenta substituir blocos para obter lucro ou censurar transações.Para os usuários, o principal efeito é que uma transação que parecia confirmada pode se tornar não confirmada ou ser substituída.É por isso que os sistemas cripto usam confirmações, regras de finalização e períodos de espera baseados em risco.

Por que os reorgs são importantes

Os reorgs são importantes porque as blockchains são usadas para determinar propriedade e liquidação.Se um pagamento, swap, depósito em uma bridge, mint, saque ou liquidação for aceito cedo demais, um reorg posterior poderá causar perdas ou confusão.Um comerciante que envia produtos após uma única confirmação pouco robusta pode correr riscos se o pagamento desaparecer em um reorg.Uma bridge que libera ativos antes da finalização da transação na chain de origem pode criar ativos duplicados ou sem lastro se a transação de origem for removida.Um protocolo DeFi que reage a um bloco antes de haver finalização suficiente pode processar um estado obsoleto.Uma carteira que mostra uma transação como concluída cedo demais pode induzir o usuário ao erro.

A documentação da Circle sobre finalização e confirmações de bloco explica que atestações mais rápidas podem envolver risco de reorganização, enquanto os fluxos padrão aguardam a finalização definitiva, quando é improvável que as transações sejam revertidas por um reorg.

Por isso, estar atento a reorgs é essencial para a segurança em blockchain, especialmente em transferências de alto valor e aplicativos cross-chain.

Como ocorre um reorg

Um reorg começa quando existem simultaneamente duas ou mais ramificações válidas da chain.Isso pode acontecer naturalmente porque blockchains são sistemas distribuídos e os nós não recebem novos blocos exatamente no mesmo momento.Um grupo de nós pode receber o Bloco A primeiro.Outro grupo de nós pode receber o Bloco B primeiro.Ambos os blocos podem ser válidos, mas somente uma ramificação pode se tornar o caminho canônico.As regras de consenso da rede determinam qual ramificação vence.Quando um nó descobre que outra ramificação válida se tornou mais forte de acordo com a regra de escolha de fork da rede, ele muda para essa ramificação.Essa mudança é a reorganização da chain.

Reorg versus fork

Um fork é uma divisão do histórico da blockchain em que existe mais de uma ramificação válida.Um reorg é o processo de mudar de uma ramificação para outra.Nem todo fork se transforma em um reorg significativo.Muitos forks curtos são resolvidos rapidamente quando a rede escolhe uma ramificação e abandona a outra.Um hard fork é diferente porque altera as regras do protocolo e pode criar uma divisão permanente da chain se as comunidades continuarem apoiando os dois lados.Um reorg normal geralmente é temporário e ocorre sob as mesmas regras de consenso.Uma divisão permanente cria duas redes em funcionamento contínuo.Um reorg é a correção do caminho da chain ativa dentro do processo de consenso de uma rede.

Reorg versus finalização

Finalização é o ponto em que uma transação é considerada extremamente difícil ou impossível de reverter segundo as regras da rede.Um reorg é o que a finalização tenta impedir ou tornar economicamente inviável.

A documentação da Ethereum sobre Proof of Stake afirma que uma transação é finalizada quando faz parte de um bloco que não pode ser alterado sem que uma grande quantidade de ETH seja queimada.

A mesma documentação explica que reverter um bloco finalizado da Ethereum exigiria que um invasor perdesse pelo menos um terço do total de ETH em staking.O Bitcoin usa finalização probabilística, pois cada bloco adicional torna mais difícil substituir o histórico anterior.A Solana usa níveis de comprometimento como processed, confirmed e finalized para ajudar os clientes a entender o grau de certeza de uma transação.A lição prática é que uma transação pode ser incluída em um bloco antes de ter finalização robusta.Os aplicativos devem decidir o nível de finalização necessário com base no valor, na velocidade e no risco.

Reorg versus bloco órfão

Um bloco órfão ou obsoleto é um bloco que era válido, mas não permaneceu na chain canônica.Um reorg pode criar blocos obsoletos porque a ramificação antiga deixa de ser a chain ativa.As comunidades de diferentes blockchains usam esses termos de maneiras ligeiramente distintas.Na linguagem cotidiana de cripto, os usuários costumam dizer que um bloco ficou órfão quando foi substituído por uma ramificação concorrente.O importante é que as transações nesse bloco talvez precisem ser processadas novamente ou desapareçam do histórico confirmado.As carteiras e os exploradores de blockchain podem atualizar o status da transação após detectar um reorg.Os desenvolvedores não devem tratar um bloco como permanente simplesmente porque ele foi visto uma vez.Devem acompanhar as confirmações e o status de finalização antes de realizar ações irreversíveis off-chain.

Reorg versus gasto duplo

Um gasto duplo é uma tentativa de gastar os mesmos fundos de duas maneiras conflitantes.Um reorg pode permitir um gasto duplo se uma transação que paga a uma parte for removida e uma transação conflitante que paga a outra parte for confirmada na nova chain.

A documentação de processamento de pagamentos do Bitcoin explica que um gastador malicioso pode criar uma transação que paga ao destinatário e outra que gasta a mesma entrada de volta para si. Somente uma das duas pode entrar na blockchain.

A mesma documentação explica que, quando uma transação está em um bloco, substituí-la exige modificar o histórico da blockchain, o que se torna mais difícil à medida que aumentam as confirmações.Um reorg nem sempre envolve um gasto duplo, mas um ataque de gasto duplo geralmente precisa de um reorg para ter êxito depois que a primeira transação foi confirmada.Por isso, pagamentos de alto valor normalmente exigem mais confirmações do que pagamentos pequenos.Quanto mais profundamente a transação estiver sob blocos posteriores, mais caro será substituí-la.Assim, a política de confirmações é uma defesa contra gastos duplos baseados em reorg.

Causas comuns de reorgs

A primeira causa comum é a latência da rede.Quando um bloco válido demora para chegar a todos os nós, outro produtor de blocos pode criar um bloco concorrente antes de saber da existência do primeiro.A segunda causa é a produção simultânea de blocos.Dois mineradores ou validadores podem criar blocos válidos quase ao mesmo tempo.A terceira causa é o comportamento de validadores ou mineradores.Um produtor de blocos pode reter, atrasar ou publicar blocos estrategicamente de maneiras que aumentem o risco de reorg.A quarta causa são bugs de software ou dos clientes.Se diferentes clientes interpretarem o estado incorretamente, podem discordar temporariamente sobre qual é a chain correta.A quinta causa é um ataque malicioso.Um invasor pode tentar reorganizar blocos para realizar gastos duplos, censurar transações ou extrair valor.

Reorgs curtos

Um reorg curto geralmente substitui um ou poucos blocos recentes.Reorgs curtos são mais comuns do que reorgs profundos porque há menos segurança por trás dos blocos recentes.Eles podem ocorrer naturalmente em condições normais de rede.Para muitos usuários, um reorg de um bloco pode apenas fazer o status da transação mudar de confirmado para pendente e, depois, voltar a confirmado.Mesmo um reorg curto pode ser importante para aplicativos de alta velocidade.Um aplicativo de negociação, bridge, oráculo, bot de liquidação ou processador de pagamentos pode reagir a blocos muito recentes.Se esses blocos forem substituídos, o aplicativo talvez precise reverter ou corrigir seu estado interno.Por isso, a infraestrutura deve ser projetada para lidar com reorgs, em vez de presumir que eles nunca acontecerão.

Reorgs profundos

Um reorg profundo substitui muitos blocos.Reorgs profundos são muito mais graves porque podem remover transações que os usuários já consideravam confiáveis.Eles podem indicar um grande problema de rede, ataque, bug de consenso, falha de validadores ou partição extrema da rede.Em sistemas Proof of Work, os reorgs profundos ficam mais caros à medida que mais Proof of Work é acumulado sobre a transação original.Em sistemas Proof of Stake com finalização econômica, reorgs profundos que afetam blocos finalizados podem exigir comportamentos passíveis de slashing e envolver custos econômicos muito altos.

O roteiro de finalização em slot único da Ethereum explica que o atraso atual na finalização cria oportunidades para reorgs curtos e que uma finalização mais rápida poderia reduzir esse risco.

Reorgs profundos são raros em redes maduras, mas são importantes porque seu impacto pode ser grave.Qualquer sistema que processe grandes valores deve estar preparado para cenários raros, mas de alto impacto, envolvendo reorgs.

Reorgs em redes Proof of Work

Em redes Proof of Work, os nós geralmente seguem a chain válida com mais trabalho acumulado.Se surgirem duas ramificações válidas, os mineradores continuarão construindo sobre a que considerarem melhor.A ramificação que acumular mais trabalho se torna canônica.Os nós que seguiam a ramificação perdedora se reorganizam para seguir a vencedora.

A documentação dos modos de operação do Bitcoin explica que os nós completos verificam a blockchain baixando e validando blocos e que enganar um nó completo exige uma história alternativa da blockchain com dificuldade maior do que a da chain verdadeira atual.

Por isso, as confirmações são fundamentais para a liquidação em Proof of Work.Cada novo bloco adiciona mais trabalho que um invasor precisa superar.O risco de reorg diminui conforme aumenta a profundidade dos blocos.

Reorgs em redes Proof of Stake

Nas redes Proof of Stake, o comportamento dos reorgs depende dos votos dos validadores, das regras de escolha de fork, dos mecanismos de finalização, das penalidades e das condições de slashing.A Ethereum usa uma regra de escolha de fork chamada LMD-GHOST e um sistema de finalização baseado em votos de checkpoint.A documentação da Ethereum explica que os validadores atestam o bloco que consideram estar na ponta da chain e que os clientes de consenso favorecem o fork com o maior peso de atestações.Isso significa que pode haver divergências de curta duração antes da finalização.Depois de alcançada a finalização, reverter blocos finalizados se torna economicamente caro, pois os invasores podem perder o stake.Por isso, a análise de reorgs em Proof of Stake se concentra no peso das atestações, no status de finalização, na participação dos validadores, na latência da rede e no risco de slashing.Um reorg em Proof of Stake não é avaliado apenas pela quantidade de blocos.Também é preciso considerar se os blocos substituídos estavam finalizados, justificados, confirmados ou apenas propostos recentemente.

Reorgs e confirmações

Uma confirmação significa que uma transação foi incluída em um bloco e que blocos adicionais podem ter sido construídos sobre ele.Em muitas redes, uma confirmação significa que a transação está no bloco aceito mais recente.Duas confirmações significam que mais um bloco foi construído sobre esse bloco.Mais confirmações geralmente significam menor risco de reorg.A documentação para desenvolvedores do Bitcoin informa que seis confirmações são comumente usadas para transações de alto valor, mas também observa que esse número é um tanto arbitrário e baseado em risco.Para pagamentos pequenos, menos confirmações podem ser aceitáveis.Para depósitos grandes, bridges ou entregas off-chain irreversíveis, podem ser necessárias mais confirmações.A política de confirmações adequada depende da segurança da rede, do valor da transação, dos incentivos para ataques e da tolerância do usuário ao risco.

Reorgs e blocos finalizados

Um bloco finalizado é aquele que a rede considera extremamente difícil de remover.A finalização é mais forte do que a simples inclusão em um bloco.Na Ethereum, finalização significa que reverter um bloco exigiria penalidades econômicas severas para os invasores.

Na Solana, a documentação sobre status de comprometimento descreve o status finalized como aquele que exige 31 ou mais blocos confirmados construídos sobre o bloco-alvo.

Em sistemas de bridge e pagamento, a finalização pode ser definida pelas regras da chain de origem e pela política de risco do aplicativo.Uma transação finalizada costuma ser muito mais segura do que uma transação apenas processada ou incluída recentemente.No entanto, os modelos de finalização variam entre as blockchains.Os desenvolvedores não devem usar a mesma regra de espera para todas as redes sem compreender o design de consenso de cada uma.

Reorgs e carteiras

As carteiras devem ser projetadas para lidar com reorgs sem problemas.Primeiro, uma carteira pode mostrar uma transação como pendente.Depois, pode exibir uma ou mais confirmações.Se um reorg remover o bloco que contém a transação, a carteira deverá atualizar o status em vez de fingir que nada mudou.A transação pode voltar a ficar pendente se continuar válida e estiver aguardando nova inclusão.Pode falhar se uma transação conflitante for confirmada na nova chain.As carteiras devem evitar marcar transações de alto valor como finais cedo demais.Rótulos claros de status ajudam os usuários a entender a diferença entre enviada, incluída, confirmada e finalizada.

Reorgs e exploradores de blockchain

Os exploradores de blockchain acompanham a chain canônica atual e exibem o status das transações aos usuários.Quando ocorre um reorg, um explorador pode remover blocos da visualização da chain principal e exibir os blocos substitutos.Dependendo da rede e do design do explorador, a página de uma transação pode mudar de confirmada para descartada, pendente, falha ou substituída.Exploradores diferentes podem exibir diferenças temporárias durante reorgs rápidos porque recebem dados da rede em momentos distintos.Os usuários devem evitar depender de um único explorador para verificar confirmações críticas durante condições anormais da rede.Os desenvolvedores devem usar uma infraestrutura confiável de nós e indexação que considere a finalização, em vez de extrair dados de páginas de exploradores para definir a liquidação.Os indexadores devem armazenar histórico suficiente para reverter o estado afetado após um reorg.Um explorador é uma ferramenta útil de visualização, mas a chain canônica do nó e suas regras de finalização são a fonte de verdade.

Reorgs e exchanges

Plataformas de negociação e serviços de custódia geralmente aguardam o número exigido de confirmações antes de creditar depósitos.O objetivo é reduzir a possibilidade de um depósito desaparecer em um reorg depois que a plataforma creditar o usuário.As equipes de risco podem exigir mais confirmações em redes com menor poder de hash, segurança de stake mais baixa, instabilidade recente ou maiores incentivos para ataques.Podem exigir menos confirmações em redes com finalização determinística mais rápida.Também podem pausar depósitos e saques durante atividades anormais de reorg.Às vezes, os usuários pensam que os períodos de espera para depósitos são apenas atrasos, mas eles também servem como controles de risco.Se uma plataforma creditar um depósito cedo demais e um reorg o remover, a plataforma poderá sofrer uma perda.Por isso, as políticas de confirmação fazem parte da gestão de risco operacional.

Reorgs e bridges

As bridges são especialmente sensíveis a reorgs porque conectam duas ou mais redes.Uma bridge pode bloquear ou queimar um ativo em uma rede e liberar ou emitir um ativo relacionado em outra.Se a transação na chain de origem for removida por um reorg após a ação na chain de destino, a bridge poderá ter liberado valor sem um evento de origem válido.Isso pode criar ativos com garantia insuficiente ou incompatibilidades contábeis.Os sistemas de bridge reduzem esse risco aguardando confirmações ou finalização, usando provas de fraude ou de validade, acompanhando mensagens processadas e definindo limites de risco.As orientações de finalização da Circle mostram que sistemas de transferência cross-chain podem usar tempos de espera diferentes para transferências rápidas e padrão, pois os fluxos mais rápidos envolvem premissas diferentes sobre reorgs.Os usuários devem entender que uma bridge mais rápida pode trocar velocidade por maior risco de reorg ou de finalização.Para transferências grandes, aguardar uma finalização mais robusta geralmente é mais seguro.

Reorgs e redes Layer 2

As redes Layer 2 geralmente dependem de uma camada de liquidação para disponibilidade de dados, finalização, provas de fraude, provas de validade ou segurança de saques.Uma transação Layer 2 pode parecer final na interface da Layer 2 antes de o lote correspondente ser finalizado na camada de liquidação.A documentação de finalização da Circle observa que alguns sistemas Layer 2 dependem do momento em que os lotes são publicados na Ethereum e de quando o bloco correspondente da Ethereum é finalizado.Isso cria duas camadas de finalização que precisam ser compreendidas.Pode haver uma confirmação local na Layer 2 e finalização na camada de liquidação.Para pequenas transações comuns, a confirmação local pode ser suficiente.Para transferências cross-chain, depósitos grandes e contabilização de protocolos, pode ser necessária a finalização na camada de liquidação.Os usuários não devem presumir que todas as confirmações Layer 2 envolvem o mesmo risco de reorg.

Reorgs e MEV

MEV, ou valor máximo extraível, é o valor que produtores de blocos ou agentes responsáveis pela ordenação de transações podem capturar ao incluir, excluir ou reordenar transações.Os reorgs podem estar ligados ao MEV quando a substituição de blocos permite que um agente capture oportunidades lucrativas de ordenação de transações.A documentação da Ethereum sobre ataques e defesa afirma que reorgs maliciosos podem permitir a extração de valor por meio de transações de front-running e back-running.Os incentivos para reorgs curtos são uma preocupação importante, pois um agente pode tentar substituir um bloco se isso permitir capturar valor suficiente.A finalização reduz esse risco ao tornar mais cara a substituição de blocos mais antigos.Os aplicativos podem reduzir a exposição aguardando a finalização, usando canais privados de transação quando apropriado, projetando mecanismos de leilão mais seguros e monitorando comportamentos anormais da chain.O risco de reorg relacionado ao MEV é mais importante para negociações DeFi de alto valor, liquidações, arbitragem, atualizações de oráculos e eventos de bridge.Os usuários devem entender que o risco de reorg não é apenas um acidente técnico: ele também pode ser motivado por razões econômicas.

Reorgs e oráculos

Os oráculos levam dados off-chain ou cross-chain para contratos inteligentes.Se um oráculo ler dados de um bloco que depois for removido por um reorg, esses dados poderão deixar de corresponder ao histórico canônico da chain.Por exemplo, um oráculo pode informar um preço, saldo, depósito ou evento que existia somente em um bloco removido.Bons sistemas de oráculos consideram a profundidade das confirmações e a finalização antes de publicar dados sensíveis.Os protocolos devem evitar depender de eventos muito recentes se um reorg puder causar perdas graves.Para oráculos cross-chain, o risco de reorg na chain de origem pode afetar contratos na chain de destino.Os oráculos devem deixar claras as premissas de finalização no design.Os contratos inteligentes que usam oráculos devem entender se os dados são imediatos, confirmados ou finalizados.

Reorgs e indexadores

Os indexadores leem dados da blockchain e os transformam em bancos de dados pesquisáveis para aplicativos, painéis, carteiras, ferramentas de análise e APIs.Os reorgs representam um grande desafio para os indexadores porque os dados indexados talvez precisem ser revertidos.Se um indexador registrar eventos de um bloco que depois se torne obsoleto, deverá remover ou corrigir esses eventos.Se não lidarem com reorgs, os indexadores poderão exibir saldos, históricos de transações, propriedade de NFTs, dados de liquidação ou status de bridge incorretos.Os indexadores devem acompanhar hashes de bloco, hashes de blocos anteriores, números de bloco, status de finalização e profundidade de reversão.Devem evitar tratar novos blocos como permanentes imediatamente.Para aplicativos de alto valor, os indexadores devem disponibilizar APIs que considerem a finalização.Um indexador preparado para reorgs é uma infraestrutura essencial para aplicativos cripto sérios.

Reorgs e contratos inteligentes

Os contratos inteligentes são executados de acordo com o estado da chain canônica.Se um reorg remover um bloco que contém uma chamada de contrato inteligente, essa chamada deixa de fazer parte do histórico canônico.A transação poderá ser incluída novamente mais tarde, mas poderá ser executada de outra maneira se o estado tiver mudado na chain substituta.Isso é importante em DeFi porque o estado pode mudar rapidamente.Um swap, liquidação, atualização de oráculo, mint ou resgate pode depender do estado exato no momento da execução.Os desenvolvedores não devem criar sistemas off-chain que presumam que o resultado de uma transação é final antes de haver confirmações suficientes.Os próprios contratos inteligentes não “lembram” do histórico de blocos removidos, a menos que esse histórico faça parte da chain canônica.Os serviços off-chain associados a contratos inteligentes precisam considerar reorgs.

Reorgs e processamento de pagamentos

Os processadores de pagamentos precisam decidir quando um pagamento cripto é seguro o bastante para ser aceito.Aceitar pagamentos sem confirmações é rápido, mas arriscado.Aceitar pagamentos com uma confirmação reduz o risco, mas não o elimina.Aguardar mais confirmações reduz o risco de reorg e de gasto duplo, mas aumenta o tempo de espera do usuário.A política adequada depende do valor do pagamento e do custo de uma fraude.Uma pequena compra digital pode aceitar mais risco do que o envio de um produto físico de alto valor.Uma liquidação de alto valor geralmente deve aguardar uma confirmação ou finalização mais robusta.Os sistemas de pagamento devem deixar visível para usuários e comerciantes a política de confirmações.

Reorgs e status de transações

Uma transação pode passar por vários estados durante um reorg.Pode ser transmitida, mas não confirmada.Pode ser incluída em um bloco.Pode receber confirmações.Pode ser removida da chain canônica durante um reorg.Pode voltar a ficar pendente se ainda for válida.Pode ser confirmada novamente em um bloco substituto.Pode ser substituída definitivamente se uma transação conflitante for confirmada em seu lugar.

Reorgs e taxas de gas

O comportamento das taxas de gas durante um reorg depende do design da blockchain e do status canônico final da transação.Se uma transação for incluída em um bloco obsoleto, mas não na chain canônica final, os usuários geralmente querem saber se ela foi executada na chain aceita.Se a transação for executada posteriormente em um bloco canônico, o usuário pagará de acordo com as regras dessa chain.Se a transação não for executada no histórico canônico, será como se essa execução não tivesse sido liquidada na chain final.No entanto, as interfaces de carteiras e exploradores podem exibir temporariamente informações confusas sobre taxas durante reorgs.Os desenvolvedores devem acompanhar recibos canônicos em vez de observações temporárias de blocos.Os usuários devem aguardar confirmações antes de considerar definitivos o valor da taxa e o status de execução.Em períodos de estresse da rede, reorgs e volatilidade das taxas podem tornar inconsistente o acompanhamento de transações.

Reorgs e gestão de risco

A gestão do risco de reorg começa pela profundidade das confirmações.Quanto maior o valor da transação, mais finalização o destinatário deve exigir.A segunda ferramenta é uma política específica para cada rede.As diferentes chains têm tempos de bloco, sistemas de finalização, conjuntos de validadores e custos de ataque diferentes.A terceira ferramenta é o monitoramento.Os serviços devem detectar profundidade incomum de reorg, slots perdidos, interrupções de validadores, instabilidade na escolha de fork e divergências entre exploradores.A quarta ferramenta é a liquidação adiada.As empresas devem evitar ações off-chain irreversíveis até que a transação on-chain esteja suficientemente segura.

Reorgs e ataques de 51%

Um ataque de 51% ocorre quando um invasor controla poder de mineração ou influência de stake suficiente para afetar o histórico canônico da chain.Em sistemas Proof of Work, um invasor com poder de hash suficiente pode tentar criar uma chain alternativa e publicá-la para substituir blocos recentes.Em sistemas Proof of Stake, um invasor pode tentar influenciar a escolha de fork, atrasar a finalização ou realizar ataques mais graves que podem resultar em penalidades.A documentação da Ethereum observa que invasores em Proof of Stake podem visar reorgs, finalização dupla ou atraso na finalização.Um ataque de reorg pode ser usado para realizar gastos duplos ou censurar transações.O custo e a viabilidade dependem do modelo de segurança da rede.Em geral, é mais difícil atacar redes maduras do que redes pequenas com segurança de mineração ou staking mais fraca.Os usuários devem exigir mais cautela com confirmações em redes de baixa segurança.

Reorgs e partições de rede

Uma partição de rede ocorre quando uma parte da rede não consegue se comunicar normalmente com outra.Durante uma partição, diferentes grupos de nós podem construir ramificações distintas da chain.Quando a comunicação melhora, a rede pode escolher uma ramificação como canônica e reorganizar-se, abandonando a outra.Partições de rede podem ser causadas por falhas de roteamento da internet, problemas nos clientes, ataques de negação de serviço ou interrupções de infraestrutura.A profundidade do reorg pode depender da duração da partição e da forma como as regras de consenso lidam com ramificações concorrentes.Os aplicativos devem monitorar a integridade da rede, não apenas o status de transações individuais.Uma chain pode parecer normal em um nó enquanto outra parte da rede tem uma visão diferente.O uso de vários nós confiáveis pode ajudar a detectar visões inconsistentes da chain.

Reorgs e bugs nos clientes

Bugs nos clientes podem causar interrupções semelhantes a reorgs quando os nós discordam sobre a validade dos blocos.Se um cliente aceitar um bloco que outro rejeita, a rede poderá se dividir até que o problema seja resolvido.Por isso, diversidade de clientes, testes, auditorias e coordenação de atualizações são importantes.Uma divisão de chain causada por um bug pode ser mais perigosa do que um reorg normal de um bloco porque pode afetar o próprio consenso.Os aplicativos devem acompanhar comunicados oficiais dos clientes durante comportamentos anormais.Os operadores de nós devem manter o software atualizado, mas também entender as instruções de atualização antes de grandes lançamentos.A diversidade de clientes pode reduzir a possibilidade de um único bug de software prejudicar toda a rede.Portanto, o risco de reorg está relacionado à qualidade do software, não apenas ao comportamento de mineradores ou validadores.

Reorgs e reversões

Reversão é um termo mais amplo para retornar o estado a um ponto anterior.Um reorg é uma reversão específica de blockchain, causada pela mudança para outra ramificação da chain.Os aplicativos podem precisar reverter seus estados internos após um reorg.Por exemplo, um sistema contábil pode precisar remover o crédito de um depósito se a transação correspondente tiver sido removida por um reorg.Um jogo pode precisar remover a emissão de um item se a transação de mint desaparecer.Uma bridge pode precisar esperar mais tempo, em vez de reverter a operação após liberar ativos na chain de destino.Projetar aplicativos preparados para reorgs geralmente significa decidir quando uma reversão é aceitável e quando é mais seguro esperar.Sistemas que não podem tolerar reversões devem esperar por uma finalização robusta antes de agir.

Reorgs e segurança do usuário

Os usuários podem reduzir o risco de reorg aguardando confirmações antes de considerar uma transação final.Em pagamentos de alto valor, devem evitar enviar produtos, liberar serviços ou tomar decisões irreversíveis após uma confirmação muito recente.Devem entender que diferentes chains têm diferentes práticas de confirmação.Devem ter cuidado redobrado durante forks, interrupções, ataques, eventos de bridge e condições anormais da rede.Devem usar carteiras e serviços que exibam claramente o status das confirmações.Não devem entrar em pânico se uma transação confirmada recentemente voltar a ficar pendente após um reorg curto.Em muitos casos, a transação poderá ser incluída novamente.Se uma transação entrar em conflito ou desaparecer, os usuários devem consultar um explorador confiável, a página de suporte da carteira ou o próprio nó, quando possível.

Segurança contra reorgs para desenvolvedores

Os desenvolvedores devem presumir que reorgs podem acontecer.Não devem processar eventos importantes após ver apenas um bloco recém-criado, a menos que o caso de uso possa tolerar uma reversão.Devem armazenar hashes de blocos e de blocos anteriores, não apenas números de bloco.Devem conseguir detectar quando um bloco processado anteriormente deixa de ser canônico.Devem implementar lógica de reversão para eventos indexados.Devem definir limites de confirmações por chain e por nível de valor.Devem distinguir finalização de inclusão.Devem testar seus sistemas em redes de desenvolvimento onde os reorgs possam ser simulados.

Benefícios de entender os reorgs

O primeiro benefício é aceitar pagamentos com mais segurança.O segundo é projetar bridges melhores.O terceiro é exibir o status das carteiras com mais precisão.O quarto é aumentar a confiabilidade de indexadores e aplicativos.O quinto é melhorar a gestão de risco de depósitos e saques de negociação.O sexto é compreender melhor as confirmações e a finalização.O sétimo é se proteger melhor contra tentativas de gasto duplo.Entender reorgs ajuda os usuários a perceber que a liquidação em blockchain é um processo, não um único instante.

Limitações da proteção contra reorgs

As confirmações reduzem o risco de reorg, mas não eliminam todos os ataques possíveis.A finalização reduz ainda mais esse risco, mas os modelos de finalização variam entre as redes.Uma rede pequena ainda pode enfrentar risco de reorg profundo se sua segurança for fraca.Uma bridge ainda pode falhar se interpretar incorretamente a finalização da chain de origem.Uma carteira ainda pode induzir os usuários ao erro se exibir os status de forma inadequada.Um contrato inteligente ainda pode apresentar outros bugs, mesmo que a própria chain esteja estável.A proteção contra reorgs é uma camada de segurança, não um sistema completo de segurança.Usuários e desenvolvedores devem combiná-la com segurança de custódia, revisão de contratos inteligentes, segurança de oráculos e controles operacionais.

Equívocos comuns sobre reorgs

Um equívoco comum é acreditar que uma transação é final assim que aparece em um bloco.Na realidade, transações incluídas recentemente ainda podem ser afetadas por reorgs curtos.Outro equívoco é achar que todos os reorgs são ataques.Muitos reorgs curtos podem ocorrer naturalmente devido à latência da rede e a blocos válidos concorrentes.Outro equívoco é pensar que todas as chains precisam do mesmo número de confirmações.Os requisitos de confirmação dependem do modelo de segurança da chain, das regras de finalização, do valor transferido e da tolerância ao risco.Outro equívoco é acreditar que finalização significa a mesma coisa em todas as redes.As diferentes redes usam modelos de finalização diferentes, por isso os usuários precisam verificar as regras da chain específica.

Sinais de alerta de reorg

Um sinal de alerta é um serviço que credita depósitos grandes sem uma política de confirmação.Outro é uma bridge que libera ativos antes de a finalização da chain de origem estar clara.Outro é uma carteira que marca uma transação como final imediatamente após a transmissão.Outro é um indexador que armazena apenas números de bloco, sem hashes.Outro é um processador de pagamentos incapaz de lidar com transações que voltam a ficar não confirmadas.Outro é a atividade repetida e incomum de reorg em uma rede que normalmente tem finalização estável.Outro é uma pequena chain Proof of Work com baixo poder de hash que aceita depósitos de alto valor após poucas confirmações.Outro é um dApp que reage a blocos muito recentes sem explicar suas premissas de finalização.

Boas práticas para usuários

Aguarde mais confirmações ao receber pagamentos de alto valor.Use serviços que mostrem claramente os status pendente, confirmado e finalizado.Tenha cautela durante forks, interrupções ou atividades anormais da rede.Não entregue produtos valiosos nem serviços com base apenas em uma transação sem confirmações.Entenda que cada rede usa modelos diferentes de finalização e confirmação.Use carteiras e exploradores confiáveis para acompanhar transações.Em transferências cross-chain, escolha opções com finalização mais lenta quando a segurança for mais importante do que a velocidade.Não presuma que uma transação é irreversível até que alcance o padrão de confirmação ou finalização adequado para aquela chain.

Boas práticas para desenvolvedores

Acompanhe hashes de blocos, hashes dos blocos anteriores, números de bloco, hashes de transações e status de finalização.Projete indexadores e bancos de dados com suporte a reversões.Use limites de confirmação específicos para cada chain.Aguarde uma finalização mais robusta antes de acionar ações irreversíveis off-chain.Exiba claramente o status de confirmação na interface do usuário.Use vários nós ou provedores confiáveis para detectar visões inconsistentes da chain.Teste o comportamento do aplicativo em condições de reorg simuladas.Documente as premissas de finalização para usuários, auditores e parceiros de integração.

Por que reorg é importante para AEO e intenção de busca

As pessoas pesquisam reorg porque querem saber por que o status de uma transação cripto confirmada às vezes pode mudar.A resposta direta é que um reorg ocorre quando a rede substitui blocos recentes por outra ramificação válida da chain.As pessoas também pesquisam reorg para saber se perderam seus fundos.Na prática, uma transação afetada por um reorg pode voltar a ficar pendente, ser incluída posteriormente ou ser substituída por uma transação conflitante, dependendo da situação.As pessoas também podem pesquisar reorg para saber quantas confirmações são suficientes.A resposta útil é que a quantidade necessária depende da blockchain, do valor da transação, do modelo de finalização e da tolerância ao risco.Para usuários de cripto, a principal lição é simples.Um reorg é uma possibilidade normal em um consenso descentralizado, e sistemas seguros aguardam confirmações ou finalização suficientes antes de considerar as transações irreversíveis.

FAQ

O que é um reorg?

Um reorg é uma reorganização da chain em que um nó de blockchain substitui parte da chain aceita atual por outra ramificação válida.

O que significa Chain Reorganization?

Chain Reorganization significa que o histórico canônico recente da blockchain muda porque outra ramificação passa a ser a chain aceita.

Um reorg pode remover minha transação?

Sim. Um reorg pode remover uma transação de um bloco aceito recentemente, embora ela possa ser incluída novamente mais tarde se continuar válida.

Um reorg é sempre um ataque?

Não. Reorgs curtos podem ocorrer naturalmente por causa da latência da rede ou da produção simultânea de blocos, mas também podem ocorrer reorgs maliciosos.

O que é um reorg de um bloco?

Um reorg de um bloco acontece quando a rede substitui o bloco canônico mais recente por outro bloco válido.

O que é um reorg profundo?

Um reorg profundo substitui muitos blocos e é mais grave porque pode afetar transações que os usuários já consideravam confiáveis.

Por que as confirmações reduzem o risco de reorg?

Cada confirmação adiciona outro bloco sobre a transação, tornando mais difícil ou caro substituir o bloco da transação.

Quantas confirmações são suficientes?

A resposta depende da chain, do valor da transação, do modelo de finalização e da tolerância ao risco.

Blocos finalizados podem ser reorganizados?

Em redes com finalização econômica ou determinística, a reorganização de blocos finalizados é projetada para ser extremamente cara ou praticamente impossível sob premissas normais.

Como os reorgs afetam as bridges?

Uma bridge pode perder lastro ou liberar ativos incorretamente se agir com base em uma transação da chain de origem que depois for removida por um reorg.

Como os reorgs afetam as carteiras?

Se o bloco que contém uma transação for removido por um reorg, a carteira poderá alterar seu status de confirmado para pendente ou descartado.

Como os desenvolvedores lidam com reorgs?

Os desenvolvedores lidam com reorgs acompanhando hashes de bloco, aguardando confirmações, oferecendo suporte a reversões e usando regras de finalização específicas para cada chain.

Qual é o maior erro relacionado a reorgs?

O maior erro é tratar uma transação recém-incluída como irreversível antes que ela alcance o nível adequado de confirmação ou finalização.

Conclusão

Um reorg, ou Chain Reorganization, é um evento de blockchain em que blocos aceitos recentemente são substituídos por outra ramificação válida da chain.Os reorgs podem ocorrer naturalmente porque as redes descentralizadas precisam de tempo para chegar a um consenso sobre novos blocos.Também podem ocorrer devido a ataques, comportamento de validadores, partições de rede, bugs de software ou incentivos econômicos como o MEV.Na prática, uma transação que parecia confirmada pode voltar a ficar pendente, ser removida ou substituída.Por isso, as confirmações e a finalização são fundamentais para a liquidação em cripto.Sistemas no estilo Bitcoin dependem muito do aumento da profundidade das confirmações, enquanto sistemas Proof of Stake no estilo Ethereum combinam escolha de fork com finalização econômica.Carteiras, bridges, processadores de pagamento, indexadores, exchanges e protocolos DeFi precisam ser projetados para lidar com reorgs.A conclusão prática é simples: reorgs fazem parte do consenso descentralizado, por isso usuários e desenvolvedores devem aguardar confirmações ou finalização suficientes antes de considerar irreversíveis as transações cripto.