Une conséquence positive de toute la réflexion récente détaillée sur les formats de transaction — pas seulement 8141, mais aussi les discussions sur « l’avenir de l’état », par exemple les UTXO, le PBT, les nonces clés, et le mempool récursif STARK — est que nous avons une compréhension beaucoup plus explicite de la manière dont les transactions possèdent des « actions » et des « dépendances », et que nous pouvons concevoir des optimisations séparées pour chacune. Une action est un effet produit par une transaction. Une dépendance est un fait concernant la transaction et/ou l’état qui doit être vrai pour que la transaction soit valide. Par exemple, une signature est une dépendance, une preuve Merkle d’un UTXO est une dépendance, un ZK-SNARK (ou STARK) est une dépendance, un appel qui envoie de l’ETH est une action. Les dépendances peuvent être traitées en parallèle. Les dépendances impliquant de l’état peuvent être analysées par un mempool, surtout si l’état spécifique accédé est déclaré statiquement. Les dépendances pures (aucun appel d’état autorisé) peuvent être traitées une seule fois au niveau du mempool et n’ont jamais besoin d’être traitées à nouveau — et pourraient même être remplacées par un STARK les vérifiant, permettant non seulement d’éliminer l’exécution, mais aussi les données. En principe, les dépendances et les actions peuvent toutes être exprimées comme des appels (si nécessaire, des appels à des précompilations). Cela rendrait le format de transaction lui-même très minimaliste (une liste d’appels, des indicateurs pour le type de chaque appel — par exemple, les dépendances seraient des appels statiques ou purs — ainsi que l’origine, le nonce, etc.) et permettrait une compatibilité maximale même si différentes chaînes EVM possèdent des fonctionnalités différentes. Dans l’Ethereum de l’époque 2015, penser explicitement à ces différences n’était pas très important : l’exécution était l’exécution, il y avait assez peu de transactions pour pouvoir les traiter toutes en série, et les comptes ECDSA à clé unique suffisaient à tout le monde. La stratégie actuelle d’évolutivité d’Ethereum exige toutefois de dépasser ce paradigme. Ethereum est aimé de nombreux développeurs car son modèle d’exécution et d’état est si dynamique et flexible. Mais le dynamique et le flexible ne sont pas favorables à l’évolutivité. Heureusement, plus de 90 % de l’activité d’Ethereum en volume ne nécessite rien de dynamique ni de flexible. Nous devons donc exiger que les contrats, les comptes et les transactions spécifient explicitement ce qui est dynamique et flexible, et ce qui est plus analyzable statiquement mais plus restrictif ; les éléments plus analyzables statiquement bénéficient du coût de gaz le plus bas et évoluent donc le plus. En effet, nous devons tirer les leçons du meilleur des deux modèles — celui d’Ethereum de 2015 et celui plus similaire à Bitcoin (rappel : Bitcoin possède ce que j’appelle l’abstraction de compte depuis le début) — et offrir un mélange des deux (en réalité, tout le spectre entre les deux), avec des coûts de gaz adaptés au niveau d’évolutivité requis. Les nouveaux types d’état, le mempool récursif STARK, les nonces clés, etc., vont tous dans cette direction. Tout cela concerne les types de transactions, car un type de transaction à usage général constitue une couche d’interface naturelle sur laquelle tout cela peut être implémenté ; la réflexion actuelle autour du type de transaction EIP-8141 va exactement dans cette direction, favorable à ces types de généralisations futures. Ainsi, dans ce sens, un EIP-8141 bien réalisé n’est pas seulement le point culminant de 10 ans de travail sur l’abstraction de compte, c’est aussi une préparation pour les quelques années à venir d’une hyper-évolutivité responsable et favorable à la décentralisation.