Dans le processus de production et de validation des blocs Ethereum, les constructeurs sont responsables de l'ordonnancement des transactions et soumettent des blocs aux proposeurs via un mécanisme d'enchères. Les proposeurs sélectionnent ensuite un bloc à signer et le proposent à la blockchain. Étant donné que les proposeurs ont le dernier mot en tant qu'entité unique, il existe un risque de collusion entre les proposeurs et les constructeurs pour censurer les transactions.

Une des valeurs fondamentales de la blockchain est sa résistance à la censure, ce qui signifie que les transactions peuvent être effectuées sans ingérence des autorités centrales. Lorsque les proposants contrôlent quelles transactions sont incluses dans un bloc, cette fonctionnalité est menacée, compromettant ainsi l'équité et la transparence. De plus, ce pouvoir peut être exploité pour manipuler l'ordre des transactions dans un bloc, entraînant des gains économiques supplémentaires et soulevant des problèmes liés à la valeur extractible par les mineurs (MEV).

Solutions existantes résistantes à la censure

Pour relever ce défi, la communauté a proposé plusieurs solutions anti-censure, telles que les listes d’inclusion forcée (FOCIL). Dans le mécanisme FOCIL, un ensemble de validateurs est sélectionné de manière aléatoire pour chaque créneau afin de former un comité de liste d'inclusion. Ces membres du comité génèrent des listes d'inclusion locales basées sur leur point de vue subjectif du pool de mémoire et les diffusent. Les proposants sont alors responsables de collecter et d'agréger ces listes locales en une seule liste agrégée à inclure dans le bloc. Ce mécanisme garantit l'équité dans l'inclusion de blocs car les validateurs vérifient la liste agrégée par rapport aux listes locales précédemment diffusées, et seuls les blocs qui respectent les règles de consensus sont acceptés et ajoutés à la chaîne de blocs.

En plus de FOCIL, la communauté a également discuté des schémas de Proposants Concomitants Multiples (MCP). Ce concept a été initialement proposé par Max Resnickdans leMultiplicitémécanisme, qui vise à disperser le pouvoir en introduisant plusieurs proposants de blocs parallèles, réduisant ainsi la capacité de tout nœud individuel à censurer les transactions. Dans le mécanisme de la Multiplicité, chaque validateur sélectionne une partie des transactions de son propre mempool pour former un “paquet de transactions spécial.” Ces validateurs signent leurs paquets de transactions choisis et les envoient au proposant du tour actuel. Le proposant doit inclure au moins 2/3 de ces paquets de transactions dans le bloc qu'il propose pour qu'il soit considéré comme valide. Ce mécanisme garantit que les proposants ne peuvent pas décider unilatéralement du contenu du bloc, réduisant ainsi la possibilité de censure. Pour inciter davantage les proposants à inclure les transactions équitablement, ce mécanisme met en œuvre une règle de “tip conditionnel”, où seuls les proposants qui incluent la transaction reçoivent les frais de transaction. Les frais de transaction ne sont pas automatiquement attribués au premier proposant qui inclut la transaction, mais sont distribués à tous les proposants qui incluent effectivement la transaction en fonction de conditions spécifiques. Cela augmente le coût de la censure, car il serait nécessaire de soudoyer tous les proposants qui incluent la transaction.

BRAID : une implémentation MCP améliorée

S'appuyant sur le concept de Multiplicity, Max Resnick a introduit BRAID, une implémentation plus complexe et raffinée de MCP. Max a présenté BRAIDlors du séminaire « DeFi in the MEV Era » organisé par Paradigm. BRAID atteint MCP en permettant à plusieurs proposeurs de proposer des blocs sur différentes chaînes parallèles et en utilisant un mécanisme de consensus de synchronisation pour maintenir la cohérence entre ces chaînes. Chaque chaîne a son propre proposeur, et tous les proposeurs libèrent leurs blocs simultanément dans la même fente. La couche d'exécution Ethereum agrège les blocs générés par toutes les sous-chaînes dans cette fente, formant un bloc d'exécution. Ensuite, il dédouble, trie et exécute ces transactions selon des règles prédéfinies, réduisant la capacité de toute entité unique à manipuler les enregistrements de transaction.

La conception de BRAID évite d'introduire des rôles supplémentaires, évitant ainsi les complexités associées aux mécanismes d'incitation/punition. Cependant, sa mise en œuvre est relativement complexe, nécessitant la coordination de la synchronisation et du traitement des données de plusieurs sous-chaînes.

Problèmes avec le mécanisme BRAID

Jonahbde l'équipe Blockchain Capital a souligné unproblèmeavec le mécanisme BRAID: le modèle de "pourboire conditionnel" impose des exigences de liquidité, affectant l'expérience utilisateur. Ce modèle est une stratégie de tarification dynamique qui exige des utilisateurs de fournir une certaine quantité de liquidité pour assurer la résistance à la censure des transactions. Lors de la soumission d'une transaction, les utilisateurs doivent définir deux valeurs de pourboire (T et t). Le pourboire réellement payé dépend du nombre de proposants qui incluent la transaction.

1. Une valeur de pourboire plus élevée, T, représente les frais maximum qu'un utilisateur est prêt à payer pour s'assurer que sa transaction n'est pas censurée. Le but est d'inciter les proposants à inclure la transaction même si aucun autre proposant n'est prêt à le faire. Si un seul proposant inclut la transaction, il reçoit la totalité du montant, T.
2. Une valeur de pourboire plus faible, t, est le montant minimum fixé par l'utilisateur. Si la transaction est incluse simultanément par plusieurs proposants, l'utilisateur n'a besoin de payer que t, qui sera partagé entre les proposants. Si l'utilisateur se soucie moins de la résistance à la censure, il peut fixer T égal à t et envoyer sa transaction à un seul proposant.

Cependant, cette exigence supplémentaire de liquidité augmente la complexité et le coût de la participation aux transactions blockchain. Les utilisateurs doivent réserver des fonds supplémentaires au moment de la transaction uniquement pour garantir sa résistance à la censure. Ces fonds réservés restent gelés jusqu'à leur utilisation réelle.

Pour résoudre ce problème, Jonahb a proposé deux solutions:

• Preuve de liquidité post-état: les utilisateurs fournissent une preuve au moment de la soumission de la transaction, indiquant qu'ils auront une liquidité suffisante pour payer T après l'exécution de la transaction (par exemple, l'utilisateur disposera de 1 million de dollars de liquidité après la transaction). Cette méthode permet aux utilisateurs de procéder même s'ils n'ont pas suffisamment de fonds pour payer T avant la transaction. Le défi de cette approche est que les proposants doivent connaître l'état final de la transaction avant l'exécution. Cependant, de nombreuses transactions financières impliquent des états partagés (comme plusieurs transactions affectant le même solde de compte), ce qui rend difficile pour les proposants de déterminer avec précision l'état post-transaction avant que l'ordre de transaction ne soit finalisé. Cette approche nécessite des preuves personnalisées pour chaque type de transaction, ce qui la rend moins pratique.
• Assurance contre la censure : introduit des fournisseurs d'assurance contre la censure tiers (fournisseurs CI) pour garantir la T de l'utilisateur. Les utilisateurs paient une prime d'assurance, rT, où r est basé sur la probabilité que la transaction soit censurée. Cette approche réduit le besoin pour les utilisateurs de préparer immédiatement une grande quantité de liquidité et peut alerter les utilisateurs si leur T est trop faible et à haut risque de censure. Cependant, l'établissement d'un marché entre les utilisateurs et les fournisseurs CI prend du temps.

Réflexions de la communauté sur FOCIL vs. BRAID

Développeur de client Ethereum PrysmTerence notesun avantage significatif de BRAID est qu'il ne nécessite pas de participants supplémentaires. La plupart des conceptions de liste d'inclusion (IL), y compris FOCIL, nécessitent un participant supplémentaire, ce qui ajoute des contraintes de temps dans les slots Ethereum, tels que le temps de soumission de l'IL, la mise à jour des offres et la vérification des IL par les validateurs. Cependant, FOCIL est plus simple et plus flexible à mettre en œuvre par rapport à BRAID.

Chercheur de paradigmeDan Robinson apprécieLa conception de BRAID pour la priorisation des transactions, qui n'est pas déterminée par un seul leader (proposant), atténue efficacement les MEV. De plus, le mécanisme de pourboire conditionnel de BRAID incite à un comportement non censurant, ce qui n'est pas présent dans FOCIL.

Développeur Le développeur préfèreFOCIL sur MCP, croyant que FOCIL offre une résistance plus forte à la censure et est plus simple à mettre en œuvre. Il suggère également quelques améliorations pour rendre FOCIL plus facile à déployer.

chercheur Ethereumbarnabe.eth vuesFOCIL est un mécanisme assez général et évolutif. Il reconnaît que BRAID pourrait améliorer certaines des garanties fournies par FOCIL, mais il est prudent quant à l'abandon complet du modèle basé sur un leader. Il estime qu'il est nécessaire de travailler davantage pour prouver la faisabilité de BRAID.

déclaration :

1. Cet article est reproduit de [ChainFeeds Recherche], le titre original est “Ethereum’s road to censorship resistance: Who is better, BRAID or FOCIL?”, les droits d'auteur appartiennent à l'auteur original [0XNATALIE], si vous avez des objections à la reproduction, veuillez contacterÉquipe d'apprentissage de Gate , l'équipe s'en occupera dès que possible selon les procédures pertinentes.

2. Avertissement: Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent pas un conseil en investissement.

3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn, non mentionnées dans Gate.ioL'article traduit ne peut être reproduit, distribué ou plagié.