A Ethereum é uma plataforma líder para contratos inteligentes e aplicativos descentralizados (dApps), mas enfrenta desafios significativos de escalabilidade à medida que sua popularidade cresce. A Máquina Virtual da Ethereum de Conhecimento Zero (ZK-EVM) surge como uma solução promissora para melhorar a escalabilidade e o desempenho da Ethereum. Neste artigo, aprofundaremos o conceito das ZK-EVMs, explorando seus princípios fundamentais, arquitetura, funcionamento e aprimoramentos adicionais.
Sumário
- Introdução
- O que é uma ZK-EVM?
- Princípios Fundamentais das ZK-EVMs
- Arquitetura e Funcionamento
- Vantagens das ZK-EVMs
- Desafios e Avanços Futuros
- A EVM, Opcodes e Bytecode
- Linguagens de Alto Nível e Compilação de Bytecode
- Por que a Compatibilidade com EVM e Opcodes é Importante nas ZK-EVMs
- Tipos de ZK-EVMs
- Conclusão
- Referências
Introdução
Como a Ethereum é uma das plataformas líderes em contratos inteligentes e aplicativos descentralizados, ela tem testemunhado um notável aumento em sua popularidade e adoção em diversos setores. No entanto, esse sucesso crescente também trouxe consigo desafios significativos de escalabilidade, levando a congestionamentos na rede e elevadas taxas de transação. Diante desse cenário, surgem novas tecnologias e abordagens inovadoras para enfrentar tais obstáculos. Entre elas, a Máquina Virtual da Ethereum de Conhecimento Zero surge como uma solução promissora que promete elevar a eficiência e o desempenho da plataforma.
O que é uma ZK-EVM?
A ZK-EVM é uma Máquina Virtual da Ethereum (EVM) aprimorada que utiliza a tecnologia de provas de conhecimento zero (provas ZK, ou Zero-Knowledge Proofs) para alcançar a escalabilidade. As provas ZK permitem que um proponente demonstre o conhecimento de informações confidenciais, sem a necessidade de revelar essas informações explicitamente.
A ZK-EVM usa rollups (um tipo de solução de escalabilidade de camada 2) baseados em provas de conhecimento zero, conhecidos como ZK-rollups, para agrupar várias transações fora da cadeia em um único lote. Em seguida, cria uma prova criptográfica para demonstrar a validade desse lote. Os validadores da Ethereum podem verificar essa prova sem precisar processar cada transação individualmente, o que aumenta a eficiência da blockchain e melhora a escalabilidade.
Princípios Fundamentais das ZK-EVMs
As ZK-EVMs são baseadas em princípios fundamentais que as tornam uma solução eficaz para a escalabilidade da Ethereum:
Provas de Conhecimento Zero: As provas ZK permitem que o proponente prove a posse de informações confidenciais sem revelar os detalhes dessas informações. Isso é alcançado através de algoritmos criptográficos que produzem uma prova verificável da validade do lote de transações.
Agrupamento Eficiente: O agrupamento eficiente de várias transações em um único lote reduz a sobrecarga de processamento na blockchain principal. Em vez de processar cada transação individualmente, a ZK-EVM permite que várias transações sejam tratadas como uma única transação, o que aumenta a escalabilidade.
Verificação Criptográfica: A prova criptográfica gerada pela ZK-EVM é verificada na blockchain Ethereum para confirmar a validade do lote de transações. Essa verificação é rápida e eficiente, graças ao uso de provas de conhecimento zero.
Arquitetura e Funcionamento
A arquitetura das ZK-EVMs é composta por três componentes principais:
Gerador de Provas (Prover): O Gerador de Provas é responsável por criar a prova criptográfica que representa o lote de transações. Ele utiliza protocolos de prova de conhecimento zero, como zk-SNARKs ou zk-STARKs, para garantir a segurança e a eficiência da prova.
Verificador de Provas (Verifier): O Verificador de Provas é executado na blockchain Ethereum e é responsável por verificar a prova gerada pelo Gerador de Provas. A verificação da prova não exige que todas as operações das transações originais sejam processadas, tornando-a rápida e escalável.
Contratos Inteligentes ZK-EVM: Os Contratos Inteligentes específicos da ZK-EVM gerenciam o processamento e a verificação dos lotes de transações. Eles fornecem uma interface para os usuários interagirem com os rollups, enviando e recebendo transações agrupadas.
Vantagens das ZK-EVMs
As ZK-EVMs oferecem várias vantagens cruciais:
Escalabilidade Aprimorada: Ao agrupar e verificar várias transações em um único lote, as ZK-EVMs aumentam significativamente a capacidade de processamento da rede Ethereum, permitindo um maior número de transações por segundo.
Eficiência de Custos: A compactação e o agrupamento de transações reduzem os custos de gás, tornando as transações mais acessíveis e econômicas para os usuários.
Privacidade e Segurança: A criptografia utilizada nas provas ZK garante a privacidade das informações confidenciais dentro das transações agrupadas, garantindo maior segurança para os usuários.
Compatibilidade com a EVM: As ZK-EVMs são projetadas para serem compatíveis com a Máquina Virtual da Ethereum existente e a linguagem de programação Solidity, facilitando a adoção e integração com aplicativos já existentes na plataforma Ethereum.
Desafios e Avanços Futuros
Embora as ZK-EVMs sejam uma solução promissora para melhorar a escalabilidade da Ethereum, ainda existem desafios a serem superados:
Tempo de Geração de Provas: O tempo necessário para gerar as provas ainda pode ser significativo, dependendo da complexidade das transações agrupadas. Pesquisas contínuas na área de algoritmos de prova de conhecimento zero são necessárias para reduzir esse tempo.
Complexidade de Desenvolvimento: A implementação das ZK-EVMs requer conhecimentos especializados em criptografia e teoria dos números. Simplificar o desenvolvimento e a auditoria de soluções ZK-EVM será crucial para sua adoção generalizada.
Custos de Implementação: O desenvolvimento e a implementação de ZK-EVMs podem ser caros e exigir recursos financeiros substanciais. Avaliar a viabilidade econômica das soluções é fundamental para garantir sua aceitação no ecossistema Ethereum.
A EVM, Opcodes e Bytecode
A EVM é o ambiente de execução para contratos inteligentes na Ethereum. Além de armazenar todas as contas e saldos, de forma semelhante ao Bitcoin, a Ethereum também mantém o que é chamado de "estado da máquina". Esse estado é armazenado em uma estrutura de dados chamada trie (árvore de prefixos), e ele muda de bloco para bloco após a execução das transações contidas em um bloco. A EVM é determinística, o que significa que um conjunto de instruções executado em um determinado estado sempre resultará no mesmo novo estado.
Uma analogia simples para isso é imaginar um jogo de xadrez. O tabuleiro (Ethereum) tem um grande número de estados possíveis do jogo (a Ethereum possui um número infinito de estados possíveis). O jogo tem regras sobre quais movimentos (transações) podem ser realizados, e restrições sobre quem pode realizar quais ações (usando contas, assinaturas, etc.). Assim como no xadrez, os jogadores (usuários) fazem movimentos (enviam transações), e o jogo (Ethereum) determina as regras permitidas e as executa, resultando em um novo estado do tabuleiro (mundo) após cada movimento (bloco).
Dada uma entrada, ela produz uma saída determinística. Portanto, é muito útil descrever formalmente a Ethereum como tendo uma função de transição de estado. A documentação da Ethereum descreve isso como uma função matemática:
Y(S, T) = S'
Dado um estado válido anterior (S) e um novo conjunto de transações válidas (T), a função de transição de estado Ethereum, Y(S, T), produz um novo estado de saída válido (S').
Linguagens de Alto Nível e Compilação de Bytecode
Assim como na Ethereum, ou em qualquer outra blockchain compatível com a EVM, contratos inteligentes são normalmente escritos em Solidity (embora existam outras linguagens como Vyper e Yul). E como em todas as outras linguagens de alto nível, essas linguagens são destinadas a serem facilmente legíveis para humanos, então não precisamos nos preocupar com coisas complicadas como registros, endereços de memória e pilhas de chamadas, podendo focar na usabilidade.
No entanto, as máquinas não entendem o Solidity em si, incluindo a própria EVM. A EVM entende o bytecode, que é um código binário legível pela máquina. O bytecode representa uma série de opcodes (códigos operacionais) da EVM, onde cada um realiza uma operação específica, como operações aritméticas, manipulação de dados e operações específicas da blockchain, como obter o saldo de uma conta.
Cada item no bytecode é uma palavra de 256 bits, escolhida para facilitar o uso com criptografia de 256 bits (como hashes Keccak-256 ou assinaturas secp256k1). Para que nossos contratos inteligentes sejam executados pela EVM, precisamos convertê-los assim:
Solidity → Opcodes → Bytecode
Felizmente, existem compiladores que fazem isso por nós. Compilar contratos inteligentes é essencial para podermos interagir com a EVM e aproveitar todas as capacidades da plataforma Ethereum. Ao compreender os conceitos de EVM, opcodes e bytecode, os desenvolvedores podem criar contratos inteligentes eficientes, seguros e compatíveis com a EVM, impulsionando a inovação no ecossistema Ethereum.
Por que a Compatibilidade com EVM e Opcodes é Importante nas ZK-EVMs
Em agosto de 2022, em uma postagem em seu blog, Vitalik Buterin categorizou as ZK-EVMs em diferentes tipos com base na compatibilidade com a EVM e nos tempos de geração de provas ZK. A compatibilidade com a EVM e os tempos de geração de provas de conhecimento zero desempenham um papel crucial no desempenho e eficiência das ZK-EVMs, especialmente quando aplicadas aos ZK-rollups.
Construir um rollup compatível com a EVM apresenta desafios, pois a Ethereum não foi originalmente projetada para ser compatível com provas de conhecimento zero. Certos opcodes da EVM são mais compatíveis do que outros, exigindo uma quantidade considerável de cálculos computacionais para a geração de provas ZK. As ZK-EVMs podem optar por manter total equivalência para todos os opcodes da EVM, introduzir pequenas modificações em alguns opcodes ou até mesmo produzir bytecode completamente diferente, mantendo a equivalência em linguagens de alto nível.
Diferentes abordagens foram adotadas por vários projetos de ZK-EVM, cada um com suas compensações entre desempenho (velocidade de geração de provas ZK) e compatibilidade com a EVM. Compreender essas distinções é crucial na escolha da ZK-EVM mais adequada para casos de uso específicos, otimizando a escalabilidade e garantindo a integração perfeita com contratos inteligentes e aplicativos existentes na Ethereum. As ZK-EVMs oferecem soluções promissoras para os desafios de escalabilidade da Ethereum, e seu contínuo desenvolvimento e implementação desempenharão um papel fundamental na realização do pleno potencial de aplicativos descentralizados na blockchain Ethereum.
Tipos de ZK-EVMs
Créditos: Vitalik Buterin
Em sua postagem de blog de agosto de 2022, Vitalik Buterin categorizou as ZK-EVMs em quatro (e meio) diferentes categorias, intituladas "Os diferentes tipos de zkEVMs". Nessa postagem, Vitalik classificou os tipos com base em sua compatibilidade com a EVM e nos tempos de geração de provas ZK (desempenho). Essas categorias são as seguintes:
Tipo 1
As ZK-EVMs de Tipo 1 visam ser totalmente equivalentes à Ethereum. Elas não modificam nenhuma parte do sistema Ethereum para facilitar a geração de provas, e mantêm hashes, árvores de estado, árvores de transações e outras lógicas no consenso.
A vantagem desse Tipo de ZK-EVM é sua compatibilidade perfeita com a lógica de execução de transações, contratos inteligentes e contas da Ethereum. No longo prazo, elas são necessárias para tornar a própria Ethereum mais escalável. Elas também são ideais para rollups, pois permitem a reutilização de muita infraestrutura, como os clientes de execução Ethereum.
A desvantagem das ZK-EVMs de Tipo 1 é o tempo necessário para gerar as provas, já que a Ethereum não foi originalmente projetada para ser compatível com provas de conhecimento zero. Atualmente, as provas para blocos Ethereum levam muitas horas para serem produzidas.
Um exemplo de ZK-EVMs de Tipo 1 é a ZK-EVM Community Edition, que conta com contribuições de várias partes interessadas da comunidade, incluindo Privacy and Scaling Explorations, a equipe Scroll, Taiko e outros.
Tipo 2
As ZK-EVMs de Tipo 2 buscam ser equivalentes exatos à EVM, mas não totalmente equivalentes à Ethereum. Ou seja, elas se parecem exatamente com a Ethereum "interna", mas têm algumas diferenças "externas", especialmente em estruturas de dados como a estrutura de blocos e a árvore de estado. O objetivo é ser totalmente compatível com as aplicações existentes, mas fazer algumas pequenas modificações na Ethereum para facilitar o desenvolvimento e acelerar a geração de provas.
A vantagem da ZK-EVM de Tipo 2 é a equivalência perfeita no nível da Máquina Virtual. Isso significa que as aplicações que funcionam na Ethereum quase sempre funcionariam em um rollup ZK-EVM de Tipo 2. Você não poderia usar os clientes de execução da Ethereum como são, mas poderia usar com algumas modificações, e ainda seria capaz de usar as ferramentas de depuração da EVM e a maior parte da infraestrutura de desenvolvimento.
A desvantagem é que, embora elas ofereçam tempos de provas mais rápidos que o Tipo 1, ainda há problemas de lentidão, devido às ineficiências e à falta de compatibilidade com o ZK inerentes à EVM. Por exemplo, a operação MLOAD (Memory Load) pode ser lenta porque pode ler qualquer bloco de 32 bytes, incluindo blocos "não alinhados".
Projetos como a ZK-EVM da Scroll e a Polygon Hermez estão trabalhando para construir uma ZK-EVM de Tipo 2. No entanto, nenhum deles chegou lá ainda; em particular, muitos dos contratos pré-compilados mais complicados ainda não foram implementados. Portanto, no momento, ambos os projetos são considerados de Tipo 3.
Tipo 2.5
As ZK-EVMs de Tipo 2.5 são equivalentes à EVM, exceto pelos custos de gás para operações específicas. Uma maneira de melhorar significativamente os tempos mais lentos de prova é aumentar muito os custos de gás de operações específicas na EVM que são muito difíceis de provar com o ZK. Isso pode envolver contratos pré-compilados, o opcode KECCAK e possivelmente padrões específicos de chamada de contratos ou acesso à memória ou armazenamento ou reversão.
A mudança nos custos de gás pode reduzir a compatibilidade das ferramentas de desenvolvimento e interromper algumas aplicações, mas geralmente é considerada menos arriscada do que mudanças mais "profundas" na EVM. Os desenvolvedores devem tomar cuidado para não exigir mais gás em uma transação do que cabe em um bloco e nunca fazer chamadas com quantidades de gás pré-determinadas.
Uma alternativa para gerenciar restrições de recursos é simplesmente estabelecer limites rígidos sobre o número de vezes que cada operação pode ser chamada. Isso é mais fácil de implementar em circuitos, mas é menos compatível com as suposições de segurança da EVM. Essa abordagem seria melhor classificada como Tipo 3 em vez de Tipo 2.5.
Tipo 3
As ZK-EVMs de Tipo 3 são quase equivalentes à EVM, mas fazem alguns sacrifícios para melhorar os tempos de prova e facilitar o desenvolvimento da EVM. A vantagem das ZK-EVMs de Tipo 3 é que são mais fáceis de construir e têm tempos de prova mais rápidos. Elas podem remover alguns recursos que são excepcionalmente difíceis de implementar em uma implementação ZK-EVM, como os contratos pré-compilados. Além disso, essas ZK-EVMs podem ter pequenas diferenças em como tratam o código do contrato, a memória ou a pilha.
A desvantagem é uma maior incompatibilidade. O objetivo de uma ZK-EVM de Tipo 3 é ser compatível com a maioria das aplicações, exigindo apenas uma reescrita mínima para o restante. No entanto, haverá algumas aplicações que precisarão ser reescritas porque usam contratos pré-compilados que a ZK-EVM de Tipo 3 remove ou por causa de dependências sutis em casos limite que as VMs tratam de maneira diferente.
Atualmente, Scroll e Polygon são ambas do Tipo 3, embora se espere que melhorem a compatibilidade ao longo do tempo. A Polygon possui um design único onde é possível verificar com provas ZK sua própria linguagem interna chamada zkASM, e eles interpretam o código ZK-EVM usando a implementação zkASM.
Hoje, nenhuma equipe ZK-EVM quer ser do Tipo 3; o Tipo 3 é simplesmente uma etapa de transição até que o trabalho complicado de adicionar contratos pré-compilados seja concluído e o projeto possa passar para o Tipo 2.5. No futuro, no entanto, as ZK-EVMs de Tipo 1 ou Tipo 2 podem se tornar ZK-EVMs de Tipo 3 voluntariamente, adicionando novos contratos pré-compilados compatíveis com ZK-SNARK que fornecem funcionalidades para desenvolvedores com tempos de prova e custos de gás baixos.
Tipo 4
As ZK-EVMs de Tipo 4 funcionam pegando o código-fonte de contratos inteligentes escritos em uma linguagem de alto nível (como Solidity, Vyper ou algum intermediário para o qual ambos compilam) e compilando essa linguagem para algo explicitamente projetado para ser compatível com ZK-SNARK. A vantagem dos sistemas do Tipo 4 é que possuem tempos de prova muito rápidos. Há muita sobrecarga que pode ser evitada ao não ter que provar com o ZK todas as diferentes partes de cada passo de execução da EVM e ao começar diretamente do código de alto nível.
A desvantagem é uma maior incompatibilidade. Uma aplicação "normal" escrita em Vyper ou Solidity pode ser compilada e "simplesmente funcionar", mas há várias maneiras pelas quais muitas aplicações não são "funcionais". Por exemplo, os contratos podem não ter os mesmos endereços em um sistema do Tipo 4 como na EVM, o que impediria o funcionamento de muitas aplicações. Além disso, o bytecode EVM escrito manualmente é mais difícil de usar e muitas infraestruturas de depuração não podem ser transportadas.
O ZKSync é um sistema de Tipo 4, embora possa adicionar compatibilidade com o bytecode EVM ao longo do tempo. O projeto Warp da Nethermind está construindo um compilador de Solidity para o Cairo da Starkware, o que tornará a StarkNet um sistema de Tipo 4.
Observação: Os tipos de ZK-EVMs mencionados acima são uma generalização e podem evoluir ao longo do tempo à medida que novas pesquisas são realizadas e implementações são aprimoradas.
Conclusão
As ZK-EVMs representam uma abordagem promissora para melhorar a escalabilidade da Ethereum e permitir um maior número de transações por segundo na rede. Essa solução utiliza provas de conhecimento zero para agrupar e verificar várias transações em um único lote, aumentando a eficiência e reduzindo os custos de transação. A compatibilidade com a EVM e a escolha do tipo de ZK-EVM são fatores importantes a serem considerados ao implementar essa tecnologia, pois influenciam a velocidade de geração de provas e a compatibilidade com aplicativos existentes na plataforma.
Embora as ZK-EVMs enfrentem desafios, como o tempo de geração de provas e a complexidade de desenvolvimento, o contínuo avanço na área de provas de conhecimento zero e o desenvolvimento de projetos específicos podem superar essas limitações. No geral, a adoção de ZK-EVMs pode levar a melhorias significativas na escalabilidade da Ethereum, tornando-a ainda mais competitiva e viável para uma ampla variedade de casos de uso, além de impulsionar o crescimento do ecossistema de aplicativos descentralizados na plataforma.
Referências
https://vitalik.ca/general/2022/08/04/zkevm.html
https://blog.jarrodwatts.com/the-ultimate-zk-evm-comparison-guide
https://ethereum.org/en/developers/docs/evm/
Latest comments (0)