2023 é o primeiro ano do surto de ZK e já existem algumas opiniões. Neste artigo, nos concentraremos na discussão dos diferentes tipos de trilha de hardware zkEVM e ZKP, etc., e os analisaremos um por um. Na reunião de pesquisa de investimento sobre o tema ZK iniciada pela ChainTimes na semana passada, todos se comunicaram ativamente. Este artigo irá resolver a análise sobre zkEVM e hardware compartilhado pela MetaStone Capital.

01.Sobre zk-rollup

Como uma solução de escalabilidade Ethereum, Rollups pode agrupar e compactar transações através de sua própria rede e enviá-las para a cadeia Ethereum para verificação. Ele pode aumentar a eficiência operacional da rede, verificando múltiplas transações na rede ao mesmo tempo, e também Isto é. para aumentar o número de execuções de transações e alcançar a expansão.

Através do número de transações executadas ao mesmo tempo pelo próprio Rollups, o problema de TPS pelo qual o Ethereum foi criticado pode ser melhorado. Com base na segurança do próprio Ethereum, o número de transações executáveis ​​pode ser aumentado em várias ordens de magnitude.

zkRollups pode combinar privacidade com soluções por meio de tecnologia de prova de conhecimento zero, que permite que uma parte prove algo a outra parte sem revelar as informações que comprovam essa parte, alcançando assim a privacidade. É claro que nem todos os zkRollups aproveitarão as vantagens das propriedades de privacidade da tecnologia de conhecimento zero. Ao mesmo tempo, em comparação com L1, zkRollups tem economias de escala mais fortes. Quanto ao L1 Ethereum, seu custo e velocidade de processamento geralmente não são adequados para mais e mais usuários. Mais usuários de transação reduzirão ainda mais o custo. de usar a rede e atingir o propósito original.

Os benefícios óbvios da aplicação do zk-rollup na ETH são:

1. Compartilhando a segurança da camada de consenso Ethereum

2. Resolva o problema de escalabilidade no triângulo impossível do blockchain

3. Enormes efeitos de rede

02. Como funcionam o EVM e o zkEVM

a. Princípio de funcionamento do EVM

O bytecode do contrato inteligente é carregado do armazenamento do EVM e executado por nós ponto a ponto no EVM.

Os opcodes EVM interagem com diferentes partes do estado EVM e realizam operações de leitura e gravação (incluindo memória e pilha)

O opcode EVM realiza cálculos no valor obtido no armazenamento de estado antes de retornar o novo valor para completar a transição de estado.

b.Como funciona o zkEVM

Ou seja, é gerada uma prova de conhecimento zero para verificar cada um dos processos acima, um certificado de validade é gerado e enviado ao contrato do verificador ETH para verificação. A verificação inclui verificar se o valor correto é obtido do estado antigo, se há desvio no cálculo, etc. O processo de geração de uma prova de validade é também o processo de criação de um circuito de prova de conhecimento zero.

3. programa de execução zkEVM

01. As condições básicas do zkEVM requerem uma máquina virtual compatível com evm para executar opcodes e executar contratos inteligentes.

02. Existe um circuito de verificação que gera provas de conhecimento zero. Conclua o processo de geração de prova usando informações de pré-estado, entrada de transação e pós-estado como entrada

4. Problemas de compatibilidade entre Scroll e zkSync, Starknet e Polygon

Como o EVM não considerou a questão do cálculo do zkp quando foi originalmente projetado, há duas maneiras de combinar zk+zvm:

a. Método de compilação

O próprio Starknet usa a linguagem Cairo (linguagem de sistema à prova de conhecimento zero). Se os desenvolvedores quiserem mover aplicativos eth para starknet, eles precisarão pegar emprestado o compilador da equipe starknet para compilação, permitindo que projetos escritos em Solidity "um clique" em sua base de código. ”Traduz-se para o Cairo.

zksync também é compilado na linguagem. Por meio da linguagem intermediária YUL, usando a estrutura LLVM, o bytecode do contrato de solidez é compilado na linguagem YUL e, em seguida, compilado no bytecode executável zksync ZKEVM definido por meio do bytecode YUL.

Polygon é compilado em bytecode, e o bytecode de solidez de código aberto é compilado em código de microoperação executável polygon uvm, que na verdade substitui o código de operação nativo evm. Mas o objetivo do progresso é completar a compatibilidade do evm no nível do bytecode.

b.scroll é o processo de projetar circuitos de conhecimento zero para opcodes evm

Scroll irá executar o contrato inteligente no EVM, transferir o bytecode do contrato inteligente para a memória, executá-lo um por um com os opcodes, obter a árvore Merkle e customizar um circuito para cada árvore. Cada opcode possui um circuito e quando combinados, não há etapa de tradução e não há necessidade de modificar nada.

O zkEVM em nível de bytecode é amigável ao desenvolvedor: a implantação de baixo limite é um ponto. Além disso, sem converter o código Solidity em outra linguagem de codificação, os desenvolvedores podem usar diretamente ferramentas de desenvolvimento, bibliotecas, carteiras (como MetaMask) comuns do Ethereum, Market e. depurador, este é o mais crítico. Pelo contrário, o uso da compatibilidade de nível de linguagem causará certas dificuldades para os desenvolvedores usarem ferramentas eth e migrarem aplicações ecológicas Ethereum, e a compatibilidade será pior.

Compatibilidade à parte, como comparar o ZK-EVM:

Em um ambiente de código aberto, as diferenças entre as várias soluções ZK do sistema Prove geral são muito pequenas e as diferenças não são significativas, o que afeta fracamente a eficiência do Prove. Em termos de engenharia, é medido em termos de complexidade de prova, complexidade de verificação, complexidade de comunicação, etc., bem como das ideias gerais de desenvolvimento do circuito. É impossível julgar quem vencerá no final. Porque os efeitos de rede, a cultura comunitária, a promoção operacional, os efeitos de riqueza, o apoio ao desenvolvedor, etc. são todos os elementos mais importantes do ecossistema.

5. Tipos atuais de ZKP

Para provar um cálculo através do ZK, normalmente você precisa traduzir um programa tradicional em um programa compatível com ZK.

Quanto mais complexo for o cálculo e não for amigável para ZK, mais lento será o processo de geração de prova. Algumas operações não são amigáveis ​​para ZK (operação sha/bit a bit). Se o cálculo for amigável para ZK, mais rápido será. será. O sistema de prova Atualmente existem PLONK, Spartan e STARK. Esses sistemas de prova podem gerar uma prova com base na entrada.

No entanto, o gargalo atual na geração de provas nada mais é do que um dos dois. Todos os sistemas de provas incluem basicamente dois algoritmos: FFT e MSMs. O principal fator que limita a velocidade dos dois algoritmos atualmente depende do custo de hardware e dos custos de largura de banda.

Os tipos de hardware atuais incluem principalmente os seguintes três tipos de GPU FPGA ASIC. Atualmente, o ZKP ainda está em estágio inicial de desenvolvimento. Ainda há pouco trabalho de padronização nos parâmetros do sistema (como largura da FFT ou tamanho de bit do elemento). sistema de prova também não existe um padrão relevante.

Com base nos fatores acima, para cenários ZKP, o FPGA possui 2 atributos principais que o tornam melhor que o ASIC:

01Escrever várias vezes” VS “Escrever uma vez”

A lógica de negócios no ASIC é de gravação única. Se houver alguma modificação na lógica do ZKP, será necessário recomeçar. O FPGA pode re-flash em 1 segundo e suporta re-flash inúmeras vezes, o que significa que o mesmo hardware pode ser reutilizado entre diferentes cadeias executando sistemas de prova incompatíveis (por exemplo, se você deseja extrair MEV entre cadeias) e o mesmo hardware pode ser reutilizado a qualquer momento. Adapte-se com flexibilidade às mudanças no "meta" do ZK.

02 Fornecimento mais saudável:

O projeto, a fabricação e a implantação do ASIC normalmente levam de 12 a 18 meses ou mais. A cadeia de fornecimento de FPGA é saudável. Os principais fornecedores de FPGA, como a Xilinx, permitem que pedidos em grandes quantidades sejam feitos on-line (ou seja, nenhum outro contato é necessário) e cheguem em 16 semanas. Isso permite que as operações centradas em FPGA tenham um ciclo de feedback mais restrito sobre seus produtos e expandam suas operações comprando e implantando mais FPGAs.

E também esperamos que o desempenho do FPGA seja melhor que o da GPU, principalmente por dois motivos:

1) Sobrecarga de hardware: Os principais FPGAs (principais nós de processamento, velocidades de clock, eficiência energética e largura de banda de memória) são cerca de 3 vezes mais baratos que as principais GPUs. A demanda global por GPUs agrava ainda mais o problema.

2) Eficiência no consumo de energia: O consumo de energia do FPGA é> 10 vezes maior que o da GPU. O principal motivo é que a GPU precisa estar conectada a um dispositivo host, que geralmente consome muita energia.

Acreditamos que os futuros vencedores do mercado serão: FPGA > ASIC (ou GPU). Se apenas uma ou um pequeno número de soluções ZK L1 ou L2 dominarem a escala no futuro, e o sistema à prova de ZK se estabilizar em torno de uma única implementação, então o ASIC poderá exceder o FPGA. Mas actualmente, esta situação não acontecerá dentro de alguns anos.

Os mineradores de Bitcoin ganharam mais de US$ 15 bilhões e os mineradores de Ethereum ganharam pouco mais de US$ 17 bilhões. As provas de conhecimento zero acabarão por se tornar o meio de facto para integridade computacional e privacidade na web, caso em que a oportunidade para mineradores/provadores ZK pode ser semelhante em tamanho ao mercado de mineração de prova de trabalho.

O ZKP é mais lento e requer aceleração de hardware para implementar cálculos complexos. Acreditamos que a tecnologia mais importante para aceleração de hardware ZK é FPGA, não GPU (limitada por custo e eficiência energética) ou ASIC (limitada por sua inflexibilidade e longo ciclo de iteração).