Provas de conhecimento zero: suas aplicações na Solana

Introdução

Este é o segundo artigo de uma série introdutória sobre provas de conhecimento zero. Recomendo muito que você leia Provas de conhecimento zero: uma introdução aos fundamentos antes deste artigo, pois ele oferece o contexto necessário sobre a teoria, a matemática e a criptografia subjacentes que fundamentam esta análise. Este artigo pressupõe esse conhecimento. Portanto, se você ainda não conhece as provas de conhecimento zero, recomendo que leia o artigo anterior primeiro. O objetivo deste artigo é oferecer o conhecimento necessário para você contribuir com a discussão sobre provas de conhecimento zero na Solana e até mesmo começar a desenvolver novos e inovadores primitivos de conhecimento zero.

Assim, com esse novo conhecimento, finalmente podemos perguntar: o que são provas de conhecimento zero? Como elas são usadas na Solana?

O que são provas de conhecimento zero?

Agora que finalmente dominamos a teoria, a matemática e a criptografia necessárias, é apropriado perguntar: o que exatamente é uma prova de conhecimento zero?

Uma prova de conhecimento zero é um processo criptográfico no qual uma parte consegue provar a outra que determinada afirmação é verdadeira sem revelar nenhuma informação adicional além do fato de que ela é, de fato, verdadeira. Essas provas devem ser estatisticamente sólidas, completas e protegidas contra vazamento de informações.

Há dois tipos de afirmação que alguém pode querer provar com conhecimento zero. Em termos gerais:

• Afirmações sobre fatos (por exemplo, este grafo específico tem uma coloração com três cores)
• Afirmações sobre conhecimento (por exemplo, conheço a fatoração de N)

A primeira afirmação diz respeito, em última análise, a alguma propriedade intrínseca do universo — algo fundamentalmente verdadeiro, como 1 + 1 = 2. A segunda é chamada de prova de conhecimento. Ou seja, ela vai além da simples prova de que algo é verdadeiro e depende do que o Provador sabe.

Como mencionado anteriormente, para provar essas afirmações, nossas provas podem ser interativas ou não interativas. Em uma prova interativa de conhecimento zero, o Provador e o Verificador participam de uma série de rodadas até que o Verificador esteja convencido para além de qualquer dúvida razoável. A Zcash usa provas não interativas de conhecimento zero para permitir que os usuários façam transações anônimas. 

Em contraste, nas provas não interativas de conhecimento zero, a prova é entregue offline, sem qualquer comunicação direta entre o Provador e o Verificador. Nesse caso, o Provador gera uma prova que reúne todas as informações necessárias, e o Verificador pode verificá-la de forma independente, sem nenhuma outra interação. A Filecoin usa provas não interativas de conhecimento zero para comprovar que os usuários armazenaram dados sem revelar os próprios dados. 

 zk-SNARKs e circuitos

Uma zk-SNARK é um Argumento de Conhecimento Sucinto e Não interativo. Essas provas de conhecimento zero são especialmente eficientes e compactas, ou sucintas. Uma prova é considerada sucinta quando tanto seu tamanho quanto o tempo necessário para verificá-la crescem mais lentamente do que a computação a ser verificada. Portanto, se queremos uma prova sucinta, não podemos exigir que o verificador execute trabalho a cada rodada de hashing, pois o tempo de verificação seria proporcional à computação. Provas sucintas são possíveis graças aos polinômios e à heurística de Fiat-Shamir.

Independentemente da complexidade da afirmação que se tenta provar, as zk-SNARKs mantêm as provas pequenas e relativamente rápidas de verificar. É isso que torna as zk-SNARKs tão atraentes para rollups: temos um método para provar que todas as transações de uma determinada L2 são válidas, e a prova é pequena o suficiente para ser verificada na L1. Protocolos como a Mina vão além e usam provas recursivas, o que permite verificar todo o histórico da blockchain com uma prova de tamanho constante. Pickles é o novo sistema de provas da Mina e seu conjunto de ferramentas associado, sendo a primeira zk-SNARK implantada capaz de fazer composição recursiva sem uma configuração confiável. Observe que, por composição recursiva, estamos nos referindo a circuitos.

Os circuitos descrevem a computação que você deseja provar. Eles são uma sequência de operações matemáticas que recebe determinadas entradas para produzir saídas. Circuitos são usados em provas de conhecimento zero para representar computações executadas corretamente sem revelar suas entradas. O fluxo de trabalho geral é o seguinte:

• Escrita e compilação do circuito — Precisamos escrever e compilar o circuito. Isso pode ser tão simples quanto criar um circuito aritmético sobre um corpo finito definido pelo primo p = 7 e pela computação x * y = z. A ideia geral é representar uma computação a ser provada como um conjunto de restrições entre variáveis, reduzir essas restrições a equações polinomiais e escrever um código que mapeie todos os valores de uma forma para uma nova estrutura algébrica (isto é, um homomorfismo). O processo de compilação produzirá vários artefatos, incluindo o conjunto de restrições definido pelo circuito e um script ou binário para uso nas etapas seguintes
• Cerimônia de configuração confiável — Dependendo do tipo de zk-SNARK usado, pode ser necessário realizar uma cerimônia para gerar as chaves de prova e verificação
• Execução do circuito — Um circuito deve ser executado com o script ou binário gerado durante a compilação, como se fosse um tipo de programa. O usuário insere as entradas públicas e privadas, e os valores de todas as variáveis intermediárias e de saída são calculados. A testemunha, também conhecida como rastro, é o registro de todas as etapas da computação
• Geração da prova — Com a chave de prova da segunda etapa e a testemunha da terceira, o provador pode gerar uma prova de conhecimento zero de que todas as restrições definidas no circuito são satisfeitas, revelando apenas o valor de saída. Essa prova é enviada ao verificador
• Verificação da prova — O verificador usa a prova enviada e a chave de verificação para confirmar que a prova está correta para sua saída pública

Certos tipos de zk-SNARKs, como a Groth16, exigem uma configuração confiável para cada circuito. Isso pode ser um obstáculo, pois você precisaria realizar uma nova cerimônia para cada novo programa. Outras zk-SNARKs, como a PlonK, exigem apenas uma configuração confiável universal, simplificando todo o processo. Outros tipos de prova de conhecimento zero, como as zk-STARKs, eliminam por completo a necessidade de uma configuração confiável.

zk-STARKs

Uma zk-STARK é um Argumento de Conhecimento Transparente e Escalável. As zk-STARKs foram inventadas pela StarkWare e propostas pela primeira vez neste artigo de 2018 como alternativa às zk-SNARKs. Em essência, elas permitem que blockchains transfiram computações para um único provador STARK off-chain e verifiquem a integridade dessas computações usando um Verificador STARK on-chain. 

As zk-STARKs são consideradas de conhecimento zero porque as entradas usadas pelo provador off-chain não são expostas à blockchain, preservando a privacidade do usuário. Elas são escaláveis porque mover as computações para fora da blockchain reduz significativamente os custos de verificação na L1. Suas provas também escalam linearmente, enquanto as zk-SNARKs escalam apenas de forma quase linear. Além disso, as zk-STARKs não dependem de cerimônias elaboradas de configuração confiável, que, segundo seus defensores, estão sujeitas a resíduos tóxicos — provas inválidas que poderiam ser aceitas pelos verificadores se a cerimônia não fosse realizada corretamente. Em vez disso, as zk-STARKs usam aleatoriedade publicamente verificável para configurar as interações entre provadores e verificadores. Além disso, essas provas só podem ser geradas por um provador off-chain que realmente executou a computação, junto às entradas auxiliares exigidas por ela.

As zk-STARKs resolvem as limitações das zk-SNARKs por serem argumentos de conhecimento escaláveis e transparentes. Elas também adotam premissas criptográficas muito mais simples, evitando por completo a necessidade de elementos como curvas elípticas. Em vez disso, dependem exclusivamente de hashes e da teoria da informação, o que as torna resistentes à computação quântica. No entanto, o tamanho da prova fica na faixa de algumas centenas de kilobytes, o que pode limitar sua viabilidade em ambientes com largura de banda ou armazenamento restritos, como blockchains. Vale observar que algumas configurações de prova mais complexas e zkVMs usam uma combinação que prova zk-STARKs recursivamente em uma zk-SNARK apenas para a etapa final de verificação.

ZK Compression

O problema do crescimento do estado

Um dos problemas mais urgentes da Solana é o crescimento do estado. Para contextualizar, o estado da Solana é armazenado nos discos de nós completos no Accounts DB. Trata-se de um armazenamento de chave-valor, no qual cada entrada do banco de dados é conhecida como uma conta. As contas têm endereços de 32 bytes cada, e a quantidade de dados que uma conta pode armazenar varia de 0 a 10 MB. Atualmente, armazenar 10 MB de dados custa aproximadamente 70 SOL, independentemente de esses dados estarem em uma conta de 10 MB ou em mil contas de 10 KB. Todos os dias, cerca de um milhão de novas contas são adicionadas à blockchain. Segundo a publicação de Toly sobre o crescimento do estado, isso eleva o estado total para mais de 500 milhões de contas. À medida que a Solana continuar crescendo, isso criará vários desafios, principalmente tamanho ilimitado dos snapshots, limitações de largura de banda PCI, indexação de contas e gerenciamento caro de memória e disco. 

O snapshot completo atual tem aproximadamente 70 GB, um volume administrável com o hardware disponível hoje. No entanto, o crescimento contínuo levará inevitavelmente a ineficiências no gerenciamento do estado e a possíveis gargalos. À medida que o tamanho do snapshot aumenta, o tempo necessário para realizar uma inicialização a frio de um novo sistema após uma falha de hardware se torna significativamente maior, o que pode ser prejudicial no caso de uma reinicialização da rede. 

A largura de banda da Interconexão de Componentes Periféricos (PCI) refere-se à taxa de transferência de dados entre a CPU e dispositivos periféricos, como placas gráficas, placas de rede e dispositivos de armazenamento. O PCI Express (PCIe) é um padrão de interface de alta velocidade criado para substituir o antigo padrão PCI e oferecer taxas maiores de transferência de dados. A largura de banda PCI mais recente pode atingir velocidades de 1 TB, ou 128 GB/s. Embora pareça muito, não é no contexto da Solana. Se uma transação ler ou gravar 128 MB, uma largura de banda PCI de 128 GB/s limitará a Solana a 1.000 transações por segundo (TPS). No entanto, a maioria das transações acessa memória recente que já foi carregada e armazenada em cache na RAM de um validador. Mesmo assim, o uso eficiente da memória de estado é crucial para manter um alto throughput à medida que a Solana escala. Caso contrário, essa largura de banda pode rapidamente se tornar um fator limitante.

Cada validador precisa manter um índice de todas as contas existentes. Isso ocorre porque a criação de uma nova conta exige uma prova de que ela ainda não existe. Com um estado total superior a 500 milhões de contas, até mesmo um índice mínimo — isto é, uma chave de 32 bytes e um hash de dados de 32 bytes por entrada — exigiria cerca de 32 GB de RAM. Esse armazenamento de estado é caro e precisa ser gerenciado com cuidado para evitar a degradação do desempenho. À medida que o estado da Solana continua crescendo, torna-se crucial distinguir entre o uso de memória rápida e cara, como RAM, em certas operações, e memória mais lenta e barata, como disco.

Transações e crescimento do estado

Toda transação da Solana precisa especificar todas as contas que lê e nas quais grava. Atualmente, as transações estão limitadas a 1.232 bytes e precisam incluir o seguinte:

• Cabeçalho (3 bytes)
• Assinaturas (64 bytes cada)
• Endereços de contas (32 bytes cada)
• Dados de instruções (tamanho arbitrário)
• Blockhash recente (32 bytes)

O seguinte ocorre quando uma transação é executada:

• Verificações de integridade — Apenas transações recentes são válidas, e são realizadas verificações de deduplicação, estrutura, taxas e assinaturas na transação
• Carregamento do programa — O bytecode do programa é carregado com base no endereço do programa, e a Solana Virtual Machine (SVM) é instanciada
• Carregamento das contas — Todas as contas referenciadas pela transação são verificadas, carregadas do armazenamento para a memória e passadas à SVM
• Execução — O bytecode do programa é executado
• Sincronização — Todas as contas modificadas são sincronizadas de volta com o armazenamento

Esse ciclo de vida apresenta vários desafios à medida que o estado continua crescendo. O estado on-chain é caro, e ter mais contas armazenadas em disco gera snapshots e índices maiores. Além disso, nem todas as contas são acessadas com frequência, o que torna ineficiente arcar continuamente com seu custo de recursos.

Simplificação do gerenciamento de estado com ZK Compression

Em vez de armazenar todas as contas em disco e lê-las quando necessário, uma transação pode enviar os dados da conta como parte de seu payload. Podemos garantir que os usuários que enviam transações forneçam o estado correto usando árvores de Merkle. As provas de Merkle são uma forma de criar um compromisso com determinados dados. Assim, as provas podem ser verificadas em relação ao compromisso para validar se o estado correto foi fornecido e se o usuário não está sendo desonesto sobre ele. 

Embora seguras, essas provas podem ser bastante grandes. Por exemplo, se uma árvore contiver 100 mil contas, a prova terá 544 bytes. Fornecer provas para várias contas poderia rapidamente ultrapassar o limite de 1.232 bytes por transação. Felizmente, podemos contornar isso usando sistemas de prova mais eficientes. O uso de compromissos com provas de tamanho constante, como KZG ou compromissos de Pedersen, reduziria o tamanho da prova, tornando mais viável incluí-la no limite de tamanho da transação.

ZK Compression é simplesmente um mecanismo para resolver o problema do tamanho das provas de Merkle — uma forma de provar que determinada computação foi executada corretamente, sem os custos associados ao armazenamento on-chain, aproveitando o ledger da Solana.

O que é ZK Compression?

ZK Compression é um novo primitivo que permite aos desenvolvedores compactar o estado on-chain para reduzir seus custos em várias ordens de magnitude, preservando segurança, desempenho e composabilidade. Por exemplo, criar 100 contas de token custaria atualmente ~0,2 SOL. Com ZK Compression, o custo é reduzido em 5.000 vezes, para ~0,00004 SOL. 

ZK Compression usa provas de conhecimento zero para validar transições de estado sem expor os dados subjacentes. Para isso, agrupa várias contas em uma única raiz de Merkle verificável armazenada on-chain, enquanto os dados subjacentes ficam armazenados no ledger. Provas de validade são provas sucintas de conhecimento zero usadas para provar a existência de um número n de contas como folhas em um número m de árvores de estado, mantendo um tamanho constante de 128 bytes. Essas provas são geradas off-chain e verificadas on-chain, reduzindo a carga computacional geral sobre a Solana. ZK Compression usa a Groth16, uma renomada zk-SNARK baseada em emparelhamento, em seu sistema de prova.

Essas contas, porém, não são contas comuns da Solana. Elas são contas compactadas.

Modelo de contas compactadas

O estado compactado por ZK é armazenado em contas compactadas. Essas contas são semelhantes às contas comuns da Solana, mas apresentam várias diferenças importantes que aumentam a eficiência e a escalabilidade:

• Identificação por hash — Cada conta compactada pode ser identificada por seu hash
• Alteração do hash na gravação — Qualquer operação de gravação em uma conta compactada altera seu hash
• Endereço opcional — Opcionalmente, um endereço pode ser definido como ID exclusivo e permanente da conta compactada. Isso é útil para determinados casos de uso, como NFTs. Esse campo é opcional para evitar sobrecarga computacional, já que contas compactadas podem ser referenciadas por seu hash
• Árvores de estado esparsas — Todas as contas compactadas são armazenadas em árvores de Merkle, e apenas a raiz de estado da árvore — isto é, a raiz de Merkle — fica armazenada no espaço de contas on-chain. Mais especificamente, uma árvore de estado é uma árvore de Merkle concorrente baseada no hash Poseidon

Endereços derivados de programa (PDAs) compactados podem ser identificados por seu endereço exclusivo e persistente. Eles seguem um layout semelhante ao das contas PDA comuns, com os campos Data, Lamports, Owner e Address. No entanto, diferentemente dos PDAs comuns, o campo Data incorpora a estrutura AccountData, com os campos Discriminator, Data e DataHash.

Nós

Diferentes tipos de nós desempenham papéis cruciais no suporte à ZK Compression. Qualquer pessoa pode executar um nó Photon RPC, um nó Prover ou um nó Light Forester para se conectar à Devnet e à Mainnet-Beta. Para o desenvolvimento local, o comando test-validator da CLI de ZK Compression inicia um cluster Solana de nó único com todos os nós relevantes — isto é, Photon RPC e Prover —, além de programas de sistema, contas e recursos de runtime.

Os nós Photon RPC indexam os programas de compactação. Isso permite que os clientes leiam e criem transações que interagem com o estado compactado. O indexador de compactação canônico se chama Photon e é fornecido pela Helius. Esse tipo de nó pode ser executado localmente com configuração mínima e precisa ser direcionado a um RPC existente. 

Os nós Prover são usados para gerar provas de validade para inclusão no estado. O endpoint getValidityProof da especificação da API RPC de ZK Compression pode ser usado para buscar provas. Os nós Prover podem operar de forma independente ou em conjunto com outro RPC. Vale observar que a implementação canônica do Photon RPC inclui um nó Prover.

Os nós Light Forester gerenciam a criação, a rotação e a atualização de árvores de estado compartilhadas e pertencentes a programas. Eles são voltados a desenvolvedores que desejam ter suas próprias árvores de estado pertencentes a programas atendidas por uma rede de nós Light Forester.

Premissas de confiança

Qualquer pessoa pode executar um dos nós mencionados acima, além de armazenar os dados brutos necessários para gerar provas e enviar transações. Isso introduz uma premissa de confiança que afeta a disponibilidade do estado compactado. Mais especificamente, se os dados forem perdidos ou atrasarem, não será possível enviar transações, a menos que sejam armazenados pessoalmente. Como apenas um nó honesto é necessário para fornecer os dados e as provas são verificáveis por si mesmas, o problema está na disponibilidade e na possível censura, não na segurança.

Além disso, o fato de o programa que verifica contas compactadas poder ser atualizado atualmente introduz outra premissa de confiança. Isso permite que o programa seja modificado para corrigir problemas ou se adaptar a novos requisitos. Porém, ele poderá se tornar imutável ou ser congelado no futuro, assim que atingir um estado estável e seguro.

Outra premissa de confiança relacionada à disponibilidade é o uso de nós Forester. Esses nós mantêm o avanço das raízes de estado e gerenciam filas de anuladores, esvaziando-as e avançando as raízes de estado de forma assíncrona. Nesse processo, os hashes das contas são substituídos por zeros para anulá-los. Essa separação entre avanço e anulação garante a finalidade instantânea das transições de estado compactado, mantendo as transações dentro das restrições de tamanho da Solana. Como as filas de anuladores têm tamanho constante, os nós Forester são essenciais para a disponibilidade do protocolo. Uma fila cheia causaria uma falha de disponibilidade na árvore de estado associada. Felizmente, os nós Forester evitam isso esvaziando as filas. No entanto, ainda é necessário que pessoas executem esses nós para ajudar a preservar a integridade e a disponibilidade do protocolo. Sem esses nós, ZK Compression conseguiria oferecer suporte a apenas cerca de duas mil contas ou endereços.

Limitações 

Mesmo quando não é necessário ocultar algo, as provas de conhecimento zero transformam problemas que exigem várias etapas computacionais em problemas que exigem a verificação de uma única prova para confirmar que as computações foram executadas corretamente. E essas computações não precisam se limitar a verificar se uma folha específica pertence a determinada árvore — elas podem ser qualquer computação arbitrária. No entanto, isso tem um custo.

Antes de usar ZK Compression, considere o seguinte:

• Maior tamanho da transação — ZK Compression exige 128 bytes para a prova de validade, além do envio dos dados que serão lidos ou gravados on-chain
• Maior uso de unidades de computação — ZK Compression aumenta significativamente o uso de unidades de computação (CUs), pois exige ~100 mil CUs para verificar a prova de validade, ~100 mil CUs para uso do sistema e ~6 mil CUs por conta compactada lida ou gravada
• Custo de estado por transação — Cada operação de gravação gera um pequeno custo de rede, pois precisa anular o estado anterior da conta compactada e adicionar o novo estado compactado à árvore de estado. Portanto, é perfeitamente possível que o custo total de uma conta compactada ao longo de sua vida útil ultrapasse o de sua equivalente não compactada caso ela exija muitas atualizações de estado

Pode ser preferível usar uma conta comum se:

• A conta for atualizada com frequência
• O número de gravações na conta ao longo de sua vida útil for grande (isto é, >1.000 vezes)
• A conta armazenar uma grande quantidade de dados que precisam ser acessados em transações on-chain

Benefícios

ZK Compression é um primitivo escalável, seguro, eficiente e flexível que enfrenta diretamente o problema de crescimento do estado da Solana e oferece suporte a uma ampla variedade de aplicações e casos de uso. Provavelmente, sua vantagem mais perceptível é a redução do custo do estado. ZK Compression permite que aplicativos escalem facilmente para milhões de usuários ao armazenar o estado de forma segura no espaço mais barato do ledger, mantendo o armazenamento on-chain no mínimo por meio de impressões digitais do estado. Usando como exemplo a emissão de 10.000 contas de token e considerando um preço de US$ 130 por SOL, isso custaria aproximadamente US$ 2.600. ZK Compression reduz esse valor para menos de cinquenta centavos.

ZK Compression também se integra bem às especificações atuais da Solana. Por exemplo, a estrutura das contas compactadas é quase idêntica à das contas comuns da Solana. Ela também oferece suporte a inovações específicas da Solana, como o paralelismo. Ou seja, quaisquer duas transações na mesma árvore de estado — isto é, no mesmo compromisso — que acessem contas compactadas diferentes podem ser executadas em paralelo. Além disso, ZK Compression fortalece a composabilidade atômica síncrona. Por exemplo, uma transação que liste n contas compactadas e m contas comuns é uma configuração totalmente válida. Uma instrução que referencia uma conta compactada pode chamar outra instrução ou programa que referencia uma conta comum. Isso continua válido mesmo que as contas estejam compactadas em árvores de estado diferentes. Se uma instrução falhar, toda a transação será revertida, e as alterações ficarão visíveis de uma instrução para a seguinte. Isso difere dos rollups ZK, nos quais os rollups não podem chamar uns aos outros de forma síncrona ou atômica sem adquirir bloqueios. Naturalmente, isso justifica uma comparação entre ZK Compression e rollups.

ZK Compression não é um rollup

ZK Compression não é um rollup. Embora os dois dependam da mesma tecnologia, suas implementações são diferentes. Há dois tipos de rollup:

• Rollups otimistas — Todas as transações são consideradas válidas durante um determinado período, e provas de fraude são usadas para comprovar transações falsas dentro desse intervalo
• Rollups de conhecimento zero — Provas de validade são usadas para comprovar instantaneamente se as transações são válidas ou inválidas

Todo o estado de um rollup de conhecimento zero é representado como uma única raiz na camada base — isto é, na Ethereum. Isso levou a várias alegações de que ZK Compression seria, na verdade, um rollup. No entanto, existem várias diferenças cruciais.

Considere um cenário com 500 transações em um rollup ZK. Nesse caso, todo o rollup é tratado como um único circuito. As 500 transações são verificadas em conjunto, gerando uma única prova que confirma que a raiz do estado mudou de A para B. Depois que essa prova é verificada, o contrato inteligente que gerencia as interações entre a L1 e a L2 atualiza a raiz do estado. Em contraste, com ZK Compression, cada uma das 500 transações gera sua própria prova para verificar se os dados da conta estão corretos. Essas transações são executadas pela própria SVM, e as contas são tratadas como contas “comuns” depois que cada prova é validada.

Se classificássemos ZK Compression como um rollup, isso implicaria que qualquer raiz de Merkle armazenada na Solana poderia ser considerada um rollup baseado em validade. Se analisarmos todas as raízes de cNFTs compactados atualmente na Solana, existem aproximadamente 4 a 5 mil rollups baseados em validade, dependendo de contarmos ou não as árvores de Merkle sem nenhuma emissão.

Assim, fica claro que ZK Compression é uma solução exclusiva e adaptada à arquitetura da Solana. É um novo primitivo, diferente dos rollups ZK, que melhora a escalabilidade e a eficiência sem a complexidade e a separação dos rollups.

O futuro de ZK na Solana e a interoperabilidade

O estado atual de ZK na Solana

Uma das minhas primeiras tarefas de redação na Helius foi abordar a atualização v1.16 da Solana. Fiquei extremamente empolgado ao conhecer o melhor suporte do runtime a provas de conhecimento zero e escrevi sobre isso no artigo. No entanto, essas melhorias foram adiadas. Cometi o erro de abordá-las novamente, com mais detalhes, no artigo sobre a atualização v1.17, mas elas foram adiadas outra vez. Nem me dei ao trabalho de mencioná-las no artigo sobre a atualização v1.18. Naturalmente, fiquei decepcionado, e outras pessoas também expressaram frustração. 

Apesar desse sentimento, existe uma comunidade emergente, embora pequena, de desenvolvedores ZK na Solana. Inicialmente, o Light Protocol se concentrava na execução privada de programas na forma de PSPs (Private Solana Programs), antes de refinar seu foco para ZK Compression. O Dark protocol também é um protocolo de privacidade futárquico desenvolvido na Solana. Ele não tem uma equipe central, e as contribuições são feitas por meio de propostas. A Arcium, anteriormente conhecida como Elusiv, usa Ambientes de Execução de Computação Multipartidária (MXEs) para alimentar sua própria rede paralelizada de computação confidencial. O Bonsol é um “coprocessador” de conhecimento zero que permite aos desenvolvedores executar qualquer imagem risc0 e verificá-la na Solana — isto é, computação off-chain verificável. Tutoriais e listas de links relacionados a provas de conhecimento zero também têm circulado.

Mais notavelmente, o ZK Token Proof Program verifica várias provas de conhecimento zero adaptadas para funcionar com compromissos de Pedersen e a Criptografia Twisted ElGamal sobre a curve25519. Ele viabiliza as Transferências Confidenciais, que usam provas de conhecimento zero para criptografar os saldos e valores de transações de tokens SPL. O objetivo é a confidencialidade, não o anonimato. A criptografia homomórfica permite executar computações sobre dados criptografados sem precisar descriptografá-los. Para isso, as Transferências Confidenciais usam a Criptografia Twisted ElGamal para operações matemáticas ocultas sobre o texto cifrado e Protocolos Sigma para validar essas transferências sem revelar informações sigilosas. Apenas o titular da conta que possui a chave de descriptografia pode visualizar seu saldo criptografado. No entanto, o Sistema de Auditor Global permite acesso seletivo de leitura para conformidade e auditoria por meio de chaves de descriptografia separadas. 

No momento, o ZK Token Proof Program é um recurso bloqueado devido à aprovação da SIMD-0153: ZK ElGamal Proof Program. Essa nova SIMD pretende descontinuar o ZK Token Proof Program existente, criado especificamente para o programa SPL Token, e substituí-lo por um programa de prova de conhecimento zero mais geral e independente de qualquer aplicação específica. A SIMD foi incorporada com o apoio da Anza e da equipe do Firedancer.

No entanto, a maré está começando a mudar. A Solana está se tornando uma potência em ZK à medida que essas melhorias finalmente chegam à Devnet e à Mainnet-Beta. Agora há três syscalls ZK ativas na Solana.

Syscalls Poseidon

Poseidon é uma família de funções hash criada especificamente para provas de conhecimento zero e usada em projetos como Zcash, Mina e Light Protocol. Poseidon é mais eficiente em termos computacionais para provas de conhecimento zero do que funções hash tradicionais e generalistas, como a SHA-256. 

As funções hash Poseidon são adequadas para conhecimento zero porque:

• Executam operações aritméticas com eficiência
• Exigem menos etapas para gerar provas — isto é, apresentam menor complexidade de circuito — graças ao seu design otimizado para aritmética, à S-box otimizada e ao número reduzido de rodadas
• Usam algoritmos que processam sequências de bits de qualquer tamanho, o que as torna extremamente versáteis

Antes, era caro demais calcular hashes Poseidon em uma única transação. No entanto, isso muda com a época 644 e a ativação da syscall Poseidon — isto é, uma chamada de sistema que recebe como entrada um slice bidimensional de bytes e calcula como saída o hash Poseidon correspondente. Isso é empolgante, pois ZK Compression depende do hashing Poseidon para suas árvores de estado.

A syscall Poseidon calcula hashes usando a curva BN254 com os seguintes parâmetros:

• S-boxes — Caixas de substituição x5
• Entradas — 1 ≤ n ≤ 12
• Largura — 2 ≤ t ≤ 13
• Rodadas — 8 rodadas completas e rodadas parciais de acordo com t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Sua saída será o resultado do hash Posiedon codificado como 32 bytes na ordenação de bytes especificada.

Observe que a variante específica usada aqui pela syscall é Poseidon com uma S-box x5 e parâmetros adaptados à curva BN254. O crate light-poseidon facilitará o cálculo desses hashes. O próprio crate foi auditado e é compatível com o Circom.

Syscalls alt_bn128

alt_bn128 refere-se à implementação da curva elíptica Barreto-Naehrig (BN-128), uma curva adequada para emparelhamentos que permite provas e computações zk-SNARK eficientes. Essa curva é fundamental para vários sistemas de prova de conhecimento zero, incluindo a Groth16, que é usada pela ZK Compression para validar transições de estado. Essa syscall reduz significativamente o espaço necessário por prova, oferecendo uma otimização crucial de espaço e tempo para provas on-chain eficientes. 

As syscalls sol_alt_bn128_group_op calculam operações na curva alt_bn128, incluindo adição de pontos em G1 — por G1, queremos dizer simplesmente um grupo de pontos em uma determinada curva elíptica —, multiplicação escalar em G1 e emparelhamento:

• Entradas — Pontos e escalares serializados no formato big endian
• Operações — Adição de pontos em G1, multiplicação escalar em G1 e emparelhamento (1 ponto em G1 e 1 ponto em G2)
• Saídas — Pontos em G1 ou resultados de emparelhamento serializados como um número inteiro de 256 bits

As syscalls sol_alt_bn128_compression compactam ou descompactam pontos dos grupos G1 ou G2 sobre a curva alt_bn128 e retornam os pontos no formato big endian padrão.

Atualmente, essas syscalls estão ativas na testnet e aparentemente ficarão disponíveis na Devnet assim que os bugs na fase de recompilação dos programas carregados forem resolvidos, conforme a SIMD-0075: Secp256r1 Precompile. Essa proposta busca simplificar os códigos de erro das syscalls alt_bn128 e da syscall Poseidon, garantindo consistência e reduzindo o risco de falhas de consenso causadas por códigos de erro diferentes retornados pelos validadores.

As syscalls alt_bn128 podem ser usadas para compromissos vetoriais comuns com provas de tamanho constante, como compromissos KZG. Portanto, elas funcionarão com qualquer curva adequada para emparelhamentos e não exigirão um circuito provador ZK. 

Interoperabilidade

A Solana é uma blockchain ZK. Ela é uma blockchain de Camada 1 de alto desempenho, com taxas baixas e suporte no runtime a operações com curvas elípticas. A implementação e o suporte a syscalls relacionadas a provas de conhecimento zero promovem a inovação e permitem que novos primitivos e aplicações, como ZK Compression, sejam desenvolvidos sobre a Solana.

A introdução das syscalls alt_bn128 reduz a lacuna de composabilidade entre a Solana e os contratos baseados em Solidity que dependem de contratos pré-compilados para executar operações com curvas elípticas especificadas na EIP-196, na EIP-197 e na EIP-198. Essas operações viabilizam a verificação de provas zk-SNARK dentro dos limites de gas da Ethereum. Assim, contratos Solidity que dependem dessas operações com curvas elípticas podem agora migrar com mais facilidade para a Solana ou até mesmo interoperar com ela.

A SIMD-0075 é essencial para as soluções de interoperabilidade. Quando estiver totalmente implementada, essa SIMD permitirá que projetos como o futuro blobsream-solana, que transmite DA da Celestia para a Solana, usem a geração de provas off-chain e a verificação on-chain para armazenar compromissos de Merkle. Sem essas syscalls, não seria possível verificar provas Groth16 na Solana. Além disso, essas syscalls aprimoram pontes e a interoperabilidade com minimização de confiança, permitindo que outras blockchains interajam com a Solana de forma integrada e segura.  

Toly está certo — com todas essas melhorias no runtime da Solana, a Solana é uma L2 da Ethereum. Em breve, nada impedirá você de enviar todos os blocos da Solana a algum contrato de ponte com validação de dados na Ethereum. Da mesma forma, nada impedirá você de enviar todos os blocos da Ethereum a algum programa de ponte com validação de dados na Solana. A interoperabilidade bidirecional, acelerada por provas de conhecimento zero em vez de pontes ultrapassadas, representa um futuro promissor e emergente para a Solana.

Conclusão

As provas de conhecimento zero são, sem dúvida, um dos primitivos mais poderosos — se não o mais poderoso — já desenvolvidos por criptógrafos. Isso se torna evidente ao examinarmos, no primeiro artigo, a teoria, a matemática e a criptografia que fundamentam esse conceito a partir de princípios básicos. As aplicações possíveis são infinitas, desde uma verdadeira névoa de guerra para jogos on-chain até a comprovação de que um conjunto de transações em uma L2 resultou em uma transição de estado específica.

Esta série de duas partes poderia facilmente ter mais cinquenta páginas, abordando as complexidades da criptografia homomórfica, a programação de circuitos em Circom e a análise de diferentes esquemas de compromisso. No entanto, o objetivo desses artigos é ensinar ao leitor os fundamentos das provas de conhecimento zero para que ele possa usar esse novo conhecimento e aplicá-lo à Solana. 

A Solana está se tornando uma potência em ZK. Do lançamento de ZK Compression às diversas syscalls que entrarão em operação em breve, sua importância não pode ser subestimada. Embora primitivos como ZK Compression abstraiam toda a complexidade das provas de conhecimento zero para o desenvolvedor comum, compreender os fundamentos é inestimável para avançar a discussão e seu desenvolvimento na Solana. 

Se você leu até aqui, muito obrigado, anon! Insira seu endereço de e-mail abaixo para nunca perder uma atualização sobre as novidades da Solana. Pronto para se aprofundar? Explore os artigos mais recentes no blog da Helius e continue hoje mesmo sua jornada pela Solana.

Recursos adicionais

• Uma introdução aproximada a como as zk-SNARKs são possíveis, por Vitalik
• POSEIDON: uma nova função hash para sistemas de prova de conhecimento zero (versão atualizada)
• SIMD-0075: pré-compilação Secp256r1
• Entenda a diferença entre zk-SNARKs e zk-STARKs
• Documentação da ZK Compression