Dicas de Leitura

· Antes de ler este artigo, é necessário ter uma compreensão básica de MEV

· Esteja familiarizado com as transações Ethereum e compreenda 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 através 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 irá discutir (3) o design de Mempools Criptografados, que tem como objetivo reduzir ou eliminar MEV ao fornecer privacidade para transações através de métodos criptográficos.

Mempools Criptografados

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

Se existir uma ferramenta que permita aos utilizadores encriptar as suas transações antes de as transmitirem e desencriptá-las apenas quando forem incluídas no bloco, os utilizadores não terão de se preocupar em serem afetados pelo MEV. O Pesquisador de MEV não consegue ver o conteúdo da transação de todo, e os utilizadores não precisam de se preocupar com as suas transações serem negadas em termos de rendimento devido a serem visados pelos proponentes ou violarem sanções governamentais. A pedra angular para construir esta ferramenta é a criptografia.

As Mempools encriptadas utilizam criptografia para (1) encriptar o conteúdo da transação do usuário para proteger a sua privacidade e (2) verificar a validade da transação quando está encriptada, impedindo que os atacantes gerem um monte de transações inválidas mas encriptadas. Isto impede que lancem um ataque DoS na cadeia, pois o Proponente desperdiçaria espaço de bloco ao incluir um monte de transações inválidas que só são descobertas 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 recusar-se a aceitar quaisquer transações criptografadas, portanto, a criptografia apenas aumenta o custo da censura (o Proponente abre mão 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 PBS.

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

Após criptografar a transação, é importante garantir que ela possa ser descriptografada. Falhar em fazê-lo pode criar uma vulnerabilidade em um ataque de Negação de Serviço (DoS). Nesse tipo de 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 pool de transações do nó.

Existem algumas formas de garantir que as transações possam ser descriptografadas:

1. Pura confiança (Em voo)

2. Hardware de Confiança, Enclave

3. Encriptação/Desencriptação de Limiar

4. Atraso de Encriptação/Desencriptação

5. Testemunha de Encriptação/Desencriptação

△ 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

Compromisso-revelação

O mecanismo de commit-reveal também pode alcançar o mesmo propósito? O usuário começa inserindo o conteúdo de sua transação em uma função de hash para obter um valor de hash, conhecido como compromisso. Uma vez que o proponente garante a inclusão do compromisso de transação do usuário no bloco, o usuário procede à divulgação do conteúdo completo da transação.

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

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

Embora o Commit-reveal e a encriptação 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 desencriptação, pois o poder está nas mãos do usuário. O usuário tem a escolha de não revelar o conteúdo, quer intencionalmente quer não.

Exigir que os utilizadores depositem uma caução e perder a caução quando não revelam pode piorar a já fraca experiência do utilizador do Commit-reveal.

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

1. Confiança pura (em voo)

O utilizador encripta a transação e envia-a para o papel centralizado. O papel centralizado depois desencripta a transação e garante que não será divulgada antes de ser incluída no bloco. Os utilizadores geralmente confiam no papel centralizado e consideram as transações como encriptadas até serem incluídas no bloco, embora o papel centralizado desencripte a transação imediatamente após a receber.

Dica de leitura: Este papel centralizado seria, por exemplo, o Construtor da PBS, o Propositor, ou o 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 utilizadores confiam num hardware confiável e no código do programa que executa, em vez de confiar numa pessoa, numa organização ou numa empresa.

3. Criptografia/Descriptografia de Limiar

A Chainlink FSS também utiliza encriptação e desencriptação por limiar, mas na Chainlink FSS os gestores das chaves de limiar são Oracles da Chainlink, enquanto nos Mempools Encriptados os gestores (chamados Keypers) podem ser Validadores de L1 ou L2 (assumindo que L2 também tem No caso de Validador descentralizado).

A encriptação/desencriptação de limiar tem várias desvantagens:

• Pressuposição de maioria honesta forte: Deve-se presumir que mais da metade dos Keypers são honestos. Se forem desonestos, podem descriptografar e ver transações de usuários à 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 colabore, 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.
• Enfraquecimento da vivacidade: Um Keyper offline excessivo resultará num número 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 PoS do Ethereum, 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 a descriptografia com um limiar não é alta.

Porque a encriptação e desencriptação de limiar requer muitas alterações, o L2 é mais adequado para esta abordagem do que o 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 de Encriptação/Desencriptação

A criptografia com atraso garante que o texto cifrado possa ser automaticamente decifrado após um certo período de tempo. No entanto, o processo de decifração 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 decifração pode ser alcançada com sucesso.

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

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

△ Com o VDF, pode verificar o resultado de um cálculo que demorou 10 segundos para ser concluído, digamos, em 0,01 segundos, e eu não tinha forma de paralelizar o 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 como VDF 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 lacuna de hardware e possa concluir a descriptografia antecipadamente (e a descriptografia é feita em particular, então é difícil de detectar).

Atualmente, a Ethereum Foundation e a Protocol Labs já estão colaborando na pesquisa de chips ASIC VDF, esperando exportar o hardware de computação mais avançado para o mercado, de forma que ninguém possa ter vantagens de hardware díspares 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 imutabilidade dos números aleatórios do Ethereum.

A vantagem da criptografia e descriptografia atrasadas em comparação com a criptografia e descriptografia de limiar é que não é necessário confiar ou depender da operação normal de um grupo de Keypers, e ela será descriptografada automaticamente quando o tempo acabar. No entanto, esse tempo de descriptografia imposto também é uma desvantagem da descriptografia atrasada: as transações criptografadas precisam de um período de tempo para serem descriptografadas, o que significa que há um atraso fixo para as transações do usuário serem 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 Encriptação/Desencriptação

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

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 de testemunhas, não só podemos alcançar os efeitos da criptografia de limite e da 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 rapidamente atender à Condição 1 para descriptografar o texto cifrado. No entanto, se não houver Keypers suficientes online, podemos pelo menos garantir que possamos atender à Condição 2 e descriptografar, provando através do VDF que "cinco minutos se passaram".

△ Suficientes Keypers podem ser decifrados online (acima) ou após tempo suficiente (abaixo)

Desde que as condições sejam comprovadas como cumpridas, a descriptografia pode ser alcançada. A prova pode ser feita através de métodos como provas de conhecimento zero, que podem verificar eficientemente cálculos complexos (assumindo que as operações necessárias para provar as condições são complexas) ou esconder informações (assumindo que o provador não deseja revelar certas informações durante o processo de prova). No entanto, embora a encriptação 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 decriptação. A criptografia e decriptação de testemunhas (Witness) não é suficientemente madura. 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 formas de garantir que as transações possam ser descriptografadas, mas quando é que as transações podem ser descriptografadas? A resposta é: depois de a transação ser incluída no bloco e a ordem ser determinada. Mas como é que o Construtor de Blocos monta um bloco a partir de um monte de palavras sem sentido, ou até 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 encriptação e desencriptação forem feitas através de confiança pura (em trânsito) ou hardware confiável, na realidade não espera até que a transação seja incluída no bloco e a ordem seja determinada antes de desencriptar. Afinal, todos confiam na outra parte, então irá desencriptar e ordenar a transação imediatamente após recebê-la. Isto pode acelerar a formação de blocos e não requer recursos adicionais para realizar operações de encriptação 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 organização de transações e formação de um bloco legal a essas transações criptografadas sem decifrar a transação e obter um bloco de transações criptografado. Quando o bloco é decifrado, obteremos um bloco completo e legal, no qual as transações são decifradas e ordenadas na ordem anterior à 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 a criptografia homomórfica parcial (Partially HE) e a criptografia homomórfica total (Fully HE). A criptografia homomórfica parcial só pode adicionar ou multiplicar o texto cifrado, enquanto a criptografia homomórfica total pode adicionar e multiplicar o texto cifrado (basicamente, qualquer operação pode ser realizada).

△ A terceira coluna: A maturidade das diferentes tecnologias de criptografia e decriptação 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 diferentes vantagens e desvantagens, 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 são atendidas. Uma vez que o conteúdo da transação está oculto, pode evitar ser descriptografado. Extração de MEV e risco de censura.

Mas os dados da transação em si terão metadados relevantes, como o iniciador da transação, a taxa de transação ou 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é o tamanho dos dados da transação. Todos esses metadados têm o potencial de vazar a privacidade do usuário, portanto, também devemos proteger esses metadados.

Garantir que os metadados não comprometem a privacidade

A seguir, são listados os vários metadados de transações criptografadas e as correspondentes medidas de proteção, 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 de transações e seu valor Nonce

5. Tamanho da transação

△ Metadados diferentes de transações podem comprometer a privacidade do utilizador. 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 baseia-se em tecnologias como o Tor.

Assinatura da transação, taxa de processamento, iniciador da transação e o valor do Nonce

Estes metadados são usados para provar a validade da transação, mas revelarão a identidade do utilizador, por isso devem ser criptografados. Uma vez criptografados, devemos usar outras ferramentas para provar a validade das transações sem revelar esta informação. Caso contrário, a rede pode ser atacada por DoS e ser preenchida com um monte 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 depois (2) confirmar que o iniciador tem ETH suficiente para pagar a 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 declaração que a prova deseja provar (Declaração).

△ Por exemplo, a informação pública (entrada pública) é uma transação criptografada (texto cifrado tx), a informação privada (testemunha privada) é uma transação não criptografada (texto cifrado tx), e a declaração (instrução zk) a ser provada por esta prova de conhecimento zero é "esta "Transações criptografadas são legais" (texto cifrado tx 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 de mais de 10 ETH.

A declaração (declaração de zk) a ser provada por esta prova de conhecimento zero é 'Provar que o endereço de Alice tem um saldo superior a 10 ETH'. Para gerar esta prova, Alice deve fornecer o seu endereço e provar que detém a chave privada do endereço (por exemplo, utilizando A chave privada gera uma assinatura), e 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 detém no 1001º bloco.

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

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

A única informação que o Bob conhece é a informação pública da Raiz do Estado e os resultados de 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 tem 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.

(a) 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 por meio 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 originador 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 da transação não encriptados, 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 depois de passar pela 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 com a transação em si, incluindo dados de transação encriptados (públicos) e dados de transação não encriptados (privados). A parte verde são os dados adicionais necessários para completar a prova, tanto pública como privada.

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

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

Assim como o 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 de transação não criptografados originais (texto simples da tx). O texto simples 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 de 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) Verificar 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 reproduzida.

△ Esta prova compara o valor do Nonce do endereço do iniciador da transação (através da prova de Nonce Merkle) e o valor do Nonce especificado pela transação (o valor do Nonce especificado pela transação está incluído no texto 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, esta verificação não pode impedir que atacantes maliciosos gerem várias transações com o mesmo valor de Nonce (essas transações podem todas passar na verificação do valor de Nonce) para realizar ataques de DoS, portanto, precisamos adicionar verificações adicionais.

Exigimos que o iniciador da transação forneça mais uma Etiqueta de Repetição para garantir que haja apenas uma transação com o mesmo valor de Nonce. A Etiqueta de Repetição é o valor hash do valor de Nonce e a chave privada do iniciador da transação: etiqueta de repetição = H(nonce, chave privada), portanto, diferentes valores de Nonce do mesmo iniciador de transações corresponderão a uma única Etiqueta de Repetição única.

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

△ Esta prova irá calcular a tag de replay e compará-la com a tag de replay passada pela entrada pública. O valor Nonce da transação está contido em tx plaintext, e a chave privada está contida em private witness.

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

△ Provar o nonce do endereço do iniciador da transação = nonce da tx e tag de repetição = 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 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 de Slot de PoS no cálculo de Replay Tag: replay tag = H(nonce, private key, slot). Por exemplo, Bob enviou uma transação com um Nonce de 5 no Slot 1001, mas ainda não foi recebido, então ele decidiu dobrar o preço do gás da transação, mantendo outros campos inalterados, e enviou a transação atualizada no Slot 1005. Transação, e porque o Slot mudou, a Tag de repetição é diferente, e esta nova transação não será rejeitada porque o valor 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 existe a possibilidade de deduzir algumas informações através do tamanho. Por exemplo, os dados da transação de uma transação realizada no 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 comprometer a privacidade.

Uma abordagem intuitiva é realizar uma ação de preenchimento nos dados da transação antes de os encriptar, como preencher com um monte de zeros até que o tamanho da transação se torne uma potência de dois, ou mesmo preenchê-la até que se torne um tamanho fixo. Isso reduz a chance de um observador identificar uma transação pelo seu tamanho. O Block Builder irá combinar as transações preenchidas num bloco.

△ Branco é preenchimento. As ofertas azuis e laranjas são do mesmo tamanho, então não há como diferenciá-las 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 método são que (1) é ineficiente porque muito espaço no bloco será desperdiçado em Preenchimento, e (2) pode não fornecer 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 se tornará um desperdício relativo de espaço de 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 Block Builder pode combinar transações criptografadas através de uma função e remover o preenchimento ao mesmo tempo.

△ Usar 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 num bloco através de criptografia homomórfica, ainda existem alguns problemas a serem resolvidos, como (1) diferentes transações podem ler e escrever no mesmo estado (por exemplo, todas elas negociam na Uniswap), o que pode resultar em transações de menor classificação com maior probabilidade de falha, e (2) o Construtor de Blocos 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 de transações através do EVM para formar o bloco mais eficiente e com maior rendimento. No entanto, a complexidade técnica desta 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 evitar que as transações afetem umas às outras e resultem em eficiência reduzida na execução da transação.

△ É determinado pela taxa de manuseio e pela Lista de Acesso quais transações devem ser coletadas e a ordem em que sã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 estamos preocupados que o momento em que as transações criptografadas são enviadas para a rede p2p possa vazar privacidade (por exemplo, Alice realiza transações em UTC+8 00:00–04:00), podemos pedir aos Validadores que enviem um monte de Transações fictícias criptografadas regularmente. para confundir o observador.

A transação fictícia terá de ser acompanhada por 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 se trata de uma Transação Fictícia, apenas que é “legal e válida”).

A 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 vs. FSS

O FSS no artigo anterior também introduziu que o FSS também irá criptografar transações primeiro e depois entregá-las 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 Encrypted Mempools oculta metadados e usa prova de conhecimento zero para provar a validade da transação.
• FSS atualmente usa Criptografia/Descriptografia de Limiar e é descriptografado em conjunto pelo Oráculo Chainlink, o que significa que você deve confiar no Oráculo Chainlink. Mempools Criptografados não especificam como classificar, mas apenas se concentram em criptografar transações e comprovar sua validade com provas de conhecimento zero.
• Comparado com o FSS, que apenas enfatiza a “justiça”, as Mempools Criptografadas colocam mais ênfase em “como montar eficientemente o conteúdo do bloco e como permitir que o Proponente monte 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 nos Mempools Criptografados para melhorar ou substituir suas transações de criptografia e descriptografia.

Abordar o MEV com Criptografia

Esta palestra é sobre Mempools Criptografados, onde o autor partilha 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 verifique:https://www.youtube.com/watch?v=mpRq-WFihz8

Resumo e destaques

1. O objetivo do Encrypted Mempools é 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 alcançar verdadeiramente uma resistência eficaz à censura, deve ser usado um mecanismo como a Lista de Inclusão do PBS. Caso contrário, o Construtor ainda pode exercer censura recusando-se a receber transações criptografadas.

3. Não é fácil provar que uma transação criptografada é válida. É necessário ter várias provas de conhecimento zero para provar a assinatura da transação, o valor de Nonce do iniciador da transação, taxas de processamento suficientes, etc.

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

5. Por fim, o mais importante é garantir que as transações possam ser desencriptadas —— Encriptação Garantida. Existem cinco métodos diferentes: Pure Trust (In-flight), Trusted Hardware Enclave, Threshold Encryption/Decryption, Delay Encryption/Decryption e Witness Encryption/Decryption. Cada método tem suas próprias vantagens e desvantagens.

Dados de referência e leitura recomendada

Mempools Criptografados

• 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 pelo MEV na camada de aplicação e na 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 reverem e melhorarem este post.

Aviso Legal：

1. Este artigo é reproduzido a partir de [techflowpost]. Todos os direitos de autor pertencem ao autor original [Will 阿望；Diane Cheung]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão resolver rapidamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe da Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.