Au sein de la communauté Ethereum, un nouvel EIP est en discussion pour introduire un mempool crypté au niveau du protocole, dans le but de limiter le front running, le sandwiching et les risques de censure.
Summary
Objectifs et contexte de la proposition
Le nouvel EIP vise à intégrer dans le protocole un mempool avec des transactions chiffrées jusqu’à leur inclusion dans le bloc. L’objectif est de protéger les utilisateurs contre les réordonnancements malveillants des transactions et de renforcer la résistance à la censure en temps réel, sans viser une confidentialité totale.
En effet, les transactions sont révélées publiquement une fois incluses dans la blockchain. De plus, la proposition vise à réduire les risques réglementaires pour les block builder et autres opérateurs, qui restent temporairement « aveuglés » par le contenu des opérations jusqu’à la publication des clés de décryptage.
Ce travail s’inscrit dans la lignée d’expériences précédentes comme la Shutterized Beacon Chain et l’implémentation déjà active sur la Gnosis Chain, où un mempool crypté hors protocole est présent. Selon les auteurs, le mécanisme aborde le problème historique du front running et peut atténuer les effets secondaires du MEV, tels que la centralisation des builders.
Intégration avec la feuille de route et ePBS
La proposition est conçue pour s’intégrer naturellement avec la proposer-builder separation enshrined (ePBS) prévue dans la feuille de route d’Ethereum. Dans ce cadre, la séparation structurelle entre ceux qui proposent et ceux qui construisent les blocs se combine avec une couche de chiffrement qui limite la visibilité anticipée sur le contenu des transactions.
Cela dit, les transactions en clair restent supportées, afin de garantir la continuité opérationnelle du réseau. Même en cas de dysfonctionnements ou d’échecs des fournisseurs de clés, la progression de la chaîne est préservée, évitant les blocages ou interruptions du consensus.
Structure technique : registre des key providers
Dans la couche d’exécution, un contrat dédié est introduit, le key provider registry. Tout compte peut s’enregistrer comme fournisseur de clés, obtenant un ID unique. Lors de l’enregistrement, il est nécessaire d’indiquer un contrat avec deux fonctions : décryptage et validation de clé, toutes deux paramétrées par key ID et message.
Les fournisseurs peuvent également marquer d’autres providers comme « directement de confiance », construisant ainsi un graphe de confiance direct. Un provider A est considéré comme faisant confiance à B s’il existe un chemin direct de A à B. La Beacon Chain réplique l’état du registre, de manière analogue à la gestion des dépôts.
De cette manière, l’infrastructure reste agnostique par rapport à la technologie cryptographique utilisée : des modèles basés sur le chiffrement par seuil, MPC, TEEs, chiffrement différé ou FHE sont admis. Cependant, beaucoup de ces schémas sont peu efficaces à exprimer en EVM et nécessiteraient des précompilés dédiés, laissés hors du champ de l’EIP.
Nouveau type de transaction chiffrée
Le protocole introduit un nouveau type de transaction : la transaction cryptée. Celle-ci est composée d’une enveloppe et d’un payload chiffré. L’enveloppe contient le nonce de l’enveloppe, le gaz, les paramètres de prix du gaz, l’ID du key provider, le key ID et la signature de l’enveloppe.
Le payload chiffré inclut quant à lui le nonce du payload, la valeur transférée, la calldata et la signature sur le payload. De plus, le modèle prévoit des règles précises sur l’ordonnancement dans le bloc : une transaction chiffrée avec la clé d’un provider A ne peut être précédée que par des transactions en clair, par des transactions chiffrées avec des clés de A ou de providers que A considère de confiance.
À chaque slot, lorsqu’un key provider observe le payload d’exécution publié par le builder, il recueille tous les key ID relatifs aux transactions chiffrées qui lui sont adressées. Pour chacun d’eux, il doit publier soit la clé de décryptage correspondante, soit un avis de rétention de la clé.
Rôle du Payload Timeliness Committee et attestations
Le message qui transporte les clés fait référence au hash du bloc beacon, pour empêcher les réutilisations dans les slots futurs. Les providers peuvent publier les clés dès qu’ils observent le payload d’exécution, ou retarder la publication à un moment ultérieur dans le même slot.
Les membres du Payload Timeliness Committee (PTC) doivent surveiller les clés de décryptage relatives à toutes les transactions chiffrées, identifiées par l’ID du provider et le key ID. Ensuite, ils doivent valider ces clés en utilisant la fonction de validation du registre, avec une petite limite de gaz prédéfinie pour chaque clé.
Enfin, le PTC doit attester de la présence ou de l’absence d’une clé valide pour chaque transaction chiffrée, en étendant le message d’attestation du payload avec un bitfield approprié. De cette manière, le réseau dispose d’un registre on-chain de l’état des clés dans chaque bloc.
Exécution des enveloppes et des payloads chiffrés
Lors du traitement du payload d’exécution, après toutes les transactions en clair, les enveloppes des transactions chiffrées sont exécutées en lot. Cela met à jour les nonces des signataires et paie les commissions à partir des comptes associés aux enveloppes.
Les frais couvrent la consommation d’espace de bloc utilisée par les enveloppes, les payloads décryptés et les clés, ainsi que le calcul pour le décryptage et la validation. Ensuite, les payloads sont décryptés en utilisant la clé identifiée par l’ID du key provider et le key ID, via la fonction de décryptage dans le registre.
Si le décryptage réussit, les transactions résultantes sont exécutées dans la limite de gaz indiquée sur les enveloppes et dans le respect du block gas limit. Cependant, si le décryptage ou l’exécution échouent, ou si le PTC atteste de l’absence de clé valide, le payload est sauté sans rollback sur l’enveloppe.
Choix de conception et impact sur l’ordre des transactions
L’enregistrement des key providers est délibérément agnostique par rapport au schéma cryptographique, pour garantir neutralité et faibles barrières à l’entrée. De plus, le choix d’utiliser un contrat dans la couche d’exécution fournit un moyen canonique pour définir une logique arbitraire, même si une gestion uniquement sur la consensus layer serait possible.
Le graphe de confiance entre providers répond à un besoin compétitif. Si chaque utilisateur ne faisait confiance qu’à son propre provider, les builders pourraient inclure dans chaque bloc des transactions chiffrées liées à un seul sujet, favorisant le risque de monopole. La gestion de la confiance par les providers réduit la complexité pour les utilisateurs.
De plus, la proposition segmente en fait le bloc en deux sections : transactions en clair et transactions chiffrées. Les premières sont insérées en premier, afin que les builders puissent en simuler l’exécution et appliquer les techniques actuelles de construction de blocs et d’extraction de MEV.
Garanties sur les paiements de gaz et le décryptage des transactions
Cette structure permet aux builders d’ajouter les transactions chiffrées en queue sans coûts d’opportunité. Si l’ordre était inversé, les frais pour les transactions cryptées devraient être beaucoup plus élevés pour rendre les blocs compétitifs par rapport à ceux uniquement en clair.
Pour éviter que des payloads incapables de payer le gaz soient inclus, le paiement des commissions se fait entièrement via l’enveloppe et toutes les enveloppes sont exécutées avant les payloads. Ce choix élimine les remboursements de gaz, garantissant au builder et au protocole un revenu certain au moment de la construction du bloc.
Pour simplifier, le payload inclut une signature dédiée. En alternative, moins privée mais plus efficace, on pourrait considérer le signataire de l’enveloppe comme l’expéditeur de la transaction, réduisant la complexité cryptographique.
Gestion de la rétention des clés de décryptage
Le protocole permet explicitement aux key providers de retenir les clés de décryptage selon des conditions définies par eux. Cela permet d’appliquer des règles d’accès, par exemple liées à des paiements antérieurs, ou de prévenir des attaques spécifiques, comme celle sur le key ID.
D’autre part, les clés retenues sans justification peuvent être utilisées dans des mécanismes personnalisés de slashing ou dans des métriques de fiabilité. Le protocole enregistre en effet quelles clés ont été publiées et lesquelles ne l’ont pas été, créant une base de données vérifiable pour d’éventuels incitatifs économiques off-chain.
La proposition n’introduit pas d’incitatifs économiques dans le protocole pour les providers, ni de punitions explicites pour les comportements malveillants. Cela laisse place à différents modèles d’affaires : accords avec les builders, paiements par transaction de la part des utilisateurs ou gestion comme bien public.
Hypothèses futures : chiffrement du payload d’exécution
À l’avenir, un EIP ultérieur pourrait permettre aux builders d’utiliser les mêmes clés pour chiffrer directement le payload d’exécution. Dans ce scénario, les builders pourraient publier le payload dès qu’il est construit, plutôt que d’attendre la moitié du slot, améliorant ainsi l’efficacité du p2p.
De plus, combiné à une preuve à connaissance zéro sur les clés utilisées dans le bloc, ce mécanisme permettrait d’anticiper le début de la fenêtre temporelle de révélation des clés, l’allongeant globalement. Cependant, ces extensions sont délibérément exclues de la proposition actuelle pour contenir la complexité.
Dans l’ensemble, l’EIP introduit des modifications non rétrocompatibles à la fois à la couche d’exécution et au consensus layer, nécessitant donc un hard fork coordonné pour une éventuelle activation.
Risques de sécurité et confiance dans les key providers
En ce qui concerne la sécurité, les utilisateurs doivent nécessairement faire confiance aux providers choisis pour chiffrer les transactions, tant pour éviter la publication anticipée des clés, qui permettrait le front running et le sandwiching, que pour prévenir les retards qui bloqueraient l’exécution tout en faisant payer l’enveloppe.
Cette confiance peut se baser sur des mécanismes cryptographiques, comme le chiffrement par seuil ou matériel, sur des mécanismes économiques, comme le slashing, ou sur des gouvernances de type social, par exemple avec un vote pour sélectionner des entités considérées comme fiables.
Dans une moindre mesure, celui qui envoie des transactions chiffrées doit également faire confiance aux providers utilisés pour les transactions précédentes dans le bloc. En effet, ces derniers peuvent choisir de publier ou de retenir leurs clés après avoir vu les clés relatives aux transactions suivantes, obtenant un certain degré d’influence sur l’état précédent.
Attaques potentielles : de la reorg au key ID front running
Les actions des providers peuvent devenir plus dangereuses si des schémas de « décryptage » malveillants sont adoptés, permettant des modifications ciblées du résultat en utilisant des clés opportunément construites. Dans des cas extrêmes, cela permettrait de définir directement le contenu du payload, ouvrant la voie à des formes sophistiquées de front running.
Les utilisateurs ne doivent pas faire confiance aux providers utilisés pour les transactions suivantes, car l’état précédent à leurs opérations ne dépend pas des payloads suivants. De plus, celui qui envoie des transactions en clair reste exposé à la seule confiance dans le builder, comme dans le modèle actuel.
Un autre risque concerne les reorg : les clés sont publiées avant que les transactions correspondantes ne soient finalisées. En cas de réorganisation de la chaîne, une transaction pourrait devenir publique sans être incluse. Cependant, puisque le message de clé inclut le hash du bloc, la fonction de validation peut l’invalider dans le nouveau contexte.
Mesures contre les attaques sur le key ID
Ce mécanisme n’empêche pas l’inclusion de l’enveloppe, mais bloque l’exécution du payload, prévenant le front running. Il reste cependant un vecteur d’attaque spécifique, le key ID front running, où un acteur observe une transaction chiffrée en transit et envoie une seconde transaction utilisant le même provider et key ID.
Si cette seconde opération était incluse en premier, un provider naïf révélerait la clé, exposant le contenu de la transaction originale encore non incluse. Pour atténuer l’attaque, les providers peuvent adopter le « namespacing » des key ID, ne libérant des clés que pour des ID préfixés avec l’adresse du signataire de l’enveloppe.
Étant donné qu’il est raisonnable de supposer que l’attaquant n’a pas accès à ce compte, il ne serait pas en mesure de créer une transaction avec un key ID correctement namespacé. De cette manière, le risque de key ID front running est substantiellement réduit.
Collusion entre key provider et builder
Un autre scénario de risque est la collusion entre key provider et builder. Pour construire un nouveau bloc, ces derniers doivent connaître le post-état du bloc précédent, donc toutes les clés utilisées et celles retenues, information qui devient publique une fois que le PTC a attesté.
Un provider malveillant pourrait cependant donner un préavis à un builder spécifique, lui accordant un avantage compétitif dans le démarrage de la construction du bloc. Selon l’analyse des auteurs, l’impact est limité, car l’intervalle entre la publication des attestations et la fin du slot est jugé suffisant pour le block building.
De plus, le début de la fenêtre de construction est moins critique que la fin, lorsque l’ensemble complet des transactions incluables est connu. Retarder la publication des clés augmente également le risque qu’elles ne soient pas attestées par le PTC, annulant l’avantage de l’attaquant, surtout si le nombre de transactions liées au provider collus est réduit.
Implications globales pour Ethereum
Globalement, la proposition EIP mempool crypté vise à augmenter la protection des utilisateurs contre le front running et le sandwiching, réduire la centralisation liée au MEV et améliorer la résistance à la censure en temps réel. Cependant, elle introduit de nouveaux niveaux de complexité et de dépendance à des infrastructures de gestion de clés externes.
Par rapport au statu quo, le mécanisme déplace une partie de la confiance des acteurs du marché, comme les builders, vers les key providers, qui deviennent des sujets critiques tant du point de vue technique que de la gouvernance. La discussion en cours dans la communauté déterminera si, quand et avec quelles modifications cette architecture pourra être effectivement adoptée sur le mainnet d’Ethereum.
