Proposta de Vitalik: Permitir que cada família execute o seu próprio nó Ethereum

Vitalik Buterin, cofundador do Ethereum, submeteu no sábado uma solicitação de pull à comunidade de desenvolvedores do Ethereum, propondo a fusão do backend da cadeia Beacon (responsável pelo consenso e staking) com a camada de execução do protocolo em uma estrutura de código unificada. Esta proposta visa reduzir fundamentalmente a complexidade técnica de operar nós do Ethereum, permitindo que usuários comuns e residências possam rodar sua própria infraestrutura Ethereum de forma independente, sem depender de provedores de serviços terceirizados.

O núcleo técnico da proposta de camada única: por que “dois programas em um” é tão importante

(Origem: Ethereum Research)

Atualmente, os operadores de nós do Ethereum (validadores) precisam manter dois programas independentes: um que lida com a camada de consenso (a cadeia Beacon, responsável pela lógica de validação PoS) e outro que gerencia a camada de execução (que processa contratos inteligentes e transações no ambiente EVM). Esses dois programas requerem configurações independentes, sincronização contínua e comunicação constante para manter o nó operacional de forma estável.

Tecnicamente, essa arquitetura de dois programas leva a dois problemas principais: primeiro, a complexidade de configuração é duplicada — os usuários precisam baixar, configurar, atualizar e monitorar dois sistemas distintos; segundo, a probabilidade de erros e desincronizações aumenta significativamente, pois qualquer problema em uma das partes pode comprometer toda a operação do nó.

No post em que submeteu a proposta, Buterin admitiu que a comunidade do Ethereum, inadvertidamente, tomou uma decisão padrão: “Rodar um nó é uma tarefa extremamente assustadora de DevOps, que é melhor deixar para profissionais.” Ele deixou claro que se opõe a esse estado de coisas: “Não deveria ser assim. Precisamos mudar essa situação. Mesmo com requisitos de hardware elevados, isso não pode ser uma desculpa para exigir habilidades avançadas de DevOps ou muito tempo — os nós deveriam ser fáceis de configurar.”

Riscos de centralização: monopólio de RPC e riscos de censura

Por trás dessa melhoria técnica, há uma preocupação mais profunda com a crise de descentralização. Como o custo de rodar um nó completo é alto demais para a maioria dos usuários, incluindo desenvolvedores de DApps e usuários comuns, eles dependem de poucos provedores de RPC (chamadas de procedimento remoto), como Infura, Alchemy, para interagir com a rede Ethereum.

Buterin destacou claramente no post os perigos potenciais dessa estrutura de mercado: “Um mercado dominado por poucos provedores de RPC enfrentará forte pressão para bloquear ou censurar usuários. Muitos provedores já excluíram países inteiros de seus serviços.”

Se um provedor de RPC decidir restringir o acesso de determinadas regiões ou usuários, esses usuários perderão completamente a capacidade de interagir com o Ethereum, o que entra em conflito direto com o compromisso fundamental da tecnologia blockchain de ser “sem permissão e resistente à censura.”

Nós sem estado parciais: outro caminho técnico para reduzir barreiras

Esta proposta de camada única não é a primeira iniciativa de Buterin para diminuir a barreira de entrada para operar nós. Em maio de 2025, ele apresentou o conceito de “nós sem estado parciais” — nós que não mantêm todo o histórico de blocos, mas apenas os dados necessários para o operador do nó.

Esse design foi criado especificamente para “nós de uso pessoal”: se o usuário só precisa enviar transações e validar a blockchain, sem oferecer um serviço completo de histórico de dados, a quantidade de dados que precisa armazenar pode ser significativamente menor. Segundo a explicação do Go-Ethereum (Geth), o espaço em disco é o principal gargalo para operadores de nós — blockchains de contratos inteligentes como o Ethereum geram uma quantidade massiva de dados continuamente, exigindo armazenamento em crescimento constante. Nós sem estado parcial eliminam essa limitação de “acúmulo ilimitado de dados.”

As duas abordagens atuam em conjunto: o design de camada única reduz a complexidade de DevOps, enquanto os nós sem estado parcial reduzem custos de hardware — formando uma base técnica dupla para o futuro imaginado por Buterin, no qual “cada residência possa rodar seu próprio nó.”

Perguntas frequentes

Quanto tempo levará para a proposta de camada única de Vitalik ser implementada?

Atualmente, a proposta ainda está na fase de solicitação de pull, precisando passar por revisão técnica e discussão ampla na comunidade de desenvolvedores do Ethereum. Atualizações de protocolo do Ethereum geralmente levam meses ou mais de um ano de desenvolvimento, testes e consenso comunitário. O cronograma exato depende da complexidade da implementação, do feedback na revisão técnica e de sua inclusão na próxima atualização do Ethereum (como a versão após Fusaka).

Antes que a proposta seja implementada, quais caminhos os usuários comuns têm para rodar um nó Ethereum mais facilmente?

Atualmente, ferramentas como DAppNode, Stereum facilitam a implantação de nós com um clique, reduzindo bastante a barreira técnica. Em termos de hardware, dispositivos de baixo consumo como Raspberry Pi já podem rodar nós básicos do Ethereum (com SSD externo). Clientes leves, como Helios, permitem que usuários validem dados sem sincronizar toda a blockchain. Além disso, há esforços contínuos para padronizar e automatizar os processos de implantação de clientes Ethereum diversos.

Provedores de RPC já bloquearam países antes; o que isso significa para os usuários?

Alguns provedores de RPC, como Infura, já implementaram restrições regionais por motivos de conformidade. Isso significa que usuários de DApps em regiões restritas, sem a possibilidade de trocar de provedor ou rodar seu próprio nó, podem ficar completamente incapazes de acessar aplicações Ethereum. Essa é exatamente a razão pela qual Buterin enfatiza a autonomia dos nós — quanto mais usuários comuns puderem rodar seus próprios nós, mais forte será o compromisso do Ethereum com resistência à censura.