JAM is after 2.0, it is accelerating research and development, with more than 30 teams, different programming languages, and different development teams to implement a decentralized JAM client (based on the JAM gray paper protocol). The earliest ETH was all transactions, which required all validators to verify together (this part can actually be read in the Ethereum Yellow Book, and there is a better interpretation version). L2 is to let a smaller subset of the chain perform calculations, in two ways, one L2 is a fraud proof (repeatedly execute the transaction code after finding fraud to verify), and the other L2 is a zk proof, which does not require double calculation, but needs to use zk's more expensive GPU to generate proofs. Earlier @Polkadot 1.0 used an algorithm called ELVES, which is not like ETH's fraud algorithm, which uses passive verification, but uses a probabilistic type of algorithm for active verification. @polkadot 2.0 verification set, it has been packaged into a concept called Core, core is essentially a subset of the verification set, 2.0 supports Agile Coretime, that is, the dynamic use of core, 1.0 can only use one core per chain, 2.0 is about to go live and support Agile Coretime, that is, a chain can dynamically use coretime (number of verification subsets) according to needs, thereby increasing the service load of the system. JAM is based on the above ideas, and with so many zk, OP, smart contracts, and even ordinary web2 stateless applications, can it be a step closer to abstracting services to adapt to these different application models, and allow them to interact with each other. So JAM took a step closer to abstraction on this basis. - A variety of different L2/parachain things are now called services - Block/transaction stuff is now called a work item or work package - A work item is a service, while a work package is 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 exactly why the protocol is called JAM: Join Accumulate Machine. Joining refers to fn refine(), where all Polkadot cores perform a lot of work in parallel for different services. Concatenation refers to the distillation of data into a smaller subset and then passing it on to the next stage. - Accumulation refers to accumulating the results of all of the above operations to the main JAM state - Different forms of services are supported (OP rollups, zkrollups, parachains, stateless applications, smart contracts) The ETH era is a single-column state machine with shared state, @polkadot 1.0 era is interoperable probabilistic shards. @polkadot 2.0 era is the Agile Coretime machine. The JAM era is the Join Accumulate Machine (JAM) There are many detailed features, here is only what I understand information synchronization, more in-depth understanding why, JAM can achieve continuous running programs, without the need to call up programs through transactions, what new model products will be produced when this kind of feature is combined with DEFI in the future? Why JAM can run stateless applications such as JAM DOOM. See the video for details: Study materials: