JAM será entregue em 12-20 meses? Três desenvolvedores principais revelam os segredos do modelo econômico M1, PoP e o futuro do ZK!

JAM, esse nome já vem sendo discutido pela comunidade Polkadot há muito tempo. Com Gavin Wood trazendo uma série de informações impactantes no Web3 Summit, as expectativas e dúvidas sobre JAM atingiram um novo patamar — afinal, o que é JAM? Que mudanças ele trará para Polkadot? Quanto tempo falta para seu lançamento oficial?

Para proporcionar uma compreensão mais ampla à comunidade, a PolkaWorld convidou três convidados diretamente envolvidos no desenvolvimento central do JAM — Bryan, da equipe Acala, Junha, desenvolvedor do “FastRoll” (implementação Rust do JAM), e Boy Maas, cofundador do projeto Polona e desenvolvedor do “JAMZig” (implementação Zig do JAM).

Os três convidados não só participam profundamente da implementação técnica do JAM, como também exploram seu potencial em diferentes frentes: desde a implementação de clientes multilíngues, migração de toolchains cross-chain, até as futuras aplicações do PVM. Eles são os que melhor representam o estágio atual de progresso do JAM.

Nesta entrevista, eles nos levam, em primeira pessoa, para dentro do universo JAM:

• O que realmente significam as grandes atualizações do JAM anunciadas por Gavin?
• Como o limite de tokens do JAM (π × 1 bilhão) e o mecanismo PoP (Proof of Personhood) vão alterar o modelo econômico do Polkadot?
• Quais são os objetivos técnicos e o progresso do Milestone 1? Quando a testnet será lançada?
• Como o ZK (prova de conhecimento zero) poderá se integrar ao JAM no futuro?
• Como o mecanismo de governança do JAM e o comitê editorial do Gray Paper vão impactar a evolução de longo prazo do protocolo?

Se você quer entender o futuro do JAM e como ele pode remodelar a infraestrutura do ecossistema Polkadot — este episódio é imperdível.

Conheça as três equipes de desenvolvimento do JAM

Kristen: Olá a todos, eu sou a Kristen. Hoje trouxemos três desenvolvedores centrais do JAM, que estão diretamente envolvidos no desenvolvimento do projeto. Se você acompanha a PolkaWorld ou as últimas novidades do Polkadot, já deve saber que está acontecendo o Web3 Summit, e Gavin anunciou algumas notícias bombásticas sobre o JAM. A comunidade já começou a nos enviar perguntas com frequência, então organizamos essa live de última hora para, através dos convidados, ajudar a comunidade a entender melhor o que Gavin anunciou sobre o JAM no Web3 Summit.

Na primeira parte, gostaria que cada convidado se apresentasse brevemente, explicando qual parte do projeto JAM está responsável e o estágio atual do desenvolvimento. Embora alguns convidados já sejam velhos conhecidos do nosso programa, sempre temos novos espectadores, então peço que se apresentem novamente. Vamos começar pelo Junha.

Junha: Obrigado pelo convite, Kristen. Olá a todos, sou o Junha e é minha primeira vez participando deste programa.

Atualmente, estou desenvolvendo a implementação em Rust do protocolo JAM, chamada “FastRoll”. No momento, minha equipe sou apenas eu, então sou um desenvolvedor independente.

Já estou nesse projeto há cerca de um ano, agora estou me preparando para a avaliação do primeiro marco (milestone) e já comecei a avançar em algumas tarefas da segunda fase.

Kristen: Bem-vindo, Junha! Agora, vamos ouvir o Bryan.

Bryan: Olá a todos, sou o Bryan, da equipe Acala. Atualmente, lidero uma pequena equipe desenvolvendo outra implementação do protocolo JAM, chamada “Boka”.

• Também estamos finalizando a primeira fase e atualizando alguns componentes off-chain para preparar a segunda fase.
• Além disso, acabamos de iniciar o desenvolvimento do recompilador PVM, mas ainda está em estágio inicial, longe de ser concluído.

Kristen: Obrigada, Bryan, por voltar ao nosso programa. Bryan foi nosso primeiro convidado para apresentar o projeto JAM, é ótimo tê-lo de volta. Por fim, vamos dar as boas-vindas ao Boy Maas, que já entrevistamos anteriormente.

Boy Maas: Sim, sim, olá a todos, sou o Boy Maas. Sou o desenvolvedor independente da implementação em Zig do protocolo JAM, nosso cliente se chama “JAMZig”.

Também sou cofundador de um projeto no ecossistema JAM, cujo objetivo é migrar completamente o toolchain e a máquina virtual do Solana (SVM) para o JAM. Já concluímos a fase de prova de conceito, ou seja, já conseguimos rodar algumas funções básicas.

JAM será entregue oficialmente em 12 a 20 meses?

Kristen: Bem-vindo, Boy Maas. O Polona realmente é um projeto pioneiro, focado em atrair desenvolvedores Solana para o ecossistema Polkadot, uma ideia excelente! Sejam todos bem-vindos.

Agora, a primeira pergunta vai para o Boy Maas. Você participou do Web3 Summit, já vimos várias notícias sobre a palestra do Gavin no Twitter, mas gostaria que você compartilhasse, em primeira pessoa, o que achou. Você assistiu à palestra do Gavin? Pode compartilhar as informações mais importantes?

Boy Maas: Claro, claro, estar lá presencialmente foi incrível. Você encontra muitos membros da comunidade Polkadot, várias apresentações interessantes que realmente mostram a dinâmica da comunidade, o clima é muito positivo, cheio de energia, e nos deixa animados para o futuro. Hoje é o último dia, e estou ansioso para levar essa experiência de volta e continuar nosso desenvolvimento.

Kristen: Você assistiu à palestra do Gavin, certo?

Boy Maas: Assisti, sim.

Kristen: Tem algo que te marcou e gostaria de compartilhar? Vimos algumas informações no Twitter, mas queremos ouvir de vocês, desenvolvedores, de forma mais simples e didática.

Boy Maas: Claro. O Gavin abordou muitos tópicos em sua palestra. Ele é uma pessoa muito visionária, com muita experiência, então suas decisões e novas ideias têm grande impacto no futuro da comunidade.

O ponto mais importante foi o anúncio de que o fornecimento total de tokens do JAM terá um limite rígido de “π vezes 1 bilhão” (π × 1.000.000.000), o que é algo muito significativo e trará muitos desdobramentos.

Outro destaque é que ele tentou explicar de forma mais clara para a comunidade Polkadot o que é o JAM. O JAM, essencialmente, visa fortalecer e sustentar o ecossistema Polkadot, sendo uma infraestrutura de suporte para todo o ecossistema. Na verdade, todos agora estão em um processo de exploração e adaptação: o que é o JAM? O que ele pode fazer? Como ele coopera com a mainnet do Polkadot? Como será implementado?

Como desenvolvedores, conhecemos os detalhes técnicos do JAM, mas entendo que, para a maioria das pessoas, ainda está na fase de “não entender muito bem que mudanças o JAM trará”. Todos estão tentando imaginar como será esse futuro impulsionado pelo JAM.

Kristen: Parece muito interessante. Notei também que Gavin mencionou que o JAM será entregue oficialmente em 12 a 20 meses. O projeto de vocês, Polona, também depende desse cronograma, certo? O progresso de vocês será sincronizado com o do JAM?

Boy Maas: Sim, Kristen, você está absolutamente certa. Não planejamos estar totalmente prontos já no lançamento da testnet, mas, de acordo com o cronograma divulgado, nosso planejamento está perfeitamente alinhado. Assim que a testnet do JAM for lançada, poderemos começar a usar imediatamente. Quando a rede estiver em operação, acompanharemos desde o início.

O que é o M1 do JAM?

Kristen: Ótimo, fico feliz em ouvir esse progresso. Agora, quero passar a pergunta para o Junha.

O JAM lançou recentemente uma grande atualização técnica e definiu claramente o objetivo de entrega do primeiro marco (milestone 1). Mas alguns ouvintes ainda não entendem muito bem o que é o milestone 1, o que ele faz e em que estágio está. Você pode explicar o que inclui o milestone 1? Como está o progresso da testnet? Quando você espera que ela seja lançada?

Junha: Claro. Como você mencionou, o Gray Paper do JAM foi recentemente atualizado para a versão 0.7.0. O Gavin também disse em sua palestra que, a partir dessa versão, a Polkadot Fellowship pode começar a avaliar o milestone 1. Então, a maioria das equipes que estão implementando clientes de nó do JAM estão se preparando para essa avaliação.

O objetivo do milestone 1 é entregar um cliente de nó capaz de “importar blocos corretamente”, ou seja, validar a lógica de runtime mais básica do JAM.

Especificamente, dado uma série de blocos (incluindo blocos válidos e inválidos), o cliente deve identificar quais blocos têm o formato correto. Para blocos válidos, o cliente precisa ler os dados externos, executar a lógica de transição de estado (o núcleo do runtime da blockchain) e, finalmente, gerar um novo estado on-chain. Afinal, uma blockchain é essencialmente uma máquina de estados: dado um estado inicial, ao importar blocos e executar a lógica correspondente, um novo estado é produzido.

A avaliação do milestone 1 verifica se a implementação do nó consegue, após importar esses blocos, gerar o estado subsequente correto.

O método de avaliação é direto: preparamos um conjunto de blocos de teste e comparamos se os estados subsequentes gerados por diferentes implementações são idênticos. Esse resultado de estado pode ser resumido por uma “vertical root”, o que facilita a comparação. Já existe uma ferramenta de teste chamada JAM Conformance Fuzzer, que gera automaticamente muitos blocos com dados aleatórios para testar se todas as implementações chegam ao mesmo root de estado.

Acho que é uma ótima oportunidade para encontrar bugs críticos e corrigi-los a tempo, preparando o terreno para fases mais complexas.

Kristen: Entendi. E quando você espera que a testnet seja lançada?

Junha: Você se refere à testnet do JAM? Algumas equipes já tentaram interoperar entre implementações compilando seus próprios binários, mas, pessoalmente, acredito que uma testnet realmente funcional só estará madura após o milestone 2.

Isso porque o milestone 1 valida principalmente a lógica de transição de estado do nó, o que não é suficiente para suportar uma testnet completa. O milestone 2 avaliará se cada implementação concluiu o protocolo de comunicação de rede (networking spec). Mas esse protocolo ainda não está estável, nem foi totalmente documentado no Gray Paper. Assim que a especificação de rede estiver estável e as implementações concluírem o desenvolvimento, poderemos testar a interoperabilidade entre os nós.

Nesse momento, será mais apropriado preparar o lançamento da testnet. Claro, algumas equipes podem tentar antes, mas meu plano pessoal é entrar na testnet após o milestone 2.

Kristen: Ok. Você acha que as novidades anunciadas pelo Gavin no summit vão impactar seu progresso de desenvolvimento?

Junha: Acho que a maioria das novidades dele são voltadas para a visão de longo prazo, então, no curto prazo, não afetam muito meu planejamento. Meu foco agora é concluir o milestone 1, o que deve levar mais algumas semanas ou até um mês para entregar um cliente totalmente conforme. Então, por enquanto, minha estratégia de desenvolvimento não muda.

Claro, em um horizonte de um a três anos, essas novas direções podem ter impacto, mas, por agora, vou focar em entregar o milestone 1.

O que acontece se o PoP substituir o NPoS?

Kristen: Entendi, obrigado por compartilhar! Agora vou fazer uma pergunta “hardcore” para o Bryan, sobre o modelo econômico dos tokens. Sabemos que desenvolvedores geralmente não gostam de opinar sobre o efeito do modelo econômico, mas esse é um dos temas que mais interessam à comunidade. Gavin anunciou que o PoP (Proof of Personhood) substituirá o NPoS, as recompensas dos validadores serão fixas e haverá um mecanismo de halving anual para limitar o fornecimento total de DOT. Como desenvolvedor, o que você acha dessas mudanças? Qual o maior impacto? Você apoia pessoalmente? Tem preocupações ou sugestões?

Bryan: Realmente, é uma grande mudança.

Vou recapitular rapidamente: seja proof-of-work (PoW), proof-of-stake (PoS) ou agora o proof-of-personhood (PoP), todos esses mecanismos visam proteger a segurança da rede, evitando ataques como double-spend ou forks.

Cada mecanismo tem seu custo operacional: o PoW exige recompensas em bloco e muito consumo de energia e poder computacional, enquanto o PoS exige recompensas para os stakers.

O novo proof-of-personhood traz uma grande diferença no mecanismo de recompensas. O Polkadot usava o NPoS (nominated proof-of-stake), que, embora menos caro que o PoW, ainda tinha um problema: para manter a segurança da rede, era preciso emitir novos tokens continuamente para recompensar validadores e nominadores, gerando inflação.

Agora, o objetivo do POP é reduzir o custo operacional da segurança da rede, não dependendo mais de incentivos ou punições econômicas, mas sim de um novo método — ainda não está claro como será, mas a ideia central é “uma pessoa, um voto”. Se isso funcionar, trapacear será muito mais difícil, a rede ficará mais segura e não será preciso pagar tantas recompensas em tokens.

Do ponto de vista da rede, isso reduz muito o custo operacional, o que é positivo. Mas há efeitos colaterais: antes, muitos dependiam do staking para ganhar mais tokens, agora esse modelo de renda praticamente desaparece. Ainda haverá formas de ganhar tokens, mas em quantidade bem menor. Por outro lado, para quem detém tokens, se o gasto da rede diminui, o valor dos tokens tende a aumentar, então, no geral, vejo como algo positivo.

Além disso, pode haver um efeito benéfico para o DeFi. Com a redução dos rendimentos do staking, os usuários podem migrar fundos para outros protocolos DeFi, como empréstimos, provisão de liquidez, etc., ativando o ecossistema DeFi.

Claro, o impacto real depende dos detalhes completos, e mesmo com o design final, é difícil prever todos os efeitos. Mas, pessoalmente, vejo essas mudanças de forma positiva.

Kristen: Acho que, a curto prazo, pode ser um golpe para os validadores, já que a renda deles pode cair bastante. Você acha que isso pode causar problemas no início?

Bryan: Depende de como for feita a transição. Não será uma mudança abrupta de um dia para o outro, será gradual, como o halving anual do fornecimento de tokens. Não vamos cortar a inflação a zero no primeiro dia, mas sim reduzir ano a ano, ajustando conforme necessário, dando tempo para todos se adaptarem.

Precisamos garantir a segurança da rede, que os validadores cubram seus custos e tenham algum lucro, e que haja incentivo para indicar e escolher bons validadores. Esses princípios não mudam, só não queremos pagar recompensas tão altas. Mudanças vão ocorrer, mas esperamos que o novo modelo minimize os impactos.

O que é zkJAM?

Kristen: De fato, a comunidade está dividida. No início, todos pediam “menos inflação”, agora que vamos para a deflação, já há reclamações. Acho que a direção é boa, obrigado por compartilhar sua visão aprofundada.

Agora vamos falar de tecnologia — ZKJAM. Vi esse termo no PPT do Gavin, ainda parece conceitual. Mas “zero-knowledge proof” (ZK) está super em alta no Web3, muitos dizem que ZK é a solução final para Rollups e escalabilidade. Se no futuro ZK e JAM se integrarem, como seria esse cenário? Gostaria de ouvir a opinião de vocês três. Junha, pode começar.

Junha: Ok. O Gavin comparou o JAM, em sua palestra, a um “supercomputador bare metal descentralizado”, e os diversos serviços sobre ele seriam como sistemas operacionais rodando no hardware, tipo Windows ou macOS.

Se no futuro o ZK for integrado ao JAM, do ponto de vista dos desenvolvedores de serviços ou aplicações, não haverá uma mudança “disruptiva” na experiência de desenvolvimento ou do usuário.

Mesmo que o mecanismo de segurança do JAM mude do atual “modelo de reexecução baseada em auditoria” para um “modelo baseado em provas ZK”, desde que essa atualização seja bem validada e traga benefícios, vale a pena adotar.

Portanto, se ficar claro que ZK e JAM se encaixam bem e são superiores ao modelo atual, a atualização é viável e a experiência geral não mudará muito.

Kristen: Obrigada pela explicação. Acho que alguns ouvintes podem ter se perdido nos termos técnicos, mas não se preocupem, teremos uma versão em português do artigo para vocês lerem com calma. Agora, Bryan, sua vez de comentar.

Bryan: Acho que é importante distinguir dois conceitos: um é o JAM como infraestrutura para Rollups seguros por ZK, outro é o próprio JAM usando ZK para garantir sua segurança. São coisas bem diferentes.

Com o PVM do JAM, qualquer algoritmo ou arquitetura relacionada a ZK, como novos protocolos ZK-Rollup, pode ser implantado como um serviço no JAM. Isso é relativamente fácil de implementar.

Mas se quisermos que o próprio JAM use ZK para garantir sua segurança, aí entra muita pesquisa de ponta e otimização de algoritmos. Atualmente, isso ainda está em estágio muito inicial. Depende do estado da arte — talvez os algoritmos atuais não sejam rápidos ou baratos o suficiente, mas no futuro, alguém pode inventar um algoritmo 100 vezes mais eficiente e tudo muda.

Portanto, se no futuro surgir uma integração ZK realmente útil que torne o JAM mais seguro, eu apoio totalmente.

Kristen: Entendi, espero que esse campo avance mesmo. Boy Maas, como desenvolvedor experiente, o que acha?

Boy Maas: Acho que Bryan e Junha já explicaram muito bem. Gosto do JAM porque é um sistema muito pragmático. Suas escolhas de design são para que o sistema realmente funcione e execute cálculos. Como o Bryan disse, hoje usar ZK para tudo isso é caro e irreal. Então, imagino que no futuro poderemos ter um “modelo híbrido”, com auditoria tradicional e ZK rodando em paralelo.

Por enquanto, ZK é caro e pouco prático, mas nos próximos 12 meses a 5 anos, muita coisa deve mudar nesse campo. Se o ZK realmente se tornar eficiente, será uma tecnologia muito atraente e pode redefinir todo o nosso modelo de segurança e arquitetura do sistema.

Mas, por ora, o modelo híbrido parece mais realista: mantém a praticidade e permite que aplicações que realmente precisem de segurança ZK possam usar a tecnologia.

JAM terá um comitê editorial do Gray Paper

Kristen: Obrigada a todos pelas opiniões. Agora vamos ao próximo tema: o mecanismo de governança do JAM.

Gavin continuará como editor-chefe do Gray Paper e anunciou a criação de um “comitê editorial do Gray Paper”, formado por contribuidores tecnicamente capacitados e profundamente envolvidos no desenvolvimento do JAM. Esse comitê decidirá, no futuro, as atualizações, prioridades e decisões-chave do protocolo JAM. Como desenvolvedores, vocês acham viável esse modelo de governança por comitê? Existe risco de “desvio de propósito”? Se acontecer, como lidar? Vamos começar pelo Boy Maas.

Boy Maas: Acho essa questão muito relevante. Para um campo tão técnico e especializado, ter um comitê responsável pelas atualizações do Gray Paper é muito razoável e necessário. As decisões precisam ser tomadas por quem entende profundamente os princípios do JAM e tem experiência prática. Ter o fundador Gavin liderando o comitê faz todo sentido, então apoio totalmente esse modelo de governança.

Kristen: Então você acha bom que o protocolo seja decidido por uma equipe profissional?

Boy Maas: Sim, concordo totalmente.

Kristen: Ok, Bryan, qual sua opinião?

Bryan: Na verdade, todo projeto é governado por algum tipo de “comitê”, só muda o tamanho e os membros. A diferença é se o processo de governança está claramente definido ou não.

Acho que documentar o processo de governança já é um avanço, pois todos sabem como as atualizações são decididas, o que aumenta a transparência e facilita futuras melhorias. Se não houver regras, não há como melhorar.

O conteúdo do Gray Paper é muito complexo, quase todos os desenvolvedores das equipes JAM já leram várias versões. Mas, sinceramente, talvez só o Gavin entenda 100% — talvez nem ele saiba todos os detalhes. Muitas pessoas participam das revisões, corrigindo erros, ajustando fórmulas, otimizando a lógica, e isso já é um processo colaborativo.

Portanto, só quem tem anos de experiência nesse campo deve participar das revisões do Gray Paper. Uma pequena mudança pode causar grandes efeitos em cadeia. Afinal, isso afeta o futuro do Web3, até da internet, e envolve muita segurança de ativos, então é preciso muito cuidado. Transparência e abertura são essenciais. Todos podem sugerir, mas precisam provar que realmente entenderam o que estão propondo, senão o ruído pode sufocar as boas ideias.

Kristen: Então você acha que o comitê precisa de regras, como quem pode entrar, como organizar os membros, etc. Porque cada um tem sua opinião, e sem regras, é fácil haver divergências ou desvio de propósito.

Bryan: Por isso precisamos de contratos inteligentes, processos claros, tudo documentado. Se as regras estiverem escritas, todos podem fiscalizar, tudo é transparente, e o risco de desvio é menor. Se tudo for feito às escondidas, ninguém sabe o que está acontecendo, aí sim pode sair do rumo. Transparência é fundamental, especialmente se o processo puder ser executado por contratos inteligentes, garantindo a sustentabilidade do mecanismo.

Kristen: Entendi, lembro que a comunidade Bitcoin também tem um comitê de desenvolvedores para impulsionar o desenvolvimento.

Bryan: Sim, a comunidade Bitcoin tem um grupo de desenvolvedores centrais, mas a decisão final é feita por fork: a cadeia com mais poder computacional vence.

Kristen: Entendi, obrigado pela explicação. Agora, vamos ouvir a opinião do Junha.

Junha: Acho que criar um comitê editorial é um passo natural e significativo. O projeto JAM é muito especial: antes mesmo de desenvolver um software funcional, já foi publicado um documento técnico completo (Gray Paper), cheio de fórmulas matemáticas para definir o comportamento do sistema. Documentar antes de desenvolver é uma busca por mais descentralização e resiliência do sistema.

Por isso, o Gray Paper já foi revisado várias vezes desde o lançamento, e continuará sendo revisado mesmo após a versão 1.0.

Com mais equipes implementando o protocolo JAM e montando testnets, certamente encontraremos pontos a otimizar, melhorando a eficiência ou viabilidade do protocolo. Portanto, é natural que o Gray Paper continue evoluindo nos meses seguintes ao lançamento da mainnet, podendo até haver hard forks.

Nesse contexto, ter um grupo responsável pelo desenvolvimento do protocolo é claramente melhor do que depender de uma única pessoa.

Como o Bryan disse, transparência é fundamental, o processo decisório do comitê deve ser público. Espero que mais equipes que usam o protocolo JAM participem ativamente da revisão, correção e feedback do documento, e não apenas “acreditem que o Gavin está certo”. Essa participação ativa é ótima para encontrar pontos de melhoria. É um ótimo começo, e faz todo sentido para o JAM.

Talvez estejamos subestimando o que o JAM pode trazer para o blockchain

Kristen: Certo, realmente é um ótimo começo. Se todo o processo for transparente, será excelente. Obrigada pelas opiniões, acho que cobrimos todos os tópicos de hoje.

Antes de encerrar, alguém gostaria de acrescentar algo? Sobre o JAM, sobre o Web3 Summit, algo que não deu tempo de comentar? Vamos começar pelo Bryan.

Bryan: Não tenho nada especial a acrescentar. O JAM é uma infraestrutura de base, é importante, mas não é tudo. O que realmente importa são os serviços e aplicações construídos sobre o JAM — os usuários não usam o JAM diretamente, mas sim os serviços baseados nele.

Portanto, o lançamento do JAM é só o primeiro passo para o objetivo final. Devemos focar nos serviços e aplicações rodando sobre o JAM, pois são eles que realmente impactam os usuários. Ainda há muito a fazer, e nossa atenção não pode se limitar apenas ao protocolo central do JAM, mas também ao que é construído sobre ele.

Kristen: Obrigada. Boy Maas, algo a acrescentar sobre Polona ou JAM?

Boy Maas: Claro. Primeiro, sobre o JAM. Lembro que em Lisboa, o Gavin fez uma apresentação sobre o JAM. Na época, senti fortemente que talvez estejamos subestimando o que essa plataforma pode trazer para a comunidade blockchain.

A “largura de banda” e flexibilidade que o JAM oferece nunca foram alcançadas por nenhuma blockchain antes. Acho que já é um marco importante na história do blockchain, especialmente pelas novas aplicações que pode suportar, algo realmente único.

Mais uma novidade: nosso projeto Polona está avançando rápido, já rodamos uma prova de conceito (PoC) no JAM. Migramos o SVM do Solana para o PVM, ou seja, agora você pode rodar bytecode do Solana diretamente no JAM, incluindo chamadas entre contratos, tudo funcionando — isso é muito legal. Isso mostra o poder dos serviços do JAM.

Kristen: Ótimo, obrigada! Por fim, Junha, suas considerações finais.

Junha: Espero que mais pessoas comecem a prestar atenção no JAM, Polkadot e no Gray Paper. Gostaria muito de me conectar e compartilhar ideias com mais pessoas.

Os clientes do JAM ainda estão em desenvolvimento, então não há muitos exemplos de aplicações “prontas”. O time do Gavin mostrou alguns demos, mas ainda não há muitos casos reais para convencer as pessoas do que o sistema pode fazer.

Mas acredito que, se você se interessa pelos princípios do Web3 e quer realmente expandir os limites do setor, o JAM é um projeto que vale muito a pena estudar a fundo. Tenho trabalhado sozinho nesse projeto, então adoraria conhecer mais pessoas com interesses semelhantes, mesmo que seja só para ler o Gray Paper juntos ou discutir ideias. Espero que possamos trocar ideias e até criar coisas novas juntos, especialmente depois que entregarmos o nó.

Kristen: Obrigada pelo compartilhamento, e muito obrigada aos convidados pelas ótimas opiniões e insights! Obrigada a todos os ouvintes pela participação. Sigam nossos convidados no Twitter, os perfis estão nos anúncios da PolkaWorld. Seja você usuário comum ou desenvolvedor, acompanhar as novidades do JAM é muito valioso. Obrigada pela audiência, até a próxima! Tchau!