Ethereum prepara defesa contra bots com mempool criptografado

Os desenvolvedores da Ethereum discutirão na terça-feira, 19 de agosto, uma proposta para criptografar o mempool público e ocultar transações pendentes de bots que exploram ordens antes de elas serem incluídas em blocos. A reunião, marcada no repositório ethereum/pm no GitHub, traz à tona um dos problemas mais persistentes da rede desde o surgimento do MEV.

O ponto de entrada do problema é o mempool. Qualquer transação antes de ser confirmada on-chain fica exposta em uma fila pública, onde builders, searchers e bots leem o conteúdo bruto e decidem se vale a pena agir ao redor dela. Os ataques sandwich são o exemplo mais direto. O bot detecta uma troca, compra o ativo antes para inflar o preço e vende logo depois que a vítima fecha a operação no preço piorado.

O problema não desapareceu. Em maio, o próprio Vitalik Buterin foi alvo do bot Jaredfromsubway.eth, que executou front-running e back-running em uma troca de US$ 4 em um dos seus endereços.

A saída que os desenvolvedores agora estudam é o commit-before-reveal. A ideia é que transações sejam criptografadas enquanto aguardam inclusão e só recebem a chave de descriptografia depois que a posição no bloco já foi comprometida. Sem ver o conteúdo, o builder não consegue reordenar para extrair valor.

Duas propostas em discussão

O EIP-8184, batizado de LUCID, é a proposta principal. Criado em março de 2026 por Anders Elowsson, Justin Florentine e Julian Ma, o draft exige que builders aceitem transações seladas com um ticket cobrável e um payload cifrado, sem ter acesso ao conteúdo. A revelação do que a operação faz só acontece depois que o builder já se comprometeu a incluí-la no bloco. A arquitetura deixa espaço para evoluir a criptografia usada no futuro sem precisar alterar o protocolo.

O desafio é que nenhum esquema criptográfico hoje resolve todas as exigências na escala da Ethereum. Chaves compactas, decriptação sem interação, ausência de setup confiável, ciphertexts de tamanho viável, resistência a ataques com cifra escolhida e caminho para segurança pós-quântica não coexistem em nenhuma construção conhecida. Por isso o módulo de decriptação fica do lado de fora do protocolo.

O EIP-8105, de Jannik Luhn, entra por outro caminho com um grafo de confiança entre provedores registrados, sem impor modelo único de decriptação.

O dilema da decriptação

Se a chave não chega ou é retida de propósito, o custo recai sobre quem enviou a transação. O rascunho original do LUCID não transfere automaticamente a penalidade para o provedor externo de chaves. Para limitar o prejuízo, a parcela cifrada no topo do bloco ocupa no máximo um oitavo do limite de gas, com uma taxa de depósito que retorna ao remetente após a descriptografia ou é integralmente queimada se a revelação não acontecer.

Existe um arranjo de patrocinio fora do protocolo, no qual o provedor banca a transação dentro do bundle e absorve o prejuízo se ela permanecer lacrada, mas a Ethereum não exige nem valida esse compromisso. O protocolo é cego quanto à intenção por trás da retenção, seja mau funcionamento, atraso de rede ou decisão deliberada.

O que está em jogo no roadmap

A pauta de quarta-feira inclui se vale a pena adotar uma solução criptográfica provisória, sem proteção contra computação quântica. Também discute como comprovar retenção ou comercialização antecipada de chaves por participantes de uma lista de validadores confiáveis, e se essas provas podem ser automatizadas. LUCID se liga ao FOCIL, o EIP-7805 que atribui a vários validadores a função de indicar quais transações o builder é obrigado a incluir. O FOCIL entra no upgrade Hegotá em 2027 como prioridade de consenso, enquanto infraestrutura pós-quântica fica em um horizonte mais distante. Qualquer implementação real vai precisar se encaixar nesse cronograma.