Encaminhe o título original 'Um paradigma de conhecimento zero: Parte 1 - O que é um zk-VM?'

1. Provas de Conhecimento Zero: 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 pedaço de dados, ou conhecimento do resultado de uma computação, 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 uma computação em um pedaço 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 a computação. 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 Sucinto Argumento Não Interativo 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 pacotes cumulativos como zkSync, Scroll e Linea

zkSTARKs: Conhecimento Zero Escalável Argumento Transparente 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
• Vem ao custo de que os STARKs gerem provas maiores, o que pode ser mais difícil 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 quanto algumas outras de verificar
• Os 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 série de artigos @krzhang/privacy-in-cryptocurrencies-zero-knowledge-and-zk-snarks-1-2-68ce1838fd9c>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 complicada e criptografia 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 linhas 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 a máquina virtual em si. Abaixo, resumimos os principais componentes de uma zkVM e suas funções:

Os principais componentes de uma zkVM

O projeto 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 de fazer (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 de máquina que é interpretável e executável pela VM. A escolha de um ISA pode gerar diferenças radicais na acessibilidade e usabilidade do zkVM, bem como na velocidade e eficiência dos processos de geração de prova, 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 generalizado abstrato 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 próximos artigos.

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 da 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 disso é predeterminado pela escolha da aritmética, bem como pelo conjunto de restrições polinomiais. Esquemas comuns de aritmética 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 a computação 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, que é chamado de compromisso com X, e depois 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 na computação. 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 campos 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. Na criptografia, a heurística Fiat-Shamir converte uma prova interativa de conhecimento em uma assinatura digital para verificação. Essa 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 prova, 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 determinado 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 dada 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 da velocidade, eficiência e sucintidade, são velocidade ou eficiência em tempo de núcleo, 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 de núcleo é provavelmente a métrica mais importante para otimizar. Outros aplicativos, particularmente aplicativos relacionados a finanças ou negociação, são sensíveis à latência e desejam otimizar a velocidade.

A maioria das comparações de desempenho divulgadas se concentra exclusivamente na velocidade, que é importante, mas não uma medida holística de desempenho. Há também algumas propriedades importantes que medem a confiabilidade de um zkVM; a maioria dos quais não está à altura dos padrões de produção, mesmo para os principais operadores históricos do 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

• Exatidão
• Segurança
• Suposições de confiança

Desempenho: Mede os recursos de um zkVM

• Eficiência
• Velocidade
• Succinctness

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

Ao avaliar zkVMs para aplicativos de missão crítica, a correção e a segurança devem ser consideradas como a linha de base. É necessário que haja razões suficientes para confiar na correcção e numa segurança suficientemente forte. Além disso, as suposições de confiança precisam ser suficientemente fracas para o aplicativo.

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 hacking e exploits.

i. Correção

• A VM deve executar a computação conforme pretendido
• O sistema de prova deve satisfazer as suas propriedades de segurança reivindicadas

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

• Solidez: O sistema de prova é verdadeiro e, portanto, tudo o que ele prova é verdade. O verificador rejeita provas de declarações falsas; ele só aceita o resultado de uma computação se as entradas realmente produzirem esse resultado.
• Completude: O sistema de prova é completo e pode provar todas as afirmações verdadeiras. Se o provador afirma que pode provar o resultado de um cálculo, ele deve ser capaz de produzir uma prova que o verificador aceita.
• Conhecimento Zero: Possuir uma prova não revela mais sobre as entradas da computação 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 ele é sólido (afinal, ele nunca prova nenhuma 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 falhe. Tolerâncias zero são, naturalmente, o ideal, mas zkVMs não atingem tolerâncias zero em todas essas propriedades na prática. A solidez e a completude perfeitas parecem ser incompatíveis com a sucintura, 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 está perfeitamente correto, isso não implica necessariamente que ele é confiável. A correção implica apenas que o zkVM satisfaz suas propriedades de segurança até as tolerâncias reivindicadas. Isso não implica que as tolerâncias alegadas sejam baixas o suficiente para estarem prontas para o mercado. Além disso, se um zkVM é suficientemente seguro, isso não implica que ele esteja correto; segurança refere-se às tolerâncias reivindicadas, não as tolerâncias que são realmente alcançadas. Somente quando uma zkVM é perfeitamente correta e suficientemente segura é que se pode dizer que a zkVM é confiável até as tolerâncias reivindicadas.

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 instalaçã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 assumir que pelo menos um desses indivíduos excluiu a aleatoriedade que eles incorporaram aos dados de configuração.

Existem dois modelos comuns de pressuposto de confiança na prática.

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 alguma interação particular com o sistema, que é comumente usado por blockchains

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

É geralmente aceito que todo o resto sendo igual, zkVMs sem suposições de confiança são mais seguros do que zkVMs que exigem suposições de confiança.

4.2 O Trilema do zkVM: Equilibrando Velocidade, Eficiência e Sucintura em zkVMs

O trilema zkVM: velocidade, eficiência e sucintura

Velocidade, eficiência e sucintura são propriedades de escala deslizante. Todos esses fatores contribuem para o custo do usuário final do zkVM. Como eles devem ser ponderados em uma 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 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, com menos sendo preferível
• 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: núcleo-tempo e espaço. A eficiência pode, portanto, ser subdividida em eficiência de tempo de núcleo e eficiência de espaço.\

Eficiência do Core-Time: Quantidade média de tempo que o provador opera em todos os núcleos multiplicado pelo número de núcleos que executam o provador. Para um provador single-core, o consumo de tempo de núcleo 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 utilizar 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 usada, como RAM

O tempo do usuário é interessante como um proxy para a energia consumida pela execução de uma computação. 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 do usuário gasto por uma execução de código vinculada à CPU, predominantemente no modo de 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 no uso de recursos computacionais, 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 comprovação seja um custo operacional considerável. Por esses motivos, o tempo do usuário é uma métrica interessante. Os custos mais baixos de comprovação permitem que os prestadores de serviços repassem preços de prova mais baixos para clientes sensíveis aos custos.

Ambos os tipos de eficiência estão relacionados ao consumo de energia do processo de prova e à 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 é uma composição de três métricas distintas, com a complexidade da verificação de provas subdividida:

• Tamanho da prova: O tamanho físico das provas, normalmente medido em quilobytes
• 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 de núcleo são geralmente equivalentes neste contexto. Assim como a velocidade e a eficiência, operacionalizar a definição de sucção requer a especificação de conjuntos de programas de teste, entradas de teste e sistemas de teste.

Com cada propriedade de desempenho definida, ilustramos agora 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 prova é lenta. Mais recursos são consumidos para gerar provas, o que reduz a eficiência
• Sucinta: O provador precisa de mais tempo para comprimir provas. Mas a verificação da prova é rápida. Quanto mais sucinta a prova, maior a sobrecarga de cálculo
• Eficiência: Minimizar o uso de recursos reduz a velocidade de geração da prova e a sucinta da prova

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 a manter níveis suficientemente bons em todas as outras propriedades.

Abaixo resumimos cada imóvel 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 de nossa série. Nos próximos artigos, construiremos o 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 ficar atualizado para não perder o resto da série

Disclaimer:

1. Este artigo foi reproduzido de [lita]. Encaminhe o título original 'Um paradigma de conhecimento zero: Parte 1 - O que é um 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 prontamente.
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.