Constellation : une proposition de MCP sur Solana

Enseignements exploitables

• Constellation est la première proposition formelle au niveau du protocole visant à implémenter les proposants multiples concurrents (MCP) à grande échelle sur une blockchain en production.
• Constellation introduit deux nouveaux rôles (les proposants et les attestateurs) qui limitent la latitude du leader dans la construction des blocs. Environ 16 proposants opèrent simultanément selon un cycle de 50 ms, regroupant les transactions en pslices codées avec effacement et distribuées à 256 attestateurs. Le registre d’attestation lie cryptographiquement le leader à l’ensemble des transactions qu’il inclut. Si une pslice est attestée par un nombre suffisant d’attestateurs, le leader ne peut pas exclure la transaction sans produire un bloc invalide que le réseau rejettera.
• Constellation offre une résistance à la censure sélective : lors de chaque cycle, soit toutes les transactions dont les frais sont compétitifs sont incluses, soit aucune ne l’est.
• Les attaques fondées sur un ordonnancement tenant compte du contenu et sur la manipulation du timing restent sans solution. Sous Constellation, les transactions sont visibles par tous les proposants qui les reçoivent au moment de leur soumission. En raison de l’architecture multiproposant de MCP, cela pourrait en réalité élargir ces surfaces d’attaque plutôt que les réduire. La conception actuelle reconnaît que les stratégies de latence fondées sur le temps ne peuvent pas être sanctionnées.
• Constellation restructure les frais existants : les frais d’inclusion correspondent aux frais de base actuels, tandis que les frais d’ordonnancement correspondent aux frais de priorité existants. Le changement économique le plus important tient au fait que l’activité transitant actuellement par des services d’inclusion hors protocole et des accords de frais hors chaîne devrait revenir au protocole. La sélection des rôles pondérée par le stake maintient les dynamiques de concentration existantes, et l’impact net sur chaque validateur ne pourra pas être modélisé avant la publication du futur SIMD de Constellation.
• MCP augmente la latence de séquencement, mais réduit la latence d’inclusion. Le tour des attestateurs, la fenêtre de cycle de 50 ms et l’assemblage par lots ajoutent tous du temps par rapport au chemin actuel de soumission directe à la TPU. Aujourd’hui, la latence est plus élevée pour les validateurs qui regroupent immédiatement les transactions de la TPU et plus faible pour ceux qui les retardent. Avec Constellation, les transactions valides bénéficient désormais d’une garantie d’inclusion bornée et imposée par le protocole.
• Constellation est explicitement incompatible avec les modèles de séparation proposant-constructeur (PBS). Dès lors que le registre d’attestation limite la latitude du leader, il ne reste plus rien à vendre à un constructeur spécialisé. Cette approche repose sur une philosophie fondamentalement différente de celle qu’adopte actuellement Ethereum face au MEV.
• Il n’existe pas encore de benchmarks empiriques réalisés dans des conditions réseau réalistes. La donnée la plus importante qu’Anza puisse fournir est une projection comparative de la latence des slots de 200 ms avec le protocole actuel et avec Constellation. Tant que ces données ne seront pas disponibles, la communauté débattra de compromis qu’elle ne peut pas quantifier. 
• Constellation s’appuie sur Alpenglow, dont le lancement sur le mainnet est prévu au troisième trimestre 2026.

Introduction

Malgré une absence frappante d’agaves, Brennan Watt, CEO d’Anza, s’est rendu dans le désert californien pour dévoiler Constellation, une proposition visant à introduire les proposants multiples concurrents (MCP) sur Solana. Il s’agit de la mise à niveau la plus ambitieuse sur le plan structurel et, sans doute, de la proposition de MCP au niveau du protocole la plus importante jamais présentée par une blockchain en production. Elle vise à mettre fin au monopole temporaire du leader sur l’ordonnancement des transactions et à la valeur extractible qu’il engendre. Constellation démocratise l’espace de blocs sur Solana.

Cet article propose une analyse critique de Constellation : ce qu’elle résout, ce qu’elle reporte sciemment et ce qui reste véritablement sans réponse. Nous présentons un cadre à trois niveaux pour évaluer la résistance à la censure, comparons Constellation au paysage actuel de MCP et examinons si les compromis qu’elle introduit sont compatibles avec l’identité de performance construite par Solana.

Une connaissance préalable d’Alpenglow est requise. 

Le problème que résout Constellation

Les transactions sont le moteur vital de Solana. Elles sont regroupées et inscrites de façon permanente sur le réseau sous forme de blocs. Mais le processus qui détermine quelles transactions intègrent ces blocs, et dans quel ordre, n’est pas neutre. 

Le monopole du leader sur la production des blocs

La production des blocs est attribuée à tour de rôle selon un calendrier des leaders, dans lequel un validateur à la fois est chargé de produire les blocs pendant une fenêtre donnée.

Pendant cette période, les transactions sont transmises directement à l’unité de traitement des transactions (TPU) du leader, où celui-ci les reçoit généralement avant tous les autres participants.

Le leader occupe une position particulièrement puissante. En effet, il peut observer les transactions entrantes avant qu’elles ne soient publiquement visibles.

Le leader peut décider de ne pas inclure certaines transactions, de les réordonner arbitrairement ou d’introduire les siennes.

Il s’agit d’une caractéristique structurelle du fonctionnement actuel du consensus à leader unique, que l’on retrouve à des degrés divers dans pratiquement toutes les blockchains Proof of Stake aujourd’hui en production.

L’absence de mempool public sur Solana accentue cette asymétrie au lieu de la réduire. Le mempool public d’Ethereum offre aux participants une certaine visibilité sur les transactions en attente, créant une forme d’égalité des chances entre les acteurs sophistiqués qui cherchent à exploiter l’ordonnancement des transactions.

Sur Solana, l’avantage informationnel du leader est plus difficile à contester en raison du mode de transmission des transactions. 

Valeur maximale extractible (MEV)

Dans des conditions normales et avec des validateurs honnêtes, ce pouvoir reste largement inexploité. Le problème est toutefois que les validateurs sont des acteurs économiques rationnels. À mesure que Solana gagne en maturité et que l’activité financière continue de croître, les profits pouvant être tirés du monopole temporaire du leader augmentent en conséquence. Un validateur qui choisit de ne pas exploiter cette position renonce tout simplement à des revenus. Les nœuds qui se comportent correctement se retrouvent désavantagés sur le plan économique, ce qui les incite à compromettre la qualité du système même auquel ils participent.

Ce profit extractible est appelé valeur maximale extractible (MEV), un terme formalisé pour la première fois par Daian et al. dans Flash Boys 2.0 sous le nom de valeur extractible par les mineurs, avant son application aux réseaux Proof of Stake. Il englobe aussi bien l’arbitrage et le frontrunning que les attaques sandwich, la censure sélective et toute stratégie exploitant l’avantage informationnel et positionnel du leader sur les utilisateurs dont il traite les transactions.

La principale réponse du secteur au MEV a été le modèle de séparation proposant-constructeur (PBS), implémenté sur Ethereum par l’intermédiaire de MEV-Boost. Dans le cadre de PBS, des constructeurs spécialisés rivalisent pour construire des blocs qui maximisent la valeur extractible, tandis que les proposants se contentent de sélectionner le bloc le plus rentable à produire. Il s’agit d’un recadrage pragmatique du problème visant à démocratiser l’accès au MEV et à en redistribuer les revenus à l’ensemble des validateurs, plutôt que de les concentrer entre les mains des acteurs les plus sophistiqués, car ce modèle considère l’extraction de MEV comme inévitable.

Le problème de cette approche est que PBS ne réduit pas le préjudice subi par les utilisateurs : l’extraction a toujours lieu, seuls les bénéficiaires ont changé. PBS traite certains effets négatifs du MEV pour les nœuds du réseau, mais ne réduit pas les dommages causés aux utilisateurs du réseau.

Solana entretient elle aussi une relation évolutive avec le MEV. La combinaison de blocs rapides, de la soumission directe à la TPU et d’un ensemble concurrentiel de validateurs a créé un paysage MEV particulier, caractérisé par le spam, les enchères sur les frais de priorité et le réordonnancement des transactions au niveau des validateurs. Le moteur de blocs de Jito peut être considéré comme partiellement analogue à MEV-Boost, puisqu’il fournit un mécanisme d’enchères hors chaîne dans lequel les chercheurs enchérissent sur l’ordonnancement des transactions, les revenus étant partagés entre les validateurs et les stakers. Autrement dit, comme PBS, Jito gère et redistribue le MEV de manière plus démocratique au lieu de l’éliminer complètement.

Constellation vise à remédier à ce problème. Plutôt que d’accepter le monopole du leader et d’en gérer les conséquences, elle cherche à le contenir structurellement afin de rendre impossibles, par conception, les formes les plus nuisibles de MEV. Le livre blanc de Constellation présente cette ambition comme « l’infrastructure des marchés de capitaux d’Internet, une plateforme universelle pour l’activité économique où les utilisateurs peuvent avoir confiance dans l’équité de la structure du marché ».

Les marchés financiers traditionnels tentent d’imposer des protections similaires au moyen de la réglementation et d’une surveillance juridictionnelle. Ces protections sont réactives et inégales, et leur insuffisance a été démontrée à maintes reprises. Constellation ambitionne d’imposer l’équité au niveau du protocole, afin qu’elle ne puisse être contournée ni appliquée de manière sélective. Pour y parvenir, Constellation entend implémenter les proposants multiples concurrents (MCP) sur Solana.

Proposants multiples concurrents

Dans une blockchain traditionnelle à leader unique, un validateur est chargé de produire chaque bloc. Ce validateur, c’est-à-dire le leader, détient temporairement le contrôle exclusif de l’inclusion et de l’ordonnancement des transactions. Pendant qu’il est autorisé à produire des blocs, tous les autres participants du réseau restent des observateurs passifs au cours de cette fenêtre. Le leader décide en dernier ressort quelles transactions sont incluses et dans quel ordre.

Cette conception séduit par sa simplicité. Confier la production des blocs à un seul validateur élimine les coûts de coordination, les propositions contradictoires à résoudre et offre un modèle de responsabilité clair. Mais elle crée également un point d’exploitation unique. Le monopole temporaire du leader est la cause profonde du MEV, et toutes les principales mesures d’atténuation proposées jusqu’ici ont accepté cette structure et cherché à en gérer les conséquences.

Les proposants multiples concurrents (MCP) constituent une catégorie de conceptions de protocole qui brise ce monopole au niveau structurel. Au lieu de désigner à tour de rôle un leader unique qui détient les droits exclusifs de production des blocs, MCP permet à plusieurs nœuds de proposer simultanément des transactions. Aucun proposant ne contrôle l’ensemble complet des transactions. Leurs propositions sont plutôt combinées, généralement par un rôle d’assembleur soumis à des contraintes, conformément aux règles du protocole.

Un utilisateur qui soumet simultanément une transaction à plusieurs proposants ne dépend plus d’un seul nœud, puisqu’il dispose désormais de plusieurs chemins indépendants vers l’inclusion. Un leader qui tente d’exclure sa transaction doit tenir compte du fait que d’autres proposants l’ont déjà vue et que des attestateurs l’ont déjà attestée. Un leader unique assemble le bloc final, mais sa latitude est strictement limitée.

Le principal compromis de MCP réside dans la complexité de la coordination. Permettre à plusieurs nœuds de proposer simultanément des transactions soulève des questions que les conceptions à leader unique évitent entièrement. Comment résoudre les conflits lorsque deux proposants incluent la même transaction ? Comment déterminer l’ordre entre différentes propositions ? Comment empêcher un proposant sophistiqué de manipuler les règles de combinaison ? Cela ajoute une complexité considérable au protocole : les équipes doivent relever des défis de coordination impliquant de nouveaux rôles de nœuds, une logique de planification, des hypothèses cryptographiques et des modes de défaillance, autant d’éléments qui nécessitent des tests rigoureux.

Il convient d’être précis ici, car MCP est utilisé de manière vague dans l’ensemble du secteur pour désigner un éventail de conceptions aux propriétés sensiblement différentes. Dans sa forme la plus élémentaire, MCP offre une résistance probabiliste à la censure : une transaction soumise à plusieurs proposants est plus difficile à censurer, car cela exige une coordination entre plusieurs nœuds. Dans sa forme la plus avancée, MCP peut offrir une résistance structurelle à la censure : il devient mathématiquement impossible pour le leader de produire un bloc qui censure une transaction attestée par un quorum suffisant. C’est l’objectif de Constellation, et cette différence est capitale pour les applications financières qui exigent des garanties strictes.

Constellation : fonctionnement

Constellation est un protocole destiné à implémenter MCP sur Solana. Il complète Alpenglow : Alpenglow gère le consensus, c’est-à-dire la sécurité, la vivacité et la finalité, tandis que Constellation gère la structure du marché — qui peut proposer des transactions, comment ces propositions sont reconnues et ce que le leader est autorisé à en faire. Constellation produit la charge utile qu’Alpenglow finalise.

Architecture

Constellation introduit deux nouveaux rôles dans la pile protocolaire de Solana, chacun doté d’une responsabilité distincte, tout en modifiant les rôles des leaders et des validateurs.

Les proposants constituent le point d’entrée des transactions. À tout moment, environ 16 proposants sont actifs simultanément. Ils sont sélectionnés aléatoirement en fonction du stake et renouvelés tous les 32 cycles, soit environ 1,6 seconde. Les utilisateurs soumettent directement leurs transactions à un ou plusieurs proposants de leur choix. Un proposant est libre d’accepter ou de rejeter toute transaction, à condition que les transactions acceptées soient valides. Aucune règle du protocole n’impose l’inclusion des transactions à ce stade ; la garantie de résistance à la censure intervient plus tard dans le pipeline. Chaque proposant fonctionne selon un cycle de 50 millisecondes. Au cours de chaque cycle, il assemble les transactions acceptées dans une structure appelée pslice — le préfixe « p » est muet et sert uniquement à la distinguer des slices d’Alpenglow. La pslice est codée avec effacement en 256 fragments plus petits, appelés pshreds, puis un pshred est distribué à chacun des 256 attestateurs actifs. Le codage avec effacement utilise un seuil de récupération de 64, ce qui signifie que 64 des 256 pshreds suffisent à reconstruire la pslice complète. Chaque pshred contient un engagement de hachage cryptographique portant sur la liste complète des transactions. Le leader ne peut donc ni substituer d’autres transactions ni modifier leur ordre au sein d’une pslice après validation par les attestateurs.

Les attestateurs reçoivent les pshreds d’un proposant et les transmettent immédiatement aux quelque 2 leaders suivants afin de tenir compte d’éventuelles défaillances ou absences. Ils enregistrent également le hachage d’engagement de la pslice reçue. À la fin de chaque cycle, l’attestateur signe une attestation, c’est-à-dire une déclaration cryptographiquement contraignante qui répertorie tous les hachages d’engagement des pslices observées pendant ce cycle. Cette attestation est envoyée au leader et sert de registre probant limitant les transactions que celui-ci peut inclure. Le registre est pondéré par le stake et signé, ce qui signifie qu’il ne peut être falsifié ni ignoré discrètement. 

Dans Constellation, le leader est le même que dans Alpenglow : il s’agit du nœud chargé de produire le bloc final soumis au consensus. Avec Constellation, la différence tient au fait que le registre d’attestation limite strictement sa latitude. Constellation impose deux seuils distincts. Pour que l’attestation agrégée soit valide, au moins 60 % des attestateurs doivent participer. Si ce seuil n’est pas atteint, le bloc est entièrement ignoré. Dans ce cadre, toute pslice attestée par au moins 40 % des attestateurs doit être incluse par le leader. Dans le cas contraire, celui-ci produit un bloc invalide que le réseau rejettera. Cette conception à deux seuils distingue la validité au niveau du bloc de l’inclusion propre à chaque proposant. Autrement dit, le leader peut produire un bloc valide même si les données de certains proposants n’ont pas atteint suffisamment d’attestateurs, mais il ne peut pas exclure de manière sélective les proposants dont les données ont atteint ce seuil. Une fois toutes les pslices attestées regroupées dans un lot, le leader transmet ce lot aux validateurs par l’intermédiaire de Rotor d’Alpenglow. 

Les validateurs reçoivent les lots du leader via Rotor et exécutent les données en pipeline à mesure de leur arrivée. Une fois le bloc complet reçu, ils le comparent au registre d’attestation pour confirmer que chaque pslice attestée possède une soumission correspondante dans le bloc. Le validateur vote en faveur de sa finalisation uniquement si toutes les vérifications réussissent ; dans le cas contraire, les validateurs votent pour ignorer toute la fenêtre du leader au moyen de l’appel TrySkipWindow. 

Cycles et blocs

Un cycle est l’unité temporelle fondamentale de Constellation. Il s’agit d’une fenêtre de 50 millisecondes dérivée de l’heure UTC en divisant l’horodatage Unix en nanosecondes par 50 000 000. Point crucial : les cycles ne sont pas alignés sur les slots d’Alpenglow. Un slot contient plusieurs cycles, et les lots produits au fil de ces cycles constituent la charge utile du bloc du leader. Cette distinction est importante, car le cycle de 50 ms représente le rythme économique, c’est-à-dire la fenêtre au sein de laquelle la résistance à la censure est appliquée, tandis que le slot reste l’unité de consensus d’Alpenglow.

Le livre blanc définit une tolérance au décalage des horloges entre les proposants et les attestateurs, et ajuste la fenêtre d’attestation en conséquence. Pour comprendre l’importance de ce point, supposons que l’horloge d’un proposant avance de 5 ms par rapport à celles des attestateurs. Les pshreds de ce proposant peuvent parvenir aux attestateurs plus tôt que prévu par rapport à la limite du cycle, ce qui offre aux transactions de cette pslice une fenêtre légèrement plus longue pour accumuler des attestations. À l’inverse, un proposant dont l’horloge retarde peut voir ses pshreds arriver si tard qu’ils se retrouvent entièrement hors de la fenêtre d’attestation, même s’il les a soumis « à temps ». Dans les centres de données qui utilisent des outils comme chrony ou des récepteurs GPS, la synchronisation des horloges est courante et la dérive est généralement inférieure à une milliseconde, ce qui reste largement dans les limites de tolérance de Constellation. Le problème est que Constellation introduit une nouvelle variable qui n’existait pas dans le modèle de temps purement logique d’Alpenglow, et dont le futur SIMD de Constellation devrait préciser les limites de surveillance.

Lorsque Constellation approche de la fin d’une époque, les proposants et les attestateurs peuvent brièvement ne pas savoir si l’époque suivante a commencé. Pendant cette fenêtre, Constellation opère simultanément dans les deux époques, avec deux ensembles de proposants et d’attestateurs actifs en parallèle. Le consensus d’Alpenglow détermine naturellement à quelle époque appartient chaque cycle.

Cycle de vie des transactions et frais

Une transaction doit franchir quatre étapes avant d’être exécutée :

• Elle doit être acceptée et incluse dans une pslice par un proposant.
• Cette pslice doit accumuler suffisamment d’attestations pour être incluse dans le lot du leader.
• L’offre associée à la transaction doit être suffisamment élevée pour que celle-ci soit sélectionnée en vue de son exécution dans la limite de calcul du lot.
• Le bloc contenant le lot doit être confirmé par le consensus d’Alpenglow.

Chaque transaction comporte une offre, c’est-à-dire les frais d’exécution par unité de calcul, qui détermine sa position dans un même lot. Les offres les plus élevées sont exécutées en premier.

Constellation divise le coût d’une transaction en deux frais distincts :

• Des frais d’inclusion.
• Des frais d’ordonnancement.

Les frais d’inclusion sont un petit montant fixe calculé en fonction de la taille de la transaction et de son nombre de signatures. Ils sont versés au proposant qui a inclus la transaction dans sa pslice et sont prélevés dès que la transaction franchit le seuil d’attestation, qu’elle soit finalement exécutée ou non. Ils sont comparables aux frais de base du système actuel de Solana, avec une réserve importante : si un utilisateur soumet la même transaction à trois proposants à des fins de redondance, il paie trois fois les frais d’inclusion, c’est-à-dire une fois par proposant, puisque chacun a effectué indépendamment le travail nécessaire à son inclusion. Par conséquent, si un utilisateur soumet la même transaction à n proposants différents à des fins de redondance, il paie n fois les frais d’inclusion.

Les frais d’ordonnancement constituent la composante la plus importante, fondée sur la priorité. Ils correspondent au nombre total d’unités de calcul de la transaction multiplié par son offre. Ces frais ne sont facturés qu’une seule fois, car la transaction ne peut être exécutée qu’une fois, quel que soit le nombre de proposants qui l’incluent. Par exemple, une transaction demandant 200 000 unités de calcul avec une offre de 0,00001 SOL par unité de calcul entraîne des frais d’ordonnancement de 2 SOL. Si cette même transaction a été soumise à quatre proposants à des fins de redondance, l’utilisateur paie quatre frais d’inclusion auxquels s’ajoutent des frais d’ordonnancement uniques de 2 SOL. Les frais d’ordonnancement sont reversés à l’écosystème proportionnellement au stake des nœuds ; le livre blanc réserve la conception de ce mécanisme à son futur SIMD.

Chaque compte payeur de frais doit conserver un solde de réserve minimal d’environ 0,001 SOL afin d’empêcher la manipulation des frais entre proposants concurrents. Cela garantit que les frais d’inclusion pourront toujours être payés, même lorsque plusieurs proposants incluent simultanément des transactions qui concernent le même compte.

Constellation et Alpenglow

Alpenglow est le protocole de consensus de Solana. Il détermine quels blocs sont valides, l’ordre dans lequel ils sont finalisés et la manière dont le réseau récupère après une défaillance. Ses composants Votor et Rotor remplacent Tower BFT et la propagation des votes fondée sur le gossip, réduisant considérablement le délai de finalité. Alpenglow ne précise ni qui propose les transactions ni comment leur ordre est déterminé au sein d’un bloc.

Constellation est une couche de structure de marché qui limite ce que le leader d’Alpenglow est autorisé à faire avec les blocs qu’il assemble : elle définit qui propose les transactions et comment leur ordre est déterminé dans chaque bloc. Les lots produits par Constellation deviennent la charge utile des blocs d’Alpenglow. Votor, le composant d’Alpenglow, notarise ensuite ces blocs conformément à ses règles de vote prédéfinies. Les deux protocoles sont combinés de sorte qu’Alpenglow assure la sécurité et la vivacité, tandis que Constellation garantit l’équité de l’ordonnancement.

Grâce à cette composabilité, Constellation hérite également des hypothèses de sécurité d’Alpenglow sans les affaiblir. Constellation ne modifie pas les garanties d’Alpenglow. Elle introduit plutôt de nouvelles garanties et hypothèses pour les nouveaux rôles de proposant et d’attestateur, ainsi que la synchronisation avec l’heure UTC, dans son nouveau modèle temporel fondé sur les cycles.

Constellation est la première proposition formelle au niveau du protocole visant à implémenter MCP sur une blockchain évolutive en production. Elle constitue une avancée importante pour introduire la résistance à la censure sur Solana, ouvrant ainsi le prochain chapitre de la feuille de route du protocole initiée par Alpenglow.

Ce que la résistance à la censure exige réellement

La littérature sur la MEV a historiquement abordé le problème sous plusieurs angles distincts qui, pris ensemble, dessinent une vision plus unifiée de ce que toute proposition de résistance à la censure doit réellement résoudre. En nous appuyant sur la taxonomie fondatrice des attaques par front-running d’Eskandari et al., sur le cadre formel à deux propriétés de Garimidi et al. pour les protocoles MCP et sur l’analyse de Landers et Marsh concernant les canaux de MEV propres au MCP, nous proposons d’organiser la surface d’attaque en trois couches distinctes, chacune nécessitant une catégorie de solution différente. Ce cadre constitue notre propre synthèse, présentée ici pour évaluer la conception de Constellation.

Couche 1 : censure stricte

La censure stricte désigne la capacité d’un leader ou d’un proposeur à refuser d’inclure une transaction qu’il a identifiée. Il s’agit de la forme de manipulation la plus évidente, et Constellation la résout structurellement. Avec Constellation, il devient cryptographiquement impossible pour un leader de produire un bloc valide qui exclut une transaction offrant des frais compétitifs et attestée par un quorum suffisant d’attesteurs. Le slashing n’est pas nécessaire ici, car l’application de cette règle est architecturale.

Couche 2 : ordonnancement avec contenu visible

La deuxième couche est plus difficile à traiter. Même si les proposeurs ne peuvent pas censurer directement, ils peuvent toujours observer le contenu des transactions avant l’ordonnancement final et tenter d’exploiter cette visibilité, par exemple en prenant en sandwich une transaction importante. C’est ce que Garimidi et al. formalisent comme la propriété de dissimulation : un adversaire ne doit pas pouvoir voir le contenu des transactions avant leur confirmation. Constellation met en œuvre une dissimulation partielle. Autrement dit, une transaction n’est visible que par le proposeur qui la reçoit, et non par tous les proposeurs, tandis que le leader ne voit son contenu qu’après l’expiration du délai du cycle. C’est préférable à une visibilité totale, mais cela ne satisfait pas pleinement la propriété de dissimulation de Garimidi et al., qui exige que le contenu d’une transaction reste invisible pour toutes les parties avant sa confirmation. Le proposeur qui la reçoit peut toujours observer et exploiter son contenu.

Le problème plus profond de Constellation est que le MCP avec soumission publique des transactions peut amplifier leur exploitation fondée sur la visibilité du contenu. Il crée un système dans lequel chaque proposeur observe les transactions qu’il reçoit et peut exploiter cette visibilité au sein de sa propre pslice. La surface d’attaque diffère de celle du modèle à leader unique, car plusieurs entités peuvent chacune voir un sous-ensemble. Un utilisateur qui soumet sa transaction à un seul proposeur ne l’expose qu’à celui-ci. Mais un utilisateur qui la soumet à plusieurs proposeurs à des fins de redondance élargit proportionnellement son exposition. Landers et Marsh formalisent cette dynamique : la production concurrente de blocs crée des jeux de timing, des possibilités de duplication dans le même tick et l’absence structurelle d’un point de passage obligé auprès d’un builder unique, qui limite actuellement le nombre de tentatives d’extraction pouvant aboutir pour chaque transaction victime. Décentraliser l’ensemble des proposeurs sans traiter la visibilité du contenu multiplie la surface d’attaque de la MEV au lieu de la réduire.

L’analyse de Landers et Marsh sur les canaux de MEV propres au MCP suppose une visibilité du contenu plus large que celle offerte par Constellation. Avec la dissimulation partielle de Constellation, l’amplification de l’exploitation fondée sur la visibilité du contenu dépend de la stratégie de soumission de l’utilisateur plutôt que d’être une conséquence architecturale inévitable. Un utilisateur qui soumet sa transaction à un seul proposeur de confiance présente un profil d’exposition du contenu à peu près identique à celui du modèle actuel à leader unique. En contrepartie, la soumission à un seul proposeur sacrifie la redondance dont dépend la résistance à la censure. 

Couche 3 : manipulation du timing et de la latence

La couche la plus subtile et la plus difficile à sanctionner concerne la manipulation du timing et de la latence. Avec Constellation, un proposeur peut retarder la transmission des pshreds aux attesteurs juste assez pour que la transaction d’un concurrent sorte de la fenêtre d’attestation, ou exploiter un décalage des horloges UTC afin de déterminer quelles transactions accumulent suffisamment d’attestations. Cette lacune est directement reconnue dans le livre blanc de Constellation : une livraison tardive des messages « ne peut pas être sanctionnée », car elle est impossible à distinguer d’un véritable retard réseau. C’est à ce niveau que le slashing pourrait devenir pertinent, et il s’agit de la principale question ouverte que le futur SIMD de Constellation devra traiter. 

Une hypothèse fondamentale de la conception de Constellation est que la relation entre proposeur et utilisateur n’est pas anonyme : il s’agit d’une interaction répétée dans laquelle la confiance est mesurable et la réputation compte. Avec environ 16 proposeurs actifs à tout moment, un utilisateur constamment mal servi par un proposeur peut commencer à soumettre ses transactions à l’un des 15 autres. Cela ne crée aucun artefact onchain permettant de sanctionner directement un acteur malveillant, mais entraîne des conséquences économiques pour les proposeurs qui exploitent leur position. La question de savoir si cette pression réputationnelle suffit à dissuader la manipulation du timing, par rapport à une solution comme le slashing, reste ouverte et dépendra probablement de la transparence croissante du comportement des proposeurs pour les utilisateurs. 

Impact sur les validateurs et les utilisateurs

Validateurs

Constellation redistribue les possibilités de MEV entre les validateurs au lieu de les éliminer entièrement. La source de revenus la plus évidente et la plus directement extractible dont disposent aujourd’hui les leaders, à savoir la censure stricte, devient impossible par conception. Elle est toutefois remplacée par un ensemble de canaux de timing plus subtils et plus difficiles à sanctionner, qui favorisent les validateurs bénéficiant d’avantages en matière de latence, d’une synchronisation précise des horloges et des compétences nécessaires pour exploiter systématiquement les fenêtres de transmission des pshreds. L’effet net est une évolution de la manière dont les validateurs extraient de la valeur, plutôt qu’une réduction de la surface totale d’extraction. Seule réserve : cette extraction devient nettement plus difficile.

Constellation n’introduit pas tant de nouveaux flux de frais qu’il ne restructure ceux qui existent déjà. Les frais d’inclusion sont analogues aux frais de base actuels, tandis que les frais d’ordonnancement correspondent aux frais de priorité existants. La répartition devrait ressembler à ce que gagnent aujourd’hui les validateurs. La différence est principalement opérationnelle. Autrement dit, les opérateurs performants devraient percevoir davantage de frais d’inclusion en tant que proposeurs, créant une gradation fondée sur les performances au sein du modèle économique existant plutôt qu’une catégorie de revenus distincte. Le rôle d’attesteur n’est pas rémunéré séparément dans la conception actuelle. La justification est que, comme la participation actuelle à Turbine, il devrait être assuré parce qu’il présente un bénéfice net pour le réseau. L’évolution économique la plus importante concerne l’activité qui passe actuellement par des services d’inclusion hors protocole, des enchères fondées sur le marché et des accords de frais offchain, et qui devrait revenir dans le protocole pour bénéficier plus directement aux validateurs. Toutefois, tant que le SIMD n’en précise pas les mécanismes exacts, l’impact économique net sur chaque validateur reste une question ouverte, en particulier pour les plus petits, dont la fréquence de sélection comme proposeur est réduite par la pondération selon le stake et pour lesquels les coûts d’infrastructure augmentent le seuil minimal de rentabilité.

Les proposeurs et les attesteurs sont sélectionnés en fonction du poids de leur stake. Les mêmes dynamiques de concentration qui façonnent l’économie des validateurs déterminent donc aussi la participation à ces rôles. Si un petit nombre de validateurs disposant d’un stake élevé domine la sélection des proposeurs, la garantie de résistance à la censure reste formellement intacte, mais la diversité pratique de l’ensemble des proposeurs diminue, même si cela reste une amélioration par rapport à la situation actuelle de Solana, c’est-à-dire n parmi 1 contre n parmi 16. L’hypothèse d’indépendance commence à s’affaiblir dans la pratique, même si elle reste valide en théorie. Cette préoccupation mérite d’être signalée compte tenu de l’émergence d’offres Validator-as-a-Service (VaaS), qui permettent à une seule entité d’exploiter plusieurs validateurs dotés d’un stake élevé. La question de savoir si le SIMD introduira des mécanismes anticontcentration ou des incitations pour la sélection des proposeurs a des implications directes sur la solidité des garanties avancées par Constellation. 

Utilisateurs

Pour les utilisateurs, une transaction offrant des frais compétitifs et soumise à un nombre suffisant de proposeurs bénéficie, pour la première fois, d’une garantie stricte du protocole contre l’exclusion sélective. Il devient ainsi possible de créer des applications financières avec des garanties qui n’existaient tout simplement pas auparavant, ce qui redéfinit ce qui n’est possible que sur Solana. 

Les utilisateurs à haute fréquence et sensibles aux prix doivent désormais soumettre leurs transactions à plusieurs proposeurs à des fins de redondance. Le problème est que décentraliser l’ensemble des proposeurs sans traiter la visibilité du contenu peut accroître l’exposition aux attaques sandwich : chaque proposeur peut observer les transactions qui lui sont soumises et agir en conséquence. Les utilisateurs qui soumettent leurs transactions à plusieurs proposeurs pour assurer leur redondance augmentent donc proportionnellement le nombre de parties qui voient leur contenu. Cette pratique supprime par nature le point de passage obligé du leader unique et diffuse l’intention transactionnelle auprès d’un ensemble plus large d’adversaires potentiels. En pratique, les utilisateurs les plus sophistiqués devront élaborer de nouvelles stratégies de soumission conciliant redondance et exposition. Elles reposeront probablement, par exemple, sur un ciblage sélectif des proposeurs selon leur réputation ou leur stake plutôt que sur des stratégies générales de soumissions multiples.

Pour les teneurs de marché en particulier, la garantie d’inclusion de Constellation élimine le risque adversarial lié au fait que l’infrastructure détermine la qualité d’exécution. Il ne reste qu’une pure asymétrie d’information, soit le même profil de risque que celui auquel les teneurs de marché sont aujourd’hui confrontés sur les meilleures places de marché traditionnelles. C’est cette convergence qui rend concret, plutôt qu’hypothétique, l’argument en faveur de l’inclusion et de la réduction de la latence. Nous examinons cette convergence plus en détail dans notre section « Questions ouvertes ».

L’évolution nette de l’expérience perçue par l’utilisateur moyen sera probablement marginale, mais la garantie d’inclusion constitue une amélioration significative de la fiabilité. Dans l’attente de futurs benchmarks, l’impact net sur la latence de séquençage reste une question empirique ouverte.

Paysage : comparaison de Constellation

Sei Giga

Sei Giga est l’analogue le plus proche de Constellation dans le paysage actuel du MCP. Il s’agit d’une blockchain prête pour la production qui fait du MCP une priorité architecturale de premier ordre plutôt qu’un futur objectif de recherche. Leur comparaison est instructive dans la mesure où ces deux systèmes font des compromis différents au sein d’une même couche.

Le socle de consensus de Giga s’appelle Autobahn. Il s’agit d’un protocole BFT à plusieurs proposeurs dans lequel chaque validateur exploite en parallèle sa propre « voie » continue de propositions. Au lieu de dépendre d’un leader unique, chaque nœud diffuse en continu son propre flux de propositions de données sur des voies indépendantes, tandis que la couche de consensus valide périodiquement une « coupe des extrémités », c’est-à-dire un instantané compact agrégeant les dernières propositions de chaque voie. Cette architecture diffère du modèle de Constellation, dans lequel environ 16 proposeurs sélectionnés opèrent selon un cycle fixe de 50 ms. Le modèle à voies d’Autobahn permet à tout validateur de maintenir une voie continue de propositions, au lieu d’être sélectionné dans un sous-ensemble tournant et pondéré selon le stake, ce qui élargit considérablement la participation à la production des blocs.

La différence la plus importante concerne l’ordonnancement avec contenu visible. Autobahn permet l’exécution asynchrone en dissociant l’ordonnancement des transactions de leur exécution, un choix de conception que Constellation reporte. Comme expliqué dans la section suivante, l’exécution asynchrone réduit la surface d’attaque de l’ordonnancement avec contenu visible en empêchant les proposeurs de simuler les résultats d’exécution à partir d’un état final connu au moment de l’ordonnancement.

Giga offre une résistance probabiliste à la censure, tandis que Constellation fournit des garanties structurelles. Giga repose sur l’idée qu’une transaction soumise à plusieurs proposeurs est plus difficile à censurer, puisque chaque proposeur dispose d’informations incomplètes et que l’intérêt de la censure peut disparaître si un autre proposeur inclut la transaction dans le même tick. À l’inverse, avec Constellation, un leader qui exclut une transaction suffisamment attestée produit un bloc invalide. La résistance probabiliste augmente le coût de la censure, tandis que la résistance structurelle la rend cryptographiquement impossible. Pour les applications financières que les deux protocoles cherchent à rendre possibles, cette différence compte. 

Il convient de parler franchement de la différence d’ambition entre les deux conceptions. Constellation est une spécification de protocole qui démontre des propriétés de correction, définit les conditions de faute, précise les seuils de quorum et doit être soumise comme proposition formelle à un réseau de production évolutif comptant des milliards de valeur stakée. Le livre blanc de Sei Giga se lit différemment : il est axé sur les objectifs de débit et la compatibilité EVM, tandis que la MEV et la résistance à la censure sont présentées comme des avantages émergents de l’architecture à plusieurs proposeurs plutôt que comme des garanties formellement spécifiées. L’exécution asynchrone va dans la bonne direction, mais Giga n’offre pas le même niveau de garanties formelles que Constellation concernant les contraintes d’ordonnancement, les quorums d’attesteurs ou les conditions de faute. Il ne s’agit pas tant d’une critique des choix de séquençage de Giga que du reflet de contextes différents : Constellation est proposé pour la blockchain de production au débit le plus élevé au monde, ce qui exige et produit un niveau de spécification proportionnellement supérieur.

L’idéal académique

La référence théorique pour la conception d’un MCP est Proposeurs multiples concurrents : pourquoi et comment (2025), de Garimidi et Neu d’a16z Crypto Research et de Max Resnick d’Anza. L’article propose un protocole MCP offrant deux propriétés que ses auteurs jugent indispensables à toute conception résistante à la censure : la résistance à la censure sélective et la dissimulation. La première garantit qu’un adversaire ne peut pas retarder sélectivement des transactions, tandis que la seconde garantit que leur contenu reste invisible avant leur confirmation. Il s’agit de la seule conception MCP de la littérature actuelle qui réalise formellement les deux à la fois.

Le mécanisme qui permet la dissimulation est HECC, pour Hiding Erasure-Correcting Code. Il est paramétré de telle sorte que T shreds ne révèlent aucune information sur le lot de transactions sous-jacent, tandis que K + T shreds permettent sa reconstruction complète. Le détail essentiel est que les relais ne diffusent leurs shreds stockés qu’après que le consensus a confirmé les lots inclus. Cela empêche toute observation du contenu des transactions avant confirmation et élimine entièrement la surface d’attaque de l’ordonnancement avec contenu visible grâce à une garantie issue de la théorie de l’information. 

Selon le cadre élaboré précédemment, cette conception de protocole est la seule qui traite la couche 1 avec une résistance structurelle à la censure, la couche 2 avec la dissimulation et qui borne la couche 3 grâce aux garanties de résistance à la censure fournies par la dissimulation. Ni Constellation ni Giga n’y parviennent intégralement.

Cette comparaison est particulièrement intéressante parce que Resnick, coauteur de l’idéal théorique, est aussi coauteur de Constellation, un protocole qui s’en écarte en toute connaissance de cause. Cela reflète le jugement délibéré selon lequel la conception complète fondée sur HECC ne peut pas encore être déployée sur un réseau de production à l’échelle de Solana, et que la résistance structurelle à la censure est le problème le plus urgent à résoudre en premier. L’article sert d’étoile polaire à Constellation : il spécifie formellement l’objectif vers lequel le protocole évolue, même s’il ne peut pas tout concrétiser en une seule fois. 

Ethereum Braid

Braid est la principale proposition de MCP d’Ethereum. Présentée par Max Resnick, elle est actuellement envisagée dans le cadre de la feuille de route Scourge d’Ethereum, aux côtés de la conception concurrente de listes d’inclusion FOCIL. Sa présence ici vise moins une comparaison technique que la mise en contexte : l’ensemble du secteur tente de résoudre les mêmes problèmes structurels, mais à partir de points de départ différents.

Braid met en œuvre le MCP en permettant à plusieurs proposeurs de construire simultanément des blocs sur des chaînes parallèles au cours d’un même slot, la couche d’exécution agrégeant, dédupliquant et triant les transactions selon des règles prédéfinies. Il n’introduit aucun rôle supplémentaire dans le protocole. La différence la plus importante est que la sécurité de Braid dépend fortement de mempools chiffrés, ce qui fait de la dissimulation un prérequis plutôt qu’un élément reporté. Braid reste une proposition de recherche non déployée, et la communauté Ethereum n’a pas encore trouvé de consensus sur la question de la privilégier par rapport à FOCIL.

Braid confirme en définitive que l’argument structurel en faveur du MCP dépasse le cadre d’une seule chaîne. Il convient également de noter que Resnick a travaillé sur trois des quatre projets présentés dans cette section. C’est peut-être le signe le plus clair que Constellation est le produit d’une réflexion durable, transversale et rigoureuse sur le plan académique autour d’un problème qui a résisté aux solutions simples.

Remarque sur le PBS

La séparation entre proposeur et builder (PBS) mérite d’être mentionnée ici comme contrepoint, plutôt que comme conception comparable. Alors que chaque projet de cette section cherche à limiter structurellement le monopole temporaire du leader, le PBS l’accepte et s’organise autour de lui afin de redistribuer les revenus de la MEV. Constellation est explicitement incompatible avec le PBS : dès lors que la marge de décision d’un leader est contrainte par le registre des attestations, il ne reste plus rien à vendre pour un builder spécialisé. Le fait que le PBS soit devenu le principal mécanisme d’atténuation de la MEV sur Ethereum, bien qu’il ne réduise en rien le préjudice subi par les utilisateurs, représente précisément le mode de défaillance que le MCP cherche à éviter.

Le précédent hors protocole

Avant même le lancement de Constellation, l’écosystème de Solana reproduit déjà certains aspects du MCP hors protocole. Harmonic, par exemple, est une couche ouverte d’agrégation pour la construction de blocs qui collecte et évalue en continu les propositions de blocs de plusieurs builders indépendants, puis les présente en temps réel aux validateurs pour une sélection concurrentielle. Il ne s’agit pas d’un MCP au sens formel, car il n’existe aucune résistance à la censure imposée par le protocole, aucun quorum d’attestation ni aucune contrainte cryptographique limitant la marge de décision du leader. Néanmoins, les validateurs exécutant Harmonic choisissent déjà entre plusieurs propositions de blocs concurrentes, ce qui constitue le mécanisme central que le MCP cherche à inscrire dans le protocole. Avec BAM, ces deux systèmes représentent la tentative de l’écosystème de résoudre des problèmes de structure de marché sans attendre une application au niveau du protocole. Ces systèmes hors protocole montrent que la demande de propriétés similaires à celles du MCP est suffisamment réelle pour que les builders n’attendent pas le lancement de Constellation.

Questions ouvertes

Le livre blanc de Constellation est une spécification de protocole. Il démontre des propriétés de correction selon les hypothèses énoncées et reporte à juste titre tout le reste, ce qui convient à une proposition v0.9. Ce qui suit n’est pas une liste des échecs de Constellation, mais une cartographie des points que son futur SIMD et ses prochaines versions devront traiter pour intégrer efficacement le MCP à Solana. 

Ces questions ne présentent pas toutes le même degré de difficulté. Certaines relèvent du travail de spécification : ce sont des décisions de conception qu’Anza peut et doit résoudre par le processus SIMD normal. D’autres sont de véritables problèmes ouverts que la communauté de recherche sur le MCP n’a pas encore résolus, mais dont nous devons avoir conscience alors que nous ouvrons la voie pour devenir la première blockchain à grande échelle à mettre en œuvre le MCP. Aucun SIMD ne peut à lui seul résoudre ces problèmes. Cette distinction est importante, car confondre les deux risquerait soit d’exagérer les lacunes de Constellation, soit de sous-estimer le travail restant.

Les travaux SIMD les plus simples comprennent :

• Répartition des frais : la manière dont les frais de priorité sont répartis entre les proposeurs, les attesteurs et l’ensemble plus large des validateurs est décrite, mais pas entièrement détaillée. Le livre blanc indique que les frais de priorité sont restitués à l’écosystème proportionnellement au stake, mais le mécanisme exact de répartition entre proposeurs, attesteurs et validateurs n’est pas défini.
• Structure des récompenses des validateurs : la manière dont les proposeurs sont rémunérés par rapport aux récompenses actuelles des validateurs, et la question de savoir si la suppression des frais liés aux transactions de vote avec Alpenglow modifie le calcul pour les petits validateurs.
• Séquençage du déploiement : Constellation dépend d’Alpenglow, dont le lancement est prévu au troisième trimestre 2026. Le SIMD doit préciser explicitement cette dépendance et traiter ce qui se passera pendant la période de transition entre Alpenglow seul et Constellation+Alpenglow. Certains SIMD prérequis doivent-ils être déployés sur mainnet en premier ?
• Gouvernance des paramètres des rôles : le nombre de proposeurs (p ≈ 16), le nombre d’attesteurs (q ≈ 256), la durée du cycle (△cycle = 50 ms) et les autres paramètres du tableau 1 du livre blanc de Constellation sont présentés comme de simples suggestions. Le SIMD doit préciser comment ces paramètres doivent être définis, gouvernés et éventuellement modifiés au fil du temps.

Les questions plus difficiles, comme l’exécution asynchrone, le slashing et la confidentialité de la couche de soumission, sont abordées dans les sous-sections suivantes. La communauté de recherche sur le MCP travaille activement sur ces questions, dont nous devons tenir compte, car les choix de conception de Constellation peuvent faciliter ou compliquer l’accès à certaines solutions futures.

Exécution asynchrone

Dans le cadre d’une exécution synchrone, un proposeur qui reçoit une transaction en texte clair, ou qui peut la décoder de manière anticipée avec un modèle de soumission naïf, connaît son contenu et peut en simuler le résultat. Il peut exécuter la transaction sur l’état actuel afin de calculer précisément le résultat de son exécution, notamment les prix des swaps, les variations des soldes de comptes et les possibilités d’arbitrage en aval. C’est ce qui donne aux attaques sandwich leur précision mécanique. Les attaquants peuvent repérer les swaps importants et calculer le montant nécessaire pour effectuer un front-running maximisant leurs profits.

L’exécution asynchrone supprime la seconde moitié de cet avantage, mais uniquement lorsqu’elle est associée au MCP. Si le consensus valide l’ordonnancement des transactions avant leur exécution, un proposeur qui voit le contenu d’une transaction ne peut pas simuler son résultat d’exécution à partir d’un état final connu, car cet état n’existe pas au moment de l’ordonnancement. L’avantage informationnel passe alors de « je sais ce que fait cette transaction et dans quel ordre elle s’exécute » à « je sais ce qu’est cette transaction, mais pas ce qu’elle fera par rapport à l’ensemble ordonné final ». Cet avantage suppose que le proposeur ne contrôle pas l’ordonnancement final. Dans un modèle à leader unique, l’exécution asynchrone seule n’offre pas cette protection, car le leader conserve toute latitude sur l’ordonnancement et peut positionner avantageusement ses propres transactions, quel que soit le moment de leur exécution. C’est la combinaison d’un ordonnancement contraint et d’une exécution différée qui réduit la surface d’attaque.

Notons que l’exécution asynchrone ne ferme pas complètement la couche 2. Un proposeur sophistiqué peut encore procéder à des inférences catégorielles. Par exemple, il peut toujours voir qu’une transaction interagit avec un pool de liquidité précis et en déduire sa direction probable sans en connaître le résultat exact. Cela relève sensiblement le niveau de difficulté des formes d’exploitation les plus mécaniques et rentables, et représente la voie architecturale la plus claire pour réduire la couche 2 sans recourir à une dissimulation cryptographique au niveau du consensus. C’est notamment l’approche choisie par Sei Giga, qui fait de l’exécution asynchrone une priorité architecturale de premier ordre aux côtés du MCP.

Cela soulève une question naturelle qui mérite réflexion : pourquoi l’exécution asynchrone n’a-t-elle pas été mise en œuvre en premier ? Elle réduit la couche 2 et aurait pu, en principe, être développée comme une modification circonscrite de la couche d’exécution, sans introduire la complexité supplémentaire du MCP au niveau du protocole, à savoir de nouveaux rôles de nœuds, des exigences de synchronisation des horloges UTC, une conception du slashing encore non résolue et un doublement de la charge liée au shredding. 

L’argument le plus solide en faveur de cet ordre est que l’exécution asynchrone et le MCP résolvent des problèmes différents. Le MCP apporte des contraintes structurelles d’ordonnancement que l’exécution asynchrone seule ne peut pas fournir : un validateur qui ne peut pas simuler les résultats d’exécution, mais qui voit toujours le contenu des transactions, peut exercer son pouvoir discrétionnaire sur l’ordonnancement dans la fenêtre autorisée par le protocole. L’argument en faveur d’un MCP mis en œuvre en premier est qu’il contraint structurellement la couche 1, qui constitue la menace la plus évidente et la plus immédiate sur le plan économique. Adapter l’exécution asynchrone au modèle d’exécution synchrone existant de Solana est un problème d’ingénierie plus difficile que de l’intégrer dès le départ à une nouvelle chaîne, compte tenu des hypothèses de composabilité et de l’architecture des programmes de Solana. Sei Giga a le luxe de pouvoir concevoir son système pour l’exécution asynchrone dès le premier jour, contrairement à Solana. Cette asymétrie pratique peut être aussi importante que l’argument de priorité théorique pour expliquer pourquoi le MCP a été privilégié. L’architecture d’Alpenglow rend également le MCP plus facile à mettre en œuvre qu’il ne l’aurait été avec Tower BFT, comme nous l’examinons dans la sous-section suivante consacrée à la complexité du protocole.

La pertinence de cet ordre reste une question ouverte légitime. Constellation ne modifie pas la couche 2, ce qui pose problème compte tenu des nouveaux vecteurs d’attaque que le MCP introduit dans la couche 3. Cela peut à son tour rendre les attaques de couche 2 plus rentables, puisque les deux surfaces d’attaque sont complémentaires. Par exemple, un proposeur qui voit une transaction DEX importante peut retarder ses pshreds afin de l’exclure de la fenêtre du lot en cours, tout en effectuant un front-running avec sa propre transaction dans cette même fenêtre. La visibilité de la couche 2 et les jeux de timing de la couche 3 sont des armes indissociables au sein de la même surface d’attaque et ne feront que gagner en sophistication à mesure que Solana mûrit.

Slashing

L’application cryptographique fonctionne bien lorsque le comportement fautif d’un acteur produit un artefact vérifiable, par exemple des signatures contradictoires, des contrôles de validité échoués ou des engagements dont la malformation peut être prouvée. Constellation répond avec autant d’efficacité aux préoccupations de résistance à la censure de la couche 1 parce qu’un leader qui exclut une transaction attestée produit un bloc invalide, et que cette invalidité peut être démontrée mathématiquement. Les jeux de timing et la manipulation de la latence ne produisent aucun artefact de ce type. La difficulté tient au fait que ce comportement fautif est impossible à distinguer d’un retard réseau légitime à l’échelle de chaque acte. La faute se manifeste par une absence, qui ne peut pas être prouvée cryptographiquement. Le seul levier disponible est la dissuasion économique, qui nécessite le slashing. 

Le problème du slashing est qu’il exige traditionnellement une faute démontrable. Les mécanismes de témoins de faute de Constellation couvrent le cas où un proposeur qui signe deux pshreds contradictoires peut être identifié et exclu. Toutefois, la manipulation stratégique de la latence ne produit aucun témoin de faute. Ni équivocation, ni double signature, ni empreinte onchain. Un proposeur qui se contente de retarder systématiquement et sélectivement la transmission des pshreds de quelques millisecondes ne laisse rien qui puisse faire l’objet d’un slashing. 

Si les pshreds d’un proposeur parviennent systématiquement aux attesteurs dans les dernières millisecondes de la fenêtre du cycle, et ce sur de nombreux cycles pour des transactions qui se trouvent être concurrentes des propres soumissions du proposeur, un mécanisme de slashing bien spécifié pourrait considérer ce schéma comme la preuve d’une manipulation systématique, même en l’absence d’un acte malveillant démontrable pris isolément. Le slashing traditionnel ne peut pas traiter directement ce problème. Dans sa forme canonique, il exige une preuve non ambiguë et autonome, or aucune preuve de ce type n’existe pour un proposeur qui a simplement retardé la transmission de quelques millisecondes. Ce qui diffère, c’est le schéma récurrent.

La finance traditionnelle pourrait ici fournir des enseignements utiles à la finance décentralisée sur l’approche réglementaire de la manipulation fondée sur la latence. L’application des règles contre le spoofing prévues par le Dodd-Frank Act, par exemple, repose sur la détection de schémas statistiques, comme les ratios entre annulations et exécutions, les distributions temporelles des annulations ou les corrélations avec l’impact sur les prix, plutôt que sur la démonstration d’une intention pour chaque ordre individuel. Aucune occurrence isolée n’est manifestement intentionnelle. En revanche, le schéma l’est. La même logique s’applique, car la régularité statistique est objective même lorsque les actes individuels ne le sont pas. De plus, l’incitation économique à manipuler existe autant dans les ensembles de proposeurs sans permission que chez les traders à haute fréquence de la finance traditionnelle. L’analogie cesse toutefois de fonctionner au niveau de l’application des règles. Le Dodd-Frank Act repose en effet sur une autorité de régulation disposant d’un pouvoir d’assignation, tandis qu’un environnement trustless exige que les mécanismes de détection et de sanction soient inscrits dans le protocole lui-même.

Nous proposons d’adapter les nœuds fisherman comme mécanisme potentiel pour combler cette lacune. Initialement présentés dans les recherches de Vitalik sur la disponibilité des données, les nœuds fisherman pourraient être adaptés pour constituer une catégorie d’observateurs qui surveillent les données d’attestation sur de nombreux cycles et soumettent des preuves statistiques de fraude à un protocole d’arbitrage intégré. Une arrivée tardive prise isolément est subjective. En revanche, le schéma calculé de manière déterministe sur n cycles est objectif. C’est le même principe que celui des preuves de fraude dans les rollups optimistes, mais appliqué au comportement temporel plutôt qu’aux transitions d’état. De plus, un protocole d’arbitrage intégré pour les preuves statistiques de fraude n’est pas fondamentalement différent des nouveaux outils de gouvernance en cours de développement, qui permettraient aux stakers de remplacer les votes de leur validateur lors de futures propositions de gouvernance. Si Solana est prêt à se doter d’une infrastructure permettant aux stakers de remplacer ces votes, les fondations techniques d’un système d’arbitrage fondé sur des fisherman pourraient être plus proches qu’il n’y paraît.

Cette exploration des nœuds fisherman représente une piste plus crédible que l’extension du slashing canonique à des actes qui ne laissent aucune empreinte onchain isolée. Il s’agit aussi d’une piste que le développement actuel de l’infrastructure de gouvernance du protocole pourrait déjà permettre de prendre en charge. Cela dit, toute spécification concrète devrait traiter trois limites. Premièrement, effectuer une analyse statistique des données de timing des attestations sur des milliers de cycles n’est pas trivial et pourrait facilement augmenter les exigences matérielles imposées aux validateurs. Cela accroît les coûts opérationnels et risque de concentrer le rôle de détection des fraudes entre les mains d’un groupe restreint d’acteurs sophistiqués. Deuxièmement, toute spécification de seuil doit être suffisamment robuste pour distinguer les variations réelles du réseau des manipulations stratégiques, sans être excessivement stricte au point de produire des faux positifs. Troisièmement, le protocole d’arbitrage introduit lui-même une nouvelle surface d’attaque permettant de manipuler ce nouveau système fondé sur des fisherman au moyen de signalements coordonnés. La conception d’un tel protocole devrait en tenir compte, éventuellement par des mécanismes d’incitation rendant l’exploitation de fisherman viable pour les plus petits participants, ou par des schémas d’agrégation répartissant les calculs entre l’ensemble des fisherman.

La question de recherche concrète que nous posons est la suivante : peut-on spécifier un cadre de preuves statistiques de fraude, définissant les paramètres de seuil, tenant compte des variations du réseau et précisant l’échelle des sanctions, qui soit à la fois suffisamment robuste pour dissuader la manipulation systémique de la latence, suffisamment prudent pour éviter de sanctionner les variations légitimes et suffisamment simple pour résister aux manipulations adversariales d’opérateurs sophistiqués ? Il s’agit de l’un des problèmes ouverts les plus exigeants sur le plan technique dans la littérature consacrée au MCP, et la communauté de recherche dans son ensemble ne l’a pas encore résolu.

Dissimulation

Le slashing n’est pas la seule solution aux jeux de manipulation du timing et de la latence. La dissimulation traite à la fois les problèmes d’ordonnancement avec contenu visible et ceux de manipulation du timing et de la latence, que ni l’exécution asynchrone ni le slashing ne peuvent résoudre seuls. Constellation met en œuvre une dissimulation partielle, c’est-à-dire que le contenu d’une transaction n’est visible que par le ou les proposeurs qui la reçoivent, puis par le leader après l’expiration du délai du cycle, mais n’offre pas une dissimulation complète. La surface d’attaque évolue avec le nombre de proposeurs auxquels un utilisateur choisit de soumettre sa transaction. Si cette dissimulation partielle réduit la surface d’attaque par rapport à une visibilité totale, elle ne la ferme pas. La dissimulation complète, dans laquelle aucune partie n’observe le contenu d’une transaction avant sa confirmation, reste un problème ouvert pour Constellation.

L’idéal théorique correspond à l’approche décrite par Garimidi et al., qui utilise le Hiding Erasure-Correcting Code (HECC) comme primitive. Contrairement au Reed-Solomon standard de Constellation, HECC fournit une garantie issue de la théorie de l’information selon laquelle un adversaire qui collecte moins de shreds que le seuil défini n’apprend rien sur le contenu de la transaction. Constellation a choisi de continuer à utiliser le codage d’effacement actuellement déployé sur Solana via Turbine.

Le développement récent le plus pertinent est le Block Assembly Marketplace (BAM) de Jito, qui utilise des environnements d’exécution de confiance (TEE) afin de créer un mempool chiffré où les transactions restent privées jusqu’à leur exécution. BAM montre qu’il existe une demande matérielle croissante pour la confidentialité du contenu sur Solana. La dissimulation fondée sur les TEE n’est toutefois pas sans limites : elle transfère les hypothèses de confiance aux fabricants de matériel, ce qui constitue une contrainte importante pour un protocole visant un fonctionnement trustless. Il convient d’explorer en profondeur une voie reposant sur le chiffrement à seuil afin d’offrir une alternative fondée sur des principes plus solides.

BAM est important dans la mesure où il représente une tentative hors protocole de résoudre le problème de visibilité du contenu que Constellation reporte. Grâce à BAM, Jito est en mesure de fournir à grande échelle une confidentialité des transactions avant même le lancement de Constellation. Cela soulève la question de savoir si la dissimulation au niveau du protocole reste urgente lorsqu’une solution au niveau applicatif peut déjà la fournir. La réponse dépend entièrement des hypothèses de confiance et de la question de savoir si les fabricants de matériel sont jugés « suffisamment » dignes de confiance par rapport à ce que le protocole pourrait théoriquement garantir. Cette solution ne peut néanmoins pas être considérée comme permanente. La voie la plus probable est que BAM assure la confidentialité à court terme, tandis que les futures versions de Constellation exploreront le chiffrement à seuil comme solution à plus long terme.

Pour un protocole qui aspire à devenir l’infrastructure des marchés de capitaux sur Internet, la dissimulation partielle représente une avancée significative, mais pas une destination finale. La lacune restante correspond à la différence entre une structure de marché équitable et une structure simplement moins inéquitable que celle qui existe aujourd’hui. 

Complexité du protocole

Constellation est la mise à niveau la plus ambitieuse sur le plan structurel proposée à Solana depuis sa création. Elle introduit trois nouveaux rôles de nœuds, un nouveau modèle de timing dépendant de la synchronisation des horloges UTC, de nouvelles passes de codage d’effacement, de nouveaux types de messages et de nouveaux modes de défaillance, le tout par-dessus Alpenglow, qui n’est pas encore déployé sur mainnet. La question de savoir si le moment est bien choisi pour assumer cette complexité est sérieuse et mérite davantage qu’un simple optimisme.

Solana a acquis par le passé une réputation notoire en raison des différentes pannes qui ont affecté le réseau en 2021 et 2022. Ces pannes avaient un point commun : elles provenaient de la difficulté inhérente à raisonner sur les cas limites d’un protocole novateur à haut débit dans des conditions de charge réelles. Les plus de deux années de disponibilité continue que le réseau a depuis récemment atteintes constituent une véritable étape, forgée dans les épreuves douloureuses de l’itération. Ce bilan incite à faire confiance à la maturité de Solana. 

Toute modification du protocole de l’ampleur de Constellation exige désormais une implémentation simultanée dans Agave et Firedancer. Deux équipes de développement indépendantes doivent donc s’accorder sur une sémantique du protocole, des cas limites et des hypothèses de timing qui sont nouveaux pour toutes deux. Parvenir à cet alignement pour Alpenglow seul représente déjà une complexité importante, que Constellation ne fera qu’amplifier. Ce n’est pas un argument contre la poursuite du projet. C’est plutôt un argument en faveur de l’inclusion d’un plan clair d’implémentation multiclient dans le futur SIMD de Constellation.

Les institutions financières commencent à migrer onchain. Les conséquences d’une panne importante sont nettement plus graves qu’en 2021, tant en matière de réputation que de préjudice économique. En tant que communauté, nous devons être honnêtes quant à la complexité introduite par Constellation. Le futur SIMD doit être abordé avec la rigueur qu’exige un système financier mondial. 

La question du pourquoi maintenant se pose naturellement. Voulons-nous réellement assumer le risque d’une telle mise à niveau ? N’existe-t-il pas des améliorations progressives que nous pourrions apporter au fil du temps afin d’atténuer ce changement ? Les explorations précédentes sur l’exécution asynchrone et le slashing, par exemple, suggèrent qu’une autre voie progressive est possible. Une version de la feuille de route de Constellation dans laquelle l’écosystème bénéficie de déploiements échelonnés pour différentes améliorations complémentaires est envisageable. Que cette approche soit considérée comme prudente ou comme un frein à l’accélération relève autant des valeurs que de la technique, et des personnes raisonnables peuvent ne pas être d’accord. Nous construisons autant un système porteur de sens qu’un système dédié à la finance.

Cela se produit déjà dans la pratique. Anza a confirmé que les slots de 200 ms et les fenêtres de leader de deux slots seront déployés avant Constellation. Solana bénéficiera donc d’améliorations de performances significatives qui traiteront certaines préoccupations de la communauté concernant la latence de séquençage, que nous examinerons dans la section suivante, sans nécessiter toute la complexité du MCP. Si les slots de 200 ms rapprochent suffisamment le parcours de confirmation de Solana du surcoût prévu de Constellation pour que le coût marginal du MCP soit faible, l’argument politique devient beaucoup plus facile à défendre. Toutefois, si les acteurs établis du trading considèrent les 200 ms comme « suffisamment bonnes », l’urgence de Constellation diminue. Des projections comparatives de latence montrant les slots de 200 ms seuls face aux slots de 200 ms avec Constellation peuvent aider la communauté à évaluer le coût supplémentaire au regard de la garantie supplémentaire. Nous devrons évidemment attendre le futur SIMD de Constellation et son implémentation proposée pour en juger.

L’argument le plus solide en faveur de la poursuite du projet est la fenêtre ouverte par Alpenglow. Constellation hérite du modèle de sécurité d’Alpenglow, utilise Rotor comme couche de diffusion des données et bénéficie de la suppression de la complexité de Tower BFT. Le coût marginal de l’ajout du MCP à Alpenglow est inférieur à celui d’une future conception de consensus créée à partir de zéro. Attendre n’est pas sans coût, compte tenu des travaux de nos concurrents visant à intégrer le MCP onchain et du fait que reporter la résistance à la censure à un futur cycle de mise à niveau entraînera inévitablement sa propre complexité et ses propres obstacles politiques.

Si ce n’est pas maintenant, quand ?

Cette complexité est justifiée, mais cette justification doit être étayée par une spécification rigoureuse, des déploiements échelonnés et une validation empirique des affirmations sur la latence et la bande passante que la communauté débat actuellement sur une base purement théorique. 

Constellation est-il aligné sur l’IBRL ?

Latence de séquençage et latence d’inclusion

La réaction initiale de la communauté Solana à Constellation a été pour le moins polarisée. Cette réaction a fait émerger un débat important qui mérite une réponse précise plutôt que diplomatique. La formulation la plus tranchée est venue du tweet de Cavey, qui affirme que « le MCP et l’IBRL sont fondamentalement incompatibles ». Selon lui, le MCP réduit directement et incontestablement la bande passante et augmente la latence dans le but d’améliorer la structure du marché. La réponse de Toly a été tout aussi directe : « Vous avez tort. Il n’existe aucun moyen de réduire la latence d’inclusion sans MCP. »

Les deux ont techniquement raison : ils ne mesurent pas la même chose.

Le MCP réduit la latence d’inclusion et augmente la latence de séquençage. Ce ne sont pas les mêmes propriétés, et leur confusion est à l’origine de l’essentiel du débat actuel.

La latence de séquençage correspond au temps écoulé entre la soumission d’une transaction et son exécution. Elle augmente nécessairement avec le MCP, car le tour des attesteurs, la fenêtre de cycle de 50 ms et l’étape d’assemblage des lots ajoutent tous un délai absent du parcours de soumission actuel via le TPU vers un leader coopératif. La critique selon laquelle des acteurs rationnels qui envoient leurs transactions à plusieurs proposeurs consomment davantage de bande passante est exacte. L’ajout de latence par la fenêtre de regroupement l’est également. Ce sont des coûts réels qui doivent être mesurés et présentés à la communauté comme des compromis nécessaires à l’élimination de la censure stricte.

La latence d’inclusion est la fenêtre temporelle garantie pendant laquelle une transaction valide offrant des frais compétitifs sera incluse. Dans le modèle actuel à leader unique, cette garantie est essentiellement non bornée. Autrement dit, un leader qui souhaite retarder ou exclure une transaction donnée peut le faire, sans qu’aucun mécanisme du protocole ne puisse l’en empêcher. La latence que subissent déjà les utilisateurs comprend tous les frottements liés à la rétention, à la planification et aux jeux de timing, ainsi que l’ordonnancement sélectif imposé par les leaders. L’argument selon lequel les délais de confirmation réels incluent la latence de ces jeux, de sorte que l’expérience nette des utilisateurs pourrait s’améliorer, va dans la bonne direction avec ce cadre d’analyse et est étayé par les discussions actuellement en cours sur X au sein de la communauté. 

La véritable question est de savoir quelle latence optimiser.

FIFO, FCFS ou FBO

Avant d’examiner quelle latence optimiser, il convient de comprendre un débat connexe que la communauté mène en parallèle : le MCP est-il compatible avec FIFO ?

Le FIFO (First In, First Out, ou premier entré, premier sorti) est un principe général d’ordonnancement selon lequel les transactions sont traitées dans leur ordre d’arrivée. Umberto a longuement expliqué pourquoi la réponse est intrinsèquement nuancée. MCP peut produire ce que l’on appelle un « FIFO probabiliste », mais uniquement dans des conditions d’infrastructure précises. En substance, si un utilisateur est suffisamment proche d’un nombre suffisant de proposeurs pour éviter la censure, et si ces proposeurs sont eux-mêmes assez proches des attestateurs pour atteindre rapidement le seuil d’attestation de 40 % garantissant l’inclusion, alors l’utilisateur bénéficie en pratique d’une inclusion FIFO. Autrement dit, sa transaction est incluse avant qu’un concurrent ait le temps de l’observer et d’y réagir. La course s’achève au moment de l’inclusion plutôt qu’à celui de l’exécution. Dans ces conditions, MCP se rapproche du FIFO en tant que propriété émergente, et non comme règle du protocole.

Le problème est que l’infrastructure actuelle de Solana ne remplit pas ces conditions. Le stake est concentré dans une poignée de régions, ce qui entrave la formation d’un quorum, qui doit atteindre des poches de stake très denses. Cette concentration crée une fenêtre pendant laquelle un observateur « géographiquement avantagé » peut devancer une transaction en cours de propagation. La répartition géographique et la densité des attestateurs nécessaires au FIFO probabiliste sont aussi déterminantes que la conception même du protocole pour le déploiement de Constellation. Un protocole qui garantit la résistance à la censure, mais permet le front-running fondé sur la latence en raison d’une infrastructure géographiquement clairsemée, n’offrira pas l’équité de marché promise par son livre blanc.

Une question liée, mais distincte, consiste à savoir si Constellation aurait pu mettre en œuvre le FCFS, mais a choisi de ne pas le faire. Alors que le FIFO est une propriété émergente de l’infrastructure, le FCFS (First Come, First Served, ou premier arrivé, premier servi) est une règle de protocole précise qui garantit que la première transaction reçue est traitée de manière déterministe. Il convient de noter que Constellation applique bien un ordonnancement déterministe : les transactions sont triées par frais de priorité au sein de chaque lot. La question n’est donc pas de savoir si l’ordonnancement est imposé par le protocole, mais si l’heure d’arrivée doit prévaloir sur les frais de priorité pour déterminer cet ordonnancement.

Un débat récent a fait émerger une objection plus fondamentale que celle soulevée initialement : le FCFS pourrait être totalement inapplicable dans un environnement sans confiance. Les validateurs peuvent simplement falsifier l’ordre d’arrivée des transactions sans laisser la moindre trace onchain. Il s’agit du même problème d’absence de preuve qui empêche de sanctionner la manipulation temporelle par slashing au sens traditionnel, et qui pourrait exiger des solutions plus créatives, comme l’approche de détection statistique de schémas développée dans la sous-section consacrée au slashing. Une règle de protocole que les validateurs honnêtes respecteraient, mais que les validateurs malhonnêtes pourraient ignorer discrètement, ne constitue pas une garantie réelle. L’absence de FCFS dans Constellation n’apparaît donc plus comme une préférence de conception nécessitant une explication, mais comme la reconnaissance que, dans un ensemble de validateurs permissionless, le FCFS ne peut peut-être pas encore être implémenté sur Solana comme une propriété stricte du protocole, du moins dans le cadre des hypothèses actuelles. Si le FCFS est réellement inapplicable dans un ensemble de validateurs permissionless selon les hypothèses actuelles, le SIMD doit expliciter cette contrainte et justifier l’ordonnancement par frais de priorité comme choix de conception par défaut. Laisser la communauté débattre du FCFS comme s’il s’agissait d’une option viable que Constellation avait choisi de ne pas implémenter, au lieu de le présenter comme une propriété potentiellement impossible à mettre en œuvre, ne fera qu’accroître les tensions au sein de la communauté.

L’ordonnancement par frais de priorité dans un intervalle de temps fixe n’est pas un compromis inédit. Il est connu sous le nom d’enchère fréquente par lots (frequent batch auction, ou FBA), un modèle de microstructure de marché bénéficiant d’un soutien universitaire important. Budish, Cramton et Shim affirment par exemple dans La course aux armements du trading à haute fréquence : les enchères fréquentes par lots comme réponse de conception des marchés (2015) que les enchères par lots à temps discret, assorties de prix de compensation uniformes, éliminent la course à la vitesse créée par les marchés en temps continu. La concurrence fondée sur la latence est ainsi remplacée par une concurrence fondée sur les prix. Constellation s’en inspire pour introduire le Fixed Batch Ordering (FBO), fondé sur les frais de priorité. Le cycle de 50 ms de Constellation concrétise donc ce modèle : les transactions se concurrencent sur les frais plutôt que sur l’heure d’arrivée au sein de chaque lot, et toutes les transactions d’un même lot bénéficient du même traitement d’ordonnancement. Il s’agit précisément de la catégorie d’applications précédemment décrite comme n’existant pas encore à grande échelle sur Solana. 

Les débats sur le FIFO, le FCFS et le FBO portent en grande partie sur la même préoccupation sous-jacente : qui contrôle l’ordonnancement une fois la résistance à la censure garantie, et si la structure de marché que Constellation cherche à créer est réellement équitable ou simplement moins injuste que celle qui existe aujourd’hui. Constellation élimine la forme de manipulation la plus manifeste. Ce qui la remplacera dépendra des choix que le livre blanc laisse au SIMD.     

Alors, qu’optimisons-nous ?

La latence de séquencement est particulièrement importante pour les applications de trading existantes, comme les AMM, les desks de trading pour compte propre et les CLOB. Ces applications reposent sur l’hypothèse que l’acteur le plus rapide et le plus compétitif sur les frais l’emporte, et elles ont conçu leur infrastructure en conséquence. Le trading ne devrait être limité que par les lois de la physique afin d’offrir une expérience utilisateur sans équivalent sur Solana. Pour certains de ces utilisateurs, Constellation représente un recul sur la métrique qui compte le plus pour eux. Le risque est que Solana commette la même erreur fatale qu’Ethereum autrefois : privilégier la structure de marché au détriment des performances, ce qui pourrait pousser l’exécution hors de la blockchain. C’est un risque légitime qui mérite d’être discuté.

Pour les applications financières que Constellation doit rendre possibles, comme les enchères onchain, les carnets d’ordres assortis de garanties d’inclusion fiables et les protocoles DeFi résistants à la censure, la latence d’inclusion est la bonne métrique. Un ordre à cours limité qui peut faire l’objet de front-running ou être retardé de manière sélective offre des garanties plus faibles qu’un ordre de type boursier, quelle que soit la rapidité nominale de sa confirmation. Solana peut désormais prendre en charge des applications de trading par enchères en lots avec des prix de compensation uniformes, où le séquencement ne devrait pas affecter le prix d’exécution. Cette catégorie d’applications est aujourd’hui largement absente de Solana, précisément parce qu’aucune garantie d’inclusion n’est disponible. On peut considérer que Constellation privilégie excessivement une conception optimisée pour des utilisateurs qui n’existent pas encore à grande échelle sur Solana, au détriment de ceux qui existent déjà ; un argument déjà avancé par des contributeurs principaux.   

La question de la latence de séquencement doit être replacée dans le contexte du recul significatif que Solana subit actuellement face à Hyperliquid sur le marché des contrats perpétuels. Hyperliquid est une plateforme d’échange de contrats perpétuels dotée d’un séquenceur centralisé et conçue spécifiquement à cet effet. Elle ne prétend pas être décentralisée, mais offre une expérience d’exécution attrayante en moins d’une milliseconde, dont ont besoin les traders et les applications sophistiqués. Hyperliquid a délibérément choisi de créer un produit que les professionnels veulent réellement utiliser, en sacrifiant les principes fondamentaux qui font véritablement de la crypto de la « crypto ». Le risque implicite de Constellation est que l’ajout d’une surcharge de communication et de cycles d’attestation au parcours de confirmation constitue le même compromis que celui fait par Hyperliquid, mais dans la mauvaise direction. Les critiques voient d’un mauvais œil le sacrifice de tout avantage potentiel en matière de performances qui permet actuellement à Solana de rivaliser avec les applications de trading centralisées, alors même que les applications financières susceptibles de justifier ce compromis n’existent pas encore, et ils le font savoir avec force.

Cette préoccupation ne doit pas être écartée aussi facilement. Nous pouvons reformuler notre précédente question — faut-il optimiser la latence de séquencement ou la latence d’inclusion ? — en nous demandant si Solana peut se permettre ce compromis, compte tenu de la concurrence à laquelle elle fait actuellement face.

Il existe toutefois un problème plus profond. La comparaison avec Hyperliquid montre que la signification d’IBRL a peut-être évolué au fil du temps. La motivation initiale de Toly et Raj pour créer Solana était la résistance à la censure : « Pour permettre aux produits DeFi d’attirer des milliards d’utilisateurs et d’appareils, nous devons faire évoluer la résistance à la censure… C’est le problème le plus important à résoudre et la raison même pour laquelle nous avons créé Solana. » IBRL est apparu bien plus tard comme l’expression technique de cette mission : construire un réseau suffisamment rapide pour qu’un système décentralisé puisse surpasser les infrastructures centralisées sur les métriques qui comptent. Depuis, IBRL a acquis sa propre signification techno-optimiste et est devenu omniprésent dans l’air du temps culturel de Solana. Il tient à parts égales du diktat technique, du signe de reconnaissance culturel et de la prière laïque. Pour beaucoup, il est devenu une fin plutôt qu’un moyen : la minimisation de la latence de séquencement est désormais une fin en soi, dissociée de l’objectif de résistance à la censure qu’elle devait servir.

Si cette dérive a bien eu lieu, comme cela semble être le cas, Constellation se heurtera à une forte résistance culturelle. Cette dynamique n’est pas nouvelle, comme l’a montré le rejet par la communauté de SIMD-228, une proposition controversée de réduction de l’inflation qui n’a pas obtenu suffisamment de voix lors du vote de gouvernance. Même les propositions les plus largement bénéfiques peuvent échouer lorsqu’elles vont à l’encontre des convictions profondément ancrées de la communauté. Le cas de Constellation est plus nuancé, car ses coûts en bande passante et en latence sont réels, mais leur effet net sur l’expérience utilisateur n’a pas été quantifié. Il est prématuré de tirer des conclusions définitives dans un sens ou dans l’autre sans disposer de données. Ce qui manque à la communauté, et ce qu’Anza devra fournir pour présenter un SIMD convaincant, ce sont des données empiriques sur le parcours de confirmation dans des conditions réseau réalistes. Alpenglow n’a pas rencontré ce problème grâce à son alignement sur IBRL : une réduction par 100 du délai de finalisation des transactions et un consensus rationalisé. Le bien-fondé de Constellation est moins intuitif, mais tout aussi réel si les futurs benchmarks le confirment.

Il semble que la communauté jugera une mise à niveau résistante à la censure selon une métrique de performance qu’elle n’a jamais été conçue pour optimiser. La question la plus constructive est de savoir si ce compromis en vaut la peine. Son coût est réel et mesurable : une hausse de la latence de séquencement et de la consommation de bande passante en échange d’une garantie stricte, imposée par le protocole, qu’aucun leader ne peut exclure sélectivement une transaction. Il s’agit d’un prérequis pour les applications financières que Solana cherche actuellement à attirer.

Selon nous, Constellation est aligné sur IBRL si l’on retient l’interprétation correcte de l’objectif qu’IBRL a toujours été censé poursuivre. L’adhésion de la communauté à cette conclusion dépendra moins des qualités techniques que de la présentation de preuves empiriques et de l’explication des choix de conception.  

Conclusion

Constellation est la première proposition formelle au niveau du protocole visant à déployer MCP à grande échelle sur une blockchain en production. Elle résout structurellement la censure stricte : les transactions compétitives en matière de frais et attestées par un quorum suffisant ne peuvent pas être exclues d’un bloc valide. Cette garantie cryptographique transforme ce qu’il est possible de créer sur Solana. 

Ce que Constellation reporte en connaissance de cause est tout aussi important. L’ordonnancement fondé sur le contenu visible est partiellement atténué par le modèle de soumission de Constellation, dans lequel seul le proposeur destinataire voit le contenu de la transaction. Cependant, la surface d’attaque résiduelle augmente avec le nombre de proposeurs auxquels un utilisateur soumet sa transaction. La manipulation du timing et de la latence reste le principal problème non résolu et ne peut actuellement pas être sanctionnée dans le cadre de la conception actuelle. Les voies potentielles pour y remédier, comme l’exécution asynchrone, le slashing ou la dissimulation, sont identifiées mais non spécifiées, et chacune apporte ses propres complexités. Le livre blanc de Constellation expose honnêtement ces limites, et son futur SIMD devra en faire autant.

La question la plus difficile soulevée par Constellation est de savoir si Solana peut se permettre les compromis qu’il introduit. Le coût réel et mesurable en matière de latence de séquencement et de bande passante n’a pas encore été quantifié. De même, les garanties d’inclusion offrent un avantage réel, mais non mesuré, et ne disposent pas encore d’une base d’applications suffisante pour les justifier à grande échelle. Il est demandé à la communauté d’investir dans une infrastructure destinée à des applications financières qui sont aujourd’hui largement absentes de Solana, potentiellement au détriment des applications de trading qui y existent déjà. Déterminer si cette approche est visionnaire ou prématurée dépend de données dont la communauté ne dispose pas encore.

Le bien-fondé de Constellation sera finalement confirmé ou infirmé par ses futurs benchmarks empiriques réalisés dans des conditions réalistes. La comparaison entre le parcours de confirmation avec des slots de 200 ms seuls et celui avec des slots de 200 ms sous Constellation est la donnée la plus importante qu’Anza puisse fournir. D’ici là, la communauté débat de compromis qu’elle ne peut pas quantifier.

Selon nous, Constellation représente la prochaine étape appropriée de la feuille de route du protocole ouverte par Alpenglow. Il est aligné sur IBRL si l’on retient l’interprétation d’IBRL que Solana devait initialement servir. Cette opinion dépend toutefois de la capacité du SIMD à atteindre le niveau de rigueur qu’exige un système financier mondial, qu’il s’agisse de sa spécification, de son déploiement progressif, de ses tests ou des preuves empiriques présentées à la communauté à laquelle il demande de l’adopter.

Ressources supplémentaires

• Budish, E., Cramton, P., et Shim, J. (2015). La course aux armements du trading à haute fréquence : les enchères fréquentes par lots comme réponse de conception des marchés. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0 : front-running, réordonnancement des transactions et instabilité du consensus dans les plateformes d’échange décentralisées. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., et Clark, J. (2019). SoK : malhonnêteté transparente : attaques par front-running sur la blockchain. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., et Resnick, M. (2025). Plusieurs proposeurs simultanés : pourquoi et comment. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., et Wattenhofer, R. (2026). Solana Constellation : marchés de capitaux sur Internet. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. et Marsh, B. (2025). MEV dans les blockchains à plusieurs proposeurs simultanés. https://arxiv.org/abs/2511.13080
• Yakovenko, T., et Gokal, R. Les développeurs blockchain se concentrent sur le mauvais problème. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem