Sobre as limitações dos mempools criptografados

O valor que pode ser extraído ao incluir, excluir ou reordenar transações em um bloco é chamado de “maximal extractable value” (MEV) — ou valor máximo extraível —, conforme explicado em MEV. O MEV é frequente na maioria das blockchains e tem sido tema de intenso debate e interesse na comunidade.

Nota: Este artigo pressupõe conhecimento básico sobre MEV. Para quem deseja se aprofundar, sugerimos iniciar pelo nosso guia introdutório sobre MEV.

Diante do cenário do MEV, muitos pesquisadores levantaram uma pergunta essencial: a criptografia pode solucionar o problema? Uma das estratégias propostas é o mempool criptografado, em que os usuários transmitem transações criptografadas, reveladas apenas após serem ordenadas. Dessa forma, o protocolo de consenso determina a ordem das transações às cegas, o que, em tese, impediria que oportunidades de MEV fossem exploradas durante a ordenação.

No entanto, sob o ponto de vista prático e teórico, não acreditamos que mempools criptografados sejam solução definitiva para o MEV. A seguir, detalhamos as principais dificuldades e analisamos como esses mempools podem ser estruturados.

Como funcionam os mempools criptografados

Há diversas propostas de mempools criptografados, mas o funcionamento geral segue estas etapas:

1. Usuários transmitem suas transações criptografadas.
2. As transações criptografadas são registradas on-chain (em algumas propostas, após serem aleatoriamente embaralhadas com prova).
3. Depois que o bloco de registro é finalizado, as transações são descriptografadas.
4. Em seguida, as transações são executadas.

O passo 3 (descriptografia das transações) traz um desafio central: quem será responsável pela descriptografia e o que ocorre caso ela não aconteça? Uma solução ingênua seria permitir que os próprios usuários descriptografem suas transações (nesse caso, nem seria necessário criptografia, bastando ocultar os compromissos). Contudo, isso é vulnerável: um atacante pode realizar MEV especulativo.

No MEV especulativo, o atacante tenta antecipar que determinada transação criptografada possui MEV. Ele criptografa suas próprias transações para posicioná-las estrategicamente (por exemplo, antes ou depois da transação alvo). Se a sequência esperada se confirmar, o invasor descriptografa e extrai o MEV; caso contrário, se recusa a descriptografar, fazendo com que a transação não seja incluída na cadeia final.

Uma possível solução seria penalizar usuários que não realizam a descriptografia, mas isso é difícil de implementar. A penalidade precisa ser idêntica para todas as transações criptografadas (já que são indistinguíveis pelo sistema) e alta o suficiente para coibir MEV especulativo, inclusive contra alvos de alto valor. Isso exigiria o bloqueio de volumes significativos de capital, obrigatoriamente de forma anônima (para não vazar a autoria das transações). Além disso, penalizaria indevidamente usuários legítimos em situações de bugs ou falhas de rede.

Por essa razão, a maioria das propostas sugere que as transações sejam criptografadas de modo que a descriptografia seja possível no futuro — mesmo que o usuário original saia do ar ou não colabore. Isso pode ser implementado de diferentes formas:

TEEs: Neste caso, os usuários criptografam as transações para uma chave administrada por um Trusted Execution Environment (TEE). Em configurações simples, o TEE apenas descriptografa as transações após um tempo limite (sendo necessário algum mecanismo de temporização interno ao TEE). Soluções mais avançadas usam o TEE para descriptografar e organizar o bloco, ordenando as transações por critérios como chegada ou taxas. O diferencial do TEE é operar com transações em texto claro, evitando spam na rede ao filtrar transações que seriam revertidas. Porém, esse método exige confiança irrestrita no hardware.

Compartilhamento secreto e criptografia threshold: Com essa abordagem, usuários criptografam as transações para uma chave compartilhada por um comitê de validadores. Para descriptografar, é necessário um número mínimo (threshold), geralmente dois terços do comitê.

O modelo mais simples utiliza uma chave compartilhada diferente a cada rodada (por bloco ou epoch, por exemplo, no Ethereum), reconstruída e publicada pelo comitê após a finalização do bloco. A vantagem está na simplicidade, mas todas as transações do mempool são reveladas, mesmo as que não foram incluídas. Além disso, é necessário gerar a chave distribuída (DKG) a cada rodada.

Para garantir mais privacidade, é preferível descriptografar apenas as transações realmente incluídas no bloco, usando descriptografia threshold. Isso permite amortizar custos de DKG ao reutilizar a mesma chave por múltiplos blocos, com o comitê descriptografando apenas as transações ordenadas nos blocos finalizados. O desafio, no entanto, é o volume de trabalho adicional do comitê, que é proporcional ao número de transações. Pesquisas recentes apontam para técnicas de descriptografia threshold em lote, reduzindo significativamente esse esforço.

Com a descriptografia threshold, a confiança sai do hardware e passa para o comitê. Como os protocolos já pressupõem maioria honesta dos validadores para o consenso, assume-se que a maioria também não irá descriptografar prematuramente. Contudo, essa não é uma equivalência direta: falhas de consenso (como forks) são públicas (confiança fraca), já ações maliciosas do comitê podem ocorrer secretamente, sem deixar evidências (confiança forte). Portanto, na prática, a confiança de que o comitê não coluda é mais frágil do que parece.

Criptografia time-lock e delay: Outra alternativa à threshold encryption é a criptografia baseada em atraso computacional. Nela, usuários criptografam transações usando uma chave pública cujo segredo fica oculto em um “puzzle” time-lock. Esse desafio só pode ser resolvido após determinado tempo, por meio de computação sequencial não paralelizável. Assim, qualquer pessoa pode, após o tempo requerido, obter a chave e descriptografar as transações, impedindo sua revelação antes da finalização do bloco. A versão mais robusta utiliza delay encryption publicamente. Outra possibilidade envolve um comitê confiável resolvendo o puzzle, mas nesses casos as vantagens sobre threshold encryption são discutíveis.

Tanto por estratégias de delay quanto por comitê confiável, há desafios práticos. É difícil garantir o momento exato da descriptografia, já que o atraso é puramente computacional. Além disso, essas soluções demandam equipamentos sofisticados para processar rapidamente os puzzles, e não está claro como incentivar economicamente esse papel. Outro fator é que, nesses modelos, todas as transações transmitidas podem ser descriptografadas, independentemente de terem sido finalizadas ou não. Soluções threshold (ou witness encryption) têm potencial para restringir a descriptografia apenas às transações efetivamente incluídas.

Witness encryption: A abordagem criptográfica mais avançada utiliza o conceito de witness encryption, permitindo, em teoria, criptografar informações para quem conhece o testemunho de uma relação NP específica. Por exemplo, é possível criptografar uma mensagem que só pode ser acessada por quem possui a solução de determinado problema ou o pré-imagem de um hash.

SNARKs também podem ser aplicados a qualquer relação NP. O witness encryption pode ser entendido como um mecanismo onde o acesso à informação só é possível a quem puder gerar uma prova SNARK válida de determinada condição. No contexto de mempools criptografados, essa condição pode ser a finalização de um bloco.

Embora seja um conceito poderoso e generalizado — englobando as abordagens por comitê e por atraso —, ainda não existem implementações práticas de witness encryption. Mesmo havendo, não está claro se isso traria vantagens sobre o modelo por comitê nas blockchains proof-of-stake. Um comitê malicioso pode simular o consenso privadamente, finalizar blocos ocultos e descriptografar transações, tornando a segurança equivalente à da descriptografia threshold, mas com mais complexidade.

No entanto, witness encryption se destaca em blockchains proof-of-work, pois nem mesmo um comitê comprometido conseguiria minerar secretamente blocos adicionais para simular a finalização.

Desafios técnicos para mempools criptografados

Diversos desafios práticos limitam a capacidade dos mempools criptografados de mitigar o MEV. Em geral, garantir confidencialidade é tarefa complexa. Apesar de rara no universo web3, a criptografia já é amplamente utilizada na web (TLS/HTTPS) e em comunicações privadas (PGP, Signal, WhatsApp), demonstrando na prática as dificuldades de implantação. Criptografia é uma ferramenta importante para confidencialidade, mas não basta por si só.

Em primeiro lugar, há risco de terceiros acessarem o texto claro da transação. Frequentemente, o usuário delega a criptografia ao provedor da carteira, que, por sua vez, tem acesso ao conteúdo e pode usar ou comercializar essas informações para explorar MEV. Em última análise, a segurança criptográfica é limitada ao conjunto de titulares da chave.

Outro ponto crítico são os metadados — dados que circundam a transação criptografada e não são protegidos pela criptografia. Buscadores de MEV podem explorar metadados para inferir intenções e atuar especulativamente. Para isso, não é necessário conhecer todos os detalhes da transação, apenas identificar, por exemplo, que há probabilidade razoável de se tratar de uma ordem de compra em determinada DEX.

Alguns tipos de metadados são desafios clássicos na criptografia, enquanto outros são específicos do contexto de mempools criptografados.

• Tamanho da transação: A criptografia, por si só, não oculta o tamanho do dado criptografado (a própria definição formal de segurança semântica exclui esse fator). Trata-se de um vetor de ataque recorrente em comunicações criptografadas. Por exemplo, mesmo com dados protegidos, um observador pode identificar qual vídeo está sendo assistido na Netflix ao analisar o tamanho dos pacotes. No caso do mempool, tipos específicos de transação podem ter tamanhos característicos que denunciam seu propósito.

• Tempo de transmissão: A criptografia não esconde o momento da transmissão (outro vetor clássico de ataque). No ambiente web3, ordens de venda padronizadas costumam ocorrer em intervalos definidos ou podem ser correlacionadas a eventos externos, como oscilações em exchanges ou notícias. De forma ainda mais sutil, um sequenciador pode lucrar em arbitragem CEX/DEX ao inserir transações com base nas últimas atualizações de preço, excluindo outras submetidas depois, assegurando a própria vantagem estratégica.

• Endereço IP de origem: Monitorando a rede peer-to-peer, buscadores podem identificar o remetente da transação pelo IP de origem — uma vulnerabilidade reconhecida há mais de uma década no ecossistema do Bitcoin. Isso permite vincular transações criptografadas a registros anteriores, facilitando a identificação de padrões.

• Remetente e dados de taxa/gas: As taxas de transação — incluindo endereço remetente (usado para pagamento), limite de gas e valor por unidade de gas — são metadados típicos do Ethereum. Eles permitem rastrear e associar transações a entidades reais, além de deduzir a intenção da transação de acordo com a quantidade de gas solicitada, como ocorre em interações com DEXs específicas.

Buscadores mais sofisticados podem combinar esses fatores para prever o conteúdo de uma transação.

É possível ocultar todos esses metadados, mas com custos significativos em desempenho e complexidade. Preencher transações até um tamanho padrão mascara o dado real, mas consome largura de banda e espaço na blockchain. Atrasar o envio das mensagens reduz a previsibilidade do tempo, mas aumenta a latência. Utilizar redes anônimas, como Tor, pode mascarar o IP do remetente, mas ainda apresenta limitações próprias.

Entre todos, ocultar as taxas de transação é o maior desafio. Criptografar esse dado impõe obstáculos ao construtor de blocos. Primeiramente, abre margem para spam: qualquer pessoa pode transmitir transações criptografadas inválidas, que serão ordenadas, mas não conseguiriam pagar taxas — após a descriptografia, não seriam executadas, sem sanções para o remetente. SNARKs podem ser utilizados para provar que a transação é válida e financiada, mas aumentam o custo computacional.

Outro impacto é sobre a eficiência na montagem dos blocos e nos leilões de taxas. Os construtores dependem das taxas para montar blocos rentáveis e precificar recursos on-chain; ocultar esse dado prejudica o processo. Alternativas como taxa fixa por bloco são ineficientes e podem incentivar mercados paralelos para inclusão de transações, minando os benefícios do mempool criptografado. Leilões de taxas via computação multipartidária segura ou hardware confiável são viáveis, porém custosos.

Adicionalmente, mempools criptografados impõem overheads variados: criptografia gera latência, uso de processamento e maior consumo de banda. Integrar tais soluções a sharding ou execução paralela — metas estratégicas para o futuro da blockchain — é um desafio significativo. Também há risco de surgirem novos pontos de falha, como o próprio comitê de descriptografia ou o resolvedor de funções de atraso. E, inevitavelmente, o desenvolvimento e a implementação tornam-se mais complexos.

Vários desses desafios também se aplicam a blockchains voltadas à privacidade transacional (como Zcash ou Monero). O lado positivo é que resolver os problemas de criptografia para mitigar MEV pavimentaria o caminho para privacidade de transações.

Desafios econômicos para mempools criptografados

Além dos desafios técnicos — que podem eventualmente ser superados com engenharia dedicada —, mempools criptografados enfrentam limitações econômicas fundamentais.

O problema central do MEV decorre da assimetria de informação: usuários que criam transações não sabem o valor extraível de MEV, enquanto buscadores e construtores conhecem e exploram essas oportunidades. Assim, mesmo que o mempool seja totalmente criptografado, usuários podem ser estimulados a vender suas chaves de descriptografia por valores inferiores ao extraído efetivamente (descriptografia incentivada).

Esse cenário já existe em certa medida, como visto no programa MEV Share. O MEV Share realiza leilões de fluxo de ordens, permitindo que usuários transmitam seletivamente dados de transações para um pool, onde buscadores disputam a exploração do MEV — o vencedor repassa parte do lucro ao usuário.

Esse modelo poderia facilmente migrar para ambientes de mempool criptografado, exigindo que usuários revelem chaves de descriptografia (ou parte delas) para participar. Contudo, a maior parte dos usuários não compreende o custo de oportunidade envolvido, percebendo apenas as recompensas recebidas e, assim, cedendo acesso às próprias informações. O mesmo ocorre em práticas da finança tradicional, como corretoras zero-fee do tipo Robinhood, que lucram comercializando o fluxo de ordens dos clientes — o chamado modelo de negócio “payment-for-order-flow”.

Há também casos em que grandes construtores podem obrigar usuários a revelar informações (ou dados parciais) por motivos regulatórios ou censórios. A resiliência à censura é tema relevante no web3. Caso grandes proponentes e construtores sejam legalmente obrigados a aplicar listas de censura (como a OFAC), podem simplesmente recusar sequenciar transações criptografadas. Soluções técnicas, como provas de conhecimento zero que demonstrem conformidade com as listas de censura, aumentam custos e complexidade. Mesmo em blockchains com forte resistência à censura — garantindo inclusão de transações criptografadas —, é provável que construtores priorizem transações em texto claro no início dos blocos, relegando criptografadas ao fim. Nesses casos, garantir certos resultados de execução pode exigir que usuários revelem suas transações.

Outros desafios de eficiência

Mempools criptografados impactam o desempenho do sistema de diversas formas: além de exigir criptografia e descriptografia das transações, aumentam o custo computacional e podem inflar o tamanho das transações. O tratamento de metadados, conforme discutido, soma-se a esses overheads. Há, porém, custos indiretos menos óbvios: em finanças, mercados são considerados eficientes quando preços refletem toda a informação disponível; atrasos e assimetrias — inerentes aos mempools criptografados — geram ineficiências.

Dentre as consequências dessas ineficiências está a maior incerteza sobre preços, decorrente do atraso adicional trazido pelos mempools criptografados. Isso pode aumentar o número de operações mal-sucedidas por slippage e desperdiçar espaço na blockchain.

Outro impacto é a maior incidência de operações MEV especulativas, buscando lucro via arbitragem on-chain. Com mempools criptografados, a incerteza sobre os estados dos DEXs — por conta da execução atrasada — tende a criar mercados menos eficientes, com discrepâncias de preço entre plataformas. Essas operações, quando abortadas, desperdiçam espaço em bloco.

Nosso objetivo foi destacar os principais desafios de mempools criptografados, para que a comunidade foque em desenvolver soluções alternativas; ainda assim, mempools criptografados podem compor parte das estratégias de mitigação do MEV.

Uma alternativa viável são designs híbridos, que ordenam parte das transações às cegas via mempool criptografado e parte por outros métodos. Para ordens de grandes players — que podem criptografar e padronizar suas transações, estando dispostos a pagar mais para evitar MEV —, designs híbridos são recomendados. O mesmo se aplica a transações altamente sensíveis, como correções de falhas críticas em contratos inteligentes.

Entretanto, dada a complexidade tecnológica, os altos custos de engenharia e o impacto no desempenho, mempools criptografados dificilmente serão a solução mágica para o MEV, como alguns acreditam. A comunidade precisará desenvolver outras soluções, como leilões de MEV, defesas na camada de aplicação e redução do tempo de finalização de blocos. O MEV continuará a ser um desafio — encontrar o equilíbrio certo exigirá estudo aprofundado e múltiplas abordagens.

Pranav Garimidi é Research Associate na a16z Crypto, pesquisador em design de mecanismos e teoria dos jogos aplicada a blockchain, com ênfase em incentivos ao longo da stack. Formou-se em Ciência da Computação pela Columbia University antes de integrar a a16z.

Joseph Bonneau é Professor Associado de Ciência da Computação no Courant Institute (NYU), consultor técnico da a16z crypto, especialista em criptografia aplicada e segurança de blockchains. Lecionou cursos de criptomoedas nas universidades de Melbourne, NYU, Stanford e Princeton, sendo PhD por Cambridge e graduado/mestrado por Stanford.

Lioba Heimbach é doutoranda no grupo de Computação Distribuída (Disco) da ETH Zurich, sob orientação do Prof. Dr. Roger Wattenhofer. Seu foco de pesquisa está em protocolos blockchain e finanças descentralizadas (DeFi), visando ecossistemas acessíveis, descentralizados, justos e eficientes. Foi pesquisadora visitante da a16z crypto no verão de 2024.

As opiniões aqui expressas pertencem exclusivamente aos membros da AH Capital Management, L.L.C. (“a16z”) citados, não refletindo necessariamente o posicionamento institucional da a16z ou afiliadas. Certos dados foram obtidos de terceiros, inclusive empresas investidas por fundos da a16z. Embora considerados fontes confiáveis, a a16z não verificou esses dados de forma independente e não garante precisão, atualização ou adequação das informações. Este conteúdo pode conter publicidade de terceiros, não analisada ou endossada pela a16z.

Este material é meramente informativo, não configurando recomendação jurídica, empresarial, fiscal ou de investimentos. Consulte seus próprios assessores antes de qualquer decisão. As referências a valores mobiliários ou ativos digitais são ilustrativas e não representam oferta ou recomendação de investimento nem proposta de serviços de assessoria de investimentos. O conteúdo não se destina a investidores ou potenciais investidores, tampouco deve ser utilizado como base para decisões de investimento em fundos da a16z. (Ofertas serão realizadas exclusivamente por meio de memorando de colocação privada, contrato de subscrição e documentação aplicável, a serem lidos integralmente.) Investimentos mencionados ou referidos não representam todos os investimentos realizados por fundos da a16z, tampouco garantem resultados futuros ou características similares. A relação de investimentos dos fundos Andreessen Horowitz (excetuando investimentos confidenciais ou não anunciados em ativos digitais públicos) pode ser acessada em https://a16z.com/investments/.

O conteúdo é válido na data de publicação. Projeções, estimativas, opiniões e perspectivas aqui contidas podem ser alteradas sem aviso e divergir de outras opiniões. Acesse https://a16z.com/disclosures para mais informações relevantes.

Aviso legal:

1. Este artigo foi reproduzido de [a16zcrypto]. Todos os direitos pertencem aos autores originais [Pranav GarimidiJoseph BonneauLioba Heimbach]. Caso exista qualquer objeção à republicação, contate a equipe Gate Learn para providências imediatas.
2. Isenção de responsabilidade: As opiniões expressas neste artigo pertencem exclusivamente aos autores e não constituem aconselhamento de investimento.
3. Traduções para outros idiomas deste artigo são realizadas pela equipe Gate Learn. Exceto quando indicado, é proibido copiar, distribuir ou plagiar as versões traduzidas.