Sobre os limites dos mempools cifrados

O valor extraído ao incluir, excluir ou reordenar transações num bloco denomina-se “valor máximo extraível” ou MEV. O MEV é prevalente na maioria das blockchains e tem sido amplamente debatido na comunidade.

Nota: Este artigo pressupõe conhecimentos básicos de MEV. Alguns leitores poderão preferir iniciar pela nossa explicação introdutória sobre MEV.

Perante o fenómeno do MEV, muitos investigadores colocaram uma questão fundamental: pode a criptografia resolver o problema? Uma abordagem consiste num mempool encriptado, em que os utilizadores transmitem transações encriptadas que apenas são reveladas após o seu ordenamento. Assim, o protocolo de consenso teria de assumir uma ordem de transações de forma cega, o que parece inviabilizar o aproveitamento de oportunidades de MEV durante a ordenação.

No entanto, tanto por razões práticas como teóricas, não prevemos que os mempools encriptados ofereçam uma solução universal para o MEV. Apresentamos aqui as principais dificuldades e discutimos possíveis modelos de mempools encriptados.

Como operam os mempools encriptados

Apesar de existirem diversas propostas para mempools encriptados, o modelo genérico baseia-se nos seguintes passos:

1. Os utilizadores transmitem as respetivas transações encriptadas.
2. As transações encriptadas são registadas na blockchain (em algumas propostas, após uma permutação aleatória comprovada).
3. Depois de finalizado o bloco de compromisso, as transações são desencriptadas.
4. Por fim, as transações são executadas.

O passo 3 (desencriptação) coloca um desafio crítico: quem desencripta e o que sucede se não houver desencriptação? Uma solução ingénua seria os próprios utilizadores desencriptarem as suas transações (neste caso seria suficiente ocultar os compromissos, sem autenticação). No entanto, este modelo é vulnerável: um atacante pode explorar MEV especulativo.

No MEV especulativo, o atacante tenta prever que uma determinada transação encriptada produz MEV, encriptando as suas próprias transações na esperança de que surjam em posições vantajosas (por exemplo, imediatamente antes ou depois da transação-alvo). Se a ordem for favorável, o atacante desencripta e extrai o MEV. Se não for, recusa-se a desencriptar e a transação não se concretiza na cadeia final.

Poder-se-ia penalizar a falha de desencriptação, mas tal é difícil de implementar. A penalização teria de ser idêntica para todas as transações encriptadas (por serem indistinguíveis) e suficientemente dissuasora mesmo perante altos valores de MEV. Isso exigiria imobilizar grandes montantes de capital de modo anónimo (para não associar transações a utilizadores), prejudicando ainda utilizadores legítimos em caso de bugs ou falhas de rede que impeçam a desencriptação.

Por isso, a maioria das propostas sugere encriptação de forma a garantir que a desencriptação será possível no futuro, mesmo sem cooperação do utilizador. Existem várias formas de atingir esse objetivo:

TEEs: Os utilizadores podem encriptar para uma chave de um Trusted Execution Environment (TEE). Em soluções básicas, o TEE serve apenas para desencriptar após um determinado tempo (exigindo temporização interna). Modelos mais sofisticados usam o TEE para desencriptar e construir o bloco conforme critérios como tempo de chegada ou valor da taxa. Os TEEs distinguem-se pela capacidade de filtrar transações inválidas e reduzir spam, operando sempre sobre dados em claro, mas exigem confiança no hardware.

Partilha secreta e encriptação por limiar: Os utilizadores encriptam para uma chave partilhada por um comité (normalmente validadores). A desencriptação requer um limiar mínimo (por exemplo, dois terços do comité).

No modelo simples, é gerada uma nova chave partilhada em cada ronda (bloco ou época do Ethereum), sendo reconstruída e publicada pelo comité após o ordenamento das transações num bloco final. Isto exige partilha secreta simples, mas expõe todo o mempool, mesmo as transações não incluídas, e obriga a novo Distributed Key Generation (DKG) em cada ronda.

Uma alternativa mais amiga da privacidade desencripta apenas as transações incluídas, recorrendo a desencriptação por limiar. Desta forma é possível utilizar a mesma chave por vários blocos, amortizando custos do DKG, com o comité a processar só as transações ordenadas num bloco final. O revés é o acréscimo de trabalho do comité: o esforço é linear no número de transações, ainda que investigaçõesrecentes em desencriptação por limiar em lote apontem ganhos substanciais.

Neste modelo, a confiança passa do hardware ao comité. Como a maioria dos protocolos assume maioria honesta entre validadores, pode-se aceitar que estes não desencriptarão antecipadamente. Contudo, convém notar: a premissa de confiança difere daquela do consenso. Quebras no consenso, como forks, são públicas (confiança fraca), mas a desencriptação prematura de transações por um comité malicioso é invisível e indetetável (confiança forte). Na prática, o risco de colusão em comités pode ser maior do que sugere a teoria.

Encriptação por atraso (time-lock e delay encryption): Alternativamente, pode encriptar-se para uma chave pública cuja privada só está acessível após resolução de um puzzle cryptográfico temporizado. O puzzle só revela o segredo após computação demorada e sequencial, bloqueando desencriptação antes da finalização das transações. O método mais robusto baseia-se em delay encryption pública, podendo ser aproximado por comités de confiança usando time-lock, embora com vantagens questionáveis face à encriptação por limiar.

Seja por atraso computacional ou comité de confiança, surgem desafios práticos. Primeiro, é difícil garantir tempos de desencriptação precisos, dado o atraso não ser determinístico. Segundo, estes sistemas dependem de hardware avançado para resolução eficiente dos puzzles; embora qualquer um possa tentar, não está claro como incentivar estes operadores. Finalmente, nestes modelos, todas as transações emitidas acabam por ser desencriptadas, incluindo as não incluídas em bloco; soluções limiares ou witness encryption poderiam restringir a desencriptação às transações efetivamente incluídas.

Witness encryption: Esta abordagem avançada recorre à witness encryption, permitindo encriptar informação de modo que só quem conheça o testemunho (witness) de uma relação NP a possa desencriptar. Por exemplo, apenas quem resolve determinado Sudoku ou dispõe do preimage de um hash específico.

Os SNARKs também se aplicam a todas as relações NP; podemos pensar no mecanismo como encriptar dados para quem produza um SNARK provando uma condição desejada. Num mempool encriptado, essa condição pode ser que apenas podem ser desencriptadas após finalização do bloco.

Este primitivo é extremamente poderoso do ponto de vista teórico, abrangendo os modelos por comité e atraso como casos particulares. Contudo, não há soluções práticas para witness encryption e, mesmo existindo, não traria melhorias evidentes face ao comité em sistemas proof-of-stake. Mesmo que a desencriptação ocorra apenas após finalização, um comité malicioso pode simular o consenso em privado, finalizar o bloco e usar a cadeia privada como proof para desencriptar. A utilização de desencriptação por limiar pelo mesmo comité assegura segurança semelhante de forma muito mais simples.

O witness encryption revela mais vantagens em protocolos proof-of-work, já que nem um comité totalmente malicioso consegue “minerar em privado” novos blocos para simular finalização.

Desafios técnicos dos mempools encriptados

Os mempools encriptados enfrentam limitações práticas notórias na prevenção do MEV. Proteger informação confidencial é intrinsecamente difícil. De facto, a encriptação é pouco utilizada na web3. Décadas de experiência mostram como é desafiante implementar encriptação na web (TLS/HTTPS) e comunicação privada (do PGP ao Signal ou WhatsApp). A encriptação pode preservar a confidencialidade, mas não a garante por si só.

Para começar, pode haver entidades com acesso direto ao conteúdo original da transação. É comum que o utilizador não encripte, delegando a tarefa ao fornecedor da carteira, que assim detém o texto não encriptado e o pode usar ou vender para extrair MEV. A força da encriptação nunca ultrapassa o círculo de quem tem acesso à chave.

Para além disso, o principal problema reside nos metadados: dados associados à transação encriptada mas não protegidos. Os searchers analisam estes metadados para deduzir a intenção da transação e explorar MEV especulativo. Não precisam compreender toda a transação nem acertar sempre; basta terem um grau razoável de probabilidade — por exemplo, saber que é uma ordem de compra numa determinada DEX.

Podem distinguir-se vários tipos de metadados, alguns desafios clássicos da encriptação e outros específicos do mempool encriptado:

• Tamanho da transação: A encriptação não esconde o tamanho do texto original. (As próprias definições formais de segurança semântica excluem esse objetivo.) Trata-se de um vetor de ataque clássico: por exemplo, é possível detectar em tempo real que filme é transmitido via Netflix com base no tamanho dos pacotes, mesmo encriptados. Em mempools encriptados, certos tipos de transação terão tamanhos caraterísticos que denunciam o seu conteúdo.

• Momento da transmissão: Também não oculta a informação temporal (mais um vetor de ataque clássico). No contexto web3, certos emissores — por exemplo, operações programadas — emitem transações a intervalos regulares. O tempo da transação pode ainda ser correlacionado com atividade em bolsas externas ou notícias. Outra exploração, mais subtil, é a arbitragem CEX/DEX: um sequenciador pode emitir a sua transação o mais tarde possível para aproveitar preços mais recentes e excluir transações (mesmo encriptadas) transmitidas após certo momento, garantindo exclusividade do lucro.

• Endereço IP de origem: Searchers podem inferir a identidade do remetente monitorizando a rede e os IPs de origem. Isto foi identificado há mais de uma década no ecossistema Bitcoin, sendo útil quando remetentes têm padrões reconhecíveis — por exemplo, associando transações encriptadas a outras já desencriptadas.

• Remetente e informações de comissão/gas: Em Ethereum, as transações incluem o endereço de remetente (para pagamento da taxa), o orçamento máximo de gas e o valor por unidade de gas. Estes elementos podem servir para relacionar transações e entidades, ou deduzir a intenção — por exemplo, transações com necessidades muito específicas de gas revelam interações com contratos ou DEXs concretos.

Searchers sofisticados podem combinar estes fatores de metadados para antecipar o conteúdo das transações.

Ocultar toda esta informação é possível, mas implica custos de desempenho e complexidade. Por exemplo, preencher transações até um tamanho padrão esconde o volume, mas desperdiça largura de banda e espaço. Adicionar atrasos à transmissão reduz a previsibilidade temporal, mas prejudica a latência. Recorrer a redes de anonimato, como Tor, esconde o IP, mas tem desafios próprios.

Os metadados mais difíceis de ocultar são os relacionados com as taxas. Encriptar estes dados levanta questões para o construtor. O primeiro problema é o potencial de spam: se o pagamento de taxas for ocultado, qualquer agente pode submeter transações encriptadas inválidas que serão ordenadas mas não executáveis — sem forma de penalização. SNARKs podem demonstrar que a transação é válida e financiada, mas aumentam significativamente a sobrecarga.

O segundo problema é a construção eficiente de blocos e leilões de taxas. Os construtores baseiam-se nas taxas para maximizar lucros e definir o preço dos recursos onchain. Se tal informação for encriptada, o processo é perturbado. Soluções como uma taxa fixa por bloco são ineficazes e criam mercados secundários contrários ao objetivo do mempool encriptado. Usar computação multipartidária segura ou hardware de confiança para gerir o leilão é possível, mas dispendioso.

Além disso, mempools encriptados impõem custos adicionais ao sistema — aumento de latência, exigência computacional e largura de banda. A integração com sharding e execução paralela, objetivos futuros do sector, é um desafio de engenharia. A complexidade adicional pode trazer riscos operacionais e pontos críticos de falha (como o comité de desencriptação ou o resolvedor das funções de atraso).

Grande parte destes problemas são comuns a blockchains focadas na privacidade das transações (ex: Zcash, Monero). A resolução integral dos desafios de encriptação para combater o MEV abriria caminho à privacidade transacional como benefício colateral.

Desafios económicos dos mempools encriptados

Os mempools encriptados enfrentam ainda desafios económicos. Ao contrário das limitações técnicas, mitigáveis com engenharia, estes representam obstáculos de base de difícil solução.

A origem do MEV está na assimetria de informação entre utilizadores, que criam as transações, e searchers/construtores, que detetam oportunidades MEV. Tipicamente, os utilizadores desconhecem o valor potencial do MEV das suas operações. Assim, mesmo com um mempool encriptado perfeito, podem ser tentados a vender as chaves de desencriptação a construtores por montantes inferiores ao real extraível — desencriptação incentivada.

O fenómeno é já observável em modelos como o MEV Share: um leilão de fluxo de ordens em que utilizadores submetem parcialmente a sua informação a um pool, competindo searchers pelo direito de explorar o MEV da transação. O vencedor partilha parte do lucro (lance ou fração) com o utilizador.

Este modelo poderia ser facilmente adaptado a mempools encriptados, bastando os utilizadores revelarem a chave de desencriptação (ou parte dos dados) para participar. Mas a maioria não compreenderá o custo de oportunidade, limitando-se a aceitar o retorno imediato e cedendo a sua informação. O caso é comparável ao modelo tradicional de “payment-for-order-flow”, adotado por plataformas como a Robinhood.

Cenários adicionais incluem construtores de grande escala obrigarem utilizadores a revelar transações (ou metadados) para efeitos de censura. A resiliência à censura é tema recorrente no web3, mas, se grandes construtores estiverem obrigados a listas de censura (como OFAC), podem recusar-se a ordenar transações encriptadas. Poder-se-ia recorrer a provas de conhecimento zero de conformidade, mas tal aumentaria custos e complexidade. Mesmo com resistência à censura, construtores podem priorizar transações em claro, relegando as encriptadas para o final dos blocos — forçando a revelação da sua informação se os utilizadores quiserem garantias de execução.

Outras ineficiências

Mempools encriptados acrescentam sobrecarga de modo claro: os utilizadores encriptam transações, o sistema desencripta. Isso implica custos computacionais e normalmente aumenta o tamanho das transações. Lidar com metadados agrava este impacto. Existem, porém, ineficiências indiretas: em mercados financeiros, a eficiência resulta da total divulgação de informação, e atrasos e assimetrias — inerentes ao mempool encriptado — criam ineficiências.

Uma consequência é a acentuada incerteza de preços resultante do atraso adicional, levando ao aumento de operações falhadas por deslizamento e desperdício de espaço em cadeia.

De igual modo, a incerteza estimula transações MEV especulativas em busca de arbitragem onchain. Com o estado dos DEX desatualizado pela execução atrasada, aumentam os desequilíbrios de preços e as oportunidades de arbitragem, o que prolifera transações MEV especulativas e leva ao desperdício de espaço de bloco por falhas sucessivas.

O objetivo deste artigo é sistematizar os desafios dos mempools encriptados, incentivando a comunidade a desenvolver alternativas, mas não excluindo que possam ser parte da resposta ao MEV.

Uma opção promissora é o design híbrido: parte das transações é ordenada cegamente via mempool encriptado, parte por outras vias. Para ordens de grandes operadores — que podem encriptar e preencher as transações e dispõem de margem para evitar MEV —, o híbrido pode ser a solução certa, aplicando-se também a operações críticas como correções de bugs em contratos vulneráveis.

Contudo, pelas limitações tecnológicas, complexidade e impacto no desempenho, é improvável que o mempool encriptado venha a ser a solução perfeita para o MEV, como por vezes se sugere. A comunidade terá de apostar noutras alternativas — leilões MEV, defesas ao nível da aplicação e redução do tempo de finalização. O desafio do MEV persistirá e será fundamental identificar o melhor equilíbrio possível de soluções.

Pranav Garimidi é investigador na a16z Crypto, dedicado a temas de design de mecanismos e teoria dos jogos aplicada à blockchain, focando incentivos ao longo da camada. Licenciado em Ciência da Computação pela Universidade de Columbia.

Joseph Bonneau é Professor Associado no Departamento de Ciência da Computação do Courant Institute (NYU) e consultor técnico na a16z crypto. Investiga criptografia aplicada e segurança em blockchain, tendo lecionado sobre criptomoedas em Melbourne, NYU, Stanford e Princeton. Doutorado pela Universidade de Cambridge, licenciado e mestre em Stanford.

Lioba Heimbach é doutoranda no quarto ano sob orientação do Prof. Dr. Roger Wattenhofer no grupo Distributed Computing (Disco) da ETH Zurique, centrando-se em protocolos blockchain e DeFi, com o objetivo de promover uma blockchain e um ecossistema DeFi acessíveis, descentralizados, justos e eficientes. Estagiária de investigação na a16z crypto no verão de 2024.

As opiniões expressas são da exclusiva responsabilidade do pessoal da AH Capital Management, L.L.C. (“a16z”) aqui citado e não refletem necessariamente as posições da a16z ou das suas afiliadas. Certos dados constantes do artigo foram obtidos junto de terceiros, incluindo empresas do portefólio de fundos geridos pela a16z. Ainda que as fontes sejam consideradas fidedignas, a a16z não verifica de forma independente nem se responsabiliza pela precisão ou adequação da informação, nem por anúncios de terceiros eventualmente presentes.

Este conteúdo é meramente informativo e não constitui aconselhamento legal, financeiro, fiscal ou de investimento. Consulte os seus próprios consultores para esses efeitos. Qualquer referência a títulos mobiliários ou ativos digitais tem fins ilustrativos, não constituindo uma recomendação de investimento ou proposta de serviços de consultoria. Não se destina a investidores ou potenciais investidores e não pode ser utilizado como base para decisão de investimento em fundos geridos pela a16z. (Qualquer proposta de investimento só será formalizada através do respetivo memorando de colocação privada, acordo de subscrição e documentação associada, a analisar integralmente.) Os investimentos ou empresas aqui mencionados não representam todos os investimentos realizados pela a16z, não havendo garantias de rentabilidade futura ou de semelhança com outros investimentos posteriores. A lista dos investimentos dos fundos geridos pela Andreessen Horowitz (excluindo investimentos ainda não tornados públicos) está disponível em https://a16z.com/investments/.

O conteúdo está atualizado à data da publicação. Quaisquer previsões, estimativas, objetivos ou opiniões expressos podem ser alterados sem aviso e podem divergir de outras opiniões. Consulte https://a16z.com/disclosures para mais informações relevantes.

Aviso legal:

1. Este artigo foi republicado de [a16zcrypto]. Todos os direitos de autor pertencem aos autores originais [Pranav GarimidiJoseph BonneauLioba Heimbach]. Caso existam objeções a esta republicação, contacte a equipa Gate Learn para tratamento célere.
2. Isenção de responsabilidade: As opiniões expressas são da exclusiva responsabilidade do(s) autor(es) e não constituem qualquer aconselhamento de investimento.
3. As traduções para outras línguas são realizadas pela equipa Gate Learn. Salvo indicação em contrário, é expressamente proibida a cópia, distribuição ou plágio dos artigos traduzidos.