Je pense que la principale raison pour laquelle la plupart des blockchains n'ont pas adopté l'exécution asynchrone est simple : lorsque les utilisateurs voient que leur transaction est confirmée, ils s'attendent à ce que le résultat soit disponible car leurs actions ultérieures en dépendent. Bien qu'avec l'exécution différée, il soit possible de simuler localement le résultat pour les transactions travaillant avec un état non contentieux (comme les transferts/approbations), ce sont aussi les types de transactions qui n'ajoutent pas beaucoup de surcharge à l'exécution synchrone. Cet aspect rend l'exécution asynchrone une alternative beaucoup moins attrayante compte tenu de : 1. Coûts de développement supplémentaires 2. Une conditionnalité de traitement des transactions non triviale pour le client final (vérifier si une transaction peut toucher un état contentieux et choisir d'attendre le résultat de la chaîne ou de le simuler localement)

C'est certainement un chemin intéressant à emprunter, mais l'histoire montre que les paradigmes qui devraient techniquement offrir plus de performance échouent souvent à atteindre l'adoption en raison d'une complexité supplémentaire. Par exemple, l'exécution asynchrone dans TON (bien que très différente de celle de Monad, mais aussi meilleure sur le papier d'ailleurs) est le principal point de plainte des développeurs que j'ai entendus, et cela n'apporte pas non plus de gains de performance raisonnables.

@MaxResnick1 Je ne comprends pas non plus pourquoi tu as répété que c'est strictement plus rapide en termes d'état finalisé. En termes de latence, c'est évidemment le cas et ce n'était pas le but de mon post.