Discurso de Gavin Wood: Situação da entrega do JAM e estratégia de médio e longo prazo para introduzir ZK no JAM!

Este é o texto traduzido da palestra de Gavin Wood no Web3 Summit do mês passado! Como o conteúdo desta série é extenso, vamos publicá-lo em quatro partes. Este é o primeiro capítulo, com foco nos seguintes tópicos:

• Status da entrega do JAM
• O desempenho do ZK melhorou, mas ainda está longe de ser comercial
• 33 recomputações vs. prova matemática: o custo real de dois modelos de segurança
• Quanto custa rodar um nó ZK-JAM? A resposta é 10 vezes mais caro do que você imagina!
• Evolução de curto, médio e longo prazo do ZK no JAM

Vamos conferir as ideias interessantes que Gavin compartilhou!

Então, sem mais delongas, sobre o que vou falar nesta palestra?

Primeiro, quero compartilhar minha visão geral sobre Polkadot, ou seja, minha posição de pensamento atual, que pode ser entendida como um “instantâneo do momento”. Talvez vocês já tenham ouvido falar do JAM — um projeto que venho pesquisando há muito tempo e que está intimamente ligado ao Polkadot. Esperamos que ele possa, eventualmente, sustentar a próxima fase de desenvolvimento do Polkadot. Além disso, falarei sobre tecnologias de criptografia de conhecimento zero (ZK), especialmente sua aplicação na expansão das funcionalidades do blockchain.

Também vou abordar o modelo econômico do token DOT. Em seguida, apresentarei algumas novidades que venho pesquisando recentemente, com o objetivo de aprimorar as capacidades existentes e até mesmo trazer novas possibilidades para o Polkadot e o universo Web3 em geral. Essa parte abrange vários aspectos, alguns com mais detalhes, outros apenas superficialmente. Ok, vamos começar oficialmente.

Status atual da entrega do JAM

A versão inicial do JAM é a 0.1, e estamos avançando gradualmente para a 1.0. Quando chegar à 1.0, isso significará que o protocolo JAM estará pronto para ser utilizado na atualização do Polkadot. À medida que o protocolo se estabiliza, nosso foco se volta para a otimização, especialmente a modelagem de gas. No início deste ano, fiz uma palestra sobre esse tema na conferência Ethereum em Praga (East Prague). A modelagem de gas é um tema muito interessante, mas também extremamente complexo.

O JAM deve iniciar a auditoria do protocolo ainda este ano. No ciclo da versão 0.7, restam poucos trabalhos; já na 0.8, a modelagem de gas será oficialmente introduzida, aumentando significativamente a carga de trabalho. Espero que possamos avançar para a versão 0.9 ainda este ano e, então, iniciar formalmente a auditoria.

Claro, ter um protocolo central é uma coisa, mas poder desenvolver sobre ele é outra. Você precisa de SDKs, documentação e outras ferramentas de desenvolvimento. Esta parte ainda está em estágio inicial. Embora já seja possível desenvolver software no JAM, na Parity, sou eu quem está liderando a construção e o lançamento do SDK. No entanto, na prática, isso ainda exigirá meses ou até anos de investimento e aprimoramento contínuos. Obviamente, o desenvolvimento do SDK não ficará restrito à Parity. Espero que mais equipes se juntem para construir seus próprios SDKs JAM.

Já começamos a definir padrões para mensagens entre serviços, que podem ser vistos como a versão JAM do XCM/XCMP. Ao mesmo tempo, o CoreVM está se tornando parte do SDK e será aprimorado nos próximos meses. O CoreVM já suporta várias funções, como saída de áudio, saída de vídeo, entrada/saída de dados, processamento de transações e serviços internos que estão por vir. Atualmente, ele ainda não suporta EVM, mas isso está nos nossos planos. Além disso, o mecanismo que eu chamava de coreplay (agendamento colaborativo central) também está planejado para ser implementado nos próximos 12 a 24 meses.

Recentemente, em um grupo de bate-papo do JAM, alguém fez uma pergunta interessante: como evitar que eu mesmo me torne um ponto único de falha do JAM? Atualmente, a evolução do protocolo JAM depende totalmente do que escrevo no Gray Paper. Isso significa que, se algo acontecer comigo, o projeto pode ficar paralisado. Obviamente, isso não é bom nem para o JAM nem para mim.

Portanto, tratamos o conteúdo do Gray Paper como a especificação técnica do JAM. O Gray Paper mais recente é o JAM mais recente. Se uma versão do Gray Paper já foi auditada, o protocolo JAM definido por ela é considerado maduro para produção, de forma direta.

Então, no futuro, se a atualização do Gray Paper não depender mais só de mim, como ela vai evoluir?

Minha ideia é criar um comitê editorial. Os membros iniciais serão aqueles que realmente participaram da redação do Gray Paper, têm profundo entendimento e fizeram contribuições substanciais. Espero que esses membros mantenham alto nível de envolvimento técnico na implementação do JAM. Eu mesmo não vou sair completamente, continuarei como editor-chefe, mas quero reduzir minha carga de trabalho e dar a outros o poder de propor, revisar e mesclar alterações.

À medida que o JAM ultrapassar a versão 1.0, esse comitê editorial assumirá responsabilidades de nível mais alto:

• Não apenas lidar com pequenas mudanças, mas decidir a direção e as prioridades do JAM;
• Quando houver opiniões divergentes, o julgamento coletivo do comitê deve ser a voz mais importante.

Planejo nomear um vice para assumir o trabalho quando eu estiver ausente, de férias ou em outras situações. A longo prazo, os vices também serão responsáveis por selecionar, convidar e decidir novos membros do comitê editorial, garantindo que o mecanismo funcione de forma autônoma. No fim, espero que esse sistema de governança se torne gradualmente independente, até mesmo envolvendo organizações externas, como a Polkadot Fellowship.

De fato, pretendo colocar o Gray Paper sob uma licença aberta, ainda não decidi qual, mas provavelmente será uma licença copyleft, com algumas cláusulas para evitar abuso de patentes.

Quanto à governança do Polkadot, ela tem total autoridade para decidir qual protocolo rodar. Polkadot é um protocolo soberano, e o mecanismo de governança é a expressão dessa soberania. Atualmente, a governança do Polkadot já deixou claro: quer adotar o JAM. Isso é ótimo. Ao mesmo tempo, outras redes também podem escolher usar o JAM, pois é um protocolo aberto.

No futuro, se o JAM continuar evoluindo, Polkadot pode optar por acompanhar as versões mais recentes; se não gostar da direção do JAM, pode fixar em uma versão específica, modificar o protocolo central ou até bifurcar o Gray Paper. Isso mostra que o JAM é um sistema independente, e eu pessoalmente espero que ele mantenha uma relação de benefício mútuo com o Polkadot a longo prazo. Claro, se um dia seguirem caminhos separados, isso também é totalmente viável.

Enquanto ambos estiverem alinhados, espero que a governança do Polkadot participe ativamente e apoie o funcionamento do comitê editorial do Gray Paper. Se outros protocolos adotarem o JAM no futuro, também espero que participem de forma semelhante.

Bem, esse é o progresso atual do JAM, ou o estágio que está prestes a alcançar. Agora, quero falar sobre provas de conhecimento zero (ZK).

O desempenho do ZK melhorou, mas ainda está longe de ser comercial

Muita gente me pergunta: quando o ZK (prova de conhecimento zero) será realmente comercial?

Ethereum é muito entusiasta do ZK, e seu roadmap gira quase todo em torno do ZK. Já no JAM, usamos ZK apenas em alguns mecanismos especiais de consenso na construção de blocos, não dependemos dele no geral. Mas, mesmo assim, é uma questão que precisa ser pensada com seriedade:

• Quando o ZK poderá ser uma tecnologia realmente capaz de expandir a capacidade computacional e viável comercialmente?
• Já chegou esse momento?
• Se não, quanto tempo ainda falta?

Se você olhar materiais do ecossistema Ethereum (como ethprovers.com), verá números impressionantes, alegando que o ZK já é economicamente viável. Mas investigamos e descobrimos que esses números não são reais. A boa notícia é que, embora ainda não seja totalmente viável, a diferença diminuiu muito em relação a 18 meses atrás.

Por exemplo: atualmente, a máquina virtual do JAM, PVM (equivalente ao EVM do JAM), é cerca de 34% mais lenta que a execução nativa. Ou seja, se um programa leva 34 minutos em ambiente nativo, na PVM leva cerca de 100 minutos.

Esse resultado já é muito bom, estamos satisfeitos e ainda há espaço para melhorias.

Claro, em alguns casos a diferença é maior, como 50% ou mais. Especialmente em tarefas como hash SHA-1, a execução na PVM é mais lenta. Isso pode ser porque, no ambiente nativo, o compilador pode usar instruções SIMD ou outras otimizações, enquanto a PVM ainda não consegue.

Agora, vejamos outro número importante: este é o custo de gerar uma prova de execução usando o melhor provador que encontramos, o Succinct SP1 — ou seja, o custo extra em relação à execução direta na PVM. Lembre-se, a comparação é com a PVM, não com o ambiente nativo. A PVM já é cerca de 34% mais lenta que o nativo.

Os resultados atuais dos testes são: usamos a versão mais recente do software e assumimos apenas uma GPU (porque o código aberto só suporta uma GPU). Se fosse uma versão comercial fechada, talvez pudesse escalar para clusters de GPU, mas no ambiente open source, é assim. O teste foi o mesmo de antes, SHA-1 hash, para garantir a comparação.

Então, qual é a diferença?

Há 18 meses, fizemos um experimento semelhante, e os números eram muito maiores, na faixa de 60 milhões a 64 milhões. Agora, o custo caiu bastante.

Há dois motivos principais:

• Por um lado, o aluguel de GPU ficou mais barato;
• Por outro, o software foi muito otimizado, talvez melhorando uma ordem de magnitude ou mais.

Vale ressaltar que, há 18 meses, usamos o provador RISC-0, não o SP1. Mas, de qualquer forma, o resultado mostra: a tecnologia de ponta está avançando rápido, e o progresso é notável.

Até julho de 2025, usar o SP1 (provador da Succinct) para gerar uma prova de um execution trace é 306.451 vezes mais caro do que executar a mesma computação com segurança na PVM. Nos últimos 18 meses, o custo da prova caiu cerca de 200 vezes, mas esse número ainda é enorme. A tecnologia ZK está avançando rápido, mas ainda é muito mais cara do que a execução direta.

Agora vamos falar sobre a medição de Gas.

Rodar código rápido é uma coisa, mas o importante é confiar nele. E se alguém escrever código para “atrasar” de propósito? Em mecanismos de consenso, se o sistema precisa chegar a um acordo em tempo determinado, mas o código foi projetado para ser lento, o sistema pode travar ou até colapsar.

No Polkadot, esse problema não é tão grave porque temos o leilão de slots de parachain. Ou seja, quem pode submeter código ao sistema é conhecido, pois pagou caro pelo slot, então dificilmente vai querer causar danos.

Mas se ampliarmos para um ambiente mais aberto e genérico, o problema é sério.

Qual é a solução?

É preciso estimar antecipadamente o tempo máximo de execução de um código — ou seja, quanto tempo ele pode levar no pior caso. E garantir que, aconteça o que acontecer, nunca será mais lento do que esse pior caso. Caso contrário, se alguém conseguir fazer o código rodar 10 vezes mais devagar do que estimamos, teremos um grande problema.

Então, qual é a precisão da nossa estimativa do pior caso?

Usando SHA-1 hash como exemplo, atualmente, para garantir a segurança, precisamos assumir que pode ser 4,5 vezes mais lento que o normal. Ou seja, se normalmente leva 1 segundo, na estimativa do pior caso consideramos 4,5 segundos. Só assim garantimos que nem o atacante mais malicioso conseguirá atrasar mais do que isso.

Esse método de “multiplicar por alguns fatores de segurança” é essencial para garantir a segurança em mecanismos de consenso com restrição de tempo.

No futuro, esse fator deve cair, ou seja, a estimativa será mais precisa e eficiente. Agora, 4,5 vezes é o melhor resultado que conseguimos após uma ou duas semanas de trabalho. Otimisticamente, talvez caia para 3 vezes, mas não muito mais baixo.

33 recomputações vs. prova matemática: o custo real de dois modelos de segurança

No Polkadot e no JAM, usamos um protocolo chamado elves para garantir a segurança da computação. Sua função é nos permitir ter certeza de que um cálculo foi realmente executado corretamente.

Essencialmente, elves e provas de conhecimento zero (ZK) são parecidos:

• ZK usa prova matemática, te dá uma “prova irrefutável”;
• Já o elves é mais como um jogo de criptoeconomia: participantes usam assinaturas e regras para provar que o resultado está certo, assumindo que “menos de um terço são mal-intencionados”.

Ao rodar o elves, o cálculo é refeito várias vezes. Os participantes decidem aleatoriamente se vão ou não refazer a computação.

O resultado: nesse modelo, o trabalho é refeito em média 33 vezes. Então, o custo é cerca de 33 vezes o da execução normal.

Assim, podemos calcular a diferença de custo entre ZK e elves. A resposta: ZK é cerca de 4.000 vezes mais caro que elves. Ou seja, usar prova de conhecimento zero para verificar a correção é muito mais caro do que usar o sistema criptoeconômico elves. Você pode imaginar isso como a comparação de custos entre diferentes soluções de Rollup.

Nota PolkaWorld: imagine que elves é como se 33 alunos da classe copiassem o dever de casa e depois conferissem as respostas para garantir que está certo; ZK seria como contratar um doutor em matemática para escrever uma “prova absolutamente correta”, mas o doutor pode levar dias para fazer isso.

Essa diferença de 4.000 vezes é enorme; para que o ZK seja viável na prática, o custo precisa cair muito. Claro, também podemos continuar otimizando o elves para torná-lo mais eficiente.

No entanto, o problema de custo não é só hardware. Há outros pontos-chave:

• Custo de operação (sysadmin): não importa o hardware, o salário do operador é parecido. Em muitos casos, o custo de operação é até maior que o do hardware.
• Custo de staking: para garantir que menos de um terço sejam mal-intencionados, o sistema precisa de um mecanismo de filtragem. No Polkadot, isso é feito por “staking + mecanismo de punição”. Ou seja, os participantes precisam depositar parte dos fundos (capital de risco), assim é possível distinguir “bons validadores” dos “maus validadores”.

O problema é: o staking também é caro, é outro custo extra (vou explicar mais adiante).

Em comparação, o ZK não tem o peso do staking. O ZK é simples: ou a prova está certa, ou está errada, fica claro na hora.

Mas o problema é que gerar provas ZK é muito lento. Se usar uma única GPU, pode levar horas; já na PVM (ou CPU comum), a mesma computação leva milissegundos ou segundos. A diferença é enorme.

No entanto, já mostraram que é possível reduzir a latência com clusters de GPU em paralelo. Se houver GPUs suficientes conectadas, a latência cai. Mas o problema é:

A eficiência da paralelização é desconhecida: ou seja, não sabemos quanto o custo aumenta. Quem fez experimentos não divulgou esses dados, talvez nem queira divulgar. Então, ou fazemos experimentos secretos, ou desenvolvemos nosso próprio código, ou procuramos pesquisas ainda não descobertas.

Além disso, há as questões de verificação e liquidação.

Por exemplo, na verificação na Ethereum L1, o custo é até maior que o de gerar a prova. Estimamos que gerar uma prova custa cerca de US$ 1 a US$ 1,20, mas verificar na Ethereum L1 custa US$ 1,25. Claro, se você tem sua própria chain, o custo de verificação pode ser bem menor, mas ainda precisa de:

• Verificação
• Liquidação
• Finalidade
• Armazenamento

Essas etapas não são eliminadas pelo ZK. No fim, ainda é preciso garantir que menos de um terço sejam mal-intencionados, ou seja, ainda voltamos ao staking, como na Ethereum L1, Polkadot e na maioria das chains.

Quanto custa rodar um nó ZK-JAM? A resposta é 10 vezes mais caro do que você imagina!

Agora, vamos pensar de outro jeito: suponha que exista um nó garantidor ZK-JAM, qual seria o custo operacional?

Explicando rapidamente: no JAM, há um papel chamado garantidor, que funciona como “porteiro” do sistema. Todas as transações ou tarefas vão primeiro para eles, que processam, empacotam o resultado e passam para outros validadores. Os validadores podem ou não revisar o trabalho deles.

Agora, vamos supor:

• Remover a revisão (ninguém mais verifica o trabalho do garantidor);
• Reduzir o staking (pois não dependemos totalmente da confiança no garantidor);
• Mas obrigar o garantidor a rodar um cluster de GPU e gerar provas ZK.

Qual seria o custo disso?

Segundo estimativas: gerar uma prova ZK custa cerca de US$ 1,18 (usando SHA-1 como exemplo, equivalente a 6 segundos de computação e 12MB de I/O). Isso é mais ou menos o trabalho que um JAM core pode fazer em um slot. O JAM tem 341 cores, e esse é o custo de um core.

Claro, isso é uma estimativa grosseira. O custo pode variar dependendo da tarefa: pode ser mais caro ou mais barato que US$ 1,18, mas é dessa ordem de grandeza.

Se anualizarmos: o custo de um core por ano é cerca de US$ 9,5 milhões.

Aqui, assumimos que a paralelização do cluster de GPU traz 50% de custo extra, principalmente para reduzir a latência. Mas esse 50% é só um palpite; na prática, pode ser só 5% ou até 200%. O certo é que haverá custo extra, e pode não ser pequeno.

E como isso se compara ao modelo de staking atual do Polkadot?

No modelo atual, para garantir segurança equivalente ao elves (ou cerca de 80% da segurança do elves), o custo por core é inferior a US$ 1 milhão.

Os 80% referem-se ao fato de que, mesmo usando ZK, ainda é preciso algum staking para garantir a segurança de outras partes críticas, como:

• Funcionamento da chain principal
• Liquidação
• Finalidade
• Armazenamento

Tudo isso é importante, mas a correção da computação é o mais central, respondendo por cerca de 80% do custo do staking.

Supondo que rodamos 341 cores e mantemos o modelo econômico de staking atual do Polkadot, o custo é esse. Se o número de cores diminuir, o custo por core aumenta, pois o “bolo” do staking é o mesmo, mas dividido entre menos participantes.

Resumindo: atualmente, o custo do ZK é cerca de 10 vezes o do elves.

Claro, se conseguirmos reduzir o custo de segurança (acredito que é possível), por exemplo, de US$ 9,16 milhões para US$ 2,7 milhões, ou até combinando novos mecanismos em desenvolvimento, para US$ 1,44 milhão. Nesse caso, a diferença de custo entre ZK e elves diminui. Mas lembre-se, US$ 1,44 milhão já é uma estimativa otimista.

Então, qual é a conclusão final?

O custo do ZK está realmente caindo, mas ainda é de 10 a 100 vezes mais caro que o elves. Além disso, há custos extras incertos, como liquidação, armazenamento e finalidade — que o JAM já suporta nativamente, ou que o elves pode aproveitar, mas o ZK não.

Além disso, o elves tem uma vantagem: pode escalar de forma superlinear. Ou seja, é possível conectar várias redes JAM e compartilhar o mesmo conjunto de validadores, aumentando a eficiência geral. O ZK não tem essa capacidade, só cresce linearmente — para gerar prova para outro core, é preciso gastar o mesmo custo de novo, sem poder combinar ou reutilizar.

Evolução de curto, médio e longo prazo do ZK no JAM

Portanto, do ponto de vista estratégico, qual caminho seguir depende da situação.

Acredito que uma estratégia razoável seja:

• Reduzir o custo da prova: precisa cair mais 1–2 ordens de magnitude. Pela experiência, isso pode levar de 18 meses a 5 anos.
• Precisamos de ferramentas open source: capazes de gerar provas de forma eficiente em clusters de GPU. Atualmente, não há ferramentas maduras, ou pelo menos não as mais rápidas. Sem essas ferramentas, nossas estimativas de custo não se sustentam.
• Questão do preço do core: se o preço de mercado do core já estiver em um patamar que torna o modelo elves razoável, o ZK perde a vantagem.
• Escolha de segurança: o mercado precisa distinguir entre dois tipos de segurança: ZK oferece “segurança perfeita”, enquanto elves oferece “segurança sob restrições econômicas”. A questão é se o mercado realmente se importa com qual usar, o que ainda não está claro.
• Eliminar a dependência de alto staking: precisamos ser capazes de realizar outras tarefas do JAM/elves, como armazenamento, liquidação e finalidade, sem depender de grande staking. Se ainda precisarmos de muito staking, não há vantagem, só tornará o ZK mais caro.

Com base nisso, minha estratégia sugerida para o ZK é:

• Começar pelo que é fácil de testar: por exemplo, desenvolver um framework de serviço ZK-JAM, mas ainda usando o mecanismo criptoeconômico existente do JAM (elves) para garantir a segurança.
• Aproveitar as vantagens do JAM: um JAM core tem grande capacidade computacional (CPU) e bom I/O (12MB), e a eficiência de execução da PVM é alta. Isso significa que podemos fazer muita verificação ZK diretamente no JAM core, sem precisar de processos externos caros e complexos.
• Otimizar a etapa da prova: normalmente, o processo de prova ZK tem várias etapas, terminando com uma “compressão da prova” para torná-la menor e mais fácil de verificar. Mas, no JAM core, como o poder de computação é alto, talvez nem precisemos dessa etapa, economizando custos.
• Priorizar provas de armazenamento: como o JAM core tem grande capacidade de computação, mas I/O relativamente limitado, a prova de armazenamento pode compensar essa fraqueza, permitindo processar rapidamente grandes volumes de transações.
• Outras tarefas simples: como verificação de assinatura, que já é fácil e não é gargalo.

Ou seja, o verdadeiro desafio é garantir que os dados em que as transações dependem estejam corretos. Esse é o foco principal.

No médio prazo, a abordagem mais razoável é:

Já temos uma nova visão para Kusama — construir uma rede compatível com ZK. Então, usar esse orçamento e colaborar com outras equipes, focando em ferramentas eficientes e distribuídas de geração de provas, faz todo sentido.

• Se não houver equipe trabalhando nisso, lance um novo projeto;
• Se já houver equipe fazendo ou disposta a fazer, colabore e apoie para que façam bem feito.

O foco deve ser a prova de execução da PVM, pois é fundamental para garantir a compatibilidade futura entre ZK-JAM e JAM normal, além de ser essencial a geração distribuída de provas.

O objetivo é manter o sistema modular e aberto, para acompanhar as pesquisas de ponta. Só acompanhando o avanço tecnológico poderemos reduzir o custo das provas em mais ordens de magnitude, tornando-as realmente viáveis comercialmente.

No longo prazo, se quisermos que o ZK seja a solução central, precisamos encontrar uma forma de substituir o staking. Porque, enquanto houver staking, o custo será muito alto.

Então, como implementar um JAM totalmente baseado em ZK?

Primeiro, isso só faz sentido se o custo do ZK cair o suficiente e se ficar claro que o uso do core no modelo atual não é economicamente viável. Ainda não sabemos, então é uma hipótese condicional.

Quando as condições forem atendidas, podemos evoluir o JAM para um modelo de segurança multimodal:

• De um lado, oferecer segurança barata, mas limitada (tipo elves, custo baixo);
• De outro, oferecer segurança perfeita, mas cara (baseada em ZK, custo linear crescente).

A questão central é: precisamos encontrar uma forma de garantir finalidade (finality) e armazenamento (storage) sem depender de staking.

Uma possível direção é a prova de personalidade (Proof of Personhood). Se conseguirmos integrar esse mecanismo ao protocolo central, a eficiência e o uso de capital aumentam muito.

No entanto, para isso, é preciso um mecanismo anti-sybil muito forte. A maioria das soluções atuais não é suficiente, ou depende de uma autoridade central, ou de uma organização coletando dados dos usuários para decidir quem é real e quem não é. Isso traz problemas de centralização, e só poucas soluções chegam perto de serem viáveis.