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 un état non contentieux (comme les transferts/approbations), ce sont également les types de transactions qui n'ajoutent pas beaucoup de surcharge à une exécution synchrone, ce qui rend l'exécution asynchrone une alternative beaucoup moins attrayante compte tenu des coûts de développement supplémentaires et de la conditionnalité du traitement des transactions sur le client final (vérifier si une transaction peut toucher un état contentieux, ce qui n'est pas trivial, et choisir d'attendre le résultat de la chaîne ou de le simuler localement).
Keone Hon ⨀
Keone Hon ⨀11 août, 03:59
Aujourd'hui, j'écris sur l'exécution asynchrone (également appelée exécution différée). C'est l'une des "grandes idées" des Monades qui semblera évidente avec le recul : dès que l'ordre des transactions est déterminé, l'état est déterminé. Vous ne le savez peut-être pas, mais dans la plupart des blockchains, y compris Ethereum et Solana, les nœuds évaluant une liste de transactions (c'est-à-dire un bloc) doivent également s'accorder sur le résultat de cette liste de transactions (c'est-à-dire la racine d'état après ces transactions) dans le cadre du processus de vote. Cela nécessite qu'ils exécutent ces transactions avant de répondre avec un vote, ce qui réduit évidemment considérablement la quantité de travail qu'on peut attendre d'eux. Cette attente est trop stricte et est l'une des principales raisons pour lesquelles le débit des blockchains est si limité.
1,31K