La voie de l'anti-censure d'Ethereum : BRAID ou FOCIL, lequel est supérieur ?
TechFlow SélectionTechFlow Sélection
La voie de l'anti-censure d'Ethereum : BRAID ou FOCIL, lequel est supérieur ?
BRAID est un schéma amélioré à plusieurs proposants concurrents (MCP). FOCIL est un schéma amélioré à liste incluse (IL).
Dédié à des analyses Web3 approfondiesRédaction : 0XNATALIE
Dans le processus de génération et de validation des blocs Ethereum, les bâtisseurs (builders) sont responsables du classement des transactions et soumettent les blocs aux proposants via un mécanisme d'enchères. Les proposants choisissent ensuite l'un de ces blocs, le signent et le proposent sur la blockchain. Étant donné que le proposant, en tant qu'entité unique, détient le pouvoir de décision final, cela crée un risque de collusion possible entre proposants et bâtisseurs afin de censurer certaines transactions.
L'une des valeurs fondamentales de la blockchain réside dans sa résistance à la censure, c'est-à-dire la capacité pour toute personne d'effectuer des transactions sans ingérence d'une autorité centrale. Lorsque les proposants peuvent contrôler quelles transactions sont incluses dans un bloc, cette caractéristique est compromise, menaçant ainsi l'équité et la transparence. De plus, ils peuvent exploiter ce pouvoir pour manipuler l'ordre des transactions dans un bloc afin d'obtenir des gains économiques supplémentaires, ce qui soulève le problème du MEV.
Les solutions existantes contre la censure
Pour répondre à ce défi, la communauté a proposé plusieurs solutions, telles que la liste d'inclusion forcée (FOCIL). Dans le mécanisme FOCIL, un groupe de validateurs est aléatoirement sélectionné à chaque slot (intervalle temporel) pour former un comité de liste d'inclusion. Ces membres du comité génèrent chacun une liste locale d'inclusion basée sur leur propre vision subjective du pool de transactions (mempool), puis diffusent cette liste. Le proposant collecte ensuite ces listes locales et les agrège en une liste agrégée incluse dans le bloc. Ce mécanisme garantit l'équité du bloc, car les validateurs vérifient la conformité de la liste agrégée avec les listes locales précédemment diffusées. Seuls les blocs respectant les règles de consensus sont acceptés et ajoutés à la blockchain.
Outre FOCIL, la communauté a également discuté du concept de plusieurs proposants concurrents (MCP). Cette idée a été initialement proposée par Max Resnick dans le cadre du mécanisme Multiplicity, visant à décentraliser le pouvoir en introduisant plusieurs proposants de blocs en parallèle, réduisant ainsi la capacité d'un nœud unique à censurer des transactions. Dans Multiplicity, chaque validateur sélectionne une partie des transactions depuis son propre mempool pour constituer un « paquet de transactions spécial ». Ils signent ensuite ce paquet et l'envoient au proposant du tour en cours. Une fois reçu, le proposant doit inclure au moins 2/3 de ces paquets dans le bloc qu'il propose. Seul un bloc satisfaisant cette condition est considéré comme valide. Ce mécanisme empêche le proposant de décider seul du contenu du bloc, réduisant ainsi les risques de censure. Pour inciter davantage les proposants à inclure équitablement les transactions, un système de « pourboires conditionnels » est mis en œuvre : seuls les proposants ayant effectivement inclus une transaction peuvent recevoir une part de son pourboire. Le pourboire n'est pas automatiquement attribué intégralement au premier proposant à inclure la transaction, mais distribué selon certaines conditions à tous les proposants qui l'ont incluse. Cela augmente le coût de la censure, car celle-ci nécessiterait de corrompre tous les proposants ayant inclus la transaction.
BRAID : une implémentation améliorée du MCP
Sur la base de Multiplicity, Max Resnick a proposé BRAID, une version plus complexe et aboutie du MCP. Lors d’un atelier organisé par Paradigm sur le thème « DeFi in the MEV Era », Max a présenté BRAID. Ce mécanisme permet à plusieurs proposants de proposer simultanément des blocs sur différentes chaînes parallèles, tout en maintenant la cohérence inter-chaînes grâce à un mécanisme de consensus synchronisé. Chaque chaîne possède son propre proposant, et tous publient leurs blocs simultanément au sein du même slot. La couche d'exécution d'Ethereum regroupe alors toutes les transactions issues des sous-chaînes pour ce slot, formant un bloc d'exécution. Ces transactions sont ensuite désdupliquées, triées et exécutées selon des règles prédéfinies, limitant ainsi la capacité de toute entité unique à manipuler l’enregistrement des transactions.
La conception de BRAID ne fait pas appel à des rôles supplémentaires, évitant ainsi la complexité liée aux mécanismes d'incitation ou de sanction. Toutefois, sa mise en œuvre est relativement complexe, nécessitant une coordination étroite entre la synchronisation et le traitement des données des multiples sous-chaînes.
Les problèmes du mécanisme BRAID
Jonahb, membre de Blockchain Capital, a pointé un problème dans le mécanisme BRAID : le modèle de « pourboires conditionnels » impose une exigence de liquidité qui nuit à l'expérience utilisateur. Ce modèle constitue une stratégie de tarification dynamique exigeant que les utilisateurs disposent d'une certaine réserve de liquidités pour garantir la résistance à la censure de leurs transactions. Lorsqu'ils soumettent une transaction, les utilisateurs doivent définir deux montants de pourboire (T et t). Le montant effectivement payé dépend du nombre de proposants ayant inclus la transaction.
-
Pourboire élevé T : représente le montant maximal que l'utilisateur est prêt à payer pour s'assurer que sa transaction ne soit pas censurée. Il vise à inciter les proposants à inclure la transaction lorsqu'aucun autre proposant n'est disposé à le faire. Si un seul proposant l'inclut, il reçoit intégralement T.
-
Pourboire faible t : montant inférieur défini par l'utilisateur. Dès lors que plusieurs proposants incluent la transaction, l'utilisateur ne paie que t, réparti entre eux. Si l'utilisateur n'accorde pas d'importance à la résistance à la censure, il peut fixer T = t et envoyer sa transaction à un seul proposant.
Cependant, cette exigence supplémentaire en liquidités augmente la complexité et le coût de participation aux transactions blockchain. Les utilisateurs doivent bloquer à l'avance une somme d'argent uniquement pour garantir la résistance à la censure, somme qui reste gelée jusqu'à utilisation effective.
À ce sujet, Jonahb propose deux solutions :
-
Proof of Post-State Liquidity (Preuve de liquidité post-exécution) : l'utilisateur fournit une preuve au moment de la soumission de la transaction indiquant qu'après exécution, il disposera de suffisamment de liquidités pour payer T (par exemple, avoir 1 million de dollars après la transaction). Ainsi, même s’il n’a pas assez de fonds avant l’exécution, il peut prouver sa capacité à payer ultérieurement. Le défi principal réside dans le fait que le proposant doit connaître l’état final de la transaction avant son exécution. Or, la plupart des transactions financières impliquent des états partagés (comme plusieurs transactions accédant au même solde de compte), rendant impossible pour le proposant de déterminer précisément l’état futur avant que l’ordre des transactions ne soit fixé. Cela nécessiterait des preuves personnalisées pour chaque type de transaction, ce qui diminue fortement la faisabilité pratique.
-
Censorship Insurance (Assurance contre la censure) : introduction de fournisseurs tiers d’assurance contre la censure (CI providers) qui garantissent le montant T pour le compte de l’utilisateur. En échange, l’utilisateur paie une prime rT, où r est calculé en fonction de la probabilité de censure. Cette solution réduit non seulement le besoin immédiat de disposer de grandes liquidités, mais permet aussi aux CI de signaler aux utilisateurs lorsque T est trop bas et que le risque de censure est élevé. Toutefois, la création d’un marché entre utilisateurs et fournisseurs CI nécessite du temps.
Opinions de la communauté sur FOCIL et BRAID
Terence, développeur du client Ethereum Prysm, souligne un avantage notable de BRAID : l’absence de participants supplémentaires. La plupart des conceptions basées sur des listes d’inclusion (IL), y compris FOCIL, nécessitent un rôle additionnel, ce qui ajoute des contraintes temporelles critiques au slot Ethereum — comme le délai de soumission de la IL, celui de mise à jour de l’offre ou encore celui de vérification par les validateurs. En revanche, FOCIL s’avère plus simple et flexible à mettre en œuvre que BRAID.
Dan Robinson, chercheur chez Paradigm, apprécie la conception de BRAID concernant le classement des priorités de transactions, qui évite que le leader (proposant unique) décide seul, atténuant efficacement le problème du MEV. De plus, le mécanisme de pourboires conditionnels incite au comportement non censeur, des aspects absents dans FOCIL.
Le développeur Dev préfère FOCIL au MCP, estimant que FOCIL offre une meilleure résistance à la censure combinée à une mise en œuvre simplifiée. Il a également proposé plusieurs améliorations pour faciliter encore davantage l’implémentation de FOCIL.
Barnabe.eth, chercheur sur Ethereum, considère FOCIL comme un mécanisme relativement universel et extensible. Bien qu’il reconnaisse que BRAID pourrait améliorer certaines garanties offertes par FOCIL, il adopte une position prudente quant à l’abandon complet du modèle basé sur un leader, jugeant qu’il ne s’agit pas encore d’un consensus et qu’il faudrait davantage de travaux pour en prouver la faisabilité.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@ChainFeedsxyz
