Anagram Build passa a maior parte do nosso tempo pesquisando novos primitivos de criptografia e aplicando esses primitivos em produtos específicos. Um de nossos projetos de pesquisa recentes nos levou ao campo de Cálculo Verificável (CV); nossa equipe alavancou essa pesquisa para criar um novo sistema de código aberto chamado Bonsol. Escolhemos esta área de pesquisa dada a emergência de casos de uso eficazes que o VC possibilita e os esforços concertados em várias L1s para otimizar a eficácia de custos e escalabilidade do VC.

Neste blog, temos dois objetivos.

• Primeiramente, queremos garantir que você saia com uma compreensão melhor do VC como conceito e dos possíveis produtos que ele possibilita no ecossistema Solana.
• Em segundo lugar, queremos apresentar-lhe a nossa mais recente criação, Bonsol.

O que é Computação Verificável, afinal?

O termo 'Cálculo Verificável' pode não aparecer nos decks de investimento das startups de mercado em alta, mas o termo 'Conhecimento Zero' sim. Então, o que significam esses termos?

Verifiable Compute (VC) está executando uma carga de trabalho específica de uma maneira que produz uma atestação de seu funcionamento que pode ser verificada publicamente sem executar a computação novamente. Zero Knowledge (ZK) é ser capaz de provar uma afirmação sobre dados ou uma computação sem revelar todos os dados ou as entradas para a computação. Os termos estão um pouco conflacionados no mundo real, ZK é um tanto um nome incorreto. Tem mais a ver com selecionar as informações que precisam ser tornadas públicas para provar uma afirmação sobre isso. VC é um termo mais preciso e é o objetivo geral em muitas arquiteturas de sistemas distribuídos existentes.

Como o VC nos ajuda a construir melhores produtos cripto?

Então, por que queremos adicionar sistemas VC ou ZK, em cima de plataformas como Solana e Ethereum? Parece que a resposta é mais sobre segurança para o desenvolvedor. O desenvolvedor de um sistema age como um mediador entre a confiança dos usuários finais em uma caixa preta e as funções técnicas que tornam essa confiança objetivamente válida. Ao utilizar técnicas ZK/VC, o desenvolvedor pode reduzir a área de superfície para ataques nos produtos que estão construindo. Os sistemas VC transferem o locus de confiança para o sistema de prova e a carga de trabalho computacional sendo comprovada. Isso é uma inversão de confiança semelhante à que ocorre ao passar de uma abordagem típica de cliente/servidor web2 para uma abordagem de blockchain web3. A confiança passa de depender das promessas de uma empresa para confiar no código aberto e nos sistemas criptográficos da rede. Não existem sistemas verdadeiramente de zero confiança do ponto de vista do usuário, e eu argumento que, para os usuários finais, tudo parece uma caixa preta.

Por exemplo, ao usar um sistema de login ZK, um desenvolvedor terá menos responsabilidade na manutenção de um banco de dados e infraestrutura seguros do que apenas um sistema que verifica se algumas propriedades criptográficas são alcançadas. Técnicas de VC estão sendo aplicadas em muitos lugares onde o consenso é necessário para garantir que a única coisa necessária para criar consenso seja que as matemáticas sejam válidas.

Embora haja muitos exemplos promissores de uso de VC e ZK na natureza, muitos deles atualmente dependem do desenvolvimento em andamento em todos os níveis do conjunto de software criptográfico para torná-lo rápido e eficiente o suficiente para ser usado em produção.

Como parte do nosso trabalho aqui na Anagram, temos a oportunidade de falar com uma multitude de fundadores / desenvolvedores de criptomoedas para entender onde o estado atual da pilha de software das criptomoedas está retardando a inovação de produtos. Historicamente, nossas conversas nos ajudaram a identificar uma tendência interessante. Especificamente, uma coorte de projetos está movendo ativamente a lógica de produtos on-chain para off-chain porque está se tornando muito cara, ou eles precisam adicionar lógica de negócios mais exótica. No final, esses desenvolvedores se veem tentando encontrar sistemas e ferramentas para equilibrar as partes on-chain e off-chain dos produtos que estão desenvolvendo, que estão se tornando mais poderosos. É aqui que o VC se torna uma parte crítica do caminho a seguir, ajudando a conectar os mundos on-chain e off-chain usando métodos trustless e verificáveis.

Vamos lá! Então, como funcionam os sistemas de VC/ZK hoje?

As funções VC e ZK agora são principalmente executadas em camadas de computação alternativas (também conhecidas como rollups, sidechains, relays, oracles ou coprocessors) disponíveis por meio de uma chamada de retorno para o tempo de execução do contrato inteligente. Para viabilizar este fluxo de trabalho, muitas das cadeias L1 têm esforços em andamento para fornecer atalhos fora do tempo de execução do contrato inteligente (por exemplo, syscalls ou precompiles) que permitem que eles façam coisas que de outra forma seriam muito caras on-chain.

Existem alguns modos comuns dos sistemas de VC atuais. Vou mencionar os quatro principais dos quais estou ciente. Em todos, exceto no último caso, as provas ZK acontecem fora da cadeia, mas é onde e quando as provas são verificadas que dão a cada um desses modos sua vantagem.

Verificação totalmente on-chain

Para sistemas de prova VC e ZK que podem produzir provas pequenas, como Groth16 ou algumas variedades de Plonk, a prova é então enviada na cadeia e verificada na cadeia usando código previamente implantado. Tais sistemas são agora muito comuns, e a melhor maneira de experimentar isso é usando Circom e um verificador Groth16 no Solana ou EVM. A desvantagem é que esses sistemas de prova são bastante lentos. Eles também normalmente requerem aprender uma nova linguagem. Para verificar um hash de 256 bits no Circom, você realmente precisa lidar manualmente com cada um desses 256 bits. Existem muitas bibliotecas que permitem apenas chamar funções de hash, mas nos bastidores, você precisa reimplementar essas funções em seu código Circom. Esses sistemas são ótimos quando o elemento ZK e VC do seu caso de uso é menor, e você precisa que a prova seja válida antes que alguma outra ação determinística seja tomada. Bonsol se enquadra atualmente nesta primeira categoria.

Verificação fora da cadeia

A prova é enviada para a cadeia para que todas as partes possam ver que está lá e posteriormente usar o cálculo off-chain para verificar. Neste modo, você pode suportar qualquer sistema de prova, mas como a prova não está ocorrendo na cadeia, você não obtém o mesmo determinismo para qualquer ação que depende da submissão da prova. Isso é bom para sistemas que têm algum tipo de janela de desafio onde as partes podem "contestar" e tentar provar que a prova está incorreta.

Redes de Verificação

A prova é submetida a uma rede de verificação, e essa rede de verificação atua como um oráculo para chamar o contrato inteligente. Você obtém o determinismo, mas também precisa confiar na rede de verificação.

Verificação Síncrona On-chain

O quarto e último modo é bastante diferente; neste caso, a prova e a verificação acontecem simultaneamente e completamente na cadeia. Aqui é onde o L1 ou um contrato inteligente no L1 é realmente capaz de executar um esquema ZK sobre entradas de usuário que permitem que a execução seja comprovada sobre dados privados. Não há muitos exemplos generalizados disso na natureza, e geralmente, os tipos de coisas que você pode fazer com isso são limitados a operações matemáticas mais básicas.

Recap

Todos os quatro destes modos estão a ser testados em vários ecossistemas de cadeias, e veremos se surgem novos padrões e qual padrão se torna dominante. Por exemplo, na Solana, não há um vencedor claro, e o cenário de VC e ZK é muito inicial. O método mais popular em várias cadeias, incluindo a Solana, é o primeiro modo. A verificação totalmente on chain é o padrão ouro, mas como discutido, tem algumas desvantagens. Principalmente a latência e limita o que os seus circuitos podem fazer. Ao explorarmos o Bonsol, verá que segue o primeiro modo com um pequeno toque.

Apresentando Bonsol!

Entrar Bonsol, um novo sistema VC nativo da Solana que nós da Anagram construímos e tornamos de código aberto. Bonsol permite que um desenvolvedor crie um executável verificável sobre dados privados e públicos e integre os resultados em contratos inteligentes da Solana. Note que este projeto depende da popular cadeia de ferramentas RISC0.

Este projeto foi inspirado por uma pergunta feita por muitos dos projetos com os quais trabalhamos semanalmente: "Como posso fazer essa coisa com dados privados e comprová-la na cadeia?" Embora a "coisa" fosse diferente em cada caso, o desejo subjacente era o mesmo: minimizar suas dependências centralizadas.

Antes de entrarmos em detalhes do sistema, vamos começar ilustrando o poder do Bonsol com dois casos de uso separados.

Cenário um

Um Dapp que permite aos usuários comprar bilhetes de rifa em pools de vários tokens. As pools são 'decantadas' uma vez por dia de uma pool global de tal forma que o valor do dinheiro na pool (os montantes de cada token) está oculto. Os usuários podem comprar acesso a faixas cada vez mais específicas dos tokens na pool. Mas há um detalhe: uma vez que um usuário compra a faixa, ela se torna pública para todos os usuários ao mesmo tempo. O usuário deve então decidir comprar o bilhete. Eles podem decidir que não vale a compra, ou podem garantir uma participação na pool comprando um bilhete.

Bonsol entra em jogo quando o pool é criado e quando o usuário paga pela faixa para se tornar conhecida. Quando o pool é criado / decantado, o programa ZK recebe as entradas privadas da quantidade de cada token a ser decantado. Os tipos de tokens são entradas conhecidas, e o endereço do pool é uma entrada conhecida. Esta prova é uma prova de seleção aleatória do pool global para o pool atual. A prova contém um compromisso com os saldos também. O contrato on-chain receberá esta prova, verificará e manterá os compromissos de modo que, quando o pool for finalmente fechado e os saldos forem enviados do pool global para os proprietários do bilhete da rifa, eles possam verificar que os montantes dos tokens não foram alterados desde a seleção aleatória no início do pool.

Quando um usuário compra uma "abertura" das faixas de saldo de token ocultas, o programa ZK leva os saldos de token reais como entradas privadas e produz uma gama de valores que são comprometidos juntamente com a prova. Uma entrada pública deste programa ZK é a prova de criação de pool previamente comprometida e suas saídas. Dessa forma, todo o sistema é verificado. A prova anterior deve ser validada na prova de faixa, e os saldos de token devem ser hash para o mesmo valor comprometido na primeira prova. A prova de faixa também é comprometida à cadeia e, como dito anteriormente, torna a faixa visível para todos os participantes.

Embora haja muitas maneiras de realizar esse tipo de sistema de bilhetes para sorteio, as propriedades do Bonsol tornam muito fácil ter muito pouca confiança na entidade responsável pelo sorteio. Ele também destaca a interoperabilidade do Solana e do sistema VC. O programa Solana (contrato inteligente) desempenha um papel crucial na intermediação dessa confiança, pois verifica as provas e permite que o programa aja em seguida.

Cenário dois

Bonsol permite que os desenvolvedores criem uma primitiva que é usada por outros sistemas. Bonsol contém a noção de implantações, onde um desenvolvedor pode criar algum programa ZK e implantá-lo para os operadores Bonsol. Os operadores da rede Bonsol atualmente têm algumas maneiras básicas de avaliar se uma solicitação de execução para um dos programas ZK será economicamente vantajosa. Eles podem ver algumas informações básicas sobre quanto cálculo o programa ZK levará, os tamanhos de entrada e a gorjeta que o solicitante está oferecendo. Um desenvolvedor pode implantar uma primitiva que eles pensam que muitos outros Dapps vão querer usar.

Na configuração de um programa ZK, o desenvolvedor especifica a ordem e o tipo de entradas necessárias. O desenvolvedor pode liberar um Conjunto de Entradas que pré-configura algumas ou todas as entradas. Isso significa que eles podem configurar algumas das entradas de modo que possam criar primitivas que ajudem os usuários a verificar cálculos em conjuntos de dados muito grandes.

Por exemplo, digamos que um desenvolvedor cria um sistema que, dado um NFT, pode provar na cadeia a transferência de propriedade incluindo um conjunto específico de carteiras. O desenvolvedor pode ter um conjunto de entradas preconfiguradas que contenham um monte de informações de transações históricas. O programa ZK busca no conjunto para encontrar os proprietários correspondentes. Este é um exemplo artificial e pode ser feito de várias maneiras.

Considere outro exemplo: um desenvolvedor é capaz de escrever um programa ZK que pode verificar que uma assinatura de par de chaves vem de um par de chaves ou conjunto hierárquico de pares de chaves sem revelar as chaves públicas desses pares de chaves autoritativos. Digamos que isso seja útil para muitos outros Dapps, e eles usem esse programa ZK. O protocolo dá ao autor deste programa ZK uma pequena gorjeta de uso. Como o desempenho é crítico, os desenvolvedores são incentivados a tornar seus programas rápidos para que os operadores queiram executá-los, e os desenvolvedores que procuram copiar o trabalho de outro desenvolvedor precisarão modificar o programa de alguma forma para poder implantá-lo, pois há uma validação do conteúdo do programa ZK. Qualquer operação adicionada ao programa ZK afetará o desempenho, e embora definitivamente não seja infalível, isso pode ajudar a garantir que os desenvolvedores sejam recompensados pela inovação.

Arquitetura Bonsol

Esses casos de uso ajudam a descrever para que serve o Bonsol, mas vamos dar uma olhada em sua arquitetura atual, modelo de incentivo atual e fluxo de execução.

A imagem acima descreve um fluxo de um usuário precisando realizar algum tipo de cálculo verificável, que geralmente será feito por meio de um dapp que precisa disso para permitir que o usuário realize alguma ação. Isso tomará a forma de uma Solicitação de Execução que contém informações sobre o ZKprogram que está sendo executado, as entradas ou conjuntos de entradas, o tempo dentro do qual o cálculo deve ser comprovado e a gorjeta (que é como os Relays são pagos). A solicitação é capturada pelos Relays e eles devem correr para decidir se desejam reivindicar essa execução e começar a provar. Com base nas capacidades específicas dos operadores de relé, eles podem optar por passar isso adiante porque a gorjeta não vale a pena ou o zkprogram ou entradas são muito grandes. Se decidirem realizar esse cálculo, devem reivindicá-lo. Se forem os primeiros a reivindicar, então sua prova será aceita até um certo momento. Se não conseguirem produzir a prova a tempo, outros nós podem reivindicar a execução. Para reivindicar, o Relay deve colocar em jogo alguma participação atualmente codificada para gorjeta / 2 que será cortada se não conseguirem produzir uma prova correta.

Bonsol foi construído com a tese de que mais computação se moverá para uma camada onde é atestada e verificada na cadeia, e que Solana será uma cadeia "preferida" para VC e ZK em breve. As transações rápidas da Solana, a computação barata e a crescente base de usuários tornam-na um excelente lugar para testar essas ideias.

Foi fácil de construir? Caramba, não!

Isso não quer dizer que não houve desafios na construção do Bonsol. Para poder pegar a prova Risco0 e verificá-la na Solana, precisamos torná-la menor. Mas não podemos fazer isso sem sacrificar as propriedades de segurança da prova. Portanto, usamos Circom e envolvemos o Risc0 Stark, que pode ter cerca de 200kb, em uma prova Groth16 que sempre acaba sendo de 256 bytes. Felizmente, o Risc0 forneceu algumas ferramentas incipientes para isso, mas isso adiciona muita sobrecarga e dependências ao sistema.

À medida que começamos a construir o Bonsol e usar as ferramentas existentes para envolver o Stark com o Snark, buscamos maneiras de reduzir as dependências e aumentar a velocidade. O Circom permite a compilação do código Circom em C++ ou wasm. Primeiro tentamos compilar o circuito Circom em um arquivo wasmu produzido pelo LLVM. Esta é a maneira mais rápida e eficiente de tornar o ferramental Groth16 portátil e ainda rápido. Escolhemos o wasm devido à sua portabilidade, já que o código C++ dependia da arquitetura de cpu x86, o que significa que novos Macbooks ou servidores baseados em Arm não poderão usar isso. Mas isso se tornou um beco sem saída para nós na linha do tempo com a qual tínhamos que trabalhar. Como a maioria dos nossos experimentos de pesquisa de produtos são encaixotados, até que provem seu valor, tivemos 2-4 semanas de tempo de desenvolvimento para testar essa ideia. O compilador wasm llvm simplesmente não conseguiu manipular o código wasm gerado. Com mais trabalho, poderíamos ter passado disso, mas tentamos muitos sinalizadores de otimização e maneiras de fazer com que o compilador llvm funcionasse como um plugin wasmer para pré-compilar esse código em llvm, mas não tivemos sucesso. Como o circuito Circom tem cerca de 1,5 milhão de linhas de código, você pode imaginar que a quantidade de Wasm se tornou enorme. Em seguida, voltamos nossos olhos para tentar apenas criar uma ponte entre o C++ e nossa base de código de retransmissão Rust. Isso também encontrou uma derrota rápida, pois o C++ continha algum código de assembly específico x86 com o qual não queríamos mexer. A fim de obter o sistema para o público, acabamos simplesmente inicializando o sistema de uma forma que faz uso do código C++, mas remove algumas das dependências. No futuro, gostaríamos de expandir outra linha de otimização em que estávamos trabalhando. Isso era pegar o código C++ e realmente compilá-lo em um gráfico de execução. Esses artefatos C++ da compilação Circom são, em sua maioria, apenas aritmética modular sobre um campos finitoscom um número primo muito grande como gerador. Isso mostrou alguns resultados promissores para artefatos C++ menores e mais simples, mas mais trabalho é necessário para fazê-lo funcionar com o sistema Risc0. Isso ocorre porque o código C++ gerado tem cerca de 7 milhões de linhas de código, e o gerador de gráficos parece atingir limites de tamanho de pilha, e aumentar esses limites parece produzir outras falhas que não tivemos tempo de determinar. Embora algumas dessas abordagens não tenham dado certo, conseguimos fazer contribuições para projetos OSS e esperamos que, em algum momento, essas contribuições sejam integradas.

O próximo conjunto de desafios está mais no espaço de design. Uma parte essencial deste sistema é ser capaz de ter entradas privadas. Essas entradas precisam vir de algum lugar, e devido a limitações de tempo, não fomos capazes de adicionar um sistema de criptografia MPC sofisticado para permitir que as entradas privadas estejam no sistema em um loop fechado. Portanto, para atender a essa necessidade e desbloquear os desenvolvedores, adicionamos a noção de um servidor de entrada privada que precisa validar o solicitante, o qual é validado por uma assinatura de um payload atual como legítimo detentor da prova e servir para eles. À medida que estendemos o Bonsol, planejamos implementar um sistema de descriptografia de threshold MPC pelo qual os nós de retransmissão podem permitir que o requerente descriptografe as entradas privadas. Toda essa discussão sobre entradas privadas nos leva a uma evolução de design que planejamos disponibilizar no repositório do Bonsol. Isso é o Bonsolace, que é um sistema mais simples que permite a você, como desenvolvedor, provar facilmente esses programas zk em sua própria infraestrutura. Em vez de enviar para a rede provadora, você pode simplesmente prová-lo você mesmo e verificá-lo no mesmo contrato que a rede provadora usa. Este caso de uso é para casos de uso de dados privados de alto valor, onde o acesso aos dados privados deve ser minimizado a todo custo.

Uma última observação sobre Bonsol que não vimos em outros lugares usando Risc0 ainda é que forçamos um compromisso (hash) sobre os dados de entrada no programa zk. E realmente verificamos no contrato que as entradas às quais o verificador teve que se comprometer correspondem ao que o usuário esperava e enviou ao sistema. Isso tem um custo, mas sem isso significa que o verificador poderia trapacear e executar o zkprogram em entradas que o usuário não especificou. O restante do desenvolvimento do Bonsol se enquadrou no desenvolvimento normal do Solana, mas deve-se notar que tentamos intencionalmente algumas novas ideias lá. No contrato inteligente, estamos usando flatbuffers como o único sistema de serialização. Esta é uma técnica um tanto nova que gostaríamos de ver desenvolvida e transformada em um framework, pois se presta bem à geração automática de sdks que são multiplataforma. Uma observação final sobre o Bonsol é que atualmente precisa de uma pré-compilação para funcionar de forma mais eficiente, essa pré-compilação está prevista para ser lançada no Solana 1.18, mas até lá estamos trabalhando para ver se as equipes estão interessadas nessa pesquisa e olhando além do Bonsol para outras tecnologias.

Concluindo

Além do Bonsol, a equipe de construção de anagramas está investigando profundamente muitos lugares dentro do domínio do VC. Projetos como Jolt, zkllvm, spartan 2, Binius são projetos que estamos acompanhando, juntamente com empresas que trabalham no espaço de Criptografia Homomórfica Totalmente (FHE), se você não sabe o que é, fique ligado, pois abordaremos em algum momento.

Por favor, verifique o repositório Bonsol e faça um problema para os exemplos que você precisa ou como você deseja estendê-lo. É um projeto muito inicial e você tem a chance de deixar sua marca.

Se estiver trabalhando em projetos de VC interessantes, incentivamos você ainscreva-se aqui para o programa Anagram EIRonde, ao lado da equipe Anagram, você poderá testar sua tese, construir uma empresa e enfrentar os maiores problemas possíveis. Sinta-se à vontade para contribuir ou fazer qualquer pergunta.

Aviso legal:

1. Este artigo é reproduzido a partir de [soluçãoAnagrama], Todos os direitos autorais pertencem ao autor original [austbot]. Se houver objeções a essa reimpressão, entre em contato com o Aprender na Gateequipe e eles lidarão com isso prontamente.

2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.