*Encaminhar 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 discutir as vantagens e desvantagens desta blockchain, que acreditamos poder ter um futuro promissor.

ZkSync é uma blockchain de segundo nível (Camada 2 - L2) para o Ethereum, projetada para resolver os problemas de taxas elevadas e limitações de throughput (Transações Por Segundo - TPS) na rede Ethereum. Esta plataforma utiliza a tecnologia ZK-Rollup, que usa Provas de Conhecimento Zero (ZKP) para agrupar múltiplas 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, melhorando significativamente a eficiência e reduzindo custos.

Desenvolvido porMatter Labs, zkSync é anunciado como um produto totalmente de código aberto (100% de código aberto), gerido 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, estão operacionais duas blockchains: zkSync Lite, que processa pagamentos em ETH e tokens ERC20, e zkSync Era, suportando contratos inteligentes completos. Os planos futuros incluem o lançamento de um sistema de hipercadeia (L3), garantindo alta segurança. O objetivo da Matter Labs é escalar a tecnologia a um nível que irá atrair os próximos bilhões de utilizadores de blockchain.

Antecedentes

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

1. Escalabilidade: A capacidade de um sistema lidar eficientemente com um volume crescente de transações ou dados sem perder desempenho e segurança.
2. Segurança da Blockchain: Garantir a fiabilidade e proteção de dados contra acesso não autorizado, adulteração ou modificações.
3. Descentralização: A ausência de uma estrutura de controlo centralizada. Num sistema descentralizado, a gestão e a tomada de decisões são distribuídas de forma democrática entre todos os participantes da rede.

O Ethereum foca-se na segurança e descentralização, enfatizando o seu estatuto como um protocolo peer-to-peer com nós distribuídos pelo mundo. Para obter 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 retarda a rede. Além disso, sob carga de rede alta, as transações podem se tornar bastante caras e exigir um tempo significativo para processar.

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 a divisão de validadores em subgrupos para processar segmentos separados da rede, reduzindo assim a carga geral e aumentando a capacidade. No entanto, a comunidade tem se concentrado em soluções de Camada 2, considerando seu desenvolvimento rápido.

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

• Canais de Pagamento e Estado
• Cadeias Laterais
• Plasma
• Rollup Otimista

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

• Validium
• zkRollup
• Volition

Pode encontrar informações mais detalhadasaqui.

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

À primeira vista, as blockchains L2 podem parecer semelhantes, pois a sua principal tarefa é aumentar o número de transações fora da L1, delegando o papel de garante de segurança à L1. Os desenvolvedores de tais blockchains frequentemente afirmam que as suas soluções são as mais rápidas, mais confiáveis e mais simples. Na realidade, cada abordagem para a escalabilidade tem as 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 estes aspetos nos levam de volta às questões fundamentais do trilema das blockchains.

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

• segurança,
• desempenho e eficiência económica,
• facilidade de uso,
• aspectos adicionais, como o 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 (uma vez que existe 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, irei fornecer uma tabela e aqui descreverei brevemente o seu conteúdo.

Segurança

• Assunção de Vida ou “viabilidade” da Camada-2. Parte-se do pressuposto de que, para manter a funcionalidade da Camada-2, alguns participantes estarão sempre onchain ao nível da Camada-1 para responder a possíveis casos de fraude. Estes são ou validadores que apostam uma certa quantia de fundos (marcados como “Garantidos” na tabela) no L1, ou terceiros que garantem a segurança do protocolo em troca de uma recompensa. Como se observa 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 razões de segurança, for necessário iniciar a retirada de fundos por todos os utilizadores de L2 para L1. Como se pode ver na tabela, este problema só existe com o protocolo Plasma, sobre o qual se pode ler mais.aqui.
• Guarda. A questão de saber se os validadores L2 podem temporariamente bloquear ou confiscar os fundos dos utilizadores.
• Vulnerabilidades económicas. Inclui vários ataques aos validadores de L2, incluindo subornar mineiros de L1, criar DAOs "sombra" e outros ataques motivados economicamente.
• Criptografia. A diferença entre primitivos criptográficos padrão e novos. Os padrão são mais estudados e potencialmente vulneráveis, enquanto os novos (como SNARK e STARK) oferecem maior confiabilidade, mas exigem conhecimentos adicionais e auditorias por parte dos desenvolvedores.

Desempenho e Economia

Com desempenho, é simples. TPS (Transações Por Segundo) indica a capacidade da rede e, no contexto da escalabilidade, é o parâmetro mais crucial.

Aspetos económicos:

• Eficiência de Capital: Este aspecto é especialmente importante para Canais de Pagamento. Eles requerem 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, pois em todas as outras soluções uma conta criada em L1 funciona em L2 por padrão.
• Custo da transação: Juntamente com TPS, este é um dos fatores mais críticos de escalabilidade, determinando a atratividade econômica da solução.

Facilidade de Utilização

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

Outros Aspectos

• Contratos Inteligentes: Consideração sobre 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 alterações significativas.
• Suporte integrado à privacidade: Consideração da eficiência da proteção da privacidade em soluções 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, criado por desenvolvedores para desenvolvedores com amor por provas e mergulhos profundos em detalhes.

Ciclo de Vida da Transação no zkSync

A operação de ZK-Rollups pode ser representada a um nível elevado da seguinte forma:

1. Formação de Rollup: As transações são agrupadas num 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 zkSync recolhem blocos internos das 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 registam 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 enviam-no para verificação a um contrato inteligente Ethereum. Após 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 fisicamente não podem roubar fundos. O dano potencial mais significativo que podem causar é uma paralisação temporária da rede.

Nota: Na Era zkSync, o papel dos validadores é desempenhado pelos operadores.

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

1. Segurança do Fundo: Os operadores nunca podem danificar o estado da rede ou roubar fundos, o que é uma vantagem comparativamente às Sidechains.
2. Possibilidade de Recuperação de Fundos: Os utilizadores podem sempre extrair os seus fundos, mesmo que os operadores cessem as operações. Isto é possível graças à disponibilidade de dados, ao contrário do sistema Plasma.
3. Independência da Monitorização: Graças ao ZKP, os utilizadores ou terceiros de confiança não precisam de monitorizar continuamente os blocos Rollup para evitar fraudes, o que é uma vantagem comparativamente aos 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 de Rollup em L1:

• Pendente: A transação foi recebida pelo operador, mas ainda não foi processada.
• Processado: A transação está a ser processada pelo operador e está pronta para ser incluída no próximo bloco.
• Comprometido: Os dados da transação são publicados na Ethereum, garantindo a disponibilidade dos dados, mas não confirmando a 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.

Para 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 foram retirados do L1. No entanto, após uma atualização, estes valores serão agora obtidos a partir de L2. Apesar disso, os desenvolvedores planeiam disponibilizar métodos para aceder aos dados a partir de L1.

Diferenças Entre zkEVM e EVM

A compatibilidade das soluções L2 baseadas em ZKP com o Ethereum é uma tarefa complexa. Isto deve-se ao facto de o Ethereum não ter sido originalmente concebido para uma interação ótima com o ZKP. Como resultado, ao desenvolver tais sistemas, deve ser encontrada uma compromisso entre o desempenho e o potencial de escalabilidade, por um lado, e a compatibilidade com o Ethereum e o EVM, por outro. Artigo de Vitalik Buterin Os diferentes tipos de ZK-EVMsdiscute esses aspectos em detalhe e destaca diferentes níveis de compatibilidade.

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

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

O bytecode especificamente compilado para EVM não é compatível com 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 deste método é a independência de linguagens de programação específicas. No futuro, os desenvolvedores do zkSync prometem adicionar suporte para linguagens como Rust e C++. É importante que a demora 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ínima. Inicialmente, houve a ideia de criar sua própria linguagem de programação, Zinc, mas neste momento, a equipe está focada em suportar linguagens de programação mais populares.

A questão da compatibilidade dos zk-compiladores 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 zk-compiladores out of the box, criando dificuldades em trabalhar com eles. No entanto, soluçõesestão a ser desenvolvidos que prometem facilitar o processo de migração de projetos e adaptação a novas tecnologias.

O artigo de Vitalik Buterin menciona que a Ethereum provavelmente se esforçará para melhorar a compatibilidade com a ZKP a nível do protocolo ao longo do tempo. Da mesma forma, as soluções de L2 com ZKP irão se adaptar para uma melhor compatibilidade com a 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á a ser desenvolvido ativamente; consulte sempre a versão mais recente da documentação!

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

1. Diferenças em relação ao 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 odocumentaçãopara alterações.
2. Contratos do Sistema: No zkSync, existem contratos inteligentes do sistema para várias funções, como o ContractDeployer para implementar contratos inteligentes e o MsgValueSimulator para trabalhar com ETH. Mais sobre os 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 a dependência do preço do gás em L1. Os detalhes podem ser encontradosaqui.
5. Teste local: Ferramentas padrão como Hardhat Node ou Anvil não são adequadas para teste local de zkEVM. Em vez disso, opções especiaissão utilizados, incluindo testes no modo de fork.
6. Verificação de assinatura: É recomendado usar o suporte integrado para abstração de conta em vez de ecrecover.
7. Rastreio de Erros Relacionados com Gás: No zkSync, é impossível rastrear erros relacionados com a falta de gás devido às especificidades da execução dentro do contrato inteligente do sistema DefaultAccount.

Para uma compreensão profunda do trabalho com zkEVM, é recomendado estudar a documentação, incluindo a secçãoSegurança e melhores práticas.

Abstração de Conta

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

1. Nível de Implementação: No zkSync, a abstração de contas está integrada ao nível do protocolo, tornando todas as contas, incluindo Contas de Propriedade Externa (EOA), funcionalmente semelhantes a contratos inteligentes.
2. Processamento de Transações: Enquanto o ERC-4337 utiliza um mempool separado para os agrupadores, criando duas correntes de transações diferentes, a Era zkSync tem um único mempool. Isso significa que as transações originadas de EOAs e contratos inteligentes são processadas numa única corrente, garantindo uma integração e processamento mais suaves.
3. Suporte para Mestres de Pagamento: A zkSync suporta mestres de pagamento 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á a ganhar rapidamente impulso e já inclui dezenas de protocolos: Bridges, DeFi, protocolos de infraestrutura e muito mais. (A lista atual pode ser vistaaqui).

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

Hyperchains

O protocolo zkSync iniciou o seu desenvolvimento com o lançamento do zkSync Lite, destinado apenas a transferências de ether e tokens ERC-20, sem a capacidade de implementar protocolos completos. Esta etapa 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. No entanto, as ambições do zkSync não se limitam a isso, uma vez que os planos de desenvolvimento incluem o lançamento das chamadas hyperchains.

Hyperchains, ou "escalonamento fractal", consistem em redes ZKP, cada uma formando seus próprios blocos e provas. Essas provas são então coletadas e publicadas na rede principal L1. Cada uma dessas redes é uma cópia completa de todo o sistema e pode ser considerada seu "fractal".

A singularidade das hyperchains está no facto de poderem ser criadas e implementadas de forma independente. Para manter a consistência e compatibilidade, cada hyperchain deve utilizar um motor zkEVM comum, parte da pilha ZK (com a Era zkSync a atuar como a primeira hyperchain). Isto permite que as hyperchains herdem a sua segurança do L1, garantindo a sua fiabilidade 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: As Hyperchains irão transferir 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 Utilizadores: Os utilizadores não vão notar a diferença - as suas transações são processadas em hyperchains e podem passar por vários níveis antes de chegar à rede principal, criando assincronia no processamento.
• Vantagens sobre as 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 significativamente maior escalabilidade.
• Flexibilidade na Criação de Blockchains Personalizadas: As Hyperchains permitem a criação de blockchains personalizadas e contas com vários níveis de segurança e privacidade. Mesmo com um nível mais baixo de segurança, no pior dos casos, apenas uma suspensão temporária de fundos é esperada.

Mais sobre tudo isso pode ser encontrado aqui.

Prós e contras do zkSync

Prós

1. Segurança: Segurança próxima do 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 de transações 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. Infraestrutura em evolução: Desenvolvimento de infraestrutura muito ativo.
9. Potencial de escalabilidade: oportunidades para melhorias significativas de escalabilidade.

Contras

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

Conclusão

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

Aviso Legal:

1. Este artigo é reimpresso de [GateMetaLamp]. Encaminhar o Título Original 'Como ZKP e ZK-Rollups ajudam a resolver o problema de escalabilidade: uma análise da blockchain zkSync'. Todos os direitos autorais pertencem ao autor original [MetaLamp]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As 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 indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.