*Encaminhe o Título Original 'Como ZKP e ZK-Rollups ajudam a resolver o problema de escalabilidade: uma revisão da blockchain zkSync'

Neste artigo, explicaremos o que é a tecnologia de prova de conhecimento zero e falaremos sobre uma blockchain popular - zkSync: como funcionam as transações no zkSync e as principais diferenças da Máquina Virtual Ethereum (EVM). Também discutiremos as vantagens e desvantagens desta blockchain, que acreditamos poder ter um futuro promissor.

ZkSync é uma blockchain de segundo nível (Camada 2 - L2) para Ethereum, projetada para abordar os problemas de taxas altas e throughput limitado (Transações Por Segundo - TPS) na rede Ethereum. Esta plataforma emprega a tecnologia ZK-Rollup, que utiliza Provas de Conhecimento Zero (ZKP) para agrupar várias transações fora da rede principal (L1). Apenas as provas criptográficas da correção das transações e seus dados comprimidos são enviados para L1, aumentando significativamente a eficiência e reduzindo os custos.

Desenvolvido porMatter Labs, zkSync é anunciado como um produto totalmente de código aberto (100% de código aberto), gerenciado pela comunidade. De acordo com Cryptorank, o projeto já atraiu atenção, levantando investimentos de $458 milhões. A longo prazo, a Matter Labs tem como objetivo criar um ecossistema abrangente. Atualmente, duas blockchains estão operacionais: zkSync Lite, que processa pagamentos em tokens ETH e ERC20, e zkSync Era, suportando contratos inteligentes completos. Os planos futuros incluem o lançamento de um sistema hyperchain (L3), garantindo alta segurança. O objetivo da Matter Labs é escalar a tecnologia para um nível que atrairá os próximos bilhões de usuários de blockchain.

Antecedentes

ZkSync representa uma nova abordagem para resolver o problema de escalabilidade conhecido como o trilema do blockchainEste projeto, assim como outras soluções de Camada 2 (L2), busca encontrar um equilíbrio entre segurança, escalabilidade e descentralização nas redes blockchain.

1. Escalabilidade: A capacidade de um sistema para lidar de forma eficiente com um volume crescente de transações ou dados sem perder desempenho e segurança.
2. Segurança da Blockchain: Garantir a confiabilidade e proteção de dados contra acessos não autorizados, manipulações ou modificações.
3. Descentralização: A ausência de uma estrutura de controle centralizada. Em um sistema descentralizado, a gestão e a tomada de decisões são distribuídas democraticamente entre todos os participantes da rede.

Ethereum foca na segurança e descentralização, enfatizando seu status como um protocolo peer-to-peer com nós distribuídos ao redor do mundo. Para as informações mais recentes sobre a distribuição de nós, consulte NodeWatch.

Para manter a descentralização na rede, cada nó deve verificar todas as transações. Isso naturalmente desacelera a rede. Além disso, sob carga de rede alta, as transações podem se tornar bastante caras e exigir tempo significativo para serem processadas.

Camada 2

A principal tarefa para aumentar o TPS da rede Ethereum sem aumentar a carga nos nós foi a introdução de Shardingem combinação com a transição para o consenso PoS (Proof of Stake). Isso envolveu dividir os validadores em subgrupos para processar segmentos separados da rede, reduzindo assim a carga geral e aumentando o throughput. No entanto, a comunidade tem se concentrado em soluções de Camada 2, considerando seu rápido desenvolvimento.

Além da ideia de implementar o Sharding no Ethereum, outras soluções de escalabilidade surgiram, tais como:

• Pagamento e Canais de Estado
• Sidechains
• Plasma
• Rollup Otimista

Bem como tecnologias baseadas em Provas de Conhecimento Zero (ZKP), incluindo:

• Validium
• zkRollup
• Volition

Mais informações detalhadas podem ser encontradas aqui.

Embora o Sharding ainda esteja em desenvolvimento, o hardfork Dencun está planejado para o início de 2024, o que irá implementar Proto-Danksharding. Este passo intermediário tem como objetivo melhorar as soluções de Camada 2, tornando o armazenamento de dados na L1 mais econômico. Assim, o Proto-Danksharding promete reduzir os custos de transação na L2, como um passo em direção a uma solução completa de Sharding.

À primeira vista, as blockchains L2 podem parecer semelhantes, já que sua principal tarefa é aumentar o número de transações fora da L1, enquanto delegam o papel de garantidor de segurança para L1. Os desenvolvedores de tais blockchains frequentemente afirmam que suas soluções são as mais rápidas, confiáveis e simples. Na realidade, cada abordagem de escalonamento tem suas nuances e compromissos inevitáveis em relação à velocidade das transações, nível de segurança ou grau de descentralização. Soluções totalmente centralizadas também são comuns. Todos esses aspectos nos trazem de volta às questões fundamentais do trilema da blockchain.

Em este artigo, são propostos critérios-chave para avaliar os protocolos utilizados nas soluções de Camada 2. Eles incluem:

• segurança,
• desempenho e eficiência econômica,
• facilidade de uso,
• aspectos adicionais, como suporte a contratos inteligentes, compatibilidade com bytecode EVM e opções de privacidade.

Importante! O artigo é escrito pela Matter Labs e, na minha opinião, algumas coisas são "esticadas" a favor do zkRollup (já que há um claro conflito de interesse), mas isso não é tão importante, o principal é ver quais diferenças existem entre os protocolos de Camada-2.

Abaixo vou fornecer uma tabela e aqui vou descrever brevemente seu conteúdo.

Segurança

• Pressuposição de Vitalidade ou “viabilidade” da Camada-2. Assume-se que, para manter a funcionalidade da Camada-2, alguns participantes sempre estarão onchain no nível da Camada-1 para responder a casos potenciais de fraude. Estes são ou validadores que apostam uma certa quantia de fundos (marcados como “Garantidos” na tabela) em L1, ou terceiros que garantem a segurança do protocolo por uma recompensa. Conforme visto na tabela, as soluções que utilizam ZKP (Validium e zkRollup) não têm essa necessidade.
• Problema de Saída em Massa. Um problema que surge se, por motivos de segurança, for necessário iniciar a retirada de fundos por todos os usuários do L2 para o L1. Conforme visto na tabela, esse problema existe apenas com o protocolo Plasma, mais sobre o qual pode ser lido aqui.
• Guarda. A questão de saber se os validadores L2 podem temporariamente bloquear ou confiscar os fundos dos usuários.
• Vulnerabilidades econômicas. Inclui vários ataques aos validadores da L2, incluindo subornar os mineradores da L1, criar DAOs 'sombra' e outros ataques motivados economicamente.
• Criptografia. A diferença entre primitivas criptográficas padrão e novas. Os padrões são mais estudados e potencialmente vulneráveis, enquanto os novos (como SNARK e STARK) oferecem maior confiabilidade, mas exigem conhecimentos adicionais e auditorias dos desenvolvedores.

Desempenho e Economia

Com performance, é simples. TPS (Transações Por Segundo) indica o throughput da rede e, no contexto de escala, é o parâmetro mais crucial.

Aspectos econômicos:

• Eficiência de Capital: Este aspecto é especialmente importante para Canais de Pagamento. Eles exigem congelar fundos iguais ao volume médio de operações no canal, tornando-os menos eficientes em termos de investimento de capital.
• Transação L1 para criar uma conta L2. Também uma desvantagem para os canais de pagamento, já que em todas as outras soluções uma conta criada em L1 funciona em L2 por padrão.
• Custo da transação: Junto com TPS, este é um dos fatores mais críticos de escalabilidade, determinando a atratividade econômica da solução.

Facilidade de Uso

• Tempo de saque de L2 para L1: Este período pode variar de alguns minutos a várias semanas. Rollups otimistas e Plasma são particularmente inconvenientes nesse aspecto, pois requerem mais tempo para saque de fundos.
• Tempo até a Finalidade Subjetiva da Transação: Determina o quão rapidamente uma transação se torna irrevogável na L1 do ponto de vista de observadores externos. Por exemplo, nos Rollups Otimistas, alcançar a finalidade na L1 requer apenas uma confirmação no Ethereum, mas a finalidade total da transação leva cerca de uma semana.
• Verificabilidade da Finalidade Subjetiva com Código do Cliente: Determina se o tempo para a finalidade subjetiva pode ser verificado por clientes leves (navegadores/carteiras móveis). Continuando com o exemplo de Rollups Otimistas, para confirmar a finalidade da transação, o usuário deve baixar e verificar todo o rollup de estado da última semana.
• Confirmações instantâneas de transações. O protocolo pode fornecer confirmações instantâneas de transação com garantia total? Ou garante isso apenas no nível de consenso L2.
• Finalidade Visível Instantânea: Pode ser implementada em cima da maioria dos protocolos L2, o que significa que as transações são instantaneamente confirmadas na interface do usuário. Apenas canais de pagamento (canais de estado) oferecem garantias de segurança completas para essas confirmações, enquanto em outros protocolos essas transações ainda podem ser revertidas dentro de um certo tempo antes de serem confirmadas no L1.

Outros Aspectos

• Contratos Inteligentes: Consideração se a solução L2 suporta contratos inteligentes totalmente programáveis, ou apenas um subconjunto limitado de funções através de predicados.
• Compatibilidade com o Bytecode EVM: Avalia a viabilidade de transferir contratos inteligentes existentes de bytecode EVM do Ethereum para L2 sem mudanças significativas.
• Suporte à Privacidade Incorporado: Consideração da eficiência da proteção de privacidade em soluções de L2, especialmente no contexto da disponibilidade e custo-efetividade de transações confidenciais.

Abaixo está uma tabela comparativa das principais soluções baseadas em ZKP:

Para uma compreensão mais detalhada das Provas de Conhecimento Zero (ZKP), recomendo consultar este artigoem nossoblockchain-wiki, criada por desenvolvedores para desenvolvedores com amor por provas e aprofundamentos em detalhes.

Ciclo de Vida da Transação no zkSync

A operação dos ZK-Rollups pode ser representada em alto nível da seguinte forma:

1. Formação de Rollup: As transações são agrupadas em um rollup.
2. Criação de ZKP: Uma Prova de Conhecimento Zero é formada.
3. Verificação no Ethereum: A prova é enviada para verificação a um contrato inteligente Ethereum.

No contexto da arquitetura do zkSync, o processo parece assim:

1. Coleção de Blocos Internos: Os validadores do zkSync coletam blocos internos de transações a cada poucos segundos.
2. Formação do Pacote de Blocos: A cada 30-90 segundos, um pacote de blocos é criado a partir dos blocos internos.
3. Compromisso de Estado da Blockchain: Os validadores registram o estado atual da blockchain e transmitem os dados modificados para L1 como dados de chamada para possível recuperação.
4. Cálculo e Submissão de SNARK: Os validadores calculam o SNARK (ZKP) para o pacote e o enviam para verificação a um contrato inteligente Ethereum. Após a verificação, o novo estado da rede torna-se final.

Os validadores em ZK-Rollups desempenham um papel fundamental, empacotando transações em blocos e gerando Provas de Conhecimento Zero para elas. Uma característica do sistema é que os validadores não podem fisicamente roubar fundos. O dano potencial mais significativo que eles podem causar é uma interrupção temporária da rede.

Observação: Na Era zkSync, o papel dos validadores é desempenhado pelos operadores.

Os desenvolvedores do zkSync destacam as seguintes garantias de sua arquitetura:

1. Segurança do Fundo: Os operadores nunca podem danificar o estado da rede ou roubar fundos, o que é uma vantagem em comparação com as Sidechains.
2. Possibilidade de Recuperação de Fundos: Os usuários sempre podem extrair seus fundos mesmo se os operadores encerrarem as operações. Isso é possível graças à disponibilidade de dados, ao contrário do sistema Plasma.
3. Independência da Monitorização: Graças ao ZKP, os usuários ou terceiros confiáveis não precisam monitorar continuamente os blocos Rollup para evitar fraudes, o que é uma vantagem em comparação com sistemas baseados em provas de fraude, como canais de pagamento ou Rollups otimistas.

As transações na Era zkSync passam por vários estados-chave, diferentes das confirmações habituais do Rollup em L1:

• Pendente: A transação foi recebida pelo operador, mas ainda não foi processada.
• Processado: A transação está sendo processada pelo operador e está pronta para ser incluída no próximo bloco.
• Comprometido: Os dados da transação são publicados no Ethereum, garantindo a disponibilidade dos dados, mas não confirmando sua execução correta.
• Executado: A fase final em que a prova de validade (SNARK) para a transação é verificada por um contrato inteligente Ethereum, tornando a transação final.

Além do número do bloco, as transações no zkSync também exibem o número do pacote. Originalmente, parâmetros como block.number, block.timestamp e blockhash eram retirados da L1. No entanto, após uma atualização, esses valores agora serão obtidos da L2. Apesar disso, os desenvolvedores planejam fornecer métodos para acessar dados da L1.

Diferenças Entre zkEVM e EVM

A compatibilidade das soluções L2 baseadas em ZKP com o Ethereum é uma tarefa complexa. Isso ocorre porque o Ethereum não foi originalmente projetado para interação ideal com ZKP. Como resultado, no desenvolvimento de tais sistemas, um compromisso deve ser encontrado entre desempenho e potencial de escalabilidade, por um lado, e compatibilidade com o Ethereum e EVM, por outro. Artigo de Vitalik Buterin "Os diferentes tipos de ZK-EVMs"discute esses aspectos em detalhes e destaca diferentes níveis de compatibilidade.

zkSync escolheu um dos caminhos mais desafiadores, visando alto desempenho, mas com compatibilidade limitada tanto com Ethereum quanto com EVM. Para obter bytecode compatível com zkEVM, o LLVMo projeto é usado com uma série de compiladores e otimizadores proprietários. No caso do Solidity e Yul, após o compilador padrão solc, o código passa por várias etapas antes de se tornar bytecode zkEVM. O diagrama abaixo ilustra todas as etapas desse processo (descritas com mais detalhes aqui:)

Importante! As otimizações no zksolc são suportadas.

O bytecode especificamente compilado para o EVM não é compatível com o zkEVM. Isso significa que os endereços de contratos inteligentes idênticos no Ethereum e no zkSync serão diferentes. No entanto, os desenvolvedores planejam resolver esse problema no futuro.

Uma das vantagens significativas desta abordagem é a independência de linguagens de programação específicas. No futuro, os desenvolvedores da zkSync prometem adicionar suporte para linguagens como Rust e C++. É importante que o atraso nas atualizações e a integração de inovações entre compiladores de alto nível (por exemplo, solc) e compiladores de plataforma (por exemplo, zksolc) seja mínimo. Inicialmente, havia a ideia de criar sua própria linguagem de programação, Zinc, mas no momento, a equipe está focada em suportar linguagens de programação mais populares.

A questão da compatibilidade dos compiladores zk com as ferramentas de desenvolvimento e depuração existentes para contratos inteligentes Solidity e Vyper é significativa. Plataformas de desenvolvimento atuais como Remix, Hardhat e Foundry não suportam compiladores zk prontos para uso, criando dificuldades ao trabalhar com eles. No entanto, soluçõesestão sendo desenvolvidas que prometem facilitar o processo de migração de projetos e adaptação a novas tecnologias.

O artigo de Vitalik Buterin menciona que o Ethereum provavelmente se esforçará para melhorar a compatibilidade com ZKP no nível do protocolo ao longo do tempo. Da mesma forma, as soluções L2 com ZKP se adaptarão para uma melhor compatibilidade com o Ethereum. Como resultado, no futuro, as diferenças entre esses sistemas podem se tornar quase imperceptíveis, garantindo uma integração e transição mais suaves para os desenvolvedores.

Recursos do zkEVM

Importante! O protocolo está sendo desenvolvido ativamente; sempre consulte a versão mais recente da documentação!

zkEVM difere do EVM e, apesar dos esforços dos desenvolvedores para esconder essas diferenças "por baixo do capô," existem características importantes a considerar ao escrever contratos inteligentes:

1. Diferenças do EVM: O comportamento do código escrito em Solidity para zkEVM pode ser diferente, especialmente em aspectos como block.timestamp e block.number. É importante verificar regularmente o documentaçãopara mudanças.
2. Contratos do Sistema: No zkSync, existem contratos inteligentes do sistema para várias funções, como ContractDeployer para implantar contratos inteligentes e MsgValueSimulator para trabalhar com ETH. Mais sobre contratos inteligentes do sistema pode ser encontrado no documentação.
3. Padrão de Proxy para Implantação: É recomendado usar um padrão de proxy durante os primeiros meses após a implantação para evitar possíveis erros de compilador.
4. Cálculo de gás: O modelo de cálculo de gás no zkEVM difere do Ethereum, incluindo um conjunto diferente de opcodes e dependência do preço do gás no L1. Detalhes podem ser encontrados aqui.
5. Teste Local: Ferramentas padrão como Hardhat Node ou Anvil não são adequadas para o teste local do zkEVM. Em vez disso, opções especiaissão utilizados, incluindo testes de modo fork.
6. Verificação de assinatura: É recomendado utilizar o suporte integrado para a abstração de contas em vez de ecrecover.
7. Rastreando Erros Relacionados a Gás: No zkSync, é impossível rastrear erros relacionados a escassez de gás devido às especificidades da execução dentro do contrato inteligente do sistema DefaultAccount.

Para uma compreensão profunda de como trabalhar com zkEVM, é recomendado estudar a documentação, incluindo a seção “Segurança e melhores práticas”.

Abstração de Conta

A abstração de conta no zkSync oferece várias vantagens-chave sobre ERC-4337:

1. Nível de Implementação: No zkSync, a abstração de conta é construída no nível do protocolo, tornando todas as contas, incluindo Contas de Propriedade Externa (EOA), funcionalmente semelhantes a contratos inteligentes.
2. Processamento de Transação: Enquanto o ERC-4337 usa um mempool separado para bundlers, criando dois fluxos diferentes de transações, a Era zkSync possui um único mempool. Isso significa que as transações originárias de EOAs e contratos inteligentes são processadas em um único fluxo, garantindo uma integração e processamento mais suaves.
3. Suporte para Paymasters: zkSync suporta paymasters para todos os tipos de contas, permitindo que as taxas de gás sejam configuradas em tokens ERC20 para qualquer conta.

Infraestrutura zkSync

A infraestrutura da era zkSync está ganhando rapidamente impulso e já inclui dezenas de protocolos: Bridges, DeFi, protocolos de infraestrutura e muito mais. (A lista atual pode ser visualizadaaqui).

Outra vantagem é a compatibilidade com carteiras Ethereum, como MetaMask ou TrustWallet.

Hypercadeias

O protocolo zkSync iniciou seu desenvolvimento com o lançamento do zkSync Lite, destinado apenas a transferências de ether e tokens ERC-20, sem a capacidade de implantar protocolos completos. Esta fase foi um passo importante no desenvolvimento, mas apenas antecedeu a chegada da zkSync Era - uma solução L2 completa para Ethereum, que teoricamente pode ser adaptada para outras blockchains L1 também. No entanto, as ambições do zkSync não param por aí, pois os planos de desenvolvimento incluem o lançamento das chamadas hyperchains.

Hypercadeias, ou “dimensionamento fractal,” consistem em redes de ZKP, cada uma formando seus próprios blocos e provas. Essas provas são então coletadas e postadas na rede principal L1. Cada uma dessas redes é uma cópia completa de todo o sistema e pode ser considerada sua “fractal”.

A singularidade das hyperchains é que elas podem ser criadas e implantadas de forma independente. Para manter a consistência e compatibilidade, cada hyperchain deve usar um mecanismo comum zkEVM, parte do ZK stack (com a Era zkSync atuando como a primeira hyperchain). Isso permite que as hyperchains herdem sua segurança do L1, garantindo sua confiabilidade e eliminando a necessidade de medidas adicionais de confiança e segurança.

Hyperchains representam uma abordagem inovadora para escalar redes blockchain, reduzindo a carga na rede principal e aumentando a velocidade de processamento de transações. Aspectos-chave desta abordagem incluem:

• Transferência de Prova entre Hyperchains: Os Hyperchains transferirão provas de bloco entre si, aumentando a distância que uma transação deve percorrer antes de chegar à rede principal L1. Isso ajuda a distribuir a carga e evitar problemas de gargalo.

• Transparência para os Usuários: os usuários não perceberão a diferença - suas transações são processadas em hyperchains e podem passar por vários níveis antes de chegar à rede principal, criando assincronicidade no processamento.
• Vantagens Sobre Soluções Existentes: Ao contrário das soluções L2 atuais, que são mais rápidas, mas ainda limitadas em volume de transações e às vezes comprometem a segurança, as hyperchains prometem escalabilidade significativamente maior.
• Flexibilidade na Criação de Blockchains Personalizadas: As Hyperchains permitem a criação de blockchains e contas personalizadas com vários níveis de segurança e privacidade. Mesmo com um nível mais baixo de segurança, no pior caso, espera-se apenas uma suspensão temporária dos fundos.

Mais sobre tudo isso pode ser encontrado aqui.

Prós e contras do zkSync

Prós

1. Segurança: Segurança próxima ao nível L1 e potencial para descentralização no futuro.
2. Compatibilidade com EVM: Suporte para contratos inteligentes compatíveis com EVM.
3. API Web3 e Carteiras: API Web3 padrão e suporte para carteiras Ethereum como MetaMask.
4. Abstração de Conta: Suporte nativo para abstração de conta.
5. Velocidade de transação: Processamento rápido da transação na L2 com confirmação subsequente na L1.
6. Taxas baixas: Taxas de gás reduzidas em comparação com L1.
7. Pagamentos de Gás ERC20: Capacidade de pagar taxas de gás em tokens ERC20.
8. Evoluindo Infraestrutura: Desenvolvimento de infraestrutura muito ativo.
9. Potencial de escalabilidade: Oportunidades para melhorias significativas de escalabilidade.

Cons

1. Compatibilidade EVM Limitada: Comparado aos concorrentes (por exemplo, Polygon zkEVM, Scroll), possui menor compatibilidade EVM.
2. Risco de Erros em Contratos Inteligentes: Aumento do risco de erros, exigindo testes e auditorias minuciosos.
3. Necessidade de adaptar o conjunto de desenvolvimento às especificidades do protocolo.
4. Atraso nas Tecnologias Principais: Atraso na adoção de inovações em compiladores e atualizações de bibliotecas.
5. Centralização da rede: Atualmente, a rede é gerenciada por um número limitado de operadores.
6. Necessidade de Contratos Inteligentes Atualizáveis: De tudo o que foi mencionado acima, segue-se que há uma necessidade de sempre criar contratos atualizáveis no início do projeto, a fim de poder corrigir prontamente deficiências e vulnerabilidades.

Conclusão

O protocolo zkSync parece muito promissor e tem um grande potencial, embora, no momento, o lançamento nesta blockchain ainda esteja associado a uma série de riscos que precisam ser considerados. O desenvolvimento para o zkSync é atualmente mais desafiador do que para blockchains que são muito mais compatíveis com a EVM e a pilha de desenvolvimento do EVM. No entanto, talvez no futuro, essa diferença se torne insignificante ou desapareça completamente.

Aviso Legal:

1. Este artigo é reproduzido de [GateMetaLamp]. Encaminhe o Título Original 'Como ZKP e ZK-Rollups ajudam a resolver o problema de escalabilidade: uma revisão da blockchain zkSync'. Todos os direitos autorais pertencem ao autor original [MetaLamp]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
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 Gate Learn. Salvo menção em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.