a16z: Por que a encriptação pool de memória é uma solução universal difícil para MEV?

Tecnologia, economia, eficiência: três montanhas que não podemos evitar.

Escrito por: Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z

Compilação: Saoirse, Foresight News

Na blockchain, o ato de ganhar dinheiro decidindo quais transações são incluídas em um bloco, quais são excluídas ou ajustando a ordem das transações é conhecido como "valor máximo extraível", abreviado como MEV. O MEV está amplamente presente na maioria das blockchains e tem sido um tópico amplamente discutido na indústria.

Nota: Este artigo pressupõe que os leitores têm um entendimento básico sobre MEV. Alguns leitores podem primeiro ler o nosso artigo de divulgação sobre MEV*.*

Muitos 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 descompactadas e reveladas após a conclusão da ordenação. Assim, o protocolo de consenso deve "selecionar cegamente" a ordem das transações, o que parece impedir a obtenção de lucros por meio de oportunidades MEV na fase de ordenação.

Mas, infelizmente, tanto do ponto de vista da aplicação prática quanto teórica, os pools de memória criptográfica não conseguem fornecer uma solução universal para o problema MEV. Este artigo irá expor as dificuldades envolvidas e explorar direções de design viáveis para os pools de memória criptográfica.

Como funciona o pool de memória criptografada

Existem muitas propostas sobre o pool de memória criptográfica, mas sua estrutura geral é a seguinte:

  1. O usuário transmite a transação criptografada.
  2. As transações de criptomoeda são submetidas à blockchain (em algumas propostas, as transações devem passar primeiro por um embaralhamento aleatório verificável).
  3. Quando os blocos que contêm estas transações forem finalmente confirmados, as transações serão descriptografadas.
  4. Por fim, execute estas transações.

É importante notar que há um problema crucial 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 mesmo seria necessário criptografar, apenas ocultar o compromisso). Mas essa abordagem tem vulnerabilidades: atacantes podem implementar MEV especulativo.

No MEV especulativo, o atacante tenta adivinhar se uma determinada transação em criptomoeda contém oportunidades 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 estiverem ordenadas conforme o esperado, o atacante irá descriptografar e extrair MEV por meio de sua própria transação; se não estiverem conforme o esperado, eles se recusarão a descriptografar, e sua transação não será incluída na blockchain final.

Talvez se possa impor penalizações aos usuários que falham na descriptografia, mas a implementação desse mecanismo é extremamente difícil. A razão é que: a severidade da penalização para todas as transações criptografadas deve ser uniforme (afinal, após a criptografia, não é possível distinguir as transações), e a penalização deve ser suficientemente severa para conter a MEV especulativa, mesmo quando se trata de alvos de alto valor. Isso pode resultar em grandes quantidades de fundos sendo bloqueadas, e esses fundos devem manter a anonimidade (para evitar a divulgação da associação entre as transações e os usuários). Mais complicado ainda, se devido a falhas no programa ou na rede, usuários reais não conseguirem descriptografar normalmente, eles também sofrerão perdas.

Portanto, a maioria das propostas sugere que, ao criptografar uma transação, deve-se garantir que ela possa ser descriptografada 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 zonas seguras de ambientes de execução confiáveis (TEE). Em algumas versões básicas, o TEE é utilizado apenas para descriptografar transações após um determinado ponto no tempo (o que requer que o TEE tenha capacidade de percepção de tempo). Soluções mais complexas permitem que o TEE seja responsável por descriptografar transações e construir blocos, ordenando as transações com base em critérios como hora de chegada e taxas. Em comparação com outras soluções de memórias criptografadas, a vantagem do TEE é a capacidade de lidar diretamente com transações em texto claro, reduzindo informações redundantes na cadeia ao filtrar transações que seriam revertidas. No entanto, a desvantagem desse método é a dependência da confiabilidade do hardware.

Partilha de segredos e criptografia de limiar (Secret-sharing and threshold encryption): Neste esquema, o utilizador cifra a transação até uma determinada chave, que é detida em conjunto por um comitê específico (geralmente um subconjunto de validadores). A descriptografia requer o cumprimento de certas condições de limiar (por exemplo, dois terços dos membros do comitê devem concordar).

Ao adotar a criptografia de limiar, o vetor de confiança passa de hardware para um comitê. Os apoiantes argumentam que, uma vez que a maioria dos protocolos já pressupõe que os validadores possuem a característica de "maioria honesta" no mecanismo de consenso, também podemos fazer uma suposição semelhante, ou seja, que a maioria dos validadores permanecerá honesta e não irá decifrar transações antecipadamente.

No entanto, é importante notar uma diferença chave: essas 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 em particular não deixam qualquer 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 consistentes, na prática, a credibilidade da suposição de que "os comitês não conspirarão" é muito menor.

Bloqueio de Tempo e Criptografia com Atraso (Time-lock and delay encryption): Como uma alternativa à criptografia de limite, 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 tipo de enigma criptográfico que encapsula um segredo, cujo conteúdo secreto só pode ser revelado após um tempo pré-estabelecido; 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 esse mecanismo, qualquer um pode resolver o enigma para obter a chave e descriptografar a transação, desde que complete um cálculo lento (essencialmente executado em série) projetado para levar um tempo suficientemente longo, garantindo que a transação não possa ser descriptografada antes da confirmação final. A forma mais forte desse primitivo criptográfico é gerar publicamente tais enigmas através da tecnologia de criptografia com atraso; também pode ser aproximadamente realizado através de um comitê de confiança utilizando criptografia com bloqueio de tempo, embora a essa altura a vantagem relativa sobre a criptografia de limite já seja discutível.

Quer seja através de criptografia de atraso ou cálculos executados por um comitê de confiança, esses tipos de soluções enfrentam muitos desafios práticos: em primeiro lugar, como o atraso depende essencialmente do processo de cálculo, é difícil garantir a precisão do tempo de decodificação; em segundo lugar, essas soluções dependem de entidades específicas para operar hardware de alto desempenho para resolver eficientemente os problemas, embora qualquer pessoa possa assumir esse papel, ainda não está claro como incentivar essa entidade a participar; finalmente, nesses tipos de designs, todas as transações transmitidas serão decifradas, incluindo aquelas que nunca foram finalmente escritas em blocos. Por outro lado, soluções baseadas em limite (ou criptografia de testemunho) podem decifrar apenas as transações que foram efetivamente incluídas.

Witness encryption: A final and advanced cryptographic scheme employs "witness encryption" technology. Theoretically, the mechanism of witness encryption is as follows: after information is encrypted, only those who know the specific NP relationship corresponding to the "witness information" can decrypt it. For example, information can be encrypted such that only those who can solve a particular Sudoku puzzle, or provide a specific numerical hash preimage, can complete the decryption.

(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 testemunhos é essencialmente a forma de criptografar dados de modo que apenas os sujeitos que podem provar através de SNARK que satisfazem determinadas condições possam descriptografá-los. Em um cenário 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 grande potencial. Na verdade, é um esquema de versatilidade, onde tanto o método baseado em comitês quanto o método baseado em atrasos são apenas formas específicas de aplicação. Infelizmente, atualmente não temos nenhum esquema criptográfico baseado em testemunhas que possa ser implementado na prática. Além disso, mesmo que existisse tal esquema, é difícil afirmar que ele teria vantagens sobre o método baseado em comitês em uma cadeia de proof-of-stake. Mesmo que a criptografia testemunhal seja configurada para "apenas quando a transação for ordenada em um bloco finalizado é que poderá ser descriptografada", um comitê malicioso ainda pode simular o protocolo de consenso em particular para falsificar o estado de confirmação final da transação, e então usar esta cadeia privada como um "testemunho" para descriptografar a transação. Neste caso, o mesmo comitê pode utilizar a descriptografia por limiar, alcançando a mesma segurança e sendo muito mais simples de operar.

No entanto, nas provas de trabalho dos protocolos de consenso, as vantagens da criptografia de testemunhas são ainda mais evidentes. Porque mesmo que o comitê seja completamente malicioso, não pode minerar vários novos blocos em segredo no topo da blockchain atual para falsificar o estado de confirmação final.

Desafios técnicos enfrentados pelas memórias criptografadas

Vários desafios práticos limitam a capacidade dos pools de memória criptográfica em prevenir o MEV. De maneira geral, a confidencialidade da informação é, por si só, um problema difícil. É importante notar que a aplicação de tecnologias criptográficas no espaço Web3 não é ampla, mas as décadas de prática em implantar tecnologias criptográficas em redes (como TLS/HTTPS) e comunicações privadas (de PGP a Signal, WhatsApp e outras plataformas de mensagens criptografadas modernas) expuseram plenamente as dificuldades: a criptografia é uma ferramenta para proteger a confidencialidade, mas não pode garantir proteção absoluta.

Primeiro, algumas entidades 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 suas transações por conta própria, mas delegam essa tarefa a provedores de serviços de carteira. Dessa forma, os provedores de serviços de carteira conseguem acessar o texto claro das transações e podem até usar ou vender essas informações para extrair MEV. A segurança da criptografia depende sempre de todos os sujeitos que têm acesso às chaves. O alcance do controle das chaves é a fronteira da segurança.

Além disso, o maior problema reside nos metadados, ou seja, os dados não criptografados que cercam a carga útil criptográfica (transações). Os buscadores podem usar esses metadados para inferir a intenção da transação e, assim, implementar MEV especulativo. É importante notar que os buscadores não precisam entender completamente o conteúdo da transação, nem precisam acertar todas as vezes. Por exemplo, desde que possam avaliar 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 dividir os metadados em várias categorias: uma categoria consiste em problemas clássicos inerentes à tecnologia de criptografia, enquanto a outra categoria abrange problemas específicos do pool de memórias criptográficas.

  • Tamanho da transação: A criptografia em si não pode ocultar o tamanho do texto claro (é importante notar que a definição formal de segurança semântica exclui explicitamente a ocultação do tamanho do texto claro). Este é um vetor de ataque comum em comunicações criptografadas, onde um exemplo típico é que, mesmo após a criptografia, um espião ainda pode determinar em tempo real o conteúdo que está a ser reproduzido no Netflix através do tamanho de cada pacote de dados no fluxo de vídeo. Em um pool de memória criptografada, tipos específicos de transações podem ter tamanhos únicos, revelando assim informações.
  • Tempo de Broadcast: A criptografia também não pode ocultar informações temporais (este é outro vetor de ataque clássico). No cenário Web3, certos remetentes (como em cenários de venda estruturada) podem iniciar transações em intervalos fixos. O tempo das transações também pode estar associado a outras informações, como atividades de exchanges externas ou eventos de notícias. Uma forma mais sutil de exploração de informações temporais é a arbitragem entre exchanges centralizadas (CEX) e exchanges descentralizadas (DEX): o ordenante pode inserir transações criadas o mais tarde possível, aproveitando as informações de preços mais recentes da CEX; ao mesmo tempo, o ordenante pode excluir todas as outras transações que foram transmitidas após um determinado ponto no tempo (mesmo que criptografadas), garantindo que sua transação desfrute exclusivamente da vantagem do preço mais recente.
  • Endereço IP de origem: Os investigadores podem inferir a identidade do remetente da transação monitorizando redes ponto a ponto e rastreando o endereço IP de origem. Este 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 saber a identidade do remetente, é possível correlacionar transações criptográficas 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 metadado exclusivo do pool de memórias criptográficas. No Ethereum, as transações tradicionais incluem o endereço do remetente na cadeia (para pagamento de taxas), o orçamento máximo de gas e a taxa de gas que o remetente está disposto a pagar por unidade. 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 de 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 também aumentará a latência; submeter 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 sobre as taxas de transação é a meta-informação mais difícil de esconder. Os dados de taxas de criptomoedas trazem uma série de problemas para os construtores de blocos: em primeiro lugar, o problema de informações lixo, se os dados de taxas de transação forem criptografados, qualquer pessoa pode transmitir transações criptografadas com formato incorreto, estas transações podem ser ordenadas, mas não podem pagar taxas; uma vez descriptografadas, não podem ser executadas e ninguém pode ser responsabilizado. Isto pode ser resolvido através de SNARKs, que provam que o formato da transação é correto e que os fundos são suficientes, mas isso aumentaria significativamente os custos.

Em segundo lugar, está a questão da eficiência na construção de blocos e leilão de taxas. Os construtores dependem das informações de taxas para criar blocos que maximizam o lucro e determinam o preço de mercado atual dos recursos na cadeia. Os dados de taxas criptográficas comprometem esse processo. Uma solução seria definir uma taxa fixa para cada bloco, mas isso é economicamente ineficiente e pode gerar um mercado secundário para a empacotamento de transações, contrariando a intenção original do pool de memórias criptográficas. Outra solução é realizar leilões de taxas através de computação multipartidária segura ou hardware confiável, mas ambas as abordagens têm custos extremamente altos.

Por fim, um pool de memória criptografada seguro aumentará os custos 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 isso se combina com metas futuras 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 descriptografia em esquemas de limiar, solucionadores de funções de atraso); ao mesmo tempo, a complexidade de design e implementação também aumentará significativamente.

Muitos dos problemas da memória criptográfica estão relacionados aos desafios enfrentados pelas 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, também abrirá caminho para a privacidade das transações.

Desafios econômicos enfrentados pela memória criptográfica

Finalmente, a pool de memória criptográfica enfrenta desafios a nível económico. Ao contrário dos desafios tecnológicos, que podem ser gradualmente mitigados com investimento suficiente em engenharia, esses desafios económicos são limitações fundamentais e a sua resolução é extremamente difícil.

O problema central do MEV decorre da assimetria de informações entre os criadores de transações (usuários) e os mineradores de oportunidades MEV (pesquisadores e construtores de blocos). Os usuários geralmente não têm clareza sobre quanto valor extraível está implícito em suas transações, portanto, mesmo na presença de uma pool de memórias criptográficas perfeita, podem ser induzidos a divulgar chaves de decriptação em troca de uma recompensa abaixo do valor real do MEV, um fenômeno que pode ser denominado "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, e os buscadores competem para obter o direito de explorar as oportunidades de MEV dessa transação. O vencedor, após extrair o MEV, devolve uma parte dos lucros (ou seja, o montante da licitação ou uma certa proporção dele) aos usuários.

Este modo pode ser diretamente adaptado à memória criptografada: os usuários precisam divulgar a chave de decodificação (ou parte da informação) para participar. Mas a maioria dos usuários não percebe o custo de oportunidade de participar de tais mecanismos, eles apenas veem o retorno imediato e ficam felizes em vazar informações. Há casos semelhantes nas finanças tradicionais: por exemplo, a plataforma de negociação sem comissões Robinhood, cujo modelo de lucro é vender o fluxo de pedidos dos usuários a terceiros através do "pagamento pelo fluxo de pedidos" (payment-for-order-flow).

Outro cenário possível é: grandes construtores forçam os usuários a divulgar o conteúdo das transações (ou informações relacionadas) sob o pretexto de revisão. A resistência à censura é um tópico importante e controverso no campo do 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 cumprir uma lista de revisão, eles podem se recusar a processar qualquer transação em criptomoeda. Do ponto de vista técnico, os usuários podem, em teoria, usar provas de conhecimento zero para confirmar que suas transações em criptomoeda estão em conformidade com os requisitos de revisão, mas isso aumentaria o custo e a complexidade adicionalmente. Mesmo que a blockchain apresente uma forte resistência à censura (garantindo que transações em criptomoeda sejam necessariamente incluídas), os construtores ainda podem optar por priorizar transações com texto claro conhecido na frente do bloco, enquanto colocam transações criptografadas no final. Portanto, aqueles que precisam garantir a execução de transações prioritárias 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á o custo do sistema de várias maneiras evidentes. Os usuários precisam criptografar as transações, e o sistema também precisa descriptografá-las de alguma forma, o que aumentará o custo computacional e poderá aumentar o tamanho das transações. Como mencionado anteriormente, o processamento de metadados agravará ainda mais esses custos. No entanto, existem alguns custos de eficiência que não são tão evidentes. No setor financeiro, se os preços puderem refletir todas as informações disponíveis, o mercado é considerado eficiente; enquanto os atrasos e a assimetria da informação podem levar a ineficiências de 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 dos preços, que é um produto direto dos atrasos adicionais introduzidos pelo pool de memórias criptográficas. Assim, as transações que falham devido ao excesso da tolerância ao deslizamento de preços podem aumentar, resultando em um desperdício de espaço na cadeia.

Da mesma forma, essa incerteza de preços pode também gerar transações MEV especulativas, que tentam lucrar com a arbitragem em blockchain. Vale a pena notar que o pool de memórias criptográficas pode tornar essas oportunidades mais comuns: devido ao atraso na execução, o estado atual das exchanges descentralizadas (DEX) se torna mais nebuloso, o que provavelmente leva a uma diminuição da eficiência do mercado e à ocorrência de disparidades de preços entre diferentes plataformas de negociação. Essas transações MEV especulativas também desperdiçam espaço em bloco, pois, uma vez que as oportunidades de arbitragem não são descobertas, elas tendem a ser interrompidas.

Resumo

O objetivo deste artigo é identificar os desafios que as pools de memória criptográficas enfrentam, 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 de uma solução de governança MEV.

Uma abordagem viável é o design híbrido: parte das transações é realizada através de um pool de memória criptografada com "classificação cega", enquanto a outra parte adota outros esquemas de classificação. Para tipos específicos de transações (por exemplo, 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 híbrido pode ser a escolha adequada. Para transações altamente sensíveis (como transações de correção dirigidas a contratos de segurança com vulnerabilidades), esse design também faz sentido prático.

No entanto, devido a limitações técnicas, à elevada complexidade de engenharia e ao custo de desempenho, a pool de memória criptográfica é pouco provável que se torne 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 nível de aplicação e a redução do tempo de confirmação final, entre outros. O MEV continuará a ser um desafio por um tempo no futuro, exigindo uma pesquisa aprofundada para encontrar um equilíbrio nas várias soluções, a fim de mitigar seus efeitos negativos.

Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
  • Recompensa
  • Comentar
  • Partilhar
Comentar
0/400
Nenhum comentário
  • Pino
Negocie cripto em qualquer lugar e a qualquer hora
qrCode
Digitalizar para transferir a aplicação Gate
Novidades
Português (Portugal)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)