Ethereum Propose Preuves Partagées Et Paiements Batch

Et si demain plusieurs transactions Ethereum pouvaient mutualiser le coût d’une preuve cryptographique tout en gardant chacune son paiement et sa signature ? C’est exactement ce que propose un nouveau draft déposé récemment par un contributeur. L’idée paraît simple sur le papier, mais elle touche à des mécanismes fondamentaux de vérification, de frais et d’inclusion dans les blocs. Voici ce que l’on sait pour l’instant, sans engouement excessif ni promesse non fondée.

Un draft qui relance le débat sur les preuves partagées

Le 13 novembre 2026, Marchhill a soumis un pull request au dépôt des Ethereum Improvement Proposals. Ce document n’est pas encore un EIP numéroté. Il reste à l’état de brouillon, sans fil de discussion dédié officiel et sans date d’activation envisagée sur le réseau principal. Pourtant, son contenu attire déjà l’attention car il s’attaque à un point sensible : le coût et la rigidité de la vérification des preuves dans un contexte de batch.

Le texte propose d’activer le schéma LEANSTARK_SCHEME réservé dans l’EIP-8288 et d’y ajouter des règles précises pour les lots sponsorisés. L’objectif affiché est de permettre qu’une même preuve puisse couvrir plusieurs revendications tout en laissant chaque transaction membre conserver son propre paiement et sa propre signature. Un constructeur de blocs pourrait alors inclure n’importe quel sous-ensemble valide sans obliger les participants restants à signer de nouveau.

Cette séparation entre le travail de preuve et le travail de paiement constitue le cœur de la proposition. Elle s’inscrit dans la continuité des discussions autour des preuves agrégées et des signatures hors processus d’exécution principal. L’EIP-8288, porté notamment par Vitalik Buterin et Thomas Coratger, avait déjà ouvert la voie à une agrégation de preuves cryptographiques en dehors de l’exécution classique. Le draft de Marchhill va plus loin en précisant les mécanismes de paiement et de sélection de sous-ensembles.

Ce que change concrètement le partage des preuves

Dans le modèle classique, chaque transaction qui nécessite une vérification cryptographique complexe doit souvent porter seule le poids de cette vérification. Avec un batch partagé, plusieurs revendications peuvent s’appuyer sur une même preuve. Le sponsor du lot paie pour chaque feuille de preuve retenue. Les transactions membres, elles, paient uniquement selon les revendications qu’elles soumettent.

Le nonce de chaque transaction et son reçu d’exécution restent attachés à la transaction individuelle. Le partage du travail de preuve ne fusionne donc pas les historiques. Un utilisateur dont la transaction est prête à être incluse n’a pas besoin de produire une nouvelle signature simplement parce que d’autres membres du groupe initial n’ont pas été retenus. Cette flexibilité est présentée comme un gain d’efficacité pour les constructeurs de blocs.

Les preuves récursives servent à authentifier les sources utilisées dans le lot. Le draft insiste sur la distinction entre deux types de travail : établir que les revendications sont valides d’un côté, et confirmer que les paiements nécessaires les accompagnent de l’autre. Les réclamations bénéficiant d’une réduction et les paiements du sponsor iraient directement aux constructeurs de blocs. Les preuves ordinaires portant sur une seule déclaration resteraient éligibles au mempool public.

Le lien avec l’EIP-8288 et le schéma leanSTARK

L’EIP-8288 pose les bases d’une agrégation de signatures et de preuves cryptographiques en dehors du chemin d’exécution principal. Les transactions indiquent les déclarations qu’elles souhaitent voir vérifiées. Une STARK récursive établit ensuite leur validité au niveau du bloc. Les STARK sont des preuves qui démontrent qu’un calcul a été correctement effectué sans obliger chaque vérificateur à le refaire entièrement. La récursion permet à une preuve d’en vérifier d’autres et de combiner leurs résultats.

Dans sa version actuelle, l’EIP-8288 réserve le schéma générique leanSTARK sans l’autoriser encore pleinement dans les cadres de dépendances. Le draft de Marchhill propose précisément d’ouvrir cette voie. Il remplace également la simple déclaration basée sur un hachage de données par un condensé stable représentant une liste de revendications. Cette modification vise à rendre l’identité des preuves plus robuste et plus exploitable dans un contexte de lots.

Le design s’inscrit dans une lignée de réflexions déjà présentes dans la communauté. Vitalik Buterin avait notamment souligné l’intérêt de traiter les cryptographies complexes via des preuves agrégées. Le draft de Marchhill ne se contente pas de reprendre cette idée : il propose une organisation concrète des paiements et de la sélection des sous-ensembles.

La séparation claire entre la validation des revendications et la confirmation des paiements associés permettrait une plus grande flexibilité sans compromettre l’intégrité des transactions individuelles.

Synthèse du draft Marchhill

Les frais proposés restent provisoires

Le document fournit des chiffres indicatifs. La vérification native serait facturée environ 15 400 unités de gaz. La vérification générique ordinaire monterait à 572 000 unités. Une part intrinsèque de preuve serait fixée à 5 100 unités, un paiement de feuille à 675 000 unités et une revendication de lot à 4 200 unités. Ces montants ne constituent en aucun cas un barème définitif. Ils doivent encore être calibrés conjointement et validés par des mesures de performance réelles.

Le draft justifie le coût plus élevé des paiements de feuille par le travail supplémentaire lié à la liaison des paiements. Les revendications et les paiements n’entraîneraient pas de part intrinsèque de preuve additionnelle. L’ensemble reste donc sujet à ajustement. Aucune économie garantie pour l’utilisateur final n’est annoncée à ce stade.

Des contrôles de ressources accompagnent ces propositions de frais. Une limite provisoire de 16 384 dépendances distinctes par bloc est envisagée, indépendamment du gaz. Une règle de correspondance pour les listes d’inclusion est également mentionnée. Une feuille pourrait contenir jusqu’à 256 revendications et une étape de preuve jusqu’à 16 entrées. Ces plafonds ne s’appliquent pas à l’échelle de tout le bloc.

Les conditions d’activation restent strictes

Avant toute activation, le draft exige des mesures portant sur le calendrier complet de traitement, la réparation tardive des sponsors et les charges par preuve qui doivent tenir dans les limites de gaz des transactions, y compris les frais généraux. Le matériel de référence distingue les résultats mesurés sur un nœud individuel ou une machine unique des projections modélisées avec seize workers. Les écarts de performance restants doivent être documentés.

Un point de vigilance est clairement mentionné : un sponsorship invalidé pourrait faire perdre du travail à un constructeur de blocs. Le gaz d’inclusion ne rembourserait pas ce travail perdu. Les constructions de commitment concrètes et les encodages restent définis dans la spécification du système de preuves épinglée. Aucun nouveau message réseau n’est introduit par la proposition.

Cette prudence technique explique pourquoi le document reste à l’état de draft. Il ne s’agit pas d’une mise à niveau annoncée pour le mainnet. Il s’agit d’une contribution ouverte qui devra encore passer par des discussions, des calibrations et des tests de performance complets avant d’espérer un éventuel chemin vers l’activation.

Pourquoi cette proposition arrive maintenant

Ethereum a multiplié ces dernières années les efforts pour réduire le coût des transactions et améliorer la scalabilité. Les preuves de type STARK et les mécanismes d’agrégation font partie des outils étudiés pour alléger la charge de vérification. Dans ce contexte, permettre à plusieurs transactions de partager une même preuve tout en conservant des paiements distincts apparaît comme une étape logique.

Le marché des rollups et des solutions de couche 2 repose déjà largement sur la capacité à agréger des preuves. Un mécanisme plus flexible côté couche 1 pourrait faciliter certains cas d’usage où des lots de transactions doivent être vérifiés ensemble sans pour autant fusionner les responsabilités de paiement. Les constructeurs de blocs y verraient potentiellement une source de revenus plus prévisible via les paiements de sponsors.

Il ne faut cependant pas surestimer l’impact immédiat. Tant que les mesures de performance n’ont pas été publiées et validées, les chiffres de gaz restent indicatifs. Tant qu’aucun numéro d’EIP n’est attribué et qu’aucun consensus large n’émerge, le draft reste une proposition parmi d’autres. L’historique d’Ethereum montre que de nombreuses idées passent par de longues phases de refinement avant d’éventuellement aboutir.

Les implications pour les utilisateurs et les développeurs

Pour un utilisateur final, l’intérêt principal serait une possible baisse du coût de certaines opérations qui nécessitent aujourd’hui des preuves coûteuses. Si un sponsor prend en charge une partie du travail de preuve, le coût marginal pour chaque transaction membre pourrait diminuer. Cette hypothèse reste cependant conditionnée à la calibration finale des frais et à l’adoption réelle du mécanisme.

Pour les développeurs de protocoles et d’applications, la séparation claire entre preuve et paiement ouvre des possibilités de conception nouvelles. On peut imaginer des services qui sponsorisent des lots de preuves pour des utilisateurs en échange d’une commission, ou des mécanismes où des ensembles de transactions liées partagent une preuve sans perdre leur individualité. La préservation des nonces et des reçus est ici un point important : elle maintient la traçabilité et la compatibilité avec les outils existants.

Les constructeurs de blocs, quant à eux, pourraient voir apparaître une nouvelle source de revenus via les paiements de sponsors et les revendications réduites. En contrepartie, ils prendraient le risque d’un sponsorship invalidé qui ne serait pas compensé par le gaz d’inclusion. Cette asymétrie de risque est explicitement reconnue dans le draft.

Les limites et les zones d’ombre encore présentes

Plusieurs éléments restent volontairement ouverts. Les frais exacts ne sont pas figés. Les limites de ressources sont provisoires. Les constructions concrètes de commitment dépendent d’une spécification externe. Aucun nouveau message réseau n’est introduit, ce qui simplifie l’intégration mais peut aussi limiter certains cas d’usage futurs.

Le draft exige des mesures de performance complètes avant activation. Cela signifie que même si l’idée est techniquement solide, le chemin jusqu’à une éventuelle inclusion dans un hard fork reste long. Les résultats mesurés sur une seule machine ou un seul nœud devront être confrontés à des projections multi-workers et aux conditions réelles du réseau.

Enfin, le fait que le document supersède un précédent pull request montre que le sujet évolue encore. Les discussions à venir pourront modifier significativement les paramètres proposés aujourd’hui. Il est donc prudent de considérer ce draft comme une étape de réflexion plutôt que comme une feuille de route figée.

Comment situer cette proposition dans l’évolution d’Ethereum

Ethereum a toujours progressé par couches successives d’améliorations. Les preuves agrégées, les mécanismes de récursion et les optimisations de gaz font partie de cette trajectoire. Le draft de Marchhill s’inscrit dans cette continuité en cherchant à rendre plus flexible l’utilisation des preuves complexes tout en préservant les propriétés individuelles des transactions.

Il ne s’agit pas d’une révolution isolée. Il s’agit plutôt d’un raffinement possible d’un cadre déjà esquissé par l’EIP-8288. Si les mesures de performance sont concluantes et si la communauté valide l’approche, le mécanisme pourrait un jour faciliter certains lots de transactions coûteuses en vérification. Dans le cas contraire, il restera une contribution utile à la réflexion collective.

Pour l’instant, la proposition reste ouverte. Elle invite les développeurs, les chercheurs et les opérateurs de nœuds à examiner les chiffres, à tester les hypothèses et à documenter les écarts. C’est précisément ce processus d’examen collectif qui a permis à Ethereum de progresser de manière relativement prudente malgré la complexité croissante de son protocole.

Ce qu’il faut retenir à ce stade

Un contributeur nommé Marchhill a déposé un draft visant à activer le schéma leanSTARK réservé dans l’EIP-8288 et à y ajouter des règles de paiement pour les lots sponsorisés. L’idée centrale est de permettre qu’une preuve soit partagée entre plusieurs revendications tout en laissant chaque transaction conserver son paiement et sa signature. Un constructeur de blocs pourrait inclure n’importe quel sous-ensemble valide sans nouvelle signature des membres restants.

Les frais proposés sont purement indicatifs. Les limites de ressources sont provisoires. L’activation est conditionnée à des mesures de performance complètes. Aucun numéro d’EIP n’a encore été attribué et aucune date de déploiement n’est envisagée. Le document supersède un précédent pull request et reste en cours de développement.

Cette proposition s’inscrit dans une réflexion plus large sur la manière d’alléger le coût de la vérification cryptographique tout en préservant l’individualité des transactions. Elle mérite d’être suivie, mais elle ne doit pas être interprétée comme une annonce de mise à niveau imminente. Le travail de calibration, de test et de consensus reste entièrement devant nous.

Dans les semaines et mois à venir, les discussions techniques autour de ce draft permettront de clarifier si les gains attendus en flexibilité et en coût se confirment dans des conditions réelles. En attendant, le document offre déjà une vision claire d’une possible évolution des mécanismes de preuve et de paiement sur Ethereum. Une évolution qui, si elle aboutit, pourrait simplifier certains cas d’usage sans bouleverser les fondamentaux du protocole.

Le plus important reste de garder à l’esprit le caractère provisoire de l’ensemble. Les chiffres de gaz, les plafonds de dépendances et les règles de sélection de sous-ensembles sont des points de départ. Ils évolueront probablement au fil des retours de la communauté et des résultats des bancs d’essai. C’est ainsi que progressent la plupart des améliorations significatives sur Ethereum : par itérations successives, mesures concrètes et discussions ouvertes.

Pour les observateurs du réseau, ce draft illustre une fois de plus la densité du travail de recherche et de spécification qui se poursuit en arrière-plan. Derrière les fluctuations de prix et les annonces médiatiques, des contributeurs continuent d’explorer des pistes pour rendre la vérification plus efficace et les lots plus flexibles. Que cette piste précise aboutisse ou non, elle enrichit le débat et force à préciser les contraintes de performance et de sécurité.

Enfin, il convient de souligner que la préservation des nonces et des reçus individuels n’est pas un détail. Elle garantit que le partage de la preuve n’efface pas l’identité de chaque transaction. Dans un environnement où la traçabilité et la compatibilité avec les outils existants restent essentielles, ce choix de conception apparaît particulièrement pertinent. Il montre que l’on peut chercher des gains d’efficacité sans renoncer aux propriétés qui font la force du modèle transactionnel d’Ethereum.

Le draft de Marchhill n’est donc pas seulement une proposition technique. C’est aussi un rappel que l’évolution du protocole se joue souvent dans des détails de paiement, de signature et de sélection de sous-ensembles. Des détails qui, une fois bien calibrés, peuvent avoir des effets systémiques sur le coût et la fluidité des opérations. Pour l’heure, le travail continue. Les mesures de performance diront si l’idée mérite de passer à l’étape suivante.