Intégrer l'anti-censure dans le protocole : qui décide si une transaction Ethereum peut être ajoutée à la blockchain ?

L'anti-censure au niveau du protocole permet à toute transaction conforme aux règles de ne pas être exclue à long terme simplement en raison des préférences d'un petit nombre de constructeurs de blocs.

Dans le monde de la blockchain, nous entendons souvent un terme : « anti-censure ».

Pour beaucoup, la première réaction peut sembler être un slogan quelque peu politique, voire teinté d'anarchisme. Cependant, pour un réseau de règlement ouvert aux utilisateurs du monde entier comme Ethereum, l'anti-censure n'est d'abord pas une position politique, mais une capacité technique très concrète.

Imaginez que vous initiez une transaction dans votre portefeuille imToken.

La signature est correcte, le solde du compte est suffisant, les frais de Gas ne sont pas faibles, mais la transaction n'est toujours pas écrite dans le bloc, l'état de votre portefeuille reste en « En attente », tandis que d'autres transactions avec des frais similaires, voire inférieurs, sont constamment ajoutées à la blockchain.

La question devient alors : qui a le pouvoir de décider si une transaction peut entrer dans un bloc ? Après tout, si Ethereum doit finalement dépendre de quelques participants centralisés pour décider quelles transactions peuvent être ajoutées à la blockchain, alors il n'y a pas de différence essentielle avec le système financier traditionnel.

C'est pourquoi Ethereum explore ces dernières années une série de mécanismes anti-censure tels que FOCIL et FairFIL, tentant de répondre à une question apparemment simple mais en réalité très cruciale : comment garantir que toute transaction conforme aux règles du protocole ait une chance équitable d'entrer dans un bloc ?

1. D'où vient réellement la « censure » ?

Pour comprendre pourquoi Ethereum a besoin de ces mécanismes, il faut d'abord clarifier ce qui se passe après qu'une transaction a été envoyée depuis un portefeuille.

Lorsque l'utilisateur signe et envoie une transaction dans son portefeuille, celle-ci entre généralement d'abord dans la piscine de transactions publiques d'Ethereum, également connue sous le nom de mémoire (Mempool), qui ressemble davantage à une zone d'attente contenant de nombreuses transactions qui n'ont pas encore été écrites dans un bloc.

Mais entrer dans la zone d'attente ne signifie pas que la transaction a été ajoutée à la blockchain ; 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.

Le problème surgit précisément à ce stade.

Après la mise à niveau d'Ethereum vers le mécanisme PoS (preuve d'enjeu), afin d'empêcher les grands pools de mise d'exploiter le MEV (valeur maximale extractible) pour créer un monopole économique, Ethereum a introduit le système PBS (Proposer-Builder Separation, séparation des proposeurs et des constructeurs). Dans cette architecture, le processus de traitement de chaque transaction Ethereum est en fait divisé entre deux rôles :

• Constructeur (Builder) : responsable de la collecte des transactions, de l'organisation de leur ordre, de la recherche d'opportunités d'arbitrage et de liquidation, et de la construction d'un bloc avec un rendement aussi élevé que possible ;
• Proposeur (Proposer) : responsable de la sélection d'un bloc candidat soumis par le Builder et de sa soumission au réseau ;

Cette division du travail présente des avantages très concrets.

Il est bien connu que ces dernières années, les stratégies MEV sont devenues de plus en plus complexes. Si l'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 fonds, de données et de capacités techniques.

Ainsi, en confiant le travail complexe de construction de blocs à des Builders professionnels, les nœuds de validation ordinaires, même s'ils ne possèdent pas de capacités d'arbitrage avancées, peuvent participer à la proposition de blocs et obtenir des revenus correspondants, atténuant ainsi l'impact du MEV sur la décentralisation de la mise.

Cependant, cela a également involontairement entraîné un autre effet secondaire, à savoir la concentration excessive du pouvoir de construction de blocs. Par exemple, actuellement, plus de 90 % des blocs Ethereum dans le réseau sont produits par seulement quelques Builders professionnels, et comme ces Builders ont généralement un arrière-plan commercial clair, ils sont facilement soumis à des pressions externes liées à la conformité légale dans certains pays ou régions (comme les listes de sanctions OFAC), ce qui constitue en réalité un risque de centralisation.

C'est pourquoi, si ces principaux Builders choisissent de filtrer sélectivement certaines transactions sensibles (comme Tornado Cash) ou des transactions d'adresses spécifiques, ces transactions peuvent se retrouver dans une situation où elles ne peuvent pas être emballées pendant une longue période, voire risquer d'être « censurées » de manière implicite.

En résumé, du point de vue des utilisateurs ordinaires, Ethereum est un réseau ouvert auquel tout le monde 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 ; la capacité de la transaction à réellement entrer en vigueur dépend également de sa sélection, de son tri et de son écriture par un constructeur de blocs.

Ainsi, la discussion sur l'« anti-censure » dans Ethereum n'est pas seulement un concept grandiose lié à la politique, à la réglementation ou aux sanctions, c'est d'abord une question technique très concrète :

Lorsque qu'une transaction respecte les 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 ?

2. De FOCIL à FairFIL : comment Ethereum limite les constructeurs de blocs

En fait, à ce stade, le problème est déjà très clair : les Builders peuvent améliorer l'efficacité de la construction de blocs, mais si le pouvoir de décision des transactions reste longtemps concentré entre les mains de quelques Builders, Ethereum risque de créer à nouveau de nouveaux risques de monopole centralisé.

Pour cela, les chercheurs d'Ethereum ont proposé des Inclusion Lists, généralement appelées « listes d'inclusion ».

Ce nom peut sembler un peu abstrait, mais sa logique fondamentale n'est pas compliquée : les Builders restent responsables de la création des blocs, mais ne peuvent pas décider seuls du sort de toutes les transactions. Les nœuds de validation participant normalement à la mise d'Ethereum doivent également conserver une partie du pouvoir, leur permettant de dresser une liste de transactions qui doivent être traitées.

Prenons l'exemple d'une station de bus : on peut comprendre un bloc comme un trajet avec un nombre de sièges limité.

Le Builder décide de la manière dont la plupart des passagers font la queue et s'asseyent, afin d'augmenter le rendement de l'ensemble du trajet grâce à une meilleure organisation ; mais les nœuds de validation peuvent également soumettre une « liste de passagers obligatoires », tant que les transactions de la liste sont toujours valides, prêtes à payer des frais raisonnables, et qu'il y a suffisamment d'espace dans le bloc, le Builder ne peut pas simplement les rejeter en raison de ses propres préférences.

Cependant, qui doit établir une liste d'inclusion et que faire si quelqu'un omet intentionnellement des transactions restent deux questions à résoudre.

FOCIL et FairFIL se développent précisément dans ces deux directions.

1. FOCIL : ne plus laisser un seul Proposeur établir la liste d'inclusion

FOCIL (Fork-Choice Enforced Inclusion Lists) transfère le pouvoir de décider quelles transactions doivent être incluses d'un seul proposeur à un « comité de nœuds de validation » composé de plusieurs parties.

À chaque cycle de création de blocs, le réseau sélectionne au hasard un groupe de nœuds de validation pour former un comité temporaire. Chaque membre du comité observe indépendamment la mémoire du réseau et soumet sa propre liste d'inclusion locale.

Cela signifie que même si 99 % des Builders et des proposeurs du réseau tentent de censurer une transaction, tant qu'il y a un nœud honnête dans le comité qui inclut cette transaction dans sa liste, cette transaction a une chance d'entrer dans les contraintes du protocole. Si les censeurs veulent continuer à l'exclure, ils doivent non seulement influencer une personne, mais contourner plusieurs participants indépendants.

Ainsi, son avantage réside dans le fait qu'il n'est pas nécessaire de croire que chaque membre du comité reste neutre.

Mais avoir seulement une liste n'est pas suffisant. Si le Builder reçoit la liste et choisit toujours de ne pas l'exécuter, la liste d'inclusion deviendra une simple suggestion sans contrainte.

Ainsi, FOCIL a ajouté une deuxième couche de conception, introduisant des règles de choix de fork (Fork-Choice Rule) pour imposer des contraintes strictes, obligeant tous les nœuds responsables de la validation des votes à vérifier rigoureusement le bloc soumis par le Builder. Si un Builder enfreint la liste d'inclusion intégrée par le comité, l'ensemble du réseau refusera de voter pour ce bloc.

Cela signifie qu'un bloc non conforme sera immédiatement jugé comme un bloc invalide par le protocole, et le Builder en subira de lourdes conséquences en cas d'échec de création de blocs.

2. FairFIL : non seulement combler les lacunes, mais aussi rendre les omissions vérifiables

Si FOCIL interdit de manière stricte la censure sur le plan des règles de consensus, FairFIL (Fair Forward Inclusion Lists) et le mécanisme de responsabilité visent à rendre le comportement de censure extrêmement coûteux et insoutenable sur le plan économique.

En d'autres termes, il pose des exigences plus avancées, comme qu'une transaction qui n'entre pas dans un bloc devrait laisser une trace vérifiable publiquement.

Dans le fonctionnement réel du réseau, le Builder peut avoir besoin d'une très courte période de temps pour optimiser le tri des transactions et le MEV d'arbitrage. 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éclenchera immédiatement un processus de responsabilité.

Sa logique générale peut être comprise en trois étapes.

• Tout d'abord, le protocole établira un ensemble de règles de référence publiques et vérifiables pour déterminer quelles transactions dans le pool de transactions publiques peuvent, en temps normal, entrer dans le bloc actuel. Si certaines transactions qui auraient dû être éligibles selon ces règles de référence ne sont finalement pas traitées, le Builder devra les inscrire publiquement dans FairFIL ;
• Ensuite, les validateurs vérifieront si cette liste est complète. Si le Builder omet manifestement des transactions éligibles sans les inscrire sur la liste, ce comportement pourrait être détecté et affecter le soutien des nœuds de validation pour ce bloc ;
• Enfin, les transactions valides entrant dans FairFIL deviendront des tâches prioritaires à traiter dans les blocs suivants. Le prochain Builder pourra toujours les placer à un endroit spécifique dans le bloc, mais il ne pourra pas faire semblant de ne pas les voir ;

Si une transaction est continuellement omise, le bloc concerné pourrait perdre le soutien des validateurs, et le Builder pourrait ainsi perdre l'ensemble des revenus du bloc.

En d'autres termes, la "responsabilité" mise en avant par FairFIL est en réalité introduite par des sanctions économiques graduelles. Les Builders qui continuent à examiner les transactions seront confrontés au risque de perdre l'intégralité de la récompense du bloc, voire de voir leur dépôt de garantie confisqué.

C'est également la direction dans laquelle le mécanisme anti-censure d'Ethereum s'approfondit progressivement, visant à établir un ensemble de contraintes plus réalistes. Même si quelques participants ont l'intention de censurer, il sera difficile de contrôler l'entrée des transactions à long terme ; même si quelqu'un choisit délibérément d'omettre des transactions, cela devra laisser des traces et coûtera de plus en plus cher pour une censure continue.

Qu'est-ce que cela signifie pour les utilisateurs ordinaires ?

Pour les utilisateurs ordinaires qui effectuent des transferts, des échanges ou utilisent DeFi via un portefeuille chaque jour, ces mécanismes sous-jacents, même s'ils sont mis en œuvre à l'avenir, ne nécessiteront pas de changer leurs habitudes opérationnelles existantes.

Les utilisateurs continueront à remplir le montant dans leur portefeuille, à confirmer le Gas, à signer, puis à attendre que la transaction soit ajoutée à la chaîne. Cependant, dans les protocoles sous-jacents invisibles, la logique de savoir si une transaction peut entrer dans un bloc pourrait changer de manière significative.

Ce qu'il améliore réellement, c'est la certitude du processus d'inclusion des transactions.

• Tout d'abord, une transaction conforme aux règles ne dépendra plus entièrement du choix d'un Builder : même si le Builder actuel ne souhaite pas traiter, d'autres validateurs peuvent établir une exigence d'inclusion au niveau du protocole via une liste d'inclusion ;
• Deuxièmement, le droit d'inclusion des transactions et le droit de tri des transactions pourraient progressivement se séparer : le Builder peut toujours utiliser des algorithmes spécialisés pour organiser l'ordre des transactions et augmenter les revenus du bloc, et il peut toujours rivaliser autour de l'arbitrage et de la liquidation, mais son pouvoir de décider "qui est éligible à entrer sur le marché" sera limité ;

Plus loin encore, la neutralité de confiance d'Ethereum pourrait également passer d'une proposition de valeur dépendant des promesses des participants à des règles de protocole exécutées automatiquement par le client.

Les utilisateurs n'ont pas besoin de savoir quel Builder a construit le bloc actuel, ni de croire individuellement que ces Builders resteront neutres. Les nœuds de validation vérifieront le bloc selon un même ensemble de règles, rendant difficile la reconnaissance par le réseau des blocs violant l'obligation d'inclusion.

À l'avenir, les portefeuilles et les explorateurs de blocs pourraient même fournir des états de transaction plus détaillés.

Une transaction ne sera plus simplement affichée comme "en attente de traitement", mais pourrait en outre informer l'utilisateur si elle a déjà été incluse dans la liste d'inclusion, si elle a obtenu l'obligation d'inclusion dans les blocs suivants, et si l'attente est due à un Gas insuffisant, à une transaction déjà échouée, ou à une anomalie dans le processus de construction du bloc.

Cependant, le mécanisme anti-censure ne signifie pas que chaque transaction réussira immédiatement.

Les transactions avec un solde insuffisant, un conflit de Nonce, un Gas trop bas ou des conditions d'exécution de contrat déjà échouées pourraient toujours ne pas entrer dans le bloc. Lorsque le réseau est congestionné et que l'espace de bloc est insuffisant, les utilisateurs devront toujours attendre une confirmation par la compétition des frais.

Mais ce qu'il améliore principalement, c'est qu'une transaction qui est valide, avec des frais raisonnables et déjà diffusée dans le pool de transactions publiques, ne devrait pas être indéfiniment retardée en raison du choix subjectif d'un petit nombre de constructeurs de blocs.

En termes de progression, à partir d'août 2026, le FOCIL correspondant à l'EIP-7805 est toujours en état de brouillon. Cependant, il a déjà été sélectionné par les développeurs principaux d'Ethereum comme Headliner de la mise à niveau Hegotá et est entré dans la phase de planification pour inclusion, ce qui signifie que l'équipe du client a accepté de faire avancer sa mise en œuvre et le développement des tests du réseau, mais la date de mise en ligne sur le réseau principal n'est pas encore définitivement fixée.

FairFIL est encore plus précoce, étant principalement un projet de recherche publié en juillet 2026. Sa future inclusion dans la feuille de route d'Ethereum nécessitera encore des discussions plus larges, des mises en œuvre et des vérifications de sécurité.

En conclusion

Objectivement, 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 véritable réseau décentralisé résilient ne peut pas être construit sur l'hypothèse idéale que "tout le monde fera ce qui est juste".

La véritable anti-censure est que même si certains participants tentent d'interférer avec les transactions, d'autres participants ont toujours la capacité de briser ce contrôle ; même si quelqu'un choisit de s'écarter des principes de neutralité, le protocole peut rendre ce comportement visible, coûteux et difficile à maintenir.

Depuis la liste d'inclusion initiale, jusqu'à FOCIL qui contraint les Builders par un comité distribué, puis à FairFIL qui exige que les comportements d'omission puissent être vérifiés publiquement, en passant par la possibilité pour quiconque d'envoyer des transactions, jusqu'à garantir que les transactions de quiconque aient une chance d'être vues.

Sous cet angle, Ethereum essaie effectivement de transformer cette promesse, d'une déclaration de valeur, en l'écrivant progressivement dans le protocole lui-même.

À suivre.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.