jakiro
Auteur: 0xnatalie
Au cours du processus de génération et de vérification des blocs Ethereum, le constructeur est responsable de la sélection et du tri des transactions dans le pool de transactions et de la soumission des blocs au proposant via un mécanisme d’enchères.Le proposant sélectionne un bloc dans ces blocs soumis pour la signature et le propose à la blockchain.Étant donné que le proposant, en tant qu’entité unique, a l’option ultime, cela entraîne le risque de collusion possible entre le proposant et le constructeur pour examiner la transaction.
L’une des valeurs fondamentales de la blockchain est sa résistance à la censure, c’est-à-dire que n’importe qui peut échanger sans interférence de l’autorité centrale.Cette fonctionnalité est menacée lorsque le proposant peut contrôler les transactions incluses dans le bloc.Blesser l’équité et la transparence.Et ce pouvoir peut être utilisé pour manipuler l’ordre des transactions dans le bloc, obtenant ainsi des avantages économiques supplémentaires, causant des problèmes de MEV.
Solutions anti-censure existantes
Pour relever ce défi, la communauté a proposé une variété de solutions anti-censure, telles que la liste d’inclusion forcée (FOCIL).Dans le mécanisme FOCIL, chaque créneau (créneau horaire) sélectionnera au hasard un groupe de validateurs pour former un comité contenant des listes.Ces membres du comité génèrent des listes d’inclusion locales en fonction de leurs opinions subjectives respectives du pool de transactions (MEMPOOL).Le proposant est responsable de la collecte et de l’agrégation de ces listes locales pour former une liste globale et les inclure dans le bloc.Ce mécanisme garantit l’équité des blocs, car le validateur vérifiera l’exactitude de la liste agrégée basée sur la liste locale qui a été diffusée précédemment, et seuls les blocs qui respectent les règles de consensus seront acceptés et ajoutés à la blockchain.
En plus de FOCIL, la communauté a également discuté des schémas de multiples proposeurs de concurrence (MCP).Ce concept a d’abord été proposé par Max Resnick dans le mécanisme multiplicatif, visant àRéduisez la capacité d’un seul nœud à examiner les transactions en introduisant plusieurs proposants de blocs parallèles pour diversifier la puissance.Dans le mécanisme de multiplicabilité, chaque validateur sélectionnera une partie de la transaction dans son pool de trading pour former un « package de transaction spécial ».Ces validateurs signent et envoient leur package de transaction sélectionné au proposant du tour actuel.Une fois que le proposant l’a reçu, il doit inclure au moins 2/3 des packages de transactions dans son bloc proposé.Ce n’est que de cette manière que ce bloc peut être considéré comme valide.Ce mécanisme garantit que le proposant ne peut pas décider séparément le contenu du bloc, réduisant ainsi la possibilité de censure.Pour inciter davantage les proposants à inclure équitablement les transactions, ce mécanisme met en œuvre la règle « Tip conditionnel », c’est-à-dire que seuls les proposants qui incluent la transaction peuvent recevoir des conseils de transaction.La pointe de la transaction n’est pas automatiquement donnée au premier proposant contenant la transaction, mais est distribué à tous les proposants qui contiennent réellement la transaction en fonction de certaines conditions.Cela augmente le coût de l’examen, et si vous souhaitez examiner, vous devez soudoyer tous les proposants qui incluent la transaction.
Tresse: solution d’implémentation MCP améliorée
Sur la base de la multiplicabilité, Max Resnick a en outre proposé la tresse, qui est une implémentation MCP plus complexe et plus complète.Lors d’un séminaire sur « Defi in Mev Era » tenu par paradigme, Max a présenté la tresse.Braid implémente MCP en permettant à plusieurs proposants de proposer des blocs sur différentes chaînes parallèles et en utilisant un mécanisme de consensus synchrone pour maintenir la cohérence inter-chaîne.Chaque chaîne a son propre proposant et tous les proposants publient leurs blocs simultanément dans la même machine à sous.La couche d’exécution Ethereum collecte toutes les transactions de bloc générées par les sous-chaines de cette fente pour former un bloc d’exécution et déduir, trier et exécuter ces transactions en fonction des règles prédéterminées, réduisant ainsi la manipulation d’enregistrement de transaction par n’importe quelle entité.
La conception de la tresse n’introduit pas de rôles supplémentaires, évitant ainsi la complexité du mécanisme d’incitation / punition, mais sa mise en œuvre est relativement complexe et nécessite une coordination de la synchronisation et du traitement des données de plusieurs sous-chaînes.
Problèmes avec le mécanisme des tresses
L’équipe de Blockchain Capital Jonahb a souligné un problème dans le mécanisme des tresses: le modèle « Tip conditionnel » a des exigences de liquidité, ce qui affecte l’impact de l’expérience utilisateur.Ce modèle est une stratégie de prix dynamique qui oblige les utilisateurs à préparer une certaine liquidité pour assurer la résistance à la censure de la transaction.Les utilisateurs doivent définir deux valeurs de conseils (T et T) lors de la soumission d’une transaction.Les conseils réels versés à la fin dépendent du nombre de proposants contenant la transaction.
Pointe supérieure t: Représente les frais maximaux que l’utilisateur est prêt à payer pour s’assurer que la transaction n’est pas examinée.Le but est d’inciter le proposant à choisir d’inclure lorsqu’aucun autre proposant n’est disposé à inclure une transaction.Finalement, si un seul proposant est prêt à l’inclure, il obtient un T.
Pointe inférieure t: Il s’agit d’un montant inférieur défini par l’utilisateur.T sera alloué entre plusieurs proposants.Si l’utilisateur n’est pas préoccupé par la résistance à la censure, il peut définir T = T et envoyer ses transactions à un seul proposant.
Cependant, cette exigence de liquidité supplémentaire augmente la complexité et le coût de la participation aux transactions blockchain.Ces fonds réservés sont gelés jusqu’à ce qu’ils soient réellement utilisés.
À cet égard, Jonahb a proposé deux solutions:
-
Preuve de liquidité après l’État: Lors de la soumission d’une transaction, l’utilisateur fournit une preuve qu’il y aura une liquidité suffisante après l’exécution de la transaction pour payer t (par exemple, l’utilisateur aura une liquidité de 1 million de dollars après la transaction).De cette façon, même s’il n’y a pas suffisamment de fonds pour payer avant la transaction, l’utilisateur peut payer après la transaction par preuve.Le défi de cette approche est que le proposant doit comprendre l’état final de la transaction avant l’exécution de la transaction, mais la plupart des transactions financières impliquent un état partagé (tel que les transactions multiples partagent le même solde du compte), de sorte que le proposant ne peut juger avec précision jusqu’à ce que le Le tri des transactions est déterminé.Cela nécessite une preuve personnalisée pour chaque type de transaction, ce qui est moins pratique.
-
Assurance censure: Présentation d’un fournisseur d’assurance d’examen tiers (fournisseur CI) pour fournir des garanties à T.L’utilisateur paie une prime d’assurance RT pour cela, où R est calculé en fonction de la possibilité que la transaction soit examinée.Cette solution réduit non seulement la nécessité pour les utilisateurs de se préparer immédiatement à de grandes quantités de liquidité, mais rappelle également aux utilisateurs que T est trop faible et qu’il y a un risque élevé d’examen via CI.Mais il faut du temps pour créer un marché entre les utilisateurs et les fournisseurs de CI.
Opines de la communauté sur FOCIL et tresse
Client Ethereum Prysm développeurTerence estime qu’un avantage significatif de la tresse est qu’il ne nécessite pas de participants supplémentaires.Dans la plupart des conceptions de la liste d’inclusion (IL), y compris FOCIL, un participant supplémentaire est requis, ce qui ajoute des contraintes de temps dans les créneaux horaires Ethereum, tels que le temps de soumettre IL, le temps de mettre à jour les offres et les vérifications du validateur.Cependant, la solution focil est plus simple et plus flexible que la tresse.
Le chercheur de paradigme, Dan Robinson, apprécie la conception de Braid dans la priorisation des transactions, plutôt que d’être décidé par le leader (proposant unique) pour atténuer efficacement le MEV.De plus, les mécanismes de basculement conditionnels en tresse incitent les comportements non censurés, qui ne se reflètent pas dans FOCIL.
Dev, un développeur, préfère Focil sur MCP, estime que FOCIL a plus d’avantages à fournir une forte résistance et à simplifier la mise en œuvre.Et certaines améliorations sont fournies pour faciliter la mise en œuvre du focil.
Le chercheur d’Ethereum Barnabe. Ce n’est pas un consensus pour le moment et plus de travail est nécessaire pour prouver sa faisabilité.
