Este artigo foi compilado e organizado pela BlockWeeks
Merge é a transição do Ethereum do consenso de prova de trabalho (PoW) para prova de participação (PoS), e também a mudança de código mais complexa e radical na história do Ethereum. Seu processo de ativação é diferente de qualquer hard fork anterior: consiste em três grandes etapas e exige que os operadores de nós passem de executar apenas um cliente de software para executar dois clientes simultaneamente. Como a maior blockchain de uso geral do mundo por capitalização de mercado e valor total bloqueado, o valor e a reputação em jogo na transição do Ethereum são enormes.
O que o Merge se destina a resolver: A fusão de duas cadeias
Atualmente, as transações do Ethereum são finalizadas por meio de um protocolo de consenso PoW chamado ethash. Executando em paralelo com esta cadeia PoW está a Beacon Chain — uma blockchain independente que vem executando o novo protocolo de consenso PoS do Ethereum, o Gasper, por conta própria desde dezembro de 2020.
O objetivo do Merge é fundir as duas cadeias: fazer com que a blockchain existente do Ethereum dependa inteiramente da Beacon Chain para produzir consenso de rede, e abandonar completamente a prova de trabalho. O Ethereum que conhecemos hoje não processará mais transações por meio do ethash, mas existirá apenas como a Camada de Execução (EL), para aplicações descentralizadas e usuários transmitirem transações. A Máquina Virtual Ethereum (EVM), o motor de computação do Ethereum, continuará a operar normalmente na Camada de Execução.
A Beacon Chain então se torna a Camada de Consenso (CL) do Ethereum: as transações da Camada de Execução são recebidas, processadas e finalizadas aqui. Empacotar transações da Camada de Execução em blocos e finalizá-las por meio do protocolo Gasper se tornará responsabilidade dos validadores da Beacon Chain. Após o Merge, para acompanhar a cadeia principal do Ethereum, todos os validadores e operadores de nós completos devem executar dois clientes de software simultaneamente — um cliente da Camada de Execução e um cliente da Camada de Consenso.
Primeira etapa: O hard fork Bellatrix
Primeiro, a Camada de Consenso do Ethereum executa um hard fork chamado Bellatrix. Bellatrix introduz uma nova estrutura de bloco da Beacon Chain na Camada de Consenso para acomodar blocos que carregam transações da Camada de Execução. Também incorpora um conjunto de instruções para que os nós da Camada de Consenso não comecem a inserir transações da Camada de Execução em blocos beacon até que a Camada de Execução atinja uma específica "Dificuldade Total Terminal" (TTD). Todos os nós da Camada de Consenso devem atualizar para Bellatrix antes de uma altura de slot especificada (equivalente à altura de bloco na cadeia PoW). Após a conclusão do Bellatrix, os nós da Camada de Consenso começam a monitorar a TTD.
Design chave: Por que usar TTD em vez de altura de bloco
A Dificuldade Total Terminal mede a dificuldade de mineração acumulada da Camada de Execução do Ethereum. Aqui, "dificuldade" refere-se a quão difícil é para os mineradores anexar um novo bloco à blockchain, representando quantas combinações os mineradores normalmente precisam tentar para encontrar o hash correto que gera o próximo bloco. À medida que o poder de computação (taxa de hash) contribuído pelos mineradores cresce, a dificuldade aumenta automaticamente. A TTD é a soma da dificuldade de mineração de todos os blocos na história do Ethereum.
Historicamente, as ativações de hard fork da Camada de Execução nunca dependeram de uma TTD específica, mas sim de uma altura de bloco predefinida. O Merge abandonou essa abordagem devido à possibilidade de um ataque de "fork rápido": um atacante poderia usar uma minoria do poder de hash para bifurcar a Camada de Execução e minerar até o número de bloco especificado mais rápido que a cadeia principal. Se isso acontecesse, a Camada de Consenso poderia completar erroneamente o merge com a cadeia minoritária do atacante em vez da cadeia principal. Portanto, os desenvolvedores escolheram usar a TTD como o limiar para acionar o Merge, porque é muito mais difícil para agentes maliciosos manipulá-la.
Mas usar a TTD como limiar também tem um custo: a TTD é um valor extremamente difícil de prever, o que também torna a previsão do momento de ativação do Merge após o Bellatrix complicada e imprecisa. Essa consequência foi exposta quando os desenvolvedores principais tentaram ativar o Merge pela primeira vez na testnet Ropsten — a configuração original da TTD era imprecisa, fazendo com que o tempo de ativação se desviasse do esperado.
Etapa Dois e Etapa Três: Paris e a Troca da Camada de Execução
Quando a Camada de Execução atinge o limite de TTD, duas propostas de atualização da Camada de Execução são acionadas, uma das quais é a EIP-4399: ela altera a forma como a aleatoriedade on-chain é gerada, deixando de depender da dificuldade de mineração para gerar números inteiros aleatórios para dApps. Ambas as EIPs são ativadas simultaneamente no momento em que o TTD é atingido. Ao mesmo tempo, os nós da Camada de Consenso que estavam aguardando e monitorando esse valor de TTD também começam a processar transações da Camada de Execução a partir desse momento.
O ritmo de lançamento dos clientes e a comunicação com as partes interessadas devem ser enfatizados. Para se preparar para o hard fork Bellatrix, espera-se que a Fundação Ethereum publique um post no blog várias semanas antes, listando as versões de cliente correspondentes às atualizações Paris e Bellatrix para que os operadores de nós as baixem antecipadamente. Essas versões iniciais serão preenchidas com um valor de TTD excepcionalmente grande como espaço reservado. Como o Bellatrix é ativado em uma altura de slot específica, a data e o horário estimado dessa atualização também serão comunicados às partes relevantes.
Após a conclusão do Bellatrix, o novo valor de TTD será comunicado aos operadores de nós novamente por meio de um segundo post no blog. Desta vez, não é necessária uma atualização completa dos clientes da Camada de Consenso ou da Camada de Execução; no mínimo, basta adicionar uma linha de código a cada um dos dois tipos de clientes para substituir manualmente o valor de TTD anterior. Atualizações opcionais de clientes também podem ser oferecidas neste momento, mas isso é uma decisão de cada equipe de cliente e de forma alguma é um lançamento obrigatório necessário para acompanhar a fase final da Merge.
Após o anúncio do valor de substituição do TTD, começa a fase de espera para que o novo limite seja atingido. Embora haja estimativas aproximadas de tempo, a data e a hora exatas da ativação do Paris não podem ser conhecidas com precisão antecipadamente.
Riscos de Execução Que Não Podem Ser Ignorados
1. O Vácuo Operacional Causado pelo Momento Imprevisível
A incapacidade de prever com precisão o TTD significa que todos os serviços que dependem do Ethereum não podem fixar antecipadamente o momento exato de "o momento da Merge". Para empresas que precisam pausar ou congelar depósitos e saques, isso representa um desafio operacional real.
2. A Pressão Operacional da Arquitetura de Cliente Duplo
Após a Merge, os operadores de nós devem executar simultaneamente clientes da Camada de Execução e da Camada de Consenso, e qualquer configuração incorreta ou incompatibilidade de versão em qualquer um dos lados pode fazer com que um nó fique para trás. Os ensaios iniciais em testnets (Sepolia, Goerli) tornam-se, portanto, cruciais.
3. Uma Mudança Fundamental na Produção de Blocos e na Lógica de Finalidade
Após a Merge, os blocos não serão mais finalizados em unidades de altura de bloco, mas em unidades de slots e épocas. Os validadores processam um slot a cada 12 segundos, e 32 slots compõem uma época, ou seja, uma época a cada 6,4 minutos. As transações na Beacon Chain atingem a finalidade após 2 épocas, cerca de 12,8 minutos. Para exchanges, DEXs e outras aplicações DeFi construídas com diferentes suposições sobre a finalidade das transações e a velocidade de confirmação, essas mudanças futuras devem ser antecipadas e preparadas com antecedência para evitar interrupções de serviço ou exploração.
Conclusão: Pequena Probabilidade, Grande Impacto
A transição do Ethereum de PoW para PoS é a atualização de blockchain de Camada 1 mais acompanhada e de maior alcance na história das criptomoedas; nunca antes uma rede comparável em escala e importância ao Ethereum passou por uma mudança tão drástica. Como os desenvolvedores investiram enormes esforços em testes e preparação, a probabilidade de que os riscos acima impactem severamente usuários e dApps não é alta; mas se qualquer um dos cenários descritos neste artigo ocorrer, a ponto de a rede precisar reverter a atualização por meio de um hard fork de emergência, o valor e a reputação do Ethereum como blockchain de propósito geral poderão ser prejudicados.
Portanto, todas as partes interessadas devem estar cientes desses riscos e tomar medidas para mitigar o impacto de problemas potenciais em seu próprio uso da rede, por exemplo, pausando ou congelando depósitos e saques durante janelas críticas em que podem ocorrer interrupções. Ao mesmo tempo, validadores, dApps e provedores de serviços devem se preparar participando dos ensaios de ativação subsequentes nas redes de teste Sepolia e Goerli, o que pode tanto garantir que os operadores de nós dominem as melhores práticas para acompanhar a atualização Merge quanto expor problemas no processo antes da ativação da mainnet. Além disso, a vigilância da Ethereum Foundation, das equipes de clientes e da mídia confiável contra desinformação relacionada ao Merge durante a ativação é especialmente crítica — incluindo valores de TTD incorretos, versões de clientes incorretas, expectativas de tempo incorretas e orientações operacionais incorretas — e eles precisam coordenar rapidamente para informar claramente às partes relevantes o que preparar a seguir, até que a atualização Merge esteja completamente concluída.
