Roteiro de privacidade do Ethereum: as três mudanças técnicas propostas por Vitalik Buterin

O Ethereum já possui ferramentas criptográficas avançadas capazes de proteger transações. Na prática, porém, grande parte das informações dos usuários ainda acaba exposta — seja pela ordem das transações, pela infraestrutura de carteiras ou pelos dados observados por operadores de nós.

Para enfrentar esses pontos fracos, o cofundador do Ethereum, Vitalik Buterin, apresentou um roteiro de privacidade de curto prazo que prioriza mudanças de engenharia relativamente incrementais, capazes de ser implementadas antes de uma grande reformulação do protocolo. O plano se concentra em três melhorias técnicas principais que atuam em diferentes camadas da rede.

1. Account Abstraction + FOCIL para reduzir censura de transações

O primeiro passo aborda um problema estrutural das blockchains: quem decide quais transações entram em um bloco.

Hoje, construtores de blocos e validadores podem priorizar ou ignorar certas transações. Em casos extremos, transações ligadas a ferramentas de privacidade podem ser atrasadas ou simplesmente não incluídas.

A proposta destaca a combinação de Account Abstraction (AA) com Fork‑Choice Enforced Inclusion Lists (FOCIL). Esse mecanismo cria listas obrigatórias de inclusão que garantem que transações válidas presentes no mempool público sejam incluídas em um bloco dentro de um número limitado de slots, em vez de depender apenas da decisão de um único proponente de bloco.

O FOCIL está previsto como um dos principais recursos da atualização Hegota, planejada para a segunda metade de 2026.

Para sistemas de privacidade, isso é crucial: não adianta proteger os dados da transação se a infraestrutura puder simplesmente se recusar a processá‑la. Garantir inclusão confiável fortalece a resistência à censura — um dos princípios centrais do Ethereum.

2. Nonces com chave (EIP‑8250) para transações paralelas

O segundo ponto resolve um gargalo técnico importante.

No modelo atual do Ethereum, cada conta possui um único nonce sequencial usado para impedir ataques de repetição e manter a ordem das transações. O problema é que esse sistema cria um efeito dominó: se uma transação fica presa ou atrasada, todas as seguintes também ficam bloqueadas.

A proposta EIP‑8250 introduz o conceito de "keyed nonces" (nonces com chave), que criam múltiplas "faixas" independentes de nonce dentro de uma mesma conta. Cada transação teria dois campos:

• nonce_key — define o domínio de proteção contra repetição
• nonce_seq — define a sequência dentro desse domínio

Com isso, transações usando chaves diferentes podem avançar em paralelo, sem interferir umas nas outras.

Essa mudança é especialmente útil para protocolos de privacidade e infraestrutura baseada em relayers, onde múltiplos usuários ou ações podem passar por um mesmo endereço. No sistema atual, essas operações acabam competindo pelo mesmo nonce sequencial. Com nonces paralelos, o fluxo de transações pode escalar sem conflitos.

Desenvolvedores discutem incluir essa melhoria também na atualização Hegota, junto com outras mudanças estruturais do modelo de transações do Ethereum.

3. Privacidade na camada de acesso: carteiras, Kohaku e consultas privadas

A terceira etapa trata de um problema menos visível, mas igualmente relevante: o vazamento de metadados fora da blockchain.

Mesmo quando transações são privadas, usuários frequentemente revelam informações ao simplesmente consultar a rede — por exemplo:

• verificar saldo
• consultar dados de contratos
• interagir com determinados aplicativos

Essas consultas normalmente passam por provedores RPC (como serviços que conectam carteiras à blockchain), que podem registrar essas atividades e criar perfis de comportamento dos usuários.

Por isso, o roteiro enfatiza melhorias na chamada camada de acesso, incluindo frameworks de carteira que integrem privacidade diretamente no software.

Um exemplo é o Kohaku, um conjunto modular de ferramentas de privacidade para carteiras Ethereum. Em vez de depender de aplicativos separados para transações privadas, a ideia é incorporar esses recursos diretamente nas carteiras comuns usadas pelos usuários.

Algumas abordagens incluem integração com light clients, permitindo que a carteira verifique dados da blockchain por conta própria em vez de depender totalmente de provedores centralizados de RPC. Isso reduz significativamente o risco de rastreamento das consultas feitas pelos usuários.

Como o plano se encaixa na estratégia maior do Ethereum

O roteiro revela uma mudança de abordagem no ecossistema Ethereum.

Em vez de esperar por um grande protocolo único de privacidade, o plano aposta em melhorias distribuídas em várias camadas da infraestrutura. Essas mudanças visam resolver dois pontos fracos recorrentes em blockchains públicas:

• censura de transações, quando validadores ou construtores podem bloquear certas operações
• vazamento de metadados, quando a infraestrutura observa e analisa o comportamento dos usuários

Ao fortalecer garantias de inclusão de transações, permitir fluxos paralelos de transações e proteger consultas feitas por carteiras, o objetivo é transformar a privacidade de um recurso experimental em infraestrutura utilizável por aplicativos e carteiras comuns.

No longo prazo, a ambição é permitir que usuários — e também instituições — utilizem o Ethereum sem expor publicamente todos os detalhes de suas atividades, mantendo ao mesmo tempo a transparência e a verificabilidade que tornam as blockchains públicas confiáveis.

Em resumo, a proposta trata a privacidade não como uma única funcionalidade, mas como uma propriedade do sistema inteiro, que envolve consenso, mecânica de transações e a própria infraestrutura de acesso à rede.