JAM da Polkadot: Redefinindo a Arquitetura Blockchain com RISC-V
Em abril de 2025, Vitalik Buterin propôs algo que pareceria herético um ano antes: substituir a EVM da Ethereum por RISC-V. A sugestão gerou um debate imediato. Mas o que a maioria dos comentaristas esqueceu foi que a Polkadot já estava construindo exatamente essa arquitetura há mais de um ano — e estava a meses de implementá-la em produção.
O JAM (Join-Accumulate Machine) da Polkadot não é apenas mais uma atualização de blockchain. Ele representa um repensar fundamental do que uma "blockchain" sequer significa. Enquanto a visão de mundo da Ethereum se concentra em uma máquina virtual global processando transações, o JAM elimina o conceito de transação inteiramente em sua camada central, substituindo-o por um modelo de computação que promete 850 MB / s de disponibilidade de dados — 42 vezes a capacidade anterior da Polkadot e 650 vezes os 1,3 MB / s da Ethereum.
As implicações vão muito além dos benchmarks de desempenho. O JAM pode ser a articulação mais clara até agora de um paradigma pós-Ethereum para a arquitetura blockchain.
O Gray Paper: O Terceiro Ato de Gavin Wood
O Dr. Gavin Wood escreveu o Ethereum Yellow Paper em 2014, fornecendo a especificação formal que tornou a Ethereum possível. Ele seguiu com o Polkadot White Paper em 2016, introduzindo o sharding heterogêneo e a segurança compartilhada. Em abril de 2024, ele lançou o JAM Gray Paper no Token2049 em Dubai — completando uma trilogia que abrange toda a história das blockchains programáveis.
O Gray Paper descreve o JAM como "um ambiente de objetos sem permissão e singleton global — semelhante ao ambiente de contratos inteligentes da Ethereum — emparelhado com computação de banda lateral segura paralelizada em uma rede de nós escalável". Mas isso subestima a mudança conceitual.
O JAM não apenas melhora os designs de blockchain existentes. Ele pergunta: e se parássemos de pensar em blockchains inteiramente como máquinas virtuais?
O Problema da Transação
As blockchains tradicionais — incluindo a Ethereum — são fundamentalmente sistemas de processamento de transações. Os usuários enviam transações, os validadores as ordenam e executam, e a blockchain registra as mudanças de estado. Este modelo serviu bem, mas carrega limitações inerentes:
- Gargalos sequenciais: As transações devem ser ordenadas, criando restrições de throughput
- Contestação de estado global: Cada transação potencialmente toca o estado compartilhado
- Acoplamento de execução: Consenso e computação estão fortemente ligados
O JAM desacopla essas preocupações por meio do que Wood chama de paradigma "Refinar-Acumular" (Refine-Accumulate). O sistema opera em duas fases:
Refinar (Refine): A computação acontece em paralelo em toda a rede. O trabalho é dividido em unidades independentes que podem ser executadas simultaneamente sem coordenação.
Acumular (Accumulate): Os resultados são coletados e mesclados no estado global. Apenas esta fase requer consenso sobre a ordenação.
O resultado é um protocolo principal "sem transações". O JAM em si não processa transações — os aplicativos construídos no JAM o fazem. Essa separação permite que a camada base se concentre puramente em computação segura e paralela.
PolkaVM: Por Que o RISC-V é Importante
No coração do JAM está a PolkaVM, uma máquina virtual construída para esse propósito baseada no conjunto de instruções RISC-V. Essa escolha tem implicações profundas para a computação em blockchain.
A Dívida Arquitetônica da EVM
A EVM da Ethereum foi projetada em 2013 - 2014, antes que muitas premissas modernas sobre a execução de blockchain fossem compreendidas. Sua arquitetura reflete aquela era:
- Execução baseada em pilha (stack-based): As operações empilham e desempilham valores de uma pilha ilimitada, exigindo rastreamento complexo
- Tamanho de palavra de 256 bits: Escolhido para conveniência criptográfica, mas ineficiente para a maioria das operações
- Gás unidimensional: Uma métrica tenta precificar recursos computacionais vastamente diferentes
- Apenas interpretação: O bytecode da EVM não pode ser compilado para código nativo de forma eficiente
Essas decisões de design faziam sentido como escolhas iniciais, mas criam penalidades de desempenho contínuas.
Vantagens do RISC-V
A PolkaVM adota uma abordagem fundamentalmente diferente:
Arquitetura baseada em registradores: Como as CPUs modernas, a PolkaVM usa um conjunto finito de registradores para passagem de argumentos. Isso se alinha com o hardware real, permitindo a tradução eficiente para conjuntos de instruções nativos.
Tamanho de palavra de 64 bits: Os processadores modernos são de 64 bits. O uso de um tamanho de palavra correspondente elimina a sobrecarga de emular operações de 256 bits para a grande maioria das computações.
Gás multidimensional: Diferentes recursos (computação, armazenamento, largura de banda) são precificados de forma independente, refletindo melhor os custos reais e prevenindo ataques de precificação incorreta.
Modos de execução duais: O código pode ser interpretado para execução imediata ou compilado via JIT para desempenho otimizado. O sistema escolhe o modo apropriado com base nas características da carga de trabalho.
Impacto no Desempenho
As diferenças arquitetônicas se traduzem em ganhos reais de desempenho. Os benchmarks mostram que a PolkaVM atinge melhorias de mais de 10 x + em relação ao WebAssembly para contratos intensivos em aritmética — e a EVM é ainda mais lenta. Para interações complexas de múltiplos contratos, a lacuna aumenta ainda mais à medida que a compilação JIT amortiza os custos de configuração.
Talvez mais importante, a PolkaVM suporta qualquer linguagem que compile para RISC-V. Enquanto os desenvolvedores da EVM estão limitados a Solidity, Vyper e um punhado de linguagens especializadas, a PolkaVM abre as portas para Rust, C ++ e, eventualmente, qualquer linguagem suportada por LLVM. Isso expande drasticamente o conjunto de desenvolvedores em potencial.
Mantendo a Experiência do Desenvolvedor
Apesar da reformulação arquitetônica, o PolkaVM mantém a compatibilidade com os fluxos de trabalho existentes. O compilador Revive oferece suporte completo ao Solidity, incluindo assembler inline. Os desenvolvedores podem continuar usando Hardhat, Remix e MetaMask sem alterar seus processos.
A equipe Papermoon demonstrou essa compatibilidade ao migrar com sucesso o código do contrato da Uniswap V2 para a testnet da PolkaVM — provando que até mesmo códigos DeFi complexos e testados em batalha podem fazer a transição sem reescritas.
Metas de Desempenho do JAM
Os números que Wood projeta para o JAM são impressionantes para os padrões atuais de blockchain.
Disponibilidade de Dados
O JAM visa 850 MB/s de disponibilidade de dados — aproximadamente 42 vezes a capacidade básica da Polkadot antes das otimizações recentes e 650 vezes os 1,3 MB/s da Ethereum. Para contextualizar, isso se aproxima do throughput de sistemas de banco de dados corporativos.
Taxa de Transferência Computacional
O Gray Paper estima que o JAM pode atingir aproximadamente 150 bilhões de gas por segundo em capacidade total. Traduzir gas para transações é impreciso, mas a taxa de transferência máxima teórica atinge mais de 3,4 milhões de TPS com base na meta de disponibilidade de dados.
Validação no Mundo Real
Estes não são números puramente teóricos. Testes de estresse validaram a arquitetura:
- Kusama (Agosto de 2025): Alcançou 143.000 TPS com apenas 23% da capacidade de carga
- Polkadot "Spammening" (2024): Atingiu 623.000 TPS em testes controlados
Esses números representam a taxa de transferência real de transações, não projeções otimistas ou condições de testnet que não refletem ambientes de produção.
Status de Desenvolvimento e Cronograma
O desenvolvimento do JAM segue um sistema estruturado de marcos (milestones), com 43 equipes de implementação competindo por um fundo de prêmios que excede US$ 60 milhões (10 milhões de DOT + 100.000 KSM).
Progresso Atual (Final de 2025)
O ecossistema atingiu vários marcos críticos:
- Múltiplas equipes alcançaram 100% de conformidade com os vetores de teste da Web3 Foundation
- O desenvolvimento progrediu através das versões 0.6.2 a 0.8.0 do Gray Paper, aproximando-se da v1.0
- A conferência JAM Experience em Lisboa (maio de 2025) reuniu equipes de implementação para uma colaboração técnica profunda
- Tours universitários alcançaram mais de 1.300 participantes em nove locais globais, incluindo Cambridge, Universidade de Pequim e Universidade Fudan
Estrutura de Marcos
As equipes progridem através de uma série de marcos:
- IMPORTER (M1): Aprovação em testes de conformidade de transição de estado e importação de blocos
- AUTHORER (M2): Conformidade total, incluindo produção de blocos, rede e componentes off-chain
- HALF-SPEED (M3): Alcançar o nível de desempenho da Kusama, com acesso ao JAM Toaster para testes em escala total
- FULL-SPEED (M4): Desempenho em nível de mainnet da Polkadot com auditorias de segurança profissionais
Várias equipes concluíram o M1, com algumas progredindo em direção ao M2.
Cronograma para a Mainnet
- Final de 2025: Revisões finais do Gray Paper, submissões contínuas de marcos, participação expandida na testnet
- Q1 2026: Atualização da mainnet JAM na Polkadot após aprovação de governança via referendo OpenGov
- 2026: Implantação da Fase 1 da CoreChain, testnet pública oficial do JAM, transição total da rede
O processo de governança já mostrou forte apoio da comunidade. Uma votação quase unânime dos detentores de DOT aprovou a direção da atualização em maio de 2024.
JAM vs. Ethereum: Complementar ou Competitivo?
A questão de saber se o JAM representa um "Ethereum killer" ignora as nuances arquitetônicas.
Diferentes Filosofias de Design
A Ethereum constrói para fora a partir de uma base monolítica. A EVM fornece um ambiente de execução global, e as soluções de escalabilidade — L2s, rollups, sharding — são camadas sobrepostas. Essa abordagem criou um ecossistema enorme, mas também acumulou dívida técnica.
O JAM começa com a modularidade em seu núcleo. A separação das fases Refine e Accumulate, a otimização de domínio específico para o manuseio de rollups e a camada base sem transações (transactionless) refletem um design focado em escalabilidade desde o início.
Escolhas Técnicas Convergentes
Apesar dos diferentes pontos de partida, os projetos estão convergindo para conclusões semelhantes. A proposta RISC-V de Vitalik em abril de 2025 reconheceu que a arquitetura da EVM limita o desempenho a longo prazo. A Polkadot já havia implantado o suporte a RISC-V na testnet meses antes.
Essa convergência valida o julgamento técnico de ambos os projetos, ao mesmo tempo que destaca a lacuna de execução: a Polkadot está entregando o que a Ethereum está propondo.
Realidades do Ecossistema
A superioridade técnica não se traduz automaticamente em domínio do ecossistema. A comunidade de desenvolvedores da Ethereum, a diversidade de aplicações e a profundidade da liquidez representam efeitos de rede substanciais que não podem ser replicados da noite para o dia.
O resultado mais provável não é a substituição, mas a especialização. A arquitetura do JAM é otimizada para certas cargas de trabalho — particularmente aplicações de alta taxa de transferência e infraestrutura de rollup — enquanto a Ethereum mantém vantagens na maturidade do ecossistema e na formação de capital.
Em 2026, eles se parecem menos com competidores e mais com camadas complementares de uma internet multi-chain.
O que o JAM Significa para a Arquitetura Blockchain
A importância do JAM vai além da Polkadot. Ele representa a articulação mais clara de um paradigma pós-EVM que outros projetos estudarão e adotarão seletivamente.
Princípios Chave
Separação de computação: Desacoplar a execução do consenso permite o processamento paralelo na camada base, não como uma solução tardia.
Otimização específica do domínio: Em vez de construir uma VM de propósito geral e esperar que ela escale, o JAM é arquitetado especificamente para as cargas de trabalho que as blockchains realmente executam.
Alinhamento com o hardware: O uso de RISC - V e palavras de 64 bits alinha a arquitetura da máquina virtual com o hardware físico, eliminando a sobrecarga de emulação.
Abstração de transações: Mover o tratamento de transações para a camada de aplicação permite que o protocolo se concentre na computação e no gerenciamento de estado.
Impacto na Indústria
Independentemente de o JAM ter sucesso ou falhar comercialmente, essas escolhas arquitetônicas influenciarão o design de blockchains pela próxima década. O Gray Paper fornece uma especificação formal que outros projetos podem estudar, criticar e implementar seletivamente.
A proposta RISC - V da Ethereum já demonstra essa influência. A questão não é se essas ideias se espalharão, mas com que rapidez e em que forma.
O Caminho à Frente
O JAM representa a visão técnica mais ambiciosa de Gavin Wood desde a própria Polkadot. Os riscos correspondem à ambição: o sucesso validaria uma abordagem inteiramente diferente para a arquitetura de blockchain, enquanto o fracasso deixaria a Polkadot competindo com novas L1s sem uma narrativa técnica diferenciada.
Os próximos 18 meses determinarão se as vantagens teóricas do JAM se traduzem na realidade da produção. Com 43 equipes de implementação, um fundo de prêmios de nove dígitos e um roteiro claro para a mainnet, o projeto tem recursos e ímpeto. O que resta saber é se a complexidade do paradigma Refine - Accumulate pode cumprir a visão de Wood de um "computador distribuído que pode executar quase qualquer tipo de tarefa".
Para desenvolvedores e projetos que avaliam a infraestrutura de blockchain, o JAM merece atenção séria — não como hype, mas como uma tentativa tecnicamente rigorosa de resolver problemas que toda grande blockchain enfrenta. O paradigma da blockchain como máquina virtual serviu bem à indústria por uma década. O JAM aposta que a próxima década exige algo fundamentalmente diferente.
Construindo na infraestrutura de blockchain de próxima geração? BlockEden.xyz fornece endpoints RPC de alto desempenho em todo o ecossistema Polkadot e em mais de 30 outras redes. Explore nosso marketplace de APIs para acessar infraestrutura de nível empresarial para suas aplicações.