Encaminhe o título original 'A Zero Knowledge Paradigm: Part 1 - What is a zk-VM?'

1. Zero Provas de Conhecimento: Uma Cartilha

O que são provas de conhecimento zero (ZKPs)?

Se você não tem conhecimento prévio de provas de conhecimento zero (ZKP), este vídeo da Wired explica o conceito em cinco níveis de dificuldade de forma interativa com exemplos e demonstrações facilmente compreensíveis. Altamente recomendado.

Em termos mais simples, os ZKPs permitem que uma parte (provador) prove a outra parte (o verificador) que sabe algo sem revelar o que é essa coisa ou qualquer informação adicional. Mais especificamente, ZKPs provam o conhecimento de um dado, ou conhecimento do resultado de um cálculo, sem revelar os dados ou entradas. O processo de criação de uma prova de conhecimento zero envolve uma série de modelos matemáticos para transformar os resultados de um cálculo em uma peça de informação sem sentido que prova a execução bem-sucedida do código, que pode ser verificada posteriormente.

Em alguns casos, é preciso menos trabalho para verificar a prova, que é construída após várias rodadas de conversões algébricas e criptografia, do que seria necessário para executar o cálculo. Essa combinação única de segurança e escalabilidade é o que torna a criptografia de conhecimento zero uma ferramenta tão poderosa.

zkSNARKs: Conhecimento Zero Argumento não interativo sucinto do conhecimento

• Depende de um processo de configuração inicial (confiável ou não confiável) para estabelecer parâmetros para verificação
• Requer pelo menos uma interação entre provador e verificador
• Os tamanhos das provas são pequenos e fáceis de verificar
• As provas baseadas em NARK são usadas por rollups como zkSync, Scroll e Linea

zkSTARKs: Conhecimento Zero Argumento Transparente Escalável de Conhecimento

• Nenhuma configuração confiável necessária
• Oferecer alta transparência usando aleatoriedade publicamente verificável para criar sistemas verificáveis sem confiança, ou seja, gerando parâmetros comprovadamente aleatórios para provar e verificar
• Altamente escaláveis, pois podem gerar e verificar provas rapidamente (nem sempre), mesmo quando o tamanho da testemunha subjacente (dados) é grande
• Não requer interação entre provador e verificador
• Tem o custo de que os STARKs gerem provas maiores, que podem ser mais difíceis de verificar do que os SNARKs
• As provas são mais difíceis de verificar do que algumas provas zkSNARK, mas não tão difíceis de verificar como algumas outras
• STARKs são usados pela Starknet, bem como zkVMs como Lita, Risc Zero e Succinct Labs

(Nota: A ponte do Succinct usa SNARKs, mas o SP1 é um protocolo baseado em STARK)

Vale a pena notar que todos os STARKs são SNARKs, mas nem todos os SNARKs são STARKs.

Para uma melhor compreensão geral de SNARKs e STARKs, recomendamos a leitura desta @krzhang/privacy-in-cryptocurrencies-zero-knowledge-and-zk-snarks-1-2-68ce1838fd9c">série de artigos escrita por Yan Zhang e Yi Sun da Axiom, e esta coleção de artigos no github de Ventali Tan.

2. O que é um zkVM?

Uma máquina virtual (VM) é um programa que executa programas. No contexto, um zkVM é um computador virtual que é implementado como um sistema para gerar provas de conhecimento zero, ou um circuito universal, ou ferramenta, para gerar ZKPs para qualquer programa ou computação.

zkVMs eliminam a necessidade de aprender matemática e criptografia complicadas para projetar e codificar ZK, e permite que qualquer desenvolvedor execute programas escritos em suas linguagens preferidas e gere ZKPs, tornando muito mais fácil integrar e interagir com conhecimento zero. Em termos gerais, a maioria das referências a zkVMs inclui implicitamente as cadeias de ferramentas do compilador e os sistemas de prova anexados à máquina virtual que executa os programas, e não apenas à máquina virtual em si. Abaixo, resumimos os principais componentes de um zkVM e suas funções:

Os principais componentes de um zkVM

O design e a implementação de cada componente são regidos pela escolha da prova (SNARKs ou STARKs) e pela arquitetura do conjunto de instruções (ISA) do zkVM. Tradicionalmente, um ISA especifica do que uma CPU é capaz (tipos de dados, registros, memória, etc.) e a sequência de ações que a CPU executa quando executa um programa. No contexto, o ISA determina o código da máquina que é interpretável e executável pela VM. A escolha de um ISA pode produzir diferenças radicais na acessibilidade e usabilidade do zkVM, bem como na velocidade e eficiência dos processos de geração de provas, e sustenta a construção de qualquer zkVM.

Abaixo estão alguns exemplos de zkVMs e seus componentes para sua referência.

zkVMs e seus componentes

Por enquanto, vamos nos concentrar nas interações entre cada componente em um alto nível para fornecer uma estrutura para entender os processos algébricos e criptográficos, bem como as compensações de design de um zkVM em um artigo posterior.

3. Fluxo de processo zkVM abstraído

O diagrama a seguir é um fluxograma de processo abstrato, generalizado de um zkVM, dividido e categorizado entre o formato (entradas / saídas) de um programa à medida que ele se move através dos componentes de um zkVM. Examinaremos cada processo em profundidade nos artigos subsequentes.

Fluxo geral para um zkVM

O fluxo de processo de um zkVM é geralmente o seguinte:

• Estágio do compilador

1. O compilador primeiro compila programas escritos em linguagens convencionais (C, C++, Rust, Solidity) em código de máquina. O formato do código da máquina é ditado pela escolha do ISA.

• Estágio VM

1. A VM executa o código da máquina e gera um rastreamento de execução, que é a série de etapas do programa subjacente. O formato deste é predeterminado pela escolha da aritmética, bem como pelo conjunto de restrições polinomiais. Esquemas comuns de aritmização incluem R1CS como em Groth16, aritmização PLONKish como em halo2, e AIR como em plonky2 e plonky3.

• Estágio Prover

1. O provador recebe o traço e o representa como um conjunto de polinômios ligados por um conjunto de restrições, essencialmente traduzindo o cálculo em álgebra mapeando os fatos matematicamente.

2. O provador se compromete com esses polinômios usando um Esquema de Compromisso Polinomial (PCS). Um esquema de compromisso é um protocolo que permite ao provador criar uma impressão digital de alguns dados X, o que é chamado de compromisso com X, e posteriormente provar fatos sobre X sem revelar X, usando o compromisso com X. O PCS é a impressão digital; uma versão sucinta "pré-processada" das restrições no cálculo. Isso permite que o provador prove fatos sobre o cálculo, agora expressos em uma equação polinomial, usando valores aleatórios propostos pelo verificador nas etapas seguintes.

3. O provador executa um Polynomial Interactive Oracle Proof (PIOP) para mostrar que os polinômios comprometidos representam um traço de execução que satisfaz as restrições dadas. Um PIOP é um protocolo de prova interativo que consiste em uma série de rodadas em que o provador envia compromissos para polinômios, o verificador responde com valores de campo aleatórios, e o provador fornece avaliações do polinômio nesses valores aleatórios, semelhante a "resolver" a equação polinomial usando valores aleatórios para persuadir probabilisticamente o verificador.

4. Aplicação da heurística Fiat-Shamir; o provador executa o PIOP em um modo não interativo, onde o comportamento do verificador é limitado ao envio de pontos de desafio pseudoaleatórios. Em criptografia, a heurística Fiat-Shamir converte uma prova interativa de conhecimento em uma assinatura digital para verificação. Esta etapa criptografa a prova e a torna zero conhecimento.

5. O provador deve convencer o verificador de que as avaliações polinomiais alegadas estão corretas, no que diz respeito aos compromissos polinomiais que enviou ao verificador. Para fazer isso, o provador produz uma prova de "avaliação" ou "abertura", que é fornecida pelo esquema de compromisso polinomial (impressão digital).

• Estágio do verificador

1. O verificador verifica a prova seguindo o protocolo de verificação do sistema de provas, usando as restrições ou o compromisso. O verificador aceita ou rejeita o resultado de acordo com a validade da prova.

Resumidamente, uma prova zkVM prova, para um determinado programa, um dado resultado, e dadas as condições iniciais, que há alguma entrada que faz com que o programa produza o resultado dado quando executado a partir das condições iniciais dadas. Podemos combinar essa instrução com o fluxo do processo para chegar à seguinte descrição de um zkVM.

Uma prova zkVM prova, para um determinado programa VM e uma determinada saída, que há alguma entrada que faz com que o programa dado produza a saída dada quando executado na VM.

4. Avaliando zkVMs

Quais são os critérios pelos quais devemos avaliar zkVMs? Em outras palavras, quando devemos dizer que um zkVM é melhor do que outro? Na verdade, a resposta depende do caso de uso.

A pesquisa de mercado da Lita sugere que, para a maioria dos casos de uso comercial, as propriedades mais importantes, fora de velocidade, eficiência e sucintidade, são velocidade ou eficiência de tempo central, dependendo da aplicação. Algumas aplicações são sensíveis ao preço e querem otimizar para baixo consumo de energia e baixo uso de capital na prova; Para estes, a eficiência do tempo central é provavelmente a métrica mais importante a ser otimizada. Outras aplicações, particularmente aplicações relacionadas com finanças ou negociação, são sensíveis à latência e querem otimizar para velocidade.

A maioria das comparações de desempenho divulgadas concentra-se exclusivamente na velocidade, que é importante, mas não uma medição holística do desempenho. Há também algumas propriedades importantes que medem a confiabilidade de um zkVM; a maioria dos quais não está à altura das normas de produção pronta, mesmo para os operadores históricos líderes de mercado.

Propomos que as zkVMs sejam avaliadas com base nos seguintes critérios, separados em dois subconjuntos:

Principais critérios para avaliar zk-VMs

Linha de base: mede a confiabilidade de zkVMs

• Correção
• Segurança
• Pressupostos de confiança

Desempenho: mede os recursos de um zkVM

• Eficiência
• Velocidade
• Sucinta

4.1 Linha de base: pressupostos de correção, segurança e confiança

Ao avaliar zkVMs para aplicações de missão crítica, a correção e a segurança devem ser consideradas como a linha de base. Tem de haver razões suficientes para estar confiante na correção e numa segurança reivindicada suficientemente forte. Além disso, os pressupostos de confiança têm de ser suficientemente fracos para a aplicação.

Sem essas propriedades, o zkVM é potencialmente pior do que inútil para o aplicativo, pois pode falhar no desempenho especificado e expor os usuários a hackers e exploits.

i. Correção

• A VM deve executar o cálculo conforme pretendido
• O sistema de prova deve satisfazer as suas propriedades de segurança alegadas

A correção é composta por três propriedades:

• Solidez: O sistema de prova é verdadeiro e, portanto, tudo o que prova é verdade. O verificador rejeita provas de declarações falsas; só aceita o resultado de um cálculo se os inputs produzirem efetivamente esse resultado.
• Exaustividade: O sistema de prova é completo e pode provar todas as afirmações verdadeiras. Se o provador alegar que pode provar o resultado de um cálculo, deve ser capaz de produzir uma prova que o verificador aceita.
• Conhecimento Zero: Possuir uma prova não revela mais sobre as entradas do cálculo do que saber o resultado em si

Você pode ter completude sem solidez; Se o sistema de prova prova tudo, incluindo falsidade, obviamente é completo, mas não sólido. Inversamente, você pode ter solidez sem completude; Se o sistema de prova prova que um programa existiu mas não consegue provar os cálculos, obviamente que é sólido (afinal, nunca prova qualquer falsidade), mas não completo.

ii. Segurança

• Relaciona-se com as tolerâncias de solidez, completude e conhecimento zero

Na prática, todas as três propriedades de correção têm tolerâncias diferentes de zero. Isso implica que todas as provas são probabilidades estatísticas de correção, e não certezas absolutas. Uma tolerância refere-se à probabilidade máxima tolerável de que uma propriedade irá falhar. As tolerâncias zero são, obviamente, o ideal, mas as zkVMs não atingem tolerâncias zero em todas essas propriedades na prática. A perfeita solidez e completude parecem ser incompatíveis com a sucinta, e não há métodos conhecidos para alcançar o conhecimento zero perfeito. Uma maneira comum de medir a segurança é em bits de segurança, onde uma tolerância de 1 / (2^n) é referida como n bits de segurança. Mais bits de segurança é melhor.

Se um zkVM estiver perfeitamente correto, isso não implica necessariamente que ele seja confiável. A correção implica apenas que o zkVM satisfaz suas propriedades de segurança até as tolerâncias reivindicadas. Tal não implica que as tolerâncias alegadas sejam suficientemente baixas para estarem prontas para o mercado. Além disso, se um zkVM é suficientemente seguro, isso não implica que ele esteja correto; A segurança refere-se às tolerâncias reivindicadas, não às tolerâncias que são efetivamente alcançadas. Somente quando um zkVM é perfeitamente correto e suficientemente seguro pode-se dizer que o zkVM é confiável até as tolerâncias alegadas.

iii. Pressupostos de confiança

• Suposições sobre a honestidade do provador e verificador para chegar à conclusão de que o zkVM funciona de forma confiável

Quando zkVMs têm suposições de confiança, isso geralmente assume a forma de um processo de configuração confiável. Um processo de configuração para um sistema de prova ZK é executado uma vez, antes que a primeira prova seja gerada usando o sistema de prova, a fim de gerar algumas informações chamadas "os dados de configuração". Em um processo de configuração confiável, um ou mais indivíduos geram alguma aleatoriedade que é incorporada aos dados de configuração, e é preciso presumir que pelo menos um desses indivíduos excluiu a aleatoriedade que incorporaram nos dados de configuração.

Na prática, existem dois modelos comuns de presunção de confiança.

Uma suposição de confiança da maioria honesta afirma que, de algum conjunto de N indivíduos, mais de N/2 desses indivíduos exibiram integridade em algumas interações particulares com o sistema, que é comumente usado por blockchains

Uma suposição de confiança "1 de N" afirma que, de algum conjunto de N indivíduos, pelo menos um desses indivíduos exibiu integridade em algumas interações particulares com o sistema, que é comumente usado por ferramentas e aplicativos baseados em MPC.

É geralmente aceite que, sendo tudo o resto igual, os zkVMs sem pressupostos de confiança são mais seguros do que os zkVMs que requerem pressupostos de confiança.

4.2 O Trilema zkVM: Equilibrando velocidade, eficiência e sucinta em zkVMs

O trilema zkVM: velocidade, eficiência e sucinta

Velocidade, eficiência e sucintidade são propriedades de escala deslizante. Todos esses fatores contribuem para o custo do zkVM para o usuário final. A forma como devem ser ponderados numa avaliação depende da aplicação. Muitas vezes, a solução mais rápida não é a mais eficiente ou a mais sucinta; a solução mais sucinta não é a mais rápida nem a mais eficiente; e assim por diante. Vamos primeiro definir cada propriedade antes de explicar a sua relação

i. Velocidade

• Com que rapidez o provador pode gerar provas
• Medido em tempo de relógio de parede, que é o tempo decorrido do início ao fim da computação

A velocidade deve ser definida e medida em relação a programas, entradas e sistemas de teste específicos para garantir que possa ser avaliada quantitativamente. Essa métrica é crítica para aplicativos sensíveis à latência, onde a disponibilidade imediata de provas é essencial, mas vem com maior sobrecarga e tamanhos de prova maiores

ii. Eficiência

• Os recursos consumidos pelo provador, sendo preferível menos
• Pode ser aproximado pelo tempo do usuário, que é a quantidade de tempo do computador gasto pelo código do programa

O provador consome dois tipos de recursos: tempo central e espaço. A eficiência pode, portanto, ser subdividida em eficiência de tempo central e eficiência de espaço.\

Eficiência de tempo de núcleo: quantidade média de tempo que o provador opera em todos os núcleos multiplicado pelo número de núcleos executando o provador. Para um provador single-core, o consumo de tempo central e a velocidade são a mesma coisa. Para um provador com capacidade multi-core rodando no modo multi-core em um sistema multi-core, o consumo de tempo de núcleo e a velocidade não são a mesma coisa. Se um programa utiliza totalmente 5 núcleos ou threads por 5 segundos, isso seria 25 segundos de tempo do usuário e 5 segundos de tempo de relógio de parede.

Eficiência de espaço: refere-se à capacidade de armazenamento utilizada, como RAM

O tempo do usuário é interessante como um proxy para a energia consumida pela execução de um cálculo. Em uma situação em que todos os núcleos são totalmente utilizados quase o tempo todo, o consumo de energia de uma CPU deve permanecer relativamente constante. Nessa situação, o tempo gasto pelo usuário por uma execução de código vinculada à CPU, predominantemente no modo do usuário, deve ser aproximadamente linearmente proporcional ao número de watts-hora (ou seja, energia) consumidos por essa execução de código.

Economizar no consumo de energia, ou o uso de recursos de computação, deve ser interessante do ponto de vista de quaisquer operações de comprovação que tenham escala suficiente para que sua conta de energia (ou sua conta de computação em nuvem) para provar seja um custo operacional considerável. Por esses motivos, o tempo do usuário é uma métrica interessante. Custos de comprovação mais baixos permitem que os prestadores de serviços repassem preços de comprovação mais baixos para clientes sensíveis aos custos.

Ambos os tipos de eficiência estão relacionados com o consumo de energia do processo de prova e a quantidade de capital utilizado pelo processo de prova, que se relaciona com o custo financeiro da prova. Para operacionalizar a definição de eficiência para medição, a definição deve ser feita em relação a um ou mais programas de teste, uma ou mais entradas de teste para cada um desses programas e um ou mais sistemas de teste.

iii. Sucinta

• O tamanho das provas geradas e a complexidade de verificá-las

A sucinta é um composto de três métricas distintas, com a complexidade da verificação da prova ainda mais subdividida:

• Tamanho da prova: O tamanho físico das provas, normalmente medido em kilobytes
• Tempo de verificação da prova: Duração necessária para verificar as provas.
• Espaço de verificação de prova: uso de memória durante a verificação de prova

A verificação é tipicamente uma operação de núcleo único, portanto, a velocidade e a eficiência do tempo central são geralmente equivalentes neste contexto. Tal como acontece com a velocidade e a eficiência, operacionalizar a definição de sucintidade requer a especificação de conjuntos de programas de teste, entradas de teste e sistemas de teste.

Com cada propriedade de desempenho definida, agora ilustramos os efeitos dimunitivos da otimização de uma propriedade sobre as outras.

• Velocidade: A geração rápida de provas leva a tamanhos de prova maiores, mas a verificação de provas é lenta. Mais recursos são consumidos para gerar provas, o que reduz a eficiência
• Sucinta: Prover precisa de mais tempo para comprimir provas. Mas a verificação da prova é rápida. Quanto mais sucinta for a prova, maior será a sobrecarga de cálculo
• Eficiência: Minimizar o uso de recursos reduz a velocidade de geração de provas e a sucinta das provas

Em geral, otimizar para uma qualidade significa não otimizar para outra qualidade e, portanto, uma análise multidimensional é necessária para escolher uma solução ideal caso a caso.

Uma boa maneira de ponderar essas propriedades em uma avaliação pode ser definir níveis aceitáveis para cada propriedade e, em seguida, determinar quais propriedades são mais importantes. As propriedades mais importantes devem ser otimizadas, sujeitas à manutenção de níveis bons o suficiente em todas as outras propriedades.

Abaixo resumimos cada propriedade e suas principais considerações:

Propriedades de avaliação de zkVMs

5. O que vem a seguir?

Com a tabela acima, concluímos o primeiro artigo da nossa série. Nos próximos artigos, vamos nos basear no fluxograma mostrado acima para explicar processos aritméticos e criptográficos comuns em zkVMs.

Se você achou isso útil, visite nosso site e gitbook para saber mais sobre o que estamos construindo na Lita.

Além disso, siga-nos no X e no Discord para se manter atualizado para não perder o resto da série

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir de [lita]. Encaminhe o título original 'A Zero Knowledge Paradigm: Part 1 - What is a zk-VM?'. Todos os direitos autorais pertencem ao autor original [Lita Team]. Se houver objeções a essa reimpressão, entre em contato com a equipe do Gate Learn e eles lidarão com isso imediatamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.