a16z：Elementos essenciais para os criadores: ‘Jolt Inside’

Autor do artigo: a16z crypto

Tradução do artigo: Block unicorn

Prefácio

Hoje, a LayerZero lançou sua nova cadeia Zero, que inclui vários avanços tecnológicos — incluindo uma nova abordagem de prova de conhecimento zero que desacopla a execução e a validação de transações. Tudo isso graças ao “Jolt Inside”.

O que é o Jolt? O Jolt é uma máquina virtual zk RISC-V de código aberto (ou mais precisamente, uma “máquina virtual” simplificada), rápida, segura e fácil de usar. Ele representa uma abordagem totalmente nova e avançada de design de SNARK, desenvolvida ao longo de três anos pela a16z crypto, e será open source para que qualquer pessoa possa usar ou desenvolver ainda mais. Mas a origem do Jolt é, na verdade, uma história que levou décadas para se formar.

Por que o design de zkVM e SNARK é tão importante?

Antes de explorar a evolução do design de SNARK, precisamos entender o que é uma zkVM.

Essas máquinas virtuais costumam ser chamadas de “zk”, mas a característica mais comum é a simplicidade. Embora “zero conhecimento” seja fundamental para a privacidade, “simplificado” significa provas curtas e fáceis de verificar — duas qualidades úteis, mas distintas, que muitas vezes são confundidas. (O Jolt já possui simplicidade e, em breve, também implementará zero conhecimento.)

Mas por que zkVMs são tão importantes? zkVMs e, de modo mais amplo, SNARKs (provas de conhecimento não interativas e compactas) são componentes essenciais para escalabilidade, privacidade e segurança de blockchains. Essas provas, argumentos e conhecimentos zero (coletivamente, tecnologias de computação verificável) têm inúmeras aplicações na indústria de criptografia e além.

Devido a arquiteturas tradicionais e outros fatores, a indústria até agora tem adotado abordagens relativamente complexas na construção de zkVMs; abordagens que serão detalhadas a seguir. No entanto, o Jolt desde o início foca em uma abordagem radicalmente diferente de design de SNARK, visando maior eficiência, usabilidade e desempenho.

Resumindo, zkVM é uma forma de provar que você executou corretamente um programa de computador. A vantagem do zkVM em relação a outros SNARKs é sua facilidade de uso para desenvolvedores. Ao aproveitar infraestruturas computacionais existentes (como o ecossistema de compiladores LLVM de código aberto), os desenvolvedores podem usar SNARKs em suas linguagens de programação preferidas, sem precisar de linguagens específicas de domínio (DSL).

Isso é bastante semelhante ao que ocorre em muitas áreas modernas de criptografia — temos padrões e bibliotecas embutidas para criptografia e assinaturas digitais — desenvolvedores comuns usam essas bibliotecas diariamente, sem precisar entender seu funcionamento interno. O Jolt oferece uma camada de abstração semelhante: basta usar programas existentes e validá-los, sem se preocupar com a interação entre eles. Essa é uma condição essencial para a popularização de novas aplicações criptográficas.

Os desenvolvedores podem focar na operação real. Com o Jolt, eles não precisam de conhecimentos especializados em SNARKs: basta clicar em um botão para gerar uma prova Jolt a partir do código que escreveram.

No entanto, mesmo com avanços, gerar provas de complexidade moderada (por exemplo, uma operação por um núcleo de CPU padrão por um segundo) ainda exige grande poder computacional. Para gerar provas complexas em tempo razoável, é necessário usar múltiplas GPUs. A LayerZero portou o gerador de provas Jolt para CUDA e lançou o Zero: uma implementação que combina algoritmos altamente paralelizáveis do Jolt com hardware GPU, alcançando maior escalabilidade.

A LayerZero está empenhada em levar o gerador de provas Jolt para produção em GPUs, incluindo versões otimizadas para GPU em colaboração conosco, o que é crucial para melhorar a escalabilidade de zkVMs e provas.

Pesquisa e desenvolvimento open source

O Jolt é open source, portanto qualquer pessoa pode usar ou desenvolver com base em suas inovações. Open source é o multiplicador definitivo: compartilhar resultados publicamente permite que mais pessoas na ecossistema usem, reutilizem, testem, auditem, corrijam e inovem ainda mais.

Investir em projetos open source pode parecer incomum para fundos de risco, mas a estrutura do desenvolvimento moderno faz com que grande parte do trabalho seja feito internamente — seja em laboratórios corporativos no passado ou em fundações hoje — ou na academia. Nosso objetivo ao criar a a16z crypto é construir um laboratório de pesquisa industrial e uma equipe de engenharia que conecte teoria acadêmica à prática do setor. Como fundo de risco, podemos financiar projetos que outras instituições não podem, especialmente em cenários de investimento reverso.

A abordagem de design reverso de SNARKs é especialmente importante para o Jolt, pois representa uma mudança de paradigma radical em relação às abordagens tradicionais. Essa evolução de design levou anos para se consolidar.

Histórias de inovação geralmente envolvem mudanças de arquitetura

Para entender a grande mudança na abordagem de SNARKs do Jolt, precisamos voltar mais de duas mil anos: os gregos antigos desenvolveram os primeiros sistemas formalizados de provas matemáticas, que posteriormente foram expandidos por estudiosos do Oriente Médio, Ásia e outras regiões.

Essas provas iniciais — deduções lógicas escritas passo a passo — eram registradas em linguagem formal ou fórmulas, para que qualquer pessoa pudesse verificar. Por exemplo, um matemático poderia escrever uma prova em um “livro”, e outro poderia lê-la palavra por palavra para verificar sua validade. Essa ideia de provas estáticas, escritas, é a essência do que chamamos de NP na teoria de complexidade “P vs NP”.

É importante notar que esse método tradicional de prova é sequencial, requerendo que as partes se alternem: é uma prova estática, não interativa.

Avançando para 1985*, Shafi Goldwasser, Silvio Micali e Charles Rackoff propuseram o conceito de provas interativas (“IP”).[*Na verdade, o artigo foi submetido alguns anos antes, mas foi rejeitado várias vezes antes de ser aceito.] A ideia central das provas interativas é que, por exemplo, dois matemáticos podem trocar mensagens em tempo real, sem precisar esperar que uma parte escreva uma prova completa para convencer a outra. Em outras palavras, a interação permite explorar a validade da prova por meio de perguntas e respostas.

A grande força das provas interativas — em comparação com as provas tradicionais, estáticas, gregas — só foi plenamente reconhecida cinco anos depois, em 1990. Nesse ano, Carsten Lund, Lance Fortnow, Howard Karloff e Noam Nisan propuseram o protocolo de soma de verificações: uma técnica algébrica para sistemas de provas interativas. Com o trabalho subsequente de Adi Shamir, isso levou à conclusão fundamental “IP=PSPACE” — uma afirmação técnica que, na prática, expressa que:

Se o provador e o verificador podem interagir — como em sistemas de prova tradicionais de desafio-resposta (onde um mentiroso não consegue responder às perguntas de forma convincente) — então podemos verificar afirmações mais complexas de forma rápida, em comparação com as provas estáticas gregas.

Em outras palavras: a interatividade nos dá uma vantagem enorme na verificação de provas. A técnica de soma de verificações (sum-check) é o núcleo que transforma essa vantagem em verificações eficientes — permitindo que o verificador valide o resultado alegado sem precisar reconstruir toda a computação subjacente.

Anos depois, Joe Kilian propôs construir provas de conhecimento verificáveis probabilísticas (PCP) a partir de provas. Na teoria PCP, o provador (que podemos imaginar como um matemático grego, mas agora um computador) escreve uma prova “recheada” em um livro, com alta redundância. O interessante é que essa redundância permite ao verificador, ao invés de ler o livro inteiro, apenas consultar aleatoriamente alguns poucos trechos — por exemplo, três palavras — e, com alta confiança, decidir se a prova é válida.

Porém, o problema é que provas PCP são longas, mesmo que a verificação seja barata.

Kilian mostrou como combinar PCP com criptografia, permitindo que o provador “comprometa-se” com a prova completa, e só divulgue alguns trechos com uma certificação criptográfica curta. O resultado final do protocolo de Kilian é essa pequena “porção” de prova (mais alguns dados criptográficos) — suficiente para convencer o verificador de que toda a prova é válida.

Na época, essas provas ainda eram interativas. Depois, Micali mostrou como aplicar a transformação de Fiat-Shamir para converter provas interativas baseadas em PCP em provas não interativas. Em resumo, a transformação Fiat-Shamir “elimina” o desafio aleatório do verificador, permitindo que o provador gere o desafio por conta própria e apresente uma prova única e completa.

Impacto duradouro das arquiteturas tradicionais

Ao longo da história dos sistemas de prova, vimos uma evolução de sistemas estáticos para interativos, depois para probabilísticos e não interativos (PCP), depois de volta para interativos (Kilian), e finalmente para não interativos (Micali). SNARKs aparecem no final dessa cadeia: ao aplicar a transformação de Fiat-Shamir às provas de Kilian, Micali criou o que hoje chamamos de primeiro SNARK.

Porém, esses SNARKs baseados em PCP tinham um grande problema: a carga de trabalho do provador era enorme — demorava demais para gerar as provas — dificultando sua implementação prática.

Apesar disso, o método de design de SNARKs permaneceu por décadas. Mesmo quando a indústria tentou fugir do paradigma baseado em PCP, os designers continuaram usando conceitos relacionados (como “PCP linear”), que na verdade eram variações de técnicas inspiradas em PCP. Essas abordagens geraram SNARKs extremamente curtos, mas não as mais rápidas para o provador.

Por muito tempo, os projetistas de SNARKs não voltaram às suas raízes — ao protocolo de soma de verificações — para obter provas mais rápidas e fáceis de usar, que hoje já seriam possíveis com o poder de computação atual.

Se quisermos adotar o protocolo de soma de verificações mais cedo, precisaríamos reavaliar toda a história e evolução dos SNARKs de forma não linear. Desde (a) prova interativa → (b) PCP → © prova interativa simplificada → (d) SNARKs iniciais, a indústria passou por várias mudanças:

Na transição de (a) para (b), o principal desafio foi como manter a simplicidade da verificação ao remover a interatividade do sistema. Isso levou os projetistas a abandonarem o protocolo de soma de verificações (a parte interativa).

Por outro lado, na transição de (b) para ©, a interatividade voltou a aparecer… e, por fim, foi eliminada novamente com a transformação de Fiat-Shamir, levando à transição de © para (d).

Ao analisar linearmente esses passos — (a) → (b) → © → (d) — fica claro que os projetistas de SNARKs omitiram duas vezes a interatividade: uma ao passar de (a) para (b), e outra ao passar de © para (d).

Se quisermos usar Fiat-Shamir para eliminar a interatividade, deveríamos pular diretamente a etapa intermediária (b), ou seja, os PCPs verificáveis probabilísticos! Pular essa etapa é a chave por trás do método Jolt, que constrói SNARKs diretamente a partir de provas interativas — indo direto para a verificação por soma.

Por que mais pessoas não adotaram mais cedo o design baseado em protocolos de soma de verificações? Talvez porque os primeiros projetistas de SNARKs não tenham percebido essa possibilidade, já que PCP e SNARKs parecem semelhantes — ambos visam provas curtas e verificações rápidas. Além disso, a arquitetura — e possíveis mal-entendidos — podem ter perpetuado essa visão.

Para nós, investir pesado no desenvolvimento do zkVM baseado em soma de verificações, como o Jolt, é uma aposta contrária à abordagem dominante de décadas na área de SNARKs.

‘Jolt Inside’

A abordagem de design de SNARK do Jolt (que também usa avaliação em lote e mecanismos de verificação de memória, como Twist + Shout) é baseada em provas interativas e protocolos de soma de verificações.

Hoje, anos após começarmos a construir o Jolt, outros também estão adotando protocolos de soma de verificações em seus projetos. Então, quais são as principais características do Jolt na atual geração de zkVMs? O Jolt maximiza o aproveitamento das estruturas repetitivas na execução de CPU. Ao observar como o ciclo “busca-decodifica-executa” de cada núcleo de CPU se aplica ao mecanismo de avaliação em lote, o Jolt consegue uma eficiência incomparável com complexidade mínima.

Por outro lado, outros zkVMs dependem fortemente de “pré-compilados” (semelhantes a aceleradores ASIC para subprogramas específicos) para alcançar desempenho razoável. O Jolt rejeita esses pré-compilados, pois eles repetem o erro das abordagens tradicionais de SNARK antes do advento do zkVM: exigir que especialistas projetem circuitos específicos, o que aumenta a chance de bugs e dificulta o uso por desenvolvedores comuns. O foco do Jolt é democratizar o SNARK.

Verificar a correção da execução da CPU é o núcleo do valor do zkVM — e uma grande inovação na experiência do desenvolvedor — pois permite reutilizar infraestruturas de computação geral, já existentes e reforçadas. As infraestruturas globais de computação são construídas para suportar CPUs, e o Jolt aproveita ao máximo essa “estrutura” inerente à execução de CPU, elevando a simplicidade e o desempenho.

Desde o início, o Jolt priorizou usabilidade e desempenho de nível de produção: os desenvolvedores podem validar programas existentes imediatamente; mesmo para validações rápidas, sem precisar modificar o código. O Jolt não força equipes a reestruturarem aplicações em torno de “pré-compilados” ou APIs especiais — mantém o código original intacto, facilitando adoção, auditoria e iteração de custos menores.

Mais importante, o Jolt é mais rápido e mais simples. Outros projetos exigem que os projetistas de zkVM criem circuitos para cada instrução básica, enquanto o Jolt não — cada instrução básica pode ser definida com cerca de dez linhas de código em Rust. Sem circuitos, apenas dez linhas de código.

Próximos passos do Jolt

Já estamos na vanguarda em velocidade. Com otimizações adicionais e recursos como recursão e provas de zero conhecimento — especialmente com a transição de criptografia de curvas elípticas para criptografia de grade —, planejamos alcançar mais um nível de velocidade ainda este ano, sem falar na era pós-quântica.

O Jolt torna mais viáveis muitas aplicações. Para blockchains, a escalabilidade e descentralização há muito esperadas ficarão mais fáceis de implementar. Provas de conhecimento zero podem ser usadas imediatamente, sem meses ou anos de engenharia criptográfica.

À medida que o Jolt evoluir — por exemplo, criando uma máquina virtual de provas rápidas e simples, compatível com smartphones e laptops — os desenvolvedores poderão desbloquear mais casos de uso na ponta do cliente e na privacidade. Aplicações de privacidade em celulares, por exemplo, podem passar de soluções difíceis de manter e quase inviáveis de rodar, para algo de fácil implementação e uso imediato.

No longo prazo, esses sistemas de prova se tornarão componentes centrais da infraestrutura digital global, semelhantes à criptografia e assinaturas digitais. Essa tecnologia de compressão criptográfica universal — onde qualquer pessoa pode enviar um arquivo de prova de 50 KB para demonstrar que possui GBs de dados que atendem a certos atributos — é tão poderosa que é difícil prever todas as aplicações que virão. As possibilidades são infinitas.