- Tópico
19k Popularidade
18k Popularidade
61k Popularidade
31k Popularidade
3k Popularidade
113k Popularidade
28k Popularidade
27k Popularidade
7k Popularidade
18k Popularidade
- Pino
19k Popularidade
18k Popularidade
61k Popularidade
31k Popularidade
3k Popularidade
113k Popularidade
28k Popularidade
27k Popularidade
7k Popularidade
18k Popularidade
Explicação detalhada do validador de bloco Ethereum Zeth: o primeiro zkEVM Tipo 0
Título original: Anunciando Zeth: o primeiro Type Zero zkEVM
Elenco: Tim Cartens, Victor Graf, Rami Khalil, Steven Li, Parker Thompson, Wolfgang Welz, Zeth Collaboration
Compilação: bayemon.eth, ChainCatcher
Em 25 de agosto, Zeth, o validador de bloco ZK de código aberto Ethereum baseado em RISC Zero zkVM, foi lançado publicamente. Zeth faz todo o trabalho necessário para construir novos blocos no zkVM sem depender de validadores ou comitês de sincronização. Zeth foi verificado em vários blocos reais da rede principal Ethereum e passou em todos os testes relevantes do conjunto de testes oficial Ethereum. Zeth foi capaz de implementar suporte Rust baseado em zkVM e placas fortes, incluindo revm, éteres e ligas, em 4 semanas. Com o suporte do zkVM para continuidade e serviços de prova de Bonsai, Zeth pode gerar essas provas em minutos. Com o suporte da Zeth para verificação on-chain, qualquer pessoa pode verificar essas provas on-chain a baixo custo. Neste post entraremos em mais detalhes, mas se você quiser se aprofundar no código, confira o código-fonte e visite o portal do desenvolvedor RISC Zero.
Resumo
Há cerca de um ano, Vitalik elaborou sobre os diferentes tipos de zkEVM:
Embora tenha havido casos na história do Ethereum em que isso foi possível, hoje temos o prazer de anunciar que as provas de bloqueio do Ethereum usando os serviços zkVM e Bonsai do RISC Zero levam minutos, não horas.
Zeth: Geração de bloco Ethereum verificável
Hoje lançamos Zeth, um validador de bloco ZK de código aberto para Ethereum no RISC Zero zkVM.
Zeth pode provar que um determinado bloco Ethereum é válido sem depender de validadores ou comitês de sincronização. Isso ocorre porque Zeth faz todo o trabalho necessário para gerar novos blocos no zkVM, incluindo:
Depois que um novo bloco é gerado, Zeth calcula e gera seu hash. Ao executar este processo no zkVM, podemos obter provas ZK de que novos blocos são válidos.
Aproveitando o zkVM do RISC Zero e as populares caixas Rust, como revm, ether e Alloy, escrevemos a primeira versão do Zeth em menos de 4 semanas. Com o suporte do zkVM para continuidade e o serviço de provas Bonsai, a geração de provas pode ser feita em poucos minutos. Com suporte para verificação on-chain, podemos verificar essas provas on-chain a baixo custo.
Zeth foi verificado em vários blocos reais da rede principal Ethereum e passou em todos os testes relevantes do conjunto de testes oficial Ethereum.
Como Zeth constrói blocos Ethereum padrão, ele pode ser considerado um zkEVM tipo 1. Mas é muito mais do que isso: como Zeth é construído usando codeboards Rust padrão (os mesmos codeboards usados por nós completos populares como Reth), preferimos pensar nele como um zkEVM classe 0: compatibilidade total de protocolo e muita reutilização de código . **
Este marco representa um grande avanço para a tecnologia ZK e para o ecossistema Ethereum. Neste post, discutimos como escrever a primeira versão do Zeth em algumas semanas, seu desempenho, como funciona e o que isso significa para o projeto ZK.
RISC Zero facilita a construção de zk rollups, zkEVMs, light clients e bridges
Escrevemos Zeth por dois motivos:
rollup zk e zkEVM
Como um zkEVM Tipo 0, Zeth permite que os desenvolvedores criem rollups zk com compatibilidade EVM e Ethereum totalmente nativa. Juntamente com o suporte da Zeth para verificação de prova em cadeia, construir uma solução de expansão L2 orientada por ZK se tornará extremamente simples.
Os rollups ZK e os circuitos zkEVM existentes são monolíticos por design e não podem ser atualizados sem que um desenvolvedor tenha um conhecimento de alto nível da criptografia ZK. Em contraste, a abordagem Zeth baseada em zkVM permite que qualquer desenvolvedor a personalize e modifique de acordo com suas necessidades.
Zeth é de código aberto baseado em revm, e ajustes para suportar outras cadeias compatíveis com zkEVM e EVM é uma tarefa relativamente fácil. Portanto, Zeth terá uma resposta relativamente mais rápida a futuras atualizações de EIP. Além disso, Zeth também oferece modularidade, permitindo que os desenvolvedores construam sua própria lógica de construção de blocos nele.
Esperamos que os esforços de Zeth democratizem o zk rollup e os zkEVMs, sabendo que as soluções L2 orientadas pelo zk anteriormente exigiam anos de pesquisa e desenvolvimento e mais de 100 milhões de dólares americanos em financiamento, um consumo que a maioria dos projetos não pode pagar.
Cliente leve e ponte
Não há dúvida de que a introdução da cadeia de beacon é uma bênção para clientes leves e pontes. Essas técnicas baseiam-se no modelo PoS agora maduro da Ethereum, permitindo que clientes leves e pontes verifiquem facilmente blocos recentes sem reconstruí-los, desde que todos cumpram as regras.
É claro que o objetivo do staking é fornecer incentivos econômicos para que os nós sigam as regras. No entanto, a ameaça que o Slashing impõe aos nós não pode evitar completamente o mal - os incentivos externos sempre inclinarão o "equilíbrio" dos interesses para o mal - e é muito importante projetar um cliente leve ou uma ponte que possa lidar adequadamente com esses comportamentos maliciosos. duro.
Com ferramentas como Zeth, o risco de os nós fazerem o mal é bastante reduzido. Os clientes Light podem se integrar ao Zeth simplesmente adicionando algumas chamadas ao zkVM; aplicativos on-chain, como pontes, podem se integrar ao Zeth usando nosso contrato de verificação de prova de prova on-chain.
Num futuro próximo, podemos imaginar clientes leves e pontes usando provas ZK para determinar se um determinado bloco é válido. Esta abordagem reduziria enormemente o risco sem aumentar significativamente o custo de validação de blocos.
Isto é especialmente importante para cadeias de aplicativos, ecossistemas modulares e novas cadeias que ainda não têm o mesmo nível de segurança que a grande comunidade de nós completos da Ethereum oferece.
Uma boa base simplifica o processo de desenvolvimento do projeto
Baseado no RISC Zero zkVM e desenvolvido na arquitetura de conjunto de instruções RISC-V, Zeth pode fornecer aos desenvolvedores uma experiência de programação familiar. Mas nosso zkVM é mais do que apenas um núcleo RISC-V. Também temos circuitos de aceleração para tarefas criptográficas comuns, como hashing e verificação de assinatura.
Esta abordagem híbrida (combinação de núcleos de CPU de uso geral com circuitos de aceleração) nos dá o melhor dos dois mundos:
Como resultado, fomos capazes de construir Zeth rapidamente usando pacotes de código Rust existentes de revm, ether e Alloy. Ao reutilizar placas existentes, concluímos a primeira versão do Zeth em menos de 4 semanas. Este tipo de velocidade não é possível em ecossistemas menos maduros.
Em termos de desempenho, Zeth aproveita nossos circuitos aceleradores para verificação de assinatura ECDSA, bem como Continuidade - um novo recurso de nossa estrutura ZK que facilita o uso de clusters de GPUs trabalhando em paralelo (usando nVidia CUDA ou Apple Metal) para provar rapidamente grandes cálculos. As continuações são fáceis de usar: esta funcionalidade é fornecida de forma transparente para todos os programas convidados em execução no zkVM, ou seja, nenhuma modificação de código é necessária para que funcione corretamente.
Com nosso zkVM, podemos gerar rapidamente provas ZK de validade do bloco Ethereum em minutos, não em horas.
Desempenho
Abordaremos o desempenho do gerador de blocos Zeth. Zeth ainda é um produto novo, portanto esses números estão sujeitos a alterações; no entanto, queríamos fornecer alguns números concretos para servir de base para trabalhos futuros.
Quando se trata de desempenho, há vários fatores a serem considerados:
Continuidade
O zkVM da Zeth pode ser ajustado para desempenho usando execução contínua. Portanto, precisamos fazer uma pausa e discutir como funciona a “operação contínua”.
Nosso zkVM implementa processadores RISC-V padrão. Portanto, a execução é medida em ciclos. (Em nosso circuito, a maioria das instruções RISC-V são executadas em 1 ciclo, embora haja exceções). Programas simples normalmente requerem apenas algumas centenas de milhares de ciclos para serem executados, mas programas mais complexos podem exigir bilhões de ciclos.
Em um sistema ZK típico, esses ciclos de execução são agrupados em uma prova; à medida que o número de ciclos aumenta, aumenta também o tempo e a memória necessários para gerar a prova. Mas nosso zkVM não segue esses estereótipos e, no início deste ano, fomos pioneiros em um novo recurso de continuidade que melhora as desvantagens da geração tradicional de esquemas de prova.
Em termos de continuidade, o processo de prova é dividido em três fases:
Realizamos os cálculos necessários em um simulador não-prova. Ao longo do caminho, contamos o número de vezes que o loop foi executado até agora. Em intervalos configuráveis, tiramos instantâneos do estado do programa. Isso efetivamente divide a execução em várias partes. Cada segmento é pequeno, normalmente representando 1 milhão de ciclos ou menos.
Essas peças são atribuídas a um conjunto de trabalhadores de geração de provas. Eles geram provas ZK para determinados segmentos do programa. É importante ressaltar que eles podem fazer isso em paralelo. Desde que haja trabalhadores suficientes, todos os segmentos do programa podem ser provados no tempo necessário para provar um segmento do programa. Devido ao pequeno tamanho do segmento de rede, o tempo necessário geralmente é curto (dezenas de segundos).
Quando as provas de segmentos são geradas, elas eventualmente serão acumuladas. Cada operação de “rollup” pega um par de provas segmentadas consecutivas e produz uma nova prova para a combinação desses segmentos. Por exemplo, se o segmento 1 provar que o programa fez a transição do estado A para o estado B, e o segmento 2 provar que o programa fez a transição do estado B para o estado C, então o rollup prova que o programa fez a transição do estado A para o estado C. Com trabalhadores suficientes, isso pode ser feito em tempo log(N), onde N é o número de fragmentos.
Veremos esses estágios em ação quando nos aprofundarmos nos números.
**Quão difícil é construir um bloco Ethereum? **
Primeiro, vejamos a complexidade de construir um bloco Ethereum. Na tabela abaixo, pegamos alguns blocos Ethereum do mundo real e os reconstruímos usando Zeth no zkVM.
Por exemplo, o bloco 17606771 produz 2.131 extensões. Cada segmento representa no máximo 2^20 ciclos de execução, portanto, todo o cálculo leva no máximo 2.234.515.456 ciclos de execução.
Em geral, vemos um bloco Ethereum típico levando de 2 a 400 milhões de ciclos para ser construído, mas às vezes até 9,5 bilhões de ciclos. (No início, ficamos surpresos ao ver que essas diferenças não se refletiam no gás da transação. Mas depois de pensar mais sobre isso, fazia sentido: o sistema de gás foi projetado tendo em mente a execução regular, e não as provas ZK).
Com continuidade, essa escala é fácil de gerenciar. De acordo com esses números, uma rede peer-to-peer de 10.000 nós executando validadores zkVM é suficiente para alcançar o mais alto desempenho de validação paralela para os blocos maiores, o que é uma fração dos 700.000 validadores que o Ethereum possui atualmente.
**Quanto tempo leva para gerar uma prova? **
Para coletar alguns dados básicos de desempenho, lançamos uma instância de teste Bonsai com 64 GPU Workers. Em seguida, pedimos que ele atesta o bloco 17735424 (182 transações, 3.242 segmentos ou cerca de 3,4 bilhões de ciclos) usando Zeth.
Para gerar provas, o zkVM deve primeiro dividir a execução em segmentos. Na captura de tela abaixo, esse processo foi capturado pela tarefa do utor, que durou 10 minutos. (A maior parte do tempo é fazer coisas da AWS, como gravar no armazenamento de rede). Na máquina local, a mesma tarefa leva menos de 6 minutos para ser concluída. Esperamos reduzir este tempo significativamente no próximo ano).
O executor finalmente divide a execução em 3.242 partes. É muita fragmentação para apenas 64 GPUs. Portanto, cada nó trabalhador deve gerar 50 provas de segmentos. Conforme mostrado na figura abaixo, isso leva 35 minutos. Se tivermos 50 vezes mais nós de trabalho, levará apenas 42 segundos.
Depois que a prova do segmento for concluída, o rollup será iniciado. Como existem 3.242 segmentos, precisamos realizar um processo de rollup de log_2(3242) = 12 rodadas. Nos estágios iniciais do rollup, há mais trabalhadores do que trabalhadores; portanto, o primeiro estágio leva 1 minuto, o segundo estágio leva 35 segundos, o terceiro estágio leva 25 segundos e assim por diante. No estágio sete, o tempo estabilizou em pouco mais de 5 segundos. Da mesma forma, se tivéssemos mais trabalhadores, cada etapa levaria apenas 5 segundos.
Após a conclusão do rollup, os resultados são finalizados, o que leva mais um minuto.
Como resultado, conseguimos gerar provas em cerca de 50 minutos (velocidade efetiva de 1,1 MHz) com tamanho de cluster insuficiente. Se o cluster estiver dimensionado corretamente, estimamos que a geração de provas será mais rápida:
No caso totalmente paralelizado, a etapa de prova pode ser concluída em 42 + 12 * 5 + 60 segundos ou 2 minutos e 42 segundos.
Se arredondarmos de forma conservadora e incluirmos o tempo do executor, o tempo ficará entre 9 e 12 minutos (velocidade efetiva 4,7 MHz - 6,3 MHz).
À medida que continuamos a melhorar nossos executores e nossa estrutura de provas, estamos otimistas de que esse tempo será reduzido significativamente no próximo ano.
Consumo de recursos para geração de provas
O cluster de teste acima foi implantado na AWS. Consiste em 64 nós de prova g5.xlarge e 1 nó de execução m5zn.xlarge. De acordo com a Amazon, cada nó g5.xlarge possui
No momento em que este artigo foi escrito, o preço sob demanda para essas instâncias era de US$ 1,006/hora, e as instâncias reservadas eram de US$ 0,402/hora. Enquanto isso, a folha de especificações da Amazon mostra que nosso nó m5zn.xlarge possui
No momento em que este livro foi escrito, o preço sob demanda para esta instância era de US$ 0,3303/hora.
Podemos usar esses números para estimar aproximadamente o custo da prova para o bloco 17735424 descrito acima.
Lembre-se de que implantamos 64 nós de prova e nesta implantação demoramos 50 minutos (ponta a ponta) para gerar uma prova. Ignorando o tempo de trabalho ocioso, 64 nós de prova mais um nó de execução custam 50/60 * (64 * 0,402 + 0,3303) = US$ 21,72 por 50 minutos. Esta é uma estimativa exagerada porque pressupõe que estamos a pagar trabalhadores ociosos. Se não levarmos em conta o custo dos trabalhadores ociosos (por exemplo, fechá-los ou colocá-los em outros empregos), o custo será de cerca de US$ 19,61.
*Este bloco tem 182 transações, ou US$ 0,11 por transação.
Vale a pena notar que essas estimativas em dólares são independentes do tamanho do cluster! O que importa é o número de segmentos. Isso ocorre porque 1 máquina realizando 2 trabalhos em sequência custa o mesmo que 2 máquinas realizando 1 trabalho em paralelo. Portanto, se o tamanho do cluster for maior, as provas serão geradas mais rapidamente, mas não mais caras.
Existem várias maneiras de reduzir ainda mais custos. Além de continuar a melhorar o desempenho do zkVM, talvez adicionando um acelerador Keccak, também podemos procurar instâncias mais baratas. É importante ressaltar que, dadas as máquinas de baixa especificação que estamos usando (e nosso zkVM suporta nVidia Cuda e Apple Metal), esse trabalho pode ser feito facilmente em uma rede p2p de PCs e Macs comuns.
Verificação na cadeia
Conforme mencionado acima, verificamos as provas Zeth em Sepolia usando o validador RISC Zero Groth16. Esta é uma parte relativamente nova da pilha de protocolos RISC Zero, lançada no início deste mês. Ele funciona usando o Bonsai para converter a prova STARK nativa do zkVM em uma prova SNARK equivalente e enviar essa prova para um validador SNARK na cadeia.
Se visualizarmos a entrada da transação como dados UTF-8, veremos que a prova corresponde ao bloco 17735424.
Usando o Bonsai, a conversão de STARK para SNARK leva cerca de 40 segundos. A verificação do SNARK on-chain custou 245.129 gás (~$5,90 no momento em que este artigo foi escrito).
Obviamente, uma vantagem do zkVM é que ele pode combinar várias provas em uma. Com esta funcionalidade, todo um conjunto de provas pode ser verificado na rede sem a utilização de qualquer gás adicional. Dessa forma, o custo da verificação on-chain pode ser distribuído por todo o conjunto de provas, reduzindo o custo para todos.
O que isso significa para Ethereum
Conforme mencionado anteriormente, o Ethereum não foi projetado tendo em mente a compatibilidade com ZK. Como mostra o caso dos zkEVMs, há muitas coisas que podem ser feitas de diferentes maneiras, especialmente quando se trata de opcodes, assinaturas digitais e funções hash.
Embora essas mudanças tenham melhorado o desempenho, ainda conseguimos alcançar um desempenho sólido sem essas mudanças. Quando Vitalik escreveu sobre diferentes tipos de zkEVMs no ano passado, demorou horas para provar a validade de um bloco Ethereum; agora podemos fazer isso em minutos. O desempenho do ZK está melhorando rapidamente e temos motivos para acreditar que esta tendência continuará nos próximos anos.
Apêndice: Como Zeth funciona
Esta seção é para desenvolvedores.
Grosso modo, Zeth constrói blocos da mesma maneira que um nó completo: começamos com o bloco pai, a lista de transações e o autor do bloco e, em seguida, fazemos muitos cálculos (verificamos assinaturas, executamos transações, atualizamos o estado global, etc.), e finalmente retornar o novo valor de hash do bloco.
Mas, diferentemente dos nós completos, fazemos isso no zkVM. Isso significa que obtemos uma prova ZK de que um bloco com um determinado hash é válido.
É claro que isso não ocorre sem desafios. Nesta seção, apresentamos esses desafios e como os abordamos.
Criptografia
O primeiro desafio é a criptografia. Construir um bloco Ethereum requer muito trabalho, sendo os mais importantes o hashing (Keccak-256) e a verificação de assinatura (ECDSA e secp256k1).
Nosso zkVM acelerou o suporte para curvas elípticas, portanto a verificação da assinatura ECDSA não é difícil.
Mas quando se trata de hashing, não temos tanta sorte. Nosso zkVM acelerou o suporte para Sha2-256, mas não (no momento em que este artigo foi escrito) Keccak-256. Portanto, atualmente estamos usando apenas a implementação Keccak na caixa sha3 Rust. Através da criação de perfil, sabemos que isso leva muitos ciclos. Não é o ideal, mas nosso zkVM pode lidar com isso e podemos reciclar e adicionar aceleradores Keccak posteriormente.
Contas e armazenamento: desempenho e segurança
No Ethereum, as contas e o armazenamento são rastreados por uma Merkle Patricia Trie (MPT) global.
No momento em que este artigo foi escrito, a árvore continha o estado de quase 250 milhões de endereços Ethereum exclusivos, de acordo com o Etherscan. No geral, não é uma grande quantidade de dados, mas é o suficiente para nos fazer ter cuidado sobre como os armazenamos e usamos. Em particular, o desempenho do MPT é crítico.
Mas o desempenho não é o único fator, devemos considerar também a segurança.
O gerador de blocos do Zeth é executado como cliente no zkVM. Isso significa que ele não pode acessar diretamente a rede p2p Ethereum ou outros provedores de RPC. Em vez disso, ele deve contar com dados fornecidos por programas separados executados fora do zkVM.
Ao analisar a segurança de um aplicativo ZK, devemos assumir que os programas externos são maliciosos e, portanto, podem fornecer dados maliciosos. Para evitar isso, os aplicativos ZK devem verificar se os dados que lhes são fornecidos são válidos.
Para geradores de blocos Zeth, isso significa verificar o estado de todas as contas e armazenamento relevantes (ou seja, as contas e o armazenamento necessários para executar uma determinada lista de transações).
Felizmente, esse mecanismo é fornecido pelo EIP-1186, que define uma forma padrão de comprovar o estado de uma determinada conta (e seu armazenamento) por meio da inclusão Merkle.
Em princípio, os geradores de blocos Zeth poderiam verificar o estado da conta e do armazenamento verificando um conjunto de provas de inclusão EIP-1186. Mas esta abordagem não é ideal.
Em vez disso, é melhor usar os dados da prova de inclusão EIP-1186 para construir um MPT parcial. Este é um tipo de MPT que inclui apenas nós que são relevantes para uma determinada lista de transações; ramificações não relacionadas são simplesmente representadas com hashes correspondentes. Você pode pensar nos MPTs parciais como uma espécie de “união” de provas de inclusão de Merkle; ou, se preferir, como provas de subconjuntos de Merkle.
O processo de verificação de um MPT parcial é basicamente o mesmo que a verificação de uma prova EIP-1186 normal: o hash raiz é calculado e comparado com a raiz de estado do bloco pai. Se os dois forem iguais, a integridade das contas e do armazenamento dentro delas pode ser confiável.
Uma vez verificado o MPT parcial, a transação pode ser aplicada e o MPT parcial atualizado. A nova raiz de estado pode ser obtida calculando o novo valor hash da raiz do MPT parcial.
No zkVM, o gerador de blocos Zeth:
Após a conclusão do gerador de bloco Zeth, ele gerará o valor hash do novo bloco.
Este hash inclui um compromisso com o bloco pai e, portanto, a raiz de estado do bloco pai (usado para verificar o MPT parcial original). Isso significa que um validador malicioso não pode fornecer contas e armazenamento com dados inválidos sem fornecer um bloco pai inválido.
Em outras palavras: se o bloco pai for válido, então o novo bloco gerado pelo Zeth também será válido.
Portanto, se alguém lhe der um novo bloco e uma prova ZK gerada por Zeth, você poderá verificar a validade do bloco verificando as três coisas a seguir:
Se estes forem verificados, o novo bloco será válido.
Limitações e melhorias futuras
O objetivo do nosso projeto é estudar o desempenho da construção de blocos. Por esse motivo, decidimos limitar o escopo aos blocos mesclados.
Além disso, embora Zeth seja capaz de provar que um determinado bloco é válido, atualmente não pode provar o consenso (ou seja, que o bloco está de fato incluído na cadeia canônica). Isso pode mudar no futuro, talvez adicionando verificações de assinaturas do validador ou do comitê de sincronização no zkVM.
Finalmente, Zeth é um novo software. Embora tenhamos feito alguns testes (incluindo o conjunto de testes Ethereum e vários blocos do mundo real), Zeth ainda pode conter alguns bugs. No momento em que este livro foi escrito, deveria ser considerado um software experimental.