Comment les preuves de validité des transactions opèrent-elles dans le cadre de l’EIP-8361 ?

EIP-8361 autorise une transaction frame EIP-8141 à soumettre un STARK succinct avec sa charge utile peer-to-peer, permettant aux nœuds de confirmer que le préfixe de validation a approuvé la transaction selon les hypothèses d’état déclarées. Au lieu d’exécuter à plusieurs reprises le même mécanisme, les nœuds vérifient une seule preuve, ses dépendances et les conditions d’état pertinentes, ce qui peut réduire le coût de vérification pour une logique de compte complexe. Les sections suivantes détaillent comment les transactions valides obtiennent des preuves, comment les nœuds détectent les transactions obsolètes ou frauduleuses, pourquoi la preuve fait référence à l’état valide précédent sans devenir une racine Merkle, et pourquoi elle disparaît après inclusion dans un bloc.

L’explication distingue aussi EIP-8361 des deux principaux types de sécurité rollup : les preuves ZK, qui établissent la validité avant l’acceptation, et les preuves de fraude, qui nécessitent un processus de contestation pour démontrer qu’une transition invalide s’est produite. Elle clarifie également les limites liées aux signatures ECDSA, à la sécurité quantique, aux risques potentiels liés aux ordinateurs quantiques et au rôle plus restreint de la proposition par rapport aux solutions de scalabilité. Cette analyse technique s’adresse aux équipes de portefeuilles, aux développeurs clients, aux opérateurs de provers et aux utilisateurs qui évaluent comment les transactions porteuses de preuve pourraient permettre une validation Ethereum plus complexe, alors qu’EIP-8361 demeure une proposition de réseau à l’état de draft, sans être une règle de consensus active.

Principaux points à retenir

• EIP-8361 autorise une transaction frame EIP-8141 à transporter une preuve d’admission en tant que métadonnée de transport off-chain.

• Un prover off-chain exécute le préfixe de validation selon les hypothèses déclarées et produit un STARK lié à la transaction, au payeur, aux dépendances et aux conditions de validité.

• Un nœud récepteur effectue des vérifications stateless, valide la preuve et les dépendances, puis compare les hypothèses avec son état Ethereum actuel.

• Une preuve valide permet l’admission au mempool sans répéter la simulation complète du préfixe de validation.

• La preuve ne détermine pas la validité du bloc, n’altère pas l’exécution et ne fait pas partie de l’état permanent d’Ethereum. Elle est supprimée après inclusion ou retrait du mempool.

Qu’est-ce qu’une preuve de validité de transaction EIP-8361 ?

EIP-8361 définit une méthode d’admission proposée pour les transactions créées sous EIP-8141. Son objectif est limité : rendre certains calculs coûteux suffisamment abordables pour que les nœuds puissent les évaluer avant de les transmettre dans le mempool public.

Une transaction frame EIP-8141 peut intégrer une logique programmable déterminant si l’expéditeur autorise la transaction, qui paiera l’exécution et si les conditions spécifiées sont satisfaites. Cette logique apparaît dans un préfixe de validation exécuté avant les frames d’exécution ordinaires de la transaction.

En admission simulée normale, chaque nœud récepteur peut devoir exécuter ce préfixe pour déterminer si la transaction doit entrer dans son mempool. EIP-8361 propose une autre option. Un prover exécute le préfixe une fois off-chain et crée une preuve cryptographique montrant qu’il aboutit à un résultat APPROVE et à un payeur identifié.

La transaction et la preuve voyagent ensemble. Le nœud vérifie la preuve au lieu de reconstruire l’ensemble du processus de validation.

Le framework EIP-8361 concerne donc l’admission au mempool avec preuve, tandis que le processus de validation mempool EIP-8361 détermine comment les nœuds récepteurs décident d’accepter, de conserver, de mettre en attente ou de retirer ces transactions.

Au 6 août 2026, EIP-8361 est présenté dans le draft pull request #12075 comme une proposition Standards Track Networking. Il n’introduit pas de nouveau type de transaction ni ne modifie le consensus Ethereum.

Comment fonctionne la preuve cryptographique EIP-8361 ?

La preuve couvre une déclaration spécifique, sans prétendre que tous les résultats d’exécution futurs sont connus.

De façon simplifiée, le prover doit démontrer que :

Le préfixe de validation de la transaction T, évalué selon les hypothèses et dépendances déclarées, suit les règles de trace EIP-8141 et se termine par APPROVE et le payeur P, sous réserve des conditions déclarées.

Les entrées publiques proposées lient la preuve à cinq éléments :

Ce lien est crucial car une preuve valide pour une transaction ne peut pas simplement être attachée à une autre transaction avec des données, des dépendances, des conditions ou des informations de payeur différentes.

Le témoin privé inclut les informations nécessaires pour évaluer le préfixe, y compris le contenu de la liste de dépendances déclarée. La preuve résultante démontre la correction de ce calcul sans obliger chaque nœud récepteur à le répéter.

EIP-8361 propose actuellement de réutiliser le format de preuve et la machine de vérification d’entrée associés à EIP-8288. L’EIP mentionne les STARKs car ils peuvent représenter un calcul important avec une preuve succincte et n’exigent pas que chaque vérificateur reproduise la charge de travail originale.

Comment le vecteur d’hypothèses est-il utilisé dans la validation de transaction ?

Une preuve cryptographique peut montrer qu’un calcul était correct pour des entrées particulières, mais un nœud mempool doit encore déterminer si ces entrées correspondent à l’état Ethereum actuel.

EIP-8361 traite cela avec un vecteur d’hypothèses, représenté par A. Il liste chaque valeur d’état lue par le préfixe de validation. Les entrées proposées incluent une adresse, une clé de stockage ou une référence de solde, un type de comparaison et une valeur.

Deux types de comparaison sont définis :

• Les hypothèses EQ exigent que la valeur d’état actuelle soit égale à la valeur déclarée dans la preuve.

• Les hypothèses GEQ exigent que la valeur d’état actuelle soit supérieure ou égale à un seuil déclaré.

Une entrée EQ exacte peut convenir pour un hash de code, un nonce ou une branche de stockage dont la signification change à chaque modification de la valeur sous-jacente. Une entrée GEQ est plus utile pour des exigences monotones, comme vérifier qu’un payeur dispose d’assez de fonds pour un préfinancement.

Par exemple, supposons que le préfixe de validation d’un smart account n’approuve une transaction que si le solde du paymaster est au moins de 0,2 ETH. Le prover peut enregistrer une hypothèse GEQ avec un seuil de 0,2 ETH. Un nœud peut continuer à considérer la preuve comme applicable tant que le solde est de 0,2 ETH ou plus. Il n’a pas besoin d’une nouvelle preuve à chaque augmentation du solde au-dessus de ce seuil.

Cette conception évite d’ancrer la preuve à une racine d’état complète ou d’exiger une preuve Merkle volumineuse pour l’ensemble de l’état Ethereum. Le circuit évalue le préfixe de validation selon les valeurs déclarées, tandis que le nœud vérifie ces valeurs par rapport à son état actuel.

Comment fonctionnent les preuves de validité de transaction sous EIP-8361 ?

Le processus de validation de transaction proposé suit une série ordonnée de vérifications.

1. Exécuter les vérifications stateless. Le nœud vérifie la validité intrinsèque de la transaction et confirme que la liste des dépendances ou des signatures est bien formée. Une transaction mal formée est rejetée avant la vérification coûteuse de la preuve.

2. Vérifier la preuve d’admission. Le nœud vérifie le STARK avec la clé de vérification désignée. Un échec signifie que le calcul de validation revendiqué n’a pas été établi.

3. Vérifier les dépendances externes. La preuve peut supposer que des signatures ou d’autres dépendances déclarées sont valides. Le nœud vérifie ces dépendances séparément et confirme que leur liste correspond au hash de dépendance engagé.

4. Vérifier les conditions de validité. Le nœud évalue les conditions déclarées, qui peuvent inclure des deadlines, des fenêtres de slot ou d’epoch, des plages d’expiration ou des exigences de nonce.

5. Comparer les hypothèses avec l’état live. Chaque entrée EQ est vérifiée pour l’égalité, chaque entrée GEQ est testée par rapport à son seuil.

6. Admettre la transaction. Lorsque toutes les vérifications réussissent, le nœud peut accepter et propager la transaction sans simuler son préfixe de validation complet.

Cette séquence empêche une preuve de contourner les vérifications structurelles, de signature, d’état ou de timing ordinaires. Elle modifie la méthode de calcul utilisée pour décider de l’admission, mais pas les exigences de validité sous-jacentes de la transaction.

Que se passe-t-il lorsque l’état Ethereum change ?

L’admission au mempool n’est pas une garantie permanente car l’état Ethereum continue d’évoluer après l’entrée d’une transaction dans le pool.

Sous EIP-8361, un nœud revérifie les conditions de validité et le vecteur d’hypothèses lorsqu’un nouveau bloc modifie la tête de la chaîne. Il n’a pas besoin de régénérer la preuve, de réexécuter le préfixe de validation ni de revérifier la même preuve. La preuve précédemment vérifiée reste un résultat mis en cache sur la fonction de validation selon ses entrées déclarées.

Un échec EQ invalide normalement la preuve car une entrée exacte a changé. Le nœud doit évincer la transaction sauf si l’expéditeur crée une nouvelle preuve ou si la transaction est admissible en simulation ordinaire.

Un échec GEQ peut être traité différemment. Le nœud peut mettre la transaction en attente au lieu de la retirer complètement. Si le payeur ou le paymaster reçoit plus de fonds, le nœud peut réactiver la transaction en vérifiant à nouveau le seuil.

Cette distinction fait du vecteur d’hypothèses plus qu’un engagement Merkle sur un état historique. Il définit quels changements d’état invalident réellement l’approbation et lesquels restent compatibles.

Pourquoi la preuve est-elle supprimée après inclusion dans le bloc ?

La preuve EIP-8361 n’est requise que pour l’admission et la propagation dans le mempool public. Ce n’est pas la preuve faisant autorité que la transaction incluse a produit la bonne transition d’état.

Une fois qu’un validateur inclut la transaction dans un bloc, Ethereum la traite par l’exécution protocolaire ordinaire. L’EVM exécute le préfixe de validation et les frames restants selon l’état canonique du bloc. Les clients de consensus déterminent la validité du bloc selon les règles Ethereum normales.

Par conséquent, la preuve d’admission :

• n’est pas placée dans le bloc ;

• n’est pas ajoutée à la calldata de la transaction ;

• n’apparaît pas dans le reçu ;

• ne devient pas partie d’un arbre Merkle ou d’une racine d’état ;

• ne crée pas de changement d’état permanent on-chain ;

• n’a pas besoin d’être conservée après inclusion ou retrait de la transaction.

La suppression évite un coût calldata permanent et la croissance de l’état pour une information ayant déjà rempli son rôle réseau. La transaction elle-même reste on-chain, mais son enveloppe de preuve temporaire disparaît.

Système de preuve EIP-8361 vs. preuves de validité ZK-rollup

EIP-8361 utilise une technologie de preuve cryptographique, mais sa preuve d’admission ne doit pas être confondue avec les preuves de validité utilisées par les ZK rollups.

Les ZK rollups utilisent généralement des ZK-SNARKs ou ZK-STARKs pour prouver la validité des lots de transactions. Une fois la preuve acceptée par le contrat Layer 1, le rollup peut finaliser la transition d’état associée sans attendre la période de contestation par preuve de fraude utilisée par les rollups optimistes.

EIP-8361 ne prouve pas un lot L2, n’autorise pas des retraits immédiats de rollup ni ne garantit qu’une chaîne L2 ne puisse jamais entrer dans un état invalide. Sa preuve est un artefact réseau temporaire relatif à la validation pré-inclusion.

De même, bien que les preuves zero-knowledge puissent vérifier une déclaration sans révéler tous les témoins sous-jacents, EIP-8361 n’est pas principalement une proposition de confidentialité. « Preuve succincte » et « zero knowledge » sont des propriétés liées mais non interchangeables.

Les retraits Layer 2 vers Layer 1 peuvent être plus rapides avec les preuves de validité car les ZK rollups n’exigent pas la période de contestation par preuve de fraude utilisée par les rollups optimistes. Le temps de retrait final dépend toujours de la génération de preuve, de la vérification Layer 1, des règles de bridge et de la finalité Ethereum. EIP-8361 ne fournit pas ce mécanisme de retrait ; sa preuve soutient l’admission au mempool d’une transaction frame EIP-8141 individuelle, pas le règlement d’un lot de transactions Layer 2.

Comment fonctionnent les preuves de fraude dans les rollups optimistes ?

Les preuves de fraude reposent sur un mécanisme de sécurité différent. Un rollup optimiste accepte initialement une transition d’état proposée et permet aux contestataires de démontrer une fraude pendant une période de contestation. Selon l’implémentation, résoudre un litige peut nécessiter plusieurs tours ou une preuve d’exécution réduite.

EIP-8361 cherche à établir la déclaration d’admission requise avant que la transaction ne soit acceptée dans la classe de mempool concernée. Il n’y a pas de période de contestation post-admission où un autre participant prouve que le résultat du préfixe était frauduleux.

La différence clé est le timing et la portée :

• Une preuve de validité démontre une déclaration spécifiée avant l’acceptation.

• Une preuve de fraude permet une déclaration optimiste sauf si elle est contestée avec succès.

• Une preuve d’admission EIP-8361 concerne la politique mempool.

• Une preuve de fraude rollup concerne la validité d’une transition d’état L2.

Les compromis techniques entre exécution EVM répétée et vérification succincte sont abordés dans EIP-8361 vs simulation de transaction, y compris là où le coût de génération de preuve remplace le coût de simulation côté nœud.

EIP-8361, validation complexe de comptes et sécurité post-quantique

Les comptes programmables peuvent utiliser une autorisation multi-signature, des rotations de clés, des règles de récupération, des schémas de signature non standards, des candidats à la signature post-quantique, des politiques de dépenses ou des vérifications zero-knowledge coûteuses en gas. Une partie de cette logique peut être valide mais trop coûteuse pour que chaque nœud mempool la simule en toute sécurité.

EIP-8361 cherche à préserver la propagation publique des transactions pour ces comptes en rendant la validation coûteuse pour le prover mais relativement abordable pour chaque vérificateur. Il peut aussi réduire la pression à déplacer une autorisation complexe dans la phase d’exécution, où une vérification échouée pourrait devenir une transaction revertée payante et enregistrée publiquement.

Ce mécanisme ne rend pas chaque smart contract sécurisé ni n’établit une sécurité post-quantique complète. Un STARK peut éviter certains postulats des systèmes de preuve basés sur courbe elliptique, mais la transaction peut toujours dépendre de clés publiques, de schémas de signature, d’implémentations client, de code portefeuille ou de clés de vérification avec des propriétés de sécurité distinctes.

Les responsabilités résultantes pour les créateurs de transactions, portefeuilles, provers et clients diffèrent considérablement, comme résumé dans l’impact EIP-8361 sur portefeuille, nœud et développeur.

Par exemple, un trader évaluant si les développements d’abstraction de compte Ethereum influencent le sentiment du marché peut comparer les étapes de la proposition avec le graphique du marché ETH/USDT, bien que l’évolution des prix ne puisse confirmer qu’un EIP draft a été implémenté ou adopté.

Risques et limitations

EIP-8361 reste un draft précoce, donc son format de preuve, ses limites, ses dépendances, sa terminologie et ses détails d’implémentation peuvent évoluer avant la standardisation.

Le mécanisme introduit aussi plusieurs risques techniques :

Concentration de génération de preuve : Produire un STARK peut exiger un logiciel spécialisé et un calcul important. Si seuls quelques services peuvent générer des preuves efficacement, les portefeuilles risquent de dépendre d’une infrastructure de prover centralisée.

Pression de déni de service : La vérification de preuve est moins coûteuse que la répétition du calcul original, mais elle n’est pas gratuite. Les clients doivent fixer des limites de taille de preuve, des limites de taux peer et une attribution des échecs pour empêcher les attaques par inondation de nœuds avec des preuves invalides ou surdimensionnées.

Complétude des hypothèses : La preuve n’est significative que si le vecteur d’hypothèses contient chaque état lu par le préfixe de validation. Un bug de circuit ou de client omettant une dépendance pourrait produire des décisions d’admission incorrectes.

Obsolescence de l’état : Une preuve peut rester cryptographiquement correcte alors que ses conditions déclarées ne correspondent plus à l’état actuel. Les nœuds doivent continuer à revérifier A et C tant que la transaction reste en pool.

Aucune garantie d’exécution : L’admission au mempool ne garantit ni l’inclusion dans un bloc ni une exécution finale réussie. Une autre transaction peut modifier le nonce, le solde, le code, le stockage ou tout état pertinent de l’expéditeur avant inclusion.

Complexité d’implémentation : Les clients, portefeuilles et systèmes de prover doivent s’accorder sur l’encodage des preuves, les clés de vérification, la gestion des dépendances, le comportement peer et les règles de revalidation. Des implémentations incohérentes pourraient fragmenter la propagation des transactions.

EIP-8361 est-il aussi la proposition Tapered Issuance Burn ?

Certaines discussions initiales ont associé le numéro EIP-8361 à une proposition de politique monétaire Ethereum distincte appelée Tapered Issuance Burn. Cette proposition a ensuite été identifiée comme EIP-8363, tandis qu’EIP-8361 concerne les Proofs de validité de transaction dans la catégorie networking. Les deux propositions sont indépendantes : EIP-8361 traite l’admission au mempool basée sur preuve, tandis que Tapered Issuance Burn modifie l’économie des récompenses de consensus selon le solde de staking actif.

Conclusion

Les proofs de validité de transaction EIP-8361 déplacent la partie coûteuse de la validation de transaction programmable hors de chaque nœud récepteur vers un prover off-chain. Le STARK résultant lie une transaction EIP-8141 à son résultat d’approbation, au payeur, aux dépendances, aux conditions et aux hypothèses d’état, permettant aux nœuds de vérifier une déclaration concise avant l’admission au mempool.

Le mécanisme est particulièrement utile lorsqu’un smart account possède une logique de validation légitime dépassant les limites pratiques de simulation. Sa contrainte principale est tout aussi importante : la preuve ne s’applique qu’à l’admission au niveau réseau. Ethereum exécute toujours la transaction normalement à l’inclusion, et la preuve temporaire est supprimée car elle n’a aucun rôle de consensus ou on-chain par la suite.

FAQ

Comment les ZK rollups utilisent-ils les preuves de validité ?

Les ZK rollups traitent les transactions off-chain, les regroupent en lots et calculent une preuve de validité pour chaque lot. La preuve, souvent construite avec des ZK-SNARKs, des ZK-STARKs ou des engagements polynomiaux, permet à un contrat Ethereum de vérifier que la transition d’état résultante est correcte sans rejouer chaque transaction.

Les preuves de validité garantissent-elles qu’une chaîne L2 ne peut pas devenir invalide ?

Les preuves de validité empêchent un vérificateur L1 d’accepter une transition d’état invalide lorsque le circuit, le contrat de vérification, la cryptographie et l’implémentation fonctionnent correctement. Elles n’éliminent pas les risques liés au code défectueux, à la disponibilité des données, aux bridges, aux sequencers, à la gouvernance ou aux contrôles de mise à jour.

Pourquoi les retraits ZK-rollup sont-ils généralement plus rapides ?

Les ZK rollups peuvent finaliser les retraits après soumission et vérification de la preuve de validité, sans attendre la période de contestation par preuve de fraude utilisée par les rollups optimistes. Les retraits peuvent toujours dépendre de la génération de preuve, de la soumission du lot, des règles de bridge et de la finalité Ethereum, donc « immédiat » ne signifie pas toujours instantané.

En quoi les preuves de validité diffèrent-elles des preuves de fraude ?

Les preuves de validité établissent la validité de la transaction avant qu’une transition d’état soit acceptée. Les preuves de fraude fonctionnent selon un modèle optimiste où une transition peut être acceptée temporairement et contestée plus tard ; de nombreux rollups optimistes utilisent une période de contestation d’environ sept jours, bien que la durée exacte varie.

Les preuves zero-knowledge cachent-elles toujours les données de transaction ?

Non. Les preuves zero-knowledge peuvent vérifier une déclaration sans révéler le témoin privé, mais la confidentialité dépend des entrées cachées. De nombreux ZK rollups utilisent les preuves ZK principalement pour la vérification scalable des transactions plutôt que pour des transactions entièrement privées.

Quelle est la différence entre les ZK-SNARKs et les ZK-STARKs ?

Les ZK-SNARKs produisent généralement des preuves petites avec un coût de vérification faible, bien que de nombreux designs nécessitent un setup de confiance. Les ZK-STARKs ne nécessitent pas de setup de confiance et sont souvent considérés comme plus résistants aux attaques futures par ordinateur quantique, mais leurs preuves sont souvent plus volumineuses.

Que vérifie une preuve Merkle ?

Une preuve Merkle confirme que des données spécifiques appartiennent à un ensemble représenté par une racine Merkle sans révéler ni télécharger l’ensemble complet. Elle prouve l’inclusion ou l’exclusion, pas la validité d’un lot de transactions ou d’une transition d’état complète.

Les preuves de validité réduisent-elles la consommation de ressources on-chain ?

Oui, elles peuvent compresser un calcul off-chain important en une seule preuve moins coûteuse à vérifier on-chain que de rejouer chaque transaction. Les économies réelles dépendent du coût de vérification de la preuve, de la taille du lot, de l’utilisation de calldata ou de blob et de l’implémentation du rollup.

Les preuves de validité réduisent-elles le risque d’attaque 51 % ?

Pas directement. Les preuves de validité protègent la validité des transitions d’état Layer 2 vérifiées, tandis qu’une attaque 51 % concerne le contrôle du consensus Ethereum et le choix de fork. Les deux mécanismes traitent des risques de sécurité différents.

Les proofs EIP-8361 sont-elles identiques aux proofs ZK-rollup ?

Non. Les proofs ZK-rollup valident des lots de transactions Layer 2 et soutiennent la finalité d’état et les retraits. Les proofs EIP-8361 soutiennent l’admission au mempool de transactions frame EIP-8141 individuelles, restent hors du bloc et sont supprimées après inclusion ou retrait.

Avertissement

Ce contenu est éducatif et décrit une proposition Ethereum draft dont la spécification et le statut d’implémentation peuvent évoluer. Il ne constitue pas un conseil financier, de sécurité ou de déploiement logiciel. Les développeurs doivent vérifier le texte EIP le plus récent et les exigences client avant de construire des systèmes en production.