Le chemin de l’Ethereum vers la résistance à la censure : BRAID contre FOCIL

Dans le paysage évolutif d’Ethereum, la bataille pour la résistance à la censure a introduit plusieurs mécanismes innovants. Parmi ceux-ci, BRAID et FOCIL se distinguent comme deux approches prometteuses conçues pour protéger l’intégrité du réseau en minimisant le risque de censure des transactions.

Ces deux solutions s’attaquent à des problèmes critiques dans le processus de proposition de blocs, mais adoptent des approches fondamentalement différentes pour atteindre leurs objectifs. Cet article examine les nuances de ces deux mécanismes et explore lequel pourrait s’avérer le plus efficace en fin de compte.

Comprendre la menace de la censure dans Ethereum

Au cœur du processus de génération et de validation des blocs d’Ethereum se trouvent deux acteurs principaux : les constructeurs et les proposants. Les constructeurs sont chargés de trier les transactions et de soumettre un bloc aux proposants, qui sélectionnent ensuite un bloc à signer et à proposer à la blockchain.

Ce processus crée toutefois une vulnérabilité potentielle. Étant donné que les proposants ont le dernier mot quant au bloc proposé, il existe un risque de collusion entre les proposants et les constructeurs pour censurer certaines transactions, menaçant ainsi le principe de résistance à la censure d’Ethereum.

La résistance à la censure est essentielle pour maintenir l’équité et la transparence de la blockchain. Si les auteurs de propositions peuvent inclure ou exclure des transactions de manière sélective, cela compromet la nature décentralisée du réseau et peut conduire à l’exploitation de l’ordre des transactions, ce qui entraîne des problèmes tels que la valeur extractible par les mineurs (MEV).

Solutions existantes : MCP et FOCIL

Pour relever ce défi, plusieurs solutions résistantes à la censure ont été proposées, dont deux des plus discutées sont la liste d’inclusion de force (FOCIL) et les mécanismes de proposition multiconcurrente (MCP).

Liste d’inclusion de la force (FOCIL)

FOCIL est conçu pour garantir l’équité en faisant intervenir un comité de validateurs sélectionnés de manière aléatoire pendant chaque tranche horaire.

Ces validateurs créent des listes d’inclusion locales basées sur leur vision du mempool et diffusent ces listes.

L’auteur de la proposition regroupe ensuite ces listes locales en une liste d’inclusion finale qui est ajoutée au bloc.

Ce mécanisme garantit qu’aucun auteur de proposition n’a le contrôle total des transactions incluses dans un bloc, ce qui réduit le risque de censure.

Les validateurs vérifient que le bloc respecte les règles de consensus avant de l’accepter dans la blockchain.

Proposant multi-concurrent (MCP)

Le MCP introduit le concept de plusieurs proposants simultanés, comme l’a suggéré pour la première fois Max Resnick dans le mécanisme de la multiplicité.

Dans ce système, plusieurs proposants travaillent en parallèle, chacun sélectionnant une partie des transactions du pool de mémoire.

Ces transactions sont regroupées dans des « liasses de transactions spéciales » et signées par les proposants. L’auteur de la proposition principale doit inclure au moins deux tiers de ces paquets dans le bloc proposé pour que celui-ci soit considéré comme valide.

Cette méthode décentralise le pouvoir d’un seul proposant et réduit considérablement la probabilité de censure des transactions.

BRAID : Une mise en œuvre améliorée du MCP

S’appuyant sur le concept MCP, Max Resnick a développé BRAID, une implémentation MCP plus sophistiquée et plus complète.

Présenté lors du séminaire « DeFi in MEV Era » organisé par Paradigm, BRAID permet à plusieurs proposants de proposer simultanément des blocs sur différentes chaînes parallèles.

Ces blocs sont ensuite synchronisés par le biais d’un mécanisme de consensus afin de garantir la cohérence entre les chaînes.

La couche d’exécution d’Ethereum consolide tous les blocs générés dans la fente en un seul bloc d’exécution, où les transactions sont dédupliquées, ordonnées et exécutées selon des règles prédéfinies.

Cette approche réduit considérablement le pouvoir d’une seule entité de manipuler les enregistrements de transactions.

L’un des principaux avantages de BRAID est qu’il évite de créer des rôles supplémentaires ou des structures d’incitation complexes, ce qui peut ajouter à la complexité.

Cependant, la coordination de la synchronisation entre plusieurs sous-chaînes et le traitement des données posent leurs propres problèmes.

Défis et considérations concernant BRAID

Malgré ses atouts, BRAID n’est pas sans poser de problèmes. L’un d’entre eux est le modèle de « pourboire conditionnel », qui exige des utilisateurs qu’ils disposent de liquidités pour s’assurer que leurs transactions résistent à la censure. Les utilisateurs doivent définir deux valeurs de pourboire lorsqu’ils soumettent des transactions :

1. Pointe supérieure (T) : Le montant maximum qu’un utilisateur est prêt à payer pour s’assurer que sa transaction est incluse même en cas de tentative de censure. Si un seul proposant inclut la transaction, il reçoit le montant total de T.
2. Pointe inférieure (t) : Un pourboire plus petit qui est payé si plusieurs proposants incluent la transaction. Dans ce cas, le pourboire est réparti entre les proposants qui incluent la transaction.

Ce modèle, bien qu’efficace pour décourager la censure, introduit une complexité et des coûts supplémentaires pour les utilisateurs. Ceux-ci doivent réserver des liquidités supplémentaires au moment de la transaction, qui peuvent être gelées jusqu’à ce qu’il soit déterminé si elles seront nécessaires.

Pour résoudre ces problèmes, Jonahb de Blockchain Capital propose deux solutions potentielles :

• Preuve de liquidité post-étatique : Cette approche permet aux utilisateurs de fournir la preuve qu’ils disposeront de liquidités suffisantes pour payer le pourboire le plus élevé après l’exécution de la transaction. Toutefois, elle exige des proposants qu’ils comprennent l’état post-transaction, ce qui est difficile dans le cas de transactions impliquant un état partagé ou des opérations financières complexes.
• Assurance contre la censure : Ce concept introduit des fournisseurs tiers d’assurance-censure (IC) qui garantissent le pourboire de l’utilisateur en échange d’une redevance. Cela réduit la charge de liquidité immédiate pour les utilisateurs, mais nécessite le développement d’un marché entre les utilisateurs et les fournisseurs d’assurance-censure.

Perspectives communautaires : FOCIL vs. BRAID

La communauté Ethereum est divisée sur les mérites relatifs de FOCIL et BRAID. Terence, développeur pour le client Ethereum Prysm, apprécie que BRAID ne nécessite pas de participants supplémentaires, ce qui simplifie le processus par rapport à FOCIL, qui introduit des contraintes de temps supplémentaires pour la soumission et la vérification des listes d’inclusion. Cependant, FOCIL est généralement considéré comme plus facile à mettre en œuvre et plus flexible.

Dan Robinson, chercheur chez Paradigm, fait l’éloge de BRAID pour son approche de la hiérarchisation des transactions, qui permet de réduire efficacement les risques liés à la MEV. Il souligne également que le mécanisme de basculement conditionnel constitue une forte incitation à la censure, un aspect qui fait défaut à FOCIL.

À l’inverse, le développeur Dev préfère FOCIL pour sa simplicité et sa forte résistance à la censure, ce qui suggère que FOCIL offre une mise en œuvre plus directe avec moins de complications.

Le chercheur d’Ethereum barnabe.eth reconnaît que si BRAID peut offrir des améliorations dans certains domaines, il reste prudent quant à l’abandon total du modèle basé sur le leader sur lequel FOCIL et d’autres conceptions d’IL sont construites, citant le besoin de recherches et de preuves supplémentaires pour valider la faisabilité de BRAID.

Conclusion : Quel mécanisme est supérieur ?

Le débat entre BRAID et FOCIL souligne la complexité de la résistance à la censure dans Ethereum. L’approche innovante de BRAID pour décentraliser le pouvoir de proposition et réduire le risque de MEV est convaincante, mais elle s’accompagne de défis de mise en œuvre importants et nécessite un développement plus approfondi.

FOCIL, bien que plus simple et plus flexible, peut ne pas offrir le même niveau de robustesse face à des tentatives de censure sophistiquées.

En fin de compte, le choix entre BRAID et FOCIL peut dépendre des priorités spécifiques du réseau Ethereum à un moment donné. À mesure que l’écosystème continue d’évoluer, les deux mécanismes pourraient jouer un rôle dans le renforcement de la résistance d’Ethereum à la censure, en veillant à ce que le réseau reste fidèle à ses principes décentralisés.