MEV-Boost, le protocole side-car actuel pour l’extraction de MEV dans Ethereum, s’appuie fortement sur des acteurs centralisés appelés relais.

Nous proposons une architecture alternative qui permet une communication directe et cryptographiquement privée entre les constructeurs et les proposeurs. Elle est basée sur une forme novatrice et non interactive de chiffrement seuil "silencieux" qui peut utiliser les paires de clés BLS existantes des validateurs.

Essentiellement, nous nous appuyons sur le comité d'attestation pour la confidentialité et la disponibilité des données en chiffrant de manière seuil les propositions de bloc à une fraction des validateurs pour le créneau. Leurs attestations forment la clé de déchiffrement; une fois que le seuil souhaité a été attesté, le bloc peut être déchiffré.

Notre construction aborde la confidentialité entre les constructeurs et les demandeurs, mais ne garantit pas à elle seule la validité du bloc. Elle peut être combinée à d'autres mécanismes pour reproduire pleinement les fonctionnalités fournies par les relais, à la fois la confidentialité et la validité du bloc. Par exemple, des schémas de preuve tels que les preuves de l'environnement d'exécution de confiance (TEE) ou les preuves de connaissance nulle (ZK), ou des mécanismes cryptonomiques pour garantir les constructeurs.

En supprimant le besoin de relais pour assurer la confidentialité des constructeurs et garantir la validité des blocs, nous visons à réduire la latence et à améliorer la décentralisation et la résistance à la censure d'Ethereum.

MEV-Boost et le rôle des Relais

MEV-Boost est un protocole sidecar qui fait office d'intermédiaire entre les constructeurs de blocs et les proposants. The rôle principaldu relais est de fournir deux garanties:

• Confidentialité pour les constructeurs : Le relais garantit que les proposeurs ne peuvent pas voir le contenu du bloc et voler le MEV trouvé par le constructeur.
• Sécurité pour les soumissionnaires : Le relais garantit que le constructeur paie la valeur promise au soumissionnaire dans l'offre du constructeur et que le bloc est valide (par exemple, toutes les transactions paient des frais intrinsèques).

Cependant, la dépendance vis-à-vis des relais introduit une centralisation importante. Environ 90% des blocs sur Ethereum sont transmis par seulement quelques relais. Cela présente quelques risques :

• Centralisation : Les constructeurs peuvent être efficaces en termes de latence en se colocalisant avec les relais plutôt qu'en reflétant la distribution géographique des proposants. Cela mine directement la décentralisation géographique et la résistance à la censure que nous obtiendrions autrement à partir d'un grand ensemble de validateurs répartis dans le monde entier.
• Chiffre d’affaires : La latence moyenne de traitement des blocs de bout en bout des relais efficaces est d’environ 5 à 20 millisecondes. Ensuite, il y a une latence de communication entre le proposant et le constructeur. Le fait de sauter des relais réduira la latence, réduira les risques d’exécution inter-domaines (par exemple, CEX/DEX) et, en fin de compte, augmentera les récompenses MEV des proposants.

TEE-Boost

Une des principales propositions pour remplacer les relais est «TEE-Boost“, qui s'appuie sur les TEE (Environnements d'Exécution de Confiance). Notez que les TEE ne sont pas essentiels à notre schéma ; il est simplement utile d'utiliser TEE-Boost comme exemple pédagogique des problèmes que nous cherchons à résoudre.

Concrètement, TEE-Boost permet aux constructeurs d'utiliser des TEE pour créer des preuves démontrant aux proposants l'honnêteté de leurs offres et la validité de leurs blocs sans révéler le contenu réel des blocs aux proposants. Les proposants peuvent vérifier ces preuves sans exécuter eux-mêmes des TEE sur du matériel grand public.

Cependant, TEE-Boost a un problème de disponibilité des données : les constructeurs ne partagent qu'une preuve TEE et des en-têtes de bloc avec les proposants, pas le contenu réel des blocs.^[1] et peut choisir de ne pas publier le contenu du bloc même après que le proposant ait signé l'en-tête (par exemple, si les conditions du marché changent défavorablement). Les approches suggérées pour résoudre ce problème de DA sont:

• [ ] TEE-Escrow : Un TEE-Escrow obtient le bloc du constructeur avant que le proposant ne le signe et le libère une fois qu’il voit l’en-tête signé.
• [ ] Couches de disponibilité des données: les constructeurs envoient des charges utiles de blocs cryptées à une couche de disponibilité des données (DA).

Les deux approches ont des inconvénients. La solution d'entiercement TEE reproduit la dynamique de latence de centralisation similaire à celle des relais existants.^[2]L'utilisation d'une couche DA externe introduit une hypothèse extra-protocole et supporte les dynamiques de latence de ce protocole externe (qui sont également probablement défavorables).

1. Théoriquement, si les proposants avaient également accès aux TEE, les constructeurs pourraient chiffrer leurs blocs vers un TEE géré par le proposant. Le TEE du proposant ne décrypterait le bloc qu'après l'avoir signé. Cependant, nous pensons que TEE-Boost ne prend pas en compte cette conception car cela nécessiterait que les proposants (validateurs) exécutent des TEE. Nous voulons que les validateurs puissent fonctionner sur du matériel grand public.↩

2. La dynamique de latence peut être évitée si les soumissionnaires eux-mêmes exécutent TEE-Escrow en tant que sidecar colocalisé à leur nœud valideur. Cependant, encore une fois, nous ne voulons pas que les validateurs exécutent des TEE.↩

Cryptographie seuil pour atteindre la confidentialité du constructeur

Nous proposons une solution élégante au problème DA de TEE-Boost : le chiffrement seuil au comité des validateurs. Plus précisément, le seuil du constructeur chiffre le bloc à une fraction spécifiée du comité des validateurs pour ce créneau. Une fois suffisamment d'attestations sont rassemblées, le bloc devient déchiffrable et disponible.

La technologie clé permettant cela estCryptage de seuil silencieux. Cette technique cryptographique permet un cryptage de seuil sans exiger de phase de configuration interactive de génération de clés distribuées (DKG), comme le requéraient les constructions précédentes. Au lieu de cela, la clé publique commune est calculée de manière déterministe à partir des clés publiques BLS déjà existantes de l'attestant plus quelques "indices" (discutés ultérieurement).

Cela permet une communication directe à un seul saut entre le constructeur et le validateur avec une confidentialité cryptographique. Les validateurs ne sont pas tenus d'exécuter eux-mêmes des TEE ou de gérer de nouveaux matériaux clés.

Mécanique:

Le constructeur construit un bloc et l'encrypte pour le comité d'attestants.

Le constructeur construit une preuve TEE démontrant trois choses au comité d'attestation : que l'offre est honnête, que le bloc est valide et qu'il est correctement chiffré.

Le constructeur communique le bloc chiffré seuil et la preuve TEE (qui inclut la valeur de l'offre) au proposant.^[3]

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

Une fois que la fraction spécifiée (par exemple n/2 ou 2n/3) du comité des validateurs n-attester pour le créneau atteste du bloc, il est déchiffré.

Le bloc déchiffré se poursuit normalement jusqu'à la finalisation.

1. L'effet sur les exigences de bande passante des demandeurs doit être étudié. Les demandeurs à faible bande passante pourraient limiter leurs besoins en vérifiant les preuves avant de demander le corps du bloc, ou en utilisant d'autres techniques de filtrage heuristique et de téléchargement intelligent. Il s'agit d'une question ouverte, mais il semble probablement pas plus difficile à résoudre que les problèmes habituels de spam de la mémoire tampon.↩

Considérations

Performance

Les caractéristiques de performance du cryptage de seuil silencieux sont assez favorables. Ici

n est la taille maximale du comité que nous souhaitons prendre en charge et t est le seuil de déchiffrement.

Tant le chiffrement que le déchiffrement partiel sont effectués en temps constant. Avec une implémentation naïve, le chiffrement prend <7 ms - et cela peut être parallélisé. Le déchiffrement partiel prend <1 ms.

La taille du texte chiffré est un facteur additif constant, 768 octets, plus grande que le texte en clair (pour tout n et t).

L'agrégation des déchiffrements partiels (c'est-à-dire le déchiffrement) dépend de la taille du comité. Avec n=1024, une implémentation naïve prend <200ms. Nous prévoyons qu'avec n=128 (la taille du comité d'attestation pour chaque créneau), cela diminuera d'un facteur de 10 et que l'implémentation pourra être encore optimisée.

De manière importante, le temps de chiffrement est le nombre clé de performance à comparer à la latence du relais. C'est ce que le constructeur doit calculer dans le "chemin critique" de la production de blocs. Il est inférieur à la latence de traitement de bloc du relais existant et évite la communication multi-sauts.

Publication de données

Le cryptage du seuil silencieux n'est pas entièrement gratuit. Il nécessite une chaîne de référence commune de la forme : (g,g^τ,g^τ2,...,g^τn−t), similaire à ce qui est utilisé pour le schéma d’engagement polynomial KZG.

De plus, chaque validateur ayant une clé publique BLS de la forme gsk publie un ensemble d'éléments de groupe que nous appelons des "indices" : (g^sk⋅τ,…,g^sk⋅τn−t). Ces indices ne sont nécessaires que pour agréger les clés publiques et décrypter les textes chiffrés. Le chiffrement n'utilise qu'une clé publique agrégée de taille constante.

Au moment de la rédaction de ce post, il y a environ 1 million de validateurs. Si nous fixons n=128 et t=n/2, chaque validateur doit publier ≈ 3 Ko d'indices. Ainsi, stocker les indices de tous les validateurs nécessite 3 Go.

Cette exigence diminuera probablement considérablement avec le activation de MaxEB, ce qui permet aux validateurs contrôlant >32 ETH de détenir des soldes plus importants sous la même paire de clés (plutôt que de les diviser en plusieurs dépôts de 32 ETH). La réduction de l'ensemble des validateurs qui sera réalisée est sujette à débat. Il semble possible que nous puissions descendre à ~1 Go.

Enfin, en fonction des changements futurs de l'architecture de consensus d'Ethereum (par exemple, des réductions supplémentaires de la taille de l'ensemble de validateurs, ou des alternatives de canalisation de finalité), la taille des indications à stocker pourrait encore diminuer.

Vivacité

Ethereum souhaite rester en ligne même dans des conditions réseau défavorables. Un problème avec ce schéma est la possibilité de blocs qui ne peuvent pas être déchiffrés car la fraction spécifiée du comité est hors ligne.

Une solution consiste à permettre au constructeur de décider de la fraction acceptable (𝑡) du comité pour le déchiffrement. Il y a un compromis entre la confidentialité (la possibilité de dégroupage et de vol de MEV) et la probabilité que le seuil du comité soit en ligne. Pour maximiser leurs revenus, les constructeurs doivent faire en sorte que leurs blocs soient inclus, plutôt que d'être exclus, ils devraient donc trouver un paramètre de seuil optimisé.^[4]

De plus, l'utilisation de ce schéma de chiffrement devrait être facultative. Dans des conditions réseau défavorables, où aucun comité d'une taille acceptable n'est disponible de manière cohérente, les proposants et les bâtisseurs pourraient recourir à des relais, à l'auto-construction ou à tout autre mécanisme préférable compte tenu de la nature de l'environnement défavorable.

1. L'affirmation spécifique ici est que c'est une EV négative pour un bloc de constructeur d'être forké (ils ne reçoivent aucune recette de cela), et une EV très négative pour être dégroupé. Si vous donnez au constructeur la possibilité de choisir t dans [0,128], ils devraient être naturellement incités à sélectionner t suffisamment élevé pour qu'il y ait très peu de risque de dégroupage et une forte probabilité d'être satisfait (au moins t membres du comité étant en ligne). Certains blocs seraient probablement forkés même dans des conditions normales de réseau, mais nous notons que cela se produit déjà avec des jeux de synchronisation, et la vivacité de la chaîne reste acceptable.↩

Blocs non disponibles

Alternativement, le comité peut être en ligne, mais un constructeur peut être capable de créer une situation dans laquelle le bloc est soit incapable d'être déchiffré, soit invalide lors du déchiffrement (par exemple, avec des preuves frauduleuses).

Du point de vue du protocole, il n’y a pas de problème à débourser ces blocs. L’ensemble plus large des validateurs ne pouvait tout simplement pas les attester ou les blocs qui y font référence. La meilleure façon de gérer ce type d’erreur est probablement de rendre le client de consensus conscient de la possibilité et capable d’échouer gracieusement. Une étude plus approfondie sur la façon exacte serait nécessaire.

Structure du marché

Le constructeur gagnant connaît le contenu du bloc avant les autres jusqu'à ce que le seuil soit atteint, ce qui pourrait créer un avantage injuste dans les emplacements suivants. Cependant, le comité des validateurs est censé agir avant la fin de l'emplacement suivant, et la majorité de la valeur du bloc se trouve à la fin de l'emplacement, de sorte que les effets de cet avantage devraient être aussi minimes que possible.

Preuves purement cryptographiques

À long terme, il pourrait être possible de remplacer les preuves TEE par des preuves de connaissance zéro (ZK). Actuellement, les preuves ZK sont trop lentes, mais les avancées en cryptographie, en logiciels et en matériel spécialisé (ASIC) pourraient éventuellement rendre la génération de preuves ZK réalisable dans les contraintes de latence nécessaires. Notamment, les preuves ZK accompagnant les blocs existent déjà dans la technologie Gate.partie centrale de la feuille de route à long terme d'Ethereum.

Adoption

Avec la taille actuelle de l'ensemble des validateurs et le taux de croissance, ce schéma peut ne pas valoir la quantité de données requise pour être publiée sur L1. Cependant, Ethereum prévoit déjà de réduire considérablement le nombre d'ensemble des validateurs avec MaxEB.

La meilleure approche serait probablement une mise à niveau avec ou après MaxEB dans laquelle les clients de consensus sont informés de la possibilité de sémantiques de blocs chiffrés et les validateurs sont encouragés à publier des indices. Par exemple, après MaxEB, il pourrait être nécessaire que les nouveaux validateurs publient des indices, et les anciens validateurs pourraient être incités à effectuer une mise à niveau.

Les constructeurs commenceraient à utiliser le mécanisme une fois qu'une fraction suffisante de l'ensemble des validateurs l'aurait adopté pour avoir des tailles de comité suffisantes (c'est-à-dire à la fois une confidentialité acceptable et une probabilité de déchiffrement suffisante).

Si notre approche présente effectivement une latence favorable par rapport au relais multi-sauts, le marché devrait l'adopter sans que le protocole ait besoin d'imposer son utilisation ou d'inscrire une paramétrisation spécifique.

Raison

Les relais sont l'une des sources de centralisation les plus importantes d'Ethereum, créant des opportunités de recherche de location et déformant la décentralisation géographique du protocole.

Nous devons supprimer les relais et penser que c’est une façon relativement élégante de le faire. Il nécessite des modifications au niveau de la couche de consensus, mais aucun nouveau matériel ou matériel de clé n’est requis de la part des validateurs.

L'inconvénient est que c'est un changement complexe de la couche de consensus pour un mécanisme qui (s'il est facultatif, comme suggéré) peut ou non être adopté par le marché. Cependant, de nombreux changements potentiels du pipeline de la valeur extractible en attente (MEV) soulèvent des questions similaires d'adoption et d'optimisation des revenus (par exemple, listes d'inclusion). Et il peut y avoir d'autres cas d'utilisation futurs qui dépendent de l'ensemble des validateurs ayant une infrastructure d'encryption de seuil disponible.

Avertissement :

1. Cet article est repris de [ paradigme]. Tous les droits d'auteur appartiennent à l'auteur original [Charlie NoyesGuru, Vamsi Policharla]. S'il y a des objections à cette reproduction, veuillez contacter le Porte d’apprentissagel'équipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.