Um guia do desenvolvedor para o zkGalaxy

Esta é uma heurística extremamente útil para diferenciar abordagens para suportar um zkEVM. No entanto, zkEVMs são um subconjunto de todas as formas possíveis de construir aplicativos de conhecimento zero. Para um programador que deseja aproveitar as propriedades exclusivas da computação zk, ou seja, concisão, conhecimento zero e correção, um zkEVM pode não ser a melhor escolha. Ao definir todo o conjunto de ferramentas do desenvolvedor, espero fornecer um guia que auxilie no processo de tomada de decisão sobre a pilha zk certa para seu aplicativo.

Nos últimos dois anos, houve um enorme progresso nas ferramentas zk. Eles estão se aproximando de um ponto em que os desenvolvedores de software comuns podem aproveitar as poderosas propriedades do zk sem uma compreensão profunda da intimidante matemática e engenharia subjacentes. Por outro lado, houve uma proliferação de ferramentas para usuários avançados que fornecem aos especialistas do zk um controle extremamente preciso sobre a pilha do zk.

O software moderno é construído em inúmeras camadas de abstração para maximizar a produtividade do especialista. Existem muitas vantagens da abstração na engenharia que são um tanto intuitivas – um desenvolvedor web não precisa entender como os sistemas operacionais funcionam em profundidade. 

A chave para construir boas camadas de abstração reutilizáveis ​​é encapsular a complexidade de uma camada e, em seguida, fornecer interfaces simples, porém expressivas, para as camadas mais altas da pilha usarem. Feito corretamente, isso permite que desenvolvedores com diferentes áreas de especialização e conhecimento criem ferramentas úteis em toda a pilha.

Não é surpresa que esses mesmos princípios se apliquem aos sistemas zk, e essas camadas de abstração estão amadurecendo o suficiente para que um novato em zk comece a usá-las e a criar aplicativos hoje.

Arkworks-rs é um ecossistema de bibliotecas Rust que fornece implementações eficientes e seguras dos subcomponentes de um aplicativo zkSNARK. O Arkworks fornece as interfaces necessárias para que os desenvolvedores personalizem a pilha de software para um aplicativo zk sem ter que reimplementar pontos em comum com outras bibliotecas existentes.

Antes do Arkworks, a única maneira de criar um novo aplicativo zk era criar tudo do zero. As principais vantagens do Arkworks-rs em relação às ferramentas personalizadas e integradas verticalmente são o nível de flexibilidade, a redução de engenharia duplicada e a redução do esforço de auditoria. As linhas de interface sensatas da Arkworks entre os componentes permitem um ritmo de atualização que pode manter a pilha relevante em meio ao ritmo alucinante da inovação em tecnologias zk, sem forçar as equipes a reconstruir tudo do zero.

Arkworks é para projetos que precisam de controle fino sobre toda a pilha de software zk, mas não querem construir todas as peças redundantes do zero. Se você está considerando uma versão personalizada de um circuito DSL porque, por exemplo, está prototipando um novo sistema de prova, mas não tem certeza do esquema de compromisso ou da curva elíptica correspondente, o arkworks permitirá que você troque rapidamente entre várias opções com interfaces compartilhadas, em vez do que começar do zero.

Para criar uma prova sobre algum cálculo, primeiro esse cálculo deve ser expresso de uma forma que um sistema zkSNARK possa entender. Várias linguagens específicas de domínio criaram linguagens de programação que permitem aos desenvolvedores de aplicativos expressar sua computação dessa maneira. Esses incluem Asteca Noir, Starknet Cairo, Circo, ZoKrates, e Aleo's Leão entre outros. O sistema de prova subjacente e os detalhes matemáticos geralmente não são expostos ao desenvolvedor do aplicativo.

Os desenvolvedores do zkApp devem se tornar proficientes em escrever seus programas em linguagens específicas de domínio. Algumas dessas linguagens se parecem muito com linguagens de programação familiares, enquanto outras podem ser bastante difíceis de aprender. Vamos decompor alguns deles:

Cairo – Starkware DSL necessário para criar aplicativos no Starknet. Compila em linguagem de montagem específica do Cairo que pode ser interpretada pelo Cairo zkVM.

ZoKrates — ZoKrates é um kit de ferramentas para necessidades comuns de SNARK, incluindo uma linguagem de alto nível para escrever circuitos. O ZoKrates também tem alguma flexibilidade em torno das curvas, esquema de prova e back-end, permitindo que os desenvolvedores façam hot-swap por um simples argumento CLI.

Circo — Circom é uma linguagem desenvolvida especificamente para a construção de circuitos. Atualmente, é a linguagem de fato para circuitos em produção. A linguagem não é especialmente ergonômica. A própria linguagem o torna consciente do fato de que você está escrevendo circuitos.

Leão — Leo foi desenvolvido como a linguagem para o blockchain Aleo. Leo tem uma sintaxe parecida com Rust e é feito especificamente para transições de estado dentro de um blockchain.

Noir – Sintaxe inspirada em Rust. Arquitetado em torno do IR em vez da linguagem em si, o que significa que pode ter um front-end arbitrário. 

Qualquer desenvolvedor de aplicativo que deseja aproveitar as propriedades exclusivas do zk em seu aplicativo. Algumas dessas linguagens foram testadas em batalha com bilhões de dólares movimentando-se por meio de cadeias como ZCash e Starknet. Embora alguns dos projetos que discutiremos ainda não estejam prontos para uso em produção, escrever seus circuitos em uma dessas linguagens é atualmente a melhor estratégia, a menos que você precise dos controles mais precisos que um kit de ferramentas como o Arkworks oferece.

O objetivo principal de um zkEVM é fazer uma transição de estado Ethereum e provar sua validade usando uma prova sucinta de conhecimento zero de correção. Conforme mencionado na postagem de Vitalik, há várias maneiras de fazer isso com diferenças sutis e compensações correspondentes. 

A principal diferença técnica entre todos eles é exatamente onde na pilha de linguagem a computação é convertida em uma forma (aritmetização) que pode ser usada em um sistema de prova. Em alguns zkEVMs, isso acontece nas linguagens de alto nível (Solidity, Vyper, Yul), enquanto outras abordagens tentam provar o EVM até o nível do opcode. As vantagens e desvantagens entre essas abordagens foram abordadas profundamente no post de Vitalik, mas vou resumi-las em uma frase: Quanto menor a conversão/aritmetização acontecer na pilha, maior será a penalidade de desempenho.

O principal desafio na criação de provas para uma máquina virtual é que o tamanho do circuito cresce proporcionalmente ao tamanho de TODAS as instruções possíveis para cada instrução executada. Isso ocorre porque o circuito não sabe quais instruções serão executadas em cada programa, por isso precisa suportar todas elas.

O que isso significa na prática é que você paga (em custo de desempenho) pela instrução mais cara possível, mesmo quando estiver executando apenas a instrução mais simples. Isso leva a uma troca direta entre generalização e desempenho – à medida que você adiciona mais instruções para generalização, você paga por isso em cada instrução você prova!

Este é um problema fundamental com circuitos universais, mas com novidades em tecnologias como IVC (computação verificável incremental), essa limitação pode ser melhorada dividindo a computação em partes menores, cada uma com subcircuitos menores e especializados.

As implementações atuais do zkEVM usam estratégias diferentes para mitigar o impacto desse problema... Por exemplo, o zkSync extrai as operações mais caras (principalmente pré-compilações criptográficas como hashes e ECDSA) do circuito principal de verificação de execução em circuitos separados que são agregados no terminar via recursão snark. O zkSync adotou essa abordagem depois que percebeu que a maioria de seus custos vinha de algumas instruções complexas.

No fundo, a razão pela qual provar um conjunto de instruções mais equivalente ao EVM é mais caro é que o EVM não foi projetado para cálculos zk. Abandonar o EVM no início da pilha permite que os zkEVMs sejam executados em conjuntos de instruções que são mais otimizados para zk e, portanto, mais baratos de provar.

Os clientes ideais para um zkEVM são aplicativos de contrato inteligente que precisam de transações de ordens de magnitude mais baratas do que as disponíveis no L1 Ethereum. Esses desenvolvedores não têm necessariamente experiência ou largura de banda para escrever aplicativos zk do zero. Portanto, eles preferem escrever seus aplicativos em linguagens de alto nível com as quais estão familiarizados, como o Solidity. 

Escalando Ethereum é atualmente a aplicação mais exigida da tecnologia zk.

Um zkEVM é uma solução de dimensionamento Ethereum que mitiga sem atrito o problema de congestionamento que restringe os desenvolvedores L1 dApp.

O objetivo de um zkEVM é oferecer suporte a uma experiência de desenvolvedor que seja o mais próxima possível do desenvolvimento atual do Ethereum. O suporte Full Solidity significa que as equipes não precisam criar e manter várias bases de código. Isso é um tanto impraticável de se fazer perfeitamente porque os zkEVMs precisam negociar alguma compatibilidade para poder gerar provas de tamanho razoável em um período de tempo razoável.

A principal diferença entre zkSync e Scroll é onde/quando na pilha eles executam aritmetização – isto é, onde eles convertem de construções EVM normais em uma representação compatível com SNARK. Para zkSync, isso acontece quando eles convertem o bytecode YUL em seu próprio conjunto de instruções zk personalizado. Para Scroll, isso acontece no final, quando o rastreamento de execução real é gerado com opcodes EVM reais.

Então, para o zkSync, tudo é igual a interagir com o EVM até que o bytecode zk seja gerado. Para Scroll, tudo é o mesmo até que o bytecode real seja executado. Esta é uma diferença sutil, que troca desempenho por suporte. Por exemplo, zkSync não suporta ferramentas de bytecode EVM como um depurador pronto para uso, porque é um bytecode completamente diferente. Enquanto Scroll terá mais dificuldade em obter um bom desempenho de um conjunto de instruções, isso não foi projetado para zk. Existem prós e contras em ambas as estratégias e, em última análise, existem muitos fatores exógenos que afetarão seu sucesso relativo.

💡 Apesar de sua nomenclatura, LLVM não é uma VM (máquina virtual). LLVM é o nome de um conjunto de ferramentas do compilador que é ancorado por uma representação intermediária (IR) independente de linguagem.

=nulo; Fundação (sobre o nome, é uma piada de injeção SQL se você está se perguntando) está construindo um compilador que pode converter qualquer linguagem de front-end LLVM em uma representação intermediária que pode ser comprovada dentro de um SNARK. O zkLLVM é arquitetado como uma extensão da infraestrutura LLVM existente, uma cadeia de ferramentas padrão do setor que oferece suporte a muitas linguagens de alto nível, como Rust, C, C++ etc.

Um usuário que deseja provar algum cálculo simplesmente implementaria esse cálculo em C++. O zkLLVM pega esse código-fonte de alto nível que é suportado por seu compilador clang modificado (atualmente C++) e gera alguma representação intermediária do circuito. Neste ponto, o circuito está pronto para ser testado, mas o usuário pode querer provar o circuito com base em algumas entradas dinâmicas. Para lidar com entradas dinâmicas, o zkLLVM possui um componente adicional denominado atribuidor, que gera uma tabela de atribuição com todas as entradas e testemunhas totalmente pré-processadas e prontas para serem comprovadas ao longo do circuito.

Esses 2 componentes são tudo o que é necessário para gerar uma prova. Um usuário pode, teoricamente, gerar uma prova sozinho, mas como essa é uma tarefa computacional um tanto especializada, ele pode querer pagar a outra pessoa, que tenha o hardware, para fazer isso por ele. Para este mecanismo de descoberta de contraparte, =nil; A Foundation também estabeleceu um 'mercado de prova' onde os provadores competem para provar a computação para usuários que os pagarão para fazê-lo. Essa dinâmica de mercado livre levará os provadores a otimizar as tarefas de prova mais valiosas.

Uma vez que cada tarefa computacional a ser provada é única e gera um circuito diferente, há um número infinito de circuitos que os provadores precisarão ser capazes de manipular. Essa generalização forçada dificulta a otimização de circuitos individuais. A introdução de um proof market permite a especialização nos circuitos que o mercado considera valiosos. Sem esse mercado, seria um desafio convencer um provador a otimizar esse circuito por causa desse problema natural de partida a frio.

A outra compensação é a clássica abstração versus controle. Os usuários que desejam usar essa interface fácil de usar estão abrindo mão do controle sobre as primitivas criptográficas subjacentes. Para muitos usuários, essa é uma compensação muito válida, pois geralmente é melhor deixar que os especialistas em criptografia tomem essas decisões por você.

Um zkVM descreve o superconjunto de todas as máquinas virtuais zk, enquanto um zkEVM é um tipo específico de zkVM, que vale a pena discutir como um tópico separado por causa de sua prevalência hoje. Existem alguns outros projetos que estão trabalhando na construção de zkVMs mais generalizados que são baseados em ISAs além das VMs criptográficas sob medida.

Em vez de provar o EVM, o sistema poderia provar uma arquitetura de conjunto de instruções (ISA) diferente, como RISC-V ou WASM em uma nova VM. Dois projetos que estão trabalhando nesses zkVMs generalizados são RISC Zero e zkWASM. Vamos mergulhar um pouco no RISC Zero aqui para demonstrar como essa estratégia funciona e algumas de suas vantagens/desvantagens. 

O RISC Zero é capaz de provar qualquer computação executada em uma arquitetura RISC-V. O RISC-V é um padrão de arquitetura de conjunto de instruções (ISA) de código aberto que vem ganhando popularidade. A filosofia RISC (computador com conjunto reduzido de instruções) é construir um conjunto de instruções extremamente simples com complexidade mínima. Isso significa que os desenvolvedores das camadas mais altas da pilha acabam assumindo uma carga maior na implementação de instruções usando essa arquitetura, ao mesmo tempo em que tornam a implementação de hardware mais simples.

Essa filosofia também se aplica à computação em geral. Os chips ARM têm aproveitado os conjuntos de instruções no estilo RISC e começaram a dominar o mercado de chips móveis. Acontece que os conjuntos de instruções mais simples também têm maior eficiência de energia e área de matriz.

Essa analogia vale muito bem para a eficiência de geração de provas zk. Conforme discutido anteriormente, ao provar um rastreamento de execução em zk, você paga pela soma do custo de todas as instruções por cada item no rastreamento, portanto, instruções mais simples e menos totais são melhores.

Do ponto de vista do desenvolvedor, usar o RISC Zero para lidar com provas zk é muito parecido com o uso de funções do AWS Lambda para lidar com a arquitetura do servidor de back-end. Os desenvolvedores interagem com RISC Zero ou AWS Lambda simplesmente escrevendo código e o serviço lida com toda a complexidade do back-end.

Para RISC Zero, os desenvolvedores escrevem Rust ou C++ (eventualmente qualquer coisa voltada para RISC-V). O sistema então pega o arquivo ELF gerado durante a compilação e o usa como código de entrada para o circuito VM. Os desenvolvedores simplesmente chamam prove que retorna um objeto recibo (que contém a prova zk do rastreamento de execução) que qualquer um pode chamar `verify` de qualquer lugar. Do ponto de vista do desenvolvedor, não há necessidade de entender como o zk funciona, o sistema subjacente lida com toda essa complexidade.

Para alguns circuitos básicos e reutilizáveis ​​que são particularmente úteis para aplicativos blockchain ou em outro lugar, as equipes podem já ter construído e otimizado esses circuitos para você. Você pode apenas fornecer a entrada para seu caso de uso específico. Uma prova de inclusão Merkle, por exemplo, é algo comumente necessário em aplicativos de criptografia (listas de lançamento aéreo, Tornado Cash, etc). Como desenvolvedor de aplicativos, você sempre pode reutilizar esses contratos testados em batalha e apenas modificar as camadas superiores para criar um aplicativo exclusivo.

Por exemplo, os circuitos do Tornado Cash podem ser reutilizados para um aplicativo airdrop privado ou um aplicativo de votação privada. Manta e Semaphore estão construindo todo um conjunto de ferramentas de dispositivos de circuito comuns como este que podem ser usados ​​em contratos Solidity com pouco ou nenhum entendimento da matemática subjacente do zk moon.

Conforme discutido detalhadamente, há uma infinidade de opções diferentes para desenvolver um aplicativo zk, todas com seu próprio conjunto exclusivo de compensações. Este gráfico ajudará a resumir esta matriz de decisão para que, com base em seu nível de experiência em zk e necessidades de desempenho, você possa escolher a melhor ferramenta para o trabalho. Esta não é uma lista abrangente, pretendo adicioná-la no futuro, à medida que ficar ciente de mais ferramentas surgindo no espaço.

zk está na vanguarda de várias tecnologias, e construí-lo requer um profundo conhecimento de matemática, criptografia, ciência da computação e engenharia de hardware. No entanto, com mais e mais camadas de abstração disponíveis a cada dia, os desenvolvedores de aplicativos podem aproveitar o poder do zk sem um Ph.D. Como as limitações dos tempos de prova são levantadas lentamente ao longo do tempo por meio de otimizações em todos os níveis da pilha, provavelmente veremos ferramentas ainda mais simples para o desenvolvedor médio.

Espero ter convencido você, o curioso desenvolvedor de software, de que pode começar a usar o zk em seus aplicativos hoje mesmo. Feliz Hacking 🙂

Divulgações: A Blockchain Capital é investidora em vários dos protocolos mencionados acima.

As opiniões expressas em cada postagem do blog podem ser as opiniões pessoais de cada autor e não refletem necessariamente as opiniões da Blockchain Capital e suas afiliadas. Nem a Blockchain Capital nem o autor garantem a precisão, adequação ou integridade das informações fornecidas em cada postagem do blog. Nenhuma representação ou garantia, expressa ou implícita, é feita ou dada por ou em nome da Blockchain Capital, o autor ou qualquer outra pessoa quanto à precisão, integridade ou justiça das informações contidas em qualquer postagem do blog e nenhuma responsabilidade ou responsabilidade é aceita para tais informações. Nada contido em cada postagem do blog constitui conselho de investimento, regulatório, jurídico, de conformidade ou tributário ou outro, nem deve ser considerado na tomada de uma decisão de investimento. As postagens do blog não devem ser vistas como recomendações ou solicitações atuais ou passadas de uma oferta para comprar ou vender quaisquer valores mobiliários ou para adotar qualquer estratégia de investimento. As postagens do blog podem conter projeções ou outras declarações prospectivas, baseadas em crenças, suposições e expectativas que podem mudar como resultado de muitos eventos ou fatores possíveis. Se ocorrer uma mudança, os resultados reais podem variar materialmente daqueles expressos nas declarações prospectivas. Todas as declarações prospectivas falam apenas a partir da data em que tais declarações são feitas, e nem a Blockchain Capital nem cada autor assumem qualquer dever de atualizar tais declarações, exceto conforme exigido por lei. Na medida em que quaisquer documentos, apresentações ou outros materiais produzidos, publicados ou distribuídos de outra forma pela Blockchain Capital sejam referenciados em qualquer postagem de blog, tais materiais devem ser lidos com atenção cuidadosa a quaisquer isenções de responsabilidade fornecidas neles.