Explique os cinco tipos de ZK-EVM em detalhes: arquitetura, vantagens e desvantagens e soluções

Autor do texto original: s Compilação do texto original: Deep Tide TechFlow

Este artigo explora cinco tipos de ZK-EVM em detalhes, cada um com sua arquitetura exclusiva, vantagens e desvantagens e possíveis soluções.

Além disso, o artigo também lista alguns exemplos práticos de projetos para que os leitores possam entender melhor o desempenho desses tipos em aplicações práticas. Seja você um desenvolvedor de blockchain ou um leitor interessado na tecnologia blockchain, este artigo fornecerá informações detalhadas e concisas.

Vamos explorar os tipos de ZK-EVMs, seus prós e contras.

1. Tipo 1: completamente equivalente ao Ethereum;

2. Tipo 2: totalmente equivalente ao EVM;

3. Tipo 2.5: Parcialmente equivalente a EVM;

4. Tipo 3: quase equivalente ao EVM;

5. Tipo 4: onde a linguagem de alto nível é equivalente.

Tipo 1: totalmente equivalente ao Ethereum

Arquitetura: É exatamente igual ao Ethereum e não altera nenhuma parte do sistema Ethereum.

vantagem

Compatibilidade perfeita:

• Capacidade de verificar blocos Ethereum;
• Ajude a tornar o Ethereum L1 mais escalável;
• Adequado para Rollups, pois eles podem reutilizar muita infraestrutura.

deficiência

Compatibilidade perfeita:

• Ethereum não foi originalmente projetado para a funcionalidade ZK;
• Muitos componentes do Ethereum requerem muita computação para gerar provas ZK (ZKP);
• As provas dos blocos Ethereum levam muitas horas para serem geradas.

Solução do problema:

• Provador de paralelização em larga escala;
• ZK-SNARK ASIC.

Tipo 2: totalmente equivalente ao EVM

Arquitetura:

• A estrutura de dados (estrutura de bloco e árvore de estado) é significativamente diferente do Ethereum;
• Totalmente compatível com aplicativos existentes;
• Pequenas modificações no Ethereum para facilitar o desenvolvimento e gerar provas mais rapidamente.

vantagem

• Fornece tempos de prova mais rápidos que o Tipo 1;
• A estrutura de dados não é acessada diretamente pelo EVM;
• Aplicações em execução no Ethereum: provavelmente serão executadas no Tipo 2;
• Suporte para ferramentas de depuração EVM existentes e outras infra-estruturas de desenvolvimento.

deficiência

Antes de entender as desvantagens, primeiro entenda o que é “Keccak”:

• O algoritmo de hash da blockchain Ethereum;
• Usado para proteger dados no Ethereum;
• Certifique-se de que a mensagem seja convertida em um hash.

O tipo 2 não é compatível com aplicativos que verificam provas Merkle de blocos históricos para verificar informações sobre transações históricas, recibos/estados. Isso ocorre porque se o algoritmo de hash mudar (não mais Keccak), a prova se tornará inválida.

Podemos pensar em Keccak como uma linguagem que usa provas de Merkle (alfabetos). Se o ZK-EVM substituir Keccak por outro algoritmo de hash (como Poseidon), as provas de Merkle se tornarão desconhecidas e os aplicativos não poderão lê-los e validar suas reivindicações.

Solução potencial para deficiências: Ethereum pode adicionar pré-compilação futura de acesso ao histórico escalável.

projeto

• Rolagem; *Polígono Hermez.

No entanto, esses projetos ainda não implementaram uma pré-compilação mais sofisticada, portanto, podem ser considerados Tipo 2 incompletos.

Tipo 2.5: Parcialmente equivalente ao EVM

Arquitetura:

Aumentar o custo do gás de operações específicas de EVM que são difíceis de provar ZK;

• Pré-compilado;
• Código operacional Keccak;
• O modo de chamar o contrato;
• Acessar a memória;
• armazenar.

vantagem

• Tempo de prova de pior caso significativamente melhorado;
• Mais seguro do que fazer alterações mais profundas na pilha EVM.

deficiência

• A compatibilidade das ferramentas de desenvolvimento é reduzida;
• Alguns aplicativos não funcionarão.

Tipo 3: Quase equivalente ao EVM

Arquitetura:

• Na implementação do ZK-EVM, algumas funções extremamente difíceis de implementar são excluídas, geralmente pré-compiladas;
• ZK-EVM tem pequenas diferenças em como lida com código de contrato, memória ou pilha.

vantagem

• encurtar o tempo de verificação;
• Tornar o EVM mais fácil de desenvolver;
• O objetivo é exigir o mínimo de reescritas para aplicativos menos compatíveis.

deficiência

• Mais incompatibilidades;
• Os aplicativos que usam pré-compilação que foram removidos no Tipo 3 precisarão ser reescritos.

projeto

Atualmente, Scroll e Polygon são considerados Tipo 3, no entanto, a equipe ZK-EVM não deve se contentar em ser Tipo 3, Tipo 3 é um estágio de transição onde ZK-EVM adiciona pré-compilação para melhorar a compatibilidade e passa para o Tipo 2.5.

Tipo 4: equivalente de linguagem de alto nível

Arquitetura:

• Aceitar código de contrato inteligente escrito em linguagens de alto nível (como Solidity, Vyper);
• Compilado para uma linguagem projetada para ser compatível com ZK-SNARK.

vantagem

• Tempo de prova muito rápido;
• Redução do overhead (custo, tempo e esforço computacional);
• Reduzir a barreira para se tornar um provador: aumentar o grau de descentralização.

falha

• Em um sistema tipo 4, o endereço do contrato pode ser diferente do endereço no EVM, porque o endereço depende do bytecode exato;
• Isso significa que se os ZK-EVMs tipo 4 não tiverem bytecodes, eles não poderão criar endereços;
• O tipo 4 será incompatível com aplicações baseadas em contratos contrafactuais nos casos acima;
• Muitas infraestruturas de depuração não são portáveis porque rodam em bytecode EVM.

projeto

• zkSync

Por fim, podemos comparar os tipos acima juntos para ajudar todos a entender rapidamente os diferentes zkEVMs.