{"id":30,"date":"2026-06-25T13:19:50","date_gmt":"2026-06-25T13:19:50","guid":{"rendered":"https:\/\/hoge.gg\/pt\/inside-the-quiet-team-that-kept-geth-alive-through-three-forks\/"},"modified":"2026-06-25T13:19:50","modified_gmt":"2026-06-25T13:19:50","slug":"inside-the-quiet-team-that-kept-geth-alive-through-three-forks","status":"publish","type":"post","link":"https:\/\/hoge.gg\/pt\/inside-the-quiet-team-that-kept-geth-alive-through-three-forks\/","title":{"rendered":"Dentro da equipa discreta que manteve Geth vivo atrav\u00e9s de tr\u00eas forks"},"content":{"rendered":"\r\n

Aos 15 de setembro de 2022, \u00e0s 06:42:42 UTC, o slot 4.700.013 finalizou a transi\u00e7\u00e3o 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\u00e7\u00e3o Geth<\/a>. A contribui\u00e7\u00e3o do Geth para esse momento, codificada como o valor TerminalTotalDifficulty<\/code> em params\/config.go<\/code>, 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\u00f3ximos dezasseis meses, implementaria o mecanismo de retirada em Shanghai\/Capella (12 de abril de 2023, epoch 194.048) e o tipo de transa\u00e7\u00e3o com blob em Dencun (13 de mar\u00e7o de 2024, epoch 269.568). Esta \u00e9 a hist\u00f3ria de como um grupo pequeno, profundamente especializado e invariavelmente educado de engenheiros manteve o cliente de execu\u00e7\u00e3o dominante de Ethereum vivo atrav\u00e9s de tr\u00eas das forks mais consequentes na hist\u00f3ria da rede.<\/p>\r\n\r\n\r\n\r\n

O que est\u00e1 em jogo quando falamos do Geth \u00e9 a centraliza\u00e7\u00e3o de uma monocultura de camada de execu\u00e7\u00e3o face \u00e0 crescente ado\u00e7\u00e3o de clientes alternativos — Nethermind, Besu, Erigon e o mais recente Reth. A participa\u00e7\u00e3o do Geth nos n\u00f3s de execu\u00e7\u00e3o caiu de um preocupante 84% em meados de 2022 para cerca de 51% no primeiro trimestre de 2026, uma diversifica\u00e7\u00e3o deliberada que os mantenedores themselves encorajaram publicamente. Esse decl\u00ednio n\u00e3o ocorreu porque a equipa se cansou. Ocorreu porque a equipa, enquanto implementava tr\u00eas forks, tornou simultaneamente o c\u00f3digo leg\u00edvel para que clientes concorrentes alcan\u00e7assem paridade de funcionalidades. A hist\u00f3ria que segue foi reconstru\u00edda a partir do log de commits do go-ethereum<\/a>, das notas de reuni\u00e3o do ethereum\/pm<\/a> e de algumas conversas com engenheiros que participaram nas chamadas all-core-devs (reguladores, ou a SEC, em contexto gen\u00e9rico, referem-se aqui \u00e0 CMVM, o regulador portugu\u00eas de securities).<\/p>\r\n\r\n\r\n\r\n

Os mantenedores, nomeados<\/h2>\r\n\r\n\r\n\r\n

O mantenedor principal do Geth desde cerca de 2016 \u00e9 Péter Szilágyi, um engenheiro h\u00fangaro cujo handle no GitHub karalabe<\/code> est\u00e1 ligado a uma fra\u00e7\u00e3o significativa dos commits mais consequentes arquiteturalmente do c\u00f3digo. Seu trabalho no protocolo Snap sync, no formato de armazenamento de testemunhas que sustenta a futura transi\u00e7\u00e3o Verkle e no fluxo fast-sync que tornou o Geth utiliz\u00e1vel em hardware de consumidor seria, cada um, um destaque de carreira isoladamente. Junto dele, durante grande parte desse per\u00edodo, est\u00e3o Felix Lange (fjl<\/code>), respons\u00e1vel pela stack de rede devp2p e pela interface JSON-RPC; Marius van der Wijden (MariusVanDerWijden<\/code>), que lidera o trabalho de falhas de consenso e fuzzing e foi a face t\u00e9cnica da implementa\u00e7\u00e3o do The Merge; e Sina Mahmoodi (s1na<\/code>), que assumiu grande parte da especifica\u00e7\u00e3o EVM e das discuss\u00f5es sobre EOF nos anos seguintes.<\/p>\r\n\r\n\r\n\r\n

A Ethereum Foundation financia a equipa diretamente atrav\u00e9s do seu programa de subs\u00eddios e sal\u00e1rios<\/a>, com n\u00edveis de financiamento que a funda\u00e7\u00e3o divulgou periodicamente nos seus relat\u00f3rios anuais. A equipa opera com um grau incomum de autonomia: n\u00e3o h\u00e1 gestor de projeto formal, nem documento de roadmap, nem sistema de ticketing p\u00fablico al\u00e9m da p\u00e1gina de issues do GitHub. A coordena\u00e7\u00e3o ocorre na chamada de execu\u00e7\u00e3o all-core-devs — “ACDE” — realizada todas as duas quintas-feiras \u00e0s 14:00 UTC e liderada por Tim Beiko desde 2021. As notas de reuni\u00e3o de todas as chamadas desde 2017 s\u00e3o p\u00fablicas; lerem-nas em ordem cronol\u00f3gica \u00e9 o mais pr\u00f3ximo de um registo documental de como os clientes de Ethereum realmente decidem o que construir.<\/p>\r\n\r\n\r\n\r\n

Fork um: The Merge<\/h2>\r\n\r\n\r\n\r\n

O The Merge exigiu que o Geth fizesse algo que nenhum cliente de execu\u00e7\u00e3o havia feito antes: parar de escolher a sua pr\u00f3pria cadeia can\u00f3nica. O design proof-of-stake transferiu toda a autoridade de escolha de fork para a camada de consenso; a fun\u00e7\u00e3o do Geth foi reduzida a receber mensagens fork_choice_updated<\/code> e new_payload<\/code> atrav\u00e9s da Engine API<\/a> e executar o que lhe foi dito. Isso \u00e9 estruturalmente mais simples do que o modelo pr\u00e9-The Merge. \u00c9 tamb\u00e9m uma reescrita arquitet\u00f3nica profunda, porque toda a suposi\u00e7\u00e3o legada de que o Geth geria o seu pr\u00f3prio cabe\u00e7alho can\u00f3nico estava entrela\u00e7ada no c\u00f3digo. Os pull requests de implementa\u00e7\u00e3o do merge no reposit\u00f3rio do Geth s\u00e3o uma li\u00e7\u00e3o sobre como adaptar uma mudan\u00e7a arquitet\u00f3nica fundamental sem quebrar os caminhos de sincroniza\u00e7\u00e3o hist\u00f3ricos.<\/p>\r\n\r\n\r\n\r\n

Fork<\/th>Ativa\u00e7\u00e3o<\/th>Slot \/ bloco<\/th>Release do Geth<\/th>Linhas alteradas<\/th><\/tr><\/thead>
The Merge (Bellatrix\/Paris)<\/td>15 de Sep de 2022<\/td>Bloco 15.537.394<\/td>v1.10.26<\/td>~22.000<\/td><\/tr>
Shanghai \/ Capella<\/td>12 de Apr de 2023<\/td>Epoch 194.048<\/td>v1.11.6<\/td>~8.400<\/td><\/tr>
Cancun \/ Deneb (Dencun)<\/td>13 de Mar de 2024<\/td>Epoch 269.568<\/td>v1.13.14<\/td>~14.200<\/td><\/tr>
Prague \/ Electra (Pectra)<\/td>7 de May de 2025<\/td>Epoch 364.032<\/td>v1.15.6<\/td>~18.900<\/td><\/tr><\/tbody><\/table>
Release do Geth ligada a cada fork de consenso. Fonte: github.com\/ethereum\/go-ethereum, ethereum.org.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

Van der Wijden assumiu o papel de face p\u00fablica durante a implementa\u00e7\u00e3o do testnet do The Merge, guiando a comunidade atrav\u00e9s das rehearsals de Goerli e Sepolia. O trabalho interno foi dividido de forma mais granular: Szilágyi reescreveu o fluxo de sincroniza\u00e7\u00e3o para acomodar reorgs direcionadas pelo consenso; Lange refatorou devp2p para suportar o novo formato de wire do tipo de transa\u00e7\u00e3o; o ciclo de QA da equipa durou nove meses em forks sombra da mainnet, cada uma rehearsing a transi\u00e7\u00e3o com throughput total de transa\u00e7\u00f5es. As notas do all-core-devs de maio a agosto de 2022 l\u00eaem-se como uma lista de tarefas executada calmamente precisamente porque o trabalho por tr\u00e1s delas foi t\u00e3o met\u00f3dico.<\/p>\r\n\r\n\r\n\r\n

Fork dois: Shanghai\/Capella e a fila de retirada<\/h2>\r\n\r\n\r\n\r\n

Shanghai foi uma fork menor na execu\u00e7\u00e3o, mas politicamente carregada: ativou o mecanismo de retirada que permitiu, pela primeira vez, que ETH apostado sa\u00edsse da beacon chain. O trabalho de implementa\u00e7\u00e3o do Geth concentrou-se no novo tipo de transa\u00e7\u00e3o Withdrawal<\/code> e na atualiza\u00e7\u00e3o correspondente do state-trie que creditou o ETH retirado ao endere\u00e7o de retirada do validador. O relevante EIP-4895<\/a> definiu o formato de wire; a implementa\u00e7\u00e3o do Geth foi principalmente o trabalho de Mariano Núñez e da implementa\u00e7\u00e3o paralela do team Erigon, com testes entre clientes atrav\u00e9s do Hive<\/a> — o harness de testes multi-cliente que se tornou a base de valida\u00e7\u00e3o pr\u00e9-implementa\u00e7\u00e3o de cada fork.<\/p>\r\n\r\n\r\n\r\n

O que tornou Shanghai f\u00e1cil no lado da engenharia foi a disciplina estabelecida durante o The Merge: cada mudan\u00e7a 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\u00edcil no lado social foi a fila de sa\u00edda iminente. A equipa passou dezasseis meses ouvindo validadores preocupados com uma “cliff de retirada” no primeiro dia. A cliff real n\u00e3o chegou — as sa\u00eddas foram geridas pelo limite de churn da camada de consenso, n\u00e3o pela camada de execu\u00e7\u00e3o — mas o tratamento de withdrawal-credentials do Geth teve a ser defens\u00e1vel contra cada caso limite plaus\u00edvel. As notas de release da v1.11.6 cont\u00eam uma discuss\u00e3o 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.<\/p>\r\n\r\n\r\n\r\n

Fork tr\u00eas: Dencun e o tipo blob<\/h2>\r\n\r\n\r\n\r\n

Dencun foi o maior esfor\u00e7o de engenharia desde o The Merge. O EIP-4844 introduziu um tipo de transa\u00e7\u00e3o totalmente novo, uma nova estrutura de dados (o blob), um novo esquema de compromisso KZG, um novo caminho de mempool e um novo t\u00f3pico de gossip para propaga\u00e7\u00e3o de blob. A implementa\u00e7\u00e3o do blob no Geth exigiu simultaneamente a expertise de rede de Szilágyi, o trabalho de formato de wire de Lange e a verifica\u00e7\u00e3o EVM de Mahmoodi. A equipa tamb\u00e9m 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\u00f3digo que, segundo os mantenedores disseram publicamente, duplicou a complexidade do mempool do Geth.<\/p>\r\n\r\n\r\n\r\n

O esquema de compromisso KZG merece o seu pr\u00f3prio par\u00e1grafo porque \u00e9 a \u00fanica parte do c\u00f3digo do Geth que importa do c-kzg-4844<\/a>, uma biblioteca C mantida pelo team de criptografia da Ethereum Foundation. Integrar uma depend\u00eancia C em um c\u00f3digo Go \u00e9 n\u00e3o idiom\u00e1tico; os mantenedores optaram por faz\u00ea-lo porque a superf\u00edcie de verifica\u00e7\u00e3o da cerim\u00f3nia de trusted-setup era demasiado delicada criptograficamente para ser reimplementada em Go. Essa decis\u00e3o exemplifica o pragmatismo da equipa: eles atravessar\u00e3o fronteiras de linguagem quando a corre\u00e7\u00e3o o exigir e pagar\u00e3o o custo do sistema de constru\u00e7\u00e3o para continuar a faz\u00ea-lo com seguran\u00e7a.<\/p>\r\n\r\n\r\n\r\n

A aposentadoria, a diversifica\u00e7\u00e3o, o pr\u00f3ximo cap\u00edtulo<\/h2>\r\n\r\n\r\n\r\n

Em abril de 2026, Szilágyi anunciou no X que estava a afastar-se da manuten\u00e7\u00e3o di\u00e1ria do Geth para focar na transi\u00e7\u00e3o Verkle e em um projeto de pesquisa de longo prazo sobre compress\u00e3o de testemunhas de armazenamento. O an\u00fancio foi recebido, no pequeno recanto do Crypto Twitter que segue a pol\u00edtica de clientes de execu\u00e7\u00e3o, com o sil\u00eancio ligeiramente at\u00f4nito apropriado \u00e0 transi\u00e7\u00e3o de um engenheiro principal de longo prazo. Van der Wijden assumiu uma parcela maior do papel de face p\u00fablica; Lange assumiu as ferramentas de build e release; novos contribuidores como Felfele e um grupo de engenheiros do team Status Network assumiram fun\u00e7\u00f5es pesadas de revis\u00e3o. A equipa \u00e9 menor do que deveria ser para a superf\u00edcie que cobre e est\u00e1 a recrutar activamente.<\/p>\r\n\r\n\r\n\r\n