Autor | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilado | Saoirse, Foresight News
Na blockchain, o maior valor que pode ser extraído, que se refere à capacidade de lucrar decidindo quais transações são empacotadas em um bloco, quais são excluídas, ou ajustando a ordem das transações, é chamado de "valor máximo extraível", abreviado como MEV. O MEV é comum na maioria das blockchains e tem sido um tema de ampla atenção e discussão na indústria.
Vários pesquisadores, ao observar o fenômeno MEV, levantaram uma questão clara: a tecnologia de criptografia pode resolver esse problema? Uma das soluções é adotar um pool de memórias criptografadas: os usuários transmitem transações criptografadas, que só serão descriptografadas e divulgadas após a ordenação. Assim, o protocolo de consenso deve "selecionar de forma cega" a ordem das transações, o que parece prevenir a exploração de oportunidades de lucro com MEV durante a fase de ordenação.
Mas, infelizmente, tanto do ponto de vista prático quanto teórico, as pools de memória criptografadas não conseguem oferecer uma solução universal para o problema do MEV. Este artigo irá esclarecer as dificuldades envolvidas e explorar direções de design viáveis para as pools de memória criptografadas.
O funcionamento do pool de memória criptografada
Existem várias propostas sobre o pool de memória criptográfica, mas a sua estrutura geral é a seguinte:
O usuário transmite a transação criptografada.
As transações criptográficas são submetidas à cadeia (em algumas propostas, as transações devem primeiro passar por uma embaralhamento aleatório verificável).
Quando os blocos contendo essas transações forem finalmente confirmados, as transações serão descriptografadas.
Por fim, execute essas transações.
É importante notar que há um problema chave no Passo 3 (descriptografia da transação): quem é responsável pela descriptografia? O que acontece se a descriptografia não for concluída? Uma ideia simples é permitir que os usuários descriptografem suas próprias transações (neste caso, nem é necessário criptografar, basta ocultar o compromisso). Mas esse método tem uma falha: atacantes podem implementar MEV especulativo.
Em MEV especulativo, o atacante tenta adivinhar se uma transação de criptomoeda contém uma oportunidade de MEV, em seguida, criptografa sua própria transação e tenta inseri-la em uma posição favorável (por exemplo, antes ou depois da transação alvo). Se as transações forem organizadas na ordem esperada, o atacante irá descriptografar e extrair MEV através de sua própria transação; se não forem, eles se recusarão a descriptografar, e sua transação não será incluída na blockchain final.
Talvez seja possível impor penalidades aos usuários que falharem na decriptação, mas a implementação desse mecanismo é extremamente difícil. A razão para isso é: a severidade das penalidades para todas as transações criptografadas deve ser uniforme (afinal, não é possível distinguir as transações após a criptografia), e as penalidades devem ser severas o suficiente para conter a MEV especulativa, mesmo quando enfrentando alvos de alto valor. Isso pode levar a uma grande quantidade de fundos sendo bloqueada, e esses fundos devem permanecer anônimos (para evitar a divulgação da associação entre transações e usuários). Mais complicado ainda, se um usuário real não conseguir decriptar normalmente devido a falhas de programa ou problemas de rede, eles também sofrerão perdas por causa disso.
Assim, a maioria das propostas sugere que, ao criptografar as transações, deve-se garantir que elas possam ser descriptografadas em algum momento no futuro, mesmo que o usuário que iniciou a transação esteja offline ou se recuse a cooperar. Este objetivo pode ser alcançado de várias maneiras:
Ambientes de Execução Confiáveis (TEEs): Os usuários podem criptografar transações com chaves mantidas em uma zona segura de um Ambiente de Execução Confiável (TEE). Em algumas versões básicas, o TEE é usado apenas para descriptografar transações após um determinado momento (o que exige que o TEE tenha capacidade de percepção temporal). Soluções mais complexas permitem que o TEE seja responsável pela descriptografia das transações e pela construção de blocos, ordenando as transações com base em critérios como o tempo de chegada, taxas, entre outros. Em comparação com outras soluções de mempool criptografadas, a vantagem do TEE é que ele pode processar transações em texto claro diretamente, reduzindo informações redundantes na blockchain ao filtrar transações que seriam revertidas. No entanto, a desvantagem desse método é a dependência da confiabilidade do hardware.
Compartilhamento secreto e criptografia de limiar (Secret-sharing and threshold encryption): Neste esquema, o usuário criptografa a transação até uma determinada chave, que é mantida em conjunto por um comitê específico (geralmente um subconjunto dos validadores). A descriptografia deve atender a certas condições de limiar (por exemplo, a concordância de dois terços dos membros do comitê).
Ao adotar a criptografia de limiar, o portador de confiança passa de hardware para um comitê. Os apoiantes acreditam que, uma vez que a maioria dos protocolos já pressupõe que os validadores possuem a característica de "maioria honesta" nos mecanismos de consenso, também podemos fazer uma suposição semelhante, ou seja, a maioria dos validadores se manterá honesta e não irá decifrar as transações antecipadamente.
No entanto, é importante notar uma diferença crucial: estas duas suposições de confiança não são o mesmo conceito. Falhas de consenso, como bifurcações de blockchain, têm visibilidade pública (pertencem à "supondo de confiança fraca"), enquanto comitês maliciosos que decifram transações antecipadamente em privado não deixam nenhuma evidência pública, esse tipo de ataque não pode ser detectado nem punido (pertencem à "supondo de confiança forte"). Portanto, embora à primeira vista os mecanismos de consenso e as suposições de segurança dos comitês criptográficos pareçam estar alinhados, na prática, a credibilidade da suposição de que "o comitê não irá conspirar" é muito menor.
Bloqueio de tempo e criptografia com atraso (Time-lock and delay encryption): como uma alternativa à criptografia de limiar, o princípio da criptografia com atraso é: o usuário criptografa a transação para uma determinada chave pública, enquanto a chave privada correspondente a essa chave pública está oculta em um enigma de bloqueio de tempo. O enigma de bloqueio de tempo é um quebra-cabeça criptográfico que encapsula um segredo, cujo conteúdo secreto só pode ser revelado após um período de tempo predefinido; mais especificamente, o processo de descriptografia requer a execução repetida de uma série de cálculos que não podem ser paralelizados. Sob este mecanismo, qualquer pessoa pode resolver o enigma para obter a chave e descriptografar a transação, desde que complete um cálculo lento (essencialmente executado de forma sequencial) projetado para levar tempo suficiente, garantindo que a transação não possa ser descriptografada antes da confirmação final. A forma mais forte desse primitivo criptográfico é a geração pública de tais enigmas por meio da tecnologia de criptografia com atraso; também pode ser aproximadamente realizada por meio de um comitê de confiança utilizando criptografia de bloqueio de tempo, embora nesse caso suas vantagens em relação à criptografia de limiar sejam questionáveis.
Quer se trate de criptografia de atraso ou de cálculos executados por um comitê confiável, esses tipos de soluções enfrentam numerosos desafios práticos: primeiro, como o atraso depende essencialmente do processo de cálculo, é difícil garantir a precisão do tempo de descriptografia; em segundo lugar, essas soluções precisam depender de entidades específicas que operam hardware de alto desempenho para resolver eficientemente os quebra-cabeças, embora qualquer pessoa possa assumir esse papel, não está claro como incentivá-las a participar; por fim, em tais designs, todas as transações transmitidas serão descriptografadas, incluindo aquelas que nunca foram finalmente escritas em um bloco. Por outro lado, soluções baseadas em limite (ou criptografia de testemunha) podem apenas descriptografar aquelas transações que foram incluídas com sucesso.
Criptografia de testemunho (Witness encryption): A última e mais avançada solução em criptografia é a utilização da tecnologia de "criptografia de testemunho". Teoricamente, o mecanismo da criptografia de testemunho é: após a criptografia da informação, apenas aqueles que conhecem a "informação de testemunho" correspondente a uma relação NP específica poderão realizar a descriptografia. Por exemplo, a informação pode ser criptografada de forma que apenas quem consegue resolver um quebra-cabeça Sudoku ou fornecer uma imagem original de um hash específico possa completar a descriptografia.
(Nota: A relação NP é a correspondência entre "problema" e "resposta que pode ser verificada rapidamente")
Para qualquer relação NP, é possível implementar uma lógica semelhante através de SNARKs. Pode-se dizer que a criptografia de testemunho é essencialmente a forma de criptografar dados de modo que apenas as entidades que podem provar através de SNARK que satisfazem determinadas condições possam descriptografá-los. Em cenários de pool de memória criptografada, um exemplo típico dessas condições é: as transações só podem ser descriptografadas após a confirmação final do bloco.
Esta é uma teoria original com um grande potencial. Na verdade, é um esquema de generalidade, onde os métodos baseados em comitês e os métodos baseados em atrasos são apenas formas específicas de aplicação. Infelizmente, até agora não temos nenhum esquema criptográfico baseado em testemunhas que possa ser implementado na prática. Além disso, mesmo que existam tais esquemas, é difícil afirmar que eles teriam vantagens sobre os métodos baseados em comitês em uma cadeia de prova de participação. Mesmo configurando a criptografia de testemunhas para "só ser possível decriptar quando a transação é ordenada em blocos finalizados", um comitê malicioso ainda pode simular um protocolo de consenso em particular para falsificar o estado de confirmação final da transação e, em seguida, usar essa cadeia privada como uma "testemunha" para decriptar a transação. Nesse caso, o mesmo comitê poderia usar decriptação por limite, alcançando a mesma segurança e com um processo muito mais simples.
No entanto, na prova de trabalho do protocolo de consenso, as vantagens da criptografia de testemunho são ainda mais evidentes. Porque mesmo que o comitê seja completamente malicioso, não pode minerar vários novos blocos em segredo na cabeça atual da blockchain para falsificar o estado de confirmação final.
Desafios técnicos enfrentados por pools de memória criptográfica
Várias dificuldades práticas limitam a capacidade da memória criptográfica de prevenir o MEV. De modo geral, a confidencialidade da informação é, em si, um desafio. Vale ressaltar que a aplicação de tecnologias de criptografia no campo do Web3 não é ampla, mas as décadas de prática na implementação de tecnologias de criptografia em redes (como TLS/HTTPS) e comunicação privada (de PGP a plataformas modernas de mensagens criptografadas como Signal, WhatsApp, etc.) expuseram amplamente suas dificuldades: a criptografia é uma ferramenta para proteger a confidencialidade, mas não pode garantir proteção absoluta.
Primeiro, certos sujeitos podem obter diretamente as informações em texto claro das transações dos usuários. Em cenários típicos, os usuários geralmente não criptografam as transações por conta própria, mas delegam essa tarefa aos prestadores de serviços de carteira. Assim, os prestadores de serviços de carteira podem acessar o texto claro das transações e até podem usar ou vender essas informações para extrair MEV. A segurança da criptografia depende sempre de todos os sujeitos que podem acessar as chaves. O alcance do controle das chaves é a fronteira da segurança.
Além disso, o maior problema está nos metadados, ou seja, nos dados não criptografados em torno da carga criptográfica (transação). Os buscadores podem usar esses metadados para inferir a intenção da transação e, assim, implementar MEV especulativo. É importante saber que os buscadores não precisam entender completamente o conteúdo da transação, nem precisam acertar todas as vezes. Por exemplo, desde que consigam julgar com uma probabilidade razoável que uma transação é um pedido de compra de uma determinada exchange descentralizada (DEX), isso é suficiente para iniciar um ataque.
Podemos classificar os metadados em várias categorias: uma é os clássicos problemas inerentes à tecnologia de criptografia, e a outra são os problemas específicos da pool de memória criptográfica.
Tamanho da transação: A criptografia em si não pode ocultar o tamanho do texto simples (vale a pena notar que a definição formal de segurança semântica exclui explicitamente a ocultação do tamanho do texto simples). Esta é uma vetor de ataque comum em comunicações criptografadas, um caso típico é que, mesmo após a criptografia, um invasor ainda pode determinar em tempo real o conteúdo que está sendo reproduzido no Netflix, através do tamanho de cada pacote de dados no fluxo de vídeo. Em pools de memória criptografada, tipos específicos de transações podem ter tamanhos únicos, revelando assim informações.
Hora de transmissão: a criptografia também não consegue ocultar informações temporais (este é outro vetor de ataque clássico). No cenário Web3, certos remetentes (como cenários de venda estruturada) podem iniciar transações em intervalos fixos. O tempo da transação também pode estar associado a outras informações, como a atividade de bolsas externas ou eventos de notícias. Uma maneira mais sutil de explorar informações temporais é através da arbitragem entre bolsas centralizadas (CEX) e bolsas descentralizadas (DEX): os ordenadores podem inserir transações criadas o mais tarde possível, aproveitando as informações de preços mais recentes da CEX; ao mesmo tempo, os ordenadores podem excluir todas as outras transações transmitidas após um determinado momento (mesmo que criptografadas), garantindo que suas transações desfrutem da vantagem de preço mais recente.
Endereço IP de origem: Os investigadores podem inferir a identidade do remetente da transação monitorando a rede ponto a ponto e rastreando o endereço IP de origem. Esse problema foi identificado nos primeiros dias do Bitcoin (já se passaram mais de dez anos). Se um remetente específico tiver um padrão de comportamento fixo, isso é extremamente valioso para os investigadores. Por exemplo, ao conhecer a identidade do remetente, é possível correlacionar transações criptografadas com transações históricas já decifradas.
Informações sobre o remetente da transação e taxas / gas: As taxas de transação são um tipo de metadados específico do pool de memória criptográfica. No Ethereum, uma transação tradicional inclui o endereço do remetente na cadeia (para pagamento de taxas), o orçamento máximo de gas e a taxa de gas por unidade que o remetente está disposto a pagar. Semelhante ao endereço da rede de origem, o endereço do remetente pode ser usado para associar várias transações e entidades reais; o orçamento de gas pode sugerir a intenção da transação. Por exemplo, interagir com um DEX específico pode exigir uma quantidade fixa de gas identificável.
Os buscadores complexos podem combinar vários tipos de metadados mencionados acima para prever o conteúdo das transações.
Teoricamente, essas informações podem ser ocultadas, mas isso vem com um custo em desempenho e complexidade. Por exemplo, preencher as transações até um comprimento padrão pode ocultar o tamanho, mas desperdiçará largura de banda e espaço na cadeia; aumentar a latência antes do envio pode ocultar o tempo, mas aumentará a latência; enviar transações através de redes anônimas como o Tor pode ocultar o endereço IP, mas isso traz novos desafios.
A informação de taxas de transação é a metadata mais difícil de esconder. Os dados de taxas de criptomoeda trazem uma série de problemas para os construtores de blocos: primeiro, o problema de informações indesejadas; se os dados de taxas de transação forem criptografados, qualquer pessoa pode transmitir uma transação criptografada com formato incorreto, que, embora seja ordenada, não poderá pagar taxas, e não será executável após a descriptografia, mas ninguém poderá ser responsabilizado. Isso pode ser resolvido através de SNARKs, que provam que o formato da transação está correto e que os fundos são suficientes, mas isso aumentará significativamente os custos.
Em segundo lugar, há o problema da eficiência na construção de blocos e na leilão de taxas. Os construtores dependem das informações sobre taxas para criar blocos que maximizem o lucro e determinar o preço de mercado atual dos recursos na cadeia. Os dados de taxas criptográficas podem prejudicar esse processo. Uma solução é definir uma taxa fixa para cada bloco, mas isso é economicamente ineficiente e pode gerar um mercado secundário de empacotamento de transações, contrariando a intenção original do pool de memórias criptográficas. Outra solução é realizar leilões de taxas por meio de computação multipartidária segura ou hardware confiável, mas ambas as abordagens têm um custo extremamente alto.
Por fim, um pool de memória criptográfica seguro aumentará o custo do sistema de várias maneiras: a criptografia aumentará a latência da cadeia, a carga computacional e o consumo de largura de banda; como se combinará com objetivos futuros importantes, como fragmentação ou execução paralela, ainda não está claro; também pode introduzir novos pontos de falha para a liveness (como comitês de decriptação em esquemas de limiar, solucionadores de funções de atraso); ao mesmo tempo, a complexidade do design e da implementação também aumentará significativamente.
Muitos dos problemas da memória criptográfica estão interligados com os desafios enfrentados por blockchains que visam garantir a privacidade das transações (como Zcash, Monero). Se há um aspecto positivo, é que resolver todos os desafios da tecnologia criptográfica na mitigação de MEV ajudará a eliminar obstáculos para a privacidade das transações.
Desafios econômicos enfrentados pela memória criptográfica
Por fim, o pool de memória criptográfica também enfrenta desafios econômicos. Ao contrário dos desafios técnicos, que podem ser gradualmente mitigados com investimento suficiente em engenharia. Esses desafios econômicos pertencem a limitações fundamentais, cuja resolução é extremamente difícil.
O problema central do MEV decorre da assimetria de informação entre os criadores de transações (usuários) e os mineradores de oportunidades de MEV (pesquisadores e construtores de blocos). Os usuários geralmente não têm clareza sobre quanto valor pode ser extraído de suas transações, e, mesmo que exista um pool de memórias criptográficas perfeito, eles ainda podem ser induzidos a revelar chaves de decriptação em troca de uma recompensa inferior ao valor real do MEV, um fenômeno que pode ser chamado de "decriptação incentivada".
Este cenário não é difícil de imaginar, pois mecanismos semelhantes como o MEV Share já existem na realidade. O MEV Share é um mecanismo de leilão de fluxo de ordens que permite aos usuários submeter informações de transações a um pool de forma seletiva, onde os buscadores competem para obter o direito de explorar oportunidades de MEV dessa transação. O vencedor, após extrair o MEV, devolverá uma parte dos lucros (ou seja, o valor da oferta ou uma certa porcentagem dele) aos usuários.
Este modelo pode ser diretamente adaptado a pools de memória criptográfica: os usuários precisam divulgar a chave de decriptação (ou parte da informação) para participar. Mas a maioria dos usuários não se dá conta do custo de oportunidade de participar desse tipo de mecanismo; eles só veem o retorno imediato e ficam felizes em divulgar informações. No setor financeiro tradicional, há casos semelhantes: por exemplo, a plataforma de negociação sem comissões Robinhood, cujo modelo de lucro é vender o fluxo de ordens dos usuários a terceiros através do "pagamento por fluxo de ordens" (payment-for-order-flow).
Outro possível cenário é que grandes construtores forcem os usuários a divulgar o conteúdo das transações (ou informações relacionadas) sob a justificativa de conformidade. A resistência à censura é um tema importante e controverso no espaço Web3, mas se grandes validadores ou construtores forem legalmente obrigados (como pelas regras do Escritório de Controle de Ativos Estrangeiros dos EUA, OFAC) a aplicar listas de censura, eles podem se recusar a processar qualquer transação de criptomoeda. Do ponto de vista técnico, os usuários podem, em teoria, usar provas de conhecimento zero para comprovar que suas transações de criptomoeda atendem aos requisitos de conformidade, mas isso aumentaria o custo e a complexidade adicionais. Mesmo que a blockchain tenha uma forte resistência à censura (assegurando que as transações de criptomoeda sejam necessariamente incluídas), os construtores ainda podem priorizar transações conhecidas em texto claro na parte frontal do bloco, enquanto colocam transações criptografadas no final. Assim, aqueles que precisam garantir a execução prioritária das transações podem acabar sendo forçados a divulgar o conteúdo aos construtores.
Outros desafios em termos de eficiência
O pool de memória criptográfica aumentará os custos do sistema de várias maneiras evidentes. Os usuários devem criptografar as transações, e o sistema também precisa descriptografá-las de alguma forma, o que aumentará o custo computacional e pode também aumentar o tamanho das transações. Como mencionado anteriormente, lidar com metadados agravará ainda mais esses custos. No entanto, existem também alguns custos de eficiência que não são tão evidentes. No setor financeiro, se os preços conseguem refletir todas as informações disponíveis, o mercado é considerado eficiente; no entanto, atrasos e assimetria de informações podem levar a uma ineficiência do mercado. Este é, de fato, o resultado inevitável do pool de memória criptográfica.
Esse tipo de ineficiência leva a uma consequência direta: o aumento da incerteza de preços, que é um produto direto da introdução de atrasos adicionais na memória da criptomoeda. Assim, as transações que falham devido à superação do limite de tolerância ao deslizamento de preços podem aumentar, desperdiçando assim espaço na cadeia.
Da mesma forma, essa incerteza de preços pode também gerar transações especulativas de MEV, que tentam lucrar com a arbitragem em blockchain. Vale ressaltar que a memória da criptomoeda pode tornar essas oportunidades mais comuns: devido ao atraso na execução, o estado atual das exchanges descentralizadas (DEX) torna-se mais nebuloso, o que provavelmente leva a uma diminuição da eficiência do mercado e a diferenças de preços entre diferentes plataformas de negociação. Essas transações especulativas de MEV também desperdiçam espaço em blocos, pois, uma vez que oportunidades de arbitragem não são descobertas, elas tendem a interromper a execução.
Resumo
O objetivo deste artigo é identificar os desafios enfrentados pelas pools de memória criptográficas, para que as pessoas possam direcionar seus esforços para o desenvolvimento de outras soluções, mas as pools de memória criptográficas ainda podem fazer parte das soluções de governança MEV.
Uma abordagem viável é o design misto: parte das transações é realizada através de um pool de memória criptográfica para implementar a "ordenação cega", enquanto a outra parte utiliza outros esquemas de ordenação. Para tipos específicos de transações (como ordens de compra e venda de grandes participantes do mercado, que têm a capacidade de criptografar cuidadosamente ou preencher transações e estão dispostos a pagar custos mais altos para evitar MEV), o design misto pode ser uma escolha adequada. Para transações altamente sensíveis (como transações de correção em contratos de segurança com vulnerabilidades), esse design também tem significado prático.
No entanto, devido a limitações técnicas, à elevada complexidade dos projetos e aos custos de desempenho, a memória criptográfica pouco provável de se tornar a "solução universal para MEV" que as pessoas esperam. A comunidade precisa desenvolver outras soluções, incluindo leilões de MEV, mecanismos de defesa em camada de aplicação e redução do tempo de confirmação final, entre outros. O MEV continuará a ser um desafio durante algum tempo, e será necessário encontrar um equilíbrio entre várias soluções através de pesquisa aprofundada para lidar com seu impacto negativo.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
a16z: Por que a encriptação do pool de memória é difícil de ser a solução universal para MEV?
Autor | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilado | Saoirse, Foresight News
Na blockchain, o maior valor que pode ser extraído, que se refere à capacidade de lucrar decidindo quais transações são empacotadas em um bloco, quais são excluídas, ou ajustando a ordem das transações, é chamado de "valor máximo extraível", abreviado como MEV. O MEV é comum na maioria das blockchains e tem sido um tema de ampla atenção e discussão na indústria.
Vários pesquisadores, ao observar o fenômeno MEV, levantaram uma questão clara: a tecnologia de criptografia pode resolver esse problema? Uma das soluções é adotar um pool de memórias criptografadas: os usuários transmitem transações criptografadas, que só serão descriptografadas e divulgadas após a ordenação. Assim, o protocolo de consenso deve "selecionar de forma cega" a ordem das transações, o que parece prevenir a exploração de oportunidades de lucro com MEV durante a fase de ordenação.
Mas, infelizmente, tanto do ponto de vista prático quanto teórico, as pools de memória criptografadas não conseguem oferecer uma solução universal para o problema do MEV. Este artigo irá esclarecer as dificuldades envolvidas e explorar direções de design viáveis para as pools de memória criptografadas.
O funcionamento do pool de memória criptografada
Existem várias propostas sobre o pool de memória criptográfica, mas a sua estrutura geral é a seguinte:
O usuário transmite a transação criptografada.
As transações criptográficas são submetidas à cadeia (em algumas propostas, as transações devem primeiro passar por uma embaralhamento aleatório verificável).
Quando os blocos contendo essas transações forem finalmente confirmados, as transações serão descriptografadas.
Por fim, execute essas transações.
É importante notar que há um problema chave no Passo 3 (descriptografia da transação): quem é responsável pela descriptografia? O que acontece se a descriptografia não for concluída? Uma ideia simples é permitir que os usuários descriptografem suas próprias transações (neste caso, nem é necessário criptografar, basta ocultar o compromisso). Mas esse método tem uma falha: atacantes podem implementar MEV especulativo.
Em MEV especulativo, o atacante tenta adivinhar se uma transação de criptomoeda contém uma oportunidade de MEV, em seguida, criptografa sua própria transação e tenta inseri-la em uma posição favorável (por exemplo, antes ou depois da transação alvo). Se as transações forem organizadas na ordem esperada, o atacante irá descriptografar e extrair MEV através de sua própria transação; se não forem, eles se recusarão a descriptografar, e sua transação não será incluída na blockchain final.
Talvez seja possível impor penalidades aos usuários que falharem na decriptação, mas a implementação desse mecanismo é extremamente difícil. A razão para isso é: a severidade das penalidades para todas as transações criptografadas deve ser uniforme (afinal, não é possível distinguir as transações após a criptografia), e as penalidades devem ser severas o suficiente para conter a MEV especulativa, mesmo quando enfrentando alvos de alto valor. Isso pode levar a uma grande quantidade de fundos sendo bloqueada, e esses fundos devem permanecer anônimos (para evitar a divulgação da associação entre transações e usuários). Mais complicado ainda, se um usuário real não conseguir decriptar normalmente devido a falhas de programa ou problemas de rede, eles também sofrerão perdas por causa disso.
Assim, a maioria das propostas sugere que, ao criptografar as transações, deve-se garantir que elas possam ser descriptografadas em algum momento no futuro, mesmo que o usuário que iniciou a transação esteja offline ou se recuse a cooperar. Este objetivo pode ser alcançado de várias maneiras:
Ambientes de Execução Confiáveis (TEEs): Os usuários podem criptografar transações com chaves mantidas em uma zona segura de um Ambiente de Execução Confiável (TEE). Em algumas versões básicas, o TEE é usado apenas para descriptografar transações após um determinado momento (o que exige que o TEE tenha capacidade de percepção temporal). Soluções mais complexas permitem que o TEE seja responsável pela descriptografia das transações e pela construção de blocos, ordenando as transações com base em critérios como o tempo de chegada, taxas, entre outros. Em comparação com outras soluções de mempool criptografadas, a vantagem do TEE é que ele pode processar transações em texto claro diretamente, reduzindo informações redundantes na blockchain ao filtrar transações que seriam revertidas. No entanto, a desvantagem desse método é a dependência da confiabilidade do hardware.
Compartilhamento secreto e criptografia de limiar (Secret-sharing and threshold encryption): Neste esquema, o usuário criptografa a transação até uma determinada chave, que é mantida em conjunto por um comitê específico (geralmente um subconjunto dos validadores). A descriptografia deve atender a certas condições de limiar (por exemplo, a concordância de dois terços dos membros do comitê).
Ao adotar a criptografia de limiar, o portador de confiança passa de hardware para um comitê. Os apoiantes acreditam que, uma vez que a maioria dos protocolos já pressupõe que os validadores possuem a característica de "maioria honesta" nos mecanismos de consenso, também podemos fazer uma suposição semelhante, ou seja, a maioria dos validadores se manterá honesta e não irá decifrar as transações antecipadamente.
No entanto, é importante notar uma diferença crucial: estas duas suposições de confiança não são o mesmo conceito. Falhas de consenso, como bifurcações de blockchain, têm visibilidade pública (pertencem à "supondo de confiança fraca"), enquanto comitês maliciosos que decifram transações antecipadamente em privado não deixam nenhuma evidência pública, esse tipo de ataque não pode ser detectado nem punido (pertencem à "supondo de confiança forte"). Portanto, embora à primeira vista os mecanismos de consenso e as suposições de segurança dos comitês criptográficos pareçam estar alinhados, na prática, a credibilidade da suposição de que "o comitê não irá conspirar" é muito menor.
Bloqueio de tempo e criptografia com atraso (Time-lock and delay encryption): como uma alternativa à criptografia de limiar, o princípio da criptografia com atraso é: o usuário criptografa a transação para uma determinada chave pública, enquanto a chave privada correspondente a essa chave pública está oculta em um enigma de bloqueio de tempo. O enigma de bloqueio de tempo é um quebra-cabeça criptográfico que encapsula um segredo, cujo conteúdo secreto só pode ser revelado após um período de tempo predefinido; mais especificamente, o processo de descriptografia requer a execução repetida de uma série de cálculos que não podem ser paralelizados. Sob este mecanismo, qualquer pessoa pode resolver o enigma para obter a chave e descriptografar a transação, desde que complete um cálculo lento (essencialmente executado de forma sequencial) projetado para levar tempo suficiente, garantindo que a transação não possa ser descriptografada antes da confirmação final. A forma mais forte desse primitivo criptográfico é a geração pública de tais enigmas por meio da tecnologia de criptografia com atraso; também pode ser aproximadamente realizada por meio de um comitê de confiança utilizando criptografia de bloqueio de tempo, embora nesse caso suas vantagens em relação à criptografia de limiar sejam questionáveis.
Quer se trate de criptografia de atraso ou de cálculos executados por um comitê confiável, esses tipos de soluções enfrentam numerosos desafios práticos: primeiro, como o atraso depende essencialmente do processo de cálculo, é difícil garantir a precisão do tempo de descriptografia; em segundo lugar, essas soluções precisam depender de entidades específicas que operam hardware de alto desempenho para resolver eficientemente os quebra-cabeças, embora qualquer pessoa possa assumir esse papel, não está claro como incentivá-las a participar; por fim, em tais designs, todas as transações transmitidas serão descriptografadas, incluindo aquelas que nunca foram finalmente escritas em um bloco. Por outro lado, soluções baseadas em limite (ou criptografia de testemunha) podem apenas descriptografar aquelas transações que foram incluídas com sucesso.
Criptografia de testemunho (Witness encryption): A última e mais avançada solução em criptografia é a utilização da tecnologia de "criptografia de testemunho". Teoricamente, o mecanismo da criptografia de testemunho é: após a criptografia da informação, apenas aqueles que conhecem a "informação de testemunho" correspondente a uma relação NP específica poderão realizar a descriptografia. Por exemplo, a informação pode ser criptografada de forma que apenas quem consegue resolver um quebra-cabeça Sudoku ou fornecer uma imagem original de um hash específico possa completar a descriptografia.
(Nota: A relação NP é a correspondência entre "problema" e "resposta que pode ser verificada rapidamente")
Para qualquer relação NP, é possível implementar uma lógica semelhante através de SNARKs. Pode-se dizer que a criptografia de testemunho é essencialmente a forma de criptografar dados de modo que apenas as entidades que podem provar através de SNARK que satisfazem determinadas condições possam descriptografá-los. Em cenários de pool de memória criptografada, um exemplo típico dessas condições é: as transações só podem ser descriptografadas após a confirmação final do bloco.
Esta é uma teoria original com um grande potencial. Na verdade, é um esquema de generalidade, onde os métodos baseados em comitês e os métodos baseados em atrasos são apenas formas específicas de aplicação. Infelizmente, até agora não temos nenhum esquema criptográfico baseado em testemunhas que possa ser implementado na prática. Além disso, mesmo que existam tais esquemas, é difícil afirmar que eles teriam vantagens sobre os métodos baseados em comitês em uma cadeia de prova de participação. Mesmo configurando a criptografia de testemunhas para "só ser possível decriptar quando a transação é ordenada em blocos finalizados", um comitê malicioso ainda pode simular um protocolo de consenso em particular para falsificar o estado de confirmação final da transação e, em seguida, usar essa cadeia privada como uma "testemunha" para decriptar a transação. Nesse caso, o mesmo comitê poderia usar decriptação por limite, alcançando a mesma segurança e com um processo muito mais simples.
No entanto, na prova de trabalho do protocolo de consenso, as vantagens da criptografia de testemunho são ainda mais evidentes. Porque mesmo que o comitê seja completamente malicioso, não pode minerar vários novos blocos em segredo na cabeça atual da blockchain para falsificar o estado de confirmação final.
Desafios técnicos enfrentados por pools de memória criptográfica
Várias dificuldades práticas limitam a capacidade da memória criptográfica de prevenir o MEV. De modo geral, a confidencialidade da informação é, em si, um desafio. Vale ressaltar que a aplicação de tecnologias de criptografia no campo do Web3 não é ampla, mas as décadas de prática na implementação de tecnologias de criptografia em redes (como TLS/HTTPS) e comunicação privada (de PGP a plataformas modernas de mensagens criptografadas como Signal, WhatsApp, etc.) expuseram amplamente suas dificuldades: a criptografia é uma ferramenta para proteger a confidencialidade, mas não pode garantir proteção absoluta.
Primeiro, certos sujeitos podem obter diretamente as informações em texto claro das transações dos usuários. Em cenários típicos, os usuários geralmente não criptografam as transações por conta própria, mas delegam essa tarefa aos prestadores de serviços de carteira. Assim, os prestadores de serviços de carteira podem acessar o texto claro das transações e até podem usar ou vender essas informações para extrair MEV. A segurança da criptografia depende sempre de todos os sujeitos que podem acessar as chaves. O alcance do controle das chaves é a fronteira da segurança.
Além disso, o maior problema está nos metadados, ou seja, nos dados não criptografados em torno da carga criptográfica (transação). Os buscadores podem usar esses metadados para inferir a intenção da transação e, assim, implementar MEV especulativo. É importante saber que os buscadores não precisam entender completamente o conteúdo da transação, nem precisam acertar todas as vezes. Por exemplo, desde que consigam julgar com uma probabilidade razoável que uma transação é um pedido de compra de uma determinada exchange descentralizada (DEX), isso é suficiente para iniciar um ataque.
Podemos classificar os metadados em várias categorias: uma é os clássicos problemas inerentes à tecnologia de criptografia, e a outra são os problemas específicos da pool de memória criptográfica.
Tamanho da transação: A criptografia em si não pode ocultar o tamanho do texto simples (vale a pena notar que a definição formal de segurança semântica exclui explicitamente a ocultação do tamanho do texto simples). Esta é uma vetor de ataque comum em comunicações criptografadas, um caso típico é que, mesmo após a criptografia, um invasor ainda pode determinar em tempo real o conteúdo que está sendo reproduzido no Netflix, através do tamanho de cada pacote de dados no fluxo de vídeo. Em pools de memória criptografada, tipos específicos de transações podem ter tamanhos únicos, revelando assim informações.
Hora de transmissão: a criptografia também não consegue ocultar informações temporais (este é outro vetor de ataque clássico). No cenário Web3, certos remetentes (como cenários de venda estruturada) podem iniciar transações em intervalos fixos. O tempo da transação também pode estar associado a outras informações, como a atividade de bolsas externas ou eventos de notícias. Uma maneira mais sutil de explorar informações temporais é através da arbitragem entre bolsas centralizadas (CEX) e bolsas descentralizadas (DEX): os ordenadores podem inserir transações criadas o mais tarde possível, aproveitando as informações de preços mais recentes da CEX; ao mesmo tempo, os ordenadores podem excluir todas as outras transações transmitidas após um determinado momento (mesmo que criptografadas), garantindo que suas transações desfrutem da vantagem de preço mais recente.
Endereço IP de origem: Os investigadores podem inferir a identidade do remetente da transação monitorando a rede ponto a ponto e rastreando o endereço IP de origem. Esse problema foi identificado nos primeiros dias do Bitcoin (já se passaram mais de dez anos). Se um remetente específico tiver um padrão de comportamento fixo, isso é extremamente valioso para os investigadores. Por exemplo, ao conhecer a identidade do remetente, é possível correlacionar transações criptografadas com transações históricas já decifradas.
Informações sobre o remetente da transação e taxas / gas: As taxas de transação são um tipo de metadados específico do pool de memória criptográfica. No Ethereum, uma transação tradicional inclui o endereço do remetente na cadeia (para pagamento de taxas), o orçamento máximo de gas e a taxa de gas por unidade que o remetente está disposto a pagar. Semelhante ao endereço da rede de origem, o endereço do remetente pode ser usado para associar várias transações e entidades reais; o orçamento de gas pode sugerir a intenção da transação. Por exemplo, interagir com um DEX específico pode exigir uma quantidade fixa de gas identificável.
Os buscadores complexos podem combinar vários tipos de metadados mencionados acima para prever o conteúdo das transações.
Teoricamente, essas informações podem ser ocultadas, mas isso vem com um custo em desempenho e complexidade. Por exemplo, preencher as transações até um comprimento padrão pode ocultar o tamanho, mas desperdiçará largura de banda e espaço na cadeia; aumentar a latência antes do envio pode ocultar o tempo, mas aumentará a latência; enviar transações através de redes anônimas como o Tor pode ocultar o endereço IP, mas isso traz novos desafios.
A informação de taxas de transação é a metadata mais difícil de esconder. Os dados de taxas de criptomoeda trazem uma série de problemas para os construtores de blocos: primeiro, o problema de informações indesejadas; se os dados de taxas de transação forem criptografados, qualquer pessoa pode transmitir uma transação criptografada com formato incorreto, que, embora seja ordenada, não poderá pagar taxas, e não será executável após a descriptografia, mas ninguém poderá ser responsabilizado. Isso pode ser resolvido através de SNARKs, que provam que o formato da transação está correto e que os fundos são suficientes, mas isso aumentará significativamente os custos.
Em segundo lugar, há o problema da eficiência na construção de blocos e na leilão de taxas. Os construtores dependem das informações sobre taxas para criar blocos que maximizem o lucro e determinar o preço de mercado atual dos recursos na cadeia. Os dados de taxas criptográficas podem prejudicar esse processo. Uma solução é definir uma taxa fixa para cada bloco, mas isso é economicamente ineficiente e pode gerar um mercado secundário de empacotamento de transações, contrariando a intenção original do pool de memórias criptográficas. Outra solução é realizar leilões de taxas por meio de computação multipartidária segura ou hardware confiável, mas ambas as abordagens têm um custo extremamente alto.
Por fim, um pool de memória criptográfica seguro aumentará o custo do sistema de várias maneiras: a criptografia aumentará a latência da cadeia, a carga computacional e o consumo de largura de banda; como se combinará com objetivos futuros importantes, como fragmentação ou execução paralela, ainda não está claro; também pode introduzir novos pontos de falha para a liveness (como comitês de decriptação em esquemas de limiar, solucionadores de funções de atraso); ao mesmo tempo, a complexidade do design e da implementação também aumentará significativamente.
Muitos dos problemas da memória criptográfica estão interligados com os desafios enfrentados por blockchains que visam garantir a privacidade das transações (como Zcash, Monero). Se há um aspecto positivo, é que resolver todos os desafios da tecnologia criptográfica na mitigação de MEV ajudará a eliminar obstáculos para a privacidade das transações.
Desafios econômicos enfrentados pela memória criptográfica
Por fim, o pool de memória criptográfica também enfrenta desafios econômicos. Ao contrário dos desafios técnicos, que podem ser gradualmente mitigados com investimento suficiente em engenharia. Esses desafios econômicos pertencem a limitações fundamentais, cuja resolução é extremamente difícil.
O problema central do MEV decorre da assimetria de informação entre os criadores de transações (usuários) e os mineradores de oportunidades de MEV (pesquisadores e construtores de blocos). Os usuários geralmente não têm clareza sobre quanto valor pode ser extraído de suas transações, e, mesmo que exista um pool de memórias criptográficas perfeito, eles ainda podem ser induzidos a revelar chaves de decriptação em troca de uma recompensa inferior ao valor real do MEV, um fenômeno que pode ser chamado de "decriptação incentivada".
Este cenário não é difícil de imaginar, pois mecanismos semelhantes como o MEV Share já existem na realidade. O MEV Share é um mecanismo de leilão de fluxo de ordens que permite aos usuários submeter informações de transações a um pool de forma seletiva, onde os buscadores competem para obter o direito de explorar oportunidades de MEV dessa transação. O vencedor, após extrair o MEV, devolverá uma parte dos lucros (ou seja, o valor da oferta ou uma certa porcentagem dele) aos usuários.
Este modelo pode ser diretamente adaptado a pools de memória criptográfica: os usuários precisam divulgar a chave de decriptação (ou parte da informação) para participar. Mas a maioria dos usuários não se dá conta do custo de oportunidade de participar desse tipo de mecanismo; eles só veem o retorno imediato e ficam felizes em divulgar informações. No setor financeiro tradicional, há casos semelhantes: por exemplo, a plataforma de negociação sem comissões Robinhood, cujo modelo de lucro é vender o fluxo de ordens dos usuários a terceiros através do "pagamento por fluxo de ordens" (payment-for-order-flow).
Outro possível cenário é que grandes construtores forcem os usuários a divulgar o conteúdo das transações (ou informações relacionadas) sob a justificativa de conformidade. A resistência à censura é um tema importante e controverso no espaço Web3, mas se grandes validadores ou construtores forem legalmente obrigados (como pelas regras do Escritório de Controle de Ativos Estrangeiros dos EUA, OFAC) a aplicar listas de censura, eles podem se recusar a processar qualquer transação de criptomoeda. Do ponto de vista técnico, os usuários podem, em teoria, usar provas de conhecimento zero para comprovar que suas transações de criptomoeda atendem aos requisitos de conformidade, mas isso aumentaria o custo e a complexidade adicionais. Mesmo que a blockchain tenha uma forte resistência à censura (assegurando que as transações de criptomoeda sejam necessariamente incluídas), os construtores ainda podem priorizar transações conhecidas em texto claro na parte frontal do bloco, enquanto colocam transações criptografadas no final. Assim, aqueles que precisam garantir a execução prioritária das transações podem acabar sendo forçados a divulgar o conteúdo aos construtores.
Outros desafios em termos de eficiência
O pool de memória criptográfica aumentará os custos do sistema de várias maneiras evidentes. Os usuários devem criptografar as transações, e o sistema também precisa descriptografá-las de alguma forma, o que aumentará o custo computacional e pode também aumentar o tamanho das transações. Como mencionado anteriormente, lidar com metadados agravará ainda mais esses custos. No entanto, existem também alguns custos de eficiência que não são tão evidentes. No setor financeiro, se os preços conseguem refletir todas as informações disponíveis, o mercado é considerado eficiente; no entanto, atrasos e assimetria de informações podem levar a uma ineficiência do mercado. Este é, de fato, o resultado inevitável do pool de memória criptográfica.
Esse tipo de ineficiência leva a uma consequência direta: o aumento da incerteza de preços, que é um produto direto da introdução de atrasos adicionais na memória da criptomoeda. Assim, as transações que falham devido à superação do limite de tolerância ao deslizamento de preços podem aumentar, desperdiçando assim espaço na cadeia.
Da mesma forma, essa incerteza de preços pode também gerar transações especulativas de MEV, que tentam lucrar com a arbitragem em blockchain. Vale ressaltar que a memória da criptomoeda pode tornar essas oportunidades mais comuns: devido ao atraso na execução, o estado atual das exchanges descentralizadas (DEX) torna-se mais nebuloso, o que provavelmente leva a uma diminuição da eficiência do mercado e a diferenças de preços entre diferentes plataformas de negociação. Essas transações especulativas de MEV também desperdiçam espaço em blocos, pois, uma vez que oportunidades de arbitragem não são descobertas, elas tendem a interromper a execução.
Resumo
O objetivo deste artigo é identificar os desafios enfrentados pelas pools de memória criptográficas, para que as pessoas possam direcionar seus esforços para o desenvolvimento de outras soluções, mas as pools de memória criptográficas ainda podem fazer parte das soluções de governança MEV.
Uma abordagem viável é o design misto: parte das transações é realizada através de um pool de memória criptográfica para implementar a "ordenação cega", enquanto a outra parte utiliza outros esquemas de ordenação. Para tipos específicos de transações (como ordens de compra e venda de grandes participantes do mercado, que têm a capacidade de criptografar cuidadosamente ou preencher transações e estão dispostos a pagar custos mais altos para evitar MEV), o design misto pode ser uma escolha adequada. Para transações altamente sensíveis (como transações de correção em contratos de segurança com vulnerabilidades), esse design também tem significado prático.
No entanto, devido a limitações técnicas, à elevada complexidade dos projetos e aos custos de desempenho, a memória criptográfica pouco provável de se tornar a "solução universal para MEV" que as pessoas esperam. A comunidade precisa desenvolver outras soluções, incluindo leilões de MEV, mecanismos de defesa em camada de aplicação e redução do tempo de confirmação final, entre outros. O MEV continuará a ser um desafio durante algum tempo, e será necessário encontrar um equilíbrio entre várias soluções através de pesquisa aprofundada para lidar com seu impacto negativo.