Vitalik Buterin dévoile la refonte des transactions d'Ethereum

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 certaines tâches 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 puissent se produire.

Buterin a décrit les deux composants comme « actions » et « dépendances » dans un article détaillé. Les actions modifient l'état d'Ethereum, comme transférer de l'ETH ou appeler un contrat. Les dépendances couvrent les informations nécessaires 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 à connaissance nulle et les conditions d'état qui doivent rester vraies lorsqu'une transaction entre dans un bloc.

Buterin a fait valoir que rendre cette distinction explicite pourrait aider Ethereum à évoluer sans abandonner son environnement d'exécution flexible. Cependant, la proposition reste une 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.

Ethereum pourrait traiter les dépendances de transaction en parallèle

Les transactions Ethereum combinent actuellement l'autorisation, le paiement des frais et l'exécution dans 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 ces 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 ne doit pas nécessairement attendre les signatures non liées attachées à d'autres transactions. Si plusieurs vérifications indépendantes sont connues à l'avance, les clients peuvent répartir le travail sur les ressources de traitement disponibles.

Les vérifications dépendantes de l'état nécessitent plus de soin. 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 sur ces conditions plus efficacement lorsque les transactions déclarent quelles parties de l'état elles accèdent.

L'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é d'Ethereum en volume ne nécessite pas le niveau complet de flexibilité dynamique du réseau. Ce chiffre est son évaluation plutôt qu'une mesure de réseau publiée dans l'article. L'argument plus large est que les transferts courants et les interactions de contrat de routine pourraient utiliser des formats plus restrictifs sans limiter les applications spécialisées.

Le modèle proposé préserverait le système de comptes flexible d'Ethereum pour les transactions qui en ont besoin. Une activité plus prévisible pourrait utiliser des structures analysables statiquement ressemblant à des parties du modèle de transaction de Bitcoin.

Bitcoin utilise un modèle de sorties de transaction non dépensées 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 contrats programmable. Buterin ne propose pas qu'Ethereum remplace son modèle de comptes par l'architecture de Bitcoin. Il a décrit un spectre combinant des idées des deux systèmes.

L'EIP-8141 fournit un cadre général pour les transactions

L'EIP-8141 est une proposition d'amélioration d'Ethereum (EIP) à l'état de brouillon pour un nouveau type de transaction appelé transaction Frame. Elle divise une transaction en trames d'appel de contrat qui peuvent valider l'autorisation, approuver le paiement des frais 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 plutôt définir les règles d'autorisation et de paiement nécessaires.

Les transactions Frame pourraient prendre en charge des frais sponsorisés, des 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.

Dans la structure proposée, les trames de vérification détermineraient si l'expéditeur a autorisé la transaction. Des trames distinctes pourraient établir qui paie les frais, puis exécuter les opérations demandées.

Cette structure s'aligne sur la division de Buterin entre dépendances et actions. Les trames de vérification gèrent les conditions qui doivent être satisfaites. Les trames d'expéditeur gèrent les opérations qui modifient l'état.

Le format pourrait également améliorer l'interopérabilité entre les réseaux de machines virtuelles Ethereum. 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 de base d'appels avec des indicateurs 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é comme une proposition de base à l'état de brouillon. Sa spécification actuelle comprend des règles détaillées pour l'admission dans le mempool, l'exécution des trames, les reçus, les signatures, la comptabilité du gaz et la propagation des transactions. Ces détails peuvent changer au cours de 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'outillage, les limites de transactions en attente et les restrictions imposées aux trames de vérification.

Une discussion a noté que le mempool public proposé ne conserverait normalement qu'une seule transaction Frame en attente pour chaque expéditeur. Les développeurs se sont demandé comment cette règle affecterait les comptes qui soumettent régulièrement plusieurs transactions dans un même bloc.

D'autres participants ont examiné si le format introduit 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.

Les STARK récursifs pourraient éliminer la vérification répétée

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 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 l'avoir vérifiée, le réseau pourrait remplacer plusieurs travaux 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 pour la cryptographie post-quantique. Les signatures résistantes aux quantiques 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 une norme de signature fixe unique. L'agrégation récursive de preuves pourrait alors réduire le coût de vérification des grandes signatures post-quantiques.

L'EIP-8141 pourrait aider les comptes Ethereum à adopter une 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 nonces clés pourraient éliminer les goulots d'étranglement des transactions

Les comptes Ethereum utilisent des nonces séquentiels pour empêcher la relecture des transactions. Si un compte soumet des 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 est bloquée ou invalide, les transactions ultérieures du même compte peuvent également attendre, même si 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 se dérouler sans attendre qu'une autre séquence progresse.

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 nonces tout en conservant la protection contre la relecture.

Crypto.news a précédemment rapporté que les nonces clés pourraient empêcher des transactions privées indépendantes de se bloquer mutuellement. Cette fonctionnalité fait partie d'un effort plus large pour améliorer les transactions privées, les comptes flexibles et la résistance à la censure.

Buterin a également relié 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 réduits. Les appels de contrats dynamiques continueraient de 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 réelles de mise à l'échelle créées par chaque transaction. Elle ne garantirait pas des frais plus bas pour chaque utilisateur ou application.

L'EIP-8141 nécessite encore l'approbation et les tests des développeurs

L'EIP-8141 doit passer plusieurs étapes avant de pouvoir affecter les utilisateurs d'Ethereum. Les développeurs principaux doivent d'abord convenir que les transactions Frame offrent une meilleure voie que les conceptions concurrentes d'abstraction de compte.

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 une revue de sécurité. Les développeurs devraient également tester comment les transactions Frame interagissent avec les constructeurs de blocs, les mempools, les marchés de frais et les contrats intelligents existants.

Les discussions précédentes des développeurs ont envisagé l'EIP-8141 pour la future mise à niveau Hegotá d'Ethereum. Cependant, crypto.news a rapporté que les transactions Frame restaient à l'étude plutôt que formellement planifiées.

FOCIL, une proposition distincte visant à améliorer la résistance à la censure grâce à 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 transactions Frame concernent l'autorisation et la structure d'exécution, tandis que FOCIL concerne l'inclusion des transactions éligibles dans les blocs.

Les développeurs ont fait valoir que les utiliser ensemble pourrait fournir une abstraction de compte native avec une résistance à la censure plus forte. Cette combinaison est encore un ensemble proposé, pas un engagement approuvé sur 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 terminée, une date d'activation ou un changement confirmé des frais de gaz du réseau principal.

Les prochaines étapes vérifiables seraient un soutien formel des développeurs, l'inclusion dans le périmètre d'une mise à niveau et des implémentations fonctionnelles sur les réseaux de développement. Jusque-là, l'EIP-8141 et les mempools STARK récursifs restent des propositions actives de recherche et d'ingénierie.

FAQ