---
title: "O que é um reorg?"
description: "O que é, como acontece e o que vem a seguir"
---
## **O que é um reorg?**
Uma reorganização de chain, ou “reorg,” acontece quando os validadores discordam sobre a versão mais precisa da blockchain. Reorgs ocorrem quando múltiplos blocos são produzidos ao mesmo tempo, quando há um bug, ou devido a um ataque malicioso. Reorgs eliminam a blockchain duplicada mais fraca. Quanto mais tempo um reorg dura, mais caro fica lidar com ele.
Reorgs de blockchain resultam na remoção de um bloco da blockchain, já que uma chain mais longa foi criada. Isso resulta ainda em diferentes mineradores trabalhando simultaneamente na adição de blocos de transações com dificuldade semelhante à chain.
Isso acontece porque o minerador que adiciona o próximo bloco precisa decidir qual lado do fork é a chain correta, ou canônica. Uma vez que os mineradores ou validadores tenham escolhido o fork ou a chain canônica, a outra chain se perde.
Um ataque de reorganização se refere a nodes recebendo blocos de uma nova chain enquanto a chain antiga continua existindo. Nesse caso, a chain seria dividida e criaria um fork, ou uma versão duplicada da blockchain.
### **O que causa um reorg de blockchain?**
Um reorg de blockchain é causado quando dois blocos são publicados ao mesmo tempo. Reorgs curtos, de um ou dois blocos, acontecem com frequência por conta da latência da rede, mas quando os reorgs se estendem por mais de um ou dois blocos, podem indicar ataques maliciosos ou até falha da rede.
### **Quais são as consequências das reorganizações de chain?**
Há quatro consequências principais das reorganizações de chain: atrasos e pior experiência do usuário, custos de node, incerteza e vulnerabilidade a ataques.
#### **1. Atrasos e pior experiência do usuário**
Junto com o aumento dos custos de node, reorgs aumentam a chance de transações atrasadas. Isso é um problema significativo para exchanges, pois elas dependem de transações confirmadas dentro do prazo, ou podem sofrer as consequências de esperar mais tempo por um depósito.
#### 2. Custos de node
Reorgs podem aumentar o número de nodes dentro de uma blockchain ao longo do tempo, causando uma pior experiência do usuário. Ao fazer a transição para um novo fork, as atualizações de estado envolvem mais custos de memória e disco.
#### **3. Incerteza**
Quando reorgs são recorrentes, os usuários têm menos garantias de que as transações serão executadas dentro do prazo. Sem contexto suficiente, transações DeFi teriam resultados bem piores e também levariam a extração de MEV prejudicial.
#### **4. Vulnerabilidade a ataques**
Quando o reorging se torna mais comum, os atacantes só precisam superar uma parte dos mineradores honestos (devido à “regra da chain mais longa”), em vez de todos eles. Um número maior de reorgs facilita muito o papel do atacante.
## **O que é a chain canônica?**
A chain canônica é a “chain principal” acordada. Portanto, ela não é considerada uma das sidechains que terminam.
Em teoria, a rede nunca tem 100% de certeza sobre qual chain é a canônica. Isso porque ainda seria possível reverter o bloco número 1 continuando suas side-chains com poder de hash suficiente.
## **O que é um fork?**
Um fork ocorre sempre que uma comunidade faz uma mudança no protocolo ou no conjunto básico de regras da blockchain e, efetivamente, divide (ou “forka”) a chain em uma nova chain que seguirá as novas regras, e uma antiga que se torna majoritariamente obsoleta.
Como blockchains como Bitcoin e Ethereum são movidas por software descentralizado e de código aberto, mantido por membros da comunidade com interesses na rede, os participantes da rede podem propor e votar em mudanças no software.
### **O que é a fork choice rule?**
Uma fork choice rule é uma função que recebe como entrada o conjunto de blocos e outras mensagens que foram vistas, e retorna ao client qual é a “chain canônica.”
Forks ocorrem quando múltiplos blocos publicados referenciam o mesmo estado anterior. Uma blockchain pode enfrentar esse evento por acidente, se dois blocos forem publicados em momentos aproximadamente iguais, ou pode acontecer de propósito, como se um agente malicioso estivesse tentando criar um fork para “remover” um pagamento da chain.
Em ambos os casos, é necessário algum mecanismo que permita aos usuários determinar qual fork é o correto, ou “canônico.” Isso é chamado de “fork choice rule.”
Fork choice rules são necessárias porque pode haver múltiplas chains válidas para escolher. Isso é possível quando há dois blocos concorrentes com as mesmas chains-pai sendo publicados ao mesmo tempo.
Por exemplo, “a chain válida mais longa vence” seria uma fork choice simples alinhada com o mecanismo de Proof-of-Work. Podemos definir uma fork choice rule que permite que uma blockchain sirva como mecanismo de proposta para um algoritmo de consenso. Elas teriam propriedades como as descritas por [Vitalik Buterin](https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c).
Aqui estão três fork choice rules exibidas abaixo neste quadro:
1. Nakamoto
1. GASPER
1. Tendermint
Nakamoto (eg. PoW Ethereum / Bitcoin)", tooltip: "", icon: "" },
"2": { title: "None
", tooltip: "", icon: "" },
"3": { title: "Frequent
", tooltip: "", icon: "" },
"4": { title: "Longest chain
", tooltip: "", icon: "" },
id: 0,
},
{
"1": { title: "GASPER (eg. PoS ethereum)
", tooltip: "", icon: "" },
"2": { title: "Every 2-epochs (~12 min)
", tooltip: "", icon: "" },
"3": { title: "Very occasional
", tooltip: "", icon: "" },
"4": { title: "Chain with strongest support after last finalized block
", tooltip: "", icon: "" },
id: 1,
},
{
"1": { title: "Tendermint
", tooltip: "", icon: "" },
"2": { title: "Single block (~1-10s)
", tooltip: "", icon: "" },
"3": { title: "Never
", tooltip: "", icon: "" },
"4": { title: "Only finalized blocks
", tooltip: "", icon: "" },
id: 2,
},
],
}}
/>
### **O que é finality?**
Finality é a garantia total de que uma transação em cripto não poderá ser alterada, revertida ou cancelada de forma alguma após sua conclusão. A finality depende da latência da própria blockchain. Ela é frequentemente usada para medir o tempo necessário de espera até a garantia de que uma transação será executada.
## **O que acontece com um reorg na Ethereum?**
A Ethereum atualmente usa um mecanismo de consenso Proof-of-Work. A Ethereum usa uma fork choice rule chamada “regra da chain mais longa,” o que significa que, quando um client vê duas blockchains, ele escolhe a que tem maior dificuldade. Isso é feito comparando a soma da dificuldade de todos os blocos na própria chain.
A [Ethereum Beacon Chain](https://www.alchemy.com/overviews/the-ethereum-merge) recentemente passou por um reorg que poderia levar a riscos de segurança potenciais. [The Beacon](https://www.alchemy.com/dapps/the-beacon) Chain introduz o staking nativo, que é o componente principal do modelo de consenso Proof-of-Stake que a Ethereum adotou. O reorg dentro da Ethereum durou sete blocos, um dos reorgs mais longos em anos.
**Martin Köppelmann**, CEO e cofundador da Gnosis, foi uma das pessoas a tuitar sobre o que havia observado nesse reorg de sete blocos.
Um reorg de sete blocos significa que ocorreu um fork e descartou sete blocos contendo centenas de transações. Isso gerou o risco de um usuário gastar os mesmos ativos duas vezes. Um reorg de 2-3 blocos pode ser apenas um sinal de azar, já que blockchains costumam enfrentar latência de rede. Esse poderia ser o caso também para a Beacon Chain.
Dado que reorgs de cinco blocos ou mais são um sinal potencial de ataque malicioso, o reorg recente da Ethereum pareceu ter sido um evento de baixa probabilidade que não foi malicioso, segundo os desenvolvedores.
[Vitalik Buterin](https://twitter.com/VitalikButerin/status/1529479408309768192?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1529479408309768192%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fdecrypt.co%2F101390%2Fethereum-beacon-chain-blockchain-reorg) disse, em uma resposta rápida, que isso poderia ser devido a versões desatualizadas de software de mineração. Preston Van Loon, um core developer da Ethereum, disse que o reorg da blockchain Beacon foi causado pela implementação da decisão de fork Proposer Boost, que ainda não havia sido totalmente implantada na rede.
O [proposer boosting](https://github.com/ethereum/consensus-specs/pull/2730) foi introduzido para dar mais peso a blocos propostos que são recebidos dentro do prazo. O proposer boosting foi introduzido para resolver o problema dos reorgs ex-ante.
Basicamente, os validadores que tinham o proposer boosting habilitado fizeram com que a chain inferior se tornasse a chain canônica, mas os validadores que não tinham o proposer boosting escolheram, em vez disso, a chain superior, mais curta. Isso faz com que cada chain continue acumulando votos de seus respectivos validadores.
Além disso, essa reorganização é uma segmentação não trivial entre versões atualizadas e desatualizadas de software client. O reorg em si não foi um sinal de uma fork choice ruim.
Os validadores na Ethereum Beacon Chain ficaram fora de sincronia depois que uma atualização de client elevou clients específicos. Durante o processo, os validadores na rede blockchain ficaram confusos e não atualizaram seus clients, causando o fork que resultou no reorg de sete blocos.
O problema não teria ocorrido se todos os validadores estivessem rodando a mesma configuração.
## **O que acontece com os reorgs depois do merge?**
A dificuldade de reorging continuará aumentando lentamente ao longo do tempo. No entanto, à medida que a Ethereum Beacon Chain implementa o Proof-of-Stake, ela introduzirá a fork choice rule chamada [Gasper](https://arxiv.org/abs/2003.03052).
A fork choice rule Gasper tornaria o ataque à blockchain da Ethereum extremamente difícil, já que votos e attestations de attesters são introduzidos, dando “peso” a um bloco.
Controlar os attesters significa controlar a fork choice rule. Isso torna os reorgs de bloco único mais difíceis, já que ataques envolvendo apenas alguns validadores controladores precisariam competir com vários milhares de attesters.
### **O que são proposers e attesters?**
Proposers e Attesters são dois papéis importantes na fork choice rule Gasper: **Proposers** são validadores encarregados de propor um novo bloco a cada 12 segundos em um “slot,” e **Attesters** são validadores que votam no que consideram ser o head da chain canônica.
Um validador Proposer geralmente é selecionado aleatoriamente e escolhido como parte de um comitê formado por cerca de 1/32 de todos os validadores. Dentro desse comitê, também há Attesters.
Os votos dos Attesters são chamados de **attestations** e dão “peso” ao bloco, o que significa que controlar attesters também concede a capacidade de controlar a fork choice rule.
Como os comitês são escolhidos aleatoriamente, compostos por Proposers e Attesters, não há como os atacantes concentrarem seus validadores em um slot específico.
## **Problema pós-merge?**
No geral, o reorging se tornará uma preocupação menor, já que conseguir reorganizar um bloco como um único attester ou um pequeno grupo de attesters se tornará cada vez mais difícil. Além disso, os desenvolvedores da Ethereum podem fazer mudanças na fork choice rule para aumentar os requisitos para reorgs ou encontrar uma solução para caminhar em direção a um consenso de [single slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality). O consenso de single slot finality melhoraria a experiência do usuário, criaria melhor resistência a reorgs por MEV, e reduziria a complexidade e os bugs do protocolo.