Ethereum 2026: A aposta de Vitalik na confiança sem intermediários

Ao longo da última década, o Ethereum fez escolhas calculadas, trocando a ausência de confiança pela conveniência, a soberania pessoal pela experiência do utilizador, e a descentralização pela adoção generalizada.

Sempre que consulta o saldo da sua carteira, deposita confiança em empresas como a Alchemy ou a Infura. Sempre que utiliza uma dapp, os seus dados são transmitidos para servidores que nunca escolheu.

Mas 2026 representa um ponto de viragem. É o ano em que o Ethereum deixa de questionar se vale a pena diluir-se para alcançar a adoção mainstream. A resposta é clara – já não.

A visão:

• Full nodes fáceis de operar novamente (ZK-EVMs + Block-Level Access Lists)
• RPCs verificáveis em vez de confiança cega (cliente leve Helios)
• Pagamentos privados com experiência pública
• Carteiras para além das seedphrases frágeis (recuperação social)
• Interfaces de dapp imparáveis (alojamento em IPFS)
• Construção de blocos resistente à censura (FOCIL)

O retrocesso: como chegámos até aqui

A infraestrutura do Ethereum tornou-se cada vez mais centralizada, mesmo com a camada base a manter-se descentralizada.

Os nodes deixaram de ser compatíveis com portáteis, passando a exigir mais de 800 GB de armazenamento e sincronizações de 24 horas. As dapps evoluíram de páginas HTML simples para sistemas complexos do lado do servidor, expondo os seus dados em todo o lado. As carteiras passaram de RPCs controlados pelo utilizador para fornecedores pré-definidos que monitorizam todas as suas ações.

De forma mais significativa, 80-90% dos blocos do Ethereum são atualmente produzidos por apenas dois builders. Esta concentração coloca a inclusão de transações sob controlo de um pequeno grupo de entidades capazes de censurar o que quiserem.

Estas decisões não foram erros, mas escolhas pragmáticas tomadas durante o processo de escalamento sob as limitações do Proof of Work.

O custo, contudo, foi real: pressupostos de confiança infiltraram-se em sistemas “sem confiança”, pontos únicos de falha multiplicaram-se e os utilizadores perderam a verdadeira soberania pessoal. Descentralizámos o registo, mas re-centralizámos a camada de acesso.

A visão para 2026: sete pilares

1. Full Nodes

Realidade atual: mais de 800 GB de armazenamento, sincronização de 24 horas, necessidade de disponibilidade constante. A maioria dos utilizadores desistiu.

Os Block-Level Access Lists (BAL) mudam radicalmente este cenário. Imagine os BALs como um índice para cada bloco, indicando exatamente que estado será afetado. O seu computador pré-carrega tudo em paralelo antes de iniciar a execução. As transações sem conflito executam-se simultaneamente em núcleos distintos. A análise revela que 60-80% das transações não têm sobreposição.

Combinando com ZK-proofs, que verificam blocos sem reexecutar tudo, os tempos de sincronização reduzem-se drasticamente e o armazenamento torna-se acessível. Operar um node volta a ser possível num portátil decente, e não apenas para empresas de infraestrutura.

2. Helios: verifique o seu RPC

Imagine este ataque: está a trocar na Uniswap. O seu RPC malicioso mostra-lhe um preço falso. Assina aceitando menos tokens do que deveria. O RPC executa um ataque sandwich e fica com o lucro. Nunca percebeu.

Isto ainda não aconteceu com fornecedores principais, mas é tecnicamente possível. O problema reside em confiar noutra entidade para lhe indicar o estado da blockchain.

O Helios resolve isto em apenas 2 segundos. É um cliente leve que acompanha os “sync committees” dos validadores (512 validadores, períodos de cerca de 27 horas). Se 2/3 ou mais assinarem um cabeçalho de bloco, é canónico. Ao verificar o saldo, o Helios solicita uma prova Merkle ao RPC não confiável e valida-a localmente. O RPC pode recusar responder, mas não pode mentir.

Funciona em qualquer dispositivo: portátil, telemóvel, extensões de navegador. Utilize-o como RPC MetaMask e todas as dapps tornam-se sem confiança, sem alterar mais nada.

A tecnologia já existe hoje, open source e pronta para integração.

3. ORAM & PIR: consultas privadas

Cada consulta RPC revela o seu comportamento, que endereços observa, que protocolos utiliza, quando os utiliza.

O ORAM (Oblivious RAM) oculta padrões de acesso usando estruturas em árvore. O servidor vê que está a aceder a dados, mas não sabe quais. O Signal messenger utiliza esta abordagem, reduzindo os custos em 100 vezes (de 500 servidores para 6).

O PIR (Private Information Retrieval) permite consultar bases de dados sem revelar o que procura. Envia uma consulta encriptada, o servidor processa-a em dados encriptados e decripta a resposta. O tamanho da resposta mantém-se constante (~3KB), independentemente do tamanho da base de dados.

Implementações reais já existem:

• Oblivious Labs: verificador privado de saldo WBTC
• sprl.it: resolução ENS privada
• QuietRPC: exploração privada de RPC

O desafio está no estado dinâmico: recodificar 33 milhões de elementos demora 4-20 minutos. A solução passa por snapshots periódicos com atestação on-chain. Para a maioria dos casos (verificação de saldo, elegibilidade para votação), alguns minutos de desatualização são aceitáveis para garantir privacidade.

4. Recuperação social: para além das seedphrases

As carteiras atuais obrigam a escolhas impossíveis:

• Perde a seedphrase → perde tudo
• Seedphrase roubada → perde tudo
• Backup na cloud → soberania comprometida

A recuperação social distribui a confiança. Tem uma chave de assinatura diária e “guardians” (amigos, família, outros dispositivos). A recuperação exige a aprovação de 3 em 5 guardians. Timelocks (48-72 horas) impedem o roubo instantâneo e permitem recuperação legítima.

Perdeu o telemóvel num lago? Contacta os guardians, aprovam uma nova chave, inicia-se o timelock, recupera o acesso. Se alguém roubar a sua chave e tentar este processo, cancela durante o timelock.

Segurança: os atacantes precisam de 3 em 5 guardians simultaneamente. Tem dias para reagir. Cada guardian detém apenas poder parcial. Sem backdoors de empresas tecnológicas.

Carteiras como @ ready_co e @ Safe já suportam este mecanismo. O objetivo para 2026: torná-lo padrão em todo o ecossistema, com UX acessível a qualquer utilizador.

5. Pagamentos privados por defeito

Ferramentas de privacidade existem, mas são difíceis de usar: apps distintas, experiência pobre, custos de gas 3-5 vezes superiores, suporte limitado. Quase ninguém as utiliza.

Objetivo 2026: privado = experiência pública. Mesma carteira, mesma interface, custos comparáveis. A privacidade passa a ser uma opção simples, não um projeto de investigação.

Tecnologias: zkSNARKs (prova de fundos sem revelar quais), endereços stealth (endereços únicos por transação), integração com Account Abstraction.

6. FOCIL: privacidade resistente à censura

Pagamentos privados não têm valor se os builders recusarem incluí-los. Com 80-90% dos blocos a serem produzidos por dois builders, a censura é trivial.

O FOCIL (Fork-Choice enforced Inclusion Lists) elimina a possibilidade de censura:

Em cada slot, 16 validadores selecionados aleatoriamente constroem “listas de inclusão” (8KB cada) a partir das transações do mempool. Os builders de blocos têm de incluir estas transações. Os attesters só votam em blocos que cumpram as listas de inclusão. Sem votos, os blocos não podem tornar-se canónicos.

Porquê funciona:

• Baseado em comité: basta um validador honesto em 16
• Fork-choice enforced: integrado no consenso, impossível contornar
• Mesmo slot: sem atrasos
• Em qualquer parte do bloco: builders otimizam MEV mas não podem censurar

Para privacidade: se um validador incluir a sua transação privada, ela tem de estar no bloco. Os builders não podem censurar sem perder dinheiro.

7. Dapps alojadas em IPFS

Quando visita app.uniswap.org, está a carregar uma aplicação web dos servidores deles. Se os servidores falharem, fica bloqueado. Se forem hackeados por um segundo, a UI maliciosa esvazia a sua carteira. Sob pressão, servem interfaces diferentes a utilizadores distintos.

Solução IPFS: alojar interfaces usando content addressing (identificadas por hash, não por servidor). Qualquer pessoa pode servir conteúdo. Alterar a UI altera o hash. O ENS mapeia nomes amigáveis a hashes.

Vantagens: sem ponto único de falha, impossível de sequestrar, resistente à censura, verificável.

Desafio: atualizações significam novos hashes. Solução: registos ENS apontam para o hash mais recente, descentralização progressiva para governança DAO.

Porque isto importa

“No computador mundial, não existe um senhor centralizado. Não há ponto único de falha. Só existe amor.” - Vitalik

Se o Ethereum se tornar apenas mais uma plataforma que exige confiança em intermediários, porque não usar AWS?

A resposta é que o Ethereum oferece algo verdadeiramente distinto: propriedade real, ausência de permissões genuína, resistência efetiva à censura, soberania pessoal autêntica.

Mas só importa se for acessível. Um sistema teoricamente descentralizado, mas com acesso por pontos centralizados, é apenas teatro de descentralização.

O que está em jogo:

• Sucesso: o Ethereum torna-se infraestrutura fundamental para uma internet aberta, os utilizadores controlam a sua riqueza e dados, a privacidade é padrão
• Fracasso: captura regulatória na camada de acesso, os utilizadores abandonam cripto por CBDCs transparentes, o sonho cypherpunk morre

A década do pragmatismo provou que as blockchains funcionam. Agora provamos que funcionam sem abdicar dos princípios.

Conclusão

Nem tudo será lançado na próxima versão. Construir sistemas sem confiança com excelente UX exige tempo. Coordenar centenas de developers demora ainda mais.

Mas o compromisso é absoluto. Todas as decisões são avaliadas com base em: aumenta a ausência de confiança e a soberania pessoal?

2026 é o momento em que decidimos que a adoção mainstream à custa dos valores fundamentais já não compensa. Que a descentralização “suficiente” não é suficiente. Que os utilizadores merecem mais do que confiar em fornecedores de infraestrutura para aceder a redes “sem confiança”.

As peças técnicas estão a encaixar-se. O Helios já oferece RPC verificável. ORAM/PIR demonstram que consultas privadas funcionam. A recuperação social existe em produção. A resistência à censura do FOCIL está especificada. O caminho está definido.

Agora, deixemos o Ethereum construir.

Aviso:

1. Este artigo é republicado de [stacy_muur]. Todos os direitos de autor pertencem ao autor original [stacy_muur]. Caso existam objeções a esta republicação, contacte a equipa Gate Learn, que tratará do assunto de forma célere.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são da exclusiva responsabilidade do autor e não constituem aconselhamento de investimento.
3. As traduções do artigo para outros idiomas são realizadas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.