EIP-8361 cible précisément l’admission par preuve pour les transactions frame EIP-8141. Il ne remplace pas l’exécution Ethereum, n’introduit pas de nouveau type de transaction, ne déploie pas de smart contract, n’assure pas la confidentialité, ne modifie pas les récompenses des validateurs et n’impose aucune période de mise en œuvre de 18 mois. Son objectif est plus restreint : réduire les calculs redondants lors de la validation tout en conservant les garanties contre les transactions invalides ou trop consommatrices.
Les sections suivantes détaillent le fonctionnement du processus de preuve, les éléments vérifiés par les nœuds, les différences entre EIP-8361, les preuves de validité des rollups et la simulation de transaction, ainsi que les limitations techniques persistantes.
Points clés à retenir
- EIP-8361 standardise les données de preuve de validité des transactions pour la propagation peer-to-peer. Une transaction frame peut transporter un STARK attestant que son préfixe de validation atteint un état approuvé.
- Les nœuds vérifient la preuve au lieu de rejouer la logique d’autorisation coûteuse. Cette séparation entre preuve et vérification pourrait réduire les calculs répétés sur Ethereum.
- La preuve reste hors consensus. Elle accompagne la transaction, sert à l’admission dans le mempool, puis est supprimée si elle n’est plus utile.
- La conception prend en charge la validation avancée des smart accounts. Elle inclut les règles multi-signatures, les systèmes de signature alternatifs, les paymasters et les autorisations complexes.
- EIP-8361 reste un brouillon. Ce n’est pas une mise à niveau activée et il ne faut pas le confondre avec EIP-7701, EIP-7702, les preuves de validité de rollup ou les propositions de récompenses de staking.
Qu’est-ce qu’EIP-8361 ?
EIP-8361, intitulé Transaction Validity Proofs, propose un mécanisme réseau permettant à une transaction Ethereum d’être accompagnée d’une preuve cryptographique que sa logique de validation l’approuve. Ce brouillon est le pendant réseau des évolutions de protocole d’EIP-8141, qui définit les transactions frame et les étapes de validation programmables.
Une Ethereum Improvement Proposal est un document de conception technique décrivant une norme potentielle, une fonctionnalité de protocole, une interface ou un processus pour Ethereum. Sa publication ne signifie pas son adoption ou son déploiement automatique. EIP-8361 reste un brouillon dont la spécification, les dépendances et le statut peuvent évoluer.
La proposition répond à la question :
Comment un nœud peut-il admettre une transaction dont l’autorisation est coûteuse, sans que chaque pair répète ce calcul ?
Avec EIP-8361, un générateur de preuve exécute la logique de validation de la transaction off-chain et génère un STARK. Un nœud récepteur vérifie cette preuve, contrôle les hypothèses déclarées par rapport à l’état actuel d’Ethereum, et décide d’inclure ou non la transaction dans son mempool public.
La transaction doit rester valide selon les règles d’exécution d’Ethereum lors de son inclusion dans un bloc. La preuve soutient la politique d’admission, sans remplacer l’exécution protocolaire ou la validation de consensus.
Pourquoi la validation des transactions complexes sur Ethereum est-elle difficile ?
Un EOA classique est contrôlé par une clé privée et une clé publique. Il autorise une transaction par signature ECDSA, la transaction précisant le nonce, l’adresse de destination, la valeur, l’ID de chaîne, la limite de gas et le prix du gas ou les paramètres EIP-1559.
Ces contrôles sont prévisibles. Un nœud vérifie la signature, la couverture des fonds, le nonce, et rejette les transactions mal formées ou rejouées.
Les smart accounts élargissent la surface de validation. Au lieu d’une seule clé privée, un smart account peut utiliser :
- plusieurs clés publiques ;
- des plafonds de dépenses ;
- des clés de session ;
- des contrats délégués ;
- des règles de paymaster ;
- des signatures post-quantiques ;
- des conditions de récupération ;
- des preuves à divulgation nulle de connaissance ;
- un code d’autorisation spécifique à l’application.
Cette logique peut résider dans un smart contract déployé ou dans un contrat créé lors du déploiement du compte. La création et le déploiement peuvent aussi nécessiter la validation d’une factory, d’un code d’initialisation ou de l’adresse cible.
Les nœuds Ethereum ne peuvent pas exécuter sans limite du code de validation pour chaque transaction non confirmée. Un attaquant pourrait soumettre des transactions frauduleuses invoquant des smart contracts coûteux, des fonctions de hachage, des lectures de stockage ou des systèmes de preuve, sans jamais autoriser l’exécution. Même invalides, leur vérification consommerait des ressources.
Les preuves de validité EIP-8361 déplacent donc le travail coûteux vers un générateur de preuve, tout en maintenant une vérification bornée.
Fonctionnement des transactions avec preuve EIP-8361
EIP-8361 propose deux modes d’admission pour une transaction frame EIP-8141 :
- Admission simulée : le nœud exécute le préfixe de validation.
- Admission par preuve : le nœud vérifie un STARK prouvant que le préfixe de validation approuve.
Le second mode cible les cas où un appel classique dépasserait le budget de vérification du nœud.
-
La transaction définit sa logique de validation
Une transaction frame EIP-8141 divise son travail en frames avec des fonctions distinctes. Certains frames établissent l’autorisation, identifient le payeur ou préparent l’exécution. Un préfixe de validation précède les frames d’exécution.
Le préfixe de validation peut appeler un smart contract associé à l’expéditeur ou à un contrat délégué. Ce contrat vérifie signatures, permissions, soldes, conditions d’expiration ou autres règles avant l’opération APPROVE.
EIP-8141 diffère d’une transaction classique où une signature ECDSA reconnue détermine l’expéditeur. Son modèle de validation programmable s’inscrit dans l’évolution vers l’abstraction native des comptes. EIP-8141 évite aussi la liste d’autorisations ECDSA d’EIP-7702, car les transactions frame visent une flexibilité cryptographique accrue.
-
Le générateur de preuve exécute le préfixe de validation
Le générateur de preuve exécute le préfixe de validation de la transaction avec un ensemble d’entrées et d’hypothèses d’état déclarés. Ce processus peut inclure la vérification de :
- la correspondance d’une signature ;
- la couverture des fonds ;
- le maintien du solde du paymaster ;
- la présence d’une permission en stockage ;
- l’ID de chaîne attendu ;
- la prévention du rejeu par nonce ;
- la terminaison par une approbation.
Il crée ensuite un STARK engageant la transaction, les dépendances, hypothèses, payeur et conditions de validité.
-
La preuve déclare les hypothèses d’état
Une preuve cryptographique ne reste valable que si elle ne dépend pas d’un état modifié. EIP-8361 propose donc un vecteur d’hypothèses décrivant les faits d’état utilisés.
Une condition d’égalité impose la correspondance exacte d’un hash de code, d’un nonce ou d’une valeur de stockage. Une condition de seuil impose un solde minimum.
Ces hypothèses relient la preuve à un état valide antérieur, sans embarquer tout l’état Ethereum. Lorsqu’un bloc modifie les données, le nœud peut revérifier les hypothèses.
Ce mécanisme est central pour la validation du mempool EIP-8361 : le nœud ne fait pas aveuglément confiance à une ancienne preuve.
-
Les nœuds vérifient le STARK
Un nœud effectue d’abord des contrôles structurels peu coûteux avant de vérifier la preuve. Il contrôle ensuite le STARK avec la clé de vérification et compare les dépendances et hypothèses à son état Ethereum actuel.
Les preuves modernes sont plus rapides à vérifier que la ré-exécution du calcul initial. Une seule preuve peut donc remplacer la simulation répétée, réduisant la redondance sur le réseau peer-to-peer.
La génération de preuve reste cependant coûteuse en ressources, mémoire et logiciels spécialisés. La proposition déplace le calcul, elle ne le supprime pas.
-
La transaction entre dans le mempool
Si la preuve et les contrôles d’état réussissent, le nœud admet et propage la transaction sans relancer le préfixe coûteux.
La preuve reste une métadonnée peer-to-peer : elle n’est pas ajoutée au calldata, ni stockée dans un smart contract, ni inscrite dans l’état du compte, ni incluse dans la racine Merkle du bloc.
Une fois la transaction incluse, Ethereum l’exécute selon les règles du protocole. Si la preuve devient obsolète ou la transaction est retirée, la métadonnée réseau peut être supprimée.
Que prouve une preuve de validité EIP-8361 ?
Une preuve de validité EIP-8361 est une preuve cryptographique qu’un calcul de validation donné a été exécuté correctement selon des hypothèses déclarées et a atteint l’état d’approbation requis.
Elle peut démontrer la vérification d’une signature, de soldes suffisants, d’un nonce, d’un payeur ou d’une autorisation contractuelle. Elle ne prouve pas nécessairement la validité de toutes les transitions d’état EVM ultérieures.
Distinction importante :
- EIP-8361 prouve la validation liée à l’admission.
- Une preuve de validité de rollup prouve des transitions d’état off-chain.
- Une preuve Merkle prouve l’inclusion dans une structure de données authentifiée.
- Une preuve à divulgation nulle de connaissance peut masquer des informations, mais la validité seule ne garantit pas la confidentialité.
Une preuve Merkle relie une transaction à un lot, un bloc ou un arbre d’état via une racine Merkle. Dans les ZK rollups, les preuves Merkle établissent l’existence des comptes et la cohérence des soldes.
EIP-8361 utilise un STARK comme preuve d’exactitude efficace, mais l’objectif n’est pas l’exécution confidentielle. La transaction et ses dépendances restent visibles pour les nœuds.
EIP-8361 vs preuves de validité ZK-Rollup
Les solutions Layer 2 utilisent les preuves de validité de façon plus large. Un ZK rollup exécute un lot de transactions off-chain et soumet une preuve succincte à un smart contract vérificateur sur Ethereum. Cette preuve démontre la transformation correcte de l’état selon les règles du rollup.
Au lieu de ré-exécuter chaque transaction sur Ethereum, le contrat vérifie la preuve et les entrées publiques. Cela réduit la consommation de ressources on-chain et mutualise les frais de gas. Les preuves récursives agrègent plusieurs preuves en une.
Les preuves de validité empêchent un ZK rollup de finaliser une transition invalide, sous réserve de la sécurité du système de preuve, du circuit, du contrat vérificateur et du modèle de disponibilité des données. Elles permettent aussi une finalité L2–L1 plus rapide.
EIP-8361 fait autre chose : il ne prouve pas un lot de calculs, ne met pas à jour une racine Merkle L2, ni ne déclenche de retrait. Il prouve qu’une transaction frame répond aux exigences d’admission d’un nœud.
| Dimension |
EIP-8361 |
Preuve de validité ZK-Rollup |
| Objectif principal |
Admission au mempool public |
Vérification de transition d’état L2 |
| Calcul prouvé |
Préfixe de validation |
Lot de transactions ou transition d’état |
| Vérification |
Nœuds Ethereum |
Smart contract vérificateur L1 |
| Stocké on-chain |
Non |
Preuve ou engagement dérivé |
| Bénéfice principal |
Évite la simulation répétée |
Évite la ré-exécution L2 sur L1 |
| Confidentialité garantie |
Non |
Pas nécessairement |
| Rôle consensus |
Aucun |
Prend en charge le règlement L2 |
Validité EIP-8361 vs preuves de fraude
Les rollups optimistes considèrent les mises à jour d’état comme valides, sauf contestation. Les preuves de fraude exigent la détection d’une transition litigieuse et une preuve pendant une période de contestation. Une réclamation invalide peut donc rester acceptée jusqu’à résolution.
Les preuves de validité prennent l’approche inverse : un engagement d’état n’est accepté qu’après confirmation cryptographique. Cela permet souvent des retraits plus rapides.
Il serait trop large d’affirmer que les preuves de validité sont « plus sûres » que les preuves de fraude. Les différences portent sur la complexité du générateur, la sécurité du vérificateur, la disponibilité des données, les trusted setups, les hypothèses de contestation et la maturité des implémentations.
EIP-8361 n’est pas un modèle de sécurité rollup : sa preuve est vérifiée avant l’admission mempool, tandis que les preuves de fraude et de validité protègent les systèmes off-chain.
EIP-8361 vs délégation de compte EIP-7702
EIP-7702 permet aux EOA de définir un indicateur de délégation dans leur code, pour que les appels exécutent le code d’un smart contract désigné. Il introduit une transaction type 4 avec une authorization_list.
Chaque tuple d’autorisation inclut :
- chain_id ;
- adresse du contrat délégué ;
- nonce du compte ;
- champs de signature.
L’autorisation est signée par la clé privée de l’EOA. Le signataire peut différer de tx.origin, et une transaction peut transporter des autorisations de plusieurs EOA. Chaque autorisation peut mettre à jour l’indicateur de délégation du compte avant l’exécution.
Les utilisateurs peuvent ainsi déléguer l’exécution à des smart contracts via des autorisations signées, sans transformer définitivement le compte en smart contract classique. Le code délégué peut gérer le batching, le parrainage du gas, les permissions ou d’autres comportements.
EIP-7702 introduit aussi des enjeux de sécurité : un chain ID à zéro peut rendre une autorisation valide sur plusieurs chaînes, tandis que les nonces et champs signés limitent les attaques par rejeu. Le code délégué peut affecter tx.origin, les transactions en attente, le stockage, les soldes.
EIP-8361 ne remplace ni n’étend l’authorization_list : il traite de l’admission des transactions à validation complexe. Les différences entre EIP-8361 et la simulation de transaction concernent le calcul mempool, pas la délégation EOA.
EIP-8361 vs abstraction native de compte EIP-7701
EIP-7701, créé le 1er mai 2024, proposait l’abstraction native de compte. Il scindait le traitement des transactions en validation, exécution et post-opération, et proposait un nouveau type de transaction EIP-2718.
Sa conception utilisait l’adresse d’entrée native 0x7701, des opcodes à rôles, une validation séparée de l’expéditeur et du paymaster, et le paiement du gas contrôlé par contrat. Il ne nécessitait pas le flux de bundler ERC-4337.
EIP-7701 a été retiré au profit d’EIP-8141. Sa spécification publiée indique la raison du retrait. L’exigence de contrats EOF ne figure pas dans la version finale.
EIP-8361 s’appuie sur le modèle de transaction frame d’EIP-8141, facilitant la propagation sécurisée de validations programmables coûteuses.
EIP-2718 fournit l’enveloppe de transaction typée utilisée par EIP-7701, EIP-7702 et EIP-8141. Il définit une transaction comme TransactionType || TransactionPayload, le type identifiant l’interprétation de la charge utile. Inclure le type dans les données signées réduit le risque de rejeu entre types.
Impact pratique sur wallets, nœuds et développeurs
Les développeurs de wallets pourraient utiliser l’admission par preuve pour les smart accounts dont l’autorisation est trop coûteuse pour la simulation mempool. Un wallet demanderait une preuve à un générateur local, un service ou un réseau distribué avant de soumettre la transaction.
Les développeurs de nœuds devraient implémenter :
- le transport de preuve peer-to-peer ;
- des clés de vérification versionnées ;
- des limites de taille de preuve ;
- des contrôles d’hypothèses et de dépendances ;
- des limites de taux par pair ;
- l’éviction des preuves obsolètes ;
- un comportement de simulation de secours.
Les développeurs de smart contracts pourraient conserver une validation spécifique sans imposer à tous les nœuds l’exécution de son coût. Cela permet les signatures post-quantiques, les politiques multi-clés, les paymasters complexes ou les permissions à base de preuve.
L’impact wallet, nœud et développeur d’EIP-8361 dépendra de la latence de génération de preuve, de l’adoption client, de l’interopérabilité et de la spécification finale d’EIP-8141.
Un trader évaluant la réaction du marché sur Gate à une future évolution Ethereum peut comparer les annonces réseau avec le graphique ETH/USDT. Le prix, le volume ou les frais de gas ne permettent pas de savoir si un EIP en brouillon a été accepté ou activé.
Considérations de sécurité et limitations
EIP-8361 introduit plusieurs considérations de sécurité.
Premièrement, la solidité de la preuve dépend du circuit STARK et de la clé de vérification. Un bug pourrait valider une affirmation incorrecte.
Deuxièmement, la vérification de preuve consomme calcul et bande passante. Des attaquants peuvent envoyer des preuves mal formées ou trop volumineuses, d’où la nécessité de contrôles préliminaires, de limites de taille et d’attribution par pair.
Troisièmement, les hypothèses peuvent devenir obsolètes. Une preuve générée sur un solde, une valeur de stockage, un hash de code ou un nonce peut ne plus s’appliquer après modification de l’état.
Quatrièmement, des politiques de nœuds incohérentes pourraient fragmenter la propagation. Différents clients peuvent choisir des plafonds de taille, de validation ou d’admission différents.
Cinquièmement, la génération de preuve peut créer une pression de centralisation si seuls quelques services disposent du matériel ou des logiciels nécessaires.
EIP-8361 ne supprime pas le coût classique des transactions. Si une transaction atteint l’exécution on-chain, son expéditeur ou payeur reste responsable du gas. Une preuve de validité réduit la redondance hors chaîne, mais n’élimine pas les frais de gas Ethereum.
Ce que ne propose pas EIP-8361
Plusieurs affirmations relèvent d’autres propositions et ne doivent pas être attribuées à EIP-8361.
EIP-8361 ne :
- prévoit pas de période de transition de 18 mois ;
- ne supprime pas de plancher de rendement staking ;
- ne plafonne pas les récompenses des validateurs ;
- ne déduit pas de récompenses à l’approche de 50 % de staking ;
- ne crée pas d’équilibre staking piloté par le marché ;
- n’introduit pas la liste d’autorisations d’EIP-7702 ;
- n’introduit pas le point d’entrée natif d’EIP-7701 ;
- ne crée pas un nouveau type de transaction EIP-2718 ;
- ne garantit pas la confidentialité ;
- ne règle pas les lots ZK-rollup ;
- ne remplace pas les preuves de fraude ;
- ne renonce pas aux droits contractuels ou assimilés des utilisateurs.
La section copyright du brouillon peut préciser que les droits d’auteur sont abandonnés sous CC0, comme pour de nombreux EIP. Cette notice concerne la proposition, non les fonds utilisateurs, droits sur les transactions ou permissions de smart contract.
Conclusion
EIP-8361 propose l’admission de transactions transportant une preuve pour le mempool public Ethereum. Un générateur de preuve exécute une validation complexe EIP-8141, génère un STARK et permet à plusieurs nœuds de vérifier le résultat sans reproduire le même calcul coûteux.
Son principal cas d’usage concerne l’autorisation programmable dépassant les limites classiques du mempool : smart accounts avancés, signatures alternatives, paymasters, contrats à logique de preuve. La conception réduit la redondance de calcul tout en maintenant la visibilité et la vérifiabilité des hypothèses d’état.
EIP-8361 ne doit pas être confondu avec le règlement ZK-rollup, les challenges par preuve de fraude, la délégation de compte EIP-7702 ou le design EIP-7701 retiré. Il reste un brouillon dont la sécurité, l’économie de preuve, l’interopérabilité et les dépendances nécessitent un développement avant tout déploiement sur Ethereum.
FAQ
EIP-8361 crée-t-il un nouveau type de transaction ?
Non. Il applique l’admission par preuve aux transactions frame EIP-8141. EIP-2718 fournit le cadre général des transactions typées, mais EIP-8361 n’introduit pas d’autre enveloppe.
Les preuves EIP-8361 sont-elles à divulgation nulle de connaissance ?
Le brouillon propose des preuves de validité STARK, mais la validité ne signifie pas confidentialité. La preuve établit la validation sous hypothèses déclarées, sans masquer toutes les données.
Une seule preuve peut-elle couvrir plusieurs transactions ?
Les systèmes de preuve peuvent agréger des calculs ou utiliser des preuves récursives, et les rollups peuvent compresser plusieurs preuves en une. EIP-8361 se concentre sur l’admission d’une transaction frame, sans standardiser l’agrégation de lots.
EIP-8361 réduit-il les frais de gas ?
Pas directement. La proposition réduit le calcul hors chaîne répété par les nœuds, mais une transaction incluse paie toujours le gas d’exécution.
En quoi EIP-8361 diffère-t-il d’EIP-7702 ?
EIP-7702 permet aux EOA de déléguer l’exécution via des tuples d’autorisation signés. EIP-8361 propose une admission par preuve pour les transactions à validation programmable coûteuse.
Avertissement
Ce contenu est éducatif et décrit des propositions techniques à l’état de brouillon, sans garantie de mise à niveau Ethereum. Les spécifications, plans d’implémentation, hypothèses de sécurité et le soutien réseau peuvent évoluer. Les développements du protocole et les données historiques ne préjugent pas des performances futures d’ETH.
