Autor: Justin Thaler Fonte: a16z Tradução: Shanooba, Golden Finance
Máquinas Virtuais de Conhecimento Zero (zkVMs) têm como objetivo "tornar os SNARKs acessíveis ao público em geral", permitindo que mesmo pessoas sem conhecimento especializado em SNARK possam provar que executaram corretamente um determinado programa em uma entrada específica (ou testemunho). Sua principal vantagem está na experiência do desenvolvedor, mas atualmente zkVMs ainda enfrentam grandes desafios em termos de segurança e desempenho. Se zkVMs quiserem cumprir suas promessas, os designers terão que superar esses obstáculos. Este artigo discutirá as possíveis fases de desenvolvimento do zkVM, um processo que pode levar vários anos para ser concluído - não acredite em quem disser que isso pode ser rapidamente realizado.
Desafios enfrentados
Em termos de segurança, os zkVMs são projetos de software altamente complexos e ainda cheios de falhas.
Em termos de desempenho, a comprovação correta da execução de um programa pode ser dezenas de milhares de vezes mais lenta do que a execução nativa, o que torna a implantação da maioria das aplicações no mundo real atualmente inviável.
No entanto, muitas vozes na indústria blockchain ainda estão a promover que os zkVMs podem ser implantados imediatamente, e até alguns projetos já estão a pagar custos computacionais elevados para gerar provas de conhecimento zero das atividades na cadeia. No entanto, devido a várias falhas nos zkVMs, esta abordagem é na verdade apenas uma disfarce dispendioso, que faz com que o sistema pareça protegido por SNARK, quando na realidade depende de controlo de permissões, ou pior ainda — exposto a riscos de ataque.
A situação real é que ainda estamos a vários anos de distância de construir um zkVM verdadeiramente seguro e eficiente. Este artigo apresenta uma série de objetivos concretos e faseados para nos ajudar a acompanhar o progresso real do zkVM, reduzir a especulação e direcionar a atenção da comunidade para avanços tecnológicos reais.
Fase de Desenvolvimento da Segurança
Antecedentes
As SNARK baseado em zkVMs geralmente contém dois componentes principais:
Prova de oráculo interativo polinomial (Polynomial Interactive Oracle Proof, PIOP): um quadro de prova interativo para provar polinômios (ou restrições derivadas de polinômios) .
Esquema de Compromisso Polinomial (Polynomial Commitment Scheme, PCS): Garante que o verificador não consiga forjar os resultados da avaliação polinomial sem ser detectado.
zkVM garante o uso correto dos registros e da memória da máquina virtual, codificando trajetos de execução eficazes em sistemas de restrições e depois provando a satisfação dessas restrições com SNARK.
A única maneira de garantir que zkVM não tenha vulnerabilidades em um sistema tão complexo é averificação formal. Aqui estão diferentes fases de segurança do zkVM, com o** primeira fase focada na corretude do protocolo e a segunda e a terceira fases focadas na corretude da implementação.
Fase 1 de Segurança: Protocolo Correto
A prova formal da verificação da confiabilidade do PIOP;
PCS sob a forma de prova de validação vinculativa em alguns pressupostos ou modelos idealizados de criptografia;
Se o Fiat-Shamir for usado, a prova formal segura obtida combinando PIOP e PCS em um modelo de previsão aleatória é uma verificação segura (reforçada conforme necessário com outras suposições criptográficas);
O sistema de restrições aplicado pelo PIOP é equivalente à prova formal da semântica do VM.
Junte todas estas partes acima mencionadas num único e seguro prova SNARK formalmente verificada, para executar qualquer programa especificado pelo bytecode da VM. Se o protocolo pretende ser à prova de conhecimento zero, este atributo também deve ser formalmente verificado para garantir que não haja divulgação de informações sensíveis sobre os testemunhos.
Se o zkVM usar recursão, então durante o processo de recursão, PIOP, compromissos e sistemas de restriçãotodos devem ser verificados, caso contrário, essa subfase não pode ser considerada concluída.
Fase 2 de Segurança: Implementação correta do validador
Esta fase exige a verificação formal da implementação real do validador zkVM (como Rust, Solidity, etc.) para garantir que esteja em conformidade com os protocolos verificados na primeira fase. A conclusão desta fase significa que a implementação do zkVM é consistente com o design teórico, e não é apenas um protocolo de segurança de papel, ou uma especificação ineficiente escrita em linguagens como Lean.
Porque** apenas focar nos validadores e não nos provadores** tem duas razões principais: em primeiro lugar, garantir que os validadores estejam corretos pode garantir a integridade do sistema de prova zkVM (ou seja, garantir que os validadores não sejam enganados para aceitar uma prova incorreta). Em segundo lugar, a implementação do validador zkVM é pelo menos uma ordem de magnitude mais simples do que a implementação do provador, tornando a correção do validador mais facilmente assegurada a curto prazo.
Fase 3 de Segurança: Proofers corretos implementados
Nesta fase, é exigida a verificação formal da implementação real dos provadores zkVM para garantir que ele pode gerar corretamente provas do sistema de provas já verificado nas fases um e dois. O objetivo desta fase é a completude, ou seja: nenhum sistema que utilize zkVM deve travar devido à incapacidade de provar uma sentença legítima. Se o zkVM precisar ter propriedades de conhecimento zero, então deve fornecer verificação formal para garantir que a prova não revele qualquer informação sobre a testemunha.
Cronograma Previsto
Fase 1 de Progresso: Podemos esperar algum progresso no próximo ano (por exemplo, ZKLib é um esforço nesse sentido). Mas nenhum zkVM será capaz de atender completamente aos requisitos da Fase 1 em pelo menos dois anos.
Fase 2 e Fase 3 : Estas fases podem avançar simultaneamente com alguns aspectos da Fase 1. Por exemplo, algumas equipas já demonstraram a implementação do verificador Plonk que corresponde ao protocolo no documento (embora o próprio protocolo do documento possa não estar totalmente validado). No entanto, espero que qualquer zkVM não atinja a Fase 3 em menos de quatro anos - e talvez até mais tempo.
Fiat-Shamir segurança e bytecode verificado
Uma questão principal de complexidade é que a segurança da transformação Fiat-Shamir ainda tem problemas de pesquisa não resolvidos. Todos os três estágios de segurança consideram o Fiat-Shamir e o oráculo aleatório como absolutamente seguros, mas na realidade, pode haver vulnerabilidades em todo o paradigma. Isso ocorre devido à diferença entre o modelo idealizado do oráculo aleatório e as funções de hash realmente utilizadas.
Na pior das hipóteses, um sistema que já atingiu a fase de segurança 2 pode ser descoberto como totalmente inseguro devido a problemas relacionados com o Fiat-Shamir. Isso merece nossa atenção total e pesquisa contínua. Podemos precisar modificar o próprio transformação Fiat-Shamir para melhor defender contra essas vulnerabilidades.
Um sistema sem recursão é teoricamente mais seguro, pois alguns ataques conhecidos envolvem circuitos semelhantes aos utilizados em provas recursivas. No entanto, este risco continua a ser um problema fundamental não resolvido.
Outra questão a ter em atenção é que, mesmo que o zkVM prove que um programa de computador (especificado pelo código de bytes) foi executado corretamente, se o próprio código de bytes tiver defeitos, então o valor desta prova é extremamente limitado. Portanto, a utilidade do zkVM depende em grande medida de como gerar código de bytes verificado formalmente, e este desafio é enorme e ultrapassa o âmbito deste documento.
Sobre Segurança Antiquântica
Nos próximos pelo menos 5 anos (ou mesmo mais tempo), os computadores quânticos não representarão uma ameaça séria, enquanto as vulnerabilidades de software são uma questão de vida ou morte. Portanto, a tarefa principal no momento deve ser alcançar os objetivos de segurança e desempenho propostos neste artigo. Se os SNARKs não resistentes a quântica puderem atender a esses objetivos mais rapidamente, devemos priorizá-los. Aguarde até que os SNARKs resistentes a quântica alcancem o desenvolvimento, ou haja sinais de que os computadores quânticos que representam uma ameaça real estejam prestes a aparecer, e então considere a mudança.
Nível de segurança específico
100-bit Segurança Clássica é o padrão mínimo para qualquer SNARK que protege ativos de valor (embora ainda haja alguns sistemas que não atendem a este padrão mínimo). No entanto, isso ainda não deve ser aceitável, as práticas criptográficas padrão geralmente exigem segurança de 128 bits ou mais. Se a segurança do SNARK atender aos requisitos, não devemos comprometer a segurança para melhorar o desempenho.
Fase de Desempenho
Situação atual
Atualmente, o custo computacional do verificador zkVM é aproximadamente 1.000.000 vezes maior do que a execução nativa. Em outras palavras, se a execução nativa de um programa requer X ciclos de CPU, gerar uma prova de execução correta requer aproximadamente X × 1.000.000 ciclos de CPU. Esta situação era assim há um ano e ainda é hoje (embora haja algumas confusões).
Alguns termos populares na indústria atual podem ser enganosos, por exemplo:
O custo de gerar prova para toda a rede principal do Ethereum é inferior a 1 milhão de dólares por ano.
"Quase alcançamos a geração de prova em tempo real de blocos Ethereum, precisando apenas de algumas dezenas de GPUs."
"Nosso novo zkVM é 1000 vezes mais rápido que o anterior."
No entanto, essas afirmações podem ser enganosas sem contexto:
• É 1000 vezes mais rápido do que o zkVM antigo, mas ainda pode ser muito lento, o que mostra mais quão ruim costumava ser no passado, em vez de quão bom é agora.
• A capacidade de computação da mainnet do Ethereum pode aumentar 10 vezes no futuro, o que fará com que o desempenho atual do zkVM fique muito aquém das necessidades.
O chamado 'quase em tempo real' de geração de prova ainda é muito lento para muitas aplicações de blockchain (por exemplo, o tempo de bloco do Optimism é de 2 segundos, muito mais rápido do que os 12 segundos do Ethereum).
• “Several dozen GPUs running 24/7 for a long time” cannot provide sufficient guarantee of activity.
• Esses tempos de geração de prova são normalmente para tamanhos de prova acima de 1MB, o que é muito grande para muitas aplicações.
• O custo anual de menos de 1 milhão de dólares é apenas devido ao fato de que um nó completo do Ethereum executa apenas cerca de 25 dólares em cálculos por ano.
Para aplicações fora da blockchain, este custo computacional é claramente excessivo. Nenhuma quantidade de cálculos paralelos ou otimização de engenharia pode compensar um custo de computação tão grande.
O objetivo básico que devemos definir é que o custo de desempenho não exceda 100.000 vezes a execução nativa. Mas mesmo assim, isso é apenas o primeiro passo. Se quisermos realmente alcançar uma aplicação em grande escala e de grande alcance, talvez seja necessário reduzir o custo para 10.000 vezes ou menos da execução nativa.
Medição de Desempenho
O desempenho do SNARK tem três componentes principais:
A eficiência comprovada do sistema de prova de trabalho.
Otimização para aplicativos específicos (por exemplo, pré-compilação).
Engenharia e Aceleração de Hardware (por exemplo, GPU, FPGA ou CPU multi-core).
Embora (2) e (3) sejam cruciais para a implementação prática, são aplicáveis a qualquer sistema de prova, por isso nem sempre refletem melhorias nos custos básicos. Por exemplo, adicionar aceleração de GPU e pré-compilação ao zkEVM pode facilmente aumentar a velocidade em 50 vezes em relação à simples dependência da CPU - o que pode fazer com que um sistema eficiente pareça ser superior a outro sistema não otimizado da mesma forma.
Assim, este artigo centra-se na avaliação da performance básica do SNARK sem hardware especializado e pré-compilação. Isto é diferente dos métodos de teste de referência atuais, que geralmente combinam os três fatores num único "valor global". É como avaliar um diamante com base no tempo de polimento, em vez de avaliar a sua clareza inata.
Nosso objetivo é isolar os custos inerentes ao sistema de prova universal, reduzir a barreira de entrada para tecnologias ainda não profundamente pesquisadas e ajudar a comunidade a eliminar os fatores de distração, concentrando-se assim no verdadeiro progresso do design do sistema de prova.
Fase de Desempenho
Aqui estão os cinco marcos dos estágios de desempenho que propus. Primeiro, precisamos reduzir significativamente os custos do verificador na CPU antes de podermos depender mais do hardware para reduzir os custos. Ao mesmo tempo, o uso da memória também deve ser melhorado.
Em todas as fases, os desenvolvedores não devem ajustar o código para o desempenho do zkVM. A experiência do desenvolvedor é a principal vantagem do zkVM. Sacrificar o DevEx para atender aos benchmarks de desempenho não apenas perde o significado dos testes de benchmark, mas também vai contra a intenção original do zkVM.
Estes indicadores centram-se principalmente no custo do verificador. No entanto, se for permitido um crescimento ilimitado do custo do validador (ou seja, tamanho de prova ou tempo de validação sem limite), então qualquer indicador do verificador pode ser facilmente cumprido. Portanto, para cumprir os requisitos das fases a seguir, é necessário limitar simultaneamente o tamanho máximo da prova e o tempo máximo de validação.
Fase 1 Requisito: 'Custo de verificação não trivial razoável'
• Tamanho da prova: Deve ser menor que o tamanho da prova.
• Tempo de Verificação: A velocidade de verificação da prova não deve ser mais lenta do que a execução nativa do programa (ou seja, não deve ser mais lenta do que a execução direta do cálculo).
Estes são os requisitos mínimos de simplicidade para garantir que o tamanho da prova e o tempo de verificação não sejam piores do que enviar diretamente a prova para o verificador e deixá-lo verificar diretamente.
Fase 2 e acima
• Tamanho máximo da prova：256 KB。
• Tempo máximo de verificação：16 milissegundos。
Esses limites superiores são intencionalmente definidos de forma mais flexível para se adequarem às novas tecnologias de prova rápida, mesmo que possam resultar em custos de verificação mais altos. Ao mesmo tempo, esses limites excluem provas tão caras que praticamente nenhum projeto estaria disposto a usá-las na blockchain.
Fase 1 de velocidade
A velocidade de prova de um único fio não pode ser mais lenta do que a execução nativa em mais de 100.000 vezes (aplicável a várias aplicações, não apenas provas de blocos de Ethereum), e não pode depender de pré-compilação.
Especificamente, supondo que um processador RISC-V em um laptop moderno opere a uma velocidade de aproximadamente 30 bilhões de ciclos por segundo, atingir a fase 1 significa que o laptop pode gerar provas a uma velocidade de 30.000 ciclos RISC-V por segundo (em um único thread).
O custo do validador deve atender ao padrão de 'custo de validação razoável e não trivial' definido anteriormente.
Fase 2 de velocidade
A prova de velocidade de uma única linha não pode ser mais lenta do que a execução nativa em mais de 10.000 vezes.
Ou, devido a algumas perspectivas promissoras do método SNARK (especialmente o SNARK de campo binário) serem limitadas pelas atuais CPUs e GPUs, pode-se recorrer a FPGA (ou mesmo ASIC) para atender a esta fase:
Calcular o número de núcleos RISC-V simulados em velocidade nativa pelo FPGA.
Calcular, simular e demonstrar o número de FPGA necessários para a execução (quase em tempo real) de RISC-V.
Se a quantidade (2) não exceder 10.000 vezes a quantidade (1), a fase 2 é cumprida.
• Tamanho máximo do comprovante: 256 KB.
• Tempo de Verificação: máximo de 16 milissegundos em CPU padrão.
Fase 3 de Velocidade
Com base na fase 2 de velocidade, alcance despesas de prova dentro de 1000× (aplicável a várias aplicações), e deve usar pré-compilação com síntese automática e verificação formal. Essencialmente, personalize dinamicamente o conjunto de instruções de cada programa para acelerar a geração de provas, mas garanta facilidade de uso e verificação formal. (Para saber mais sobre por que a pré-compilação é uma faca de dois gumes e por que a pré-compilação "manual" não é um método sustentável, consulte a próxima seção.)
Fase 1 de memória
Atéestágio 1 de velocidade, com menos de 2 GB de RAM, e ao mesmo tempo atendendo aos requisitos de conhecimento zero. Esta etapa é crucial para dispositivos móveis ou navegadores e abre as portas para muitos casos de uso de zkVM do lado do cliente. Por exemplo, smartphones são usados para privacidade de localização, credenciais de identidade, etc. Se a geração de prova exigir mais de 1-2 GB de RAM, a maioria dos dispositivos móveis não será capaz de executá-la.
Dois pontos importantes a notar:
Mesmo para cálculos em grande escala (que requerem a execução nativa de trilhões de ciclos de CPU), o sistema de prova deve manter um limite de 2 GB de memória, caso contrário, a adequação será limitada.
Se provar ser muito lento, é facilmente mantido o limite de memória de 2 GB. Portanto, para que a fase de memória 1 seja significativa, é necessário atingir a fase 1 de velocidade dentro do limite de memória de 2 GB.
Fase 2 de Memória
Alcance a Fase 1 de velocidade (10 vezes mais rápido que a Fase 1 de memória) com menos de 200 MB de memória.
Porque reduzir para 200 MB? Considere um cenário não relacionado com blockchain: quando visita um site HTTPS, irá descarregar certificados de autenticação e encriptação. Se o site mudar para enviar provas zk desses certificados, um grande site pode precisar de gerar milhões de provas por segundo. Se cada prova precisar de 2 GB de memória, os recursos de cálculo necessários serão da ordem dos PB, claramente inviáveis. Portanto, a redução adicional do uso de memória é crucial para as aplicações não relacionadas com blockchain.
Pré-compilação: Última Milha, Cane ou Bastão?
A pré-compilação refere-se a um sistema de restrições SNARK otimizado especificamente para funções específicas (como hash, assinatura de curva elíptica). No Ethereum, a pré-compilação pode reduzir os custos de hash de Merkle e verificação de assinatura, mas depender em excesso da pré-compilação não melhora verdadeiramente a eficiência central do SNARK.
Problemas de pré-compilação
1. Ainda muito lento: Apesar de usar pré-compilação de hash e assinatura, o zkVM ainda apresenta problemas de eficiência do sistema de prova principal dentro e fora da blockchain.
2. Vulnerabilidades de Segurança: Se a pré-compilação manual não for formalmente verificada, é quase certo que existirão vulnerabilidades que podem levar a falhas de segurança catastróficas.
3. Experiência do desenvolvedor ruim: Atualmente, muitos zkVM precisam que os desenvolvedores escrevam manualmente sistemas de restrições, semelhante à forma de programação dos anos 1960, afetando seriamente a experiência de desenvolvimento.
4. Teste de benchmark enganador: Se os testes de benchmark dependem da otimização de compilação específica, podem levar as pessoas a focar nas otimizações manuais do sistema em vez de melhorar o próprio design do SNARK.
5. Despesas de E/S e acesso sem RAM Embora a pré-compilação possa melhorar o desempenho de tarefas de criptografia pesadas, ela pode não acelerar significativamente cargas de trabalho mais diversificadas, uma vez que geram muitas despesas ao lidar com entrada/saída e não podem usar RAM.
Mesmo no ambiente da blockchain, se você ultrapassar uma única L1 como o Ethereum (por exemplo, se quiser construir uma série de pontes interligadas), enfrentará diferentes funções de hash e esquemas de assinatura. Resolver esse problema através de pré-compilação contínua não é escalável e acarreta enormes riscos de segurança.
Eu realmente acredito que a pré-compilação ainda é crucial a longo prazo, mas apenas quando for automaticamente sintetizada e formalmente verificada. Isso nos permite manter a vantagem na experiência dos desenvolvedores do zkVM, ao mesmo tempo que evitamos riscos de segurança catastróficos. Esta visão é refletida na Fase 3.
Cronograma Esperado
Espero que um pequeno número de zkVMs atinja a Fase 1 de velocidade e a Fase 1 de memória mais tarde este ano. Acredito que também conseguiremos alcançar a Fase 2 de velocidade nos próximos dois anos, mas não está claro se conseguiremos atingir esse objetivo sem novas ideias de pesquisa.
Prevejo que as fases restantes (Fase de velocidade 3 e Fase de memória 2) levarão vários anos para serem concluídas.
Embora este artigo liste separadamente a segurança e o desempenho do zkVM, esses dois não são completamente independentes. À medida que as vulnerabilidades no zkVM continuam a ser descobertas, prevejo que a correção de algumas dessas vulnerabilidades inevitavelmente resultará em uma queda significativa no desempenho. Portanto, os resultados dos testes de desempenho do zkVM devem ser considerados como dados provisórios até que o zkVM atinja a Fase de Segurança 2.
zkVM tem um enorme potencial para popularizar verdadeiramente as provas de conhecimento zero, mas atualmente está em uma fase inicial - cheia de desafios de segurança e com sérias limitações de desempenho. A especulação de mercado e a publicidade tornam difícil medir o progresso real. Através de marcos claros de segurança e desempenho, espero fornecer um roadmap que possa dissipar a neblina. Eventualmente, alcançaremos o objetivo, mas isso levará tempo e esforço contínuo em pesquisa e engenharia.
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.
a16z: Explorando o caminho eficiente e seguro do zkVM
Autor: Justin Thaler Fonte: a16z Tradução: Shanooba, Golden Finance
Máquinas Virtuais de Conhecimento Zero (zkVMs) têm como objetivo "tornar os SNARKs acessíveis ao público em geral", permitindo que mesmo pessoas sem conhecimento especializado em SNARK possam provar que executaram corretamente um determinado programa em uma entrada específica (ou testemunho). Sua principal vantagem está na experiência do desenvolvedor, mas atualmente zkVMs ainda enfrentam grandes desafios em termos de segurança e desempenho. Se zkVMs quiserem cumprir suas promessas, os designers terão que superar esses obstáculos. Este artigo discutirá as possíveis fases de desenvolvimento do zkVM, um processo que pode levar vários anos para ser concluído - não acredite em quem disser que isso pode ser rapidamente realizado.
Desafios enfrentados
Em termos de segurança, os zkVMs são projetos de software altamente complexos e ainda cheios de falhas.
Em termos de desempenho, a comprovação correta da execução de um programa pode ser dezenas de milhares de vezes mais lenta do que a execução nativa, o que torna a implantação da maioria das aplicações no mundo real atualmente inviável.
No entanto, muitas vozes na indústria blockchain ainda estão a promover que os zkVMs podem ser implantados imediatamente, e até alguns projetos já estão a pagar custos computacionais elevados para gerar provas de conhecimento zero das atividades na cadeia. No entanto, devido a várias falhas nos zkVMs, esta abordagem é na verdade apenas uma disfarce dispendioso, que faz com que o sistema pareça protegido por SNARK, quando na realidade depende de controlo de permissões, ou pior ainda — exposto a riscos de ataque.
A situação real é que ainda estamos a vários anos de distância de construir um zkVM verdadeiramente seguro e eficiente. Este artigo apresenta uma série de objetivos concretos e faseados para nos ajudar a acompanhar o progresso real do zkVM, reduzir a especulação e direcionar a atenção da comunidade para avanços tecnológicos reais.
Fase de Desenvolvimento da Segurança
Antecedentes
As SNARK baseado em zkVMs geralmente contém dois componentes principais:
Prova de oráculo interativo polinomial (Polynomial Interactive Oracle Proof, PIOP): um quadro de prova interativo para provar polinômios (ou restrições derivadas de polinômios) .
Esquema de Compromisso Polinomial (Polynomial Commitment Scheme, PCS): Garante que o verificador não consiga forjar os resultados da avaliação polinomial sem ser detectado.
zkVM garante o uso correto dos registros e da memória da máquina virtual, codificando trajetos de execução eficazes em sistemas de restrições e depois provando a satisfação dessas restrições com SNARK.
A única maneira de garantir que zkVM não tenha vulnerabilidades em um sistema tão complexo é a verificação formal. Aqui estão diferentes fases de segurança do zkVM, com o** primeira fase focada na corretude do protocolo e a segunda e a terceira fases focadas na corretude da implementação.
Fase 1 de Segurança: Protocolo Correto
Se o zkVM usar recursão, então durante o processo de recursão, PIOP, compromissos e sistemas de restrição todos devem ser verificados, caso contrário, essa subfase não pode ser considerada concluída.
Fase 2 de Segurança: Implementação correta do validador
Esta fase exige a verificação formal da implementação real do validador zkVM (como Rust, Solidity, etc.) para garantir que esteja em conformidade com os protocolos verificados na primeira fase. A conclusão desta fase significa que a implementação do zkVM é consistente com o design teórico, e não é apenas um protocolo de segurança de papel, ou uma especificação ineficiente escrita em linguagens como Lean.
Porque** apenas focar nos validadores e não nos provadores** tem duas razões principais: em primeiro lugar, garantir que os validadores estejam corretos pode garantir a integridade do sistema de prova zkVM (ou seja, garantir que os validadores não sejam enganados para aceitar uma prova incorreta). Em segundo lugar, a implementação do validador zkVM é pelo menos uma ordem de magnitude mais simples do que a implementação do provador, tornando a correção do validador mais facilmente assegurada a curto prazo.
Fase 3 de Segurança: Proofers corretos implementados
Nesta fase, é exigida a verificação formal da implementação real dos provadores zkVM para garantir que ele pode gerar corretamente provas do sistema de provas já verificado nas fases um e dois. O objetivo desta fase é a completude, ou seja: nenhum sistema que utilize zkVM deve travar devido à incapacidade de provar uma sentença legítima. Se o zkVM precisar ter propriedades de conhecimento zero, então deve fornecer verificação formal para garantir que a prova não revele qualquer informação sobre a testemunha.
Cronograma Previsto
Fase 1 de Progresso: Podemos esperar algum progresso no próximo ano (por exemplo, ZKLib é um esforço nesse sentido). Mas nenhum zkVM será capaz de atender completamente aos requisitos da Fase 1 em pelo menos dois anos.
Fase 2 e Fase 3 : Estas fases podem avançar simultaneamente com alguns aspectos da Fase 1. Por exemplo, algumas equipas já demonstraram a implementação do verificador Plonk que corresponde ao protocolo no documento (embora o próprio protocolo do documento possa não estar totalmente validado). No entanto, espero que qualquer zkVM não atinja a Fase 3 em menos de quatro anos - e talvez até mais tempo.
Fiat-Shamir segurança e bytecode verificado
Uma questão principal de complexidade é que a segurança da transformação Fiat-Shamir ainda tem problemas de pesquisa não resolvidos. Todos os três estágios de segurança consideram o Fiat-Shamir e o oráculo aleatório como absolutamente seguros, mas na realidade, pode haver vulnerabilidades em todo o paradigma. Isso ocorre devido à diferença entre o modelo idealizado do oráculo aleatório e as funções de hash realmente utilizadas.
Na pior das hipóteses, um sistema que já atingiu a fase de segurança 2 pode ser descoberto como totalmente inseguro devido a problemas relacionados com o Fiat-Shamir. Isso merece nossa atenção total e pesquisa contínua. Podemos precisar modificar o próprio transformação Fiat-Shamir para melhor defender contra essas vulnerabilidades.
Um sistema sem recursão é teoricamente mais seguro, pois alguns ataques conhecidos envolvem circuitos semelhantes aos utilizados em provas recursivas. No entanto, este risco continua a ser um problema fundamental não resolvido.
Outra questão a ter em atenção é que, mesmo que o zkVM prove que um programa de computador (especificado pelo código de bytes) foi executado corretamente, se o próprio código de bytes tiver defeitos, então o valor desta prova é extremamente limitado. Portanto, a utilidade do zkVM depende em grande medida de como gerar código de bytes verificado formalmente, e este desafio é enorme e ultrapassa o âmbito deste documento.
Sobre Segurança Antiquântica
Nos próximos pelo menos 5 anos (ou mesmo mais tempo), os computadores quânticos não representarão uma ameaça séria, enquanto as vulnerabilidades de software são uma questão de vida ou morte. Portanto, a tarefa principal no momento deve ser alcançar os objetivos de segurança e desempenho propostos neste artigo. Se os SNARKs não resistentes a quântica puderem atender a esses objetivos mais rapidamente, devemos priorizá-los. Aguarde até que os SNARKs resistentes a quântica alcancem o desenvolvimento, ou haja sinais de que os computadores quânticos que representam uma ameaça real estejam prestes a aparecer, e então considere a mudança.
Nível de segurança específico
100-bit Segurança Clássica é o padrão mínimo para qualquer SNARK que protege ativos de valor (embora ainda haja alguns sistemas que não atendem a este padrão mínimo). No entanto, isso ainda não deve ser aceitável, as práticas criptográficas padrão geralmente exigem segurança de 128 bits ou mais. Se a segurança do SNARK atender aos requisitos, não devemos comprometer a segurança para melhorar o desempenho.
Fase de Desempenho
Situação atual
Atualmente, o custo computacional do verificador zkVM é aproximadamente 1.000.000 vezes maior do que a execução nativa. Em outras palavras, se a execução nativa de um programa requer X ciclos de CPU, gerar uma prova de execução correta requer aproximadamente X × 1.000.000 ciclos de CPU. Esta situação era assim há um ano e ainda é hoje (embora haja algumas confusões).
Alguns termos populares na indústria atual podem ser enganosos, por exemplo:
O custo de gerar prova para toda a rede principal do Ethereum é inferior a 1 milhão de dólares por ano.
"Quase alcançamos a geração de prova em tempo real de blocos Ethereum, precisando apenas de algumas dezenas de GPUs."
"Nosso novo zkVM é 1000 vezes mais rápido que o anterior."
No entanto, essas afirmações podem ser enganosas sem contexto:
• É 1000 vezes mais rápido do que o zkVM antigo, mas ainda pode ser muito lento, o que mostra mais quão ruim costumava ser no passado, em vez de quão bom é agora.
• A capacidade de computação da mainnet do Ethereum pode aumentar 10 vezes no futuro, o que fará com que o desempenho atual do zkVM fique muito aquém das necessidades.
O chamado 'quase em tempo real' de geração de prova ainda é muito lento para muitas aplicações de blockchain (por exemplo, o tempo de bloco do Optimism é de 2 segundos, muito mais rápido do que os 12 segundos do Ethereum).
• “Several dozen GPUs running 24/7 for a long time” cannot provide sufficient guarantee of activity.
• Esses tempos de geração de prova são normalmente para tamanhos de prova acima de 1MB, o que é muito grande para muitas aplicações.
• O custo anual de menos de 1 milhão de dólares é apenas devido ao fato de que um nó completo do Ethereum executa apenas cerca de 25 dólares em cálculos por ano.
Para aplicações fora da blockchain, este custo computacional é claramente excessivo. Nenhuma quantidade de cálculos paralelos ou otimização de engenharia pode compensar um custo de computação tão grande.
O objetivo básico que devemos definir é que o custo de desempenho não exceda 100.000 vezes a execução nativa. Mas mesmo assim, isso é apenas o primeiro passo. Se quisermos realmente alcançar uma aplicação em grande escala e de grande alcance, talvez seja necessário reduzir o custo para 10.000 vezes ou menos da execução nativa.
Medição de Desempenho
O desempenho do SNARK tem três componentes principais:
A eficiência comprovada do sistema de prova de trabalho.
Otimização para aplicativos específicos (por exemplo, pré-compilação).
Engenharia e Aceleração de Hardware (por exemplo, GPU, FPGA ou CPU multi-core).
Embora (2) e (3) sejam cruciais para a implementação prática, são aplicáveis a qualquer sistema de prova, por isso nem sempre refletem melhorias nos custos básicos. Por exemplo, adicionar aceleração de GPU e pré-compilação ao zkEVM pode facilmente aumentar a velocidade em 50 vezes em relação à simples dependência da CPU - o que pode fazer com que um sistema eficiente pareça ser superior a outro sistema não otimizado da mesma forma.
Assim, este artigo centra-se na avaliação da performance básica do SNARK sem hardware especializado e pré-compilação. Isto é diferente dos métodos de teste de referência atuais, que geralmente combinam os três fatores num único "valor global". É como avaliar um diamante com base no tempo de polimento, em vez de avaliar a sua clareza inata.
Nosso objetivo é isolar os custos inerentes ao sistema de prova universal, reduzir a barreira de entrada para tecnologias ainda não profundamente pesquisadas e ajudar a comunidade a eliminar os fatores de distração, concentrando-se assim no verdadeiro progresso do design do sistema de prova.
Fase de Desempenho
Aqui estão os cinco marcos dos estágios de desempenho que propus. Primeiro, precisamos reduzir significativamente os custos do verificador na CPU antes de podermos depender mais do hardware para reduzir os custos. Ao mesmo tempo, o uso da memória também deve ser melhorado.
Em todas as fases, os desenvolvedores não devem ajustar o código para o desempenho do zkVM. A experiência do desenvolvedor é a principal vantagem do zkVM. Sacrificar o DevEx para atender aos benchmarks de desempenho não apenas perde o significado dos testes de benchmark, mas também vai contra a intenção original do zkVM.
Estes indicadores centram-se principalmente no custo do verificador. No entanto, se for permitido um crescimento ilimitado do custo do validador (ou seja, tamanho de prova ou tempo de validação sem limite), então qualquer indicador do verificador pode ser facilmente cumprido. Portanto, para cumprir os requisitos das fases a seguir, é necessário limitar simultaneamente o tamanho máximo da prova e o tempo máximo de validação.
Fase 1 Requisito: 'Custo de verificação não trivial razoável'
• Tamanho da prova: Deve ser menor que o tamanho da prova.
• Tempo de Verificação: A velocidade de verificação da prova não deve ser mais lenta do que a execução nativa do programa (ou seja, não deve ser mais lenta do que a execução direta do cálculo).
Estes são os requisitos mínimos de simplicidade para garantir que o tamanho da prova e o tempo de verificação não sejam piores do que enviar diretamente a prova para o verificador e deixá-lo verificar diretamente.
Fase 2 e acima
• Tamanho máximo da prova：256 KB。
• Tempo máximo de verificação：16 milissegundos。
Esses limites superiores são intencionalmente definidos de forma mais flexível para se adequarem às novas tecnologias de prova rápida, mesmo que possam resultar em custos de verificação mais altos. Ao mesmo tempo, esses limites excluem provas tão caras que praticamente nenhum projeto estaria disposto a usá-las na blockchain.
Fase 1 de velocidade
A velocidade de prova de um único fio não pode ser mais lenta do que a execução nativa em mais de 100.000 vezes (aplicável a várias aplicações, não apenas provas de blocos de Ethereum), e não pode depender de pré-compilação.
Especificamente, supondo que um processador RISC-V em um laptop moderno opere a uma velocidade de aproximadamente 30 bilhões de ciclos por segundo, atingir a fase 1 significa que o laptop pode gerar provas a uma velocidade de 30.000 ciclos RISC-V por segundo (em um único thread).
O custo do validador deve atender ao padrão de 'custo de validação razoável e não trivial' definido anteriormente.
Fase 2 de velocidade
A prova de velocidade de uma única linha não pode ser mais lenta do que a execução nativa em mais de 10.000 vezes.
Ou, devido a algumas perspectivas promissoras do método SNARK (especialmente o SNARK de campo binário) serem limitadas pelas atuais CPUs e GPUs, pode-se recorrer a FPGA (ou mesmo ASIC) para atender a esta fase:
Calcular o número de núcleos RISC-V simulados em velocidade nativa pelo FPGA.
Calcular, simular e demonstrar o número de FPGA necessários para a execução (quase em tempo real) de RISC-V.
Se a quantidade (2) não exceder 10.000 vezes a quantidade (1), a fase 2 é cumprida.
• Tamanho máximo do comprovante: 256 KB.
• Tempo de Verificação: máximo de 16 milissegundos em CPU padrão.
Fase 3 de Velocidade
Com base na fase 2 de velocidade, alcance despesas de prova dentro de 1000× (aplicável a várias aplicações), e deve usar pré-compilação com síntese automática e verificação formal. Essencialmente, personalize dinamicamente o conjunto de instruções de cada programa para acelerar a geração de provas, mas garanta facilidade de uso e verificação formal. (Para saber mais sobre por que a pré-compilação é uma faca de dois gumes e por que a pré-compilação "manual" não é um método sustentável, consulte a próxima seção.)
Fase 1 de memória
Até estágio 1 de velocidade, com menos de 2 GB de RAM, e ao mesmo tempo atendendo aos requisitos de conhecimento zero. Esta etapa é crucial para dispositivos móveis ou navegadores e abre as portas para muitos casos de uso de zkVM do lado do cliente. Por exemplo, smartphones são usados para privacidade de localização, credenciais de identidade, etc. Se a geração de prova exigir mais de 1-2 GB de RAM, a maioria dos dispositivos móveis não será capaz de executá-la.
Dois pontos importantes a notar:
Mesmo para cálculos em grande escala (que requerem a execução nativa de trilhões de ciclos de CPU), o sistema de prova deve manter um limite de 2 GB de memória, caso contrário, a adequação será limitada.
Se provar ser muito lento, é facilmente mantido o limite de memória de 2 GB. Portanto, para que a fase de memória 1 seja significativa, é necessário atingir a fase 1 de velocidade dentro do limite de memória de 2 GB.
Fase 2 de Memória
Alcance a Fase 1 de velocidade (10 vezes mais rápido que a Fase 1 de memória) com menos de 200 MB de memória.
Porque reduzir para 200 MB? Considere um cenário não relacionado com blockchain: quando visita um site HTTPS, irá descarregar certificados de autenticação e encriptação. Se o site mudar para enviar provas zk desses certificados, um grande site pode precisar de gerar milhões de provas por segundo. Se cada prova precisar de 2 GB de memória, os recursos de cálculo necessários serão da ordem dos PB, claramente inviáveis. Portanto, a redução adicional do uso de memória é crucial para as aplicações não relacionadas com blockchain.
Pré-compilação: Última Milha, Cane ou Bastão?
A pré-compilação refere-se a um sistema de restrições SNARK otimizado especificamente para funções específicas (como hash, assinatura de curva elíptica). No Ethereum, a pré-compilação pode reduzir os custos de hash de Merkle e verificação de assinatura, mas depender em excesso da pré-compilação não melhora verdadeiramente a eficiência central do SNARK.
Problemas de pré-compilação
1. Ainda muito lento: Apesar de usar pré-compilação de hash e assinatura, o zkVM ainda apresenta problemas de eficiência do sistema de prova principal dentro e fora da blockchain.
2. Vulnerabilidades de Segurança: Se a pré-compilação manual não for formalmente verificada, é quase certo que existirão vulnerabilidades que podem levar a falhas de segurança catastróficas.
3. Experiência do desenvolvedor ruim: Atualmente, muitos zkVM precisam que os desenvolvedores escrevam manualmente sistemas de restrições, semelhante à forma de programação dos anos 1960, afetando seriamente a experiência de desenvolvimento.
4. Teste de benchmark enganador: Se os testes de benchmark dependem da otimização de compilação específica, podem levar as pessoas a focar nas otimizações manuais do sistema em vez de melhorar o próprio design do SNARK.
5. Despesas de E/S e acesso sem RAM Embora a pré-compilação possa melhorar o desempenho de tarefas de criptografia pesadas, ela pode não acelerar significativamente cargas de trabalho mais diversificadas, uma vez que geram muitas despesas ao lidar com entrada/saída e não podem usar RAM.
Mesmo no ambiente da blockchain, se você ultrapassar uma única L1 como o Ethereum (por exemplo, se quiser construir uma série de pontes interligadas), enfrentará diferentes funções de hash e esquemas de assinatura. Resolver esse problema através de pré-compilação contínua não é escalável e acarreta enormes riscos de segurança.
Eu realmente acredito que a pré-compilação ainda é crucial a longo prazo, mas apenas quando for automaticamente sintetizada e formalmente verificada. Isso nos permite manter a vantagem na experiência dos desenvolvedores do zkVM, ao mesmo tempo que evitamos riscos de segurança catastróficos. Esta visão é refletida na Fase 3.
Cronograma Esperado
Espero que um pequeno número de zkVMs atinja a Fase 1 de velocidade e a Fase 1 de memória mais tarde este ano. Acredito que também conseguiremos alcançar a Fase 2 de velocidade nos próximos dois anos, mas não está claro se conseguiremos atingir esse objetivo sem novas ideias de pesquisa.
Prevejo que as fases restantes (Fase de velocidade 3 e Fase de memória 2) levarão vários anos para serem concluídas.
Embora este artigo liste separadamente a segurança e o desempenho do zkVM, esses dois não são completamente independentes. À medida que as vulnerabilidades no zkVM continuam a ser descobertas, prevejo que a correção de algumas dessas vulnerabilidades inevitavelmente resultará em uma queda significativa no desempenho. Portanto, os resultados dos testes de desempenho do zkVM devem ser considerados como dados provisórios até que o zkVM atinja a Fase de Segurança 2.
zkVM tem um enorme potencial para popularizar verdadeiramente as provas de conhecimento zero, mas atualmente está em uma fase inicial - cheia de desafios de segurança e com sérias limitações de desempenho. A especulação de mercado e a publicidade tornam difícil medir o progresso real. Através de marcos claros de segurança e desempenho, espero fornecer um roadmap que possa dissipar a neblina. Eventualmente, alcançaremos o objetivo, mas isso levará tempo e esforço contínuo em pesquisa e engenharia.