MEV-Boost est un protocole secondaire pour extraire le MEV dans Ethereum qui dépend fortement d'un participant centralisé appelé Relais. Nous proposons une architecture alternative qui permet une communication directe et cryptographiquement privée entre les constructeurs et les proposants. Cette architecture est basée sur une nouvelle forme de chiffrement de seuil non interactif et silencieux qui peut être utilisé avec les clés secrètes BLSC existantes des validateurs.

Essentiellement, nous proposons de chiffrer le Bloc à l'aide d'un chiffrement de seuil et de l'envoyer à une partie des participants pour assurer la confidentialité et la disponibilité des données en s'appuyant sur le comité de preuve. Leurs preuves forment la clé secrète de déchiffrement ; une fois le seuil requis atteint, le Bloc peut être déchiffré.

Notre solution de construction résout les problèmes de confidentialité entre les constructeurs et les proposants, mais elle ne garantit pas à elle seule l'efficacité du bloc. Elle peut être combinée avec d'autres mécanismes pour reproduire complètement les fonctionnalités fournies par le relais, y compris la confidentialité et l'efficacité du bloc. Par exemple, il est possible d'utiliser des preuves d'environnement d'exécution de confiance (TEE) ou des preuves de connaissances nulles (ZK), ou de fournir une garantie aux constructeurs par le biais d'un mécanisme économique de chiffrement.

En éliminant la nécessité de la confidentialité des constructeurs de Relais et en garantissant l'efficacité des Blocs, nous visons à réduire la latence, à améliorer la décentralisation et la résistance à la censure d'Ethereum.

Le rôle de MEV-Boost et Relais

MEV-Boost est un protocole intermédiaire de relais latéral, agissant en tant qu'intermédiaire entre les constructeurs de blocs et les proposants. Le rôle principal des relais (https://ethresear.ch/t/relays-in-a-post-epbs-world/16278#h-2-relay-roles-today-3) est de fournir deux garanties :

• Confidentialité du constructeur : Le relais garantit que le proposant ne peut pas voir le contenu du bloc et ne peut pas voler les MEV trouvés par le constructeur.
• Sécurité du proposeur : Le Relais garantit que les constructeurs paient au proposeur la valeur promise selon leur offre, et assure que le Bloc est valide (par exemple, tous les paiements de transactions couvrent les frais de gas internes).

Cependant, la dépendance à l'égard des Relais a introduit une centralisation significative. Environ 90% des blocs de la chaîne Ethereum sont transmis par quelques Relais seulement. Cela présente plusieurs risques :

• Décentralisation : Les constructeurs peuvent améliorer l'efficacité de latence en déployant conjointement avec les Relais, plutôt qu'en reflétant la répartition géographique des proposants. Cela affaiblit directement la Décentralisation géographique et la résistance à la censure que nous aurions pu obtenir en tirant parti d'un ensemble de validateurs répartis à grande échelle à l'échelle mondiale.
• Revenu: La latence moyenne de traitement de bloc de bout en bout de Relais efficace est d'environ 5 à 20 millisecondes. Ensuite, il y a aussi une latence de communication entre les constructeurs et les proposants. Le fait de sauter le Relais réduira la latence, mais augmentera le risque d'exécution transfrontalière (par exemple CEX/DEX) et finalement augmentera la récompense MEV des proposants.

TEE-Boost

L'une des principales propositions de remplacement de Relais est "TEE-Boost", qui repose sur des environnements d'exécution de confiance (TEEs). Il convient de noter que les TEE ne sont pas au cœur de notre solution ; utiliser TEE-Boost comme exemple d'enseignement pour le problème que nous cherchons à résoudre est très utile.

En particulier, TEE-Boost exige que les constructeurs utilisent des TEEs pour créer des preuves de l'honnêteté de leurs offres et de la validité des blocs, sans avoir à révéler le contenu réel des blocs aux soumissionnaires. Les soumissionnaires peuvent vérifier ces preuves sur un matériel ordinaire sans avoir à exécuter eux-mêmes des TEEs.

Cependant, TEE-Boost présente un problème de disponibilité des données: les constructeurs ne partagent que les preuves de TEE et les en-têtes de bloc avec les proposants, mais pas le contenu réel du bloc.[1], et il peut choisir de ne pas libérer le contenu du Bloc après la signature de l'auteur de la proposition (par exemple, si les conditions du marché changent défavorablement). Les méthodes proposées pour résoudre ce problème de disponibilité des données comprennent :

TEE-Guardian: TEE-Guardian obtient le Bloc de l'architecte avant que le proposant ne signe et libère ce Bloc après avoir vu l'en-tête de signature.

Couche de disponibilité des données : Les constructeurs publient la charge utile de chiffrement du Bloc dans la couche de disponibilité des données (DA).

Les deux méthodes ont leurs inconvénients. La solution de garde TEE copie une latence centralisée similaire à celle de Relais existants avec une dynamique SUP. 01928374656574839201[2]. Si une couche DA externe est utilisée, des hypothèses de protocole supplémentaires seront introduites et elle devra subir la latence dynamique de ce protocole externe (qui peut également être défavorable).

1. En théorie, si le proposant a également accès aux TEE, le constructeur peut chiffrer le bloc dans le TEE du proposant. Le TEE du proposant ne déchiffrera le bloc qu'après avoir été signé. Cependant, nous pensons que TEE-Boost n'a pas pris en compte cette conception car cela exigerait que les validateurs exécutent des TEE. Nous espérons que les validateurs pourront fonctionner sur du matériel ordinaire.

2. Si le proposant exécute lui-même la garde TEE en tant que fonction latente de la voiture latente déployée avec ses validateurs Nœud, il peut éviter le mouvement de latence.

Cependant, nous ne voulons pas non plus que les validateurs exécutent des TEEs.↩

La cryptographie à seuil pour assurer la confidentialité des constructeurs

Nous avons proposé une solution élégante pour faire face au problème de disponibilité des données de TEE-Boost : un chiffrement de seuil des comités de validation. Plus précisément, les constructeurs chiffreront le bloc à un ratio spécifié du comité de validation pour cette tranche horaire. Une fois suffisamment d'approbations collectées, le bloc pourra être déchiffré et utilisé.

La technologie sous-jacente activée est le chiffrement sans seuil. Cette technologie cryptographique permet le chiffrement sans seuil sans avoir à construire au préalable la configuration DKG (Distribution de Clés Interactives) requise. Au lieu de cela, la clé publique conjointe est calculée de manière déterministe en fonction des clés publiques BLS existantes des validateurs et de quelques "indices" (discutés ultérieurement).

Cela permet une communication directe en saut unique entre les constructeurs et les validateurs, avec une confidentialité cryptographique. Les validateurs n'ont pas besoin d'exécuter leurs propres TEEs ou de gérer tout nouveau matériel Clé secrète .

Mécanisme:

构建者构建一个Bloc并将其chiffrement到验证委员会。

Le constructeur crée une preuve TEE et prouve trois aspects au comité de validation: l'offre est honnête, le Bloc est valide et le chiffrement est correct.

Les constructeurs transmettent au proposeur les preuves chiffrées du bloc et du TEE (y compris la valeur d'offre) avec un [3]

Le proposant signe le chiffrement du bloc gagnant et propage cette proposition à l'ensemble des validateurs.

Une fois qu'un comité de validation, par exemple n/2 ou 2n/3, a certifié le Bloc, il sera déchiffré.

Le Bloc déchiffré sera confirmé normalement pour la dernière fois.

3. Il est nécessaire d'étudier l'impact des besoins en bande passante des proposants. Les proposants à faible bande passante peuvent limiter leurs besoins en utilisant une preuve de validation avant la demande du bloc principal, ou en utilisant d'autres techniques de filtrage heuristique et de téléchargement intelligent. Il s'agit d'un problème ouvert, mais il semble ne pas être plus difficile à résoudre que le problème habituel de propagation des spams dans le pool de mémoire. ↩

Attention

Performance

Les caractéristiques de performance du chiffrement des portes silencieuses sont assez avantageuses. Ici, n est la taille maximale du comité que nous souhaitons soutenir, t est le seuil de déchiffrement.

Le chiffrement et le temps partiel de déchiffrement sont tous deux constants. Avec une implémentation simple, le chiffrement prend moins de 7 millisecondes et peut être parallélisé. Le déchiffrement partiel prend moins de 1 milliseconde.

Le texte chiffré est plus grand que le texte clair de 768 octets, ce qui est un facteur d'ajout constant (pour tout n et t).

La déchiffrement partiel de l'agrégat (c'est-à-dire le déchiffrement) dépend de la taille du comité. Lorsque n=1024, l'implémentation simple prend moins de 200 millisecondes. Nous prévoyons que ce temps sera réduit de 10 fois lorsque n=128 (taille du comité d'authentification pour chaque intervalle), et que l'implémentation pourra être encore optimisée.

Il est important que le temps de chiffrement soit un indicateur de performance clé par rapport à la latence du relais. C'est quelque chose que les constructeurs doivent calculer dans le 'chemin critique' de génération de blocs. Ce temps est inférieur à la latence de traitement des blocs actuels du relais et évite les communications à sauts multiples.

Publication de données

La porte de silence n'est pas totalement gratuite. Il a en effet besoin d'une chaîne de référence commune, sous la forme : (g, gτ, gτ², …, gτⁿ⁻ᵗ), similaire au contenu utilisé pour le schéma d'engagement de polynômes KZG.

De plus, chaque validateur avec une clé publique de forme g⁽ˢᵏ⁾ BLSPublique publie un ensemble d'éléments de groupe que nous appelons "indices" : (g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). Ces indices ne sont nécessaires que lors de l'agrégation de la clé publique et du déchiffrement du texte chiffré. Le chiffrement n'utilise qu'une clé publique agrégée de taille constante.

Au moment de la rédaction de cet article, il y avait environ 1 million de validateurs. Si nous fixons n=128 et t=n/2, chaque validateur doit publier des indices d'environ 3 Ko. Par conséquent, l'espace de stockage requis pour tous les indices des validateurs est de 3 Go.

Avec l'activation de MaxEB, cette exigence pourrait Goutte de manière significative, MaxEB permet de contrôler plus de 32 ETH des validateurs détenant des soldes plus importants sous une seule Clé secrète (plutôt que de les répartir sur plusieurs dépôts de 32 ETH). La diminution du nombre de validateurs à mettre en œuvre reste à discuter. Nous pourrions descendre à environ 1 Go.

Enfin, selon les futures évolutions de l'architecture de consensus d'Ethereum (par exemple, la réduction supplémentaire de la taille des validateurs ou le remplacement de la chaîne finale de finalité), la taille des suggestions à stocker pourrait être encore réduite.

Vitalité

Le réseau ETH espère rester en ligne même dans des conditions réseau défavorables. Un problème de ce schéma est que des Blocs impossibles à déchiffrer peuvent survenir en raison de la mise hors ligne d'un pourcentage spécifié de comités.

Une solution consiste à permettre aux constructeurs de déterminer la proportion acceptable de comités (t) pour le déchiffrement. Il y a un compromis entre la confidentialité (la possibilité de déballer et de voler MEV) et la possibilité d'avoir un seuil de comité en ligne. Pour les constructeurs, maximiser leurs revenus consiste à faire en sorte que leur bloc soit inclus dans la chaîne plutôt que d'être forké, ils devraient donc trouver un paramétrage de seuil optimisé.[4]

Par ailleurs, l'utilisation de ce schéma de chiffrement devrait être volontaire. En cas de conditions réseau défavorables, si aucun comité d'acceptation viable n'est en mesure de rester en ligne de manière continue, les initiateurs et les constructeurs peuvent revenir à l'utilisation de relais, d'auto-hébergement ou d'autres mécanismes choisis en fonction de la nature des conditions défavorables.

Plus précisément, la valeur attendue du Bloc des constructeurs forké est négative (ils n'en tirent aucun revenu), tandis que la valeur attendue de l'unwrapping est très négative. Si les constructeurs doivent choisir t entre 0 et 128, ils devraient naturellement être incités à choisir un t suffisamment élevé pour réduire le risque de l'unwrapping Goutte et augmenter la probabilité de satisfaction (au moins t membres du comité en ligne). Dans des conditions normales de réseau, certains Blocs peuvent être forkés, mais nous notons que cela s'est déjà produit dans le jeu temporel et que la vitalité de la chaîne est toujours acceptable. [↩] (https://www.paradigm.xyz/2024/10/removing-the-relays#fn-ref-Liveness)

Blocs non disponibles

De plus, le comité peut être en ligne, mais le constructeur peut créer une situation où le Bloc ne peut pas être déchiffré ou est invalide lors du déchiffrement (par exemple, en utilisant une preuve frauduleuse).

Du point de vue du protocole, il est possible de forker ces Blocs. Il est simplement impossible pour un ensemble plus large de validateurs de prouver de tels Blocs, ou tout Bloc qui y fait référence. La meilleure façon de gérer cette erreur est peut-être de sensibiliser le client Consensus à cette possibilité et de lui permettre d'échouer de manière élégante. Cela nécessite des recherches supplémentaires.

Structure du marché

Les constructeurs gagnants savent ce qu'il y a dans le Bloc avant d'atteindre le seuil, ce qui peut entraîner un avantage injuste dans les périodes ultérieures. Cependant, le comité de validation devrait agir avant la fin de la prochaine période, et la majeure partie de la valeur du Bloc est concentrée à la fin de la période, de sorte que l'impact de cet avantage devrait être réduit autant que possible.

Preuve purement cryptographique

À long terme, il pourrait y avoir une opportunité de remplacer la preuve TEE par la preuve de connaissance nulle (ZK). Actuellement, la vitesse de la preuve ZK est trop lente, mais les progrès en cryptographie, logiciels et matériel spécialisé (ASIC) pourraient éventuellement rendre la génération de preuves ZK réalisable dans les limites de latence nécessaires. Il est à noter que la preuve ZK est déjà un élément clé de la feuille de route à long terme d'Ethereum. (https://x.com/VitalikButerin/status/1588669785218650112)

Utilisation

En fonction de la taille actuelle et du taux de croissance des validateurs, ce schéma peut ne pas justifier la quantité de données requise pour être publié sur L1. Cependant, Ethereum a déjà prévu de réduire considérablement le nombre de validateurs grâce à MaxEB.

La meilleure approche pourrait être de mettre à niveau le client de consensus avant ou après MaxEB pour que celui-ci puisse prendre en compte la possibilité sémantique du chiffrement des blocs et encourager les validateurs à publier des indices. Par exemple, après MaxEB, il serait possible de demander aux nouveaux validateurs de publier des indices, tandis que les anciens validateurs pourraient être incités à effectuer la mise à niveau.

Une fois qu'un nombre suffisant de validateurs adoptent ce mécanisme, les constructeurs commenceront à l'utiliser pour garantir une taille de comité suffisante (c'est-à-dire, en tenant compte de la possibilité de confidentialité et de déchiffrement).

Si notre méthode est effectivement supérieure en termes de latence par rapport au routage multi-saut, le marché devrait l'adopter spontanément, sans avoir besoin d'un protocole contraignant ou de paramétrages spécifiques imposés.

Principes de base

Relais est l'une des sources centralisées les plus importantes d'Ethereum, entraînant des opportunités de location et déformant la Décentralisation géographique du protocole. Nous devons supprimer les Relais et considérer cela comme une solution relativement élégante. Cela nécessite des modifications au niveau du consensus, mais les validateurs n'ont pas besoin de fournir de nouveaux matériels ou de Clé secrète.

Le problème est que c'est un changement complexe au niveau du consensus, et ce mécanisme (s'il est adopté de manière sélective comme suggéré) peut être accepté ou non par le marché. Cependant, de nombreux changements potentiels dans les canaux de MEV sont également confrontés à des problèmes similaires d'adoption et d'optimisation des bénéfices (par exemple, liste inclusive). De plus, d'autres cas d'utilisation à l'avenir pourraient dépendre d'une infrastructure de chiffrement avec un seuil de validation des validateurs.

Clause de non-responsabilité :

1. Cet article est reproduit à partir de [paradigm], the copyright belongs to the original authors [Charlie NoyesGuru, Vamsi Policharla], if you have any objections to the reprint, please contact the Gate Learn team, the team will handle it as soon as possible according to the relevant process.
2. Clause de non-responsabilité: Les opinions exprimées dans cet article ne représentent que l'opinion personnelle 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. Sans mention de Gate.io, il est interdit de copier, diffuser ou plagier l'article traduit.