FOCIL (EIP-7805) : quand Ethereum renforce l’inclusion au cœur de sa feuille de route
Dans un écosystème où des constructeurs de blocs et des relais concentrent de plus en plus de pouvoir sur le flux des transactions, Ethereum explore des solutions pour rendre la non‑inclusion délibérée plus difficile à appliquer. Le projet FOCIL — formalisé sous EIP‑7805 — vise à donner aux validateurs des moyens protocolaires pour favoriser les chaînes qui incluent des transactions publiques valides. Ce changement, inscrit dans les discussions de la roadmap Hegota, s’inscrit dans une réflexion plus large sur la résistance à la censure, la simplicité et la compatibilité avec les preuves zéro‑connaissance.
Une ouverture pragmatique : contexte et objectifs
La direction souhaitée par certains acteurs d’Ethereum est à la fois ambitieuse et pragmatique : conserver des garanties fortes contre la censure tout en évitant une complexité difficile à auditer. Hegota structure les travaux autour de quatre axes : optimisation de l’état, consensus allégé, vérification ZK‑EVM et évolution de la machine virtuelle. FOCIL intervient précisément sur la logique de fork‑choice pour introduire une préférence explicite pour les blocs qui reprennent des transactions observées dans le mempool public.
Pourquoi l’inclusion devient un problème politique et technique
Des relayeurs centralisés et des builders privés peuvent désormais choisir quelles transactions propager ou inclure. Quand ces acteurs retardent ou filtrent certaines opérations, l’expérience utilisateur et la neutralité du réseau sont affectées. FOCIL propose de réduire la dépendance vis‑à‑vis de la « bonne volonté » des constructeurs en levant la possibilité pour les validateurs d’exiger, via des règles de fork‑choice, la présence de transactions valides vues auparavant.
Analyse technique : mécanismes et conséquences
Concrètement, FOCIL introduirait des listes d’inclusion observables qui alimentent la logique de fork‑choice. Si un validateur détecte une chaîne concurrente, il pourra privilégier celle qui intègre des transactions publiques valides, rendant la censure sélective plus coûteuse. Cet apport n’altère pas la sémantique des contrats, mais il modifie la façon dont les choix de fork sont évalués.
- Avantage pour les utilisateurs : meilleure probabilité que les transactions visibles publiquement finissent par être incluses.
- Impact pour les développeurs : pas de changement de logique contractuelle, mais prise en compte possible des nouvelles garanties d’inclusion pour l’expérience utilisateurs.
- Conséquences pour les validateurs : ajout de calculs et d’échanges réseau pour maintenir et vérifier les listes d’inclusion.
Risques et précautions
L’activation de règles de fork‑choice basées sur l’observation du mempool crée des défis : risque pour la liveness en cas d’attaques ciblées, complexité dans la chaîne d’approvisionnement MEV, et interactions réglementaires imprévues. Les équipes protocolaires insistent donc sur des spécifications multi‑client, des réseaux d’essai adversariaux et des déploiements progressifs (shadow forks, fuzzing différentiel) pour limiter les imprévus.
Zoom technique : ZK‑EVM, dual‑ISA et évolutivité
Parallèlement, la roadmap Hegota avance la vérification ZK‑EVM et la réflexion sur deux jeux d’instructions distincts : une ISA de livraison (dISA) optimisée pour l’exécution L1 et une ISA de preuve (pISA) adaptée à la génération de preuves ZK. Cette séparation permettrait d’accélérer l’innovation sur les proveurs tout en conservant la compatibilité avec le code déployé.
Débats en cours : certains plaident pour WebAssembly comme format d’exécution sur la couche de livraison, tandis que RISC‑V serait privilégié comme cible pour les systèmes de preuves. L’objectif est de limiter les coûts de migration pour les développeurs tout en maximisant l’efficience des generateurs de preuves.
Guide rapide pour les opérateurs et développeurs
- Pour les validateurs : se préparer à des charges CPU/mémoire supplémentaires et intégrer de la surveillance dédiée pour détecter les scénarios limites.
- Pour les développeurs d’apps : continuer à gérer les frais et la latence — mais considérer FOCIL comme un filet de protection contre des exclusions ciblées.
- Pour les équipes de clients : développer et tester les modifications de fork‑choice en multi‑client et via des réseaux de test hostiles.
Enjeux stratégiques et perspectives
FOCIL ne vise pas à éliminer la nécessité d’un écosystème d’infrastructures (builders, relays), mais à rééquilibrer le pouvoir en ajoutant une option protocolaire aux validateurs. Si elle est déployée prudemment, cette évolution pourrait renforcer la confiance dans la neutralité du traitement des transactions et améliorer la robustesse face aux manipulations du mempool.
À retenir
- FOCIL propose d’intégrer des règles de fork‑choice favorisant l’inclusion de transactions publiques valides.
- La mesure vise à rendre la censure économiquement coûteuse et opérationnellement fragile pour les builders.
- Des tests multi‑client, des shadow forks et des audits approfondis seront nécessaires avant toute activation.
FAQ courte
FOCIL change‑t‑il le comportement des contrats ?
Non. Les règles touchent le choix de chaîne, pas la logique d’exécution des contrats.
Est‑ce une obligation pour les validateurs ?
Les propositions actuelles privilégient une adoption progressive et optionnelle, afin de préserver la compatibilité et la sécurité.
Quel calendrier pour cette intégration ?
Le calendrier dépendra des résultats de la recherche, des implémentations multi‑client et des phases de test ; aucune date ferme n’est encore arrêtée.
La discussion autour de FOCIL illustre la tension entre robustesse du protocole et maîtrise de la complexité — un équilibre que la communauté Ethereum tente d’atteindre via des étapes mesurées et des audits rigoureux.
