JAM é a versão 2.0, que está em desenvolvimento acelerado, com mais de 30 equipes diferentes, utilizando várias linguagens de programação e diferentes equipes de desenvolvimento para implementar um cliente JAM descentralizado (baseado no protocolo do livro cinza do JAM). O ETH original exigia que todas as transações fossem verificadas por todos os validadores (essa parte pode ser vista no livro amarelo do Ethereum, e há uma versão de interpretação melhor). O L2 permite que um subconjunto menor fora da cadeia realize cálculos, através de duas abordagens: uma é a prova de fraude (que repete a execução do código da transação para verificar após descobrir uma fraude), e a outra é a prova zk, que não requer cálculos repetidos, mas precisa de GPUs caras para gerar a prova, onde a cadeia apenas valida a prova, sem precisar repetir a execução do código da função de transformação da transação anterior. O @Polkadot 1.0 utilizava um algoritmo chamado ELVES, que não é como o algoritmo de fraude do ETH, que valida passivamente, mas sim um algoritmo de tipo probabilístico que valida ativamente. No @polkadot 2.0, o conjunto de validação foi encapsulado em um conceito chamado Core, que é essencialmente um subconjunto do conjunto de validação. O 2.0 suporta Agile Coretime, ou seja, o uso dinâmico do core, onde na versão 1.0 uma cadeia só podia usar um Core, e na versão 2.0, que está prestes a ser lançada, suportará Agile Coretime, permitindo que uma cadeia utilize dinamicamente o coretime (número de subconjuntos de validação) conforme necessário, aumentando assim a carga de serviço do sistema. Assim, o JAM evolui a partir dessas ideias, surgindo com tantos zk, op, contratos inteligentes, e até mesmo aplicações sem estado do tipo web2, questionando se é possível abstrair melhor os serviços para se adaptar a esses diferentes modelos de aplicação, e permitir que eles interajam de forma combinável. Portanto, o JAM fez uma abstração adicional com base nisso. - Várias coisas diferentes de L2/cadeias paralelas agora são chamadas de serviços - Coisas de blocos/transações agora são chamadas de itens de trabalho ou pacotes de trabalho - Itens de trabalho pertencem a serviços, enquanto pacotes de trabalho são um conjunto de itens de trabalho - Os serviços são descritos por três pontos de entrada, dos quais dois são fn refine() e fn accumulated - Os nomes desses dois pontos de entrada são exatamente a razão pela qual o protocolo é chamado de JAM: Máquina de Acumulação de Conexão (Join Accumulate Machine). Conexão (Join) refere-se a fn refine(), onde todos os núcleos do Polkadot executam em paralelo uma grande quantidade de trabalho para diferentes serviços. Conexão refere-se à extração de dados em um subconjunto menor, que é então passado para a próxima fase. - Acumulação refere-se à acumulação dos resultados de todas as operações acima no estado principal do JAM - Diferentes formas de serviços são suportadas (op rollups, zkrollups, cadeias paralelas, aplicações sem estado, contratos inteligentes) A era ETH é uma máquina de estado de coluna única de estado compartilhado, A era @polkadot 1.0 é uma máquina de fragmentação probabilística interoperável. A era @polkadot 2.0 é uma máquina Agile Coretime. A era JAM é a Máquina de Acumulação de Conexão (JAM). Há muitos outros detalhes e características, aqui apenas fiz uma sincronia das informações que entendi. Uma compreensão mais profunda do porquê, o JAM pode executar programas continuamente, sem precisar invocar o programa através de transações, que tipo de novos produtos de modelo podem surgir no futuro com a combinação do JAM e DEFI? Por que o JAM pode executar aplicações não baseadas em estado, como o JAM DOOM. Para mais detalhes, veja o vídeo: Materiais de estudo: