Déplacez-vous, Sui. Déplacez-vous, Aptos. » C’est ainsi que commençait le tweet de lancement. Personne n’a demandé ce que cela signifiait réellement au niveau de l’implémentation. Sui utilise Move centré sur les objets. Chaque actif est un objet unique sur la chaîne. Cela permet une exécution parallèle sans conflits d’état, car les objets indépendants ne se bloquent pas mutuellement. C’est la raison architecturale pour laquelle Sui peut traiter des transactions comme les 15 millions d’interactions de jeu sur chaîne de XOCIETY sans goulots d’étranglement. Aptos utilise Move basé sur les comptes avec Block-STM, concurrence optimiste, détection de conflits et rollback. Plus familier pour les développeurs Ethereum, plus difficile à paralléliser proprement, mais doté d’outils de vérification formelle plus puissants via Move Prover. L’implémentation Move de @Nasun_io est basée sur les comptes. C’est un choix délibéré pour une chaîne qui gère simultanément un DEX, une couche de gouvernance IA et une économie d’actifs de jeu. Le modèle basé sur les comptes offre à la trace d’audit de Baram un modèle d’état plus cohérent. Il rend la logique de routage des commandes de Pado plus proche de ce que les développeurs Ethereum connaissent déjà. Mais cela signifie aussi que Nasun ne bénéficie pas automatiquement du parallélisme au niveau des objets comme Sui. L’observation silencieuse : « exécution parallèle Layer-1 » figure dans la description produit de Nasun elle-même. Sur une chaîne basée sur les comptes, l’exécution parallèle nécessite une concurrence optimiste de type Block-STM ou équivalente. Qu’est-ce qui fonctionne exactement en coulisses, et comment gère-t-elle les conflits entre les échanges Pado et les règlements d’actifs Gen Sol se produisant simultanément ? Voilà la question technique que le cadre « Déplacez-vous, Sui » n’a jamais eu à répondre.