Anagram Build passa a maior parte do nosso tempo a pesquisar novos primitivos cripto e a aplicar esses primitivos em produtos específicos. Um dos nossos projetos de pesquisa recentes levou-nos ao domínio da Computação Verificável (VC); nossa equipa aproveitou esta pesquisa para criar um novo sistema open source chamado Bonsol. Escolhemos esta área de investigação dada a emergência de casos de uso eficazes que o VC permite e os esforços concertados em vários L1s para otimizar a eficácia de custos e escalabilidade do VC.

Neste blog, temos dois objetivos.

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

O que é Verifiable Compute, afinal?

O termo 'Verifiable Compute' pode não aparecer nos decks de investimento de startups de mercado em alta, mas o termo 'Zero Knowledge' sim. Então, o que significam estes termos?

O Verifiable Compute (VC) está a executar uma carga de trabalho específica de forma a produzir uma atestação do seu funcionamento que pode ser publicamente verificada sem executar novamente o cálculo. Zero Knowledge (ZK) é ser capaz de provar uma afirmação sobre dados ou um cálculo sem revelar todos os dados ou inputs para o cálculo. Os termos são um pouco confundidos no mundo real, ZK é um pouco um equívoco. Tem mais a ver com selecionar a informação que precisa de ser tornada pública para provar uma afirmação sobre ela. VC é um termo mais preciso e é o objetivo geral em muitas arquiteturas de sistemas distribuídos existentes.

Como é que o VC nos ajuda a construir melhores produtos criptográficos?

Então, por que queremos adicionar sistemas de 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 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 ataque nos produtos que está construindo. Os sistemas VC transferem o locus de confiança para o sistema de comprovação e a carga de trabalho computacional que está sendo comprovada. Esta é uma inversão de confiança semelhante à que ocorre ao passar de uma abordagem típica 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 confiança zero 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. As técnicas de VC estão sendo aplicadas em muitos lugares onde é necessária a obtenção de consenso para garantir que a única coisa necessária para criar consenso seja que as matemáticas sejam válidas.

Embora existam muitos exemplos promissores de uso de VC e ZK na prática, 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 utilizado em produção.

Como parte do nosso trabalho aqui na Anagrama, temos a oportunidade de falar com uma multiplicidade de fundadores / desenvolvedores de criptomoedas para entender onde o estado atual do stack de software de criptomoedas está atrasando a inovação de produtos. Historicamente, as nossas conversas têm-nos ajudado a identificar uma tendência interessante. Especificamente, uma coorte de projetos está a mover ativamente a lógica do produto on-chain para off-chain porque está a tornar-se demasiado dispendioso, ou precisam de adicionar lógica de negócio mais exótica. No final, estes desenvolvedores encontram-se a tentar encontrar sistemas e ferramentas para equilibrar as partes on-chain e off-chain dos produtos que estão a desenvolver, os quais estão a tornar-se cada vez 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 sem confiança e verificáveis.

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

As funções de VC e ZK estão agora principalmente a serem executadas em camadas de computação alternativas (também conhecidas como rollups, sidechains, relays, oracles ou coprocessors) disponíveis através de uma chamada de retorno para a execução de contratos inteligentes. Para permitir este fluxo de trabalho, muitas das cadeias L1 têm esforços em curso para fornecer atalhos fora da execução de contratos inteligentes (por exemplo, chamadas de sistema ou precompiles) que lhes permitem fazer coisas que de outra forma seriam demasiado caras na cadeia.

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

Verificação Totalmente On-chain

Para sistemas de prova de VC e ZK que podem produzir provas pequenas, como Groth16 ou algumas variedades de Plonk, a prova é então submetida on-chain e verificada on-chain usando código previamente implementado. Tais sistemas são agora muito comuns, e a melhor maneira de experimentar isso é usando Circom e um verificador Groth16 em Solana ou EVM. A desvantagem é que esses sistemas de prova são bastante lentos. Eles também geralmente exigem 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 excelentes 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 é submetida à cadeia para que todas as partes possam ver que ela está lá e depois possam usar off-chain compute para verificar. Neste modo, você pode suportar qualquer sistema de prova, mas como a prova não está acontecendo 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 'discordar' 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 age 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 ao mesmo tempo 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 em 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 desses 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 está muito no início. O método mais popular em várias cadeias, inclusive na Solana, é o primeiro modo. A verificação totalmente na cadeia é o padrão ouro, mas, como discutido, tem algumas desvantagens. Principalmente a latência e limita o que os seus circuitos podem fazer. À medida que mergulhamos no Bonsol, verá que segue o primeiro modo com um leve toque.

Apresentamos Bonsol!

IntroduzirBonsol, um novo sistema VC nativo da Solana que nós, da Anagram, construímos e disponibilizamos. 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 isso com dados privados e prová-lo on-chain?" Embora a "coisa" diferisse 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 utilizadores comprar bilhetes de lotaria em pools de vários tokens. As pools são "decanadas" uma vez por dia a partir de uma pool global de tal forma que o montante de dinheiro na pool (os montantes de cada token) estão ocultos. Os utilizadores podem comprar acesso a intervalos cada vez mais específicos dos tokens na pool. Mas há um truque: uma vez que um utilizador compra o intervalo, torna-se público para todos os utilizadores ao mesmo tempo. O utilizador deve então decidir comprar o bilhete. Eles podem decidir que não vale a pena a compra, ou podem garantir uma participação na pool comprando um bilhete.

O Bonsol entra em jogo quando o pool é criado e quando o utilizador paga para que o intervalo fique conhecido. Quando o pool é criado/decanado, o programa ZK recebe as entradas privadas da quantidade de cada token a decantar. 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, verificá-la-á e manterá os compromissos de forma a que, quando o pool for finalmente encerrado e os saldos forem enviados do pool global para os proprietários dos bilhetes da rifa, estes possam verificar que os montantes de token não foram alterados desde a seleção aleatória no início do pool.

Quando um usuário compra uma “abertura” das gamas de saldo de token oculto, o programa ZK usa os saldos reais de token como entradas privadas e produz uma variedade 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. Desta forma, todo o sistema é verificado. A prova anterior deve ser validada na prova de gama, e os saldos de token devem fazer hash para o mesmo valor comprometido na primeira prova. A prova de gama também é comprometida com a cadeia e, como dito anteriormente, torna a gama visível para todos os participantes.

Embora existam muitas maneiras de realizar este tipo de sistema de bilhetes de rifa, as propriedades do Bonsol tornam bastante fácil ter muito pouca confiança na entidade responsável pela rifa. Também destaca a interoperabilidade do Solana e do sistema VC. O programa Solana (contrato inteligente) desempenha um papel crucial na mediação dessa confiança, pois verifica as provas e depois permite que o programa tome a próxima ação.

Cenário dois

O Bonsol permite aos desenvolvedores criar um primitivo que é usado por outros sistemas. O 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 de 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 irá levar, os tamanhos de entrada e a gorjeta que o solicitante está oferecendo. Um desenvolvedor pode implantar um primitivo que eles pensam que muitos outros Dapps irão querer usar.

Na configuração de um programa ZK, o desenvolvedor especifica a ordem e o tipo de inputs necessários. O desenvolvedor pode lançar um InputSet que pré-configura alguns ou todos os inputs. Isso significa que podem configurar alguns dos inputs de modo a criar primitivas que ajudem os utilizadores a verificar a computação em conjuntos de dados muito grandes.

Por exemplo, vamos dizer que um desenvolvedor cria um sistema que, dado um NFT, pode provar na cadeia a transferência de propriedade incluída em um conjunto específico de carteiras. O desenvolvedor pode ter um conjunto de entrada pré-configurado que contém um monte de informações de transações históricas. O programa ZK pesquisa no conjunto para encontrar os proprietários correspondentes. Este é um exemplo forçado e pode ser feito de uma infinidade de 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. Vamos dizer que é útil para muitos outros Dapps e que eles usam este programa ZK. O protocolo dá ao autor deste programa ZK uma pequena dica 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 plagiar o trabalho de outro desenvolvedor precisarão alterar o programa de alguma forma para poder implantá-lo, já que 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

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

A imagem acima descreve um fluxo a partir de um usuário que precisa realizar algum tipo de cálculo verificável, que normalmente será feito através de um dapp que necessita disso para permitir que o usuário execute alguma ação. Isso tomará a forma de um Pedido de Execução que contém informações sobre o ZKprogram a ser executado, as entradas ou conjuntos de entradas, o tempo dentro do qual o cálculo deve ser provado e a gorjeta (que é como os Relays são pagos). O pedido é recolhido pelos Relays e estes devem correr para decidir se querem reivindicar esta execução e começar a provar. Com base nas capacidades específicas dos operadores de relés, eles podem optar por passar isso adiante porque a gorjeta não vale a pena ou porque o zkprogram ou as entradas são muito grandes. Se decidirem realizar este cálculo, devem reivindicá-lo. Se forem os primeiros a reivindicar, então a sua prova será aceite até um certo momento. Se falharem em produzir a prova a tempo, outros nós podem reivindicar a execução. Para reivindicar, o Relay deve apostar alguma participação atualmente codificada para gorjeta / 2 que será cortada se falharem em produzir uma prova correta.

Bonsol foi construído com a tese de que mais computação se deslocará para uma camada onde é atestada e verificada na cadeia, e que Solana será uma cadeia de referência 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 construir isto? De modo nenhum!

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. Por isso, usamos o Circom e envolvemos o Risc0 Stark, que pode ter cerca de ~200kb, em uma prova Groth16, que acaba sempre sendo de 256 bytes. Felizmente, o Risc0 forneceu algumas ferramentas incipientes para isso, mas isso adiciona muita sobrecarga e dependências ao sistema.

Quando 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 do Circom em C++ ou wasm. Primeiro, tentamos compilar o circuito do Circom em um arquivo wasmu produzido pelo LLVM. Esta é a maneira mais rápida e eficiente de tornar as ferramentas Groth16 portáteis e ainda rápidas. Escolhemos o wasm devido à sua portabilidade, pois o código C++ dependia da arquitetura da CPU x86, o que significa que novos Macbooks ou servidores baseados em Arm não poderão usá-lo. Mas isso se tornou um beco sem saída para nós na linha do tempo com a qual tivemos que trabalhar. Como a maioria dos nossos experimentos de pesquisa de produtos são encaixotados no tempo até que provem seu valor, tivemos 2-4 semanas de tempo de desenvolvimento para testar essa ideia. O compilador llvm wasm simplesmente não conseguia lidar com o código wasm gerado. Com mais trabalho, poderíamos ter passado por isso, 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 do 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 relé 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 divulgar 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. Estes artefactos C++ da compilação do Circom são, na sua maioria, apenas aritmética modular sobre um campos finitoscom um número primo muito 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 ainda não tivemos tempo de determinar. Mesmo que algumas dessas abordagens não tenham dado certo, conseguimos contribuir 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 é poder ter entradas privadas. Essas entradas precisam vir de algum lugar e, devido a restrições de tempo, não conseguimos adicionar um sistema de criptografia MPC sofisticado para permitir que as entradas privadas estejam no sistema em um loop fechado. Portanto, para lidar com 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 é o reclamante atual da prova e serví-lo a eles. À medida que estendemos o Bonsol, planejamos implementar um sistema de decriptação de limiar do MPC pelo qual os nós de retransmissão podem permitir que o reclamante decripte as entradas privadas. Toda esta 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 terceirizar para a rede de provadores, você pode provar por si mesmo e verificar no mesmo contrato que a rede de provadores usa. Este caso de uso é para casos de uso de dados privados de alto valor, nos quais o acesso aos dados privados deve ser minimizado a todo custo.

Uma última nota sobre Bonsol que ainda não vimos em outros lugares usando Risc0 é que forçamos um compromisso (hash) sobre os dados de entrada no programa zk. E na verdade verificamos no contrato que as entradas às quais o provador teve de se comprometer correspondem ao que o usuário esperava e enviou para o sistema. Isso tem um custo, mas sem isso significa que o provador poderia trapacear e executar o zkprogram sobre entradas que o usuário não especificou. O restante do desenvolvimento do Bonsol seguiu o desenvolvimento normal do Solana, mas deve-se notar que intencionalmente experimentamos algumas ideias novas 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, porque se presta bem à geração automática de SDKs que são multiplataforma. Uma nota final sobre o Bonsol é que atualmente precisa de uma pré-compilação para funcionar de forma mais eficiente, esta pré-compilação está prevista para ser incluída no Solana 1.18, mas até lá estamos trabalhando para ver se as equipes estão interessadas nesta pesquisa e olhando para além do Bonsol em outras tecnologias.

Concluindo

Para além da Bonsol, a equipa de construção de anagramas está a analisar profundamente muitos lugares dentro do domínio do VC. Projetos como Jolt, zkllvm, spartan 2, Binius são projetos que estamos a seguir, juntamente com empresas que trabalham no espaço de Encriptação Homomórfica Total (FHE), se não sabe o que é, mantenha-se atento, pois iremos abordá-lo em algum momento.

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

Se estiver a trabalhar em projetos de VC interessantes, encorajamo-lo a aplique aqui para o programa Anagram EIRonde, juntamente com a equipa Anagram, poderá testar a 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 foi republicado de [GateAnagrama], Todos os direitos autorais pertencem ao autor original [austbot]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa e eles tratarão do assunto prontamente.

2. Aviso de responsabilidade: As opiniões expressas 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.