Para resolver o problema de expansão da rede blockchain Layer 1, surgiu a solução Rollup. Combinado com a tecnologia ZK, o ZK Rollup se tornou o novo queridinho da pista Layer 2. No entanto, para a maioria das pessoas, conceitos relacionados como ZK, Rollup e EVM podem ter um certo limite de compreensão. Portanto, o objetivo deste relatório de pesquisa é classificar sistematicamente uma série de conceitos do zkEVM Rollup para você em uma linguagem concisa e fácil de entender, analisar profundamente a evolução e o status de desenvolvimento da tecnologia zkEVM Rollup e interpretar os principais projetos em detalhes. Ele é projetado para ajudá-lo a entender e julgar completamente a tendência de desenvolvimento da trilha do zkEVM Rollup.
PARTE 1Entendendo o ZK
ZK (ou ZKP), o nome completo é Zero-Knowledge Proof, ou seja, prova de conhecimento zero. Em criptografia, prova de conhecimento zero ou protocolo de conhecimento zero é um método pelo qual uma das partes (o provador) pode submeter ao outra parte (certificador de verificação) para provar um fato sem divulgar a informação específica do fato, ou seja, uma parte (provador) pode deixar a outra parte saber se o fato está correto sem divulgar nenhuma "informação específica" de o fato, então a tecnologia ZK pode ser usada em privacidade. O campo de proteção nos dá muito espaço para imaginação.
Claro, além dos benefícios de proteção de privacidade que a tecnologia ZK pode trazer, no ZK Rollup, a tecnologia ZK é mais importante para resolver o problema de "difícil verificação". O processo de "verificação" é muito importante para o blockchain. A maior parte do processo de cálculo no Ethereum é atender aos requisitos de verificação, e o ZK Rollup pode reduzir bastante o tempo gasto na verificação por toda a rede de nós. Por exemplo, se um bloco demora muito para verificar se atende às regras de toda a rede quando o bloco foi gerado, pode haver um provador que primeiro o verifique e gere uma "prova" do resultado do cálculo desse bloco, e o resto O objetivo de verificar o bloco pode ser alcançado verificando rapidamente essa "prova" em vez do bloco original com uma grande quantidade de cálculos.
Um protocolo ZK simples é dividido nas seguintes etapas, geração de chave, comprovação e verificação, e irei desmontá-los um a um para você.
01Geração, comprovação e verificação da chave
No ZK, precisamos primeiro converter o problema a ser verificado em uma expressão matemática e depois em um polinômio e expressá-lo na forma de um circuito aritmético. Quando um programa é convertido em um circuito aritmético, ele é dividido em etapas individuais que consistem em operações aritméticas básicas, como adição, subtração, etc. Como uma função que será gerada, ela pode ser transformada no seguinte diagrama de circuito, veja a Figura 1.
Figura 1 Um exemplo de diagrama de circuito, pode-se notar que todas as operações no circuito são divididas nas operações básicas mais simples | Fonte
Usando este circuito e alguns números aleatórios como entrada, podemos gerar uma chave de prova (pk, chave de prova) e uma chave de verificação (vk, chave de verificação) para o processo de verificação subsequente, o diagrama esquemático é mostrado na Figura 2.
Figura 2 Geração de "parâmetros públicos"
Nosso sistema de prova também requer dois tipos de entradas - privada e pública, juntamente com a chave de prova para gerar a prova. Entre eles, o input privado (testemunha) é o segredo que queremos esconder, e o input público é a informação que pode ser tornada pública. Por exemplo, na equação X+Y*Z=OUT, X e OUT são entradas públicas, enquanto Y e Z possuem valores que não queremos que sejam públicos para o validador. Embora o valor de Y*Z possa ser deduzido com base na entrada do público, os valores específicos de Y e Z ainda são incertos.
Figura 3 O processo de prova e processo de verificação de ZK-SNARKs
Quando o verificador recebe a prova, ele usa a entrada pública, a prova e a chave de verificação para verificar a prova e retorna o resultado da verificação (ou seja, se a verificação foi bem-sucedida).
Depois de entender o processo acima, podemos aplicar esta tecnologia para bloquear a verificação para realizar um pequeno ZK-SNARK, conforme mostrado na Figura 3. Existem muitos protocolos e métodos para realizar a prova de conhecimento zero.SNARK é relativamente fácil de entender e também é a escolha da maioria dos projetos nesta fase. No parágrafo "Dos ZK-SNARKs aos ZK-STARKs" falaremos sobre as vantagens e desvantagens dos SNARKs.
02Tente um pouco de SNARK
Vamos usar uma prova de conhecimento zero de uma Merkle Tree que registra o status da conta como um exemplo para praticar. A Merkle Tree registra o endereço e o saldo da conta. Quando houver uma nova transação que precise atualizar a Merkle Tree, precisamos realizar as seguintes operações:
Verifique se o remetente e o destinatário da transação estão nos nós folha da árvore.
Verifique a assinatura do remetente.
Atualize os saldos do remetente e do destinatário.
Atualize o nó raiz da Merkle Tree (ou seja, Merkle Root) e use-o como saída final.
Na ausência de provas de conhecimento zero, o verificador precisa repetir essas etapas para garantir a precisão do cálculo. Mas depois de usar a prova de conhecimento zero, a situação é diferente. Primeiro, precisamos identificar dois tipos de entradas:
Durante esse processo, apenas as informações da nova transação, o Merkle Root original e o Merkle Root atualizado são entradas públicas.
A própria Merkle Tree atua como testemunha (testemunha) e não precisa ser lida ou processada pelo verificador.
Em segundo lugar, precisamos gerar chaves e circuitos de computação. Construímos processos de cálculo como atualização Merkle Tree e verificação de endereço de entrada e saída em circuitos de cálculo para obter chaves de prova e chaves de verificação. Este circuito não tem nada a ver com as informações da transação de entrada, nem com o Merkle Root existente, porque o método de cálculo da Merkle Tree é fixo.
Na etapa de geração de provas, tomamos como entrada as duas Merkle Trees e as informações da transação. Na etapa de verificador, o verificador pode garantir a confiabilidade da atualização sem obter a Merkle Tree, ou seja, sem saber as informações da conta. O circuito é como uma caixa preta sólida, desde que a entrada esteja correta, obterá a saída correta.
Usando a prova de conhecimento zero, outros verificadores podem verificar rapidamente se o processo de geração da Árvore Merkle é confiável, reduzindo assim o tempo para verificação repetida na rede, e as informações da Árvore Merkle não precisam ser divulgadas ao verificador.
03De ZK-SNARKs a ZK-STARKs
O protocolo de prova mencionado acima é o ZK-SNARKs. SNARK significa sucintos argumentos não interativos de conhecimento, onde sucinto refere-se à simplicidade deste método, e não interativo refere-se àquele comparado a outros métodos de prova, SNARKs são provas não interativas, ou seja, o verificador só precisa usar a prova sucinta gerada pode obter o resultado da verificação. No entanto, existem alguns problemas com ZK-SNARKs. Na etapa de geração da chave, o circuito e o número aleatório equivalem a um conjunto de parâmetros públicos iniciais, havendo um inevitável problema de centralização no processo de geração desse parâmetro público.
Os ZK-STARKs têm uma abordagem diferente baseada nos SNARKs, onde "s" significa escalabilidade, o que prova que o tempo de geração e o tempo de cálculo original são quase lineares, e o tempo de verificação é logarítmico no cálculo original, o que significa que no No caso de um grande conjunto de dados como dados, o tempo de verificação exigido pelo verificador é bastante reduzido.
Ao mesmo tempo, como uma versão atualizada do ZK-SNARKs, o ZK-STARKs pode não apenas melhorar a eficiência da verificação (a eficiência teórica é 10 vezes), mas também não depende de curvas elípticas ou configurações confiáveis e não requer o processo de geração de parâmetros públicos iniciais (letra "T" significa transparência), o que elimina a necessidade de uma configuração confiável centralizada. Alguns desenvolvedores acreditam que a função hash no ZK-STARK pode ajudar a resistir a ataques quânticos.
No entanto, o ZK-STARKs foi lançado tarde, a tecnologia atual não está madura o suficiente e depende de funções hash, o que limita sua versatilidade. O ZK-SNARKs ainda é um algoritmo de prova geral. Alguns exemplos de algoritmos baseados em STARK incluem Fractal, SuperSonic, etc., e projetos relacionados incluem StarkWare, Polygon Miden, etc.
PARTE 2Entendendo o Rollup
Além do ZK, outro conceito que precisamos entender é o Rollup, cujo significado é resolver o problema de congestionamento da rede da camada 1.
Tome o Ethereum como exemplo, atualmente ele tem o problema de congestionamento de transações. Existem duas maneiras de resolver esse problema: uma é aumentar a capacidade de transação do próprio blockchain, como expandir o throughput do blockchain por meio de tecnologias como sharding. Outra abordagem é mudar a forma como o blockchain é usado, ou seja, realizar a maioria das atividades na segunda camada (Layer 2, doravante denominada L2), em vez de diretamente na cadeia. Nesse caso, geralmente é implantado um contrato inteligente na cadeia, responsável apenas pelo processamento de depósitos e saques, e usa vários métodos para ler dados fora da cadeia para verificar se tudo o que acontece fora da cadeia está de acordo com as regras. Isso equivale a erguer uma rodovia ao lado de uma pequena estrada, ou seja, através da expansão L2 para resolver o problema de congestionamento.
Atualmente, os três principais tipos ou soluções para expansão L2 são canais de estado, Plasma e Rollup. São três paradigmas diferentes, cada um com vantagens e desvantagens. Todas as extensões L2 podem ser classificadas aproximadamente nessas três categorias (embora haja algumas disputas sobre nomenclatura, como validium), entre as quais o Rollup tem suas próprias vantagens.
Rollup e disponibilidade de dados
Comparado com outras soluções de expansão, o Rollup tem algumas vantagens. Uma das vantagens mais intuitivas é que resolve o problema de disponibilidade de dados do Plasma (mencionado no capítulo "Disponibilidade de dados" do artigo do Sr. Darren), e aqui também farei algumas suplemento.
O fato de os dados estarem on-chain é muito importante (nota: colocar dados "no IPFS" não funcionará, porque o IPFS não fornece verificação de nível de consenso de que não há garantia de que um determinado dado esteja disponível, ou seja, os dados devem ser armazenados em blocos). Nos dois esquemas de expansão do Plasma e do canal anterior, os dados e cálculos são completamente colocados na rede de segunda camada. Quando a rede de segunda camada interage com o Ethereum, todos os dados de transação na cadeia de segunda camada não são incluídos. estado Do ponto de vista da máquina, ou seja, todas as mudanças de estado da cadeia do Plasma não estão incluídas. Isso levará ao fato de que, se o Ethereum for separado da rede de segundo nível, como o Plasma, ele não poderá restaurar as mudanças de estado anteriores.Portanto, a disponibilidade dos dados do Ethereum depende muito da proteção dos dados do Plasma.
Mecanismo de acúmulo
Para garantir a disponibilidade dos dados, o mercado opta pelo Rollup, então como funciona o Rollup?
Figura 4 State Root no contrato L1 | Fonte
No design Rollup, há um contrato Rollup na cadeia principal, que armazena uma raiz de estado. Essa raiz de estado pode ser considerada uma versão atualizada da raiz Merkle da Merkle Tree, que armazena o saldo da conta (ou seja, um tipo de estado), o código do contrato e outras informações. A Figura 4 mostra a raiz do estado armazenada no contrato Rollup .
O nó L2 tem três funções principais: primeiro, determinar quais transações devem ser empacotadas primeiro (geralmente esse tipo de nó ou cliente é chamado de sequenciador Sequencer), em segundo lugar, ele precisa fornecer uma prova para cada dado empacotado e, finalmente, enviá-lo para o contrato L1 Rollup é verificado por este contrato. A Figura 5 mostra o papel do sequenciador em L2.
Figura 5 Sequenciar, provar e enviar Batch são as principais funções da fase L2 | Fonte
Especificamente, L2 pode transferir um lote de dados (lote) para L1. Esses dados podem ser coleções de transações altamente compactadas ou alterações de estado após a execução do contrato e também incluir a raiz do estado armazenada no contrato L1 e a nova raiz pós-estado ( raiz pós-estado) obtido após L2 processar os dados. O contrato verifica a exatidão da raiz pós-estado com base nesses dados. Passada a verificação, o lote de dados será confirmado na camada L1, completando o processo on-chain de L2 a L1.
A raiz pós-estado (raiz pós-estado) é calculada a partir dos dados originais. Para garantir que a nova raiz pós-estado nos dados enviados esteja correta, a maneira mais direta é deixar L1 recalcular uma vez. No entanto, isso sem dúvida colocará muita pressão no L1. Para resolver este problema crítico, existem dois esquemas de otimização completamente diferentes, Optimistic Rollup e ZK Rollup.
ZK Rollup e Rollup Otimista
O ZK Rollup usa provas de protocolo criptográfico, como ZK-SNARKs ou ZK-STARKs, para verificar a exatidão da raiz pós-estado após a execução do lote. Independentemente da quantidade de cálculo em L2, o ZK Rollup pode verificar rapidamente na cadeia L1.
Outro tipo de prova é o Optimistic Rollup, que usa provas de fraude. Há uma analogia vívida aqui: é como uma mãe que não verifica o dever de casa de seu filho com frequência, mas enquanto o dever de casa não for feito uma única vez, ela será severamente punida. Sob esse mecanismo, o contrato Rollup acompanha o histórico completo da raiz do estado e dos hashes de cada lote. Se alguém descobrir que um lote tem uma raiz pós-estado incorreta, poderá publicar uma prova de que o lote foi calculado incorretamente. Os outros nós juntos verificam a prova e restauram o lote e todos os lotes subsequentes.
A Figura 6 resume a comparação das vantagens e desvantagens do Optimistic Rollup e do ZK Rollup. É importante observar aqui que o ZK Rollup se destaca no TPS e tem uma vantagem significativa nos ciclos de reembolso. No entanto, suas desvantagens são a compatibilidade com EVM e o consumo computacional na camada L2:
Projetos Optimistic Rollup, como Optimism e Arbitrum, utilizam OVM e AVM respectivamente, e seus ambientes virtuais são basicamente os mesmos do EVM, podendo migrar diretamente contratos L1 para L2 para implantação. No entanto, no ZK Rollup, é bastante difícil usar o ZK-SNARK para provar a execução geral do EVM, porque o EVM não é desenvolvido de acordo com os requisitos matemáticos do cálculo da prova do ZK, portanto, é necessário transformar um determinado tipo de cliente EVM para usar Tecnologia ZK para verificação de transações e operações contratuais.
Ao mesmo tempo, mesmo após a conversão correspondente, a operação do ZK ainda requer muita entrada de energia de computação, então o ZK Rollup não é tão eficiente quanto o Optimistic Rollup na eficiência da camada L2.
O ZK Rollup fornece melhor compactação de dados do que o Optimistic Rollup, portanto, pode enviar dados menores em L1.
Como o processo de verificação de provas no ZK é mais rápido e possui maior densidade de lote, o ZK Rollup é menor no consumo de cálculo da camada L1. Pode-se entender que o pagamento do nó em L2 reduz muito os requisitos para os nós L1, melhorando significativamente a escalabilidade da camada L1.
Figura 6 Comparação de dois métodos de rollup | Fonte:
**ZK Rollup ou zkEVM Rollup? **
Embora o ZK Rollup pareça atraente, existem muitas dificuldades na implantação real. No momento, o ZK Rollup ainda tem limitações consideráveis, enquanto o Optimistic Rollup ainda é a solução principal. A maioria dos ZK Rollups implementados também são personalizados para algumas aplicações específicas.
Como entender o ZK Rollup personalizado? Os desenvolvedores constroem circuitos específicos de aplicativos ("ASICs") para diferentes DApps, como Loopring, StarkEx rollup e zkSync 1.0, que oferecem suporte a tipos específicos de pagamento, troca de tokens ou conversão de NFT. No entanto, seu design de circuito requer um alto grau de conhecimento técnico, o que leva a uma experiência ruim do desenvolvedor. Tomando como exemplo um tipo específico de dados de pagamento, o nó envia os dados da transação para o sequenciador, e o sequenciador os empacota em um lote e os envia para o nó que envia a prova como a entrada pública, o processo de prova e o contrato processo de execução na máquina virtual Não tem nada a ver, ZK é responsável apenas por provar o cálculo do rollup e o processo de compactação de um resultado de execução específico.
E o zkEVM Rollup representa a capacidade de acumular os resultados em execução da máquina virtual. Ao executar um contrato inteligente de propósito geral na camada L2, é necessário provar a validade da transição de estado antes e depois da execução do contrato, e um ambiente virtual é necessário para suportar a operação do algoritmo ZK. Portanto, o significado do zkEVM é executar o contrato, gerar o estado final, provar a validade do processo de execução do contrato e enviar os registros de transação, registros de conta e dados de registro de alteração de estado juntos no rollup. A camada L1 só precisa verificar rapidamente a prova, a sobrecarga é pequena e não há necessidade de executar o contrato novamente.A Figura 7 ilustra vividamente a função do zkVM. Deve-se notar que zkEVM é na verdade uma máquina virtual semelhante a EVM rodando na camada L2, então um termo mais preciso é Zero Knowledge Virtual Machine, zkVM, mas todos enfatizam que é compatível com Ethereum e o chamam de zkEVM.
Figura 7 Um diagrama ilustrando o zkVM | Fonte
Os projetos existentes também estão considerando o abandono gradual da otimização para aplicativos específicos e a atualização para oferecer suporte à execução de contratos de uso geral, ou seja, zkEVM Rollup. Portanto, embora o zkEVM Rollup seja um conceito subordinado do ZK Rollup, na maioria dos casos, quando o ZK Rollup é mencionado, ele se refere ao zkEVM rollup.
PARTE 4Visão geral do projeto cumulativo zkEVM
No primeiro semestre de 2023, vários projetos zkEVM surgirão em um surto. Ao prestar atenção a esses projetos, o autor se concentra principalmente nos seguintes aspectos:
Progresso atual do projeto: incluindo o estágio atual do projeto e o tempo de lançamento esperado da rede de teste e da rede principal, e se é consistente com o roteiro de desenvolvimento.
A interação real do projeto: Através da interação com a rede de teste (principal), etc., sinta subjetivamente o TPS da rede, o tempo de confirmação de uma única transação, etc., e tenha uma sensação intuitiva do desempenho da rede.
Compatibilidade com zkEVM: Este é o ponto técnico mais importante e o mais difícil de julgar. Mesmo que alguns projetos sejam de código aberto, a tecnologia no nível VM é a mais difícil e envolve mais protocolos ZK. Especificamente, é necessário prestar atenção ao protocolo ZK, segurança da VM, compatibilidade, etc.
Arquitetura do zkEVM Rollup: Em comparação com o zkEVM, os projetos gerais divulgarão sua arquitetura Rollup em white papers e outros documentos técnicos, e a diferença geral é menor, mas deve-se prestar atenção ao seu grau geral de descentralização.
Operação ecológica: O número de usuários do projeto, o grau de atividade, a operação e incubação da ecologia de aplicativos na cadeia e a manutenção da comunidade de desenvolvedores são indicadores que refletem suavemente a operação do projeto.
Situação de investimento e financiamento.
Este artigo considera o projeto mais da perspectiva dos primeiros quatro pontos e presta mais atenção à arquitetura geral do zkEVM Rollup do nível técnico.
Rolagem
Fundada em 2021, a equipe Scroll está empenhada em desenvolver o equivalente EVM do ZK Rollup para escalar o Ethereum. .zkEVM. No final de fevereiro, a Scroll anunciou que sua rede de teste Alpha agora está ativa no Goerli. Qualquer usuário pode participar de testes técnicos sem permissão. O tempo médio de bloqueio da rede de teste é de 3 segundos. Já são mais de 20 milhões de transações e mais de 1,5 milhão de blocos e mais de 4 milhões de endereços interativos. Ao mesmo tempo, Scroll também abriu a interface do ecossistema do site em 11 de abril.
A julgar pela recente divulgação de informações, a Scroll está constantemente avançando no caminho da equivalência EVM Tipo 2. Recentemente, a Scroll concluiu o desenvolvimento compatível de todos os opcodes EVM e está em processo de auditoria. Ao mesmo tempo, o próximo objetivo é ser compatível com as transações EIP2718.
Em termos de arquitetura técnica, a arquitetura do Scroll é relativamente tradicional, por isso será apresentada em detalhes aqui. Conforme mostrado na Figura 8, ele é dividido principalmente em duas partes: a parte principal é o zkEVM, que é usado para provar a exatidão da execução do EVM em L2; mas para transformar o zkEVM em um ZK Rollup completo no Ethereum, um L2 completo precisa ser construído em torno da arquitetura zkEVM. Especificamente, o testnet Scroll Alpha existente consiste em Scroll Node, Bridge Contract e Rollup Contract:
Figura 8 Arquitetura geral do rollup de rolagem | Fonte
Nó Scroll: composto por Sequencer, Relayer e Coordinator.
a) O sequenciador, o chamado sequenciador, abre JSON-RPC para usuários e aplicativos, lê transações no pool de transações e gera blocos L2 e raízes de estado. Nesta fase, os nós Sequenciadores do Scroll estão centralizados, e serão gradativamente descentralizados em futuras atualizações.
b) O Coordenador é responsável pela comunicação entre o Roller e o Scroll Node. Quando um novo bloco é gerado no Sequencer, o Roller do pool é selecionado aleatoriamente para geração da prova.
c) O Relayer monitora o Bridge Contract e o Rollup Contract nas cadeias Ethereum e Scroll. O Rollup Contract garante a disponibilidade de dados L2 no nível L1 e garante que o bloco L2 possa ser restaurado na camada L1. Uma vez que o bloco enviado pela camada L2 é verificado pelo Rollup Contract na camada L1, o bloco atingirá a finalidade na camada L2. O estado imutável de . O Bridge Contract é responsável pela comunicação entre os contratos de cadeia dupla ao cruzar cadeias, enviar mensagens arbitrárias em ambas as direções ou concluir operações de penhora e retirada de ativos ao cruzar cadeias.
Figura 9 2. Rede de Rolos | Fonte
Rede Roller: O Roller possui embutido um zkEVM, que atua como um provador na rede e é responsável por gerar as provas de validade do ZK Rollup, conforme Figura 9.
a) O Roller primeiro converte o rastreamento de ação recebido do Coordenador (ou seja, quais operações específicas o contrato realizou e quais endereços estão envolvidos) em testemunhas de circuito.
b) Gera provas para cada circuito zkEVM e finalmente agrega essas provas de vários circuitos ZK.
StarkWare
StarkWare fornece uma solução de dimensionamento baseada em STARK para garantir segurança L2, velocidade e experiência de usuário perfeita. Eles suportam vários modos de disponibilidade de dados. StarkNet é sua rede L2, enquanto StarkEx é um serviço de verificação Rollup para usuários corporativos, e DApps podem ser construídos em serviços StarkEx. No entanto, atualmente apenas circuitos personalizados podem ser escritos para DApps específicos, não para o zkEVM Rollup geral. StarkEx oferece suporte a uma série de serviços plug-and-play, incluindo cunhagem e negociação de NFT, negociação de derivativos, etc. Em termos de ecologia, a plataforma descentralizada de negociação de contratos futuros DYDX é um usuário fiel do StarkWare.
StarkNet, estritamente falando, é zkVM.Em vez de fazer circuitos ZK para opcodes Ethereum, ele fez um conjunto de linguagem de montagem mais amigável ao ZK, AIR (Algebraic Intermediate Representation) e linguagem de alto nível Cairo. Embora o próprio StarkNet não seja compatível com EVM, ele ainda pode ser compatível com Ethereum por meio de outros métodos, incluindo Kakarot (Kakarot é um zkEVM escrito no Cairo, que é um zkEVM cujo bytecode é equivalente a EVM). No meu entendimento, o StarkNet é um projeto relativamente centralizado, um dos quais é que não pode ser sincronizado com a atualização de segurança do Ethereum. Portanto, é necessário concentrar o pessoal de P&D para compensar as deficiências de segurança e acompanhar o desenvolvimento e adaptação da ETH.novo acordo.
StarkNet usa STARK como seu sistema de prova.Comparado com SNARK, STARK tem mais inovações. Ele não precisa depender de "configurações confiáveis" como SNARK. Além disso, ele também possui suposições criptográficas mais simples, evita a necessidade de curva elíptica, emparelhamento e suposições de conhecimento exponencial e depende puramente de hashing e teoria da informação, por isso é mais resistente a ataques quânticos. No geral, os STARKs são mais seguros que os SNARKs. Em termos de capacidade de expansão, o STARK tem um efeito marginal significativo e, quanto maior a prova, menor o custo total.
Porém, em termos de arquitetura, atualmente existe apenas um Sequencer (sequenciador) no sistema, que é controlado pelo StarkWare, e existe apenas um Prover (ou seja, o provador que gera ZK Proof), que não apenas gera provas para StarkNet, mas também são executados por conta própria. Prova de geração para todos os outros aplicativos no pacote StarkEx.
Variantes do ZK Rollup: Validiums e Volitions
A Validium também é uma solução de dimensionamento L2 que usa prova de computação, como ZK Rollup, para reforçar a integridade do processo de transação. Ao contrário do ZK Rollup, o Validium não armazena dados de transação na rede principal Ethereum. Sacrificar a disponibilidade de dados on-chain é uma compensação que pode levar a grandes melhorias na escalabilidade, sendo o ponto mais imediato que os Validiums podem processar cerca de 9.000 transações por segundo.
Mas, aos olhos do autor, o Validium não pode ser considerado um ZK Rollup estrito. Esta solução é semelhante ao Plasma e não atinge a disponibilidade de dados na camada L1, portanto não pode ser considerada um Rollup. A diferença com o Plasma é que o Plasma estabeleceu um "mecanismo de saída de sete dias" semelhante ao OP Rollup na camada L2, enquanto o Validium usa e ZK meios para encurtar o tempo de verificação dos dados na camada L2 e não sincroniza o dados para o L1.
O Volition, desenvolvido pela StarkWare, permite que os usuários alternem facilmente entre o ZK Rollup e o Validium. Por exemplo, alguns aplicativos, como trocas de derivativos descentralizados, podem ser mais adequados para o Validium, embora ainda desejem ser interoperáveis com aplicativos no ZK Rollup, então o Volition fornece essa comutação.
zkSync
Semelhante ao StarkNet, o zkSync sempre fez questão de escolher o zkVM, que equivale a uma linguagem de alto nível, e tem atraído muita atenção, com uma popularidade e volume de lock-up altíssimos. zkSync 1.0 (zkSync Lite) foi lançado na rede principal Ethereum em 15 de junho de 2020, alcançando uma taxa de transferência de transação de cerca de 300 TPS, mas não é compatível com EVM. E o zkSync 2.0 (zkSync Era) será lançado em 24 de março de 2023.
O objetivo do zkSync Era é gerar provas mais rapidamente usando sua VM personalizada para otimização, em vez de buscar a equivalência de EVM. Ele oferece suporte a Solidity, Vyper, Yul e Zinc (linguagem de programação interna do rollup) por meio de um poderoso compilador LLVM para implementar a maioria das funções de contrato inteligente. Devido à VM autodesenvolvida, o zkSync Era oferece suporte à abstração de conta nativa, para que qualquer conta possa usar qualquer Token para pagar.
Além disso, por meio da aplicação do protocolo zkPorter, combinado com ZK Rollups e tecnologia de fragmentação, a taxa de transferência da rede aumentou exponencialmente, atingindo mais de 20.000 TPS (semelhante à troca de disponibilidade de dados do Volitions).
No geral, o zkSync é um projeto L2 ecologicamente rico que atraiu a atenção de desenvolvedores e investidores. Embora tenha havido alguns casos recentes de projetos completamente malsucedidos no zkSync, ainda há dúvidas se os desenvolvedores podem obter uma boa experiência de desenvolvimento e migração no equivalente de linguagem de alto nível do zkVM. Atualmente, há uma falta de relatórios de uso exatos no nível do desenvolvedor. Se os desenvolvedores tiverem uma boa experiência, qual é o objetivo de outros tipos de zkVM que se esforçam para estar próximos do EVM? Ainda precisamos de mais tempo para observar.
Polígono zkEVM
A Polygon lançou a versão beta da rede principal zkEVM Rollup em 27 de março, que também é a máquina virtual equivalente do Ethereum, e abriu todo o código zkEVM. Comparado com zkSync, a quantidade bloqueada de polígonos zkEVM é muito menor, mas também existem muitos projetos interessantes e dinâmicos na ecologia.
Em termos de design Rollup, o Polygon difere do Scroll porque usa um modelo de Prova de Eficiência (PoE) para motivar o Sequenciador e o Agregador a resolver alguns dos desafios da descentralização e dos validadores sem permissão. No modelo de classificador-agregador de duas etapas sem permissão, qualquer classificador pode enviar um pedido de lotes de embalagem para obter a taxa de embalagem, mas precisa pagar a taxa de gás da camada L1 e depositar uma certa quantia de Token ; ao mesmo tempo, os Tokens de agregação precisam definir suas próprias metas para maximizar o lucro garantido para cada geração de prova. Além disso, os modos Polygon e Volition (ZK Rollup e Validium) também possuem modelos de disponibilidade de dados profundamente compatíveis para fornecer aos usuários diferentes níveis de serviços.
Além disso, a Polygon também investiu uma quantidade considerável de trabalho no protocolo ZK, e o efeito também é notável. No documento, eles resumem suas vantagens técnicas, incluindo principalmente os seguintes pontos:
Mais compatível: a Polygon sempre insistiu em usar o zkVM, que é equivalente ao EVM, para reduzir o custo dos desenvolvedores que migram dApps. Ao mesmo tempo, embora o Polygon Miden adote o protocolo ZK-STARK, ele ainda suporta a execução de contratos Solidity.
Verificação mais fácil: A razão pela qual o ZK Rollup é frequentemente criticado é que a geração de provas de validade requer hardware especializado caro que os fornecedores executam e repassam o custo aos usuários. O Polygon ZK Rollup (como o Polygon Zero) visa simplificar os esquemas de prova para que os dispositivos de nível inferior possam participar, por exemplo, testes de geração de provas Plonky2 em PCs de consumo.
Geração de prova e processo de verificação mais rápidos: O Polygon Zero pode gerar uma prova de 45kb em 170 milissegundos.
PARTE 5Lacuna entre tecnologia teórica e projetos práticos
Este relatório de pesquisa realizou principalmente a popularização científica da tecnologia ZK e a introdução do mecanismo Rollup, enfatizando a importância da disponibilidade de dados, e fez uma certa distinção na questão do ZK ou zkEVM Rollup. Além disso, com base na distinção entre zkVM e zkEVM, ele também classifica em detalhes as diferenças entre os três tipos de zkEVM e os diferentes tipos e trilhas ZK relacionadas. Finalmente, combinados com vários projetos vantajosos, revisaram seus respectivos quadros técnicos e ecologia existentes.
No entanto, em termos de projetos específicos, os projetos que escolhem linguagens de alto nível equivalentes ocupam a posição dominante no mercado, e alguns produtos com centralização séria, como o StarkWare, também podem ganhar o favor do mercado. Embora o primeiro tipo de VM mencionado na pesquisa teórica tenha fortes limitações, sob os clientes limitados do mercado, a "universalidade" parece ser um fardo e não podemos distinguir quais problemas a "expansão eficiente" rompeu e percebeu o efeito além da teoria . Claro, na verdade, muitas pessoas não prestam atenção aos recursos técnicos, então isso não parece muito Web3, mas também muito Web3.
O objetivo da tecnologia Rollup é aproveitar ainda mais o valor do blockchain, mas muitas vezes devido à necessidade urgente de se tornar um "conceito inovador" no mercado, há um fenômeno de "backtracking" e retorno à centralização. Esse é o problema do mercado atual.
O valor do blockchain é fácil de ver, quem não gostaria de ter um computador eterno? Mas o problema central é que quando a capacidade de execução deste computador é muito menor do que a de qualquer servidor ao nosso redor e requer muito investimento de recursos, mesmo que o valor de uso seja muito menor do que nosso custo de entrada, como um "produto público" , ainda é Todos podem se envolver?
Quando já temos produtos de muitos países, sociedades e até indivíduos, em que circunstâncias estamos dispostos a ignorar o alto custo de uso e perseguir o resultado de "sempre online, sempre correto"? Acho que isso é algo que a indústria de blockchain precisa pensar hoje. A tecnologia de rollup pode melhorar tecnicamente esse problema, mas ainda há um grande número de problemas que precisam ser deixados para o mercado impetuoso resolver.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
zkEVM Rollup: a lacuna entre a visão tecnológica e o projeto
Para resolver o problema de expansão da rede blockchain Layer 1, surgiu a solução Rollup. Combinado com a tecnologia ZK, o ZK Rollup se tornou o novo queridinho da pista Layer 2. No entanto, para a maioria das pessoas, conceitos relacionados como ZK, Rollup e EVM podem ter um certo limite de compreensão. Portanto, o objetivo deste relatório de pesquisa é classificar sistematicamente uma série de conceitos do zkEVM Rollup para você em uma linguagem concisa e fácil de entender, analisar profundamente a evolução e o status de desenvolvimento da tecnologia zkEVM Rollup e interpretar os principais projetos em detalhes. Ele é projetado para ajudá-lo a entender e julgar completamente a tendência de desenvolvimento da trilha do zkEVM Rollup.
PARTE 1 Entendendo o ZK
ZK (ou ZKP), o nome completo é Zero-Knowledge Proof, ou seja, prova de conhecimento zero. Em criptografia, prova de conhecimento zero ou protocolo de conhecimento zero é um método pelo qual uma das partes (o provador) pode submeter ao outra parte (certificador de verificação) para provar um fato sem divulgar a informação específica do fato, ou seja, uma parte (provador) pode deixar a outra parte saber se o fato está correto sem divulgar nenhuma "informação específica" de o fato, então a tecnologia ZK pode ser usada em privacidade. O campo de proteção nos dá muito espaço para imaginação.
Claro, além dos benefícios de proteção de privacidade que a tecnologia ZK pode trazer, no ZK Rollup, a tecnologia ZK é mais importante para resolver o problema de "difícil verificação". O processo de "verificação" é muito importante para o blockchain. A maior parte do processo de cálculo no Ethereum é atender aos requisitos de verificação, e o ZK Rollup pode reduzir bastante o tempo gasto na verificação por toda a rede de nós. Por exemplo, se um bloco demora muito para verificar se atende às regras de toda a rede quando o bloco foi gerado, pode haver um provador que primeiro o verifique e gere uma "prova" do resultado do cálculo desse bloco, e o resto O objetivo de verificar o bloco pode ser alcançado verificando rapidamente essa "prova" em vez do bloco original com uma grande quantidade de cálculos.
Um protocolo ZK simples é dividido nas seguintes etapas, geração de chave, comprovação e verificação, e irei desmontá-los um a um para você.
01 Geração, comprovação e verificação da chave
No ZK, precisamos primeiro converter o problema a ser verificado em uma expressão matemática e depois em um polinômio e expressá-lo na forma de um circuito aritmético. Quando um programa é convertido em um circuito aritmético, ele é dividido em etapas individuais que consistem em operações aritméticas básicas, como adição, subtração, etc. Como uma função que será gerada, ela pode ser transformada no seguinte diagrama de circuito, veja a Figura 1.
Figura 1 Um exemplo de diagrama de circuito, pode-se notar que todas as operações no circuito são divididas nas operações básicas mais simples | Fonte
Usando este circuito e alguns números aleatórios como entrada, podemos gerar uma chave de prova (pk, chave de prova) e uma chave de verificação (vk, chave de verificação) para o processo de verificação subsequente, o diagrama esquemático é mostrado na Figura 2.
Figura 2 Geração de "parâmetros públicos"
Nosso sistema de prova também requer dois tipos de entradas - privada e pública, juntamente com a chave de prova para gerar a prova. Entre eles, o input privado (testemunha) é o segredo que queremos esconder, e o input público é a informação que pode ser tornada pública. Por exemplo, na equação X+Y*Z=OUT, X e OUT são entradas públicas, enquanto Y e Z possuem valores que não queremos que sejam públicos para o validador. Embora o valor de Y*Z possa ser deduzido com base na entrada do público, os valores específicos de Y e Z ainda são incertos.
Figura 3 O processo de prova e processo de verificação de ZK-SNARKs
Quando o verificador recebe a prova, ele usa a entrada pública, a prova e a chave de verificação para verificar a prova e retorna o resultado da verificação (ou seja, se a verificação foi bem-sucedida).
Depois de entender o processo acima, podemos aplicar esta tecnologia para bloquear a verificação para realizar um pequeno ZK-SNARK, conforme mostrado na Figura 3. Existem muitos protocolos e métodos para realizar a prova de conhecimento zero.SNARK é relativamente fácil de entender e também é a escolha da maioria dos projetos nesta fase. No parágrafo "Dos ZK-SNARKs aos ZK-STARKs" falaremos sobre as vantagens e desvantagens dos SNARKs.
02 Tente um pouco de SNARK
Vamos usar uma prova de conhecimento zero de uma Merkle Tree que registra o status da conta como um exemplo para praticar. A Merkle Tree registra o endereço e o saldo da conta. Quando houver uma nova transação que precise atualizar a Merkle Tree, precisamos realizar as seguintes operações:
Verifique se o remetente e o destinatário da transação estão nos nós folha da árvore.
Verifique a assinatura do remetente.
Atualize os saldos do remetente e do destinatário.
Atualize o nó raiz da Merkle Tree (ou seja, Merkle Root) e use-o como saída final.
Na ausência de provas de conhecimento zero, o verificador precisa repetir essas etapas para garantir a precisão do cálculo. Mas depois de usar a prova de conhecimento zero, a situação é diferente. Primeiro, precisamos identificar dois tipos de entradas:
Durante esse processo, apenas as informações da nova transação, o Merkle Root original e o Merkle Root atualizado são entradas públicas.
A própria Merkle Tree atua como testemunha (testemunha) e não precisa ser lida ou processada pelo verificador.
Em segundo lugar, precisamos gerar chaves e circuitos de computação. Construímos processos de cálculo como atualização Merkle Tree e verificação de endereço de entrada e saída em circuitos de cálculo para obter chaves de prova e chaves de verificação. Este circuito não tem nada a ver com as informações da transação de entrada, nem com o Merkle Root existente, porque o método de cálculo da Merkle Tree é fixo.
Na etapa de geração de provas, tomamos como entrada as duas Merkle Trees e as informações da transação. Na etapa de verificador, o verificador pode garantir a confiabilidade da atualização sem obter a Merkle Tree, ou seja, sem saber as informações da conta. O circuito é como uma caixa preta sólida, desde que a entrada esteja correta, obterá a saída correta.
Usando a prova de conhecimento zero, outros verificadores podem verificar rapidamente se o processo de geração da Árvore Merkle é confiável, reduzindo assim o tempo para verificação repetida na rede, e as informações da Árvore Merkle não precisam ser divulgadas ao verificador.
03 De ZK-SNARKs a ZK-STARKs
O protocolo de prova mencionado acima é o ZK-SNARKs. SNARK significa sucintos argumentos não interativos de conhecimento, onde sucinto refere-se à simplicidade deste método, e não interativo refere-se àquele comparado a outros métodos de prova, SNARKs são provas não interativas, ou seja, o verificador só precisa usar a prova sucinta gerada pode obter o resultado da verificação. No entanto, existem alguns problemas com ZK-SNARKs. Na etapa de geração da chave, o circuito e o número aleatório equivalem a um conjunto de parâmetros públicos iniciais, havendo um inevitável problema de centralização no processo de geração desse parâmetro público.
Os ZK-STARKs têm uma abordagem diferente baseada nos SNARKs, onde "s" significa escalabilidade, o que prova que o tempo de geração e o tempo de cálculo original são quase lineares, e o tempo de verificação é logarítmico no cálculo original, o que significa que no No caso de um grande conjunto de dados como dados, o tempo de verificação exigido pelo verificador é bastante reduzido.
Ao mesmo tempo, como uma versão atualizada do ZK-SNARKs, o ZK-STARKs pode não apenas melhorar a eficiência da verificação (a eficiência teórica é 10 vezes), mas também não depende de curvas elípticas ou configurações confiáveis e não requer o processo de geração de parâmetros públicos iniciais (letra "T" significa transparência), o que elimina a necessidade de uma configuração confiável centralizada. Alguns desenvolvedores acreditam que a função hash no ZK-STARK pode ajudar a resistir a ataques quânticos.
No entanto, o ZK-STARKs foi lançado tarde, a tecnologia atual não está madura o suficiente e depende de funções hash, o que limita sua versatilidade. O ZK-SNARKs ainda é um algoritmo de prova geral. Alguns exemplos de algoritmos baseados em STARK incluem Fractal, SuperSonic, etc., e projetos relacionados incluem StarkWare, Polygon Miden, etc.
PARTE 2 Entendendo o Rollup
Além do ZK, outro conceito que precisamos entender é o Rollup, cujo significado é resolver o problema de congestionamento da rede da camada 1.
Tome o Ethereum como exemplo, atualmente ele tem o problema de congestionamento de transações. Existem duas maneiras de resolver esse problema: uma é aumentar a capacidade de transação do próprio blockchain, como expandir o throughput do blockchain por meio de tecnologias como sharding. Outra abordagem é mudar a forma como o blockchain é usado, ou seja, realizar a maioria das atividades na segunda camada (Layer 2, doravante denominada L2), em vez de diretamente na cadeia. Nesse caso, geralmente é implantado um contrato inteligente na cadeia, responsável apenas pelo processamento de depósitos e saques, e usa vários métodos para ler dados fora da cadeia para verificar se tudo o que acontece fora da cadeia está de acordo com as regras. Isso equivale a erguer uma rodovia ao lado de uma pequena estrada, ou seja, através da expansão L2 para resolver o problema de congestionamento.
Atualmente, os três principais tipos ou soluções para expansão L2 são canais de estado, Plasma e Rollup. São três paradigmas diferentes, cada um com vantagens e desvantagens. Todas as extensões L2 podem ser classificadas aproximadamente nessas três categorias (embora haja algumas disputas sobre nomenclatura, como validium), entre as quais o Rollup tem suas próprias vantagens.
Rollup e disponibilidade de dados
Comparado com outras soluções de expansão, o Rollup tem algumas vantagens. Uma das vantagens mais intuitivas é que resolve o problema de disponibilidade de dados do Plasma (mencionado no capítulo "Disponibilidade de dados" do artigo do Sr. Darren), e aqui também farei algumas suplemento.
O fato de os dados estarem on-chain é muito importante (nota: colocar dados "no IPFS" não funcionará, porque o IPFS não fornece verificação de nível de consenso de que não há garantia de que um determinado dado esteja disponível, ou seja, os dados devem ser armazenados em blocos). Nos dois esquemas de expansão do Plasma e do canal anterior, os dados e cálculos são completamente colocados na rede de segunda camada. Quando a rede de segunda camada interage com o Ethereum, todos os dados de transação na cadeia de segunda camada não são incluídos. estado Do ponto de vista da máquina, ou seja, todas as mudanças de estado da cadeia do Plasma não estão incluídas. Isso levará ao fato de que, se o Ethereum for separado da rede de segundo nível, como o Plasma, ele não poderá restaurar as mudanças de estado anteriores.Portanto, a disponibilidade dos dados do Ethereum depende muito da proteção dos dados do Plasma.
Mecanismo de acúmulo
Para garantir a disponibilidade dos dados, o mercado opta pelo Rollup, então como funciona o Rollup?
Figura 4 State Root no contrato L1 | Fonte
No design Rollup, há um contrato Rollup na cadeia principal, que armazena uma raiz de estado. Essa raiz de estado pode ser considerada uma versão atualizada da raiz Merkle da Merkle Tree, que armazena o saldo da conta (ou seja, um tipo de estado), o código do contrato e outras informações. A Figura 4 mostra a raiz do estado armazenada no contrato Rollup .
O nó L2 tem três funções principais: primeiro, determinar quais transações devem ser empacotadas primeiro (geralmente esse tipo de nó ou cliente é chamado de sequenciador Sequencer), em segundo lugar, ele precisa fornecer uma prova para cada dado empacotado e, finalmente, enviá-lo para o contrato L1 Rollup é verificado por este contrato. A Figura 5 mostra o papel do sequenciador em L2.
Figura 5 Sequenciar, provar e enviar Batch são as principais funções da fase L2 | Fonte
Especificamente, L2 pode transferir um lote de dados (lote) para L1. Esses dados podem ser coleções de transações altamente compactadas ou alterações de estado após a execução do contrato e também incluir a raiz do estado armazenada no contrato L1 e a nova raiz pós-estado ( raiz pós-estado) obtido após L2 processar os dados. O contrato verifica a exatidão da raiz pós-estado com base nesses dados. Passada a verificação, o lote de dados será confirmado na camada L1, completando o processo on-chain de L2 a L1.
A raiz pós-estado (raiz pós-estado) é calculada a partir dos dados originais. Para garantir que a nova raiz pós-estado nos dados enviados esteja correta, a maneira mais direta é deixar L1 recalcular uma vez. No entanto, isso sem dúvida colocará muita pressão no L1. Para resolver este problema crítico, existem dois esquemas de otimização completamente diferentes, Optimistic Rollup e ZK Rollup.
ZK Rollup e Rollup Otimista
O ZK Rollup usa provas de protocolo criptográfico, como ZK-SNARKs ou ZK-STARKs, para verificar a exatidão da raiz pós-estado após a execução do lote. Independentemente da quantidade de cálculo em L2, o ZK Rollup pode verificar rapidamente na cadeia L1.
Outro tipo de prova é o Optimistic Rollup, que usa provas de fraude. Há uma analogia vívida aqui: é como uma mãe que não verifica o dever de casa de seu filho com frequência, mas enquanto o dever de casa não for feito uma única vez, ela será severamente punida. Sob esse mecanismo, o contrato Rollup acompanha o histórico completo da raiz do estado e dos hashes de cada lote. Se alguém descobrir que um lote tem uma raiz pós-estado incorreta, poderá publicar uma prova de que o lote foi calculado incorretamente. Os outros nós juntos verificam a prova e restauram o lote e todos os lotes subsequentes.
A Figura 6 resume a comparação das vantagens e desvantagens do Optimistic Rollup e do ZK Rollup. É importante observar aqui que o ZK Rollup se destaca no TPS e tem uma vantagem significativa nos ciclos de reembolso. No entanto, suas desvantagens são a compatibilidade com EVM e o consumo computacional na camada L2:
Projetos Optimistic Rollup, como Optimism e Arbitrum, utilizam OVM e AVM respectivamente, e seus ambientes virtuais são basicamente os mesmos do EVM, podendo migrar diretamente contratos L1 para L2 para implantação. No entanto, no ZK Rollup, é bastante difícil usar o ZK-SNARK para provar a execução geral do EVM, porque o EVM não é desenvolvido de acordo com os requisitos matemáticos do cálculo da prova do ZK, portanto, é necessário transformar um determinado tipo de cliente EVM para usar Tecnologia ZK para verificação de transações e operações contratuais.
Ao mesmo tempo, mesmo após a conversão correspondente, a operação do ZK ainda requer muita entrada de energia de computação, então o ZK Rollup não é tão eficiente quanto o Optimistic Rollup na eficiência da camada L2.
O ZK Rollup fornece melhor compactação de dados do que o Optimistic Rollup, portanto, pode enviar dados menores em L1.
Como o processo de verificação de provas no ZK é mais rápido e possui maior densidade de lote, o ZK Rollup é menor no consumo de cálculo da camada L1. Pode-se entender que o pagamento do nó em L2 reduz muito os requisitos para os nós L1, melhorando significativamente a escalabilidade da camada L1.
Figura 6 Comparação de dois métodos de rollup | Fonte:
**ZK Rollup ou zkEVM Rollup? **
Embora o ZK Rollup pareça atraente, existem muitas dificuldades na implantação real. No momento, o ZK Rollup ainda tem limitações consideráveis, enquanto o Optimistic Rollup ainda é a solução principal. A maioria dos ZK Rollups implementados também são personalizados para algumas aplicações específicas.
Como entender o ZK Rollup personalizado? Os desenvolvedores constroem circuitos específicos de aplicativos ("ASICs") para diferentes DApps, como Loopring, StarkEx rollup e zkSync 1.0, que oferecem suporte a tipos específicos de pagamento, troca de tokens ou conversão de NFT. No entanto, seu design de circuito requer um alto grau de conhecimento técnico, o que leva a uma experiência ruim do desenvolvedor. Tomando como exemplo um tipo específico de dados de pagamento, o nó envia os dados da transação para o sequenciador, e o sequenciador os empacota em um lote e os envia para o nó que envia a prova como a entrada pública, o processo de prova e o contrato processo de execução na máquina virtual Não tem nada a ver, ZK é responsável apenas por provar o cálculo do rollup e o processo de compactação de um resultado de execução específico.
E o zkEVM Rollup representa a capacidade de acumular os resultados em execução da máquina virtual. Ao executar um contrato inteligente de propósito geral na camada L2, é necessário provar a validade da transição de estado antes e depois da execução do contrato, e um ambiente virtual é necessário para suportar a operação do algoritmo ZK. Portanto, o significado do zkEVM é executar o contrato, gerar o estado final, provar a validade do processo de execução do contrato e enviar os registros de transação, registros de conta e dados de registro de alteração de estado juntos no rollup. A camada L1 só precisa verificar rapidamente a prova, a sobrecarga é pequena e não há necessidade de executar o contrato novamente.A Figura 7 ilustra vividamente a função do zkVM. Deve-se notar que zkEVM é na verdade uma máquina virtual semelhante a EVM rodando na camada L2, então um termo mais preciso é Zero Knowledge Virtual Machine, zkVM, mas todos enfatizam que é compatível com Ethereum e o chamam de zkEVM.
Figura 7 Um diagrama ilustrando o zkVM | Fonte
Os projetos existentes também estão considerando o abandono gradual da otimização para aplicativos específicos e a atualização para oferecer suporte à execução de contratos de uso geral, ou seja, zkEVM Rollup. Portanto, embora o zkEVM Rollup seja um conceito subordinado do ZK Rollup, na maioria dos casos, quando o ZK Rollup é mencionado, ele se refere ao zkEVM rollup.
PARTE 4 Visão geral do projeto cumulativo zkEVM
No primeiro semestre de 2023, vários projetos zkEVM surgirão em um surto. Ao prestar atenção a esses projetos, o autor se concentra principalmente nos seguintes aspectos:
Progresso atual do projeto: incluindo o estágio atual do projeto e o tempo de lançamento esperado da rede de teste e da rede principal, e se é consistente com o roteiro de desenvolvimento.
A interação real do projeto: Através da interação com a rede de teste (principal), etc., sinta subjetivamente o TPS da rede, o tempo de confirmação de uma única transação, etc., e tenha uma sensação intuitiva do desempenho da rede.
Compatibilidade com zkEVM: Este é o ponto técnico mais importante e o mais difícil de julgar. Mesmo que alguns projetos sejam de código aberto, a tecnologia no nível VM é a mais difícil e envolve mais protocolos ZK. Especificamente, é necessário prestar atenção ao protocolo ZK, segurança da VM, compatibilidade, etc.
Arquitetura do zkEVM Rollup: Em comparação com o zkEVM, os projetos gerais divulgarão sua arquitetura Rollup em white papers e outros documentos técnicos, e a diferença geral é menor, mas deve-se prestar atenção ao seu grau geral de descentralização.
Operação ecológica: O número de usuários do projeto, o grau de atividade, a operação e incubação da ecologia de aplicativos na cadeia e a manutenção da comunidade de desenvolvedores são indicadores que refletem suavemente a operação do projeto.
Situação de investimento e financiamento.
Este artigo considera o projeto mais da perspectiva dos primeiros quatro pontos e presta mais atenção à arquitetura geral do zkEVM Rollup do nível técnico.
Rolagem
Fundada em 2021, a equipe Scroll está empenhada em desenvolver o equivalente EVM do ZK Rollup para escalar o Ethereum. .zkEVM. No final de fevereiro, a Scroll anunciou que sua rede de teste Alpha agora está ativa no Goerli. Qualquer usuário pode participar de testes técnicos sem permissão. O tempo médio de bloqueio da rede de teste é de 3 segundos. Já são mais de 20 milhões de transações e mais de 1,5 milhão de blocos e mais de 4 milhões de endereços interativos. Ao mesmo tempo, Scroll também abriu a interface do ecossistema do site em 11 de abril.
A julgar pela recente divulgação de informações, a Scroll está constantemente avançando no caminho da equivalência EVM Tipo 2. Recentemente, a Scroll concluiu o desenvolvimento compatível de todos os opcodes EVM e está em processo de auditoria. Ao mesmo tempo, o próximo objetivo é ser compatível com as transações EIP2718.
Em termos de arquitetura técnica, a arquitetura do Scroll é relativamente tradicional, por isso será apresentada em detalhes aqui. Conforme mostrado na Figura 8, ele é dividido principalmente em duas partes: a parte principal é o zkEVM, que é usado para provar a exatidão da execução do EVM em L2; mas para transformar o zkEVM em um ZK Rollup completo no Ethereum, um L2 completo precisa ser construído em torno da arquitetura zkEVM. Especificamente, o testnet Scroll Alpha existente consiste em Scroll Node, Bridge Contract e Rollup Contract:
Figura 8 Arquitetura geral do rollup de rolagem | Fonte
a) O sequenciador, o chamado sequenciador, abre JSON-RPC para usuários e aplicativos, lê transações no pool de transações e gera blocos L2 e raízes de estado. Nesta fase, os nós Sequenciadores do Scroll estão centralizados, e serão gradativamente descentralizados em futuras atualizações.
b) O Coordenador é responsável pela comunicação entre o Roller e o Scroll Node. Quando um novo bloco é gerado no Sequencer, o Roller do pool é selecionado aleatoriamente para geração da prova.
c) O Relayer monitora o Bridge Contract e o Rollup Contract nas cadeias Ethereum e Scroll. O Rollup Contract garante a disponibilidade de dados L2 no nível L1 e garante que o bloco L2 possa ser restaurado na camada L1. Uma vez que o bloco enviado pela camada L2 é verificado pelo Rollup Contract na camada L1, o bloco atingirá a finalidade na camada L2. O estado imutável de . O Bridge Contract é responsável pela comunicação entre os contratos de cadeia dupla ao cruzar cadeias, enviar mensagens arbitrárias em ambas as direções ou concluir operações de penhora e retirada de ativos ao cruzar cadeias.
Figura 9 2. Rede de Rolos | Fonte
a) O Roller primeiro converte o rastreamento de ação recebido do Coordenador (ou seja, quais operações específicas o contrato realizou e quais endereços estão envolvidos) em testemunhas de circuito.
b) Gera provas para cada circuito zkEVM e finalmente agrega essas provas de vários circuitos ZK.
StarkWare
StarkWare fornece uma solução de dimensionamento baseada em STARK para garantir segurança L2, velocidade e experiência de usuário perfeita. Eles suportam vários modos de disponibilidade de dados. StarkNet é sua rede L2, enquanto StarkEx é um serviço de verificação Rollup para usuários corporativos, e DApps podem ser construídos em serviços StarkEx. No entanto, atualmente apenas circuitos personalizados podem ser escritos para DApps específicos, não para o zkEVM Rollup geral. StarkEx oferece suporte a uma série de serviços plug-and-play, incluindo cunhagem e negociação de NFT, negociação de derivativos, etc. Em termos de ecologia, a plataforma descentralizada de negociação de contratos futuros DYDX é um usuário fiel do StarkWare.
StarkNet, estritamente falando, é zkVM.Em vez de fazer circuitos ZK para opcodes Ethereum, ele fez um conjunto de linguagem de montagem mais amigável ao ZK, AIR (Algebraic Intermediate Representation) e linguagem de alto nível Cairo. Embora o próprio StarkNet não seja compatível com EVM, ele ainda pode ser compatível com Ethereum por meio de outros métodos, incluindo Kakarot (Kakarot é um zkEVM escrito no Cairo, que é um zkEVM cujo bytecode é equivalente a EVM). No meu entendimento, o StarkNet é um projeto relativamente centralizado, um dos quais é que não pode ser sincronizado com a atualização de segurança do Ethereum. Portanto, é necessário concentrar o pessoal de P&D para compensar as deficiências de segurança e acompanhar o desenvolvimento e adaptação da ETH.novo acordo.
StarkNet usa STARK como seu sistema de prova.Comparado com SNARK, STARK tem mais inovações. Ele não precisa depender de "configurações confiáveis" como SNARK. Além disso, ele também possui suposições criptográficas mais simples, evita a necessidade de curva elíptica, emparelhamento e suposições de conhecimento exponencial e depende puramente de hashing e teoria da informação, por isso é mais resistente a ataques quânticos. No geral, os STARKs são mais seguros que os SNARKs. Em termos de capacidade de expansão, o STARK tem um efeito marginal significativo e, quanto maior a prova, menor o custo total.
Porém, em termos de arquitetura, atualmente existe apenas um Sequencer (sequenciador) no sistema, que é controlado pelo StarkWare, e existe apenas um Prover (ou seja, o provador que gera ZK Proof), que não apenas gera provas para StarkNet, mas também são executados por conta própria. Prova de geração para todos os outros aplicativos no pacote StarkEx.
Variantes do ZK Rollup: Validiums e Volitions
A Validium também é uma solução de dimensionamento L2 que usa prova de computação, como ZK Rollup, para reforçar a integridade do processo de transação. Ao contrário do ZK Rollup, o Validium não armazena dados de transação na rede principal Ethereum. Sacrificar a disponibilidade de dados on-chain é uma compensação que pode levar a grandes melhorias na escalabilidade, sendo o ponto mais imediato que os Validiums podem processar cerca de 9.000 transações por segundo.
Mas, aos olhos do autor, o Validium não pode ser considerado um ZK Rollup estrito. Esta solução é semelhante ao Plasma e não atinge a disponibilidade de dados na camada L1, portanto não pode ser considerada um Rollup. A diferença com o Plasma é que o Plasma estabeleceu um "mecanismo de saída de sete dias" semelhante ao OP Rollup na camada L2, enquanto o Validium usa e ZK meios para encurtar o tempo de verificação dos dados na camada L2 e não sincroniza o dados para o L1.
O Volition, desenvolvido pela StarkWare, permite que os usuários alternem facilmente entre o ZK Rollup e o Validium. Por exemplo, alguns aplicativos, como trocas de derivativos descentralizados, podem ser mais adequados para o Validium, embora ainda desejem ser interoperáveis com aplicativos no ZK Rollup, então o Volition fornece essa comutação.
zkSync
Semelhante ao StarkNet, o zkSync sempre fez questão de escolher o zkVM, que equivale a uma linguagem de alto nível, e tem atraído muita atenção, com uma popularidade e volume de lock-up altíssimos. zkSync 1.0 (zkSync Lite) foi lançado na rede principal Ethereum em 15 de junho de 2020, alcançando uma taxa de transferência de transação de cerca de 300 TPS, mas não é compatível com EVM. E o zkSync 2.0 (zkSync Era) será lançado em 24 de março de 2023.
O objetivo do zkSync Era é gerar provas mais rapidamente usando sua VM personalizada para otimização, em vez de buscar a equivalência de EVM. Ele oferece suporte a Solidity, Vyper, Yul e Zinc (linguagem de programação interna do rollup) por meio de um poderoso compilador LLVM para implementar a maioria das funções de contrato inteligente. Devido à VM autodesenvolvida, o zkSync Era oferece suporte à abstração de conta nativa, para que qualquer conta possa usar qualquer Token para pagar.
Além disso, por meio da aplicação do protocolo zkPorter, combinado com ZK Rollups e tecnologia de fragmentação, a taxa de transferência da rede aumentou exponencialmente, atingindo mais de 20.000 TPS (semelhante à troca de disponibilidade de dados do Volitions).
No geral, o zkSync é um projeto L2 ecologicamente rico que atraiu a atenção de desenvolvedores e investidores. Embora tenha havido alguns casos recentes de projetos completamente malsucedidos no zkSync, ainda há dúvidas se os desenvolvedores podem obter uma boa experiência de desenvolvimento e migração no equivalente de linguagem de alto nível do zkVM. Atualmente, há uma falta de relatórios de uso exatos no nível do desenvolvedor. Se os desenvolvedores tiverem uma boa experiência, qual é o objetivo de outros tipos de zkVM que se esforçam para estar próximos do EVM? Ainda precisamos de mais tempo para observar.
Polígono zkEVM
A Polygon lançou a versão beta da rede principal zkEVM Rollup em 27 de março, que também é a máquina virtual equivalente do Ethereum, e abriu todo o código zkEVM. Comparado com zkSync, a quantidade bloqueada de polígonos zkEVM é muito menor, mas também existem muitos projetos interessantes e dinâmicos na ecologia.
Em termos de design Rollup, o Polygon difere do Scroll porque usa um modelo de Prova de Eficiência (PoE) para motivar o Sequenciador e o Agregador a resolver alguns dos desafios da descentralização e dos validadores sem permissão. No modelo de classificador-agregador de duas etapas sem permissão, qualquer classificador pode enviar um pedido de lotes de embalagem para obter a taxa de embalagem, mas precisa pagar a taxa de gás da camada L1 e depositar uma certa quantia de Token ; ao mesmo tempo, os Tokens de agregação precisam definir suas próprias metas para maximizar o lucro garantido para cada geração de prova. Além disso, os modos Polygon e Volition (ZK Rollup e Validium) também possuem modelos de disponibilidade de dados profundamente compatíveis para fornecer aos usuários diferentes níveis de serviços.
Além disso, a Polygon também investiu uma quantidade considerável de trabalho no protocolo ZK, e o efeito também é notável. No documento, eles resumem suas vantagens técnicas, incluindo principalmente os seguintes pontos:
Mais compatível: a Polygon sempre insistiu em usar o zkVM, que é equivalente ao EVM, para reduzir o custo dos desenvolvedores que migram dApps. Ao mesmo tempo, embora o Polygon Miden adote o protocolo ZK-STARK, ele ainda suporta a execução de contratos Solidity.
Verificação mais fácil: A razão pela qual o ZK Rollup é frequentemente criticado é que a geração de provas de validade requer hardware especializado caro que os fornecedores executam e repassam o custo aos usuários. O Polygon ZK Rollup (como o Polygon Zero) visa simplificar os esquemas de prova para que os dispositivos de nível inferior possam participar, por exemplo, testes de geração de provas Plonky2 em PCs de consumo.
Geração de prova e processo de verificação mais rápidos: O Polygon Zero pode gerar uma prova de 45kb em 170 milissegundos.
PARTE 5 Lacuna entre tecnologia teórica e projetos práticos
Este relatório de pesquisa realizou principalmente a popularização científica da tecnologia ZK e a introdução do mecanismo Rollup, enfatizando a importância da disponibilidade de dados, e fez uma certa distinção na questão do ZK ou zkEVM Rollup. Além disso, com base na distinção entre zkVM e zkEVM, ele também classifica em detalhes as diferenças entre os três tipos de zkEVM e os diferentes tipos e trilhas ZK relacionadas. Finalmente, combinados com vários projetos vantajosos, revisaram seus respectivos quadros técnicos e ecologia existentes.
No entanto, em termos de projetos específicos, os projetos que escolhem linguagens de alto nível equivalentes ocupam a posição dominante no mercado, e alguns produtos com centralização séria, como o StarkWare, também podem ganhar o favor do mercado. Embora o primeiro tipo de VM mencionado na pesquisa teórica tenha fortes limitações, sob os clientes limitados do mercado, a "universalidade" parece ser um fardo e não podemos distinguir quais problemas a "expansão eficiente" rompeu e percebeu o efeito além da teoria . Claro, na verdade, muitas pessoas não prestam atenção aos recursos técnicos, então isso não parece muito Web3, mas também muito Web3.
O objetivo da tecnologia Rollup é aproveitar ainda mais o valor do blockchain, mas muitas vezes devido à necessidade urgente de se tornar um "conceito inovador" no mercado, há um fenômeno de "backtracking" e retorno à centralização. Esse é o problema do mercado atual.
O valor do blockchain é fácil de ver, quem não gostaria de ter um computador eterno? Mas o problema central é que quando a capacidade de execução deste computador é muito menor do que a de qualquer servidor ao nosso redor e requer muito investimento de recursos, mesmo que o valor de uso seja muito menor do que nosso custo de entrada, como um "produto público" , ainda é Todos podem se envolver?
Quando já temos produtos de muitos países, sociedades e até indivíduos, em que circunstâncias estamos dispostos a ignorar o alto custo de uso e perseguir o resultado de "sempre online, sempre correto"? Acho que isso é algo que a indústria de blockchain precisa pensar hoje. A tecnologia de rollup pode melhorar tecnicamente esse problema, mas ainda há um grande número de problemas que precisam ser deixados para o mercado impetuoso resolver.