Dans le monde de la blockchain, nous entendons souvent un terme : « résistance à la censure ».
La première réaction de beaucoup est probablement de penser que cela ressemble à un slogan politisé, voire teinté d'une certaine couleur anarchiste. Mais pour un réseau de règlement ouvert à des utilisateurs mondiaux comme Ethereum, la résistance à la censure n'est pas d'abord une position politique, mais une capacité technique très concrète.
Imaginez que vous initiez une transaction depuis votre portefeuille imToken.
La signature est correcte, le solde du compte est suffisant, les frais de Gas ne sont pas bas non plus, mais la transaction tarde à être écrite dans un bloc, l'état dans le portefeuille reste bloqué sur « En attente », tandis que d'autres transactions avec des frais similaires ou même inférieurs sont continuellement ajoutées à la chaîne.
La question devient alors : qui a le pouvoir de décider si une transaction peut entrer dans un bloc ? Après tout, si Ethereum a finalement besoin que quelques participants centralisés décident quelles transactions peuvent être ajoutées à la chaîne, alors il n'y a pas de différence fondamentale avec le système financier traditionnel.
C'est pourquoi Ethereum explore ces dernières années une série de mécanismes anti-censure comme FOCIL, FairFIL, pour tenter de répondre à une question apparemment simple, mais en réalité cruciale : comment garantir qu'une transaction conforme aux règles du protocole ait une chance équitable d'entrer dans un bloc ?
I. D'où vient la « censure » exactement ?
Pour comprendre pourquoi Ethereum a besoin de ces mécanismes, il faut d'abord comprendre ce qu'il arrive à une transaction après son envoi depuis un portefeuille.
Lorsqu'un utilisateur signe et envoie une transaction depuis son portefeuille, celle-ci entre généralement d'abord dans le pool de transactions public d'Ethereum, c'est-à-dire le mémopool (Mempool). Cela ressemble plus à une zone d'attente, contenant un grand nombre de transactions non encore écrites dans un bloc.
Mais entrer dans la zone d'attente ne signifie pas que la transaction est déjà sur la chaîne. Il faut encore que quelqu'un sélectionne les transactions, décide de leur ordre, compose un bloc complet, puis le soumette au réseau pour confirmation.
C'est précisément à cette étape que le problème se pose.
Après la mise à niveau d'Ethereum vers le mécanisme de PoS (Preuve d'enjeu), pour empêcher les grands pools de staking d'utiliser la MEV (Valeur Extrêmale Maximale) pour former un monopole économique, Ethereum a introduit le système PBS (Proposer-Builder Separation, Séparation du Proposant et du Constructeur). Dans cette architecture, le processus de traitement de chaque transaction Ethereum est en réalité divisé entre deux rôles :
- Constructeur (Builder) : responsable de collecter les transactions, d'organiser leur ordre, de rechercher des opportunités d'arbitrage et de liquidation, et de construire un bloc avec un rendement aussi élevé que possible ;
- Proposant (Proposer) : responsable de sélectionner un bloc candidat parmi ceux soumis par les Builders et de le proposer au réseau.
Cette division du travail présente des avantages très concrets.
Comme on le sait, ces dernières années, les stratégies de MEV sont devenues de plus en plus complexes. Si on exigeait que chaque validateur ordinaire accomplisse indépendamment le tri des transactions et l'optimisation des blocs, cela donnerait sans aucun doute un avantage aux grands nœuds disposant de plus de capitaux, de données et de capacités techniques.
Ainsi, en confiant le travail complexe de construction de blocs à des Builders professionnels, les nœuds validateurs ordinaires, même sans capacités avancées d'arbitrage, peuvent participer à la proposition de blocs et obtenir les revenus correspondants, atténuant ainsi l'impact de la MEV sur la décentralisation du staking.
Cependant, cela a involontairement entraîné un autre effet secondaire : la concentration excessive du pouvoir de construction des blocs. Par exemple, actuellement, plus de 90% des blocs Ethereum sur l'ensemble du réseau sont produits par seulement quelques Builders professionnels. Et comme ces Builders ont généralement des antécédents commerciaux clairs, ils sont très sensibles aux pressions externes de conformité légale de pays ou régions spécifiques (comme les listes de sanctions OFAC), constituant ainsi un risque réel de centralisation.
C'est aussi pour cette raison que si ces principaux Builders principaux filtrent sélectivement certaines transactions sensibles (comme celles de Tornado Cash) ou certaines adresses, ces transactions risquent de rester bloquées pendant de longues périodes, voire de faire face à un risque de « bannissement implicite ».
En résumé, du point de vue de l'utilisateur ordinaire, Ethereum est un réseau ouvert auquel n'importe qui peut se connecter, transférer des fonds et appeler des contrats intelligents. Mais du point de vue du fonctionnement du protocole, envoyer une transaction n'est que la première étape. Pour qu'une transaction prenne réellement effet, il faut qu'elle soit sélectionnée, triée et écrite dans un bloc par un constructeur de bloc.
Ainsi, la « résistance à la censure » discutée dans Ethereum n'est pas seulement un concept grandiose lié à la politique, à la régulation ou aux sanctions. C'est d'abord un problème technique très concret :
Lorsqu'une transaction satisfait aux règles du protocole, le réseau peut-il garantir qu'elle aura une chance d'entrer dans un bloc dans un délai raisonnable ?
II. De FOCIL à FairFIL : Comment Ethereum limite-t-il les constructeurs de blocs
En fait, à ce stade, le problème est déjà clair. Les Builders peuvent améliorer l'efficacité de la construction des blocs, mais si le pouvoir d'inclusion des transactions reste longtemps concentré entre les mains de quelques Builders, Ethereum risque de reformer un nouveau risque de monopole centralisé.
Pour cela, les chercheurs d'Ethereum ont proposé les Inclusion Lists, souvent appelées « listes d'inclusion ».
Ce nom peut sembler abstrait, mais sa logique centrale n'est pas compliquée - le Builder reste responsable de la création du bloc, mais ne peut pas décider seul du sort de toutes les transactions. Les nœuds validateurs participant normalement au staking sur Ethereum doivent également conserver une partie du pouvoir, leur permettant de lister certaines transactions qui doivent être traitées.
Prenons l'exemple d'un arrêt de bus. On peut voir un bloc comme un trajet avec des sièges limités.
Le Builder décide comment la plupart des passagers font la queue, à quelle place ils s'asseyent, afin d'augmenter les revenus du trajet grâce à un arrangement plus efficace ; mais les nœuds validateurs peuvent également soumettre une « liste de passagers à embarquer obligatoirement ». Tant que les transactions de cette liste sont toujours valides, prêtes à payer des frais raisonnables et qu'il reste suffisamment de place dans le bloc, le Builder ne peut pas les refuser indéfiniment en se basant uniquement sur ses préférences.
Cependant, qui produit une liste d'inclusion, et que se passe-t-il si quelqu'un omet intentionnellement une transaction, restent deux problèmes à résoudre.
FOCIL et FairFIL se développent précisément dans ces deux directions.
1. FOCIL : Ne plus laisser un seul Proposer établir seul la liste d'inclusion
FOCIL (Fork-Choice Enforced Inclusion Lists) transfère le pouvoir de décider si une transaction doit être incluse d'un seul proposant à un « comité de nœuds validateurs » composé de multiples parties.
À chaque cycle de création de bloc, le réseau sélectionne aléatoirement un groupe de nœuds validateurs pour former un comité temporaire. Chaque membre du comité observe indépendamment le mémopool du réseau et soumet sa propre liste d'inclusion locale.
Cela signifie que même si 99% des Builders et proposants du réseau entier tentent de censurer une transaction, tant qu'il existe 1 nœud honnête dans le comité qui place cette transaction dans sa liste, cette transaction a une chance d'entrer dans les contraintes du protocole. Les censeurs qui voudraient continuer à l'exclure devraient alors contourner non pas une seule personne, mais plusieurs participants indépendants simultanément.
Ainsi, son avantage est qu'il n'est pas nécessaire de croire que chaque membre du comité restera neutre.
Mais une liste seule ne suffit pas. Si le Builder, après avoir reçu la liste, choisit toujours de ne pas l'exécuter, la liste d'inclusion devient une simple suggestion sans force contraignante.
Par conséquent, FOCIL ajoute une deuxième couche de conception, introduisant une règle de choix de fourche (Fork-Choice Rule) comme contrainte stricte. Cela oblige tous les nœuds du réseau responsables de la validation par vote à vérifier strictement le bloc soumis par le Builder. Dès qu'il est découvert que le Builder ose violer la liste d'inclusion consolidée par le comité, l'ensemble du réseau refusera directement de voter pour ce bloc.
Cela signifie que le bloc non conforme sera instantanément jugé invalide par le protocole, et le Builder en paiera le prix fort d'un échec de création de bloc.
2. FairFIL : Non seulement combler les lacunes, mais aussi rendre les omissions vérifiables
Si FOCIL interdit strictement la censure au niveau des règles de consensus, alors FairFIL (Fair Forward Inclusion Lists) et le mécanisme de responsabilisation visent, du point de vue économique, à rendre le comportement de censure extrêmement coûteux et non durable.
En clair, il exige une étape supplémentaire, par exemple qu'une raison explicite et vérifiable soit donnée lorsqu'une transaction n'entre pas dans un bloc.
Dans le fonctionnement réel du réseau, un Builder peut avoir besoin d'une période tampon très courte pour optimiser le tri des transactions et les opportunités d'arbitrage MEV. FairFIL permet au Builder d'effectuer des ajustements flexibles sous certaines contraintes. Mais si le Builder tente de prolonger un comportement de censure au bloc suivant, le protocole déclenche immédiatement une procédure de responsabilisation.
Sa logique générale peut être comprise en trois étapes.
- Premièrement, le protocole établit un ensemble de règles de référence publiques et vérifiables pour déterminer quelles transactions dans le pool de transactions public remplissent normalement les conditions pour entrer dans le bloc actuel. Si certaines transactions, éligibles selon ces règles, ne sont finalement pas traitées, le Builder doit les inscrire publiquement dans la FairFIL ;
- Ensuite, les validateurs vérifient si cette liste est complète. Si le Builder a clairement omis des transactions éligibles sans les inscrire dans la liste, ce comportement peut être détecté et influencer la décision des nœuds validateurs de soutenir ou non ce bloc ;
- Enfin, les transactions valides entrant dans la FairFIL deviennent des tâches à traiter en priorité pour les blocs suivants. Le prochain Builder peut toujours organiser leur position spécifique dans le bloc, mais ne peut plus faire semblant de ne pas les voir ;
Si une transaction est omise de manière répétée, le bloc concerné risque de perdre le soutien des validateurs et le Builder pourrait perdre la récompense de l'ensemble du bloc.
En d'autres termes, la « responsabilisation » soulignée par FairFIL consiste en réalité à introduire des pénalités économiques progressives. Un Builder qui censure continuellement des transactions risque de se voir priver de la récompense entière du bloc, voire de subir une réduction de son dépôt de garantie (slashing).
C'est également la direction dans laquelle évoluent les mécanismes anti-censure d'Ethereum, visant à établir un ensemble de contraintes plus réalistes. Même si quelques participants ont l'intention de censurer, il leur sera difficile de contrôler l'entrée des transactions à long terme ; même si quelqu'un omet intentionnellement une transaction, il doit laisser une trace et payer un prix de plus en plus élevé pour une censure persistante.
III. Qu'est-ce que cela signifie pour l'utilisateur ordinaire ?
Pour l'utilisateur ordinaire qui effectue quotidiennement des transferts, des échanges ou utilise la DeFi via son portefeuille, ces mécanismes sous-jacents, même s'ils sont mis en œuvre à l'avenir, ne nécessiteront pas de changer ses habitudes actuelles.
L'utilisateur remplira toujours le montant dans le portefeuille, confirmera le Gas, signera, puis attendra que la transaction soit ajoutée à la chaîne. Mais dans la couche sous-jacente invisible du protocole, la logique de l'inclusion d'une transaction dans un bloc pourrait changer de manière importante.
Ce qui est vraiment amélioré, c'est la déterminisme du processus d'inclusion des transactions.
- Premièrement, une transaction conforme aux règles ne dépendra plus entièrement du choix d'un Builder spécifique : même si le Builder actuel ne souhaite pas la traiter, d'autres validateurs pourront, via une liste d'inclusion, établir pour elle une exigence d'inclusion au niveau du protocole ;
- Deuxièmement, le pouvoir d'inclusion des transactions et le pouvoir de tri des transactions pourraient progressivement se séparer : le Builder pourra toujours utiliser des algorithmes professionnels pour organiser l'ordre des transactions, augmenter les revenus du bloc, et continuer à rivaliser autour de l'arbitrage et des liquidations, mais son pouvoir de décider « qui a le droit d'entrer sur le marché » sera limité ;
Pour aller plus loin, la neutralité crédible d'Ethereum pourrait également passer d'une proposition de valeur reposant sur l'engagement des participants à une règle de protocole exécutée automatiquement par les clients.
L'utilisateur n'a pas besoin de savoir quel Builder a construit le bloc actuel, ni de croire individuellement que ces Builders resteront activement neutres. Les nœuds validateurs vérifieront les blocs selon le même ensemble de règles, rendant difficile la reconnaissance par le réseau des blocs qui violent les obligations d'inclusion.
À l'avenir, les portefeuilles et les explorateurs de blocs pourraient même fournir des états de transaction plus détaillés sur cette base.
Une transaction ne se contentera plus d'afficher vaguement « en attente ». Elle pourrait plutôt informer l'utilisateur si elle est déjà entrée dans une liste d'inclusion, si elle a obtenu une obligation d'inclusion pour un bloc ultérieur, et si l'attente supplémentaire est due à un Gas insuffisant, à une transaction devenue invalide, ou à une anomalie dans la construction du bloc.
Cependant, les mécanismes anti-censure ne signifient pas que chaque transaction réussira immédiatement.
Les transactions avec un solde insuffisant, un conflit de Nonce, un Gas trop faible ou dont les conditions d'exécution du contrat sont déjà invalides peuvent toujours ne pas entrer dans un bloc. Lorsque le réseau est congestionné ou que l'espace de bloc est insuffisant, les utilisateurs devront toujours attendre la confirmation par la concurrence sur les frais.
Mais ces mécanismes améliorent principalement le fait qu'une transaction initialement valide, avec des frais raisonnables et déjà propagée dans le pool de transactions public, ne devrait pas être retardée indéfiniment en raison du choix subjectif de quelques constructeurs de blocs.
En termes de progrès, jusqu'en août 2026, l'EIP-7805 correspondant à FOCIL est toujours à l'état de brouillon (Draft). Cependant, il a été sélectionné par les développeurs principaux d'Ethereum comme élément phare (Headliner) de la couche consensus pour la mise à niveau Hegotá, et est entré dans la phase Scheduled for Inclusion, ce qui signifie que les équipes clientes ont convenu de progresser vers sa mise en œuvre et de développer des tests réseau, mais la date précise de son déploiement sur le réseau principal n'est pas encore finalisée.
FairFIL est à un stade encore plus précoce. Il s'agit principalement d'un plan de recherche publié en juillet 2026. Sa future inclusion dans la feuille de route d'Ethereum nécessitera des discussions plus larges, une mise en œuvre et une vérification de sécurité.
Pour conclure
Objectivement parlant, Ethereum ne peut pas garantir que chaque Builder, validateur et opérateur d'infrastructure restera toujours neutre.
Les participants peuvent être soumis à des pressions réglementaires, poursuivre leurs propres intérêts ou accepter des incitations externes. Un réseau décentralisé véritablement résilient ne peut pas être construit sur l'hypothèse idéale que « tout le monde fera ce qu'il faut ».
La véritable résistance à la censure, c'est lorsque, même si certains participants tentent d'interférer avec les transactions, d'autres participants conservent la capacité de briser ce contrôle ; même si quelqu'un choisit de s'écarter du principe de neutralité, le protocole peut rendre ce comportement visible, coûteux et difficile à maintenir.
Des premières listes d'inclusion, à FOCIL qui contraint collectivement les Builders via un comité distribué, jusqu'à FairFIL qui exige que les omissions puissent être vérifiées publiquement. Du droit pour quiconque d'envoyer une transaction, à la garantie que la transaction de quiconque ait une chance d'être vue.
Sous cet angle, Ethereum tente bien de transformer cette promesse, d'une simple déclaration de valeur, en l'écrivant pas à pas dans le protocole lui-même.
C'est encourageant.
