O caminho para zkVMs seguros e eficientes: Como acompanhar o progresso
Autor original: a16z crypto
原文编译：Golem，Odaily 星球日报
O zkVM (Zero Knowledge Virtual Machine) se compromete a 'popularizar o SNARK', permitindo que qualquer pessoa (mesmo sem conhecimento especializado em SNARK) prove que executou corretamente qualquer programa em uma entrada (ou testemunho) dada. Sua principal vantagem está na experiência do desenvolvedor, mas atualmente enfrenta grandes desafios em termos de segurança e desempenho. Para que a visão do zkVM se concretize, os projetistas devem superar esses desafios. Neste artigo, listo as possíveis fases de desenvolvimento do zkVM, as quais levarão alguns anos para serem concluídas.
Desafio
Em termos de segurança, o zkVM é um projeto de software altamente complexo e ainda cheio de vulnerabilidades. Em termos de desempenho, a velocidade de provar a execução correta do programa pode ser várias centenas de milhares de vezes mais lenta do que a execução local, o que torna a maioria das aplicações atualmente impossíveis de implementar no mundo real.
Apesar destes desafios da vida real, a maioria das empresas na indústria da blockchain retrata o zkVM como algo que pode ser implementado imediatamente. De fato, alguns projetos já pagaram um custo computacional significativo para gerar provas de atividade na cadeia. No entanto, devido à incompletude do zkVM, isso é simplesmente uma forma cara de fingir que o sistema está protegido por SNARK, quando na realidade ou é protegido por permissões, ou pior ainda, é facilmente atacado.
Estamos a anos de distância de alcançar o zkVM seguro e de alto desempenho. Este artigo apresenta uma série de metas específicas em fases para rastrear o progresso do zkVM - metas que podem eliminar a especulação e ajudar a comunidade a focar no progresso real.
Fase de Segurança
Um zkVM baseado em SNARK geralmente consiste em dois componentes principais:
· Prova Interativa de Oráculo de Polinômio (PIOP): Um framework de prova interativa para afirmar sobre polinômios (ou restrições derivadas deles).
· Esquema de compromisso de polinômios (PCS): Garante que o provador não pode mentir sobre a avaliação do polinômio sem ser descoberto.
zkVM essencialmente codifica execuções eficazes como sistemas de restrições - o que significa que eles forçam a máquina virtual a usar corretamente registradores e memória - e depois aplica SNARK para provar que essas restrições são cumpridas.
A garantia de que sistemas complexos como o zkVM não têm erros é a verificação formal. Aqui estão as fases de segurança. A Fase 1 concentra-se nos protocolos corretos, enquanto a Fase 2 e a Fase 3 se concentram na implementação correta.
Fase de Segurança 1: Protocolo Correto
1、Prova formal da verificação de confiabilidade da PIOP;
2、Provas de verificação formal que são vinculativas em certas suposições criptográficas ou modelos ideais;
3、Se o protocolo Fiat-Shamir for usado, a prova formal de segurança em um modelo de previsão aleatória, obtida combinando a prova sucinta obtida por PIOP e PCS, é segura (reforçada conforme necessário por outras suposições criptográficas).
O sistema de restrições aplicado pelo PIOP é equivalente à prova de verificação formal da semântica do VM;
Todos esses componentes devem ser 'colados' em uma única prova de SNARK segura, formalmente verificada, para executar qualquer programa especificado pelo bytecode VM. Se o protocolo pretende alcançar conhecimento zero, essa propriedade também deve ser formalmente verificada para garantir que não haja vazamento de informações sensíveis sobre o testemunho.
Aviso de Recursão: Se o zkVM usar recursão, deve-se verificar cada PIOP, compromisso e sistema de restrições envolvidos em qualquer lugar da recursão antes que esta fase possa ser considerada concluída.
Fase de Segurança 2: Implementação correta do validador
A verificação formal prova que a implementação real do verificador zkVM (usando Rust, Solidity, etc.) corresponde ao protocolo de verificação de fase 1. Isso garante que o protocolo implementado seja razoável (não apenas um design em papel ou uma especificação ineficiente escrita em Lean, etc.).
A segunda fase concentra-se apenas na implementação do validador (e não do provador) por duas razões. Em primeiro lugar, a utilização correta do validador é suficiente para garantir a fiabilidade (ou seja, garantir que o validador não pode acreditar que qualquer afirmação falsa seja realmente verdadeira). Em segundo lugar, a implementação do validador zkVM é mais de uma ordem de magnitude mais simples do que a implementação do provador.
Fase de Segurança 3: Implementação correta do verificador
A implementação real do verificador zkVM corretamente gera provas para o sistema de prova de verificação de fase 1 e fase 2, ou seja, obtemos uma verificação formal. Isso garante integridade, o que significa que nenhum sistema que utilize zkVM será bloqueado por declarações não comprováveis. Se o verificador pretende implementar conhecimento zero, esta propriedade deve ser formalmente verificada.
Cronograma Previsto
· Progresso da Fase 1: Podemos esperar conquistas progressivas no próximo ano (por exemplo, ZKLib). No entanto, pelo menos nos próximos dois anos, não haverá nenhum zkVM que possa atender totalmente aos requisitos da Fase 1;
· Fase 2 e Fase 3: Essas fases podem avançar simultaneamente com alguns aspectos da Fase 1. Por exemplo, algumas equipes já comprovaram a implementação do validador Plonk é compatível com o protocolo no artigo (embora o próprio protocolo no artigo possa não ter sido totalmente validado). No entanto, prevejo que nenhum zkVM atingirá a Fase 3 em menos de quatro anos - e talvez ainda mais tempo.
Fiat-Shamir Segurança e bytecode verificado são pontos-chave a ter em conta
Um dos principais fatores de complexidade é a existência de questões de pesquisa não resolvidas em torno da segurança da conversão Fiat-Shamir. Todos os três estágios consideram o Fiat-Shamir e o oráculo aleatório como parte de sua segurança impenetrável, mas na realidade todo o paradigma pode ter vulnerabilidades. Isso ocorre devido à diferença entre o oráculo aleatório idealizado e as funções de hash realmente utilizadas. No pior dos casos, devido ao problema Fiat-Shamir, um sistema que tenha chegado à fase 2 pode eventualmente ser descoberto como completamente inseguro. Isso levanta sérias preocupações e requer pesquisa contínua. Pode ser necessário modificar a própria conversão para melhor prevenir tais vulnerabilidades.
Um sistema sem recursão é teoricamente mais robusto, uma vez que certos ataques conhecidos envolvem circuitos semelhantes aos utilizados em provas recursivas.
Outro ponto a notar é que, se o bytecode em si tiver defeitos, isso significa que, mesmo que o programa de computador tenha sido executado corretamente (especificado pelo bytecode), o valor ainda é limitado. Portanto, a utilidade do zkVM depende em grande parte do método de gerar bytecode de verificação formal - um desafio significativo que está além do escopo deste artigo.
Segurança na era pós-quântica
Pelo menos nos próximos cinco anos (possivelmente mais), os computadores quânticos não representarão uma ameaça séria, enquanto as vulnerabilidades são um risco para a sobrevivência. Portanto, o foco principal agora deve ser atender às fases de segurança e desempenho discutidas neste artigo. Se pudermos usar SNARK não seguros quanticamente para atender mais rapidamente a esses requisitos de segurança, então devemos fazê-lo até que SNARKs pós-quânticos alcancem ou até que as pessoas estejam seriamente preocupadas com a possibilidade de computadores quânticos relacionados à criptografia entrarem em consideração.
Estado atual do desempenho do zkVM
Atualmente, o custo gerado pelo verificador zkVM é aproximadamente 1 milhão de vezes o custo de execução nativo. Se um programa requer X ciclos para ser executado, o custo de verificação correta é aproximadamente X vezes 1 milhão de ciclos de CPU. Isso foi verdade há um ano e continua sendo verdade hoje.
Narrativas populares frequentemente descrevem essas despesas de uma forma que soa aceitável. Por exemplo:
·"O custo anual de geração de prova para a rede principal do Ethereum é inferior a um milhão de dólares."
·"Podemos quase gerar em tempo real a prova de blocos Ethereum usando um cluster composto por dezenas de GPU."
Nossa mais recente zkVM é 1000 vezes mais rápida do que sua predecessora.
Embora tecnicamente precisas, essas afirmações podem ser enganosas sem o contexto apropriado. Por exemplo:
· O zkVM anterior é 1000 vezes mais rápido, mas a velocidade absoluta ainda é muito lenta. Isso é mais uma indicação de quão ruim as coisas estão, em vez de quão boas.
· Alguém propôs aumentar em 10 vezes a quantidade de cálculos processados pela rede principal do Ethereum. Isso tornará o desempenho atual do zkVM mais lento.
A 'prova de quase em tempo real dos blocos do Ethereum' ainda é muito mais lenta do que a maioria das aplicações de blockchain exigem (por exemplo, o tempo de bloco da Optimism é de 2 segundos, muito mais rápido do que os 12 segundos do Ethereum).
·"Dezenas de GPUs em funcionamento contínuo, sem erros, não conseguem alcançar uma garantia de atividade aceitável.
· Provar que todas as atividades na rede principal do Ethereum refletem o fato de que apenas cerca de 25 dólares são necessários anualmente para um nó completo do Ethereum, custando menos de um milhão de dólares por ano.
Para aplicações fora da blockchain, esses custos são claramente excessivos. Nenhuma quantidade de paralelização ou engenharia pode compensar um custo tão grande. Devemos considerar uma abordagem em que o desempenho do zkVM seja reduzido em no máximo 100.000 vezes em relação à execução nativa - mesmo que isso seja apenas o primeiro passo. A verdadeira adoção em larga escala pode exigir custos próximos a 10.000 vezes ou menos.
Como medir o desempenho
O desempenho SNARK tem três componentes principais:
· A eficiência intrínseca do sistema de prova de participação.
· Otimização específica do aplicativo (por exemplo, pré-compilação).
· Engenharia e aceleração de hardware (por exemplo, GPU, FPGA ou CPU multi-core).
Embora ambos sejam cruciais para a implementação prática, eles geralmente se aplicam a qualquer sistema de prova, portanto, podem não refletir necessariamente os custos básicos. Por exemplo, adicionar aceleração de GPU e pré-compilação ao zkEVM pode facilmente alcançar 50 vezes mais velocidade, o que é muito mais rápido do que métodos sem pré-compilação puramente baseados em CPU - o suficiente para fazer com que um sistema essencialmente menos eficiente pareça superior a um sistema não polido da mesma forma.
Portanto, o seguinte se concentra no desempenho de SNARKs sem hardware especializado e pré-compilação. Esta situação contrasta com os atuais métodos de avaliação comparativa, que normalmente resumem os três fatores a um único «número de título». Isso equivale a julgar o valor de um diamante com base em quanto tempo ele foi polido, em vez de sua clareza intrínseca. Nosso objetivo é eliminar a sobrecarga inerente a um sistema de prova universal – para ajudar a comunidade a eliminar a confusão e se concentrar no progresso real na comprovação do projeto do sistema.
Fase de Desempenho
Aqui estão 5 marcos de desempenho atingidos. Em primeiro lugar, precisamos reduzir drasticamente os custos do verificador na CPU. Somente assim é que o foco deve mudar para reduções adicionais por meio de hardware. A utilização da memória também deve ser aumentada.
Em todas as fases abaixo, os desenvolvedores não precisam personalizar o código com base nas configurações do zkVM para atender aos requisitos de desempenho. A experiência do desenvolvedor é a principal vantagem do zkVM. Sacrificar o DevEx para atender aos benchmarks de desempenho vai contra o propósito do zkVM em si.
Esses indicadores se concentram nos custos dos provadores. No entanto, se forem permitidos custos ilimitados para os verificadores (ou seja, sem limite para o tamanho da prova ou tempo de verificação), será fácil atender a qualquer indicador do provador. Portanto, para um sistema que atenda à fase mencionada, é necessário especificar um limite máximo para o tamanho da prova e o tempo de verificação.
Requisitos de desempenho
Fase 1: "Custo de verificação razoável e não trivial":
· Tamanho da prova: O tamanho da prova deve ser menor do que o tamanho da testemunha.
· O tempo de verificação: A velocidade de verificação da prova não deve ser inferior à do programa em execução local (ou seja, executar o cálculo sem prova de correção).
Estes são os requisitos mínimos de concisão. Eles garantem que o tamanho da prova e o tempo de verificação não sejam piores do que enviar a testemunha para o verificador e permitir que o verificador verifique diretamente a sua correção.
Fase 2 e posteriores exigem:
· Tamanho máximo de prova: 256 KB.
· Tempo máximo de verificação: 16 milissegundos.
Estes limites são intencionalmente elevados para se ajustarem a novas tecnologias de prova de velocidade que possam trazer custos de verificação mais elevados. Ao mesmo tempo, eles excluem provas muito caras, o que faz com que poucos projetos estejam dispostos a incluí-las na blockchain.
Fase 1 de velocidade
A prova de um único fio deve ser pelo menos cem mil vezes mais lenta do que a execução local, medida em uma série de aplicativos (não apenas prova de blocos de Ethereum), sem depender de pré-compilação.
Especificamente, imagine executar um processo RISC-V em um laptop moderno a cerca de 30 bilhões de ciclos por segundo. Alcançar a Fase 1 significa que você pode provar cerca de 30.000 ciclos RISC-V por segundo (em um único thread) no mesmo laptop. No entanto, o custo de verificação deve ser 'razoável e não trivial', como mencionado anteriormente.
Fase 2 de velocidade
A prova de que a execução em um único thread deve ser no máximo 10.000 vezes mais lenta do que a execução local.
Ou, devido a certos métodos SNARK promissores (especialmente aqueles baseados em campos binários) serem impedidos pelas atuais CPUs e GPUs, você pode alcançar essa etapa comparando o uso de FPGA (ou mesmo ASIC):
FPGA pode simular o número de núcleos RISC-V à velocidade nativa;
Simular e provar o número de FPGA necessários para a execução (quase) em tempo real do RISC-V.
Se o último for no máximo 10.000 vezes maior que o primeiro, você está qualificado para entrar na Fase 2. Em uma CPU padrão, o tamanho da prova deve ser no máximo 256 KB e o tempo do verificador deve ser no máximo 16 milissegundos.
Etapa 3 de velocidade
Além de atingir a fase 2 de velocidade, também é possível usar uma implementação pré-compilada de síntese automática e verificação de forma para reduzir os custos de prova em menos de 1000 vezes (para aplicações amplas). Em essência, é possível personalizar dinamicamente o conjunto de instruções para cada programa a fim de acelerar a prova, mas de uma forma fácil de usar e de verificar.
Fase de Memória 1
A velocidade da Fase 1 foi alcançada com menos de 2 GB de memória necessária para o verificador (juntamente com a prova de conhecimento zero).
Isso é crucial para muitos dispositivos móveis ou navegadores, o que abre inúmeras possibilidades de uso do zkVM pelo cliente. As provas de cliente são essenciais, pois os nossos telemóveis são o nosso elo contínuo com o mundo real: rastreiam a nossa localização, credenciais, etc. Se a geração de provas requer mais de 1-2 GB de memória, isso é simplesmente demais para a maioria dos dispositivos móveis atuais. Dois pontos precisam de ser esclarecidos:
· O limite de espaço de 2 GB se aplica a declarações grandes (que requerem bilhões de ciclos de CPU para serem executadas localmente). Os sistemas de prova de limite de espaço implementados apenas para declarações pequenas carecem de ampla aplicabilidade.
Se o verificador for muito lento, é fácil manter o verificador de espaço abaixo de 2 GB de memória. Portanto, para tornar o estágio de memória 1 não trivial, exijo velocidade de estágio 1 dentro do limite de espaço de 2 GB.
Fase de memória 2
A velocidade da Fase 1 foi alcançada com menos de 200 MB de uso de memória (10 vezes melhor do que a Fase 1 de memória).
Por que reduzir para menos de 2 GB? Considere um exemplo fora da cadeia de blocos: sempre que você acessa um site via HTTPS, você baixa um certificado para autenticação e criptografia. Em vez disso, os sites podem enviar zk-SNARKs com esses certificados. Grandes sites podem gerar milhões desses SNARKs por segundo. Se cada SNARK exigir 2 GB de memória para ser gerado, seria necessário um total de RAM da ordem de PB. Reduzir ainda mais o uso de memória é crucial para implantações fora da cadeia de blocos.
Pré-Compilação: Última Milha ou Bengala?
No design zkVM, a pré-compilação refere-se a SNARKs especializados personalizados para funções específicas, como hash Keccak/SHA para assinaturas digitais ou operações de grupo de curvas elípticas. No Ethereum (onde a maioria do trabalho pesado envolve hashes de Merkle e verificações de assinatura), algumas pré-compilações feitas manualmente podem reduzir os gastos do verificador. No entanto, depender delas como muletas não permite que os SNARKs atinjam seu objetivo. As razões são as seguintes:
· Para a maioria das aplicações (tanto internas quanto externas à blockchain), ainda é demasiado lento: mesmo com a compilação prévia de hash e assinatura, o zkVM atual ainda é demasiado lento (tanto dentro como fora do ambiente da blockchain), devido à baixa eficiência do sistema de prova central.
· Falha de segurança: A pré-compilação manuscrita não oficial quase certamente está cheia de erros, o que pode levar a falhas de segurança catastróficas.
· Poor developer experience: In most zkVMs today, adding new precompiles means manually writing constraint systems for each feature - essentially reverting to a 1960s style workflow. Even with existing precompiles, developers must refactor code to call each precompile. We should optimize for security and developer experience, rather than sacrificing both for incremental performance gains. Doing so would only prove that performance has not reached its due level.
** · I / O overhead and no RAM: ** Although precompilation can improve the performance of heavy encryption tasks, they may not provide meaningful acceleration for more diverse workloads because they incur significant overhead when passing input/output and they cannot use RAM. Even in a blockchain environment, as long as you go beyond single-layer L1s like Ethereum (for example, if you want to build a series of cross-chain bridges), you will face different hash functions and signature schemes. Repeated precompilations on the issue cannot scale and pose significant security risks.
Por todas essas razões, nossa principal tarefa deve ser melhorar a eficiência do zkVM de nível inferior. A melhor tecnologia zkVM também produzirá os melhores pré-compilados. Eu realmente acredito que os pré-compilados ainda serão crucial a longo prazo, desde que sejam sintetizados automaticamente e validados formalmente. Isso manterá a vantagem da experiência dos desenvolvedores do zkVM, ao mesmo tempo em que evitará riscos de segurança catastróficos. Essa visão está refletida na fase 3 de velocidade.
Cronograma Previsto
Eu prevejo que um pequeno número de zkVMs implementará as fases de velocidade 1 e memória 1 mais tarde este ano. Acredito que também alcançaremos a fase de velocidade 2 nos próximos dois anos, mas atualmente não está claro se poderemos atingir esse objetivo sem algumas novas ideias que ainda não surgiram. Prevejo que as fases restantes (fase de velocidade 3 e fase de memória 2) levarão vários anos para serem implementadas.
Resumo
Embora eu tenha separado as fases de segurança e desempenho do zkVM neste artigo, esses aspectos do zkVM não são completamente independentes. À medida que mais vulnerabilidades forem descobertas no zkVM, espera-se que algumas só possam ser corrigidas com uma queda significativa no desempenho. O desempenho deve ser adiado até que o zkVM atinja o estágio de segurança 2.
zkVM tem o potencial de tornar as provas de conhecimento zero verdadeiramente populares, mas ainda estão numa fase inicial - cheias de desafios de segurança e enormes custos de desempenho. O sensacionalismo e a publicidade tornam difícil avaliar os verdadeiros progressos. Esperamos fornecer um roteiro claro, eliminando distrações, ao esclarecer marcos de segurança e desempenho. Alcançaremos nossos objetivos, mas isso exigirá tempo e esforço contínuo.
Link para o artigo original
：
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
a16z: Como implementar o zkVM de forma segura e eficiente em fases (um guia essencial para desenvolvedores)
O zkVM (Zero Knowledge Virtual Machine) se compromete a 'popularizar o SNARK', permitindo que qualquer pessoa (mesmo sem conhecimento especializado em SNARK) prove que executou corretamente qualquer programa em uma entrada (ou testemunho) dada. Sua principal vantagem está na experiência do desenvolvedor, mas atualmente enfrenta grandes desafios em termos de segurança e desempenho. Para que a visão do zkVM se concretize, os projetistas devem superar esses desafios. Neste artigo, listo as possíveis fases de desenvolvimento do zkVM, as quais levarão alguns anos para serem concluídas.
Desafio
Em termos de segurança, o zkVM é um projeto de software altamente complexo e ainda cheio de vulnerabilidades. Em termos de desempenho, a velocidade de provar a execução correta do programa pode ser várias centenas de milhares de vezes mais lenta do que a execução local, o que torna a maioria das aplicações atualmente impossíveis de implementar no mundo real.
Apesar destes desafios da vida real, a maioria das empresas na indústria da blockchain retrata o zkVM como algo que pode ser implementado imediatamente. De fato, alguns projetos já pagaram um custo computacional significativo para gerar provas de atividade na cadeia. No entanto, devido à incompletude do zkVM, isso é simplesmente uma forma cara de fingir que o sistema está protegido por SNARK, quando na realidade ou é protegido por permissões, ou pior ainda, é facilmente atacado.
Estamos a anos de distância de alcançar o zkVM seguro e de alto desempenho. Este artigo apresenta uma série de metas específicas em fases para rastrear o progresso do zkVM - metas que podem eliminar a especulação e ajudar a comunidade a focar no progresso real.
Fase de Segurança
Um zkVM baseado em SNARK geralmente consiste em dois componentes principais:
· Prova Interativa de Oráculo de Polinômio (PIOP): Um framework de prova interativa para afirmar sobre polinômios (ou restrições derivadas deles).
· Esquema de compromisso de polinômios (PCS): Garante que o provador não pode mentir sobre a avaliação do polinômio sem ser descoberto.
zkVM essencialmente codifica execuções eficazes como sistemas de restrições - o que significa que eles forçam a máquina virtual a usar corretamente registradores e memória - e depois aplica SNARK para provar que essas restrições são cumpridas.
A garantia de que sistemas complexos como o zkVM não têm erros é a verificação formal. Aqui estão as fases de segurança. A Fase 1 concentra-se nos protocolos corretos, enquanto a Fase 2 e a Fase 3 se concentram na implementação correta.
Fase de Segurança 1: Protocolo Correto
1、Prova formal da verificação de confiabilidade da PIOP;
2、Provas de verificação formal que são vinculativas em certas suposições criptográficas ou modelos ideais;
3、Se o protocolo Fiat-Shamir for usado, a prova formal de segurança em um modelo de previsão aleatória, obtida combinando a prova sucinta obtida por PIOP e PCS, é segura (reforçada conforme necessário por outras suposições criptográficas).
O sistema de restrições aplicado pelo PIOP é equivalente à prova de verificação formal da semântica do VM;
Aviso de Recursão: Se o zkVM usar recursão, deve-se verificar cada PIOP, compromisso e sistema de restrições envolvidos em qualquer lugar da recursão antes que esta fase possa ser considerada concluída.
Fase de Segurança 2: Implementação correta do validador
A verificação formal prova que a implementação real do verificador zkVM (usando Rust, Solidity, etc.) corresponde ao protocolo de verificação de fase 1. Isso garante que o protocolo implementado seja razoável (não apenas um design em papel ou uma especificação ineficiente escrita em Lean, etc.).
A segunda fase concentra-se apenas na implementação do validador (e não do provador) por duas razões. Em primeiro lugar, a utilização correta do validador é suficiente para garantir a fiabilidade (ou seja, garantir que o validador não pode acreditar que qualquer afirmação falsa seja realmente verdadeira). Em segundo lugar, a implementação do validador zkVM é mais de uma ordem de magnitude mais simples do que a implementação do provador.
Fase de Segurança 3: Implementação correta do verificador
A implementação real do verificador zkVM corretamente gera provas para o sistema de prova de verificação de fase 1 e fase 2, ou seja, obtemos uma verificação formal. Isso garante integridade, o que significa que nenhum sistema que utilize zkVM será bloqueado por declarações não comprováveis. Se o verificador pretende implementar conhecimento zero, esta propriedade deve ser formalmente verificada.
Cronograma Previsto
· Progresso da Fase 1: Podemos esperar conquistas progressivas no próximo ano (por exemplo, ZKLib). No entanto, pelo menos nos próximos dois anos, não haverá nenhum zkVM que possa atender totalmente aos requisitos da Fase 1;
· Fase 2 e Fase 3: Essas fases podem avançar simultaneamente com alguns aspectos da Fase 1. Por exemplo, algumas equipes já comprovaram a implementação do validador Plonk é compatível com o protocolo no artigo (embora o próprio protocolo no artigo possa não ter sido totalmente validado). No entanto, prevejo que nenhum zkVM atingirá a Fase 3 em menos de quatro anos - e talvez ainda mais tempo.
Fiat-Shamir Segurança e bytecode verificado são pontos-chave a ter em conta
Um dos principais fatores de complexidade é a existência de questões de pesquisa não resolvidas em torno da segurança da conversão Fiat-Shamir. Todos os três estágios consideram o Fiat-Shamir e o oráculo aleatório como parte de sua segurança impenetrável, mas na realidade todo o paradigma pode ter vulnerabilidades. Isso ocorre devido à diferença entre o oráculo aleatório idealizado e as funções de hash realmente utilizadas. No pior dos casos, devido ao problema Fiat-Shamir, um sistema que tenha chegado à fase 2 pode eventualmente ser descoberto como completamente inseguro. Isso levanta sérias preocupações e requer pesquisa contínua. Pode ser necessário modificar a própria conversão para melhor prevenir tais vulnerabilidades.
Um sistema sem recursão é teoricamente mais robusto, uma vez que certos ataques conhecidos envolvem circuitos semelhantes aos utilizados em provas recursivas.
Outro ponto a notar é que, se o bytecode em si tiver defeitos, isso significa que, mesmo que o programa de computador tenha sido executado corretamente (especificado pelo bytecode), o valor ainda é limitado. Portanto, a utilidade do zkVM depende em grande parte do método de gerar bytecode de verificação formal - um desafio significativo que está além do escopo deste artigo.
Segurança na era pós-quântica
Pelo menos nos próximos cinco anos (possivelmente mais), os computadores quânticos não representarão uma ameaça séria, enquanto as vulnerabilidades são um risco para a sobrevivência. Portanto, o foco principal agora deve ser atender às fases de segurança e desempenho discutidas neste artigo. Se pudermos usar SNARK não seguros quanticamente para atender mais rapidamente a esses requisitos de segurança, então devemos fazê-lo até que SNARKs pós-quânticos alcancem ou até que as pessoas estejam seriamente preocupadas com a possibilidade de computadores quânticos relacionados à criptografia entrarem em consideração.
Estado atual do desempenho do zkVM
Atualmente, o custo gerado pelo verificador zkVM é aproximadamente 1 milhão de vezes o custo de execução nativo. Se um programa requer X ciclos para ser executado, o custo de verificação correta é aproximadamente X vezes 1 milhão de ciclos de CPU. Isso foi verdade há um ano e continua sendo verdade hoje.
Narrativas populares frequentemente descrevem essas despesas de uma forma que soa aceitável. Por exemplo:
·"O custo anual de geração de prova para a rede principal do Ethereum é inferior a um milhão de dólares."
·"Podemos quase gerar em tempo real a prova de blocos Ethereum usando um cluster composto por dezenas de GPU."
Nossa mais recente zkVM é 1000 vezes mais rápida do que sua predecessora.
Embora tecnicamente precisas, essas afirmações podem ser enganosas sem o contexto apropriado. Por exemplo:
· O zkVM anterior é 1000 vezes mais rápido, mas a velocidade absoluta ainda é muito lenta. Isso é mais uma indicação de quão ruim as coisas estão, em vez de quão boas.
· Alguém propôs aumentar em 10 vezes a quantidade de cálculos processados pela rede principal do Ethereum. Isso tornará o desempenho atual do zkVM mais lento.
A 'prova de quase em tempo real dos blocos do Ethereum' ainda é muito mais lenta do que a maioria das aplicações de blockchain exigem (por exemplo, o tempo de bloco da Optimism é de 2 segundos, muito mais rápido do que os 12 segundos do Ethereum).
·"Dezenas de GPUs em funcionamento contínuo, sem erros, não conseguem alcançar uma garantia de atividade aceitável.
· Provar que todas as atividades na rede principal do Ethereum refletem o fato de que apenas cerca de 25 dólares são necessários anualmente para um nó completo do Ethereum, custando menos de um milhão de dólares por ano.
Para aplicações fora da blockchain, esses custos são claramente excessivos. Nenhuma quantidade de paralelização ou engenharia pode compensar um custo tão grande. Devemos considerar uma abordagem em que o desempenho do zkVM seja reduzido em no máximo 100.000 vezes em relação à execução nativa - mesmo que isso seja apenas o primeiro passo. A verdadeira adoção em larga escala pode exigir custos próximos a 10.000 vezes ou menos.
Como medir o desempenho
O desempenho SNARK tem três componentes principais:
· A eficiência intrínseca do sistema de prova de participação.
· Otimização específica do aplicativo (por exemplo, pré-compilação).
· Engenharia e aceleração de hardware (por exemplo, GPU, FPGA ou CPU multi-core).
Embora ambos sejam cruciais para a implementação prática, eles geralmente se aplicam a qualquer sistema de prova, portanto, podem não refletir necessariamente os custos básicos. Por exemplo, adicionar aceleração de GPU e pré-compilação ao zkEVM pode facilmente alcançar 50 vezes mais velocidade, o que é muito mais rápido do que métodos sem pré-compilação puramente baseados em CPU - o suficiente para fazer com que um sistema essencialmente menos eficiente pareça superior a um sistema não polido da mesma forma.
Portanto, o seguinte se concentra no desempenho de SNARKs sem hardware especializado e pré-compilação. Esta situação contrasta com os atuais métodos de avaliação comparativa, que normalmente resumem os três fatores a um único «número de título». Isso equivale a julgar o valor de um diamante com base em quanto tempo ele foi polido, em vez de sua clareza intrínseca. Nosso objetivo é eliminar a sobrecarga inerente a um sistema de prova universal – para ajudar a comunidade a eliminar a confusão e se concentrar no progresso real na comprovação do projeto do sistema.
Fase de Desempenho
Aqui estão 5 marcos de desempenho atingidos. Em primeiro lugar, precisamos reduzir drasticamente os custos do verificador na CPU. Somente assim é que o foco deve mudar para reduções adicionais por meio de hardware. A utilização da memória também deve ser aumentada.
Em todas as fases abaixo, os desenvolvedores não precisam personalizar o código com base nas configurações do zkVM para atender aos requisitos de desempenho. A experiência do desenvolvedor é a principal vantagem do zkVM. Sacrificar o DevEx para atender aos benchmarks de desempenho vai contra o propósito do zkVM em si.
Esses indicadores se concentram nos custos dos provadores. No entanto, se forem permitidos custos ilimitados para os verificadores (ou seja, sem limite para o tamanho da prova ou tempo de verificação), será fácil atender a qualquer indicador do provador. Portanto, para um sistema que atenda à fase mencionada, é necessário especificar um limite máximo para o tamanho da prova e o tempo de verificação.
Requisitos de desempenho
Fase 1: "Custo de verificação razoável e não trivial":
· Tamanho da prova: O tamanho da prova deve ser menor do que o tamanho da testemunha.
· O tempo de verificação: A velocidade de verificação da prova não deve ser inferior à do programa em execução local (ou seja, executar o cálculo sem prova de correção).
Estes são os requisitos mínimos de concisão. Eles garantem que o tamanho da prova e o tempo de verificação não sejam piores do que enviar a testemunha para o verificador e permitir que o verificador verifique diretamente a sua correção.
Fase 2 e posteriores exigem:
· Tamanho máximo de prova: 256 KB.
· Tempo máximo de verificação: 16 milissegundos.
Estes limites são intencionalmente elevados para se ajustarem a novas tecnologias de prova de velocidade que possam trazer custos de verificação mais elevados. Ao mesmo tempo, eles excluem provas muito caras, o que faz com que poucos projetos estejam dispostos a incluí-las na blockchain.
Fase 1 de velocidade
A prova de um único fio deve ser pelo menos cem mil vezes mais lenta do que a execução local, medida em uma série de aplicativos (não apenas prova de blocos de Ethereum), sem depender de pré-compilação.
Especificamente, imagine executar um processo RISC-V em um laptop moderno a cerca de 30 bilhões de ciclos por segundo. Alcançar a Fase 1 significa que você pode provar cerca de 30.000 ciclos RISC-V por segundo (em um único thread) no mesmo laptop. No entanto, o custo de verificação deve ser 'razoável e não trivial', como mencionado anteriormente.
Fase 2 de velocidade
A prova de que a execução em um único thread deve ser no máximo 10.000 vezes mais lenta do que a execução local.
Ou, devido a certos métodos SNARK promissores (especialmente aqueles baseados em campos binários) serem impedidos pelas atuais CPUs e GPUs, você pode alcançar essa etapa comparando o uso de FPGA (ou mesmo ASIC):
FPGA pode simular o número de núcleos RISC-V à velocidade nativa;
Simular e provar o número de FPGA necessários para a execução (quase) em tempo real do RISC-V.
Se o último for no máximo 10.000 vezes maior que o primeiro, você está qualificado para entrar na Fase 2. Em uma CPU padrão, o tamanho da prova deve ser no máximo 256 KB e o tempo do verificador deve ser no máximo 16 milissegundos.
Etapa 3 de velocidade
Além de atingir a fase 2 de velocidade, também é possível usar uma implementação pré-compilada de síntese automática e verificação de forma para reduzir os custos de prova em menos de 1000 vezes (para aplicações amplas). Em essência, é possível personalizar dinamicamente o conjunto de instruções para cada programa a fim de acelerar a prova, mas de uma forma fácil de usar e de verificar.
Fase de Memória 1
A velocidade da Fase 1 foi alcançada com menos de 2 GB de memória necessária para o verificador (juntamente com a prova de conhecimento zero).
Isso é crucial para muitos dispositivos móveis ou navegadores, o que abre inúmeras possibilidades de uso do zkVM pelo cliente. As provas de cliente são essenciais, pois os nossos telemóveis são o nosso elo contínuo com o mundo real: rastreiam a nossa localização, credenciais, etc. Se a geração de provas requer mais de 1-2 GB de memória, isso é simplesmente demais para a maioria dos dispositivos móveis atuais. Dois pontos precisam de ser esclarecidos:
· O limite de espaço de 2 GB se aplica a declarações grandes (que requerem bilhões de ciclos de CPU para serem executadas localmente). Os sistemas de prova de limite de espaço implementados apenas para declarações pequenas carecem de ampla aplicabilidade.
Se o verificador for muito lento, é fácil manter o verificador de espaço abaixo de 2 GB de memória. Portanto, para tornar o estágio de memória 1 não trivial, exijo velocidade de estágio 1 dentro do limite de espaço de 2 GB.
Fase de memória 2
A velocidade da Fase 1 foi alcançada com menos de 200 MB de uso de memória (10 vezes melhor do que a Fase 1 de memória).
Por que reduzir para menos de 2 GB? Considere um exemplo fora da cadeia de blocos: sempre que você acessa um site via HTTPS, você baixa um certificado para autenticação e criptografia. Em vez disso, os sites podem enviar zk-SNARKs com esses certificados. Grandes sites podem gerar milhões desses SNARKs por segundo. Se cada SNARK exigir 2 GB de memória para ser gerado, seria necessário um total de RAM da ordem de PB. Reduzir ainda mais o uso de memória é crucial para implantações fora da cadeia de blocos.
Pré-Compilação: Última Milha ou Bengala?
No design zkVM, a pré-compilação refere-se a SNARKs especializados personalizados para funções específicas, como hash Keccak/SHA para assinaturas digitais ou operações de grupo de curvas elípticas. No Ethereum (onde a maioria do trabalho pesado envolve hashes de Merkle e verificações de assinatura), algumas pré-compilações feitas manualmente podem reduzir os gastos do verificador. No entanto, depender delas como muletas não permite que os SNARKs atinjam seu objetivo. As razões são as seguintes:
· Para a maioria das aplicações (tanto internas quanto externas à blockchain), ainda é demasiado lento: mesmo com a compilação prévia de hash e assinatura, o zkVM atual ainda é demasiado lento (tanto dentro como fora do ambiente da blockchain), devido à baixa eficiência do sistema de prova central.
· Falha de segurança: A pré-compilação manuscrita não oficial quase certamente está cheia de erros, o que pode levar a falhas de segurança catastróficas.
· Poor developer experience: In most zkVMs today, adding new precompiles means manually writing constraint systems for each feature - essentially reverting to a 1960s style workflow. Even with existing precompiles, developers must refactor code to call each precompile. We should optimize for security and developer experience, rather than sacrificing both for incremental performance gains. Doing so would only prove that performance has not reached its due level.
** · I / O overhead and no RAM: ** Although precompilation can improve the performance of heavy encryption tasks, they may not provide meaningful acceleration for more diverse workloads because they incur significant overhead when passing input/output and they cannot use RAM. Even in a blockchain environment, as long as you go beyond single-layer L1s like Ethereum (for example, if you want to build a series of cross-chain bridges), you will face different hash functions and signature schemes. Repeated precompilations on the issue cannot scale and pose significant security risks.
Por todas essas razões, nossa principal tarefa deve ser melhorar a eficiência do zkVM de nível inferior. A melhor tecnologia zkVM também produzirá os melhores pré-compilados. Eu realmente acredito que os pré-compilados ainda serão crucial a longo prazo, desde que sejam sintetizados automaticamente e validados formalmente. Isso manterá a vantagem da experiência dos desenvolvedores do zkVM, ao mesmo tempo em que evitará riscos de segurança catastróficos. Essa visão está refletida na fase 3 de velocidade.
Cronograma Previsto
Eu prevejo que um pequeno número de zkVMs implementará as fases de velocidade 1 e memória 1 mais tarde este ano. Acredito que também alcançaremos a fase de velocidade 2 nos próximos dois anos, mas atualmente não está claro se poderemos atingir esse objetivo sem algumas novas ideias que ainda não surgiram. Prevejo que as fases restantes (fase de velocidade 3 e fase de memória 2) levarão vários anos para serem implementadas.
Resumo
Embora eu tenha separado as fases de segurança e desempenho do zkVM neste artigo, esses aspectos do zkVM não são completamente independentes. À medida que mais vulnerabilidades forem descobertas no zkVM, espera-se que algumas só possam ser corrigidas com uma queda significativa no desempenho. O desempenho deve ser adiado até que o zkVM atinja o estágio de segurança 2.
zkVM tem o potencial de tornar as provas de conhecimento zero verdadeiramente populares, mas ainda estão numa fase inicial - cheias de desafios de segurança e enormes custos de desempenho. O sensacionalismo e a publicidade tornam difícil avaliar os verdadeiros progressos. Esperamos fornecer um roteiro claro, eliminando distrações, ao esclarecer marcos de segurança e desempenho. Alcançaremos nossos objetivos, mas isso exigirá tempo e esforço contínuo.
Link para o artigo original
：