JAM est en phase de développement accéléré après la version 2.0, avec plus de 30 équipes différentes, utilisant divers langages de programmation, pour réaliser un client JAM décentralisé (basé sur le protocole du livre gris de JAM). Le tout premier ETH nécessitait que toutes les transactions soient vérifiées par tous les validateurs (vous pouvez consulter le livre jaune d'Ethereum pour plus de détails, ainsi qu'une version d'interprétation améliorée). L2 permet à un sous-ensemble plus petit hors chaîne de faire des calculs, par deux méthodes : l'une est la preuve de fraude (qui consiste à réexécuter le code de transaction en cas de fraude détectée pour vérification), l'autre est la preuve zk, qui ne nécessite pas de recalcul, mais nécessite des GPU coûteux pour générer la preuve, la chaîne ne vérifiant que la preuve sans avoir à réexécuter le code de transformation de la transaction précédente. Auparavant, @Polkadot 1.0 utilisait un algorithme appelé ELVES, qui, contrairement à l'algorithme de fraude d'ETH, vérifiait de manière passive, mais adoptait un algorithme de type probabiliste pour une vérification active. Lors de @polkadot 2.0, le groupe de validation a été encapsulé dans un concept appelé Core, qui est essentiellement un sous-ensemble du groupe de validation. La version 2.0 prend en charge Agile Coretime, ce qui signifie que le core peut être utilisé dynamiquement ; dans la version 1.0, une chaîne ne pouvait utiliser qu'un seul Core, mais avec la version 2.0, une chaîne pourra utiliser dynamiquement le coretime (nombre de sous-ensembles de validation) en fonction des besoins, améliorant ainsi la charge de service du système. Ainsi, JAM évolue sur la base de ces idées, avec l'émergence de nombreux zk, op, contrats intelligents, et même d'applications sans état de type web2. Peut-on aller plus loin dans l'abstraction des services pour bien s'adapter à ces différents modèles d'application et permettre leur interaction combinée ? C'est pourquoi JAM a fait une abstraction supplémentaire sur cette base. - Différents éléments L2/chaînes parallèles sont maintenant appelés services. - Les blocs/transactions sont maintenant appelés éléments de travail ou paquets de travail. - Les éléments de travail appartiennent aux services, tandis qu'un paquet de travail est un ensemble d'éléments de travail. - Les services sont décrits par trois points d'entrée, dont deux sont fn refine() et fn accumulated. - Ces deux points d'entrée sont précisément la raison pour laquelle ce protocole est appelé JAM : Join Accumulate Machine. Join fait référence à fn refine(), où tous les cœurs de Polkadot exécutent en parallèle un grand nombre de travaux pour différents services. Join signifie extraire des données en un sous-ensemble plus petit, puis les transmettre à l'étape suivante. - Accumulate signifie accumuler les résultats de toutes les opérations ci-dessus dans l'état principal de JAM. - Différentes formes de services sont prises en charge (op rollups, zkrollups, chaînes parallèles, applications sans état, contrats intelligents). L'ère ETH est une machine d'état à état partagé. L'ère @polkadot 1.0 est une machine de fragmentation probabiliste interopérable. L'ère @polkadot 2.0 est une machine Agile Coretime. L'ère JAM est Join Accumulate Machine (JAM). Il y a encore beaucoup de caractéristiques détaillées, ici je n'ai fait qu'une synchronisation des informations que j'ai comprises. Une compréhension plus approfondie de pourquoi JAM peut exécuter des programmes en continu sans avoir besoin de déclencher le programme par des transactions, quel nouveau modèle de produit pourrait émerger à l'avenir en combinant ces caractéristiques avec DEFI ? Pourquoi JAM peut-il exécuter des applications non-état, comme JAM DOOM ? Pour plus de détails, voir la vidéo : Matériel d'apprentissage :