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 artigo é a versão em chinês 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 os principais 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 verdadeiro custo de dois modos de segurança
• Quanto custa um nó ZK-JAM? A resposta é 10 vezes mais cara do que você imagina!
• O caminho de evolução de curto, médio e longo prazo do ZK no JAM

Vamos ver quais pontos interessantes Gavin compartilhou!

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

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

Além disso, vou discutir o modelo econômico do token DOT. Em seguida, apresentarei algumas novas pesquisas em que venho trabalhando recentemente, com o objetivo de melhorar as capacidades existentes e até mesmo trazer novas possibilidades para o Polkadot e o universo Web3 mais amplo. Esta parte abrange vários aspectos, alguns dos quais serão detalhados, outros apenas mencionados. Bem, vamos começar oficialmente.

Status atual da entrega do JAM

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

Espera-se que o JAM inicie a auditoria do protocolo ainda este ano. Há pouco trabalho a ser feito na série de versões 0.7; mas na versão 0.8, a modelagem de gas será oficialmente introduzida, aumentando significativamente o volume de trabalho. Espero que possamos avançar para a versão 0.9 ainda este ano e iniciar formalmente a auditoria nesse momento.

Claro, ter um protocolo central é uma coisa, mas ser capaz de 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á principalmente impulsionando a construção e o lançamento do SDK. No entanto, na prática, isso ainda exigirá meses ou até anos de investimento e refinamento 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. Enquanto isso, o CoreVM está gradualmente se tornando parte do SDK e será continuamente aprimorado nos próximos meses. O CoreVM já suporta muitos recursos, 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 planos. Além disso, o mecanismo que chamei anteriormente de coreplay (agendamento colaborativo central) também está planejado para ser implementado nos próximos 12–24 meses.

Recentemente, no 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 conteúdo que escrevo no Gray Paper. Isso significa que, se algo acontecer comigo, todo 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 apenas de mim, como ela irá evoluir?

Minha ideia é criar um comitê editorial. Os membros iniciais serão aqueles que realmente participaram da redação do Gray Paper, que o compreendem profundamente e fizeram contribuições substanciais. Espero que esses membros mantenham um alto nível de envolvimento técnico na implementação do JAM. Eu mesmo não vou me afastar 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 superior:

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

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 todo o mecanismo possa operar de forma autônoma. No final, espero que esse sistema de governança se torne gradualmente independente, até mesmo envolvendo algumas organizações externas, como a Polkadot Fellowship.

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

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

No futuro, se o JAM continuar evoluindo, o Polkadot pode optar por acompanhar e seguir a versão mais recente; se não estiver satisfeito com a direção do JAM, pode fixar-se em uma versão específica, modificar o protocolo central ou até mesmo bifurcar o Gray Paper. Isso mostra que o JAM é um sistema independente, e espero que ele mantenha uma relação mutuamente benéfica com o Polkadot a longo prazo. Claro, se um dia seguirem caminhos separados e se desenvolverem de forma independente, 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. E se outros protocolos adotarem o JAM no futuro, espero que também participem de maneira semelhante.

Bem, este é o progresso atual do JAM, ou o estágio que está prestes a atingir. Em seguida, quero falar sobre provas de conhecimento zero (ZK).

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

Muitas pessoas me perguntam: quando o ZK (prova de conhecimento zero) será realmente comercial?

O Ethereum é muito entusiasta do ZK, e seu roadmap gira quase totalmente em torno do ZK. Já no JAM, usamos um pouco de ZK apenas em alguns mecanismos especiais de consenso na construção de blocos, mas não dependemos dele como um todo. Mesmo assim, ainda é uma questão que precisa ser considerada seriamente:

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

Se você olhar para os materiais do ecossistema Ethereum (como ethprovers.com), verá alguns 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 PVM do JAM (equivalente ao EVM do JAM) é cerca de 34% mais lenta que a execução nativa ao rodar código. Em outras palavras, se um programa leva 34 minutos para rodar em ambiente nativo, no PVM levará 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 no PVM é mais lenta. Isso pode ser porque, no ambiente nativo, o compilador pode usar instruções SIMD ou outras otimizações, enquanto o PVM ainda não consegue.

Agora vejamos outro número chave: 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 no PVM. Observe que a comparação é com o PVM, não com o ambiente nativo. O PVM já é cerca de 34% mais lento que o nativo.

Os resultados atuais dos testes são os seguintes: usamos a versão mais recente do software e assumimos o uso de apenas uma GPU (porque o repositório público só suporta uma GPU). Se fosse uma versão comercial fechada, talvez pudesse ser expandida para clusters de GPU, mas no ambiente open source, é assim. O teste é o mesmo de antes, ainda usando hash SHA-1, para garantir a consistência da comparação.

Então, qual é a diferença?

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

Há dois motivos principais:

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

Vale acrescentar que, há 18 meses, usávamos o provador RISC-0, não o SP1. Mas, de qualquer forma, o resultado mostra uma coisa: a tecnologia de ponta está avançando rapidamente, e o progresso é considerável.

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

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

Executar código rapidamente é uma coisa, mas o fundamental é poder confiar nele. E se alguém escrever um código propositalmente para "atrasar" o sistema? Em mecanismos de consenso, se o sistema precisa chegar a um acordo em tempo determinado, mas o código foi projetado para ser lento, todo 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 é basicamente conhecido, pois pagaram caro pelo slot, então é improvável que causem danos de propósito.

Mas se ampliarmos o cenário para um ambiente mais aberto e geral, o problema se agrava.

Qual é a solução?

É preciso estimar previamente 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, ele 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, até onde conseguimos estimar o pior caso hoje?

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

Esse método de "multiplicar por alguns fatores para garantir" é exatamente o que precisamos para garantir a segurança em mecanismos de consenso com restrição de tempo.

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

33 recomputações vs prova matemática: o verdadeiro custo de dois modos 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 uma determinada computação foi realmente executada corretamente.

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

• O ZK usa uma prova matemática, fornecendo uma "prova irrefutável";
• O elves é mais como um jogo de criptoeconomia: os participantes usam assinaturas e algumas regras para provar que o resultado está correto, assumindo que "os maus não ultrapassam um terço".

Ao rodar o elves, a computação é repetida. Os participantes decidem aleatoriamente se vão ou não fazer essa "recomputação".

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

Assim, podemos calcular a diferença de custo entre ZK e elves. A resposta é: o ZK é cerca de 4.000 vezes mais caro que o elves. Em outras palavras, usar provas de conhecimento zero para verificar a correção é muito mais caro do que usar o sistema de criptoeconomia elves. Você pode pensar nisso como uma comparação de custos entre diferentes soluções de Rollup.

Nota PolkaWorld: você pode imaginar o elves como uma turma de 33 alunos copiando o dever de casa e conferindo as respostas para garantir que não há erros; o ZK seria como contratar um doutor em matemática para escrever uma "prova absolutamente correta", mas o doutor pode levar dias para fazê-la.

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

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

• Custo de operação (sysadmin): não importa o hardware que você use, o salário dos operadores é quase o mesmo. E, em muitos casos, o custo de operação é até maior que o do hardware.
• Custo de staking: para garantir que os maus não ultrapassem um terço, o sistema precisa de um mecanismo de filtragem. No Polkadot, isso é feito por meio de "staking + mecanismo de punição". Ou seja, os participantes precisam depositar parte dos fundos (capital de risco), assim é possível distinguir entre "bons validadores" e possíveis "maus validadores".

O problema é: o staking em si é caro, o que é um custo extra (vou detalhar mais adiante).

Em comparação, o ZK não tem esse fardo de staking. O ZK é simples: ou a prova está correta, ou está errada, é fácil de ver.

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

No entanto, já foi demonstrado que é possível reduzir a latência usando clusters de GPU em paralelo. Se houver GPUs suficientes conectadas, a latência pode cair. Mas o problema é:

A eficiência da paralelização é opaca: ou seja, não está claro quanto o custo aumentará. Quem fez experimentos não divulgou esses dados, talvez nem queira divulgar. Então, ou projetamos experimentos secretos para medir, ou desenvolvemos nosso próprio código, ou procuramos pesquisas relacionadas ainda não descobertas.

Além disso, há o problema de verificação e liquidação.

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

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

Essas etapas não são eliminadas pelo ZK. Portanto, no final, ainda é preciso garantir que os maus não ultrapassem um terço, ou seja, ainda é necessário o mecanismo de staking, como no Ethereum L1, Polkadot e na maioria das chains.

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

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

Explicando rapidamente: no JAM, há um papel chamado garantidores, que funcionam como "porteiros" do sistema. Todas as transações ou tarefas passam primeiro por eles, que processam, empacotam os resultados e os entregam aos validadores. Os validadores podem ou não revisar o trabalho dos garantidores.

Agora, suponhamos o seguinte cenário:

• Eliminamos a revisão (não exigimos mais que outros revisem o trabalho dos garantidores);
• Reduzimos o requisito de staking (porque não dependemos totalmente da confiança nos garantidores);
• Mas exigimos que os garantidores rodem clusters de GPU e gerem provas ZK.

Então, qual seria o custo?

De acordo com estimativas: gerar uma prova ZK custa cerca de 1,18 dólares (usando SHA-1 como exemplo, equivalente a 6 segundos de computação, 12MB de I/O). Isso é aproximadamente o trabalho que um core JAM pode fazer em um slot. O JAM tem 341 cores no total, e esse é o custo de um único core.

Claro, isso é apenas uma estimativa grosseira. O custo de diferentes tarefas pode variar: para outros cálculos, pode ser mais caro ou mais barato que 1,18 dólares, mas é dessa ordem de magnitude.

Se anualizarmos: o custo de um core por ano é de cerca de 9,5 milhões de dólares.

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

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

No mecanismo atual, para fornecer uma segurança equivalente ao elves (ou cerca de 80% da segurança do elves), o custo de cada core é de menos de 1 milhão de dólares.

Os 80% mencionados são porque: mesmo usando ZK, ainda é necessário algum staking para garantir a segurança de outras partes críticas, como:

• Operação normal da chain principal
• Liquidação
• Finalidade
• Armazenamento

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

Supondo que rodemos 341 cores e mantenhamos 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 não muda, 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 seja possível), por exemplo, de 9,16 milhões para 2,7 milhões, ou até menos com novos mecanismos em desenvolvimento, para 1,44 milhão. Nesse caso, a diferença de custo entre ZK e elves diminuirá. Mas lembre-se, 1,44 milhão já é uma estimativa otimista.

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

O custo do ZK está realmente caindo, mas mesmo assim, 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 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 provas para outro core, é preciso pagar o mesmo custo novamente, sem possibilidade de fusão ou reutilização.

O caminho de 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 específica.

Acredito que uma estratégia razoável seja:

• Reduzir o custo da prova: ainda 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 e distribuída em clusters de GPU. Atualmente, não há ferramentas maduras, ou pelo menos não as melhores e 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 intervalo que torne o modo elves razoável, o ZK perde sua vantagem.
• Escolha de segurança: o mercado precisa distinguir entre dois tipos de segurança: o ZK oferece "segurança perfeita", enquanto o 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 staking elevado: precisamos ser capazes de realizar outras tarefas do JAM/elves, como armazenamento, liquidação e finalidade, sem depender de grande staking. Se ainda for necessário muito staking, não há vantagem, só tornará o ZK mais caro.

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

• Começar por áreas fáceis de experimentar: como desenvolver uma estrutura de serviço ZK-JAM, mas ainda aproveitando o mecanismo de criptoeconomia existente do JAM (elves) para fornecer segurança.
• Aproveitar as vantagens do JAM: um core JAM tem grande capacidade de computação (CPU) e bom I/O (12MB), e a eficiência de execução do PVM também é alta. Isso significa que podemos fazer muita verificação ZK diretamente no core JAM, sem precisar do processo externo caro e complexo de provas.
• Otimizar a etapa de prova: o processo tradicional de prova ZK geralmente tem várias etapas, com uma última de "compressão da prova" para torná-la menor e mais fácil de verificar. Mas no core JAM, como o poder de computação é suficiente, talvez nem precisemos dessa etapa, economizando custos.
• Priorizar provas de armazenamento: porque o core JAM tem grande capacidade de computação, mas I/O relativamente limitado, e a prova de armazenamento pode compensar essa fraqueza, permitindo processar rapidamente grandes volumes de transações.
• Outras tarefas simples: como verificação de assinaturas, que já são fáceis de realizar e não são gargalos.

Em outras palavras, o verdadeiro desafio é garantir que os dados em que as transações dependem estejam corretos. Este é o problema principal a ser resolvido.

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

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

• Se não houver equipe trabalhando nisso, inicie um novo projeto;
• Se já houver equipe ou alguém disposto a mudar de foco, colabore e apoie para que façam um bom trabalho.

É especialmente importante focar nas provas de execução do PVM, pois isso será fundamental para manter a compatibilidade entre ZK-JAM e JAM comum no futuro, e a geração distribuída de provas é indispensável.

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

No longo prazo, se realmente quisermos que o ZK se torne a solução central, precisamos encontrar uma forma de substituir o staking. Porque enquanto o staking existir, 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 a utilização do core não é economicamente viável no modelo atual. Ainda não podemos afirmar isso, então é uma hipótese condicional.

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

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

A questão-chave é: precisamos encontrar uma forma de alcançar finalidade (finality) e armazenamento (storage) sem depender de staking.

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

No entanto, para isso, é preciso um mecanismo anti-sybil muito forte. Atualmente, a maioria das soluções não é suficientemente robusta: ou depende de uma autoridade central, ou de uma organização que coleta dados dos usuários para decidir quem é real e quem não é. Esse método é claramente centralizado, e apenas pouquíssimas soluções são quase viáveis.