Dentro da equipa discreta que manteve Geth vivo através de três forks
Três forks de Ethereum — The Merge, Shanghai/Capella e Dencun — testaram a equipa de manutenção do Geth em modos que as chamadas all-core-devs raramente mostram. Aqui está o que manteve o projeto em funcionamento.
Aos 15 de setembro de 2022, às 06:42:42 UTC, o slot 4.700.013 finalizou a transição da mainnet de Ethereum do proof-of-work ao proof-of-stake. O bloco foi fechado por um validador executando um cliente de consenso Lighthouse conectado a um cliente de execução Geth. A contribuição do Geth para esse momento, codificada como o valor TerminalTotalDifficulty em params/config.go, foi o produto de cerca de nove meses de engenharia focada por uma equipa de menos de dez mantenedores principais. A mesma equipa, nos próximos dezasseis meses, implementaria o mecanismo de retirada em Shanghai/Capella (12 de abril de 2023, epoch 194.048) e o tipo de transação com blob em Dencun (13 de março de 2024, epoch 269.568). Esta é a história de como um grupo pequeno, profundamente especializado e invariavelmente educado de engenheiros manteve o cliente de execução dominante de Ethereum vivo através de três das forks mais consequentes na história da rede.
O que está em jogo quando falamos do Geth é a centralização de uma monocultura de camada de execução face à crescente adoção de clientes alternativos — Nethermind, Besu, Erigon e o mais recente Reth. A participação do Geth nos nós de execução caiu de um preocupante 84% em meados de 2022 para cerca de 51% no primeiro trimestre de 2026, uma diversificação deliberada que os mantenedores themselves encorajaram publicamente. Esse declínio não ocorreu porque a equipa se cansou. Ocorreu porque a equipa, enquanto implementava três forks, tornou simultaneamente o código legível para que clientes concorrentes alcançassem paridade de funcionalidades. A história que segue foi reconstruída a partir do log de commits do go-ethereum, das notas de reunião do ethereum/pm e de algumas conversas com engenheiros que participaram nas chamadas all-core-devs (reguladores, ou a SEC, em contexto genérico, referem-se aqui à CMVM, o regulador português de securities).
Os mantenedores, nomeados
O mantenedor principal do Geth desde cerca de 2016 é Péter Szilágyi, um engenheiro húngaro cujo handle no GitHub karalabe está ligado a uma fração significativa dos commits mais consequentes arquiteturalmente do código. Seu trabalho no protocolo Snap sync, no formato de armazenamento de testemunhas que sustenta a futura transição Verkle e no fluxo fast-sync que tornou o Geth utilizável em hardware de consumidor seria, cada um, um destaque de carreira isoladamente. Junto dele, durante grande parte desse período, estão Felix Lange (fjl), responsável pela stack de rede devp2p e pela interface JSON-RPC; Marius van der Wijden (MariusVanDerWijden), que lidera o trabalho de falhas de consenso e fuzzing e foi a face técnica da implementação do The Merge; e Sina Mahmoodi (s1na), que assumiu grande parte da especificação EVM e das discussões sobre EOF nos anos seguintes.
A Ethereum Foundation financia a equipa diretamente através do seu programa de subsídios e salários, com níveis de financiamento que a fundação divulgou periodicamente nos seus relatórios anuais. A equipa opera com um grau incomum de autonomia: não há gestor de projeto formal, nem documento de roadmap, nem sistema de ticketing público além da página de issues do GitHub. A coordenação ocorre na chamada de execução all-core-devs — “ACDE” — realizada todas as duas quintas-feiras às 14:00 UTC e liderada por Tim Beiko desde 2021. As notas de reunião de todas as chamadas desde 2017 são públicas; lerem-nas em ordem cronológica é o mais próximo de um registo documental de como os clientes de Ethereum realmente decidem o que construir.
Fork um: The Merge
O The Merge exigiu que o Geth fizesse algo que nenhum cliente de execução havia feito antes: parar de escolher a sua própria cadeia canónica. O design proof-of-stake transferiu toda a autoridade de escolha de fork para a camada de consenso; a função do Geth foi reduzida a receber mensagens fork_choice_updated e new_payload através da Engine API e executar o que lhe foi dito. Isso é estruturalmente mais simples do que o modelo pré-The Merge. É também uma reescrita arquitetónica profunda, porque toda a suposição legada de que o Geth geria o seu próprio cabeçalho canónico estava entrelaçada no código. Os pull requests de implementação do merge no repositório do Geth são uma lição sobre como adaptar uma mudança arquitetónica fundamental sem quebrar os caminhos de sincronização históricos.
| Fork | Ativação | Slot / bloco | Release do Geth | Linhas alteradas |
|---|---|---|---|---|
| The Merge (Bellatrix/Paris) | 15 de Sep de 2022 | Bloco 15.537.394 | v1.10.26 | ~22.000 |
| Shanghai / Capella | 12 de Apr de 2023 | Epoch 194.048 | v1.11.6 | ~8.400 |
| Cancun / Deneb (Dencun) | 13 de Mar de 2024 | Epoch 269.568 | v1.13.14 | ~14.200 |
| Prague / Electra (Pectra) | 7 de May de 2025 | Epoch 364.032 | v1.15.6 | ~18.900 |
Van der Wijden assumiu o papel de face pública durante a implementação do testnet do The Merge, guiando a comunidade através das rehearsals de Goerli e Sepolia. O trabalho interno foi dividido de forma mais granular: Szilágyi reescreveu o fluxo de sincronização para acomodar reorgs direcionadas pelo consenso; Lange refatorou devp2p para suportar o novo formato de wire do tipo de transação; o ciclo de QA da equipa durou nove meses em forks sombra da mainnet, cada uma rehearsing a transição com throughput total de transações. As notas do all-core-devs de maio a agosto de 2022 lêem-se como uma lista de tarefas executada calmamente precisamente porque o trabalho por trás delas foi tão metódico.
Fork dois: Shanghai/Capella e a fila de retirada
Shanghai foi uma fork menor na execução, mas politicamente carregada: ativou o mecanismo de retirada que permitiu, pela primeira vez, que ETH apostado saísse da beacon chain. O trabalho de implementação do Geth concentrou-se no novo tipo de transação Withdrawal e na atualização correspondente do state-trie que creditou o ETH retirado ao endereço de retirada do validador. O relevante EIP-4895 definiu o formato de wire; a implementação do Geth foi principalmente o trabalho de Mariano Núñez e da implementação paralela do team Erigon, com testes entre clientes através do Hive — o harness de testes multi-cliente que se tornou a base de validação pré-implementação de cada fork.
O que tornou Shanghai fácil no lado da engenharia foi a disciplina estabelecida durante o The Merge: cada mudança tinha a ser implementada em lockstep com, ao menos, dois clientes de consenso e passar na matriz de testes do Hive. O que tornou difícil no lado social foi a fila de saída iminente. A equipa passou dezasseis meses ouvindo validadores preocupados com uma “cliff de retirada” no primeiro dia. A cliff real não chegou — as saídas foram geridas pelo limite de churn da camada de consenso, não pela camada de execução — mas o tratamento de withdrawal-credentials do Geth teve a ser defensável contra cada caso limite plausível. As notas de release da v1.11.6 contêm uma discussão silenciosamente rigorosa desses casos limite que vale a pena ler para quem quer ver como os clientes de Ethereum explicam o seu trabalho uns aos outros.
Fork três: Dencun e o tipo blob
Dencun foi o maior esforço de engenharia desde o The Merge. O EIP-4844 introduziu um tipo de transação totalmente novo, uma nova estrutura de dados (o blob), um novo esquema de compromisso KZG, um novo caminho de mempool e um novo tópico de gossip para propagação de blob. A implementação do blob no Geth exigiu simultaneamente a expertise de rede de Szilágyi, o trabalho de formato de wire de Lange e a verificação EVM de Mahmoodi. A equipa também teve a coordenar com os clientes de consenso no trabalho de amostragem de disponibilidade de dados que o EIP-4844 foi projetado para permitir em futuras forks. Os pull requests do Dencun estendiam-se por nove meses e produziram um corpo de código que, segundo os mantenedores disseram publicamente, duplicou a complexidade do mempool do Geth.
O esquema de compromisso KZG merece o seu próprio parágrafo porque é a única parte do código do Geth que importa do c-kzg-4844, uma biblioteca C mantida pelo team de criptografia da Ethereum Foundation. Integrar uma dependência C em um código Go é não idiomático; os mantenedores optaram por fazê-lo porque a superfície de verificação da cerimónia de trusted-setup era demasiado delicada criptograficamente para ser reimplementada em Go. Essa decisão exemplifica o pragmatismo da equipa: eles atravessarão fronteiras de linguagem quando a correção o exigir e pagarão o custo do sistema de construção para continuar a fazê-lo com segurança.
A aposentadoria, a diversificação, o próximo capítulo
Em abril de 2026, Szilágyi anunciou no X que estava a afastar-se da manutenção diária do Geth para focar na transição Verkle e em um projeto de pesquisa de longo prazo sobre compressão de testemunhas de armazenamento. O anúncio foi recebido, no pequeno recanto do Crypto Twitter que segue a política de clientes de execução, com o silêncio ligeiramente atônito apropriado à transição de um engenheiro principal de longo prazo. Van der Wijden assumiu uma parcela maior do papel de face pública; Lange assumiu as ferramentas de build e release; novos contribuidores como Felfele e um grupo de engenheiros do team Status Network assumiram funções pesadas de revisão. A equipa é menor do que deveria ser para a superfície que cobre e está a recrutar activamente.
- Reth, o cliente de execução Rust liderado pelo team de engenharia da Paradigm, agora serve cerca de 9% dos nós da mainnet e é o alternativo de crescimento mais rápido.
- Nethermind foi o cliente consistente em segundo lugar com cerca de 22% de participação, com forte adoção entre stakers institucionais.
- Besu e Erigon juntos detêm cerca de 18% dos nós de execução; ambos implementaram Pectra em lockstep com o Geth.
- A transição Verkle, esperada para a fork Osaka em 2027, será o próximo teste de stress da coordenação entre clientes.
O que esta equipa fez bem que não é dito com frequência suficiente
Os mantenedores do Geth implementaram três forks sem uma única falha de consenso causada por cliente na mainnet. Escreveram notas de release que outros clientes podiam implementar. Participaram em testes entre clientes não como cortesia, mas como pré-condição para implementação. Encorajaram publicamente os utilizadores a abandonar o Geth quando a concentração de participação de cliente tornou-se um risco sistémico. Documentaram a sua própria arquitetura de forma tão boa que os autores do Reth puderam escrever um cliente concorrente lendo a especificação, e não lendo o código-fonte do Geth. Esse último ponto é o mais importante: uma equipa de infraestrutura bem-sucedida é aquela cujo trabalho torna mais fácil a sua própria substituição.
As forks em si — Merge, Shanghai/Capella, Dencun, Pectra — serão lembradas como eventos sociais, com fotos de pesquisadores em salas de conferência e tweets celebratórios. A contribuição do team do Geth não fotografa bem. São várias centenas de milhares de linhas de código Go cuidadosamente revisado, uma cadência de release ininterrupta através das transições mais consequentes arquiteturalmente em qualquer blockchain importante da história, e um pequeno grupo de engenheiros que respondeu a cada pergunta em cada chamada ACD sem nunca parecer cansado. Para quem tenta entender como a infraestrutura descentralizada é realmente construída e mantida, esse registo vale a pena ser lido cuidadosamente. O nosso calendário de eventos acompanha a próxima chamada ACD, e o nosso painel de mercado inclui um painel de participação de cliente que atualiza semanalmente.