Le cofondateur d'Ethereum, Vitalik Buterin, a présenté le 6 septembre un modèle de transaction à plus long terme qui pourrait permettre au réseau de traiter certains travaux de validation en parallèle.
Sa proposition sépare les effets produits par les transactions des conditions qui doivent être satisfaites avant que ces effets ne puissent se produire.
Buterin a décrit les deux composants comme des « actions » et des « dépendances » dans un article détaillé. Les actions modifient l'état d'Ethereum, comme le transfert d'ETH ou l'appel d'un contrat. Les dépendances couvrent les informations requises pour établir qu'une transaction est valide.
Une signature numérique est un exemple de dépendance. D'autres exemples incluent les preuves de Merkle montrant qu'une sortie non dépensée existe, les preuves à divulgation nulle de connaissance et les conditions d'état qui doivent rester vraies lorsqu'une transaction entre dans un bloc.
Buterin a soutenu que rendre cette distinction explicite pourrait aider Ethereum à évoluer sans abandonner son environnement d'exécution flexible. Cependant, la proposition fait toujours partie de la recherche continue sur le protocole. Les développeurs d'Ethereum n'ont pas approuvé la conception complète pour le déploiement.
Les transactions Ethereum combinent actuellement l'autorisation, le paiement des frais et l'exécution au sein d'un flux de traitement commun. Les nœuds vérifient si une transaction est correctement signée, si l'expéditeur peut la payer et si ses instructions s'exécutent avec succès.
Certaines de ces vérifications ne dépendent pas des changements d'état finaux de la transaction. Buterin a déclaré que de telles dépendances pourraient être traitées séparément et, dans de nombreux cas, simultanément.
Par exemple, un validateur peut avoir besoin de confirmer une signature avant d'accepter une transaction. Cette vérification n'a pas nécessairement besoin d'attendre les signatures non liées attachées à d'autres transactions. Si plusieurs vérifications indépendantes sont connues à l'avance, les clients peuvent distribuer le travail sur les ressources de traitement disponibles.
Les vérifications dépendantes de l'état nécessitent plus de prudence. Une condition liée à un solde de compte ou à un emplacement de stockage peut devenir invalide si une transaction antérieure modifie le même état. Buterin a déclaré que les mempools pourraient raisonner plus efficacement sur ces conditions lorsque les transactions déclarent les parties de l'état auxquelles elles accèdent.
Cette approche récompenserait les transactions prévisibles. Les opérations qui spécifient clairement leurs dépendances pourraient bénéficier de coûts de gaz inférieurs car les clients pourraient les vérifier plus efficacement. Les transactions nécessitant des appels dynamiques et un accès imprévisible à l'état resteraient possibles mais pourraient coûter plus cher.
Buterin a estimé que plus de 90 % de l'activité Ethereum en volume ne nécessite pas le niveau total de flexibilité dynamique du réseau. Ce chiffre est son évaluation plutôt qu'une mesure réseau publiée dans l'article. L'argument plus large est que les transferts courants et les interactions contractuelles routinières pourraient utiliser des formats plus restrictifs sans limiter les applications spécialisées.
Le modèle proposé préserverait le système de compte flexible d'Ethereum pour les transactions qui en ont besoin. Une activité plus prévisible pourrait utiliser des structures statiquement analysables ressemblant à des parties du modèle de transaction de Bitcoin.
Bitcoin utilise un modèle de sorties de transaction non dépensées (UTXO) dans lequel une transaction identifie les sorties qu'elle a l'intention de dépenser. Ethereum utilise normalement des comptes avec des soldes, des nonces et un stockage de contrat programmable. Buterin ne propose pas qu'Ethereum remplace son modèle de compte par l'architecture de Bitcoin. Il a décrit un spectre combinant des idées des deux systèmes.
L'EIP-8141 est une proposition d'amélioration d'Ethereum (EIP) préliminaire pour un nouveau type de transaction appelé « Frame Transaction ». Elle divise une transaction en cadres d'appel de contrat qui peuvent valider l'autorité, approuver le paiement du gaz et effectuer des opérations utilisateur.
La proposition officielle indique que la validité de la transaction et le paiement des frais ne dépendraient plus uniquement d'une signature standard attachée à la transaction externe. Le code du compte pourrait à la place définir les règles d'autorisation et de paiement nécessaires.
Les « Frame Transactions » pourraient prendre en charge les frais sponsorisés, les paiements en jetons autres que l'ETH, la rotation des clés et le regroupement de transactions. Elles pourraient également permettre aux comptes détenus en externe de bénéficier de fonctionnalités d'abstraction de compte sans dépendre du même déploiement de contrat sur chaque réseau compatible.
Selon la structure proposée, les cadres de vérification détermineraient si l'expéditeur a autorisé la transaction. Des cadres distincts pourraient établir qui paie les frais et ensuite exécuter les opérations demandées.
Cette structure s'aligne avec la division de Buterin entre les dépendances et les actions. Les cadres de vérification gèrent les conditions qui doivent être satisfaites. Les cadres de l'expéditeur gèrent les opérations qui modifient l'état.
Le format pourrait également améliorer l'interopérabilité entre les réseaux Ethereum Virtual Machine. Différentes chaînes pourraient prendre en charge la même structure de transaction minimale tout en appliquant leurs propres outils de vérification, précompilations ou fonctionnalités de compte.
Buterin a décrit le format potentiel comme une liste basique d'appels avec des drapeaux identifiant leur fonction. Un appel pourrait être marqué comme une dépendance pure, une vérification dépendante de l'état ou une action. La transaction contiendrait également des informations standard telles que son origine et son nonce.
L'EIP-8141 reste classée comme une proposition Core préliminaire. Sa spécification actuelle comprend des règles détaillées pour l'admission au mempool, l'exécution des cadres, les reçus, les signatures, la comptabilisation du gaz et la propagation des transactions. Ces détails peuvent changer pendant l'examen.
Les développeurs d'Ethereum ont également débattu de préoccupations techniques. Celles-ci incluent les risques de déni de service, les règles de remplacement des transactions, les changements d'outils, les limites de transactions en attente et les restrictions imposées aux cadres de vérification.
Une discussion a souligné que le mempool public proposé ne conserverait normalement qu'une seule « Frame Transaction » en attente pour chaque expéditeur. Les développeurs se sont interrogés sur l'impact de cette règle sur les comptes qui soumettent régulièrement plusieurs transactions au sein d'un même bloc.
D'autres participants ont examiné si le format introduisait une complexité supplémentaire pour les portefeuilles, les constructeurs de blocs et les interfaces d'appel de procédure à distance d'Ethereum. Ces questions doivent être résolues avant que les équipes clientes puissent implémenter une spécification stable.
Le modèle à plus long terme de Buterin va au-delà de l'EIP-8141. Il a suggéré que les dépendances ne nécessitant aucun accès à l'état pourraient être vérifiées une seule fois au niveau du mempool au lieu d'être répétées par chaque validateur.
Une dépendance pure pourrait inclure une signature cryptographique ou une preuve dont la validité ne change pas avec l'état d'Ethereum. Après vérification, le réseau pourrait remplacer plusieurs éléments de travail de vérification par un STARK récursif confirmant que toutes les vérifications ont été effectuées correctement.
Un STARK est une preuve cryptographique qui permet à une partie de démontrer qu'un calcul a été effectué correctement. Les preuves récursives peuvent vérifier d'autres preuves, ce qui permet de combiner de nombreuses vérifications en une tâche de vérification plus petite.
Le mempool proposé pourrait agréger les signatures de transaction, les preuves de validité et d'autres dépendances avant l'exécution du bloc. Les validateurs vérifieraient ensuite la preuve agrégée au lieu de répéter indépendamment chaque calcul original.
Buterin a suggéré que cette approche pourrait également réduire la quantité de données de vérification placées sur la chaîne. Si la preuve récursive établit que toutes les dépendances étaient valides, certaines des données originales pourraient potentiellement être omises.
Ce résultat ne fait pas partie de la spécification actuelle de l'EIP-8141. Il nécessiterait des recherches supplémentaires couvrant la génération de preuves, la coordination du mempool, la disponibilité des données et les protections contre l'agrégation invalide.
La conception est également liée à la préparation d'Ethereum à la cryptographie post-quantique. Les signatures résistantes aux quanta sont généralement plus grandes et plus coûteuses à vérifier que les signatures ECDSA utilisées par les comptes Ethereum ordinaires.
L'EIP-8141 pourrait permettre aux comptes de définir de nouveaux schémas d'autorisation sans attendre qu'Ethereum remplace un standard de signature fixe unique. L'agrégation de preuves récursives pourrait alors réduire le coût de vérification des grandes signatures post-quantiques.
L'EIP-8141 pourrait aider les comptes Ethereum à adopter l'autorisation post-quantique si des systèmes de signature pratiques deviennent disponibles. Cela reste une voie de sécurité à plus long terme plutôt qu'une réponse immédiate à une menace quantique active.
Les comptes Ethereum utilisent des nonces séquentiels pour empêcher la relecture de transactions. Si un compte soumet les transactions numérotées 10, 11 et 12, le réseau les traite normalement dans cet ordre.
La séquence peut créer un goulot d'étranglement. Si la transaction 10 reste bloquée ou devient invalide, les transactions ultérieures du même compte peuvent également attendre, même lorsque leurs opérations ne sont pas liées.
Les nonces clés donneraient à un compte plusieurs séquences de nonces indépendantes. Les transactions assignées à différentes clés pourraient progresser sans attendre qu'une autre séquence avance.
Cela pourrait aider les comptes intelligents, les systèmes de confidentialité et les applications qui soumettent plusieurs opérations indépendantes simultanément. Chaque flux de travail pourrait recevoir son propre domaine de nonce tout en conservant la protection contre la relecture.
Crypto.news a précédemment rapporté que les nonces clés pourraient empêcher les transactions privées indépendantes de se bloquer mutuellement. Cette fonctionnalité fait partie d'un effort plus large visant à améliorer les transactions de confidentialité, les comptes flexibles et la résistance à la censure.
Buterin a également lié le travail sur les transactions à des modèles d'état alternatifs, y compris les conceptions UTXO natives et les structures d'état basées sur des preuves. Ces projets explorent si certains actifs ou opérations peuvent utiliser des règles d'état prévisibles tandis que les contrats complexes conservent la flexibilité existante d'Ethereum.
L'approche pourrait créer plusieurs niveaux de traitement. Les opérations simples et déclarées seraient plus faciles à analyser et pourraient bénéficier de frais inférieurs. Les appels de contrat dynamiques continueraient à fonctionner mais consommeraient plus de ressources car les clients ne peuvent pas préparer leur exécution de la même manière.
Une telle tarification différenciée tenterait d'aligner les frais sur les contraintes d'évolutivité réelles créées par chaque transaction. Elle ne garantirait pas des frais inférieurs pour chaque utilisateur ou application.
L'EIP-8141 doit passer par plusieurs étapes avant de pouvoir affecter les utilisateurs d'Ethereum. Les développeurs principaux doivent d'abord convenir que les « Frame Transactions » offrent une meilleure voie que les conceptions d'abstraction de compte concurrentes.
La proposition nécessiterait ensuite des implémentations client, des réseaux de développement, des tests d'interopérabilité, un support de portefeuille et un examen de sécurité. Les développeurs devraient également tester comment les « Frame Transactions » interagissent avec les constructeurs de blocs, les mempools, les marchés de frais et les contrats intelligents existants.
Des discussions antérieures entre développeurs avaient envisagé l'EIP-8141 pour la future mise à niveau Hegotá d'Ethereum. Cependant, crypto.news a rapporté que les « Frame Transactions » restaient à l'étude plutôt que d'être formellement planifiées.
FOCIL, une proposition distincte visant à améliorer la résistance à la censure via des listes d'inclusion de transactions, a également été discutée en parallèle de l'EIP-8141. Les deux propositions abordent des problèmes différents. Les « Frame Transactions » concernent l'autorisation et la structure d'exécution, tandis que FOCIL concerne l'inclusion de transactions éligibles dans les blocs.
Les développeurs ont soutenu que leur utilisation conjointe pourrait offrir une abstraction de compte native avec une résistance à la censure renforcée. Cette combinaison est encore un ensemble proposé, et non un engagement approuvé dans la feuille de route d'Ethereum.
Les commentaires de Buterin du 6 septembre décrivent donc une direction possible pour la conception des transactions Ethereum. Ils n'annoncent pas une mise à niveau achevée, une date d'activation ou un changement confirmé des frais de gaz du mainnet.
Les prochaines étapes vérifiables seraient le soutien formel des développeurs, l'inclusion dans le cadre d'une mise à niveau et des implémentations fonctionnelles sur les réseaux de développement. D'ici là, l'EIP-8141 et les mempools STARK récursifs restent des propositions de recherche et d'ingénierie actives.
L'EIP-8141 propose des « Frame Transactions » qui divisent la validation, l'approbation des frais et l'exécution en cadres d'appel de contrat distincts.
Il s'agit actuellement d'une proposition Core préliminaire. Les développeurs d'Ethereum peuvent toujours modifier ou rejeter sa spécification.
Une action modifie l'état d'Ethereum, comme l'envoi d'ETH ou l'appel d'un contrat. Une dépendance est une condition qui doit être valide, comme une signature ou une preuve d'état.
Les séparer pourrait permettre de traiter les dépendances indépendantes simultanément avant l'exécution des opérations modifiant l'état.
Cela pourrait rendre les transactions prévisibles moins chères à traiter si les développeurs adoptent une tarification du gaz qui récompense les opérations statiquement analysables.
Aucune réduction de frais n'est confirmée. Les coûts dépendraient de la spécification finale, de l'implémentation client et des futures décisions de mise à niveau.
ETH
