JAM is the accelerated development after 2.0, with over 30 teams using different programming languages and development teams to implement a decentralized JAM client (based on the JAM white paper protocol). In the early days of ETH, all transactions required all validators to verify them together (this part can actually refer to the Ethereum yellow paper, and there is a better interpretation version). L2 allows a smaller subset off-chain to perform computations in two ways: one L2 is fraud proof (re-executing transaction code upon discovering fraud to verify), and the other L2 is zk proof, which does not require re-computation but needs expensive GPUs to generate proofs; on-chain, only the proofs are verified without re-executing the previous transaction transformation function code. Earlier, @Polkadot 1.0 used an algorithm called ELVES, which is different from ETH's fraud algorithm that passively verifies; instead, it uses a probabilistic algorithm for active verification. In @polkadot 2.0, the verification set has been packaged into a concept called Core, which is essentially a subset of the verification set. 2.0 supports Agile Coretime, meaning dynamically using core; in 1.0, a chain could only use one Core, but after 2.0 goes live, it will support Agile Coretime, allowing a chain to dynamically use coretime (the number of verification subsets) based on demand, thereby enhancing the system's service load. JAM evolves based on these ideas, with the emergence of many zk, op, smart contracts, and even ordinary web2 stateless applications. Can it further abstract services to better adapt to these different application models and allow them to interact and combine? Thus, JAM has further abstracted on this basis. - Various different L2/parallel chain elements are now referred to as services. - Blocks/transactions are now referred to as work items or work packages. - Work items belong to services, while work packages are a set of work items. - Services are described by three entry points, two of which are fn refine() and fn accumulated. - The names of these two entry points are precisely why the protocol is called JAM: Join Accumulate Machine. Join refers to fn refine(), where all Polkadot cores execute a large amount of work in parallel for different services. Join means refining data into a smaller subset and then passing it to the next stage. - Accumulate refers to accumulating the results of all the above operations into the main JAM state. - Different forms of services are supported (op rollups, zkrollups, parallel chains, stateless applications, smart contracts). The ETH era was a shared state single-column state machine, @polkadot 1.0 era was an interoperable probabilistic sharding machine. @polkadot 2.0 era is the Agile Coretime machine. The JAM era is the Join Accumulate Machine (JAM). There are many detailed features; here I only synchronized the information I understood. A deeper understanding of why JAM can run continuously without invoking programs through transactions raises questions about what new model products will emerge in the future when combined with DEFI. Why can JAM run non-state applications, such as JAM DOOM? For specifics, see the video: Learning materials: