Ceci est un aperçu de l'exécution asynchrone : comment nous l'avons fait fonctionner dans Monad, pourquoi l'EIP-7702 l'a cassé, et comment le réparer. Pour donner un peu de contexte, l'exécution asynchrone est présente dans Monad depuis que les clients de consensus et d'exécution ont été reliés entre eux. L'exécution asynchrone permet à l'exécution de prendre du retard par rapport au consensus d'un nombre fixe de blocs d'un point de vue d'interaction. La plupart des blockchains ont un consensus entrelacé. C'est-à-dire que l'exécution se produit avant le consensus, ce qui signifie qu'il faut caser l'exécution dans un budget temporel qui est une petite fraction du temps de bloc (le reste étant occupé par la messagerie mondiale, également connue sous le nom de consensus). Cela limite intrinsèquement le gaz par seconde du système. Les L2 contournent cela en n'ayant pas de consensus du tout. Mais nous voulons le comportement d'un L1 distribué et décentralisé qui maintient une haute performance. L'exécution asynchrone nous permet d'éviter ce problème en déplaçant l'exécution hors du chemin chaud du consensus. Au lieu de cela, le consensus et l'exécution se produisent dans des couloirs parallèles. Le consensus sur le bloc 2 se produit pendant que l'exécution du bloc 1 s'exécute en parallèle. Il doit cependant y avoir un accord entre le consensus et l'exécution. Plus précisément, cet accord est : l'exécution n'est autorisée à prendre du retard par rapport au consensus que de k blocs, car les propositions de blocs contiennent une racine merkle retardée. De plus, le consensus construit des blocs avec une vue retardée de l'état (retardée de k blocs). Cela signifie qu'il y a un danger que le consensus inclue une transaction d'un expéditeur qui, au moment où nous exécutons, s'avère avoir un solde vide. Ce serait mauvais si le protocole permettait cela, car cela ouvrirait un vecteur de déni de service (DOS). Par conséquent, pour résoudre ce problème et permettre en toute sécurité l'exécution asynchrone, le client de consensus Monad calcule le débit maximum de MON de chaque transaction comme suit : MON_dépensé = offre_gaz * limite_gaz + valeur. Le client de consensus garde une liste à jour des soldes de compte disponibles pour chaque expéditeur après avoir déduit MON_dépensé pour chaque transaction qu'ils ont envoyée. En se basant sur ce solde courant, le client de consensus n'inclut des transactions que s'il peut être sûr que la transaction peut être payée. C'est une approche pessimiste de la construction de blocs puisque cela ne prend pas en compte la possibilité que des comptes gagnent en solde grâce à un transfert entrant. Laissez-moi expliquer ce que je veux dire avec un exemple. Supposons que le compte d'Alice ait 100 MON. Ensuite, les 3 transactions suivantes sont incluses dans le bloc 1000 : Tx 1 : Alice envoie 20 MON à Bob, coûtant 1 MON en frais. Tx 2 : Alice dépense 70 MON pour acheter un memecoin, coûtant 1 MON en frais....