Governança central do Ethereum explicada

Uma apresentação de Nixo Rokish da Fundação Ethereum na ETHBoulder, explicando a governança do protocolo central do Ethereum, como as bifurcações rígidas (hard forks) são coordenadas, equívocos comuns sobre quem controla o Ethereum e como participar do processo de governança.

Esta transcrição é uma cópia acessível da transcrição original do vídeo (opens in a new tab) publicada pela EthBoulder. Ela foi levemente editada para facilitar a leitura.

Introdução (0:12)

Obrigado aos meus seis amigos que apareceram. Certo. Hoje vou falar com vocês sobre a governança central do Ethereum. Meu nome é Nixo. Eu lidero a equipe de suporte ao protocolo na EF (Fundação Ethereum). Entre todos os nossos mandatos, um deles é tornar o processo de governança mais claro e fácil de navegar para todos os outros que participam dessas coisas, porque o Ethereum inclui muito mais do que apenas seus desenvolvedores principais (core devs).

Então, aqui está um resumo da palestra. Vamos falar sobre o que é a governança central. Vamos falar sobre equívocos, como a governança do Ethereum funciona atualmente. Vamos abordar como ela se compara a outros sistemas de governança descentralizada, por que os construtores deveriam se importar e caminhos práticos para participação.

Então, o que é a governança do protocolo central? Eu executo um nó. O que isso significa é que eu tenho um hardware, um computador na minha casa onde executo o software do Ethereum. Quando configurei esse software do Ethereum, tive que escolher os clientes que executariam esse software. O Ethereum é meio único por ter vários clientes para a diversidade de clientes. O objetivo disso é que, se um cliente cair, se houver um bug em um cliente, a rede inteira não cai. Existem outras blockchains que têm outros clientes. No entanto, o Ethereum é o único configurado de uma forma que realmente nos protege contra bugs. Então, se você for para a Solana, por exemplo, a Solana tem outro cliente, acho que se chama GTO, mas tem apenas 20–21% de adoção. Portanto, se o cliente majoritário cair, a cadeia cai. E já vimos outras redes caírem. E é por isso que o Ethereum é a blockchain mais resiliente e segura.

Então a questão passa a ser como você introduz mudanças no Ethereum quando precisa coordenar com tantos clientes diferentes. Primeiro, vamos diferenciar entre uma bifurcação rígida (hard fork) e uma bifurcação leve (soft fork). Uma bifurcação leve não exige a coordenação que uma bifurcação rígida exige. O Ethereum trabalha principalmente com bifurcações rígidas. Então, o que é uma bifurcação rígida é basicamente todos os clientes construírem uma nova versão do Ethereum e decidirem, em um momento pré-configurado, lançar essa nova versão do Ethereum. Ainda é o Ethereum, mas tem novos recursos. Tem recursos diferentes. E todos os operadores de nó como eu, que estão executando nós em casa, ou operadores profissionais, precisam adotar essa nova versão do Ethereum. Eles precisam atualizar seu nó ou atualizar seus nós para incluir esse novo software.

Então, como eles decidem quais recursos entram nessas bifurcações rígidas? Eles precisam concordar com as prioridades para alocar seu tempo e recursos, porque eles têm tempo e recursos finitos para alocar lá. Eles priorizam coisas como falhas de segurança ou correções de segurança, coisas como UX (experiência do usuário) — se houver outra blockchain competindo conosco, precisamos nos tornar competitivos com essas outras blockchains. Então, uma das coisas que eles observam é que qualquer recurso que entre deve ser compatível com possíveis itens futuros do roteiro.

Então, no ano passado, aconteceu uma coisa muito polêmica. Você deve ter ouvido falar. Chamava-se EOF. Isso é EVM Object Format. Era um conjunto de recursos programado para entrar na bifurcação rígida Fusaka — Pectra, Fusaka, acho que ambas — mas foi dividido. E um dos gatilhos, entre muitos, para que fosse retirado dessa bifurcação foi porque o Vitalik publicou um post sobre o potencial do Ethereum adotar o RISC-V. Muitas das pessoas que estavam lendo aquilo olharam e pensaram: ok, se adotarmos o RISC-V, os recursos que estamos analisando no EOF vêm nativos com o RISC-V. Então, por que adicionaríamos essa complexidade ao protocolo? Por que colocaríamos todos esses recursos de desenvolvedores de clientes nessa coisa? Seria irrelevante se acabássemos mudando para o RISC-V.

Então, essa foi a gota d'água para o EOF e ele acabou sendo retirado da bifurcação. Outra coisa que eles precisam considerar é que ele deve ser escrito e rigorosamente testado em seis linguagens diferentes, porque esses clientes são escritos em seis linguagens diferentes. Então, essa é uma matriz de testes muito grande para eles trabalharem. E, por causa disso, cada pequena escolha de design fica sujeita a debate, sem nenhuma autoridade para resolver as divergências. Então, a questão que surge é quem decide — o que é o cerne da governança.

Equívocos (5:23)

Isso nos leva aos equívocos e vamos abordar alguns deles. Um deles é que o Vitalik decide o que entra no protocolo do Ethereum. Uma extensão disso é que a EF controla tudo. E um terceiro é que são todos acordos de bastidores — pessoas de dentro, veteranos (OGs) tomando essas decisões.

Então, o primeiro: Vitalik decide. Eu apenas escolhi um subconjunto de EIPs estagnadas de autoria do Vitalik. O que isso significa é que o Vitalik sentou, escreveu uma proposta e disse: eu quero que essas coisas entrem no Ethereum, e ninguém concordou — essas coisas estão apenas paradas lá. Ele não conseguiu colocá-las no protocolo. Portanto, nem tudo o que ele propõe é incluído automaticamente.

Uma extensão disso é que a Fundação Ethereum controla tudo. Vou escolher um exemplo específico de uma época que acho que contradiz isso. Em 2024, falou-se muito sobre o limite de gas. E a razão para isso é que em 2022, durante o The Merge, aumentamos o limite de gas para 30 milhões. Essa é a computação máxima permitida em um bloco. E então meio que não tocamos nisso por um tempo porque não era realmente um gargalo que fizesse as pessoas dizerem: "É por isso que não estou mudando para o Ethereum" ou "Isso está restringindo meu caso de uso atual do Ethereum".

E no final de 2023, início de 2024, havia essa narrativa de que a Solana estava chegando. Ela ia engolir o Ethereum. E então as pessoas estavam pensando sobre o que o Ethereum poderia fazer para acelerar. E uma das coisas foi: vamos aumentar essa métrica de gas. E, na época, a EF e os desenvolvedores de clientes estavam meio que: "Temos outras coisas com que nos preocupar. Mas obrigado." Mas essas duas pessoas, Eric Connor e Mariano Conti, chegaram e disseram: "Não, nós vamos aumentar o limite de gas." O limite de gas é um parâmetro controlado pelo validador. E então eles puderam simplesmente começar a conversar com os validadores, operadores profissionais, e dizer: "Ei, aumentem seu limite de gas."

E em algum momento houve adoção suficiente para que a EF e os clientes dissessem: "Oh, temos que prestar atenção nisso. Temos que garantir que o que eles estão fazendo seja seguro e que o valor para o qual eles acabarão aumentando isso seja algo seguro para a rede." Então, eles tiveram que realocar seus recursos. O Nethermind criou essa estrutura de testes. A EF fez um monte de trabalho em Berlim. Todos os desenvolvedores de clientes estavam fazendo benchmarking disso. E então eu gosto disso porque forçou a mão da EF a decidir o que era priorizado.

E eu gosto desse tweet estúpido que tirei print aqui porque é como se algum canal de notícias aleatório chamasse Eric Connor e Mariano Conti de desenvolvedores principais (core devs). Eles não são core devs. Eric Connor era um staker e membro da comunidade. Mariano Conti era um ex-desenvolvedor de aplicativos da MakerDAO. Mas eles simplesmente foram chamados de core devs porque o desenvolvimento do Ethereum está realmente fora do mundo de como o software tradicional funciona e, então, eles viram um parâmetro central sendo modificado e pensaram: "Oh, esses devem ser desenvolvedores principais." Eles não eram. Então, este é apenas um exemplo de membros da comunidade chegando e dizendo que queremos ver essa mudança e fazendo acontecer.

São todos acordos de bastidores, pessoas de dentro, veteranos — eu entendo um pouco mais por que isso é um equívoco, porque você basicamente entra nessas chamadas de governança, há cem pessoas nessas chamadas de governança. Parece que todos estão muito confortáveis com o que está acontecendo. Você está perdido. Você não tem ideia de como essas decisões são tomadas. Você fica tipo: "Já é a minha vez de falar?" E parece que as pessoas estão ouvindo as mesmas 10 pessoas para tomar essas decisões.

Meritocracia e estatísticas de participação (10:18)

Mas a verdade é que o desenvolvimento do Ethereum é mais uma meritocracia do que eu já vi na maioria dos desenvolvimentos de software. Todas essas pessoas nesta captura de tela — esta é uma de três nesta chamada ACD aleatória que decidi capturar — nenhuma dessas pessoas foi nomeada para estar aqui. Todo mundo é apenas o tipo de pessoa que apareceu. Eles são os desenvolvedores que passaram muito tempo com este protocolo. Eles são aqueles que as pessoas reconheceram como desenvolvedores talentosos neste espaço, tomando boas decisões consistentemente, e ninguém nisso é nomeado para estar aqui.

Então, eu entrei na EF há pouco mais de um ano. Peguei essas estatísticas. Elas só remontam a março de 2025. Então, menos de um ano. A média de participantes do All Core Dev — que são as chamadas de governança — é 98. Então, em média, há 98 pessoas nessas chamadas. O máximo de participantes em uma chamada desde então foi 153. Acho que foi no dia em que estávamos decidindo a data da Mainnet da Pectra. E o total de participantes únicos é 567 apenas no último ano. Eu realmente gosto dessa métrica porque ela mostra que não são as mesmas 100 pessoas indo a essas chamadas todas as vezes. Esses desenvolvedores de aplicativos, pesquisadores, alguém ouve falar de algum recurso que está sendo discutido, eles aparecem para expressar sua oposição ou seu apoio a ele e depois não vêm a outra chamada.

Como funciona o processo de governança (11:52)

Então, este é um slide meio chato, mas acho importante repassar — é assim que a governança do Ethereum funciona atualmente. Então, quando uma dessas bifurcações está sendo discutida, a primeira coisa que acontece é que as pessoas, durante essa janela de tempo alocada, podem enviar sua proposta principal (headliner). A proposta principal é o grande recurso em torno do qual queremos que as pessoas se unam para essa bifurcação. Pode ser um membro da comunidade, um pesquisador, um desenvolvedor principal — realmente qualquer um que envie uma dessas propostas principais. Então a janela termina e nas chamadas de governança nós meio que discutimos qual delas faz sentido. As pessoas apresentam seus argumentos, as pessoas debatem e há um consenso sobre qual devemos escolher para a próxima bifurcação.

Em seguida, eles escolhem os recursos menores. Ou seja, as coisas menores que não precisam ser esses grandes recursos que impulsionam a bifurcação. E durante todo esse tempo, temos devnets específicas para recursos. Uma devnet é como uma rede de teste (testnet) — uma rede de teste privada para os desenvolvedores testarem esses recursos e garantirem que eles estão realmente funcionando no Ethereum. E então, em algum momento, há um congelamento de recursos (feature freeze). Então, discutimos os recursos principais, discutimos os recursos menores, executamos essas devnets específicas para recursos que geralmente são os destaques da bifurcação. E isso é um congelamento de recursos com um asterisco, porque nesse ponto decidimos que não adicionaremos mais nenhum recurso a essa bifurcação. Vamos executar todos os recursos juntos, garantir que tudo esteja bem, garantir que nada vai quebrar. Mas se algo começar a atrasar as coisas, se a bifurcação for adiada, se for muito complexa, as coisas ainda podem ser retiradas nesse ponto.

Então, depois de várias devnets — podem ser duas, podem ser 10 — todos os clientes decidem em algum momento que isso está estável. Confiamos no que está acontecendo agora. Estamos em um bom lugar. Vamos começar a pensar em lançar isso na Mainnet do Ethereum. Eles lançam as versões dos clientes e, em seguida, há um período de 30 dias em que a equipe de segurança da EF lança um programa de recompensas por bugs (bug bounty). Eles contratam auditorias de segurança. E então, no final desse período de 30 dias, lançamos a bifurcação nas redes de teste. Estas são redes de teste das quais você já deve ter ouvido falar — como a Holesky. É aqui que os desenvolvedores de aplicativos podem testar suas coisas antes que a bifurcação entre no ar. E estas geralmente duram no mínimo 14 dias cada, apenas para garantir que tudo esteja bem. Não esperamos grandes problemas porque já passou por devnets específicas de recursos e devnets generalizadas antes, mas historicamente isso quebrou algumas dessas redes de teste. E então esta é meio que a última chamada para encontrar e esmagar todos esses bugs.

E então, uma vez que a rede de teste não permissionada esteja estável, a data da Mainnet é escolhida. Em seguida, há um período de tolerância de 30 dias. Esse período de 30 dias existe porque as L2s e os protocolos solicitaram isso para se prepararem para a bifurcação. Então, isso é um mínimo de 30 dias e então a bifurcação acontece.

Estrutura de chamadas e coordenação (15:01)

Durante todo esse tempo, há algumas séries de chamadas principais acontecendo. Todas essas são chamadas públicas transmitidas ao vivo no YouTube. As principais são ACDE e ACDC. O E é para a camada de execução — são coisas como transações, implantações de contratos inteligentes, gerenciamento da mempool. ACDC é a camada de consenso — então são coisas de validador, como gerenciamento de validadores, penalização (slashing). E elas se alternam às quintas-feiras. Então, há uma ACD toda quinta-feira e uma delas é ACDE e a próxima é ACDC, continuando dessa forma.

As chamadas ACDE e ACDC se concentram na bifurcação que estamos fazendo atualmente e nas bifurcações que estamos planejando para o futuro. As chamadas ACDT são mais detalhistas e aprofundadas. São os clientes conversando sobre bugs que não conseguem superar ou detalhes de implementação que precisam ser resolvidos sobre a bifurcação em que estão trabalhando no momento. Então, agora, a próxima bifurcação que vai acontecer é a Glamsterdam. Portanto, essas chamadas ACDT são dominadas por conversas sobre ePBS e listas de acesso em nível de bloco, que são as coisas que entrarão na Glamsterdam. E essas são as chamadas altamente técnicas.

E então há as chamadas de grupo (breakout calls). As chamadas de grupo são membros da comunidade, pesquisadores, desenvolvedores dizendo: "Ei, eu tenho um recurso que quero colocar no Ethereum daqui a duas bifurcações." E então eles organizam essas chamadas semanais, mensais ou bimestrais onde discutem os detalhes de implementação, alteram e iteram na especificação e geralmente abordam todas as dúvidas que as pessoas têm, todas as incógnitas conhecidas para garantir que esteja no melhor lugar possível para ser incluído na bifurcação daqui a duas bifurcações. E essas podem ser agendadas sempre que o facilitador decidir.

Um processo em evolução (15:29)

Então, uma coisa que quero deixar claro para todos é que esse processo é tudo menos estático. Esse processo que acabei de descrever para vocês está ativo há menos de um ano. O Ethereum está ativo há 10 anos. Mas ele muda constantemente e a razão pela qual muda constantemente é porque ninguém está no comando. E esse processo meio que evolui para descobrir a maneira mais eficiente de operar. E eu digo eficiente, mas a reputação que a governança do Ethereum tem é de ser muito estagnada, difícil de aprovar as coisas, confusa — e isso é porque quando você tem de 100 a 500 pessoas tomando decisões, estou honestamente impressionado que isso funcione.

Então, o Tim fez um post em abril de 2025 chamado "Reconfiguring All Core Devs" (Reconfigurando Todos os Desenvolvedores Principais), que acabou sendo a proposta de como as coisas funcionam agora. E a razão para isso é porque, antes disso, tínhamos meio que essa narrativa coesa sobre no que deveríamos focar no Ethereum. Houve o The Merge, que foi um empreendimento enorme. Todo mundo estava muito animado. A maioria das pessoas estava muito animada. Os mineradores não. E então, após o The Merge, tivemos os saques. Então, não queríamos que as pessoas tivessem seu ETH bloqueado em um contrato e esse FUD (medo, incerteza e dúvida) de que nunca conseguiriam tirar o ETH disso. Então, tivemos que lançar isso o mais rápido possível. E então houve o Proto-Danksharding e depois veio a Pectra, e a Pectra foi meio que esse amálgama de diferentes EIPs não relacionadas e não tinha realmente uma narrativa coesa. E ficou tão grande porque as pessoas estavam meio que apenas enfiando as coisas devido à falta de coesão, que teve que ser dividida em duas bifurcações diferentes porque as equipes de teste disseram: "O escopo é grande demais. Não podemos testar tudo isso."

E então o ímpeto do Tim para fazer isso foi: ok, precisamos pensar em uma maneira de manter essas bifurcações o mais focadas e coesas possível. E o recurso principal (headliner) foi meio que a resposta para isso. O objetivo disso era lançar de uma forma que priorizasse fazer com que todos sentissem que sabiam do que se tratava a bifurcação, para que não tivessem que enfiar 25 EIPs diferentes.

Então, a outra captura de tela no topo é o Tim propondo definições para os estágios de inclusão dessas EIPs. E o ponto que quero destacar com isso é que às vezes você ouve as pessoas dizerem que esse processo é muito burocrático. Mas o que realmente está acontecendo é que as pessoas entram nesse processo de governança e perguntam: "Como faço para incluir uma EIP?" e as pessoas que estão lá há 10 anos respondem: "Você meio que simplesmente faz." E as pessoas ficam tipo: "Isso é horrível." E então o que essas coisas fazem é descrever o que está acontecendo para tornar mais fácil para pessoas de fora participarem desse processo, porque se você está apenas chegando aqui e diz: "Eu tenho uma EIP, não me importo com a governança do Ethereum, eu só quero que essa EIP entre" — você quer uma rubrica, você quer uma lista de verificação, você quer um passo a passo muito claro sobre como incluir essa EIP. Portanto, a maioria dessas coisas tem mais a ver com descrever como o processo funciona do que com criar regras burocráticas que as pessoas precisam seguir para dificultar a inclusão de EIPs.

A terceira coisa são os commits ao longo do tempo no Forkcast. O Forkcast é um produto da minha equipe, do Wolfram Mark, um cara da minha equipe que criou isso em meados do ano passado, quando minha equipe em sua iteração atual foi formada. E se tornou um recurso tão canônico para as pessoas usarem para interagir com uma bifurcação, para ver o que está entrando em uma bifurcação e como isso as afeta. Todas essas coisas têm menos de dois anos. Então, o ponto que estou defendendo é que esse processo muda muito. Não é nada estático. Não é uma burocracia congelada onde é difícil colocar o pé na porta.

Sistemas de governança comparáveis (20:21)

Então, apenas rapidamente, eu queria abordar os sistemas de governança descentralizada mais semelhantes que consigo ver em relação à governança do Ethereum. E o ponto que estou tentando defender aqui é que isso é sustentável — embora seja incrível que 100 a 500 pessoas possam tomar decisões, é sustentável no mundo real. Vemos exemplos disso funcionando.

A IETF é a Força-Tarefa de Engenharia da Internet (Internet Engineering Task Force). É o órgão de padrões administrado por voluntários que criou o TCP/IP, o HTTP. É a organização mais responsável pelo fato de termos a internet livre hoje. O kernel do Linux — é o núcleo do sistema operacional Linux. Então, esse é o software de código aberto que alimenta servidores de internet, telefones Android, supercomputadores. A diferença aí é que eles têm uma espécie de modelo de ditador benevolente com Linus Torvalds. Mas, mesmo assim, eles têm mais de 17.000 contribuidores, o que é alucinante.

Coisas com as quais isso não é semelhante: outras blockchains que têm votação de token onchain. O Ethereum evita especificamente qualquer tipo de mecanismo de votação porque, na minha opinião, isso leva a caminhos para captura e meio que elimina o incentivo para tornar as coisas uma meritocracia onde as pessoas simplesmente confiam nas pessoas que escrevem o melhor código. E depois há as L2s. Elas têm multi-sigs. Elas têm conselhos de segurança. Esses são mais como cargos nomeados que tomam essas decisões. E isso tem suas desvantagens. É mais centralizado. Mas se move mais rápido.

Por que os construtores se importam (22:38)

Então, por que os construtores se importam com a governança? Porque os construtores são literalmente para quem o Ethereum foi criado. O Ethereum não foi criado para os desenvolvedores principais. Não foi criado para os validadores. Às vezes, essas pessoas ficam confusas sobre isso. Os desenvolvedores principais e os validadores do Ethereum servem ao Ethereum, que serve aos construtores e usuários.

E todo mundo já teve aquele momento com uma IA em que você está se aprofundando demais nos detalhes e ela está tentando consertar essa coisinha e não consegue se afastar e olhar para todo o propósito do projeto. E os desenvolvedores principais podem ser assim, onde estão tentando aperfeiçoar o processo de desenvolvimento central. E é muito crucial, nesse caso, que os construtores entrem, porque o desenvolvimento central é tão exaustivo que eles não estão também construindo em cima do Ethereum na maior parte do tempo. Eles estão muito envolvidos no desenvolvimento central. Isso toma todo o tempo deles. E então os construtores de aplicativos realmente precisam fazer um esforço para entrar e dizer: "Ei, nós precisamos disso. Isso é crucial para o Ethereum." Apenas para garantir que a perspectiva esteja lá e que eles não fiquem rotulados apenas trabalhando para os desenvolvedores principais.

Como participar (24:40)

Então, como você participa ou inclui seu recurso? Este é um conselho meio genérico, mas acho que é o melhor. Fale alto sobre seus pontos de dor. Vá ao Twitter, escreva posts em blogs, identifique soluções para seus pontos de dor. Especule sobre as coisas que poderiam ajudá-lo. Se você encontrar outras pessoas que têm esses mesmos pontos de dor, geralmente você pode encontrar uma EIP que existe para resolver esse ponto de dor ou pedir a alguém que o ajude a escrever uma EIP que faça isso.

Uma coisa que gosto no software de código aberto é que, geralmente, empresas bem capitalizadas alocarão seu tempo de desenvolvimento e recursos para manter as ferramentas de código aberto que estão usando. E acaba sendo um monte de empresas diferentes colaborando na manutenção dessa coisa e pode ser assim que funciona no Ethereum também. Então, se você tem um ponto de dor que identificou, pode encontrar um desenvolvedor da Base que tenha um ponto de dor semelhante, e a Base é uma organização bem capitalizada e, portanto, eles provavelmente estariam dispostos a alocar alguns recursos para lançar um recurso ou guiar um recurso por meio de uma bifurcação rígida do Ethereum.

Vou apenas deixar alguns recursos para vocês. Forkcast.org — é onde você pode ir e ver o que está entrando em uma bifurcação, como isso afeta certas partes interessadas. Então, se você é um desenvolvedor de aplicativos, há uma seção para desenvolvedores de aplicativos. Se você é um desenvolvedor de carteira, um desenvolvedor de cliente da camada de consenso, há seções sobre como tudo isso afeta você. O YouTube é onde todos os vídeos dessas chamadas são enviados. Eles também estão incorporados na página forkcast.org/calls, onde há resumos, atribuições de palestrantes, para que seja mais fácil navegar por essas chamadas. O diretório de EIPs, o fórum Ethereum Magicians, onde você pode conversar com outras pessoas sobre possíveis soluções ou EIPs que deseja escrever. E muito em breve minha equipe terá um site de suporte ao protocolo. Parece incrível. Não está pronto para compartilhar. Meu e-mail também está aí — nixo@ethereum.org (opens email client). É isso.