JAM has been accelerating its development since 2.0, with over 30 teams using different programming languages and development teams to implement a decentralized JAM client (based on the JAM grey book protocol). The earliest ETH required all validators to verify all transactions together (this part can actually be found in the Ethereum Yellow Book for a better interpretation version) https://www. (infoq.cn)/article/how-does-ethereum-work-anyway）， Only then can the status be changed to the shared state that has been finally confirmed on the chain. L2 involves computing a smaller subset off chain through two methods: one is fraud proof (which involves repeatedly executing transaction code to verify fraud), and the other is zk proof, which does not require repeated computation but requires the use of zk's more expensive GPU to generate the proof. On chain verification is only used to verify the proof, without the need to repeatedly execute the previous transaction conversion function code. The earlier version of @ Polkadot 1.0 used an ELVES algorithm, which is not like ETH's fraud algorithm, which passively verifies, but actively verifies using probability based algorithms. @Polkadot 2.0's validation set has been packaged into a concept called Core, which is essentially a subset of the validation set. 2.0 supports Agile Coretime, which dynamically uses the core. 1.0 can only use one Core per chain, and 2.0 will soon support Agile Coretime, which allows a chain to dynamically use coretime (the number of validation subsets) according to demand, thereby increasing the system's service load. JAM has evolved based on the above ideas, giving rise to so many zk, op, smart contracts, and even ordinary web2 stateless applications. Can we further abstract services to adapt to these different application models and enable them to combine and interact with each other. So JAM further abstracted on this basis. -Various 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 -The service is 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 perform a large amount of work in parallel for different services. Connection refers to extracting data into a smaller subset and then passing it on to the next stage. -Accumulation refers to accumulating the results of all the above operations to the main JAM state -Different forms of services are supported (op rollups, zkrollups, parallel chains, stateless applications, smart contracts) The ETH era is a single column state machine with shared states, @Polkadot 1.0 era was an interoperable probabilistic sharding machine. @Polkadot 2.0 era is an Agile Coretime machine. In the era of JAM, it was the Join Accumulate Machine (JAM) There are still many detailed features, but here I only understand why JAM can achieve continuous program operation without the need to trigger the program through transactions. What new model products will be produced by combining these features with DEFI in the future? Why can JAM run non-state applications, such as JAM DOOM? See the video for details: https://(x.com)/pala_labs/status/1895485102077120938 Learning materials: https://(github.com)/openguild-labs/learn-jam https://wiki.polkadot.network/learn/learn-jam-chain/