Analyse des avantages et des inconvénients des proposeurs concurrents multiples (MCP)

Auteur : Maven11 ; Traduction : Jinse Caijing xiaozou

Les Proposeurs Concurrentiels Multiples (Multiple Concurrent Proposers, ci-après MCP) désignent un mécanisme permettant à plusieurs proposeurs d'être simultanément actifs (attention à ne pas le confondre avec le Protocole Multi Contexte ou le Calcul Multipartite Sécurisé, bien qu'il existe certaines similitudes entre eux). C'est une solution innovante pour résoudre le problème de la censure. Cet article explorera pourquoi il est essentiel de confier la proposition de blocs à plusieurs proposeurs plutôt qu'à un seul, y compris son fonctionnement et sa signification en termes de mise en œuvre.

Bien que le concept de base de MCP soit relativement facile à comprendre, il n'y a pratiquement aucune adoption réelle de ce mécanisme dans la blockchain à l'heure actuelle. Cependant, dans une certaine mesure, le modèle de fonctionnement des pools de minage de Bitcoin présente des similarités avec les propositions concurrentes multiples : toute personne exécutant un nœud complet Bitcoin peut faire en sorte qu'une transaction soit intégrée à la blockchain.

D’autre part, le mécanisme de construction multi-simultané de Solana a quelques points communs avec la mise en œuvre d’un MCP complet, reflétant au moins l’idée de plusieurs participants différents participant à la construction de blocs (mais pas à la proposition de blocs). Sur Ethereum, environ 95% des blocs sont construits via MEV-Boost. Bien qu’il y ait plusieurs constructeurs actifs en même temps, il ne peut y avoir qu’un seul gagnant par enchère, de sorte que l’avantage que Solana obtient grâce à plusieurs constructeurs simultanés ne tient pas ici. En fait, il n’existe actuellement aucune chaîne qui permette à plusieurs proposants d’avoir le droit de proposer des blocs à tout moment.

La façon la plus intuitive de comprendre le MCP est de le décomposer en deux niveaux : plusieurs proposeurs fournissant simultanément des blocs, ainsi que la fusion finale de ces sous-blocs.

Ces groupes de proposeurs adopteront probablement une forme de sous-comité (similaire au mécanisme existant d'Ethereum), car il n'est pas réaliste de faire participer tous les validateurs. Cela signifie également qu'il faut s'assurer qu'aucun sous-comité ne soit monopolisé par un pool de staking particulier, sinon cela pourrait entraîner des problèmes de censure et de collusion. De plus, il convient de noter que les prétendus stakers familiaux ont généralement des compétences techniques limitées - le MCP augmentera considérablement la complexité du système.

Voici les avantages clés de MCP qui méritent d'être adoptés :

Raisons de soutenir plusieurs proposeurs concurrents :

--Renforcer la résistance à la censure (particulièrement important dans le contexte actuel)

--Élargir au niveau du protocole de base plutôt que de s'appuyer sur des solutions externes

--MEV dispersé (plus décidé par un seul proposant ou constructeur pour le regroupement des transactions)

Problèmes directement exposés par la mise en œuvre de MCP :

-- Intensification de la concurrence pour le classement des transactions (emballage et ordre) (peut-elle entraîner l'émergence du phénomène PGA ?)

--Défis simulés causés par des transactions non valides

--Exigences matérielles accrues

--Problèmes de disponibilité des données pour les transactions invalides

--nécessité d'introduire des outils de finalité

Analysons ces caractéristiques point par point, en commençant par les avantages, puis en évaluant si les problèmes potentiels pourraient constituer des obstacles à la mise en œuvre des blockchains publiques à forte charge technique.

1. Avantages de MCP

(1) Renforcer la résistance à la censure

La plupart des blockchains qui adoptent un mécanisme de finalité déterministe dépendent d'un leader unique pour décider du contenu des blocs (avec de légères variations). Après la diffusion des blocs, la majorité des validateurs parviennent à un consensus et les intègrent dans la chaîne principale. Ethereum accélère le processus de création de blocs grâce à un mécanisme de sous-comité (mais l'atteinte du consensus par l'ensemble des validateurs prend plus de temps). Dans le cadre du MCP, plusieurs proposeurs construisent chacun des blocs locaux qui sont ensuite fusionnés, ce qui signifie que l'entrée des blocs passe d'un sujet unique (proposeur/concepteur/relais, idéalement le MCP devrait abandonner ces rôles) à un mode multicanal. Cela augmente considérablement la difficulté de la censure. Lorsque plusieurs entités de packaging sont présentes, la résistance à la censure du système sera considérablement renforcée.

Au cœur du goulot d’étranglement actuel (notez que des équipes comme Flashbots améliorent le statu quo) est qu’un seul constructeur reçoit les droits de construction d’un seul proposant par le biais d’une vente aux enchères, et le relais (de confiance) en tant que commissaire-priseur exacerbe encore la centralisation. Alors que le protocole de base d’Ethereum est décentralisé, le processus de transaction on-chain existant ne l’est pas. Solana fait également face à la centralisation des relais/constructeurs Jito et tente de le résoudre avec une solution de re-staking (le premier re-staking à rendement réel « AVS » !). ）。 Les utilisateurs de Bitcoin peuvent résoudre le problème de manière autonome (à moindre coût) en exécutant un nœud complet, mais cela se fait au détriment de la finalité – Bitcoin utilise la finalité probabiliste et ne dispose pas des « outils de finalité » nécessaires pour mettre en œuvre MCP, qui repose sur la règle de la chaîne la plus longue.

(2) Extension au niveau du protocole de base

Pour résoudre les problèmes de protocole de base, un grand nombre de développements sont externalisés à des équipes tierces pour corriger les défauts de conception inhérents au L1 (non seulement Ethereum). La mise en œuvre de MCP signifie traiter directement les problèmes qui étaient à l'origine résolus/causés par des solutions hors chaîne. Cela augmentera les exigences matérielles (tout en renforçant la résistance à la censure), ce qui peut être un compromis valable en fonction des besoins des utilisateurs du protocole en matière de décentralisation. Solana est particulièrement susceptible d'adopter cette solution pour faire face aux problèmes de centralisation de Jito. De plus, comme le travail de construction de blocs est réparti entre plusieurs parties, cela augmentera finalement les besoins en bande passante du réseau global.

(3) MEV dispersé

L'effet le plus unique de MCP réside dans le fait que : en permettant à l'MEV d'un bloc spécifique d'être réparti entre plusieurs proposeurs actifs (et non pas monopolisé par un seul proposeur ou constructeur), cela modifie le modèle original de "lotterie MEV". Les validateurs (majoritairement des entités commerciales) préfèrent obtenir un flux de revenus stable, ce mécanisme peut également prévenir efficacement l'extraction de l'MEV par un seul acteur grâce à la réorganisation des transactions (situation actuelle). Cette caractéristique a un effet synergique avec l'objectif d'anti-censure.

Remarque : Si vous avez déjà lu nos précédents articles, vous êtes peut-être familier avec le terme théorème CAP : ce sont les trois caractéristiques fondamentales que doit respecter le bon fonctionnement des systèmes distribués.

C : représente la cohérence (consistency), c'est-à-dire que l'expérience utilisateur doit rester uniforme entre tous les utilisateurs, et que chaque utilisation du système doit donner l'impression d'interagir avec une seule base de données.

A : représente la disponibilité (availability), c'est-à-dire ce que nous appelons souvent la vivacité (liveness), ce qui signifie que tous les messages doivent être traités par les nœuds du système et reflétés dans les blocs/queries suivants, toutes les instructions doivent être exécutées.

P : signifie tolérance de partition, ce qui signifie que le système doit maintenir sa cohérence et sa disponibilité même lorsqu’il est attaqué ou que le réseau de nœuds est divisé.

MCP est l’un des meilleurs moyens de mettre en œuvre les éléments clés du théorème CAP, en particulier la résistance à la censure, qui sont souvent simplement regroupés dans des problèmes de théorie des jeux. N’oubliez pas : faites confiance au protocole lui-même, pas à la théorie des jeux.

Cependant, les avantages sont nécessairement accompagnés de coûts, et la loi de fonctionnement du théorème CAP indique que les grandes réalisations sont toujours assorties de défauts correspondants - il est presque impossible de concilier toutes les caractéristiques. Par conséquent, examinons les problèmes que la mise en œuvre de MCP pourrait engendrer.

2. Problèmes à résoudre par le MCP

Le principal problème est que le MCP peut d’une manière ou d’une autre déclencher une phase de double concurrence au sein d’un bloc. Le premier est les frais d’emballage de transaction, et le second est les frais de tri. La redevance de tri est particulièrement délicate à gérer, car dans un premier temps, le producteur local ne dispose que d’une vue d’îlot locale et non d’une vue globale. Cela signifie qu’il est difficile de calculer avec précision l’offre optimale pour une position de bloc particulière.

Cela n'est pas seulement difficile à opérer, mais ce qui est plus crucial, c'est que (sous le mécanisme d'enchères) cela nous ramènera à l'ère des enchères de Gas prioritaires (PGA). Bien que l'anti-censure soit mieux garanti, cela ressuscite essentiellement les problèmes que MEV-Boost essayait de résoudre : la médiane des frais de Gas élevés des blocs compétitifs, la tarification exclusive au stade de l'emballage, etc.

Outre les problèmes de tri, y compris les vues locales et mondiales, il existe d’autres défis liés aux transactions. Il s’agit spécifiquement du problème causé par des transactions non valides lors de la propagation de la vue locale-globale du bloc. Étant donné qu’il est impossible de prédire l’impact des changements d’état sur les transactions des autres proposants au début de la phase (avant que les sous-blocs ne soient fusionnés en blocs co-construits par plusieurs proposants), il peut y avoir des cas où les proposants se transmettent des transactions invalides (le problème est exacerbé si ces transactions sont téléchargées dans la chaîne en tant que contenu de disponibilité des données). Il est également possible qu’un validateur dans le MCP actuel définisse une limite de paramètre (par exemple, en dépassant la valeur maximale de gaz). Bien que cela puisse être résolu en introduisant un arbitre (ou une règle intégrée au protocole) qui peut filtrer les transactions à bas prix avec le même changement d’état par frais après la divulgation de la disponibilité des données, cela nous ramène au dilemme PGA résolu. Cependant, ne pas utiliser du tout des mécanismes tels que les enchères pour donner aux chercheurs/constructeurs le contrôle des emplacements des blocs conduirait à un flot de transactions de spam et à une aggravation de la latence des jeux d’argent - ce qui compromettrait la possibilité de pré-confs. Ethereum (après la mise à niveau de Pectra) et Solana ont des considérations supplémentaires : la proposition 7702 d’Ethereum rend les transactions non invalidées en raison de nonces, et Solana n’a pas de nonce de transaction (le nonce de compte existe toujours). Il est donc beaucoup plus difficile de juger de la validité d’une transaction, c’est-à-dire de simuler toutes les combinaisons pour déterminer l’ordre correct, ce qui peut exercer une pression énorme sur la bande passante du réseau. Solana est peut-être plus facile à gérer avec sa barrière matérielle élevée à l’entrée, mais Ethereum aura sans aucun doute besoin d’une mise à niveau matérielle. Cependant, la solution potentielle d’Ethereum est que le client d’exécution (et non le constructeur + répéteur) calcule réellement l’ordre pendant la phase de fusion des sous-blocs – réaffirmant ainsi la nécessité d’une mise à niveau matérielle.

En termes de disponibilité des données (DA), comme mentionné précédemment, un autre problème important est que ces transactions invalides peuvent être divulguées sur la chaîne (devenant essentiellement des transactions gratuites). Cela exacerbe encore la charge de calcul de simulation mentionnée dans la phase de pré-consensus, bien que vous puissiez filtrer les transactions non valides pendant la phase de fusion. Certaines des implémentations existantes de FOCIL (envoyer l’adresse plutôt que la transaction complète) peuvent être réutilisées (à moins qu’elles ne reposent uniquement sur la validation de la simulation, mais l’intervention humaine plutôt que les règles de protocole peut interférer avec le processus de simulation en invalidant d’autres transactions).

Comme mentionné précédemment, la mise en œuvre de MCP nécessitera très probablement des outils de finalité pour traiter les problèmes de synchronisation - ce qui est sous-entendu dans la section de simulation d’ordre pré-consensus ci-dessus. Cela soulève également le problème du retard du jeu temporel des propositions de blocs (un phénomène qui a été observé dans les enchères MEV-Boost), avec pour effet que les proposants peuvent regarder d’autres blocs avant de construire les leurs, et ainsi envoyer délibérément des transactions qui invalident les transactions d’autres personnes (particulièrement bénéfiques pour les chercheurs). Si les règles du jeu anti-temps sont trop strictes, cela conduira à l’élimination des validateurs les moins bons (c’est-à-dire plus de blocs manquants).

Les solutions potentielles pour faire face aux jeux de temps peuvent s'inspirer des mesures d'amélioration de chaînes comme Monad, qui utilise un mécanisme d'exécution asynchrone (exécution différée). Par exemple, des règles peuvent être établies : l'effet complet de l'ensemble des transactions de tous les proposeurs actifs dans une période donnée doit attendre que l'ensemble soit entièrement construit avant de pouvoir être déterminé. Cela limitera considérablement le débit, car la probabilité que plusieurs proposeurs contiennent les mêmes transactions est élevée. L'exécution différée signifie également que même si une transaction est "incluse" dans un sous-bloc, elle peut ne pas entrer dans le bloc de fusion final, entraînant des transactions "déjà incluses mais annulées" (ce qui fait écho au problème de double inclusion mentionné au début). Il convient de noter que cela peut nécessiter des outils de finalité spécifiques pour exécuter de telles opérations (y compris l'exécution, la propagation et la confirmation finale des blocs).

Bien que nous nous concentrions principalement sur Ethereum, il convient de noter que Solana progresse activement avec le MCP. Avec l'arrivée de Max Resnick chez Anza et l'affirmation publique d'Anatoly en faveur de sa mise en œuvre, cette tendance devient de plus en plus évidente. Dans un article récemment publié, Anatoly a mentionné les points clés suivants :

--Que faire si les temps d'arrivée des blocs provenant de différents validateurs sont différents (cela pourrait aussi être un jeu de temps)

--Comment fusionner les transactions (déjà discuté précédemment)

--Comment répartir la capacité des blocs (limite maximale de Gas) entre les validateurs pour maximiser la bande passante

--Problème de gaspillage de ressources (même transaction incluse dans plusieurs sous-blocs, ce problème a également été mentionné précédemment)

De nombreux problèmes liés à la mise en œuvre de MCP sur Solana résonnent souvent avec ceux auxquels Ethereum est confronté. Cependant, Solana accorde plus d'importance à la bande passante et à l'optimisation des performances, ce qui signifie que la gestion des ressources de blocs et la fusion des blocs deviennent plus importantes tout en garantissant la robustesse du consensus.

Un autre point clé que nous avons mentionné au début de l’article est que MCP renforce non seulement le protocole, mais peut également être utilisé pour étendre le protocole. Il peut même incorporer la sérialisation spécifique à l’application (ASS) dans la couche de protocole par le biais d’un mécanisme de tri. À l’avenir, il pourrait y avoir un scénario où, au lieu d’être le proposant de la transaction XYZ, l’application elle-même agit en tant que proposant et trie l’ensemble des transactions en fonction de ses propres besoins (ce à quoi travaille le projet Delta) - ou à l’inverse, l’application fournit au proposant une compilation des transactions. Il convient de noter que l’option de transférer la taxe MEV à la partie requérante (initiateur de la transaction) et de la combiner avec le MCP est également à l’étude (ce qui sera plus facile à mettre en œuvre puisqu’il n’est plus contrôlé par un seul proposant).

Dans un article récent, Max et Anatoly ont fait valoir que MCP pourrait obtenir des écarts acheteur-vendeur plus étroits en appliquant une sérialisation dédiée (concept décentralisé du NASDAQ). Dans l’environnement actuel, comme mentionné précédemment, un seul leader peut proposer des blocs. Cela signifie que lorsque le prix fluctue, la partie cotante dans le carnet d’ordres essaiera d’inverser certaines cotations. Dans le cadre du modèle de soumissionnaire unique de Solana, cela ne peut se faire que par le biais d’enchères Jito en raison du monopole du proposant sur le pouvoir. Idéalement, comme le montre Hyperliquid, les demandes de rétrofacturation devraient être priorisées pour permettre aux teneurs de marché de maintenir des spreads plus serrés. Par conséquent, on espère que cela sera réalisé par le biais de l’ASS en tant qu’application - ils ont le monopole du pouvoir d’enchères dans le cadre du modèle du leader unique, et ce monopole peut être éliminé en adoptant le MPC. Cependant, cette solution ASS est susceptible d’être limitée aux scénarios d’isolation d’état. L’essence de la proposition est de permettre aux développeurs d’applications de définir des actions prioritaires (par exemple, des annulations de commandes) pour des comptes spécifiques, et de donner la priorité aux transactions les plus prioritaires (pas nécessairement les transactions au pourboire le plus élevé, mais l’élément vital de la liquidité) pour des comptes spécifiques. L’idée de base est de fixer un seuil de frais pour les transactions régulières, tout en permettant à certaines transactions prioritaires de franchir la limite.

Le problème des frais de packaging et de frais de tri discuté précédemment semble avoir trouvé une solution avec Solana. Les frais de packaging sont attribués aux validateurs de transactions, tandis que les frais de tri sont versés au protocole (pour destruction). Lors de la fusion de plusieurs sous-blocs, il suffit de trier et d'exécuter l'ensemble des transactions fusionnées selon les frais de tri prédéfinis.

Le mécanisme ci-dessus fonctionne en étroite collaboration avec le mécanisme de propagation de blocs de Solana, Turbine. Les leaders (MCP) utilisent des partitions de données (shreds) qui sont envoyées aux nœuds de relais dans l’arborescence Turbine - ces relais doivent contenir des partitions de tous les leaders. Le nœud de relais envoie un message de confirmation de partition à un seul responsable du consensus, qui doit collecter suffisamment de fragments de message pour diffuser et parvenir à un consensus.

Avec la publication d'Alpenglow, et compte tenu de l'annulation de l'architecture des nœuds de relais à couche unique et du mécanisme de vote en chaîne (maintenant entièrement en chaîne), la mise en œuvre spécifique pourrait être ajustée. Ces modifications devraient permettre de réduire les coûts d'exploitation des validateurs, augmentant ainsi leur nombre et attirant des participants ayant des compétences techniques moins solides. Cela est sans aucun doute bénéfique pour la décentralisation, mais pourrait affecter les performances de la chaîne. Il est intéressant de discuter de la manière dont Solana fera face aux problèmes de défaillance des validateurs après la mise en œuvre de MCP.

**3、**Pratiques MCP dans d'autres écosystèmes

L’écosystème Cosmos fait également progresser la mise en œuvre de MCP, et l’organisation bien connue Informal Systems vient de publier la spécification multi-proposants sous le modèle de consensus BFT. Ils utilisent un protocole de diffusion sécurisé qui exige que le sous-bloc de chaque validateur soit confirmé par d’autres validateurs via un mécanisme de mise à l’échelle des votes. Les blocs de construction de Tendermint/CometBFT parviennent ensuite à un consensus sur ces ensembles de sous-blocs, ce qui signifie qu’un validateur particulier produira un grand nombre de sous-blocs.

Sei développe MCP via le projet Sei Giga (s'efforçant de devenir le premier projet opérationnel), dont une partie de l'inspiration de conception provient de l'article Autobahn (fortement recommandé à lire). L'idée principale est de découpler la disponibilité des données et le tri, en accélérant la disponibilité des données à travers plusieurs canaux parallèles, puis en reclassant sur la chaîne globale. Cela diffère légèrement du concept de MCP d'Ethereum : les validateurs ne synchronisent pas les blocs à des intervalles fixes, mais produisent continuellement des blocs avant de les fusionner en une vue globale.

Patrick O'Grady de Commonware explore également des solutions connexes.

Enfin, le projet Delta a conçu une couche de base qui combine les fonctionnalités d'un tableau d'affichage résistant à la censure, tout en permettant à chaque application de faire fonctionner son propre ordonnanceur concurrent, les blocs générés étant finalement réglés au niveau de l'état global.