Uma postagem marcadas com "Polkadot"

A JAM (Join-Accumulate Machine) Chain da Polkadot representa a inovação mais significativa na arquitetura blockchain desde o lançamento da Ethereum, reimaginando fundamentalmente como a computação descentralizada opera. Introduzida pelo Dr. Gavin Wood através do JAM Gray Paper em abril de 2024, a JAM transforma a Polkadot de uma Relay Chain específica para parachains num "supercomputador sem confiança e maioritariamente coerente" de propósito geral e sem permissão, capaz de 42x mais disponibilidade de dados (850 MB/s) e 3,4+ milhões de TPS de capacidade teórica. O protocolo resolve o persistente problema de particionamento que assola os sistemas blockchain atuais, permitindo a componibilidade síncrona dentro de limites de shard dinâmicos, mantendo a execução paralelizada em mais de 350+ cores. Ao contrário da estratégia de rollup centrada em L2 da Ethereum ou do modelo de zona soberana da Cosmos, a JAM constrói a execução sharded com estado coerente diretamente na camada de consenso, usando uma nova Polkadot Virtual Machine (PVM) baseada em RISC-V e uma arquitetura sem transações, onde toda a computação flui através de um pipeline Refine→Accumulate. Com 43 equipas de implementação a competir por 10 milhões de DOT em prémios, vários clientes a atingir 100% de conformidade até agosto de 2025 e a implantação na mainnet prevista para o início de 2026, a JAM está posicionada para entregar o que a visão original da Ethereum 2.0 prometeu: execução escalável nativa sem sacrificar a componibilidade ou a segurança.

O modelo computacional: como os processos JAM funcionam em escala​

A JAM introduz um paradigma computacional fundamentalmente novo chamado CoreJAM (Collect, Refine, Join, Accumulate), que divide a execução blockchain em fases distintas otimizadas para paralelização e eficiência. O nome JAM deriva das porções on-chain — Join e Accumulate — enquanto Collect e Refine ocorrem off-chain. Esta arquitetura estabelece dois ambientes de execução primários que funcionam em conjunto: execução in-core para computação paralela pesada e execução on-chain para integração de estado.

Na fase Refine (execução in-core), os itens de trabalho passam por processamento paralelo sem estado em múltiplos cores de validador, com cada core a lidar com até 15 MB de dados de entrada por timeslot de 6 segundos e a produzir saídas comprimidas de no máximo 90 KB — uma notável taxa de compressão de 166x. Esta fase fornece 6 segundos de tempo de execução PVM por core, triplicando o limite de 2 segundos das atuais Funções de Validação de Parachain (PVFs) da Polkadot. A função Refine realiza o trabalho computacional pesado inteiramente off-chain, com apenas pesquisas de preimage como sua operação com estado, permitindo paralelização massiva sem contenção de estado.

Após o refinamento, a fase Accumulate (execução on-chain) integra os resultados do trabalho no estado da cadeia através de operações com estado limitadas a aproximadamente 10 milissegundos por saída. Esta função é executada em todos os validadores e pode ler o armazenamento de qualquer serviço, escrever no seu próprio armazenamento chave-valor, transferir fundos entre serviços, criar novos serviços, atualizar código e solicitar disponibilidade de preimage. O forte contraste nos orçamentos de execução — 6 segundos off-chain versus 10 milissegundos on-chain — reflete a visão fundamental da JAM: ao empurrar a computação cara para off-chain e paralelizá-la, o sistema reserva tempo precioso on-chain apenas para transições de estado essenciais.

Os serviços na JAM definem um terceiro ponto de entrada chamado onTransfer, que lida com a comunicação assíncrona entre serviços. Este sistema de mensagens permite que os serviços interajam sem bloqueio, com mensagens enviadas sem valores de retorno imediatos. O design antecipa futuras melhorias, como a alocação de gás adicional via cores secundários para interações complexas entre serviços.

Este modelo de execução dualístico alcança o que Wood descreve como semi-coerência: serviços agendados para o mesmo core no mesmo bloco interagem de forma síncrona (subconjunto coerente), enquanto serviços em cores diferentes comunicam assincronamente (incoerente no geral). Os limites entre a execução coerente e incoerente permanecem fluidos e economicamente impulsionados, em vez de serem impostos pelo protocolo, permitindo que serviços que comunicam frequentemente co-localizem em cores para um comportamento síncrono, mantendo a escalabilidade em todo o sistema. Isso representa um avanço na resolução do antagonismo tamanho-sincronia que restringiu as arquiteturas blockchain anteriores.

Transformação arquitetónica de Relay Chain para computação baseada em serviços​

A JAM reimagina fundamentalmente a arquitetura da Polkadot, passando de um design altamente opinativo e específico para parachains para um substrato computacional minimalista e de propósito geral. A atual Polkadot Relay Chain consagra parachains diretamente no protocolo com um limite rígido de aproximadamente 50 slots, exige acesso baseado em leilão que custa milhões em DOT e executa toda a lógica da parachain através de caminhos de validação fixos. A JAM substitui isso por serviços — ambientes de execução encapsulados e sem permissão que qualquer pessoa pode implantar sem aprovação de governação ou leilões, limitados apenas por fatores criptoeconómicos (depósitos de DOT).

A mudança na filosofia arquitetónica é profunda: de Relay Chain atualizável para protocolo fixo com serviços atualizáveis. Onde a Polkadot 1.0 mantinha uma Relay Chain altamente atualizável que acumulava complexidade ao longo do tempo, a JAM fixa os parâmetros do protocolo central (codificação do cabeçalho do bloco, esquemas de hashing, protocolo de rede QUIC, parâmetros de tempo) para permitir otimização agressiva e simplificar múltiplas implementações. A funcionalidade ao nível da aplicação, incluindo staking, governação e alocação de coretime, reside em serviços que podem ser atualizados independentemente sem tocar no protocolo central. Esta arquitetura de cadeia não atualizável reduz drasticamente a complexidade, preservando a flexibilidade onde mais importa — na camada de aplicação.

As parachains tornam-se um tipo de serviço entre muitos no modelo da JAM. Toda a funcionalidade da parachain Polkadot 1.1 será consolidada num único serviço "Parachains" ou "CoreChains", garantindo compatibilidade retroativa total com garantias hard-coded. As parachains existentes transitam automaticamente para execução na JAM quando a Relay Chain é atualizada, exigindo zero alterações de código. O modelo de serviço generaliza o que as parachains podiam fazer em padrões de execução arbitrários: smart contracts implantados diretamente em cores, frameworks baseados em atores como CorePlay, ZK-rollups, serviços de disponibilidade de dados e modelos de execução inteiramente novos ainda não concebidos.

O modelo de gestão de estado também se transforma significativamente. A Polkadot atual usa raízes de estado posteriores nos cabeçalhos dos blocos — os blocos esperam que a computação completa seja concluída antes da distribuição. A JAM emprega raízes de estado anteriores que atrasam um bloco, permitindo o pipelining: computações leves (aproximadamente 5% da carga de trabalho) são executadas imediatamente, o bloco distribui antes que as tarefas pesadas de acumulação sejam concluídas, e o próximo bloco começa a ser processado antes que o bloco atual termine a execução. Esta escolha arquitetónica significa que a JAM utiliza o tempo total de 6 segundos do bloco para computação, alcançando 3 a 3,5 segundos de tempo de computação efetivo por bloco, versus menos de 2 segundos na Polkadot atual.

A transição da JAM de WebAssembly para a Polkadot Virtual Machine (PVM) baseada em RISC-V representa outra mudança fundamental. O RISC-V, com apenas 47 instruções base, oferece determinismo superior, velocidades de execução excecionais em hardware convencional, fácil transpilação para x86/x64/ARM, suporte oficial à toolchain LLVM e tratamento natural de continuações com stack na memória. Crucialmente, a PVM fornece "medição gratuita" em comparação com a sobrecarga de medição do WebAssembly, enquanto a arquitetura baseada em registos (versus o design baseado em stack do WASM) evita o problema de alocação de registos NP-completo. Isso permite continuações habilitadas para RISC-V que estabelecem novos padrões para codificação multi-core escalável, permitindo que os programas pausem e retomem entre os limites dos blocos — essencial para a arquitetura assíncrona e paralelizada da JAM.

Especificações técnicas: metas de desempenho e requisitos de validador​

A JAM visa métricas de desempenho extraordinárias que a posicionam como um salto geracional na capacidade computacional blockchain. O sistema visa 850 MB/s de disponibilidade de dados — uma melhoria de 42x em relação à Polkadot vanilla antes das melhorias de Asynchronous Backing e ordens de magnitude além dos 1,3 MB/s da Ethereum. Isso se traduz num throughput agregado de aproximadamente 2,3 Gbps em todos os cores, com cada core a processar 5 MB de entrada por slot de 6 segundos.

A capacidade de throughput de transações escala dramaticamente: 3,4+ milhões de TPS teóricos máximos com base na meta de 850 MB/s de disponibilidade de dados. Testes de stress do mundo real validam essas projeções — a Kusama atingiu 143.000 TPS com apenas 23% da capacidade de carga em agosto de 2025, enquanto o teste de stress "Spammening" da Polkadot atingiu 623.000 TPS em 2024. Com as otimizações adicionais da JAM e a contagem expandida de cores (visando 350 cores com escalabilidade elástica), o limiar de 1 milhão+ TPS torna-se alcançável em produção.

A capacidade computacional é medida em 150 mil milhões de gás por segundo quando totalmente operacional, de acordo com as estimativas do Gray Paper, refletindo a execução total da PVM em todos os cores. O mecanismo de consenso mantém tempos de bloco de 6 segundos com finalidade determinística via GRANDPA em aproximadamente 18 segundos (cerca de 3 blocos). O SAFROLE, algoritmo de produção de blocos baseado em SNARK da JAM, fornece operação quase sem forks através de seleção anónima de validadores usando zkSNARKs e RingVRF, com tickets a servir como entradas anónimas na produção de blocos com duas épocas de antecedência.

Os requisitos de hardware do validador permanecem acessíveis a operadores profissionais, embora exijam recursos significativos:

• CPU: 8 núcleos físicos a 3,4 GHz mínimo (desempenho single-threaded priorizado)
• RAM: 128 GB mínimo
• Armazenamento: 2 TB NVMe SSD mínimo (priorizando latência sobre throughput), com crescimento contínuo estimado em 50 GB/mês
• Rede: Conexão simétrica mínima de 500 Mbit/s (1 Gbit/s preferencial) para lidar com grandes contagens de serviços e garantir controlo de congestionamento
• Sistema Operativo: Baseado em Linux (Kernel 5.16 ou posterior)
• Uptime: 99%+ necessário para evitar penalidades de slashing

O conjunto de validadores consiste em 1.023 validadores — a mesma contagem da Polkadot atual — todos a receber recompensas de bloco iguais, independentemente do stake que os apoia. Esta distribuição igual de recompensas cria incentivos económicos para que o stake se espalhe por vários validadores, em vez de se concentrar em alguns grandes operadores, promovendo a descentralização. Os requisitos mínimos de stake são dinâmicos; historicamente, entrar no conjunto de validadores ativos exigia aproximadamente 1,75 milhões de DOT de stake total (self-stake mais nomeações), embora a intenção mínima de nomeação seja de 250 DOT. O período de desvinculação de 28 dias permanece inalterado em relação à Polkadot atual.

A camada de rede da JAM transita para o protocolo QUIC para conexões diretas ponto a ponto entre todos os 1.000+ validadores, evitando os problemas de exaustão de sockets das stacks de rede tradicionais. Como a JAM é fundamentalmente sem transações (sem mempool ou gossip), o sistema emprega grid-diffusal para broadcast: os validadores organizam-se numa grelha lógica e as mensagens propagam por linha e depois por coluna, reduzindo drasticamente os requisitos de largura de banda em comparação com protocolos de gossip completos.

O ambiente de teste JAM Toaster demonstra a escala da infraestrutura de suporte ao desenvolvimento: 1.023 nós com 12.276 cores e 16 TB de RAM localizados nas instalações do Polkadot Palace em Lisboa, classificando-se entre os 500-1000 maiores supercomputadores globais. Esta infraestrutura de teste em larga escala aborda limitações históricas onde pequenas redes de teste não conseguiam simular dinâmicas de rede em grande escala e as redes de produção careciam de capacidades de monitorização abrangentes.

Modelo económico: tokenomics DOT e precificação baseada em coretime​

A JAM mantém o DOT como o único token nativo sem criação de novos tokens, preservando a continuidade com o modelo económico da Polkadot, ao mesmo tempo que introduz mudanças estruturais significativas. A arquitetura económica centra-se na implantação de serviços sem permissão, onde qualquer pessoa pode carregar e executar código por taxas proporcionais aos recursos utilizados. Os serviços não têm limites predefinidos de código, dados ou estado — a capacidade é determinada por fatores criptoeconómicos, especificamente a quantidade de DOT depositada como garantia económica.

A tokenomics sofreu uma grande transformação em 2025 com o Referendo 1710 a implementar um limite de fornecimento de 2,1 mil milhões de DOT e um cronograma de inflação decrescente. As emissões anuais de tokens serão reduzidas para metade a cada dois anos a partir de março de 2026, criando um modelo de escassez semelhante ao Bitcoin. A inflação anual atual é de 7,56% (abaixo dos 10% iniciais), projetada para atingir aproximadamente 1,91 mil milhões de DOT de fornecimento total até 2040, versus 3,4 mil milhões sob o modelo anterior. Esta pressão deflacionária visa apoiar a acumulação de valor a longo prazo, mantendo recompensas suficientes para a segurança da rede.

A estrutura de taxas transita de leilões de parachain para precificação baseada em coretime, substituindo o complexo mecanismo de leilão de slots da Polkadot 1.0 por opções flexíveis:

O Bulk Coretime fornece subscrições mensais para acesso consistente a cores computacionais, permitindo um orçamento previsível para projetos que exigem throughput garantido. O On-Demand Coretime oferece acesso pay-as-you-go para uso esporádico, reduzindo drasticamente as barreiras de entrada em comparação com leilões de slots de parachain de milhões de dólares. Este modelo de coretime ágil permite a compra de recursos computacionais por durações que variam de segundos a anos, otimizando a eficiência do capital.

A JAM introduz um novo modelo misto de consumo de recursos, onde os pacotes de trabalho podem combinar tarefas computacionalmente intensivas com operações intensivas em dados. Ao emparelhar serviços com requisitos de recursos diversos — por exemplo, verificação de prova de conhecimento zero (intensiva em computação) com disponibilidade de dados (intensiva em armazenamento) — o sistema otimiza a utilização do hardware do validador e reduz os custos gerais. Os incentivos económicos alinham naturalmente os sequenciadores para agrupar itens de trabalho relacionados e co-localizar serviços que comunicam frequentemente nos mesmos cores.

A arquitetura sem transações elimina completamente as estruturas tradicionais de taxas de transação. Em vez de os utilizadores submeterem transações a um mempool com taxas de gás, todas as ações passam pela fase Refine off-chain antes que os resultados sejam integrados on-chain. Este modelo económico fundamentalmente diferente cobra pela aquisição de coretime e processamento de pacotes de trabalho, em vez de gás por transação, com as taxas determinadas pelos recursos computacionais e de dados consumidos durante as fases Refine e Accumulate.

A economia dos validadores continua o Nominated Proof-of-Stake (NPoS) da Polkadot com recompensas de bloco iguais distribuídas por todos os validadores ativos por era, independentemente do tamanho do stake. Os validadores definem as suas próprias taxas de comissão deduzidas das recompensas totais antes da distribuição aos nomeadores. As fontes de receita incluem recompensas de bloco (primárias), bónus de pontos de era por participação ativa, gorjetas de utilizadores (100% para o validador) e taxas de comissão de nomeadores. As estatísticas atuais de staking mostram uma taxa de participação de 58% com 825,045 milhões de DOT staked em 600 validadores ativos.

Os serviços associam saldos de tokens diretamente a código e estado, permitindo ajustes do modelo económico que não são facilmente alcançáveis em cadeias puramente atualizáveis. Esta inovação permite que os serviços detenham e gerenciem DOT, criando atores económicos que podem pagar pelas suas próprias operações, implementar novos mecanismos tokenómicos ou servir como custodiantes para fundos de utilizadores — tudo sem intermediários confiáveis.

O modelo de segurança económica baseia-se em Economic Validators (ELVs) — um mecanismo de rollup cínico onde validadores selecionados aleatoriamente reexecutam o trabalho para verificar a correção. Esta abordagem prova ser aproximadamente 4.000 vezes mais económica do que as provas ZK para garantir a correção computacional, alavancando o comprovado modelo de segurança criptoeconómica da Polkadot. Quando os resultados do trabalho são contestados, o mecanismo de julgamento pode pausar a finalidade por até 1 hora enquanto os validadores chegam a um consenso, mantendo as garantias de segurança mesmo sob condições adversas.

Estado do desenvolvimento: implementações, testnets e roadmap para a mainnet​

Em outubro de 2025, o desenvolvimento da JAM atingiu massa crítica com 43 equipas de implementação ativas em cinco categorias de linguagem a competir pelo pool de prémios de 10 milhões de DOT + 100.000 KSM (avaliado em $60-100 milhões de USD). Esta diversidade sem precedentes de implementadores visa espalhar o conhecimento para além de uma única equipa, garantir a resiliência do protocolo através da diversidade de clientes e identificar ambiguidades de especificação através de implementações independentes.

Múltiplas implementações atingiram 100% de conformidade JAM até agosto de 2025, incluindo JAM DUNA (Go), JamZig (Zig), Jamzilla (Go), JavaJAM (Java), SpaceJam (Rust), Vinwolf (Rust), Jamixir (Elixir) e Boka (Swift). O JAM Conformance Dashboard fornece benchmarks de desempenho em tempo real, resultados de fuzz testing e comparações de implementação, permitindo uma avaliação transparente da maturidade de cada cliente. A implementação PolkaJAM da Parity em Rust lidera atualmente nas métricas de desempenho.

O JAM Gray Paper progrediu através de múltiplas revisões: v0.7.0 lançado a 25 de junho de 2025 com pseudocódigo detalhado para execução PVM e o Aggregating Scheduler, seguido pela v0.7.1 a 26 de julho de 2025 incorporando feedback da comunidade. O Gray Paper emula a abordagem do Yellow Paper da Ethereum, fornecendo especificações matemáticas formais que permitem múltiplas implementações independentes, em vez de depender de um único cliente de referência.

A atividade da Testnet acelerou ao longo de 2025 com o JAM Experience Event em Lisboa (9-11 de maio) a marcar um grande lançamento público da testnet, com a presença de desenvolvedores internacionais. A testnet Minimum Viable Rollup foi lançada em junho de 2025, permitindo que os desenvolvedores testassem a funcionalidade básica da JAM num ambiente de rede ao vivo. Múltiplas equipas de implementação executam testnets privadas continuamente, e a Parity lançou o binário experimental PolkaJAM, permitindo que os desenvolvedores criem as suas próprias testnets JAM para experimentação.

O JAM Implementer's Prize estrutura as recompensas em cinco marcos por caminho de implementação (Validating Node, Non-PVM Validating Node ou Light Node):

Marco 1 (IMPORTER): 100.000 DOT + 1.000 KSM por passar nos testes de conformidade de transição de estado e importar blocos. As submissões foram abertas em junho de 2025, com a Polkadot Fellowship a rever as submissões. Marco 2 (AUTHORER): Adicional de 100.000 DOT + 1.000 KSM para conformidade total, incluindo produção de blocos, rede e componentes off-chain. Marco 3 (HALF-SPEED): 100.000 DOT + 1.000 KSM por atingir desempenho de nível Kusama, concedendo acesso ao JAM Toaster para testes em larga escala. Marco 4 (FULL-SPEED): 100.000 DOT + 1.000 KSM por desempenho de nível mainnet Polkadot com auditoria de segurança externa profissional gratuita. Marco 5 (SECURE): Final de 100.000 DOT + 1.000 KSM por passar em auditorias de segurança completas sem vulnerabilidades significativas.

A diversidade de linguagens abrange linguagens empresariais tradicionais (Java, Kotlin, C#, Go no Conjunto A), linguagens de desempenho nativo (C, C++, Rust, Swift, Zig no Conjunto B), linguagens de script concisas (Python, JavaScript, TypeScript no Conjunto C) e linguagens focadas na correção (OCaml, Elixir, Julia, Haskell no Conjunto D). O Conjunto Z oferece um máximo de 5.000 KSM para implementações em linguagens esotéricas como Brainfuck ou Whitespace, demonstrando o espírito lúdico da comunidade enquanto prova a clareza da especificação.

O cronograma para a implantação da mainnet segue um calendário ambicioso:

• Final de 2025: Revisões finais do Gray Paper (v0.8.0, v0.9.0, aproximando-se da v1.0), submissões e revisões contínuas de marcos, participação expandida na testnet
• Q1 2026: Atualização da mainnet JAM direcionada na rede Polkadot após aprovação de governação via referendo OpenGov
• 2026: Implantação da CoreChain Fase 1, testnet pública oficial da JAM, transição completa da rede Polkadot para a arquitetura JAM

A estratégia de implantação envolve uma única atualização abrangente, em vez de mudanças incrementais iterativas, permitindo uma restrição precisa das ações pós-atualização e minimizando a sobrecarga do desenvolvedor devido a mudanças disruptivas constantes. Esta abordagem consolida todas as mudanças disruptivas numa única transição, evitando a acumulação de complexidade que afetou a evolução da Polkadot 1.0. No entanto, a aprovação da governação permanece obrigatória — a JAM exige a aprovação da governação on-chain descentralizada da Polkadot com votação dos detentores de tokens DOT. O precedente da aprovação quase unânime do Referendo 682 em maio de 2024 (com mais de 31 milhões de DOT de apoio) sugere um forte apoio da comunidade, embora a implantação final da mainnet exija aprovação de governação separada.

Implementações no mundo real já estão a surgir. A Acala Network anunciou o JAMVerse em agosto de 2025, construindo a primeira dApp chain nativa da JAM com um cliente JAM de classe B baseado em Swift (Boka). O seu roadmap inclui a migração de serviços DeFi centrais (Swap, Staking, LDOT) para a JAM para operações com latência sub-bloco, o desenvolvimento de um adaptador JAM-XCM para preservar a interoperabilidade com parachains Substrate e a demonstração de empréstimos flash cross-chain habilitados pela componibilidade síncrona. A Unique Network's Quartz está a transitar para ambientes de teste internos para a arquitetura JAM, com o planeamento concluído até outubro de 2025.

Impacto no ecossistema: compatibilidade retroativa e estratégias de migração​

O design da JAM prioriza a compatibilidade retroativa total com as parachains Polkadot existentes, garantindo que a transição aprimore, em vez de perturbar, o ecossistema. A documentação oficial confirma que "parte da proposta incluirá ferramentas e garantias de compatibilidade hard-coded", com a Web3 Foundation a assegurar que "as parachains permanecerão cidadãos de primeira classe mesmo pós-JAM". Quando a JAM for lançada, a Relay Chain será atualizada e as parachains tornar-se-ão automaticamente serviços a correr sobre a JAM sem exigir quaisquer alterações de código.

O Serviço de Parachains (alternativamente chamado CoreChains ou ChainService) consolida toda a funcionalidade da parachain Polkadot 1.1 num único serviço JAM. As parachains existentes baseadas em Substrate continuam a operar através desta camada de compatibilidade com comportamento funcionalmente inalterado — "A funcionalidade de qualquer uma das parachains atualmente em execução na Polkadot não será impactada." Do ponto de vista das equipas de parachain, "a stack tecnológica não parece muito diferente. Elas continuarão a ser validadas por validadores" com fluxos de trabalho de desenvolvimento semelhantes.

Três caminhos de migração permitem que as equipas adotem as capacidades da JAM ao seu próprio ritmo:

A Opção A: Sem Migração permite que as equipas de parachain continuem a operar exatamente como antes, sem esforço. O serviço de parachains lida com todas as preocupações de compatibilidade, mantendo as características de desempenho e os fluxos de trabalho de desenvolvimento atuais. Este caminho padrão é adequado para equipas satisfeitas com as capacidades existentes ou que preferem adiar as funcionalidades específicas da JAM até que a tecnologia amadureça.

A Opção B: Migração Parcial permite abordagens híbridas onde as equipas continuam a operar como uma parachain tradicional, enquanto implantam funcionalidades específicas como serviços nativos da JAM. Por exemplo, uma parachain DeFi pode continuar as suas operações de cadeia principal inalteradas, enquanto implanta um serviço ZK-rollup para funcionalidades de privacidade ou um serviço de oráculo para feeds de preços diretamente nos cores da JAM. Esta transição gradual permite testar novas capacidades sem compromisso total, mantendo a compatibilidade retroativa enquanto acede a funcionalidades avançadas seletivamente.

A Opção C: Migração Completa envolve a reconstrução usando o modelo de serviço da JAM com pontos de entrada Refine, Accumulate e onTransfer distintos. Este caminho oferece máxima flexibilidade — implantação sem permissão, componibilidade síncrona através de Accords, frameworks baseados em atores CorePlay e acesso direto aos novos modelos de execução da JAM. O JAMVerse da Acala exemplifica esta abordagem: construir uma implementação nativa completa da JAM, mantendo a operação da parachain legada durante a transição. A migração completa exige um esforço de desenvolvimento significativo, mas desbloqueia todo o potencial da JAM.

A infraestrutura de suporte à migração inclui a ferramenta de migração Omicode mencionada na documentação da Acala como permitindo "migração suave para a JAM sem necessidade de modificar a lógica de runtime" — aparentemente uma camada de compatibilidade para parachains Substrate existentes. O Polkadot SDK permanece compatível com a JAM, embora as Funções de Validação de Parachain (PVFs) sejam redirecionadas de WebAssembly para PVM. Uma vez que a PVM representa uma modificação menor do RISC-V (já um alvo oficial do LLVM), as bases de código existentes compiladas para WASM podem geralmente ser recompiladas para PVM com alterações mínimas.

A transição de WASM para PVM oferece vários benefícios: a medição gratuita elimina a sobrecarga de gás durante a execução, a arquitetura baseada em registos evita o problema de alocação de registos NP-completo inerente ao design baseado em stack do WASM, o suporte natural a continuações permite que os programas pausem e retomem entre os limites dos blocos, e as velocidades de execução excecionais em hardware convencional fornecem melhorias de desempenho sem alterações de infraestrutura. Os pallets FRAME do Substrate continuam a funcionar dentro dos serviços de parachain, embora o sistema medido da JAM muitas vezes dispense os requisitos frequentes de benchmarking que sobrecarregavam o desenvolvimento do Substrate.

A evolução do XCM (Cross-Consensus Message format) garante a interoperabilidade durante a transição. O XCMP (Cross-Chain Message Passing) completo torna-se obrigatório na JAM — onde o HRMP (Horizontal Relay-routed Message Passing) atual armazena todos os dados da mensagem na Relay Chain com limites de payload de 4 KB, o XCMP da JAM coloca apenas os cabeçalhos das mensagens on-chain com transmissão ilimitada de dados off-chain. Este requisito arquitetónico decorre de limites estritos de transmissão de dados entre as fases Refine e Accumulate, permitindo payloads de dados realistas sem gargalos na Relay Chain.

Os adaptadores JAM-XCM mantêm a interoperabilidade entre os serviços JAM e as parachains Substrate durante o período de transição. As melhorias do XCM v5, a serem lançadas em 2025, incluem transações multi-hop, pagamentos de taxas multi-chain, menos assinaturas necessárias e melhor prevenção de erros — tudo projetado para funcionar perfeitamente na transição Polkadot-para-JAM. Os Accords introduzem capacidades XCM síncronas, permitindo interações com confiança minimizada, como teletransporte direto de tokens entre cadeias sem intermediários baseados em reservas.

Os mecanismos de governação para staking, tesouraria e atualizações de protocolo migram para serviços, em vez de serem consagrados no protocolo central. Esta separação de preocupações simplifica a própria cadeia JAM, preservando toda a funcionalidade necessária no código de serviço atualizável. As funções ao nível da aplicação, incluindo distribuição de recompensas de staking, mercados de coretime e votação de governação, residem em serviços que podem evoluir independentemente através dos seus próprios mecanismos de atualização, sem exigir alterações ao nível do protocolo.

A transição do validador permanece direta — os operadores precisarão de executar clientes compatíveis com JAM, em vez dos clientes Polkadot atuais, mas as responsabilidades do validador de produzir blocos, validar transações (agora pacotes de trabalho) e manter o consenso continuam inalteradas. A mudança de BABE+GRANDPA para SAFROLE+GRANDPA para consenso afeta principalmente os internos da implementação do cliente, em vez dos procedimentos operacionais. Os validadores que mantêm 99%+ de uptime, respondem prontamente aos pedidos de validação e participam no consenso continuarão a receber recompensas iguais por era, como na Polkadot atual.

Experiência do desenvolvedor: de smart contracts a serviços e além​

A JAM transforma fundamentalmente a experiência do desenvolvedor, removendo barreiras de entrada e expandindo as opções de capacidade. Onde a Polkadot 1.0 forçava as equipas a escolher entre smart contracts (capacidade limitada, implantação fácil) ou parachains (capacidade total, acesso baseado em leilão), a JAM oferece um ambiente flexível e rico para ambos, além de novos modelos de execução.

O modelo de implantação de serviço sem permissão assemelha-se à implantação de smart contracts na Ethereum — os desenvolvedores podem implantar código como um serviço sem aprovação de governação ou leilões de slots, pagando apenas pelos recursos utilizados através da aquisição de coretime. Isso reduz drasticamente as barreiras financeiras: sem lances de leilão multimilionários, sem compromissos de slots de dois anos, sem mecânicas complexas de crowdloan. Os serviços escalam economicamente através de depósitos de DOT que limitam criptoeconomicamente o consumo de recursos, em vez de através de gatekeeping político ou financeiro.

Os smart contracts ink! continuam a prosperar no ecossistema da JAM com potencial implantação direta nos cores da JAM via serviços dedicados, eliminando a necessidade de hospedagem intermédia em parachains. As ferramentas permanecem maduras: cargo-contract para compilação, ink! playground para experimentação, rustfmt e rust-analyzer para desenvolvimento, Chainlens explorer para verificação de contratos e frameworks de teste de integração. O caminho de graduação de prova de conceito para produção permanece claro: começar com contratos ink! para iteração rápida, validar o ajuste produto-mercado e, em seguida, migrar para serviços JAM ou parachains quando os requisitos de desempenho o exigirem — reutilizando código Rust, testes e componentes de frontend em todo o processo.

Três pontos de entrada de serviço definem o modelo de programação da JAM, exigindo que os desenvolvedores pensem de forma diferente sobre a computação:

A função Refine lida com a computação sem estado que transforma as entradas de rollup em saídas. Aceita até 15 MB de itens de trabalho por slot de 6 segundos, executa por até 6 segundos de gás PVM e produz resultados comprimidos de no máximo 90 KB. O Refine é executado off-chain em paralelo em subconjuntos de validadores, com apenas pesquisas de preimage disponíveis para acesso a dados. Esta função realiza o trabalho computacional pesado — processamento de transações, verificação de provas, transformação de dados — inteiramente isolada do estado global.

A função Accumulate integra as saídas do Refine no estado do serviço através de operações com estado limitadas a aproximadamente 10 milissegundos por saída. Pode ler o armazenamento de qualquer serviço (permitindo consultas entre serviços), escrever no seu próprio armazenamento chave-valor, transferir fundos entre serviços, criar novos serviços, atualizar o seu próprio código e solicitar disponibilidade de preimage. O Accumulate é executado de forma síncrona em todos os validadores, tornando-o caro, mas seguro por padrão. A assimetria — 6 segundos para Refine versus 10 milissegundos para Accumulate — impõe disciplina arquitetónica: empurrar a computação para off-chain, manter as atualizações de estado mínimas.

A função onTransfer lida com a comunicação entre serviços através de mensagens assíncronas. Os serviços podem enviar mensagens sem esperar por respostas, permitindo um acoplamento flexível, evitando bloqueios. Futuras melhorias podem permitir a alocação de gás adicional para interações complexas entre serviços ou o tratamento de padrões síncronos através de Accords.

O CorePlay representa um framework experimental baseado em atores que mostra as capacidades únicas da JAM. Atores implantados diretamente em cores podem usar padrões de programação síncronos normais — código estilo fn main() padrão com sintaxe async/await. Quando atores no mesmo core se chamam, a execução prossegue de forma síncrona. Ao chamar atores em cores diferentes, as continuações da PVM pausam automaticamente a execução, serializam o estado e retomam num bloco posterior quando os resultados chegam. Esta abstração faz com que a execução assíncrona multi-bloco pareça síncrona para os desenvolvedores, simplificando drasticamente a lógica de aplicações distribuídas.

As melhorias nas ferramentas de desenvolvimento incluem implantação mais simples através da criação de serviços sem permissão, requisitos de benchmarking reduzidos via execução PVM medida da JAM, precificação transparente e previsível do coretime (evitando a volatilidade de taxas estilo Ethereum) e acesso ao JAM Toaster para implementadores do Marco 3+, fornecendo simulação de rede completa de 1.023 nós para testes de desempenho realistas. O suporte a várias linguagens — equipas a trabalhar em Rust, Go, Swift, Zig, Elixir, OCaml e mais — demonstra a clareza da especificação e permite que os desenvolvedores escolham toolchains familiares.

A componibilidade síncrona transforma o que é possível em aplicações multi-chain. As parachains Polkadot atuais comunicam assincronamente via XCM, exigindo que as aplicações lidem com respostas atrasadas, timeouts e cenários de rollback. Os Accords da JAM permitem smart contracts multi-instância que governam protocolos de interação entre serviços com garantias de execução síncrona. Por exemplo, o roadmap da Acala demonstra "iniciar empréstimo flash na Ethereum e executar arbitragem em múltiplas cadeias através de uma única chamada sincronizada" — atomicidade anteriormente impossível em ecossistemas blockchain fragmentados.

A mudança de pallets Substrate para serviços JAM reduz o atrito da governação — os pallets Substrate exigem aprovação de governação on-chain para implantação e atualizações, enquanto os serviços JAM são implantados sem permissão como smart contracts. Os desenvolvedores mantêm a compatibilidade com o Substrate SDK e podem continuar a usar o FRAME para serviços de parachain, mas os serviços nativos da JAM acedem a modelos de desenvolvimento simplificados sem a sobrecarga de coordenação de atualização de pallets.

A documentação e os recursos educacionais expandiram-se significativamente ao longo de 2025 com o JAM 2025 World Tour a chegar a 9 cidades em 2 continentes e a envolver mais de 1.300 desenvolvedores. A documentação técnica inclui o abrangente Gray Paper, seções JAM da Polkadot Wiki, guias oficiais para desenvolvedores e tutoriais criados pela comunidade. O programa Decentralized Futures da Web3 Foundation financia iniciativas de educação JAM, enquanto o Implementer's Prize cria incentivos económicos para a produção de documentação e ferramentas de desenvolvimento de alta qualidade.

Visão estratégica: resolvendo o trilema blockchain através da inovação arquitetónica​

A visão de Gavin Wood para a JAM aborda o que ele identifica como a limitação fundamental da blockchain — o antagonismo tamanho-sincronia, onde os sistemas devem escolher entre escala e coerência. Cadeias monolíticas como Bitcoin e Ethereum L1 alcançam alta sincronia e componibilidade, mas não podem escalar além dos limites computacionais de um único nó. Sistemas sharded como Ethereum L2s, parachains Polkadot e zonas Cosmos alcançam escala através de particionamento, mas sacrificam a coerência, forçando as aplicações a silos isolados com apenas comunicação assíncrona entre shards.

A JAM tenta transcender esta falsa dicotomia através da coerência parcial — um sistema que "garante coerência por períodos críticos" enquanto mantém a escalabilidade através da paralelização. Serviços agendados para o mesmo core no mesmo bloco interagem de forma síncrona, criando subconjuntos coerentes. Serviços em cores diferentes comunicam assincronamente, permitindo execução paralela. Crucialmente, os limites dos shards permanecem fluidos e economicamente impulsionados, em vez de serem impostos pelo protocolo. Os sequenciadores têm incentivos para co-localizar serviços que comunicam frequentemente, e os desenvolvedores podem otimizar para interação síncrona quando necessário, sem sincronia global do sistema.

O objetivo estratégico centra-se na criação de um "supercomputador sem confiança e maioritariamente coerente" que combina três propriedades historicamente incompatíveis:

Ambiente de smart contract sem permissão semelhante ao Ethereum permite que qualquer pessoa implante código sem aprovação de autoridade ou gatekeeping económico. Os serviços são criados e atualizados sem votos de governação, vitórias em leilões ou compromissos de slots. Esta abertura impulsiona a inovação, removendo barreiras institucionais, permitindo experimentação rápida e promovendo um mercado competitivo de serviços, em vez de recursos alocados politicamente.

A computação sideband segura paralelizada em rede de nós escalável pioneira da Polkadot fornece segurança partilhada em todos os serviços através do conjunto completo de 1.023 validadores. Ao contrário das zonas Cosmos com segurança independente ou dos L2s da Ethereum com suposições de confiança variadas, cada serviço JAM herda garantias de segurança idênticas desde o primeiro dia. A execução paralelizada em cores permite o escalonamento computacional sem fragmentar a segurança — adicionar serviços não dilui a segurança, aumenta o throughput total do sistema.

A componibilidade síncrona dentro de limites de execução coerentes desbloqueia efeitos de rede. Protocolos DeFi podem compor atomicamente entre serviços para empréstimos flash, arbitragem e liquidações. Mercados NFT podem agrupar atomicamente ativos de múltiplas cadeias. Aplicações de jogos podem interagir sincronicamente com primitivas DeFi para economias dentro do jogo. Esta componibilidade — historicamente limitada a cadeias monolíticas — torna-se disponível num ambiente escalado e paralelizado.

O posicionamento a longo prazo de Wood para a JAM estende-se além da blockchain para a computação geral. O slogan "computador global descentralizado" ecoa deliberadamente as primeiras descrições da Ethereum, mas com fundamentos arquitetónicos que suportam a metáfora em escala. Onde o "computador mundial" da Ethereum atingiu rapidamente os limites de escalabilidade, necessitando de pragmatismo L2, a JAM constrói o escalonamento computacional na sua fundação através do paradigma Refine-Accumulate e do suporte a continuações da PVM.

A evolução da Polkadot 1.0 para a JAM reflete uma filosofia de "menos opinião" — movendo-se de domínio-específico para propósito geral, de parachains consagradas para serviços arbitrários, de complexidade de protocolo atualizável para simplicidade fixa com aplicações atualizáveis. Este minimalismo arquitetónico permite oportunidades de otimização impossíveis em sistemas em constante evolução: parâmetros fixos permitem otimização agressiva da topologia de rede, tempos conhecidos permitem algoritmos de agendamento precisos, especificações imutáveis permitem aceleração de hardware sem risco de obsolescência.

Cinco fatores impulsionadores motivam o design da JAM:

A Resiliência através da descentralização exige mais de 1.000 operadores de validadores independentes que mantêm a segurança em todos os serviços. O design da JAM preserva o NPoS pioneiro da Polkadot com recompensas iguais para os validadores, prevenindo a concentração de stake enquanto mantém uma robusta tolerância a falhas bizantinas.

A Generalidade que permite computação arbitrária expande-se para além dos casos de uso específicos da blockchain. A PVM aceita qualquer código RISC-V, suportando linguagens de Rust e C++ a implementações mais exóticas. Os serviços podem implementar blockchains, plataformas de smart contracts, ZK-rollups, camadas de disponibilidade de dados, oráculos, redes de armazenamento ou padrões computacionais inteiramente novos.

O Desempenho que alcança "escalonamento mais ou menos indefinido" vem da paralelização horizontal — adicionar cores escala o throughput sem limites arquitetónicos. O objetivo de 850 MB/s representa a capacidade de lançamento; o escalonamento elástico e os mercados económicos de coretime permitem aumentar a capacidade à medida que a demanda aumenta, sem alterações de protocolo.

A Coerência que fornece interação síncrona quando necessário resolve o problema de componibilidade que assola os sistemas sharded. Os Accords permitem a aplicação de protocolos com confiança minimizada entre serviços, transferências de tokens cross-chain síncronas e operações atómicas multi-serviço anteriormente impossíveis em ecossistemas fragmentados.

A Acessibilidade que reduz as barreiras democratiza a infraestrutura. Substituir os leilões de parachain de milhões de dólares por coretime pay-as-you-go, implantação de serviços sem permissão e alocação flexível de recursos permite que projetos de todas as escalas — de desenvolvedores individuais a equipas empresariais — acedam a infraestrutura de classe mundial.

Cenário competitivo: JAM versus abordagens alternativas de Camada 0 e Camada 1​

O posicionamento da JAM em relação ao roadmap da Ethereum revela filosofias de escalonamento fundamentalmente diferentes. A Ethereum persegue a modularidade centrada em L2, onde a L1 fornece disponibilidade de dados e liquidação, enquanto a execução migra para rollups otimistas e ZK como Arbitrum, Optimism, Base e zkSync. O Proto-danksharding (EIP-4844) adicionou transações blob, fornecendo disponibilidade temporária de dados, com o danksharding completo planeado para aumentar a capacidade em 100x. A Proposer-Builder Separation (PBS) e o redesenho anunciado da camada de consenso Beam Chain continuam a otimizar a L1 para o seu papel cada vez mais restrito.

Esta estratégia cria particionamento persistente: os L2s permanecem ecossistemas isolados com liquidez fragmentada, suposições de confiança variadas, períodos de levantamento de 7 dias para rollups otimistas, riscos de centralização do sequenciador e volatilidade de taxas durante o congestionamento da L1 que se propaga a todos os L2s. A componibilidade funciona suavemente dentro de cada L2, mas as interações cross-L2 revertem para mensagens assíncronas com riscos de ponte. A comunidade Ethereum abraçou o pragmatismo L2 depois que a visão original de sharding da Ethereum 2.0 se mostrou muito complexa — mas este pragmatismo aceita limitações fundamentais como trade-offs inerentes.

A JAM persegue o que a Ethereum 2.0 originalmente prometeu: execução sharded nativa com estado coerente construído na camada de consenso. Onde a Ethereum moveu a execução off-chain para L2s, a JAM constrói a execução paralela no consenso L1 através do modelo Refine-Accumulate. Onde a Ethereum aceitou ecossistemas L2 fragmentados, a JAM fornece segurança unificada e componibilidade ao nível do protocolo através de serviços e Accords. A aposta arquitetónica difere fundamentalmente — a Ethereum aposta na inovação L2 especializada, a JAM aposta na escalabilidade L1 generalizada.

As metas de desempenho ilustram a ambição: a Ethereum processa aproximadamente 15 transações por segundo na L1 com 1,3 MB por bloco de disponibilidade de dados, enquanto os L2s coletivamente lidam com milhares de TPS com suposições de segurança variadas. A JAM visa 850 MB/s de disponibilidade de dados (aproximadamente 650x Ethereum L1) e 3,4+ milhões de TPS de capacidade teórica com segurança unificada. O modelo computacional também diverge — a execução sequencial EVM da Ethereum versus o processamento paralelo de 350 cores da JAM representa abordagens fundamentalmente diferentes para o problema de escalonamento.

A Cosmos com o protocolo Inter-Blockchain Communication (IBC) representa uma visão alternativa da Camada 0, priorizando a soberania sobre a segurança partilhada. As zonas Cosmos são blockchains soberanas independentes com os seus próprios conjuntos de validadores, governação e modelos de segurança. O IBC permite comunicação sem confiança através da verificação de light client — as cadeias verificam independentemente o estado da contraparte sem depender de validadores partilhados ou pools de segurança.

Esta filosofia de soberania em primeiro lugar concede a cada zona autonomia completa: mecanismos de consenso personalizados, modelos económicos especializados e decisões de governação independentes sem sobrecarga de coordenação. No entanto, a soberania acarreta custos — novas zonas devem inicializar conjuntos de validadores e segurança independentemente, enfrentar segurança fragmentada (um ataque a uma zona não compromete outras, mas também significa níveis de segurança variados entre zonas) e experimentar comunicação verdadeiramente assíncrona sem opções de componibilidade síncrona.

A JAM adota a abordagem oposta: segurança em primeiro lugar com validação partilhada. Todos os 1.023 validadores protegem cada serviço desde o lançamento, eliminando desafios de inicialização e fornecendo garantias de segurança uniformes. Os serviços sacrificam a soberania — operam dentro do modelo de execução da JAM e dependem do conjunto de validadores partilhado — mas ganham segurança imediata, componibilidade ao nível do protocolo e menor sobrecarga operacional. A diferença filosófica é profunda: a Cosmos otimiza para independência soberana, a JAM otimiza para integração coerente.

As sub-redes Avalanche fornecem outra arquitetura comparativa onde as sub-redes são blockchains soberanas da Camada 1 que os validadores escolhem validar. Os validadores da rede primária (exigindo 2.000 AVAX de stake) podem adicionalmente validar quaisquer sub-redes que escolham, permitindo conjuntos de validadores personalizados por sub-rede. Este modelo de segurança horizontal (mais sub-redes = mais conjuntos de validadores) contrasta com o modelo de segurança vertical da JAM (todos os serviços partilham o conjunto completo de validadores).

A arquitetura de sub-rede permite a otimização específica da aplicação — as sub-redes de jogos podem ter alto throughput e baixa finalidade, as sub-redes DeFi podem priorizar segurança e descentralização, as sub-redes empresariais podem implementar validadores permissionados. O consenso Snowman da Avalanche fornece finalidade sub-segundo dentro das sub-redes. No entanto, as sub-redes permanecem em grande parte isoladas: o Avalanche Warp Messaging (AWM) fornece comunicação básica entre sub-redes, mas sem a componibilidade ao nível do protocolo ou execução síncrona que os Accords da JAM permitem.

O posicionamento de desempenho mostra a Avalanche a enfatizar a finalidade sub-segundo (aproximadamente 1 segundo versus 18 segundos da JAM), mas com segurança mais fragmentada entre sub-redes, em vez dos 1.023 validadores unificados da JAM por serviço. A arquitetura de estado também difere fundamentalmente: as sub-redes Avalanche mantêm máquinas de estado completamente isoladas, enquanto os serviços JAM partilham uma camada de acumulação que permite leituras entre serviços e interações síncronas quando agendadas para o mesmo core.

Protocolos de interoperabilidade externos como LayerZero, Wormhole, Chainlink CCIP e Axelar servem propósitos diferentes do XCMP nativo da JAM. Estes protocolos fazem a ponte entre ecossistemas blockchain completamente díspares — Ethereum para Solana para Bitcoin para Cosmos — contando com validadores externos, oráculos ou redes de relayer para segurança. O LayerZero usa um modelo Oracle + Relayer que protege mais de $6 mil milhões de valor total bloqueado em mais de 50 cadeias. O Wormhole emprega 19 Guardiões que validam mais de 1 mil milhão de mensagens com uma avaliação totalmente diluída de $10,7 mil milhões.

O XCMP da JAM opera numa camada diferente: comunicação intra-ecossistema com validadores de protocolo nativos, em vez de suposições de segurança externas. Os serviços na JAM não precisam de pontes externas para interagir — partilham o mesmo conjunto de validadores, mecanismo de consenso e garantias de segurança. Isso permite interações sem confiança impossíveis com pontes externas: chamadas síncronas, operações atómicas multi-serviço, entrega garantida de mensagens e finalidade ao nível do protocolo.

O posicionamento estratégico sugere coexistência em vez de competição: a JAM usa o XCMP para comunicação interna, enquanto potencialmente integra LayerZero, Wormhole ou protocolos semelhantes para conectividade de cadeia externa. Os serviços JAM poderiam envolver protocolos externos para fazer a ponte para Ethereum, Solana, Bitcoin ou Cosmos, fornecendo o melhor dos dois mundos em conectividade — operações internas sem confiança com pontes externas pragmáticas.

Fundamentos da pesquisa: rigor académico e contribuições inovadoras para a ciência da computação​

O JAM Gray Paper estabelece a base académica do protocolo, emulando o Yellow Paper da Ethereum ao fornecer especificações matemáticas formais que permitem múltiplas implementações independentes. Lançado em abril de 2024 com a versão 0.1, o documento progrediu através de refinamento contínuo — a v0.7.0 em junho de 2025 adicionou pseudocódigo PVM detalhado, a v0.7.1 em julho incorporou feedback da comunidade — aproximando-se da v1.0 esperada para o início de 2026. Este desenvolvimento iterativo de especificações com escrutínio da comunidade é paralelo à revisão por pares académica, melhorando a clareza e detetando ambiguidades.

O resumo do Gray Paper cristaliza a contribuição teórica da JAM: "Apresentamos uma definição abrangente e formal da Jam, um protocolo que combina elementos da Polkadot e da Ethereum. Num único modelo coerente, a Jam fornece um ambiente global de objetos sem permissão singleton — muito parecido com o ambiente de smart contracts pioneiro da Ethereum — emparelhado com computação sideband segura paralelizada numa rede de nós escalável, uma proposta pioneira da Polkadot." Esta síntese de propriedades aparentemente incompatíveis — a componibilidade sem permissão da Ethereum com a segurança partilhada paralelizada da Polkadot — representa o principal desafio teórico que a JAM aborda.

A seleção do RISC-V para os fundamentos da PVM reflete uma análise rigorosa da arquitetura de computadores. O RISC-V emergiu da pesquisa da UC Berkeley como uma arquitetura de conjunto de instruções de código aberto que prioriza a simplicidade e a extensibilidade. Com apenas 47 instruções base, em comparação com centenas em x86 ou ARM, o RISC-V minimiza a complexidade da implementação, mantendo a completude computacional. A arquitetura baseada em registos evita o problema de alocação de registos NP-completo inerente a máquinas virtuais baseadas em stack como o WebAssembly, permitindo compilação mais rápida e desempenho mais previsível.

A PVM da JAM faz modificações mínimas ao RISC-V padrão, principalmente adicionando gestão de memória determinística e medição de gás, enquanto preserva a compatibilidade com as toolchains RISC-V existentes. Este conservadorismo de design permite alavancar décadas de pesquisa em arquitetura de computadores e compiladores de nível de produção (LLVM), em vez de construir infraestrutura de compilador personalizada. Linguagens que compilam para RISC-V — Rust, C, C++, Go e muitas outras — tornam-se automaticamente compatíveis com a JAM sem modificações de compilador específicas da blockchain.

O suporte a continuações na PVM representa uma contribuição teórica significativa. As continuações — a capacidade de pausar a execução, serializar o estado e retomar mais tarde — permitem computação assíncrona multi-bloco sem gestão manual complexa de estado. As VMs blockchain tradicionais carecem de suporte a continuações, forçando os desenvolvedores a dividir manualmente as computações, persistir o estado intermédio e reconstruir o contexto entre transações. O design de stack-in-memory da PVM e a execução determinística permitem suporte a continuações de primeira classe, simplificando drasticamente computações de longa duração ou entre blocos.

O dualismo Refine-Accumulate mapeia conceptualmente para o modelo de programação MapReduce pioneiro da Google para computação distribuída. O Refine opera como a fase Map — transformação embaraçosamente paralela e sem estado de entradas em saídas em trabalhadores distribuídos (cores de validador). O Accumulate opera como a fase Reduce — integração sequencial de resultados transformados em estado unificado. Este padrão da ciência da computação, comprovadamente eficaz em escala massiva em sistemas distribuídos tradicionais, adapta-se elegantemente ao ambiente de confiança minimizada da blockchain com verificação criptográfica a substituir a coordenação centralizada.

O mecanismo de consenso SAFROLE baseia-se em décadas de pesquisa em sistemas distribuídos. O algoritmo evolui do SASSAFRAS (Semi-Anonymous Sortition of Staked Assignees for Fixed-time Rhythmic Assignment of Slots), simplificando-o para os requisitos específicos da JAM, enquanto preserva propriedades chave: produção de blocos sem forks através de seleção anónima de validadores, resistência a ataques DoS direcionados via anonimato baseado em zkSNARKs até a produção de blocos e tempo determinístico que permite agendamento preciso de recursos.

Os fundamentos criptográficos combinam Ring Verifiable Random Functions (RingVRF) para provar a adesão ao conjunto de validadores anonimamente com zkSNARKs para verificação eficiente. O sistema de tickets de avanço de duas épocas — os validadores submetem tickets duas épocas antes da produção de blocos — previne vários ataques, mantendo as garantias de anonimato. Isso representa uma aplicação elegante de primitivas criptográficas modernas para resolver desafios práticos de consenso.

Os Economic Validators (ELVs) como alternativa à verificação de prova ZK fornecem uma nova análise de trade-off segurança vs. custo. A documentação da JAM afirma que os ELVs são aproximadamente 4.000 vezes mais económicos do que as provas de conhecimento zero para garantir a correção computacional. O modelo baseia-se na segurança criptoeconómica: validadores selecionados aleatoriamente reexecutam o trabalho para verificar a correção, com resultados incorretos a desencadear disputas e potencial slashing. Esta abordagem "otimista", onde a correção é assumida, a menos que seja contestada, espelha os rollups otimistas, mas opera ao nível do protocolo com finalidade imediata após auditorias de validador.

O futuro potencialmente combina ELVs e provas ZK num modelo de segurança híbrido: ELVs para segurança limitada onde as garantias criptoeconómicas são suficientes, provas ZK para segurança ilimitada onde a certeza matemática é exigida. Esta flexibilidade permite que as aplicações escolham modelos de segurança que correspondam aos seus requisitos e restrições económicas, em vez de forçar uma abordagem única para todos.

Novas contribuições teóricas da JAM incluem:

O paradigma blockchain sem transações desafia uma suposição fundamental da arquitetura blockchain. Bitcoin, Ethereum e quase todos os sucessores organizam-se em torno de transações — ações de utilizador assinadas num mempool a competir pela inclusão em blocos. A JAM elimina completamente as transações: todas as alterações de estado fluem através de pacotes de trabalho contendo itens de trabalho que passam pelas fases Refine e Accumulate. Este modelo fundamentalmente diferente levanta questões de pesquisa interessantes sobre MEV (Maximal Extractable Value), resistência à censura e experiência do utilizador que a pesquisa académica ainda não explorou totalmente.

O consenso parcialmente coerente representa uma posição inovadora entre sistemas totalmente coerentes (cadeias monolíticas) e totalmente incoerentes (shards isolados). A JAM garante coerência por janelas críticas de 6 segundos quando os serviços co-localizam em cores, enquanto aceita assincronia entre cores. Os mecanismos económicos que impulsionam os padrões de coerência — sequenciadores que otimizam a composição de pacotes de trabalho para maximizar o throughput e minimizar a latência — criam um problema interessante de teoria dos jogos. Como os atores económicos racionais organizam os serviços em cores? Que equilíbrios emergem? Estas questões aguardam validação empírica.

Os Accords como smart contracts multi-instância que governam protocolos de interação entre serviços de outra forma independentes introduzem uma nova primitiva de minimização de confiança. Em vez de confiar em pontes ou relayers para comunicação entre serviços, os Accords impõem protocolos ao nível do consenso JAM, distribuindo a execução pelos limites dos serviços. Esta abstração permite padrões com confiança minimizada, como teletransporte direto de tokens, operações atómicas multi-serviço e chamadas síncronas entre serviços — capacidades teóricas que exigem validação empírica para propriedades de segurança e viabilidade económica.

A otimização do consumo misto de recursos cria um problema interessante de agendamento e economia. Os serviços têm perfis de recursos diversos — alguns são limitados pela computação (verificação de prova ZK), outros são limitados pelos dados (serviços de disponibilidade), outros ainda são equilibrados. A utilização ótima dos recursos do validador exige o emparelhamento de serviços complementares em pacotes de trabalho. Que mecanismos surgem para coordenar este emparelhamento? Como se desenvolvem os mercados para o agrupamento de serviços complementares? Isso representa um território inexplorado na pesquisa de economia blockchain.

O pipelining através de raízes de estado anteriores, em vez de raízes de estado posteriores, permite o processamento de blocos sobrepostos, mas introduz complexidade no tratamento de disputas. Se a carga de trabalho pesada de Accumulate para o bloco N ocorrer depois que o bloco N+1 começar a ser processado, como os validadores lidam com as discrepâncias? O mecanismo de julgamento que permite pausas de finalidade de até 1 hora para resolução de disputas fornece respostas, mas as implicações de segurança desta escolha de design justificam uma análise formal.

Os esforços de verificação formal estão em andamento com a Runtime Verification a desenvolver semânticas K Framework para a PVM. O K Framework fornece rigor matemático para definir a semântica de linguagens de programação e máquinas virtuais, permitindo provas formais de propriedades de correção. Os resultados incluem especificações de referência, depuradores e ferramentas de teste de propriedades. Este nível de rigor matemático, embora comum em software aeroespacial e militar, permanece relativamente raro no desenvolvimento de blockchain — representando uma maturação do campo em direção a métodos formais.

Síntese: o lugar da JAM na evolução da blockchain e implicações para a web3​

A JAM representa o culminar de mais de uma década de pesquisa em escalabilidade blockchain, tentando construir o que as gerações anteriores prometeram, mas não conseguiram entregar. O Bitcoin introduziu o consenso descentralizado, mas não conseguiu escalar além de 7 TPS. A Ethereum adicionou programabilidade, mas atingiu limites de throughput semelhantes. A visão original da Ethereum 2.0 propôs sharding nativo com 64 shard chains, mas provou ser muito complexa, virando para o pragmatismo centrado em L2. A Polkadot foi pioneira na segurança partilhada para parachains, mas com limites fixos de 50 cadeias e acesso baseado em leilão.

A JAM sintetiza as lições dessas tentativas: manter a descentralização e a segurança (lição do Bitcoin), permitir computação arbitrária (lição da Ethereum), escalar através da paralelização (tentativa da Ethereum 2.0), fornecer segurança partilhada (inovação da Polkadot), adicionar componibilidade síncrona (a peça que faltava) e reduzir as barreiras de entrada (acessibilidade).

O trade-off entre elegância teórica e complexidade prática continua a ser o risco central da JAM. O design do protocolo é intelectualmente coerente — dualismo Refine-Accumulate, continuações PVM, consenso SAFROLE, execução parcialmente coerente, tudo se encaixa logicamente. Mas a solidez teórica não garante o sucesso prático. A mudança da Ethereum de sharding nativo para L2s não se deveu à impossibilidade teórica, mas à complexidade prática na implementação, teste e coordenação.

A estratégia de atualização única e abrangente da JAM amplifica tanto o lado positivo quanto o negativo. O sucesso entrega todas as melhorias simultaneamente — 42x de disponibilidade de dados, serviços sem permissão, componibilidade síncrona, desempenho RISC-V — numa implantação coordenada. Falhas ou atrasos afetam toda a atualização, em vez de entregar melhorias incrementais. As 43 equipas de implementação independentes, as extensas fases de testnet e os testes em larga escala do JAM Toaster visam mitigar riscos, mas coordenar 1.023 validadores através de uma grande transição arquitetónica permanece sem precedentes na história da blockchain.

A transição do modelo económico de leilões de parachain para mercados de coretime representa um mecanismo em grande parte não testado em escala. Embora o Agile Coretime da Polkadot tenha sido lançado em 2024, o modelo baseado em serviços da JAM com implantação sem permissão cria dinâmicas económicas inteiramente novas. Como os mercados de coretime precificarão diferentes tipos de serviço? A liquidez concentrar-se-á em cores específicas? Como os sequenciadores otimizam a composição de pacotes de trabalho? Estas questões carecem de respostas empíricas até a implantação da mainnet.

A adoção por desenvolvedores depende de se o novo modelo de programação da JAM — pontos de entrada Refine/Accumulate/onTransfer, execução sem estado e depois com estado, assincronia baseada em continuação — fornece valor suficiente para justificar a curva de aprendizagem. O sucesso da Ethereum deveu-se em parte à familiaridade da EVM para os desenvolvedores, apesar das ineficiências. A PVM da JAM oferece desempenho superior, mas exige repensar a arquitetura da aplicação em torno de pacotes de trabalho e serviços. A implantação sem permissão e a eliminação de leilões reduzem drasticamente as barreiras financeiras, mas as mudanças de modelo mental podem ser mais desafiadoras do que as financeiras.

As dinâmicas competitivas evoluem à medida que a JAM é implantada. Os L2s da Ethereum têm efeitos de rede significativos, liquidez e atenção dos desenvolvedores. A Solana oferece desempenho excecional com modelos de programação mais simples. A Cosmos fornece soberania que alguns projetos valorizam muito. A JAM deve não apenas entregar capacidades técnicas, mas também atrair os participantes do ecossistema — desenvolvedores, utilizadores, capital — que tornam as redes blockchain valiosas. O ecossistema existente da Polkadot fornece uma base, mas expandir-se para além dos participantes atuais exige propostas de valor convincentes para a migração.

As contribuições de pesquisa que a JAM introduz fornecem valor, independentemente do sucesso comercial. A arquitetura blockchain sem transações, o consenso parcialmente coerente, os Accords para protocolos entre serviços com confiança minimizada, a otimização do consumo misto de recursos e o modelo de execução baseado em continuação da PVM representam abordagens inovadoras que avançam a ciência da computação blockchain. Mesmo que a própria JAM não alcance uma posição dominante no mercado, essas inovações informam futuros designs de protocolo e expandem o espaço de solução para a escalabilidade blockchain.

As implicações a longo prazo para a web3, se a JAM for bem-sucedida, incluem mudanças fundamentais na forma como as aplicações descentralizadas são arquitetadas. O paradigma atual de "implantar numa blockchain" (Ethereum L1, Solana, Avalanche) ou "construir a sua própria blockchain" (Cosmos, parachains Polkadot) adiciona uma opção intermédia: "implantar como um serviço" com segurança partilhada instantânea, alocação flexível de recursos e componibilidade com o ecossistema mais amplo. Isso poderia acelerar a inovação, removendo preocupações com a infraestrutura — as equipas concentram-se na lógica da aplicação, enquanto a JAM lida com consenso, segurança e escalabilidade.

A visão de um computador global descentralizado torna-se arquitetonicamente viável se a JAM cumprir as metas de desempenho. Com 850 MB/s de disponibilidade de dados, 150 mil milhões de gás por segundo e 3,4+ milhões de TPS de capacidade, o throughput computacional aproxima-se de níveis onde aplicações tradicionais significativas poderiam migrar para infraestrutura descentralizada. Não para todos os casos de uso — aplicações sensíveis à latência ainda enfrentam limitações fundamentais de velocidade da luz, requisitos de privacidade podem entrar em conflito com execução transparente — mas para problemas de coordenação, infraestrutura financeira, rastreamento da cadeia de suprimentos, identidade digital e inúmeras outras aplicações, a computação descentralizada torna-se tecnicamente viável em escala.

As métricas de sucesso da JAM nos próximos 2-5 anos incluirão: número de serviços implantados além das parachains legadas (medindo a expansão do ecossistema), throughput real e disponibilidade de dados alcançados em produção (validando as reivindicações de desempenho), sustentabilidade económica dos mercados de coretime (provando que o modelo económico funciona), métricas de adoção por desenvolvedores (atividade no GitHub, tráfego de documentação, envolvimento em programas educacionais) e histórico de segurança (ausência de grandes exploits ou falhas de consenso).

A questão final permanece se a JAM representa uma melhoria incremental no espaço de design da blockchain — melhor do que as alternativas, mas não fundamentalmente diferente em capacidade — ou um salto geracional que permite categorias inteiramente novas de aplicações impossíveis na infraestrutura atual. Os fundamentos arquitetónicos — execução parcialmente coerente, continuações PVM, dualismo Refine-Accumulate, Accords — sugerem que o último é possível. Se o potencial se traduzirá em realidade depende da qualidade da execução, da construção do ecossistema e de fatores de timing de mercado que transcendem o mérito puramente técnico.

Para os pesquisadores da web3, a JAM fornece uma plataforma experimental rica para estudar novos mecanismos de consenso, arquiteturas de execução, mecanismos de coordenação económica e modelos de segurança. Os próximos anos gerarão dados empíricos que testarão previsões teóricas sobre consenso parcialmente coerente, arquitetura sem transações e organização blockchain baseada em serviços. Independentemente dos resultados comerciais, o conhecimento adquirido informará o design de protocolos blockchain nas próximas décadas.