Dicas de leitura

· Antes de ler este artigo, você precisa ter uma compreensão básica de MEV

· Esteja familiarizado com transações Ethereum e entenda o que uma transação contém e como é eventualmente incluída no bloco

· Conheça a Árvore de Merkle e o papel da prova de conhecimento zero

· clique para ler: MEV (5): Um ecossistema MEV mais justo (Parte 1)

O artigo anterior apresentou (1) o design do Flashbot SGX Builder, que aumenta a equidade do Block Builder por meio de hardware confiável, e (2) o design do Chainlink FSS, que previne MEV descentralizando os papéis de ordenação de transações.

Este artigo discutirá (3) o design de Mempools Criptografados, que tem como objetivo reduzir ou eliminar MEV, fornecendo privacidade para transações por meio de métodos criptográficos.

Mempools Criptografados

Dois objetivos: proteção MEV e resistência à censura

Se houver uma ferramenta que permita aos usuários criptografar suas transações antes de enviá-las e descriptografá-las apenas quando forem incluídas no bloco, os usuários não precisarão se preocupar em serem afetados pelo MEV. O Pesquisador de MEV não pode ver o conteúdo da transação de forma alguma, e os usuários não precisam se preocupar com suas transações sendo negadas devido a serem visadas pelos proponentes ou violarem sanções governamentais. A pedra angular para construir essa ferramenta é a criptografia.

Mempools criptografados utilizam criptografia para (1) criptografar o conteúdo da transação do usuário para proteger sua privacidade e (2) verificar a validade da transação quando ela é criptografada, impedindo que atacantes gerem um monte de transações inválidas, mas criptografadas. Isso impede que eles lancem um ataque de DoS na cadeia, já que o Proponente desperdiçaria espaço de bloco incluindo um monte de transações inválidas que são descobertas apenas no último momento.

Dica de leitura: A mera criptografia não pode garantir totalmente a resistência à censura, pois o Proponente que deseja censurar ainda pode se recusar a aceitar transações criptografadas, então a criptografia apenas aumenta o custo da censura (o Proponente desiste das taxas de processamento de todas as transações criptografadas). Para obter uma melhor proteção contra a censura, é necessário usar uma Lista de Inclusão como o PBS.

Garantir que as transações possam ser descriptografadas (Descriptografia Garantida)

Após criptografar a transação, é importante garantir que ela possa ser descriptografada. A falha em fazê-lo pode criar uma vulnerabilidade em um ataque de Negação de Serviço (DoS). Em tal ataque, o atacante envia repetidamente transações criptografadas que não podem ser descriptografadas. Como resultado, o nó deve reter essas transações até que expirem, levando a um acúmulo dessas transações inúteis na fila de transações do nó.

Existem algumas maneiras de garantir que as transações possam ser decifradas:

1. Confiança pura (Em voo)

2. Hardware confiável, Enclave

3. Criptografia/Descriptografia de Limiar

4. Atraso de Criptografia/Descriptografia

5. Testemunha de Criptografia/Descriptografia

△ Várias maneiras de garantir que as transações possam ser descriptografadas e seus exemplos. A complexidade aumenta da esquerda para a direita, sendo a confiança pura a mais simples e a descriptografia de testemunhas a mais difícil.

Fonte da imagem:https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

O mecanismo de comprometimento e revelação também pode alcançar o mesmo propósito? O usuário começa inserindo seu conteúdo de transação em uma função de hash para obter um valor de hash, conhecido como comprometimento. Uma vez que o proponente garante a inclusão do comprometimento da transação do usuário no bloco, o usuário prossegue para divulgar o conteúdo completo da transação.

Dica de leitura: A forma de compromisso pode ser como o Proposer no PBS prometendo que será incluído no bloco do Builder através de assinatura. É um compromisso garantido. Se o Proposer violar a promessa, será punido.

△ O proponente promete receber o compromisso da transação de Alice

Embora o Commit-reveal e a criptografia possam servir ao mesmo propósito de ocultar o conteúdo da transação do usuário e evitar a extração e censura de MEV, o Commit-reveal não pode garantir a descriptografia, uma vez que o poder está nas mãos do usuário. O usuário tem a escolha de não revelar o conteúdo, intencionalmente ou não.

Exigir que os usuários anexem um depósito e confisquem o depósito quando acabarem sem Revelação pode piorar a já fraca experiência do usuário de Compromisso-revelação.

△ Alice não precisa revelar sua transação

1. Confiança pura (em voo)

O usuário criptografa a transação e a envia para o papel centralizado. O papel centralizado então descriptografa a transação e garante que não será vazada antes de ser incluída no bloco. Os usuários geralmente confiam no papel centralizado e consideram as transações como criptografadas até serem incluídas no bloco, mesmo que o papel centralizado descriptografe a transação imediatamente após recebê-la.

Dica de leitura: Esse papel centralizado seria, por exemplo, Construtor da PBS, Proponente, ou Sequenciador/Operador do Rollup.

2. Hardware Confiável, Enclave

Funciona da mesma forma que a confiança pura, mas melhor do que a confiança pura porque os usuários confiam em hardware confiável e no código do programa que ele executa, em vez de confiar em uma pessoa, uma organização ou uma empresa.

3. Criptografia/Descriptografia por Limiar

O Chainlink FSS também utiliza criptografia e decodificação por limiar, mas no Chainlink FSS os gerentes das chaves de limite são Oráculos do Chainlink, enquanto nos MemPools Criptografados os gerentes (chamados Keypers) podem ser Validadores de L1 ou L2 (supondo que L2 também tenha No caso de Validador descentralizado).

A criptografia/decifragem de limiar possui diversas desvantagens:

• Suposição de maioria honesta forte: Deve-se presumir que mais da metade dos Keypers são honestos. Se forem desonestos, poderão descriptografar e ver as transações do usuário à vontade, revisar as transações ou extrair o MEV das transações.
• Falta de responsabilidade: Desde que um número suficiente de participantes do Keyper colaborem, eles podem descriptografar as informações. No entanto, quando os participantes do Keyper conspiram, não temos como saber quais estão envolvidos na conspiração. Sem poder identificar os atores maliciosos, é impossível projetar um mecanismo de punição para o Keyper. Portanto, devemos confiar na suposição de que a maioria dos participantes do Keyper são honestos.
• Liveness enfraquecida: O Keyper offline excessivo resultará em contagem insuficiente de Keyper online, o que impedirá a descriptografia e a produção de blocos. Isso fará com que a cadeia pare. Isso entra em conflito com o mecanismo Ethereum PoS, que enfatiza que a cadeia continuará a produzir blocos mesmo no caso de uma terceira guerra mundial, e eventualmente alcançará a finalidade. Pode-se inferir que a probabilidade de o Ethereum PoS usar descriptografia com um limite não é alta.

Porque a criptografia e descriptografia de limiar requer muitas mudanças, L2 é mais adequado para essa abordagem do que L1.

Este artigo propõe o design e considerações para implementação em L1. Projetos que estão testando este design podem consultar a Shutter Network. Para mais informações, por favor, verifique:https://ethresear.ch/t/shutterized-beacon-chain/12249

4. Atraso na Criptografia/Descriptografia

A criptografia de atraso garante que o texto cifrado possa ser automaticamente descriptografado após um certo período de tempo. No entanto, o processo de descriptografia não é verdadeiramente automático e requer que alguém atue como o decifrador e realize cálculos contínuos. Após um certo período de tempo, determinado pela dificuldade da criptografia, os cálculos podem ser concluídos e a descriptografia pode ser realizada com sucesso.

O conceito por trás da criptografia de atraso é semelhante à Função de Atraso Verificável (VDF), ambos pertencentes à família da Criptografia de Liberação de Tempo.

VDF nos permite verificar rapidamente F(x): um resultado de "cálculo sequencial demorado". Isso é semelhante ao Proof of Work (PoW), mas o cálculo do VDF é um processo sequencial, ao contrário do PoW, que pode ser acelerado por meio de computação paralela. O descriptografador do VDF só pode realizar cálculos repetidos passo a passo.

△ Com o VDF, você pode verificar o resultado de um cálculo que levei 10 segundos para concluir, digamos, em 0,01 segundos, e eu não tinha como paralelizar meu cálculo. Fonte da imagem:https://techtelegraph.co.uk/verifiable-delay-functions-on-bitcoin

A criptografia e descriptografia atrasadas também são cálculos contínuos, assim como o MEV, e não podem ser aceleradas por meio de operações paralelas. No entanto, deve-se considerar que alguém acelerará o processo de descriptografia por meio de otimização de hardware. Portanto, se você deseja adotar essa tecnologia e aplicá-la em um ambiente público real, deve garantir que ninguém tenha uma grande discrepância de hardware e possa concluir a descriptografia antecipadamente (e a descriptografia é feita em particular, então é difícil detectar).

Atualmente, a Ethereum Foundation e a Protocol Labs já estão colaborando na pesquisa de chips VDF ASIC, esperando exportar o hardware de computação mais avançado para o mercado, para que ninguém possa ter vantagens de hardware discrepantes e descriptografar secretamente antecipadamente. Para saber mais, por favor verifique: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

Dica de leitura: VDF também pode ser usado para aumentar a imanipulabilidade dos números aleatórios do Ethereum.

A vantagem da criptografia e descriptografia retardada em comparação com a criptografia e descriptografia de limiar é que não precisa confiar ou depender da operação normal de um grupo de Keypers, e ele será descriptografado automaticamente quando o tempo acabar. No entanto, esse tempo de descriptografia imposto também é uma desvantagem da descriptografia retardada: as transações criptografadas devem levar um período de tempo para serem descriptografadas, o que significa que há um atraso fixo para que as transações do usuário sejam carregadas na cadeia. Além disso, a concorrência de hardware também é um risco que não pode ser ignorado neste método. É difícil saber se alguém desenvolveu um chip mais rápido para descriptografar.

5. Testemunha de Criptografia/Descriptografia

Imagine que um texto cifrado não é decifrado por uma chave ou cálculo sequencial, mas só pode ser decifrado quando uma certa "condição" é atendida, como "quando esta equação é resolvida" ou "quando esta equação é resolvida". Uma vez que o texto cifrado está incluído no bloco, o texto cifrado pode ser decifrado e assim por diante.

Dica de leitura: 'Saber a chave para descriptografar um texto cifrado' ou 'saber os resultados de cálculos contínuos' é, na verdade, uma condição.

Através da criptografia testemunhal, podemos não apenas alcançar os efeitos da criptografia de limite e criptografia atrasada, mas também podemos combinar esses dois métodos de descriptografia. Por exemplo, podemos definir as condições como "Condição 1: 'Um grupo de Keypers concorda em descriptografar este texto cifrado' ou Condição 2: 'Após cinco minutos'": Se todos os Keypers estiverem online, podemos atender rapidamente à Condição 1 para descriptografar o texto cifrado. No entanto, se não houver Keypers suficientes online, podemos pelo menos garantir que podemos cumprir a Condição 2 e descriptografar provando através do VDF que "cinco minutos se passaram".

△ Bastante Keypers podem ser descriptografados online (acima) ou após tempo suficiente (abaixo)

Desde que as condições sejam comprovadas como atendidas, a descriptografia pode ser alcançada. A prova pode ser feita através de métodos como provas de conhecimento zero, que podem verificar de forma eficiente cálculos complexos (assumindo que as operações necessárias para provar as condições são complexas) ou ocultar informações (assumindo que o provador não deseja revelar certas informações durante o processo de prova). No entanto, embora a criptografia de testemunhas seja muito poderosa, a tecnologia atual não é suficiente para fornecer qualquer uso prático.

△ A maturidade de diferentes tecnologias de criptografia e descriptografia. A criptografia e descriptografia das testemunhas (Testemunhas) ainda não está madura o suficiente. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Manipular e realizar operações em texto cifrado através de criptografia homomórfica

Os parágrafos anteriores apresentaram diferentes maneiras de garantir que as transações possam ser descriptografadas, mas quando as transações podem ser descriptografadas? A resposta é: depois que a transação é incluída no bloco e a ordem é determinada. Mas como o Construtor de Bloco monta um bloco a partir de um monte de palavras sem sentido, ou mesmo monta eficientemente um bloco altamente lucrativo? A resposta é: Criptografia Homomórfica (HE).

△ Exemplo de criptografia homomórfica usada para votação: O conteúdo do voto foi criptografado, mas o texto cifrado ainda pode ser somado e descriptografado após o resultado ser calculado. Fonte da imagem:https://twitter.com/khushii_w/status/1660278622291210242

Dica de leitura: Se a criptografia e descriptografia forem realizadas por meio de confiança pura (em trânsito) ou hardware confiável, na verdade, não espera até que a transação seja incluída no bloco e a ordem seja determinada antes da descriptografia. Afinal, todos confiam na outra parte, então irá descriptografar e classificar a transação imediatamente após recebê-la. Isso pode acelerar a formação dos blocos e não requer recursos adicionais para realizar operações de criptografia homomórfica.

Através da criptografia homomórfica, podemos realizar operações em texto cifrado sem decifrar a transação. Podemos aplicar o processo de operação de organizar transações e formar um bloco legal a essas transações criptografadas sem decifrar a transação e obter um bloco de transação criptografado. Quando o bloco é decifrado, obteremos um bloco completo e legal, no qual as transações são decifradas e classificadas na ordem antes da criptografia.

△ Através da criptografia homomórfica, o Block Builder pode montar um bloco completo e legal a partir de transações criptografadas

Dica de leitura: Existem níveis de criptografia homomórfica, como criptografia parcialmente homomórfica (Parcialmente HE) e criptografia totalmente homomórfica (Totalmente HE). A criptografia parcialmente homomórfica só pode adicionar ou multiplicar ciphertext, enquanto a criptografia totalmente homomórfica pode adicionar e multiplicar ciphertext (basicamente, qualquer operação pode ser realizada).

△ A terceira coluna: A maturidade de diferentes tecnologias de criptografia e descriptografia que suportam FHE. Exceto em voo e enclave, que não requerem HE e, portanto, são considerados suportados, os outros ainda não estão disponíveis. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

O acima apresenta diferentes mecanismos para criptografar e descriptografar transações. Cada um deles tem vantagens e desvantagens diferentes, mas, no final, tudo o que podem fazer é ocultar o conteúdo da transação e garantir que possa ser descriptografado quando as condições forem atendidas. Uma vez que o conteúdo da transação está oculto, ele pode evitar ser descriptografado. Extração de MEV e risco de censura.

Mas os próprios dados da transação terão metadados relevantes, como o iniciador da transação, a taxa de transação ou a assinatura, que são usados para verificar a validade da transação. Além disso, o endereço IP do iniciador também é uma forma de metadados e até mesmo o tamanho dos dados da transação. Todos esses metadados têm o potencial de vazar a privacidade do usuário, então também devemos proteger esses metadados.

Garantir que os metadados não vazem privacidade

A seguir, são listados os vários metadados de transações criptografadas e as medidas de proteção correspondentes, que exigirão técnicas criptográficas como criptografia homomórfica e provas de conhecimento zero.

1. endereço IP

2. Assinatura da transação

3. Taxas de transação

4. Iniciador da transação e seu valor de nonce

5. Tamanho da transação

△ Metadados diferentes de transações podem vazar a privacidade do usuário. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

Endereço IP

A rede a que um usuário se conecta para enviar transações criptografadas pode revelar a identidade do usuário com base no endereço IP do usuário e pode ser censurada. A proteção da privacidade ao nível da rede depende de tecnologias como o Tor.

Assinatura da transação, taxa de processamento, iniciador da transação e seu valor de Nounce

Esses metadados são usados para comprovar a validade da transação, mas revelarão a identidade do usuário, então eles devem ser criptografados. Uma vez criptografados, devemos usar outras ferramentas para comprovar a validade das transações sem revelar essas informações. Caso contrário, a rede pode ser atacada por DoS e ser preenchida com uma série de transações inválidas que só são descobertas após a descriptografia.

Quando um nó recebe uma transação criptografada, ele deve (1) primeiro confirmar que o iniciador da transação realmente iniciou a transação, ou seja, verificar a assinatura da transação e então (2) confirmar que o iniciador tem ETH suficiente para pagar pela transação (saldo do usuário ≥ preço do gás * limite de gás) e (3) verificar o valor do nonce do remetente para evitar ataques de repetição de transação.

Prova de conhecimento zero

Podemos usar provas de conhecimento zero para provar que as transações passam por essas verificações sem revelar essas informações. Uma prova de conhecimento zero consiste em informações públicas (Entrada Pública), informações privadas (Testemunha Privada) e a afirmação que a prova deseja provar (Declaração).

△ Por exemplo, as informações públicas (entrada pública) são uma transação criptografada (texto cifrado tx), as informações privadas (testemunha privada) são uma transação não criptografada (texto cifrado tx), e a declaração (declaração zk) a ser provada por esta prova de conhecimento zero é "esta "Transações criptografadas são legais" (tx ciphertext válido). Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

Por exemplo, se Alice quiser provar a Bob que ela tem mais de 10 ETH, mas não quiser revelar seu endereço, ela pode usar uma prova de conhecimento zero para provar a Bob que seu endereço realmente tem um saldo superior a 10 ETH.

A declaração (declaração zk) a ser provada por esta prova de conhecimento zero é "Provar que o endereço de Alice possui um saldo superior a 10 ETH". Para gerar essa prova, Alice deve fornecer seu endereço e provar que ela detém a chave privada do endereço (por exemplo, usando A chave privada gera uma assinatura), e ela também precisa fornecer o saldo de ETH deste endereço, por exemplo, usar uma Prova de Merkle para provar quanto ETH este endereço possui no 1001º bloco.

Endereço, assinatura e Prova de Merkle não podem ser divulgados e são informações privadas (testemunha privada).

Quando essa prova é produzida, Bob pode verificar essa prova com a Raiz de Merkle (chamada de Raiz de Estado) da árvore de estados do bloco 1001. Qualquer um sabe a Raiz do Estado de cada bloco, que é a informação pública (entrada pública).

A única informação que o Bob sabe é a informação pública da Raiz do Estado e os resultados da verificação. Ele não saberá nenhuma informação privada da Alice.

△ Alice fornece duas entradas privadas: Prova de Merkle e assinatura; Bob fornece a entrada pública da raiz do Estado. A declaração zk pode verificar que Alice possui um endereço e o saldo do endereço é > 10 ETH

(1) Verificar assinatura da transação

A verificação da assinatura da transação consiste em duas partes: (a) o iniciador da transação é legítimo e (b) a assinatura da transação é assinada pelo iniciador da transação.

Principalmente para verificar se o endereço Ethereum do iniciador da transação é um endereço legal e não um número aleatório. Isso será comprovado através de uma Prova de Merkle de que o endereço existe na árvore de estado do Ethereum.

(b) Verifica se a assinatura da transação é assinada pela chave privada do iniciador da transação.

△ Esta prova verifica (a) o endereço do remetente da transação (via prova de Merkle de chave pública do remetente) e (b) a assinatura dentro da transação é legítima (a assinatura será incluída no texto simples da tx). O texto simples da tx é os dados brutos não criptografados da transação, que é a informação privada fornecida pelo iniciador da transação.

Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Dica de leitura: O texto vermelho na imagem acima refere-se ao que este certificado significa após a verificação (ou seja, “a assinatura da transação é legal”). Não faz parte da declaração zk. A parte azul é a informação relacionada à própria transação, incluindo dados de transação criptografados (públicos) e dados de transação não criptografados (privados). A parte verde é o dado adicional necessário para completar a prova, tanto público quanto privado.

△ Provar que o endereço do iniciador da transação existe na árvore de estado do Ethereum e que o iniciador da transação realmente possui a chave privada do local

(2) Confirme que o iniciador da transação tem ETH suficiente para pagar a taxa de manuseio

Assim como no exemplo anterior de Alice e Bob provando que o saldo é > 10 ETH, o iniciador da transação precisa fornecer a Prova de Merkle do saldo de seu próprio endereço, e a declaração a ser provada é “o saldo do endereço ≥ a taxa de transação.” A taxa de transação é igual ao preço do gás multiplicado pelo limite de gás. As informações tanto do preço do gás quanto do limite de gás estão incluídas nos dados originais da transação não criptografada (texto da tx). O texto da tx é informação privada fornecida pelo iniciador da transação.

△ Esta prova verifica que o saldo do endereço do iniciador da transação (via prova Merkle de saldo do remetente) é maior ou igual à taxa de transação (a informação da taxa de transação está incluída no texto da tx). Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Prove o saldo do endereço do iniciador da transação > preço do gás

(3) Verifique o valor do Nonce do iniciador da transação

Porque o Nonce também é registrado no estado do Ethereum, a Prova de Merkle também é usada para provar o valor atual do Nonce do iniciador da transação e, em seguida, compará-lo com o valor do Nonce especificado na transação para confirmar que a transação não foi repetida.

△ Esta prova compara o valor do Nonce do endereço do iniciador da transação (através da prova de Merkle do Nonce) e o valor do Nonce especificado pela transação (o valor do Nonce especificado pela transação está incluído no texto simples da tx). Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Provar o nonce do endereço do iniciador da transação = nonce da tx

No entanto, este check não pode impedir que atacantes maliciosos gerem várias transações com o mesmo valor de Nonce (essas transações podem passar todas no check de valor de Nonce) para realizar ataques DoS, então precisamos adicionar checks adicionais.

Exigimos que o iniciador da transação forneça mais uma Tag de repetição para garantir que haverá apenas uma transação com o mesmo valor de Nonce. A Tag de repetição é o valor de hash do valor Nonce e da chave privada do iniciador da transação: tag de repetição = H (nonce, chave privada), portanto, valores Nonce diferentes do mesmo iniciador de transação corresponderão a uma Tag de repetição exclusiva.

Portanto, os nós podem usar a Tag de Repetição para identificar se um iniciador de transação iniciou várias transações com o mesmo valor de Nonce (as Tags de Repetição dessas transações serão iguais) e rejeitar a segunda transação com a mesma Tag de Repetição.

△ Esta prova irá calcular a etiqueta de replay e compará-la com a etiqueta de replay passada pela entrada pública. O valor de Nonce da transação está contido no texto tx, e a chave privada está contida na testemunha privada.

Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Prove o nonce do endereço do iniciador da transação = nonce da tx e tag de replay = H(nonce, chave)

Ou se considerarmos que o iniciador da transação pode querer substituir a transação com o mesmo valor de Nonce por outra transação, talvez porque ele não queira executar a transação original, ou porque ele queira aumentar o preço do gás para que a transação possa ser coletada mais rapidamente.

Neste momento, podemos introduzir o valor do Slot de PoS no cálculo da Etiqueta de Repetição: etiqueta de repetição = H(nonce, chave privada, slot). Por exemplo, Bob enviou uma transação com um Nonce de 5 no Slot 1001, mas ainda não a recebeu, então ele decidiu dobrar o preço do gás da transação, mantendo os outros campos inalterados, e enviou a transação atualizada no Slot 1005. Transação, e como o Slot mudou, a Etiqueta de Repetição é diferente, e esta nova transação não será rejeitada porque o valor do Nonce é o mesmo.

△ A entrada pública passará em valores de slot adicionais para cálculo de tag de replay. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. Tamanho da transação

Alguns métodos de criptografia farão com que o tamanho dos dados da transação criptografada seja o mesmo que antes da criptografia. No entanto, ainda há uma chance de deduzir algumas informações através do tamanho. Por exemplo, os dados da transação de uma transação realizada na Uniswap devem ser maiores do que os dados da transação de uma simples transferência de ETH. Portanto, o tamanho da transação é o mesmo que os Metadados que podem vazar privacidade.

Uma abordagem intuitiva é realizar uma ação de preenchimento nos dados da transação antes de criptografá-los, como preencher com um monte de zeros até que o tamanho da transação se torne uma potência de dois, ou até mesmo preenchê-lo completamente até que se torne um tamanho fixo. Isso reduz a chance de um observador identificar uma transação pelo seu tamanho. O Construtor de Blocos combinará as transações preenchidas em um bloco.

△ O branco é Padding. Os negócios azul e laranja são do mesmo tamanho, então não há como distingui-los com base no tamanho. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

No entanto, as desvantagens deste enfoque são que (1) é ineficiente porque muito espaço no bloco será desperdiçado com preenchimento, e (2) pode não oferecer proteção de privacidade suficiente. Por exemplo, o tamanho da transação vermelha na imagem acima (quatro quadrados) pode ser raro, então ainda pode ser descoberto. Se todas as transações forem preenchidas para um tamanho fixo (como 64 blocos), a privacidade será melhorada, mas isso se tornará um desperdício relativamente grande de espaço no bloco.

△ A desvantagem é a ineficiência e a proteção limitada da privacidade. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

Uma abordagem melhor é primeiro preencher as transações para um tamanho fixo, mas a criptografia homomórfica pode ser usada para remover o preenchimento.

Porque as transações são todas preenchidas para um tamanho fixo, todas as transações vistas pelos observadores terão o mesmo tamanho. O Construtor de Blocos pode combinar transações criptografadas por meio de uma função e remover o preenchimento ao mesmo tempo.

△ Use criptografia homomórfica para remover o preenchimento ao combinar transações criptografadas. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Dica de leitura: O construtor de blocos com confiança pura ou hardware confiável pode alcançar o mesmo efeito sem criptografia homomórfica (afinal, todos confiam nele).

Como o Block Builder constrói blocos eficientes

Mesmo que possamos combinar eficientemente transações criptografadas em um bloco por meio de criptografia homomórfica, ainda existem alguns problemas a serem resolvidos, como (1) transações diferentes podem ler e escrever no mesmo estado (por exemplo, todas negociam na Uniswap), o que pode resultar em transações de menor classificação sendo mais propensas a falhar, e (2) o Construtor de Bloco não pode coletar transações de acordo com o nível de taxas de processamento.

A solução ideal é executar o EVM em criptografia homomórfica, assim como colocar um EVM em uma caixa preta para execução, para que o Block Builder possa simular a execução da transação através do EVM para formar o bloco mais eficiente e com a maior renda. No entanto, a complexidade técnica dessa tecnologia é muito alta, e levará muito tempo para realizá-la.

A alternativa é anexar uma taxa de manipulação criptografada e uma Lista de Acesso criptografada à transação (a Lista de Acesso é usada para indicar quais estados a transação irá ler e escrever), e usar criptografia homomórfica para verificar a validade. Dessa forma, o Construtor de Blocos pode determinar a ordem de receita da transação por meio de taxas de manipulação e usar a Lista de Acesso para impedir que as transações afetem umas às outras e resultem em eficiência de execução de transações reduzida.

△ É determinado pela taxa de manuseio e pela Lista de Acesso quais transações serão coletadas e a ordem em que serão coletadas. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

O momento em que a transação ocorre

Se estivermos preocupados que o horário em que as transações criptografadas são enviadas para a rede p2p possa vazar privacidade (por exemplo, Alice conduz transações às 00:00-04:00 UTC+8), podemos pedir aos Validadores para enviar regularmente um monte de Transações Falsas criptografadas para confundir o observador.

A transação fictícia precisará ser anexada a uma prova de conhecimento zero para provar que foi enviada pelo Validador e limitar a frequência para evitar que a rede seja preenchida com Transações Fictícias (os observadores não saberão que esta é uma Transação Fictícia, apenas que é 'legal e válida').

Transação fictícia será identificada e descartada durante a operação de criptografia homomórfica do bloco do grupo.

△ Os validadores enviam regularmente Transações Falsas (cinza) para confundir observadores, mas isso aumentará a carga na rede e nos nós. Fonte da imagem:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Mempools criptografados v.s. FSS

O FSS no artigo anterior também introduziu que o FSS também criptografará as transações primeiro e depois as entregará ao Chainlink Oracle para classificação. O processo de criptografia de transações do FSS e verificação da validade de transações criptografadas é na verdade o mesmo que MemPools Criptografados, exceto:

• A criptografia de transação do FSS não menciona a proteção de Metadados, enquanto o Mempools Criptografado oculta Metadados e usa prova de conhecimento zero para provar a validade da transação.
• Atualmente, o FSS usa o Threshold Encryption/Decryption e é descriptografado em conjunto pelo Chainlink Oracle, o que significa que você deve confiar no Chainlink Oracle. O Mempools criptografado não especifica como classificar, mas se concentra apenas em criptografar transações e provar sua validade com provas de conhecimento zero.
• Comparado com FSS, que apenas enfatiza a 'justiça', Mempools Criptografados dão mais ênfase em 'como montar eficientemente o conteúdo do bloco e como permitir ao Proponente montar o bloco mais benéfico em vez de decidir aleatoriamente a ordem das transações'.

No futuro, a FSS também pode usar a tecnologia em Mempools Criptografados para aprimorar ou substituir suas transações de criptografia e descriptografia.

Enfrentando MEV com Criptografia

Esta palestra é sobre Mempools Criptografados, onde o autor compartilha como técnicas criptográficas e melhorias na camada de consenso do Ethereum podem ajudar a combater os problemas causados pelo MEV. Para mais detalhes, por favor, confira:https://www.youtube.com/watch?v=mpRq-WFihz8

Resumo e destaques

1. O objetivo das Mempools Criptografadas é proteger contra MEV e censura, criptografando transações. Outros só podem saber que suas transações são válidas, mas não podem saber quais ações você está realizando dentro de suas transações.

2. No entanto, para realmente alcançar uma resistência eficaz à censura, um mecanismo como a Lista de Inclusão da PBS deve ser utilizado. Caso contrário, o Construtor ainda pode realizar a censura recusando-se a receber transações criptografadas.

3. Não é fácil provar que uma transação criptografada é válida. Você precisa de várias provas de conhecimento zero para provar a assinatura da transação, o valor de Nonce do iniciador da transação, taxas de manuseio suficientes, etc.

4. Além disso, é necessário evitar que metadados como IP, tamanho dos dados da transação ou horário de envio da transação vazem a privacidade da transação.

5. Por último, a coisa mais importante é garantir que as transações possam ser descriptografadas - Criptografia Garantida. Existem cinco métodos diferentes: Confiança Pura (Em voo), Enclave de Hardware Confiável, Criptografia/Descriptografia de Limiar, Criptografia/Descriptografia de Atraso e Criptografia/Descriptografia de Testemunha. Cada método tem suas próprias vantagens e desvantagens.

Dados de referência e leitura adicional recomendada

Mempools Criptografadas

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• Como a criptografia ajuda a resolver os problemas causados por MEV na camada de aplicação e camada de consenso:https://youtu.be/jLHf6yw7b5Y?t=4139

Um agradecimento especial a Steven Wu, Kimi Wu, Kevin Mai-Hsuan Chia e Anton Cheng por revisarem e melhorarem este post.

Aviso Legal:

1. Este artigo foi reproduzido de [techflowpost]. Todos os direitos autorais pertencem ao autor original [Will 阿望; Diane Cheung]. Se houver objeções a este reenvio, entre em contato com o Portão Aprenderequipe, e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem conselhos de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.