*Nota do editor: O autor o compilou com base no artigo de introdução do ZK-EVM escrito anteriormente por Vitalik e apresentou detalhadamente os vários tipos de ZK-EVM e as diferenças entre eles. *
Há cerca de um ano, um grupo de ZK-EVMs anunciou que estava prestes a lançar uma testnet. Esses movimentos despertaram a curiosidade da comunidade Ethereum e geraram discussões sobre as nuances por trás de termos como equivalência Ethereum e equivalência EVM.
Para maior clareza, Vitalik escreveu um artigo importante intitulado “Diferentes tipos de ZK-EVMs” que classifica vários ZK-EVMs em quatro tipos e explica suas diferenças.
A ideia central é: o Tipo 1 (por exemplo, Taiko) é totalmente equivalente ao Ethereum, enquanto o Tipo 4 (por exemplo, zkSync) se destaca na geração eficiente de provas. Todos os outros tipos, Tipo 2, Tipo 2.5 e Tipo 3, estão no meio (por exemplo, Polygon zkEVM, Scroll, Linea).
A maioria dos ZK-EVMs são inicialmente do Tipo 2.5 e Tipo 3, com alguma intenção de evoluir para o Tipo 1 ou Tipo 2 revelada, embora estes projetos não tenham fornecido prazos ou compromissos específicos para isso.
**Este artigo enfoca as diferenças entre o Tipo 1 e o Tipo 2/Tipo 2.5 e descreve as possíveis consequências da quebra da equivalência do Ethereum. Também abordaremos brevemente outros tipos. **
O principal objetivo do ZK-EVM é escalar o Ethereum, ou seja, aumentar o rendimento do Ethereum enquanto mantém seus outros recursos (segurança, experiência do desenvolvedor, etc.). Idealmente, o ZK-EVM deve ser capaz de:
Demonstra a execução de bytecode nativo não modificado (cobrindo 100% dos opcodes Ethereum) de acordo com a especificação da Máquina Virtual Ethereum no Livro Amarelo.
Gere provas rapidamente com baixo custo.
Permite o reaproveitamento de 100% das ferramentas e infraestrutura desenvolvidas para Ethereum.
Permitir que qualquer dApp Ethereum seja reimplantado no ZK-EVM "no estado em que se encontra" ("no estado em que se encontra" significa que não são necessárias alterações nem compromissos).
Diferenças entre os tipos ZK-EVM
No mundo ZK-EVM, as diferenças vêm principalmente do nível de equivalência Ethereum/EVM, do impacto de elementos hostis ao ZK no custo e na velocidade de geração de provas e da complexidade da implementação do circuito (como construção de VM ou estado árvores).
Vamos analisar essas diferenças, distinguindo especificamente o Tipo 1 do Tipo 2/Tipo 2.5. Também abordaremos os casos de uso mais relevantes para cada tipo.
Ao comparar vários tipos, o gráfico a seguir é frequentemente usado:
Para aqueles que não trabalham em tempo integral na área de ZK-EVM, esta tabela pode parecer confusa, então vamos traduzir esses termos para termos leigos e dar uma olhada:
Este diagrama fornece uma imagem mais clara da aparência real de cada tipo, mas ainda pode ser um pouco obscuro. Vamos explorar completamente o mundo ZK-EVM explicando cada tipo individualmente.
Tipo 1: Equivalente a Ethereum
Vitalik Buterin:
“Tipo 1 ZK-EVM é o que precisamos para tornar a camada 1 do Ethereum mais escalável.”
O tipo 1 significa não alterar nenhuma parte do sistema Ethereum para facilitar a geração de provas. Nenhuma mudança no Ethereum significa nenhum comprometimento da segurança, já que a maioria das primitivas criptográficas (por exemplo, funções hash), infraestrutura de desenvolvedor (por exemplo, depuradores) ou infraestrutura de cadeia (por exemplo, clientes de execução) já passaram 9 anos de testes de campo.
O ZK-EVM tipo 1 não substitui nada: hashes, árvores de estado, árvores de transação, pré-compilação ou qualquer outra lógica de consenso, tudo é exatamente igual ao EVM da rede principal.
O Tipo 1 é o único que pode verificar a própria cadeia Ethereum - desde blocos inteiros até a execução de transações, contratos inteligentes e lógica de conta.
Tipo 2: Equivalente a EVM
O tipo 2 torna a geração de provas mais rápida e o desenvolvimento de circuitos mais fácil, removendo algumas peças que não são propícias ao ZK. No entanto, devido às consequências disso, pode tornar o desenvolvimento de outras partes do ZK-rollup (como o software do nó) mais complexo. Essas complexidades podem ser causadas por incompatibilidades entre as melhores práticas e ferramentas de teste estabelecidas e as mudanças que estão sendo implementadas (como uma árvore de estado alterada).
*Nota: Equivalente a Ethereum e equivalente a EVM não são a mesma coisa. Embora a equivalência ao Ethereum signifique que nenhuma parte do Ethereum foi alterada, o que significa que é totalmente compatível com todos os dApps do Ethereum, a equivalência ao EVM permite alterações nas estruturas de dados (como estruturas de blocos ou árvores de estado). *
Embora esses ajustes possam parecer pequenos, eles afetam a compatibilidade do Ethereum. A alteração das estruturas de dados pode fazer com que os dApps Ethereum sejam incompatíveis com o ZK-EVM Tipo 2, especialmente ao validar provas Merkle sobre transações, recibos ou estados anteriores (como através de pontes de cadeia).
Exclua elementos hostis do ZK
As modificações no Ethereum visam simplificar o desenvolvimento e aumentar a velocidade de geração de provas. O objetivo é podar as partes do Ethereum que dependem de criptografia hostil de conhecimento zero. Em termos mais técnicos, partes que requerem um grande número de portas (operações de adição e multiplicação) devido a domínios não locais (como funções hash), um grande número de multiplicações multiescalares e/ou transformadas rápidas de Fourier (FFT); ou Apenas a parte que requer muita manipulação.
Exemplos específicos de elementos hostis de conhecimento zero que o ZK-EVM Tipo 2 pode modificar:
Função hash: Embora Ethereum use a função hash Keccak, muitos ZK-EVMs usam a função hash Poseidon, que requer um número significativamente menor de portas. Por exemplo, vamos estimar quantas funções hash de cada tipo podem ser calculadas por segundo (ou seja, uma comparação que demonstra a velocidade de geração).
As funções hash Poseidon têm vantagens significativas de velocidade na geração de provas.
No entanto, é importante notar que as primitivas criptográficas mais recentes não são tão populares em relação às primitivas criptográficas estabelecidas que são amplamente reconhecidas pela comunidade. Embora o Poseidon possa oferecer velocidade, as características testadas em batalha do Keccak o tornam mais robusto e seguro, pois é amplamente adotado.
É por isso que o Keccak, apesar de ser mais antigo e adotado por uma comunidade mais ampla (em outras indústrias, como sistemas de segurança ou sensores em dispositivos inteligentes), pode ser considerado mais experimentado e testado do que o Poseidon, que afinal está dentro da comunidade ZK New hash funções para criar e usar.
Árvores de estado para armazenamento de dados: por exemplo, enquanto Ethereum usa árvores Merkle Patricia (usando hashing Keccak), alguns ZK-EVMs Tipo 2 escolhem árvores Merkle esparsas (usando hashing Poseidon). Alterar a árvore de estados pode causar algumas incompatibilidades. Por exemplo, a árvore Merkle do Ethereum tem diferentes tipos de nós e usa RLP para codificar dados, o que é algo difícil de fazer em ZK.
Estrutura do bloco: Os blocos contêm uma grande quantidade de informações. No entanto, ao explorar L2, nos preocupamos apenas com o ution_payload_header (ou seja, o hash do bloco). Na imagem abaixo está a estrutura (hash de bloco) de todos os dados contidos em ution_payload_header.
**Observação: a alteração de qualquer um desses componentes quebrará a equivalência do Ethereum. **
Tipo 2.5: Equivalente a EVM, considerando custo do gás
O tipo 2.5 ZK-EVM aumenta o custo do gás de operações específicas que são difíceis de comprovar usando a tecnologia ZK em EVM.
Dado o limite de gás por bloco do Ethereum (30 M de gás), aumentar o custo do gás por opcode resulta em menos opcodes por bloco. Portanto, opcodes menos complexos podem ser incluídos em um bloco. Opcodes mais simples permitem que os circuitos sejam menores e as provas sejam geradas mais rapidamente.
gás é uma unidade de medida de trabalho.
*Os preços do Opcode são calculados em gás.
Opcodes especificam operações dentro de instruções em linguagem de máquina.
Um programa é uma lista estática de opcodes. A execução do programa é um rastreamento de execução.
Um rastreamento de execução é uma lista ordenada específica de opcodes executados por um programa.
As partes que são difíceis de provar ZK incluem:
Opcodes Keccak e alguns outros opcodes que dependem do Keccak.
Pré-compilado: funções acessíveis ao EVM. Alguns deles fornecem tarefas complexas ou matematicamente complexas, como funções criptográficas (como blake 2 f ou sha 256). Eles não são executados dentro do EVM, mas sim como funções codificadas no cliente de execução e expostas ao EVM usando CALLs para endereços especiais.
Acesso à memória: por exemplo, aumentando o tamanho do slot de memória (por exemplo, Ethereum usa memória alinhada a bytes, enquanto Polygon zkEVM usa slots de memória de 32 bytes). Para tornar esta mudança possível, a lógica interna de certos opcodes (como MLOAD) teve que ser alterada.
Armazenamento (ou seja, alteração da função hash ou árvore de estado conforme descrito acima).
Alterar os custos do gás pode reduzir a compatibilidade das ferramentas do desenvolvedor e quebrar alguns dApps. Por exemplo, um contrato inteligente que executa frequentemente opcodes com custos crescentes de gás pode exceder o limite de gás do bloco e não ser executado.
Tipo 3: Quase equivalente ao EVM
O ZK-EVM tipo 3 omite a pré-compilação não aplicável ao ZK e pode ajustar o acesso à memória e ao armazenamento.
Os dApps que dependiam de aplicativos pré-compilados removidos precisarão ser reescritos. Em casos incomuns, diferenças em como os casos extremos são tratados pelo ZK-EVM Tipo 3 e pelo EVM original podem exigir ajustes no dApp.
Tipo 4 (equivalente a linguagem de alto nível)
O Tipo 4 já está longe do EVM.
O código-fonte do contrato inteligente escrito em uma linguagem de alto nível (por exemplo, Solidity, Zinc) é compilado em uma representação intermediária, gerando opcodes adequados para máquinas virtuais compatíveis com ZK.
Este método evita a geração de provas ZK para cada etapa de execução do EVM, reduzindo bastante o trabalho de prova.
Mesmo que o contrato possa ser compilado, será necessário mais trabalho se o dApp usar bytecode escrito à mão EVM.
*O ZK-EVM tipo 4 também requer suas próprias ferramentas de desenvolvedor (somente nível de código de operação), como depuradores e rastreadores.
No circuito ZK que prova a trajetória de execução, cada etapa implementa a restrição e o custo de cada etapa é a soma de todos os opcodes. Portanto, o ZK-EVM Tipo 4 foi projetado para usar o menor número possível de opcodes complexos para otimizar a eficiência.
Vale ressaltar que os opcodes personalizados (opcodes não cobertos pelo Ethereum) possibilitam a passagem de novos recursos que não são possíveis no Ethereum por padrão. Por exemplo, faça várias chamadas para execução por meio do recurso de abstração de conta ou lance uma carteira de contrato inteligente usando uma solução pronta para uso como Argent.
Resumir
Diferentes tipos de ZK-EVM priorizam diferentes objetivos e características. O Tipo 1 concentra-se na equivalência Ethereum, enquanto o Tipo 4 prioriza a geração eficiente de provas. Outros tipos ficam entre esses extremos, e muitos protocolos ZK-EVM Tipo 2 e 3 anunciaram sua intenção de migrar para equivalentes Ethereum.
Estes quatro tipos de classificação podem não ser o estado final do rollup ZK e podem estar sujeitos a modificações adicionais no futuro. Por exemplo, alguns ZK-EVMs podem se tornar híbridos, Tipo 1/2 podem desenvolver soluções Tipo 4 (com a maior eficiência possível) e fornecer dApps com ambas as opções, enquanto ZK-EVMs Tipo 3 e 4 podem adicionar opções equivalentes ao Ethereum.
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.
Do Tipo1 ao Tipo4, quais são as diferenças entre os vários tipos de ZK-EVM?
Autor original| Lisa Akselrod
Compilado | Odaily Planet Daily 0xAyA
*Nota do editor: O autor o compilou com base no artigo de introdução do ZK-EVM escrito anteriormente por Vitalik e apresentou detalhadamente os vários tipos de ZK-EVM e as diferenças entre eles. *
Há cerca de um ano, um grupo de ZK-EVMs anunciou que estava prestes a lançar uma testnet. Esses movimentos despertaram a curiosidade da comunidade Ethereum e geraram discussões sobre as nuances por trás de termos como equivalência Ethereum e equivalência EVM.
Para maior clareza, Vitalik escreveu um artigo importante intitulado “Diferentes tipos de ZK-EVMs” que classifica vários ZK-EVMs em quatro tipos e explica suas diferenças.
A ideia central é: o Tipo 1 (por exemplo, Taiko) é totalmente equivalente ao Ethereum, enquanto o Tipo 4 (por exemplo, zkSync) se destaca na geração eficiente de provas. Todos os outros tipos, Tipo 2, Tipo 2.5 e Tipo 3, estão no meio (por exemplo, Polygon zkEVM, Scroll, Linea).
A maioria dos ZK-EVMs são inicialmente do Tipo 2.5 e Tipo 3, com alguma intenção de evoluir para o Tipo 1 ou Tipo 2 revelada, embora estes projetos não tenham fornecido prazos ou compromissos específicos para isso.
**Este artigo enfoca as diferenças entre o Tipo 1 e o Tipo 2/Tipo 2.5 e descreve as possíveis consequências da quebra da equivalência do Ethereum. Também abordaremos brevemente outros tipos. **
O principal objetivo do ZK-EVM é escalar o Ethereum, ou seja, aumentar o rendimento do Ethereum enquanto mantém seus outros recursos (segurança, experiência do desenvolvedor, etc.). Idealmente, o ZK-EVM deve ser capaz de:
Diferenças entre os tipos ZK-EVM
No mundo ZK-EVM, as diferenças vêm principalmente do nível de equivalência Ethereum/EVM, do impacto de elementos hostis ao ZK no custo e na velocidade de geração de provas e da complexidade da implementação do circuito (como construção de VM ou estado árvores).
Vamos analisar essas diferenças, distinguindo especificamente o Tipo 1 do Tipo 2/Tipo 2.5. Também abordaremos os casos de uso mais relevantes para cada tipo.
Ao comparar vários tipos, o gráfico a seguir é frequentemente usado:
Para aqueles que não trabalham em tempo integral na área de ZK-EVM, esta tabela pode parecer confusa, então vamos traduzir esses termos para termos leigos e dar uma olhada:
Este diagrama fornece uma imagem mais clara da aparência real de cada tipo, mas ainda pode ser um pouco obscuro. Vamos explorar completamente o mundo ZK-EVM explicando cada tipo individualmente.
Tipo 1: Equivalente a Ethereum
Vitalik Buterin:
O tipo 1 significa não alterar nenhuma parte do sistema Ethereum para facilitar a geração de provas. Nenhuma mudança no Ethereum significa nenhum comprometimento da segurança, já que a maioria das primitivas criptográficas (por exemplo, funções hash), infraestrutura de desenvolvedor (por exemplo, depuradores) ou infraestrutura de cadeia (por exemplo, clientes de execução) já passaram 9 anos de testes de campo.
O ZK-EVM tipo 1 não substitui nada: hashes, árvores de estado, árvores de transação, pré-compilação ou qualquer outra lógica de consenso, tudo é exatamente igual ao EVM da rede principal.
Tipo 2: Equivalente a EVM
O tipo 2 torna a geração de provas mais rápida e o desenvolvimento de circuitos mais fácil, removendo algumas peças que não são propícias ao ZK. No entanto, devido às consequências disso, pode tornar o desenvolvimento de outras partes do ZK-rollup (como o software do nó) mais complexo. Essas complexidades podem ser causadas por incompatibilidades entre as melhores práticas e ferramentas de teste estabelecidas e as mudanças que estão sendo implementadas (como uma árvore de estado alterada).
*Nota: Equivalente a Ethereum e equivalente a EVM não são a mesma coisa. Embora a equivalência ao Ethereum signifique que nenhuma parte do Ethereum foi alterada, o que significa que é totalmente compatível com todos os dApps do Ethereum, a equivalência ao EVM permite alterações nas estruturas de dados (como estruturas de blocos ou árvores de estado). *
Embora esses ajustes possam parecer pequenos, eles afetam a compatibilidade do Ethereum. A alteração das estruturas de dados pode fazer com que os dApps Ethereum sejam incompatíveis com o ZK-EVM Tipo 2, especialmente ao validar provas Merkle sobre transações, recibos ou estados anteriores (como através de pontes de cadeia).
Exclua elementos hostis do ZK
As modificações no Ethereum visam simplificar o desenvolvimento e aumentar a velocidade de geração de provas. O objetivo é podar as partes do Ethereum que dependem de criptografia hostil de conhecimento zero. Em termos mais técnicos, partes que requerem um grande número de portas (operações de adição e multiplicação) devido a domínios não locais (como funções hash), um grande número de multiplicações multiescalares e/ou transformadas rápidas de Fourier (FFT); ou Apenas a parte que requer muita manipulação.
Exemplos específicos de elementos hostis de conhecimento zero que o ZK-EVM Tipo 2 pode modificar:
As funções hash Poseidon têm vantagens significativas de velocidade na geração de provas.
No entanto, é importante notar que as primitivas criptográficas mais recentes não são tão populares em relação às primitivas criptográficas estabelecidas que são amplamente reconhecidas pela comunidade. Embora o Poseidon possa oferecer velocidade, as características testadas em batalha do Keccak o tornam mais robusto e seguro, pois é amplamente adotado.
É por isso que o Keccak, apesar de ser mais antigo e adotado por uma comunidade mais ampla (em outras indústrias, como sistemas de segurança ou sensores em dispositivos inteligentes), pode ser considerado mais experimentado e testado do que o Poseidon, que afinal está dentro da comunidade ZK New hash funções para criar e usar.
**Observação: a alteração de qualquer um desses componentes quebrará a equivalência do Ethereum. **
Tipo 2.5: Equivalente a EVM, considerando custo do gás
O tipo 2.5 ZK-EVM aumenta o custo do gás de operações específicas que são difíceis de comprovar usando a tecnologia ZK em EVM.
Dado o limite de gás por bloco do Ethereum (30 M de gás), aumentar o custo do gás por opcode resulta em menos opcodes por bloco. Portanto, opcodes menos complexos podem ser incluídos em um bloco. Opcodes mais simples permitem que os circuitos sejam menores e as provas sejam geradas mais rapidamente.
As partes que são difíceis de provar ZK incluem:
Alterar os custos do gás pode reduzir a compatibilidade das ferramentas do desenvolvedor e quebrar alguns dApps. Por exemplo, um contrato inteligente que executa frequentemente opcodes com custos crescentes de gás pode exceder o limite de gás do bloco e não ser executado.
Tipo 3: Quase equivalente ao EVM
O ZK-EVM tipo 3 omite a pré-compilação não aplicável ao ZK e pode ajustar o acesso à memória e ao armazenamento.
Os dApps que dependiam de aplicativos pré-compilados removidos precisarão ser reescritos. Em casos incomuns, diferenças em como os casos extremos são tratados pelo ZK-EVM Tipo 3 e pelo EVM original podem exigir ajustes no dApp.
Tipo 4 (equivalente a linguagem de alto nível)
O Tipo 4 já está longe do EVM.
O código-fonte do contrato inteligente escrito em uma linguagem de alto nível (por exemplo, Solidity, Zinc) é compilado em uma representação intermediária, gerando opcodes adequados para máquinas virtuais compatíveis com ZK.
No circuito ZK que prova a trajetória de execução, cada etapa implementa a restrição e o custo de cada etapa é a soma de todos os opcodes. Portanto, o ZK-EVM Tipo 4 foi projetado para usar o menor número possível de opcodes complexos para otimizar a eficiência.
Vale ressaltar que os opcodes personalizados (opcodes não cobertos pelo Ethereum) possibilitam a passagem de novos recursos que não são possíveis no Ethereum por padrão. Por exemplo, faça várias chamadas para execução por meio do recurso de abstração de conta ou lance uma carteira de contrato inteligente usando uma solução pronta para uso como Argent.
Resumir
Diferentes tipos de ZK-EVM priorizam diferentes objetivos e características. O Tipo 1 concentra-se na equivalência Ethereum, enquanto o Tipo 4 prioriza a geração eficiente de provas. Outros tipos ficam entre esses extremos, e muitos protocolos ZK-EVM Tipo 2 e 3 anunciaram sua intenção de migrar para equivalentes Ethereum.
Estes quatro tipos de classificação podem não ser o estado final do rollup ZK e podem estar sujeitos a modificações adicionais no futuro. Por exemplo, alguns ZK-EVMs podem se tornar híbridos, Tipo 1/2 podem desenvolver soluções Tipo 4 (com a maior eficiência possível) e fornecer dApps com ambas as opções, enquanto ZK-EVMs Tipo 3 e 4 podem adicionar opções equivalentes ao Ethereum.