A16z：Elementos essenciais para construtores: ‘Jolt Inside’

nenhum

Autor do artigo: a16z crypto

Tradução do artigo: Block unicorn

Prefácio

Hoje, a LayerZero lançou a 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 “simples”), rápida, segura e fácil de usar. Representa uma nova e avançada abordagem de design SNARK, desenvolvida ao longo de três anos pela a16z crypto, que será open source para que qualquer pessoa possa usar ou desenvolver ainda mais. Mas a história do Jolt é, na verdade, uma narrativa de décadas de maturação.

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

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

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

Mas por que zkVMs são tão importantes? zkVMs e, de forma mais ampla, SNARKs (provas de conhecimento não interativas e compactas) são componentes essenciais para escalabilidade, privacidade e segurança em blockchain. 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; abordaremos isso com mais detalhes a seguir. No entanto, o Jolt desde o início foca em uma abordagem radicalmente diferente de design SNARK, visando maior eficiência, usabilidade e desempenho.

Resumindo, uma 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 usam esses recursos 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 de computador que escreveram.

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

A LayerZero está empenhada em levar o provador Jolt para produção em GPUs, incluindo versões otimizadas para GPU desenvolvidas em parceria, essenciais 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. O open source é um multiplicador de força: 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 uma firma de venture capital, mas a estrutura do desenvolvimento moderno faz com que grande parte do trabalho seja feito internamente — seja em laboratórios corporativos ou em fundações acadêmicas. Nosso objetivo ao criar a a16z crypto é estabelecer um laboratório de pesquisa industrial e uma equipe de engenharia que conectem teoria acadêmica à prática do setor. Como VC, podemos financiar projetos que outras instituições não podem, especialmente em investimentos contrários.

A abordagem de design reverso de SNARKs que suporta o SNARK é particularmente importante para o Jolt, pois representa uma mudança de paradigma significativa e radical. 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 design SNARK do Jolt, precisamos voltar mais de duas mil anos: os gregos antigos desenvolveram os primeiros sistemas formalizados de provas matemáticas, que foram posteriormente 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, permitindo que qualquer pessoa as verificasse. 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 prova estática, escrita, é uma manifestação do clássico problema NP na teoria da complexidade “P vs NP”.

É importante notar que esse método tradicional de prova é sequencial, requerendo uma troca de passos: é 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, eles apresentaram a ideia alguns anos antes, mas seu artigo foi rejeitado várias vezes antes de ser aceito.] A ideia central é que, se duas partes (por exemplo, matemáticos) podem interagir em tempo real, eles não precisam esperar que uma escreva uma prova completa para convencer a outra. Em vez disso, podem fazer perguntas em tempo real; ou seja, a prova pode ser explorada por interação.

A grande força das provas interativas — em comparação com as provas tradicionais gregas — só foi plenamente reconhecida em 1990, com a introdução do protocolo de soma-verificação por Carsten Lund, Lance Fortnow, Howard Karloff e Noam Nisan. Essa abordagem algébrica para sistemas de provas interativas, combinada com trabalhos posteriores de Adi Shamir, levou à conclusão fundamental de que IP = PSPACE — uma afirmação técnica que, na prática, significa que:

Se o provador e o verificador podem interagir — como em sistemas tradicionais de prova challenge-response (desafio-resposta), onde um mentiroso não consegue responder a desafios impossíveis — então podemos verificar afirmações mais complexas de forma rápida, em comparação com as provas estáticas tradicionais.

Em outras palavras: a interatividade confere uma vantagem enorme aos sistemas de prova. A técnica de soma-verificação (sum-check) é o núcleo que transforma essa vantagem em uma verificação eficiente — permitindo que o verificador valide o resultado alegado sem precisar reconstruir toda a execução do cálculo.

Alguns anos depois, Joe Kilian propôs construir provas de conhecimento verificáveis probabilísticas (PCP), que geram provas compactas e verificáveis com alta confiança. No paradigma PCP, o provador (como um matemático grego, mas agora uma máquina) escreve uma prova redundante em um “livro”. A verificação, no entanto, não exige leitura completa: o verificador pode aleatoriamente escolher algumas posições — por exemplo, três “palavras” no livro — e, com alta probabilidade, determinar se a prova é válida.

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

Kilian mostrou como combinar PCP com criptografia, permitindo que o provador “comprometa” a prova longa, e só divulgue algumas partes — as palavras escolhidas — acompanhadas de uma prova criptográfica curta. O resultado final é que a prova consiste apenas nessas palavras (mais alguns dados criptográficos), o suficiente para convencer o verificador de que toda a prova é válida.

Essas provas ainda eram interativas. Depois, Micali mostrou como aplicar a transformação 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.

Impacto duradouro da arquitetura antiga

Ao longo da história das provas, passamos de sistemas estáticos para interativos, depois para provas probabilísticas e não interativas (PCP), depois de volta para interativos (Kilian), e finalmente para não interativos (Micali). SNARKs aparecem no final dessa evolução: ao aplicar a transformação Fiat-Shamir às provas de Kilian, Micali criou a primeira construção de SNARK.

No entanto, esses SNARKs baseados em PCP tinham um grande problema: o trabalho do provador era muito pesado — demorava demais para gerar provas práticas.

Apesar disso, o método de design de SNARKs permaneceu por décadas. Mesmo quando a indústria tentou fugir do paradigma PCP, os designers continuaram usando conceitos relacionados (como “SNARKs lineares”), que eram apenas variações heurísticas do PCP. Embora esses métodos gerassem SNARKs extremamente curtos, eles não eram os mais rápidos para o provador.

Os designers de SNARKs nunca voltaram às raízes — ao protocolo de soma-verificação — para obter provas mais rápidas e fáceis de usar com a tecnologia moderna.

Se quisermos adotar a soma-verificação mais cedo, precisaríamos reexaminar toda a história e evolução do SNARK de uma perspectiva não linear. Desde (a) prova interativa → (b) PCP → © prova interativa simples → (d) SNARKs iniciais, a indústria passou por várias mudanças:

Na transição de (a) para (b), o principal desafio foi remover a interatividade mantendo a simplicidade da validação — levando os projetistas a abandonar o uso do protocolo de soma-verificação (interativo).

Depois, na transição de (b) para ©, a interatividade voltou a aparecer… até que, por meio da transformação Fiat-Shamir, ela foi eliminada, levando à transição de © para (d).

Ao analisar linearmente esses passos, fica claro que os projetistas de SNARKs omitiram duas vezes a interatividade — uma na transição de (a) para (b), outra de © para (d).

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

Por que mais pessoas não adotaram mais cedo o design baseado em soma-verificação? Talvez porque os primeiros SNARKs pareciam semelhantes aos PCPs, já que ambos buscavam provas curtas e verificáveis. Além disso, a arquitetura — e possíveis mal-entendidos — podem ter perpetuado essa confusão.

Para nós, investir pesado na tecnologia de zkVM baseada em soma-verificação, como o Jolt, é uma aposta contrária, pois desafia décadas de paradigma dominante em SNARKs.

‘Jolt Inside’

A abordagem de design SNARK do Jolt (baseada em avaliação em lote e mecanismos de verificação de memória, como Twist + Shout) combina provas interativas e protocolos de soma-verificação.

Hoje, anos após começarmos a construir o Jolt, outros também estão adotando protocolos de soma-verificação em seus designs. Então, quais são as principais características do Jolt na atual geração de zkVMs? O Jolt maximiza o uso de 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.

Em contraste, 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 anteriores: exigir que especialistas projetem circuitos específicos, o que aumenta 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 zkVM — 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 simplicidade e desempenho.

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

Mais importante, o Jolt é mais rápido e mais simples. Outros sistemas exigem que o projetista crie circuitos para cada instrução básica da VM, 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.

Qual será o próximo passo do Jolt?

Já estamos na vanguarda em velocidade. Com futuras otimizações e recursos — incluindo recursão e provas de zero conhecimento, especialmente na transição de criptografia de curvas elípticas para criptografia de grade — planejamos alcançar mais um nível de velocidade até o final do ano, sem falar do pós-quântico.

O Jolt torna mais acessíveis diversas aplicações. Para blockchain, a escalabilidade e descentralização tão aguardadas ficarão mais fáceis de implementar. Provas de conhecimento zero podem ser integradas prontamente, sem meses ou anos de engenharia criptográfica.

À medida que o Jolt evoluir — por exemplo, criando uma zkVM rápida e fácil de usar para 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 se tornar mais fáceis de manter e usar, com implementação simples e pronta para uso.

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 uma prova de 50 KB para demonstrar posse de um conjunto de dados de vários GB com atributos específicos — é tão poderosa que é difícil prever quais aplicações surgirão. As possibilidades são infinitas.