O cofundador da Scroll, Zhang Ye, falou sobre quatro partes. Na primeira parte, Zhang Ye apresentou o histórico de desenvolvimento e por que precisamos do zkEVM em primeiro lugar e por que ele se tornou tão popular nos últimos dois anos. Na segunda parte, ele explicou como através de um processo completo. Construir zkEVM do zero inclui sistemas aritméticos e de prova. A terceira parte fala sobre os problemas que Scroll encontrou ao construir zkEVM através de algumas questões de pesquisa interessantes e, finalmente, apresenta alguns outros aplicativos usando zkEVM.
O blockchain tradicional da Camada 1 terá alguns nós mantidos juntos através da rede P2P. Ao receber a transação do usuário, ele irá executá-la na máquina virtual EVM, ler o contrato de chamada e armazenamento e atualizar a árvore de estado global de acordo com a transação.
A vantagem de tal arquitetura é a descentralização e a segurança. A desvantagem é que as taxas de transação em L1 são caras e a confirmação da transação é lenta.
Na arquitetura ZK-Rollup, a rede L2 só precisa fazer o upload dos dados e da prova para verificar a exatidão dos dados para L1, onde a prova é calculada através de um circuito de prova de conhecimento zero.
No início do ZK-Rollup, o circuito era projetado para aplicações específicas. Os usuários precisavam enviar transações para diferentes provadores e, em seguida, ZK-Rollups de diferentes aplicações enviavam seus próprios dados e provas para L1. O problema que isso traz é que a capacidade de composição do contrato L1 original é perdida.
O que Scroll faz é uma solução zkEVM nativa, que é um ZK-Rollup de uso geral. Isso não é apenas mais fácil de usar, mas também fornece aos desenvolvedores uma melhor experiência de desenvolvimento em L1. É claro que o desenvolvimento por trás disso é muito difícil e o custo da geração de provas atuais também é muito alto.
Felizmente, a eficiência das provas de conhecimento zero melhorou significativamente nos últimos dois anos, razão pela qual o zkEVM se tornou tão popular nos últimos dois anos. Há pelo menos quatro razões pelas quais isso se torna viável. A primeira é o surgimento do comprometimento polinomial. No sistema de prova original de Groth16, a escala das restrições era muito grande, mas o comprometimento polinomial pode suportar restrições de ordem superior e reduzir a escala do. prova em segundo lugar, o surgimento de tabelas de pesquisa e portas personalizadas pode suportar designs mais flexíveis e tornar as provas mais eficientes; o terceiro são os avanços na aceleração de hardware, que podem reduzir o tempo de prova em 1-2 ordens de magnitude por meio de GPU, FPGA e ASIC; A quarta prova recursiva pode comprimir várias provas em uma prova, tornando-a menor e mais fácil de verificar. Portanto, combinando esses quatro fatores, a eficiência de geração de provas de conhecimento zero é três ordens de grandeza maior do que há dois anos, o que também é a origem do Scoll.
De acordo com a definição de Justin Drake, o zkEVM pode ser dividido em três categorias. A primeira categoria é a compatibilidade no nível da linguagem. O principal motivo é que o EVM não foi projetado para ZK e possui muitos códigos de operação que não são amigáveis ao ZK. muita sobrecarga adicional. Portanto, empresas como Starkware e zkSync optam por compilar Solidity ou Yul em compiladores compatíveis com ZK no nível da linguagem.
O segundo tipo é a compatibilidade em nível de bytecode que Scroll está fazendo, que prova diretamente se o processamento de bytecode do EVM está correto ou não, e herda diretamente o ambiente de execução do Ethereum. Algumas compensações que podem ser feitas aqui são usar uma raiz de estado diferente da EVM, como usar uma estrutura de dados compatível com ZK. Hermez e Consensys estão fazendo algo semelhante.
A terceira categoria é a compatibilidade no nível de consenso. A desvantagem aqui é que não é apenas necessário manter o EVM inalterado, mas também incluir a estrutura de armazenamento para alcançar a compatibilidade total com o Ethereum, ao custo de um tempo de prova mais longo. Scroll está sendo construído em cooperação com a equipe PSE da Fundação Ethereum para realizar a ZKização do Ethereum.
Na segunda parte, Zhang Ye mostrou a todos como construir o ZKVM do zero.
Processo completo
Em primeiro lugar, na parte front-end do ZKP, você precisa expressar seus cálculos por meio de aritmética matemática. Os mais comumente usados são R1CS linear, assim como Plonkish e AIR. Depois de obter as restrições por meio da aritmética, você precisa executar o algoritmo de prova no backend do ZKP para provar a exatidão do cálculo. Aqui estão as provas de oráculo interativo polinomial (IOP polinomial) e o esquema de compromisso polinomial (PCS).
Aqui precisamos provar que zkEVM e Scroll usam uma combinação de Plonkish, Plonk IOP e KZG.
Para entender por que usamos essas três soluções. Começamos primeiro com o R1CS mais simples. A restrição em R1CS é que a combinação linear vezes a combinação linear seja igual à combinação linear. Você pode adicionar qualquer combinação linear de variáveis sem sobrecarga adicional, mas a ordem máxima em cada restrição é 2. Portanto, para operações de ordem superior, são necessárias mais restrições.
No Plonkish, você precisa preencher todas as variáveis da tabela, incluindo entradas, saídas e testemunhas para variáveis intermediárias. Além disso, você pode definir diferentes restrições. Existem três tipos de restrições disponíveis no Plonkish.
O primeiro tipo de restrição é uma porta personalizada. Você pode definir relacionamentos de restrição polinomial entre diferentes células, como va3 * vb3 * vc3 - vb4 =0. Comparado com R1CS, a ordem pode ser maior porque você pode definir restrições em qualquer variável e pode definir algumas restrições muito diferentes.
O segundo tipo de restrição é a permuação ou verificações de igualdade. Pode ser usado para verificar a equivalência de diferentes células e é frequentemente usado para associar diferentes portas em um circuito, como provar que a saída da porta anterior é igual à entrada da próxima porta.
O último tipo de restrição é uma tabela de pesquisa. Podemos entender a tabela de consulta como uma relação entre variáveis, que pode ser expressa como uma tabela. Por exemplo, queremos provar que vc7 está no intervalo de 0 a 15. Em R1CS, primeiro você precisa decompor esse valor em um binário de 4 bits e, em seguida, provar que cada bit está no intervalo de 0 a 1. exigirá quatro restrições. No Plonkish, você pode listar todos os intervalos possíveis na mesma coluna e só precisa provar que vc7 pertence a essa coluna. Isso é muito eficiente para provas de intervalo. No zkEVM, as tabelas de pesquisa são muito úteis para provar leituras e gravações de memória.
Para resumir, o Plonkish também oferece suporte a portas personalizadas, verificações de equivalência e tabelas de consulta, que podem ser muito flexíveis para atender a diferentes necessidades de circuitos. Uma comparação simples de STARK Cada linha em STARK é uma restrição. A restrição precisa representar a transição de estado entre as linhas, mas a flexibilidade das restrições personalizadas em Plonkish é obviamente maior.
A questão agora é como escolhemos o front end no zkEVM. Existem quatro desafios principais para o zkEVM. O primeiro desafio é que o campo do EVM é de 256 bits, o que significa que as variáveis precisam ser restritas de forma eficiente. O segundo desafio é que o EVM tem muitos opcodes hostis ao ZK, portanto, são necessárias restrições de grande escala para provar essas operações; .código, como Keccak-256; o terceiro desafio é o problema de leitura e gravação de memória, você precisa de algum mapeamento eficaz para provar que o que você lê é consistente com o que você escreveu antes; está mudando dinamicamente, então precisamos de portas personalizadas para nos adaptarmos a diferentes rastreamentos de execução. Escolhemos Plonkish pelas considerações acima.
A seguir, vamos dar uma olhada no processo completo do zkEVM. Com base na árvore de estado global inicial, após a entrada de uma nova transação, o EVM lerá o bytecode dos contratos armazenados e chamados e gerará os rastreamentos de execução correspondentes com base na transação, como. PUSH, PUSH, STORE, CALLVALUE e, em seguida, atualize gradualmente o estado global para obter a árvore de estado global após a transação. zkEVM pega a árvore de estado global inicial, a própria transação e a árvore de estado global após a transação como entrada e usa a especificação EVM para provar a exatidão do rastreamento de execução.
Aprofundando-se nos detalhes do circuito EVM, cada etapa do rastreamento de execução possui restrições de circuito correspondentes. Especificamente, as restrições de circuito de cada etapa incluem Step Context, Case Switch e Opcode Specific Witness. Step Context contém o codehash, gás restante e contador correspondente ao rastreamento de execução; Case Switch contém todos os opcodes, todas as condições de erro e as operações correspondentes da etapa Opcode Specific Witness contém testemunhas adicionais exigidas pelo opcode, como operandos wait;
Tomando a adição simples como exemplo, você precisa garantir que a variável de controle sADD do opcode de adição esteja definida como 1 e que as variáveis de controle de outros opcodes sejam todas zero. No Contexto Step, o gás consumido é restringido para ser igual a 3 definindo gas' - gas - 3 = 0. Da mesma forma, o contador é restringido O ponteiro da pilha acumula 1 após o passo no Case Switch; as variáveis são controladas para 1 por meio do opcode. Para restringir esta etapa a ser uma operação de adição no Opcode Specific Witness, restrinja a adição real de operandos.
Além disso, restrições de circuito adicionais são necessárias para garantir a exatidão dos operandos lidos da memória. Aqui, primeiro precisamos construir uma tabela de consulta para provar que o operando pertence à memória. E verifique a exatidão da tabela de memória através do circuito de memória (Circuito RAM).
O mesmo método pode ser aplicado a funções hash hostis a zk. Construa uma tabela de pesquisa da função hash, mapeie a entrada e a saída do hash no rastreamento de execução para a tabela de pesquisa e use um circuito hash adicional para verificar a função hash. a exatidão da tabela de pesquisa.
Agora vamos dar uma olhada na arquitetura do circuito do zkEVM. O circuito EVM principal é usado para restringir a exatidão de cada etapa do rastreamento de execução. Em alguns lugares onde as restrições do circuito EVM são difíceis, usamos tabelas de pesquisa para mapear, incluindo Tabela Fixa, Keccak. Tabela, Tabela RAM, Bytecode, Transação, Contexto de Bloco e, em seguida, use circuitos separados para restringir essas tabelas de pesquisa, como circuitos Keccak para restringir tabelas Keccak.
Para resumir, o fluxo de trabalho completo do zkEVM é mostrado na figura abaixo.
sistema de prova
Como a verificação direta dos circuitos EVM, circuitos de memória, circuitos de armazenamento, etc. mencionados acima em L1 é cara, o sistema de prova da Scroll adota uma arquitetura de duas camadas.
A primeira camada é responsável por provar diretamente o próprio EVM, exigindo uma grande quantidade de computação para gerar a prova. Portanto, o sistema de prova de primeiro nível é necessário para suportar portas personalizadas e tabelas de pesquisa, ser amigável à aceleração de hardware, gerar cálculos em paralelo sob memória de baixo pico e ter um pequeno circuito de verificação que possa ser verificado rapidamente. Alternativas promissoras incluem Plonky2, Starky e eSTARK. Todos eles basicamente usam Plonk no front-end, mas podem usar FRI no back-end, e todos atendem às quatro características acima. Outro tipo de soluções alternativas inclui o Halo2 desenvolvido pela Zcash e a versão KZG do Halo2.
Existem também alguns novos sistemas de prova que são promissores, como o HyperPlonk, que removeu recentemente a FFT, e o sistema de prova NOVA pode obter provas recursivas menores. Mas eles só apoiam o R1CS na pesquisa. Se puderem apoiar o Plonkish no futuro e aplicá-lo na prática, será muito prático e eficiente.
O sistema de prova de segundo nível é usado para provar a exatidão da prova de primeiro nível e precisa ser verificado de forma eficiente no EVM. Idealmente, deve ser compatível com aceleração de hardware e suportar configuração transparente ou universal. Alternativas promissoras incluem Groth16 e o sistema de prova Plonkish sem colunas. Groth16 ainda é um representante de eficiência de prova extremamente alta nas pesquisas atuais, e o sistema de prova Plonkish também pode alcançar alta eficiência de prova mesmo com um pequeno número de colunas.
Na Scroll, usamos o sistema de prova Halo2-KZG em ambos os nossos sistemas de prova de duas camadas. Como o Halo2-KZG pode suportar portas personalizadas e tabelas de pesquisa, ele funciona bem sob aceleração de hardware de GPU e o circuito de verificação é pequeno e pode ser verificado rapidamente. A diferença é que usamos hashing Poseidon no sistema de prova de primeira camada para melhorar ainda mais a eficiência da prova, enquanto o sistema de prova de segunda camada ainda usa hashing Keccak porque é verificado diretamente no Ethereum. Scroll também está explorando a possibilidade de um sistema de prova em múltiplas camadas para agregar ainda mais as provas agregadas geradas pelo sistema de prova de segundo nível.
Na implementação atual, o circuito EVM do sistema de prova de primeiro nível da Scroll tem 116 colunas, 2.496 portas personalizadas, 50 tabelas de pesquisa, a ordem mais alta é 9 e requer 2 ^ 18 linhas sob 1M de gás, enquanto o sistema de prova de segundo nível tem O; o circuito de agregação tem apenas 23 colunas, 1 porta personalizada, 7 tabelas de pesquisa e a ordem mais alta é 5. Para agregar o circuito EVM, o circuito de memória e o circuito de armazenamento, são necessárias 2 ^ 25 linhas.
Scroll também fez muitos trabalhos de pesquisa e otimização na aceleração de hardware de GPU. Para circuitos EVM, o provador de GPU otimizado leva apenas 30 segundos, o que é 9 vezes mais eficiente do que o provador de CPU. leva 149s, o que é 15 vezes mais eficiente que a CPU. Nas atuais condições de otimização, o sistema de prova de primeiro nível 1M Gas leva cerca de 2 minutos e o sistema de prova de segundo nível leva cerca de 3 minutos.
Na terceira parte, Zhang Ye falou sobre algumas questões interessantes de pesquisa no processo de construção do zkEVM pela Scroll, desde o circuito aritmético front-end até a implementação do provador.
o circuito
A primeira é a aleatoriedade no circuito. Como o campo EVM tem 256 bits, precisamos dividi-lo em 32 campos de 8 bits para realizar a prova de intervalo com mais eficiência. Em seguida, usamos o método Random Linear Combination (RLC) para codificar 32 campos em 1 usando números aleatórios. Só precisamos verificar este campo para verificar o campo original de 256 bits. Mas o problema é que o número aleatório precisa ser gerado após a divisão dos campos para garantir que não seja adulterado. Portanto, Scroll e a equipe PSE propuseram uma solução de provador de vários estágios para garantir que, após a divisão do campo, números aleatórios sejam usados para gerar RLC. Esta solução é encapsulada na API Challenge. RLC tem muitos cenários de aplicação no zkEVM. Ele pode não apenas compactar o campo EVM em um campo, mas também criptografar entradas de comprimento variável ou otimizar o layout da tabela de pesquisa.
Uma segunda questão interessante de pesquisa em circuitos é o layout dos circuitos. A razão pela qual o front-end Scroll usa Plonkish é porque o rastreamento de execução do EVM muda dinamicamente e precisa ser capaz de suportar diferentes restrições e testes de equivalência variáveis, e a porta padronizada do R1CS requer uma escala de circuito maior para ser implementada. No entanto, Scroll atualmente usa mais de 2.000 portas personalizadas para atender aos rastreamentos de execução que mudam dinamicamente e também está explorando como otimizar ainda mais o layout do circuito, incluindo a divisão do Opcode em Micro Opcode ou a reutilização de células na mesma tabela.
Uma terceira questão de pesquisa interessante em circuitos é o escalonamento dinâmico. Como a escala do circuito de diferentes opcodes é diferente, mas para atender ao rastreamento de execução que muda dinamicamente, o opcode de cada etapa precisa atender à escala máxima do circuito, como o hashing Keccak, então, na verdade, pagamos sobrecarga extra. Supondo que possamos fazer com que o zkEVM se adapte dinamicamente aos rastreamentos de execução que mudam dinamicamente, isso economizará sobrecarga desnecessária.
provador
Em termos de provadores, Scroll fez muitas otimizações para MSM e NTT em termos de aceleração de GPU, mas agora o gargalo mudou para geração de testemunhas e cópia de dados. Como se presume que MSM e NTT ocupam 80% do tempo de prova, mesmo que a aceleração de hardware possa melhorar essa eficiência em várias ordens de grandeza, o tempo de prova original de 20% para geração e cópia de dados se tornará um novo gargalo. Outro problema com o provador é que ele requer muita memória, portanto soluções de hardware mais baratas e descentralizadas precisam ser exploradas.
Ao mesmo tempo, Scroll também está explorando aceleração de hardware e algoritmos de prova para melhorar a eficiência dos provadores. Atualmente, existem duas direções principais: mudar para um domínio menor, como usar o domínio Cachinhos Dourados de 64 bits, Mersenne Prime de 32 bits, etc., ou aderir a um novo sistema de prova baseado em curvas elípticas (EC). . Claro, existem outros caminhos possíveis, e amigos com ideias podem entrar em contato diretamente com Scroll.
segurança
Ao construir o zkEVM, a segurança é fundamental. O zkEVM construído em conjunto pela PSE e Scroll tem aproximadamente 34.000 linhas de código. Do ponto de vista da engenharia de software, é impossível que essas bases de código complexas fiquem livres de vulnerabilidades por muito tempo. A Scroll está atualmente revisando a base de código zkEVM por meio de um grande número de auditorias, inclusive das principais empresas de auditoria do setor.
A Parte 4 explora outros aplicativos que usam zkEVM.
Na arquitetura zkRollup, verificamos que n transações em L2 são válidas através do contrato inteligente em L1.
Se verificarmos diretamente o bloco L1, o nó L1 não precisará executar a transação repetidamente, mas apenas verificar a validade de cada certificado de bloco. Essa solução arquitetônica é chamada Enshrine Blockchain. Atualmente, é muito difícil implementar diretamente no Ethereum porque todo o bloco Ethereum precisa ser verificado, o que incluirá a verificação de um grande número de assinaturas, resultando em maior tempo de verificação e menor segurança. Claro, já existem algumas outras cadeias públicas que usam provas recursivas para verificar todo o blockchain usando uma única prova, como a Mina.
Como o zkEVM pode provar transições de estado, ele também pode ser usado por chapéus brancos para provar que conhecem as vulnerabilidades de certos contratos inteligentes e buscam recompensas das partes do projeto.
O último caso de uso é provar afirmações sobre dados históricos por meio de prova de conhecimento zero e usá-los como um oráculo que a Axiom está atualmente fabricando produtos nesta área. No recente Hackathon da ETHBeijing, a equipe GasLockR aproveitou esse recurso para provar a sobrecarga histórica do Gas.
Finalmente, a Scroll está construindo a solução de escalonamento universal do zkRollup para Ethereum, usando circuitos aritméticos e sistemas de prova muito avançados, e construindo verificadores rápidos por meio de aceleração de hardware para provar a recursão. Atualmente, a rede de teste Alpha está online e funciona de forma estável há muito tempo.
Claro, ainda existem alguns problemas interessantes que precisam ser resolvidos, incluindo design de protocolo e mecanismo, engenharia de conhecimento zero e eficiência real. Todos são bem-vindos para se juntarem ao Scroll para construir juntos!
