Gostaríamos de agradecer à equipe Polygon Zero, ao projeto Consensys gnark, ao Pado Labs e à equipe Delphinus Lab por seus valiosos comentários e feedback sobre este artigo.
Gastamos muito tempo e esforço nos últimos meses desenvolvendo infraestrutura de ponta construída com provas concisas do zk-SNARK. Esta plataforma de inovação de próxima geração permite que os desenvolvedores construam novos paradigmas sem precedentes de aplicações blockchain.
Durante nosso trabalho de desenvolvimento, testamos e usamos diversas estruturas de desenvolvimento à prova de conhecimento zero (ZKP). Embora esta jornada tenha sido gratificante, percebemos que a variedade de estruturas ZKP muitas vezes cria desafios para novos desenvolvedores enquanto eles tentam encontrar aquela que melhor se adapta aos seus casos de uso e requisitos de desempenho específicos. Com esse ponto problemático em mente, acreditamos que há necessidade de uma plataforma de avaliação da comunidade que possa fornecer resultados abrangentes de testes de desempenho, o que facilitará muito o desenvolvimento desses novos aplicativos.
Para atender a essa necessidade, lançamos a iniciativa comunitária de bem-estar público "Patheon", uma plataforma de avaliação de estrutura de desenvolvimento à prova de conhecimento zero. O primeiro passo da iniciativa será incentivar a comunidade a compartilhar resultados de testes de desempenho reproduzíveis de várias estruturas ZKP. Nosso objetivo final é colaborar para criar e manter um ambiente de testes amplamente reconhecido para avaliar estruturas de desenvolvimento de circuitos de baixo nível, zkVMs e compiladores de alto nível e até mesmo provedores de aceleração de hardware. Esperamos que essa mudança forneça aos desenvolvedores mais referências para comparação de desempenho ao escolher uma estrutura, acelerando assim a promoção do ZKP. Ao mesmo tempo, esperamos promover a atualização e a iteração da própria estrutura do ZKP, fornecendo um conjunto de resultados de testes de desempenho geralmente referenciáveis. Investiremos pesadamente nessa iniciativa e convidaremos todos os membros da comunidade com ideias semelhantes a se juntarem a nós e contribuírem com esse esforço!
Etapa 1: Teste de desempenho da estrutura do circuito usando SHA-256
Nesta postagem, damos os primeiros passos para construir o ZKP Patheon fornecendo um conjunto de resultados de testes de desempenho reproduzíveis usando SHA-256 em uma série de estruturas de desenvolvimento de circuitos de baixo nível. Embora reconheçamos que outras granularidades e primitivas de testes de desempenho podem ser viáveis, escolhemos o SHA-256 devido à sua aplicabilidade a uma ampla gama de casos de uso do ZKP, incluindo sistemas de blockchain, assinaturas digitais, zkDIDs, etc. Também vale a pena mencionar que usamos SHA-256 em nossos próprios sistemas, então isso é útil para nós também! 😂
Nosso benchmark avalia o desempenho do SHA-256 em várias estruturas de desenvolvimento de circuitos zk-SNARK e zk-STARK. Por meio dessa comparação, buscamos fornecer aos desenvolvedores insights sobre a eficiência e praticidade de cada estrutura. Nosso objetivo é que essas descobertas permitam que os desenvolvedores tomem decisões informadas ao selecionar a estrutura mais adequada para seus projetos.
Nossos testes de desempenho avaliam o desempenho do SHA-256 em várias estruturas de desenvolvimento de circuitos zk-SNARK e zk-STARK. Por meio dessa comparação, buscamos fornecer aos desenvolvedores insights sobre a eficiência e a utilidade de cada estrutura. Nosso objetivo é fornecer aos desenvolvedores uma referência para escolher o melhor framework, para que eles possam tomar uma decisão informada.
Sistema de Prova
Nos últimos anos, observamos um aumento nos sistemas de prova de conhecimento zero. Acompanhar todos os avanços interessantes neste espaço pode ser desafiador, e selecionamos cuidadosamente os seguintes sistemas de prova para testes com base na maturidade e adoção do desenvolvedor. Nosso objetivo é fornecer uma amostra representativa de diferentes combinações de frontend/backend.
Circom + snarkjs / rapidsnark: Circom é uma DSL popular para escrever circuitos e gerar restrições R1CS, enquanto snarkjs pode gerar provas Groth16 ou Plonk para Circom. Rapidsnark também é o provador da Circom, ele gera provas Groth16 e é geralmente muito mais rápido que o snarkjs devido ao uso da extensão ADX e paraleliza a geração de provas tanto quanto possível.
gnark: gnark é um framework Golang abrangente da Consensys que suporta Groth16, Plonk e muitos outros recursos avançados.
Arkworks: Arkworks é um framework Rust abrangente para zk-SNARKs.
Halo2 (KZG): Halo2 é uma implementação zk-SNARK do Zcash e do Plonk. Ele vem com aritmética Plonkish altamente flexível e suporta muitos primitivos úteis, como gateways personalizados e tabelas de pesquisa. Usamos o fork Halo2 da KZG com suporte da Ethereum Foundation e Scroll.
Plonky2: Plonky2 é uma implementação SNARK baseada na tecnologia PLONK e FRI da Polygon Zero. O Plonky2 usa pequenos campos Goldilocks e suporta recursão eficiente. Em nossos testes de desempenho, visamos 100 bits de segurança de especulação e usamos os parâmetros que produzem o melhor tempo de prova para o esforço de teste de desempenho. Especificamente, usamos 28 consultas Merkle, um fator de amplificação de 8 e um desafio de prova de trabalho de 16 bits. Além disso, definimos num_of_wires = 60 e num_routed_wires = 60.
Starky: Starky é o framework STARK de alto desempenho do Polygon Zero. Em nossos testes de desempenho, visamos 100 bits de segurança de especulação e usamos os parâmetros que produzem o melhor tempo de prova. Especificamente, usamos 90 consultas Merkle, um fator de amplificação de 2x e um desafio de prova de trabalho de 10 bits.
A tabela a seguir resume as estruturas acima e as configurações associadas usadas em nossos testes de desempenho. Esta lista não é de forma alguma exaustiva, e também investigaremos muitas estruturas/técnicas de última geração no futuro (por exemplo, Nova, GKR, Hyperplonk).
Observe que esses resultados de testes de desempenho se aplicam apenas à estrutura de desenvolvimento de circuitos. Planejamos publicar um artigo separado no futuro para realizar testes de desempenho em diferentes zkVMs (por exemplo, Scroll, Polygon zkEVM, Consensys zkEVM, zkSync, Risc Zero, zkWasm) e estruturas de compilador IR (por exemplo, Noir, zkLLVM).
quadro
Aritmética
algoritmo
Intervalo numérico
Outra configuração
Circom + snarkjs / rapidsnark
R1CS
Groth16
Escalar BN254
retorcido
R1CS
Groth16
Escalar BN254
Obras de Arca
R1CS
Groth16
Escalar BN254
Halo2 (KZG)
Plonkish
KZG
Escalar BN254
Plonky2
Plonk
SEX
Cachinhos Dourados
fator de explosão = 8
bits de prova de trabalho = 16
rodadas de consulta = 28
num_de_fios = 60 num_fios_roteados = 60
Stark-Os-Antigos
AR
SEX
Cachinhos Dourados
fator de explosão = 2
bits de prova de trabalho = 10
rodadas de consulta = 90
Metodologia de Avaliação de Desempenho
Para realizar testes de desempenho nesses diferentes sistemas de prova, calculamos o hash SHA-256 de N bytes de dados, onde experimentamos N = 64, 128, ..., 64K (Starky é uma exceção onde o circuito repete o cálculo SHA-256 para uma entrada fixa de 64 bytes, mas mantém o mesmo número total de blocos de mensagens). O código de desempenho e a configuração do circuito SHA-256 podem ser encontrados neste repositório.
Além disso, realizamos testes de desempenho em cada sistema usando as seguintes métricas de desempenho:
Tempo de geração de prova (incluindo tempo de geração de testemunha)
O uso da memória atinge o pico durante a geração de provas
Porcentagem média de uso da CPU durante a geração de atestado. (Esta métrica reflete o grau de paralelização no processo de geração de provas)
Observe que estamos fazendo algumas suposições “arbitrárias” sobre o tamanho da prova e os custos de verificação da prova, pois esses aspectos podem ser mitigados pela combinação com Groth16 ou KZG antes da cadeia.
máquina
Realizamos testes de desempenho em duas máquinas diferentes:
Servidor Linux: 20 núcleos a 2,3 GHz, 384 GB de RAM
Macbook M1 Pro: 10 núcleos a 3,2 GHz, 16 GB de RAM
O servidor Linux é usado para simular o cenário com muitos núcleos de CPU e memória suficiente. O Macbook M1 Pro, normalmente usado para pesquisa e desenvolvimento, tem uma CPU mais potente, mas menos núcleos.
Habilitamos o multithreading opcional, mas não usamos aceleração de GPU neste teste de desempenho. Planejamos realizar testes de desempenho de GPU no futuro.
Resultados do teste de desempenho
Quantidade de restrição
Antes de passarmos para os resultados detalhados dos testes de desempenho, é útil primeiro entender a complexidade do SHA-256 observando o número de restrições em cada sistema de prova. É importante observar que o número de restrições em diferentes esquemas aritméticos não pode ser comparado diretamente.
Os resultados abaixo correspondem a um tamanho de pré-imagem de 64 KB. Embora os resultados possam variar para outros tamanhos de pré-imagem, eles são dimensionados de forma aproximadamente linear.
Circom, gnark e Arkworks usam o mesmo algoritmo R1CS, e o número de restrições R1CS para calcular SHA-256 de 64 KB fica aproximadamente entre 30M e 45M. As diferenças entre Circom, gnark e Arkworks podem ser devido a diferenças de configuração.
Tanto o Halo2 quanto o Plonky2 usam aritmética Plonkish, onde o número de linhas varia de 2^22 a 2^23. A implementação SHA-256 do Halo2 é muito mais eficiente que a do Plonky2 devido ao uso de uma tabela de consulta.
Starky usa o algoritmo AIR, onde a execução da tabela de rastreamento requer 2^16 etapas de transformação.
Sistema de Prova
Quantidade de restrição (64 KB SHA-256)
Circo
32M
retorcido
45 milhões
Obras de Arca
43 milhões
Halo 2
4M linhas (K=22)
Plonky2
8M linhas (K=23)
Stark-Os-Antigos
2^16 etapas de transição
Tempo de geração de prova
[Figura 1] O tempo de geração de prova para cada estrutura para SHA-256 em vários tamanhos de imagem original foi testado usando um servidor Linux. Podemos obter as seguintes descobertas:
Para SHA-256, as estruturas Groth16 (rapidsnark, gnark e Arkworks) geram provas mais rapidamente do que as estruturas Plonk (Halo2 e Plonky2). Isso ocorre porque o SHA-256 consiste principalmente em operações de bits, onde o valor linear é 0 ou 1. Para Groth16, isso reduz a maior parte da computação da multiplicação escalar da curva elíptica para a adição de pontos da curva elíptica. No entanto, os valores dos fios não são usados diretamente nos cálculos do Plonk, portanto, a estrutura especial dos fios no SHA-256 não reduz a quantidade de computação necessária na estrutura do Plonk.
Entre todos os frameworks Groth16, gnark e rapidsnark são de 5 a 10 vezes mais rápidos que Arkworks e snarkjs. Isso se deve à sua notável capacidade de paralelizar a geração de provas usando múltiplos núcleos. Gnark é 25% mais rápido que rapidsnark.
Para a estrutura Plonk, o SHA-256 do Plonky2 é 50% mais lento que o do Halo2 ao usar tamanhos de pré-imagem maiores >= 4 KB. Isso ocorre porque a implementação do Halo2 usa principalmente tabelas de pesquisa para acelerar operações bit a bit, resultando em 2 vezes menos linhas que o Plonky2. Entretanto, se compararmos Plonky2 e Halo2 com o mesmo número de linhas (por exemplo, mais de 2 KB de SHA-256 em Halo2 vs. mais de 4 KB de SHA-256 em Plonky2), Plonky2 é 50% mais rápido que Halo2. Se implementarmos SHA-256 usando uma tabela de consulta no Plonky2, devemos esperar que o Plonky2 seja mais rápido que o Halo2, apesar do tamanho de prova maior do Plonky2.
Por outro lado, quando o tamanho da pré-imagem de entrada é pequeno (<=512 bytes), o Halo2 é mais lento que o Plonky2 (e outras estruturas) devido ao custo fixo de configuração da tabela de consulta que domina a restrição. No entanto, à medida que o tamanho da pré-imagem aumenta, o desempenho do Halo2 se torna mais competitivo, com seu tempo de geração de prova permanecendo constante para tamanhos de pré-imagem de até 2 KB, escalando quase linearmente, conforme mostrado na figura.
Como esperado, o tempo de geração de prova do Starky é muito menor (5x-50x) do que qualquer framework SNARK, mas isso ocorre às custas de um tamanho de prova maior.
Observe também que, embora o tamanho do circuito seja dimensionado linearmente com o tamanho da pré-imagem, a geração de provas para SNARKs é dimensionada superlinearmente devido à FFT O(nlogn) (embora isso não seja óbvio no gráfico devido à escala logarítmica).
Também realizamos testes de desempenho de tempo de geração de prova em um Macbook M1 Pro, conforme mostrado na [Figura 2]. Entretanto, é importante ressaltar que o rapidsnark não foi incluído neste teste de desempenho devido à falta de suporte à arquitetura arm64. Para usar o snarkjs no arm64, tivemos que gerar a testemunha usando webassembly, que é mais lento que a geração de testemunhas em C++ usada no servidor Linux.
Algumas observações adicionais ao executar testes de desempenho no Macbook M1 Pro:
Com exceção do Starky, todas as estruturas SNARK sofrem com erros de falta de memória (OOM) ou usam memória swap (resultando em tempos de prova mais lentos) quando o tamanho da pré-imagem aumenta. Especificamente, as estruturas Groth16 (snarkjs, gnark, Arkworks) começam a usar memória swap quando o tamanho da pré-imagem é >= 8 KB, e o gnark fica sem memória quando o tamanho da pré-imagem é >= 64 KB. O Halo2 atinge os limites de memória quando o tamanho da pré-imagem é >= 32 KB. Quando o tamanho da pré-imagem é >= 8 KB, o Plonky2 começa a usar a memória swap.
As estruturas baseadas em FRI (Starky e Plonky2) são cerca de 60% mais rápidas no Macbook M1 Pro do que no servidor Linux, enquanto as outras estruturas têm tempos de demonstração semelhantes em ambas as máquinas. Portanto, embora nenhuma tabela de pesquisa seja usada no Plonky2, ele atinge quase o mesmo tempo de prova que o Halo2 em um Macbook M1 Pro. O principal motivo é que o Macbook M1 Pro tem uma CPU mais potente, mas com menos núcleos. O FRI executa principalmente operações de hash e é sensível aos ciclos de clock da CPU, mas seu paralelismo não é tão bom quanto o do KZG ou do Groth16.
Pico de uso de memória
[Figura 3] e [Figura 4] mostram o pico de uso de memória durante a geração de atestado no Linux Server e no Macbook M1 Pro, respectivamente. As seguintes observações podem ser feitas com base nesses resultados de testes de desempenho:
Entre todos os frameworks SNARK, o rapidsnark é o mais eficiente em termos de memória. Também vemos que o Halo2 usa mais memória quando o tamanho da pré-imagem é pequeno devido ao custo fixo de configuração da tabela de consulta, mas consome menos memória no geral quando o tamanho da pré-imagem é grande.
O Starky é mais de 10 vezes mais eficiente em termos de memória do que o framework SNARK. Parte do motivo é que ele usa menos linhas.
Vale ressaltar que o pico de uso de memória no Macbook M1 Pro permanece relativamente estável devido ao tamanho maior da pré-imagem devido ao uso da memória swap.
Utilização da CPU
Avaliamos o grau de paralelização de cada sistema de prova medindo a utilização média da CPU durante a geração de prova para SHA-256 com uma entrada de pré-imagem de 4 KB. A tabela a seguir mostra a utilização média da CPU no Linux Server (20 núcleos) e no Macbook M1 Pro (10 núcleos) (utilização média por núcleo entre parênteses).
As principais observações são as seguintes:
Gnark e rapidsnark mostram a maior utilização de CPU no servidor Linux, indicando que eles são capazes de usar efetivamente múltiplos núcleos e paralelizar a geração de provas. O Halo2 também mostra um bom desempenho de paralelização.
A maioria das estruturas tem o dobro de utilização de CPU em um servidor Linux do que em um Macbook Pro M1, com exceção do snarkjs.
Embora inicialmente fosse esperado que as estruturas baseadas em FRI (Plonky2 e Starky) pudessem ter dificuldade em usar múltiplos núcleos de forma eficaz, elas não tiveram desempenho pior do que algumas das estruturas Groth16 ou KZG em nossos testes de desempenho. Resta saber se haverá diferença na utilização da CPU em máquinas com mais núcleos (por exemplo, 100 núcleos).
Sistema de Prova
Utilização da CPU (média de utilização por núcleo)
(Servidor Linux)
Utilização da CPU (média de utilização por núcleo)
(MBP M1)
sarcástico
557% (27,85%)
486% (48,6%)
rapidsnark
1542% (77,1%)
N / D
retorcido
1624% (81,2%)
720% (72%)
Obras de Arca
935% (46,75%)
504% (50,4%)
Halo2 (KZG)
1227% (61,35%)
588% (58,8%)
Plonky2
892% (44,6%)
429% (42,9%)
Stark-Os-Antigos
849% (42,45%)
335% (33,5%)
Conclusão e pesquisas futuras
Esta postagem compara de forma abrangente os resultados dos testes de desempenho do SHA-256 em várias estruturas de desenvolvimento zk-SNARK e zk-STARK. Por meio dessa comparação, obtemos insights sobre a eficiência e praticidade de cada estrutura na esperança de ajudar desenvolvedores que precisam gerar provas concisas para operações SHA-256. Descobrimos que as estruturas Groth16 (por exemplo, rapidsnark, gnark) são mais rápidas na geração de provas do que as estruturas Plonk (por exemplo, Halo2, Plonky2). A tabela de consulta na aritmetização de Plonkish reduz significativamente a restrição e o tempo de prova do SHA-256 ao usar tamanhos de pré-imagem maiores. Além disso, gnark e rapidsnark demonstram excelente capacidade de explorar múltiplos núcleos para paralelizar operações. Por outro lado, o tempo de geração de provas do Starky é muito menor, mas às custas de um tamanho de prova muito maior. Em termos de eficiência de memória, rapidsnark e Starky superam outros frameworks.
Como primeiro passo na construção da plataforma de avaliação de prova de conhecimento zero "Patheon", admitimos que os resultados deste teste de desempenho estão longe de ser suficientes para se tornar a plataforma de teste abrangente que esperamos construir. Aceitamos e estamos abertos a feedback e críticas, e convidamos todos a contribuir com esta iniciativa para tornar as provas de conhecimento zero mais fáceis e acessíveis aos desenvolvedores. Também estamos dispostos a fornecer subsídios a colaboradores individuais para cobrir o custo de recursos de computação para testes de desempenho em larga escala. Juntos, esperamos melhorar a eficiência e a utilidade dos ZKPs para o benefício da comunidade de forma mais ampla.
Por fim, gostaríamos de agradecer à equipe do Polygon Zero, à equipe do gnark na Consensys, à Pado Labs e à equipe do Delphinus Lab por sua valiosa revisão e feedback sobre os resultados dos testes de desempenho.
