Un spectacle de mimétisme technologique : Les ambitions et la réalité de Solana

Récemment, un événement marquant s'est produit dans l'écosystème de Solana. La Fondation Solana, Anza, Jito Labs et d'autres acteurs majeurs ont conjointement publié une feuille de route technique intitulée "Internet Capital Markets ( Internet Capital Markets, ICM )". Le concept central de cette feuille de route est "Application Controlled Execution (, ACE )", visant à donner aux applications sur la chaîne un droit de tri autonome des transactions à la milliseconde, créant ainsi un "Wall Street décentralisé" sur la chaîne.

Il est intéressant de noter qu'en lisant l'ensemble de la feuille de route, bien que Hyperliquid ne soit pas mentionné directement, la conception y fait presque partout référence aux avantages de Hyperliquid. C'est comme si Solana déclarait : "Ce que Hyperliquid a, nous devons aussi l'avoir, et nous devons le faire mieux !"

Hyperliquid occupe une position dominante sur le marché des contrats perpétuels en chaîne, avec un volume de transactions atteignant environ 65 % de l'ensemble du marché des contrats perpétuels décentralisés. Face à de tels concurrents redoutables, Solana ne semble évidemment pas vouloir être dépassé par les nouveaux venus, c'est pourquoi il a lancé cette feuille de route ICM.

Alors, qu'est-ce que cette "performance d'imitation" ? Solana peut-il vraiment rattraper ou même dépasser Hyperliquid ? Explorons ce sujet en profondeur.

Contexte et contenu de l'ICM

Qui dirige cette transformation ?

Cette feuille de route a été élaborée par des acteurs majeurs de l'écosystème Solana:

• Solana Foundation/Labs : le "vrai papa" de Solana, responsable de la coordination globale et du développement du protocole principal.

• Anza : une entreprise de développement fondée par d'anciens membres de Solana Labs, similaire à ConsenSys d'Ethereum. Dans cette feuille de route, elle a pris en charge de nombreux travaux techniques clés, tels que le nouveau protocole de consensus Alpenglow.

• Jito Labs : fournisseur d'infrastructure MEV sur Solana, d'une grande influence, contrôlant presque tout le flux MEV sur Solana. Cette fois, il domine l'offre de Block Assembly Marketplace (BAM) et d'autres solutions de tri des transactions.

• Multicoin Capital : célèbre institution d'investissement en crypto, également l'un des premiers soutiens de Solana. Détient une grande quantité de SOL et des droits dans des projets écologiques, ayant une voix considérable en matière de direction technique.

• DoubleZero : une équipe axée sur l'accélération des communications réseau, proposant des solutions de réseau en fibre optique dédiées pour améliorer la vitesse de communication entre les nœuds de validation Solana.

• Drift : le projet DEX de contrats perpétuels leader sur Solana. Auparavant, il utilisait un modèle de mise en relation hors chaîne, et face à Hyperliquid entièrement sur chaîne, il semblait un peu en difficulté. Cette fois, il participe à l'élaboration de la feuille de route, espérant clairement se redresser grâce à une mise à niveau de la couche sous-jacente.

problème central à résoudre

La feuille de route se concentre sur l'amélioration de la microstructure du marché, l'essentiel étant que le mécanisme de transaction en chaîne actuel n'est pas assez amical pour les teneurs de marché. Les preneurs, qui initient activement les transactions, ont l'avantage, tandis que les teneurs de marché qui attendent que leurs ordres soient exécutés se trouvent désavantagés. Cela est dû au fait que les preneurs détiennent souvent les dernières informations et augmentent activement les frais de transaction pour garantir la priorité d'exécution, tandis que les teneurs de marché n'ont souvent pas le temps d'annuler leurs ordres, étant contraints d'exécuter à des prix défavorables.

Certains arbitragistes à haute fréquence exploitent cette asymétrie pour lancer des attaques de "flux toxiques". Par exemple, si le prix on-chain n'est pas encore mis à jour mais que le prix off-chain a déjà changé, l'arbitragiste peut prendre les ordres des teneurs de marché à l'ancien prix, faisant ainsi supporter des pertes aux teneurs de marché. Le résultat est que le Maker, pour se protéger, doit soit élargir l'écart entre le prix d'achat et le prix de vente, soit réduire le volume des ordres, ce qui entraîne une détérioration de la liquidité du marché dans son ensemble.

La feuille de route ICM vise à équilibrer ce schéma et à attirer une liquidité de haute qualité sur la chaîne.

( Les trois étapes de l'ICM

Solana a divisé ce grand plan en trois étapes:

Court terme )1-3 mois ### : Optimiser l'expérience de transaction sur la chaîne existante, rendre les applications de type carnet de commandes plus efficaces, réduire les interférences MEV malveillantes. Cela inclut spécifiquement :

• Le marché Block Assembly de Jito Labs(BAM) a lancé le module sur le réseau principal. Ce module fournit un système d'extension temporaire avant le lancement de l'ACE ultime, permettant aux contrats intelligents sur Solana d'avoir le droit de tri autonome des transactions.

• L'équipe Anza a optimisé le taux de réussite de "l'entrée des transactions dans le même Slot", réduisant ainsi le glissement et les pertes MEV.

Ces améliorations devraient être mises en œuvre progressivement entre juillet et septembre 2025.

Moyen terme (3-9 mois ): Introduction d'un réseau haut débit spécialisé et d'un nouveau consensus, réduisant considérablement la latence et augmentant le débit :

• Déployer un réseau de fibre optique dédié à DoubleZero, offrant aux validateurs une communication haute vitesse avec presque zéro jitter et une latence réduite jusqu'à 100 ms.

• Lancement du protocole de consensus Alpenglow, réduisant le temps de confirmation finale d'environ 12,8 secondes à environ 0,15 seconde.

• Développement de l'exécution de programme asynchrone ( Asynchronous Program Execution, APE ), réduction du blocage de l'exécution des transactions sur le consensus.

Long terme ( 9-30 mois ) : Réaliser une mise à niveau révolutionnaire de l'architecture principale de Solana, avec pour objectif d'atteindre cela d'ici 2027 :

• Leaders Concurrentiels Multiples, MCL( : Permettre à plusieurs validateurs de proposer des transactions simultanément dans leurs propres pipelines, puis de fusionner et de trier ces blocs parallèles en fonction des frais de priorité. Cela peut affaiblir le monopole d'un seul packer et renforcer la résistance à la censure.

• Exécution contrôlée par l'application )Application Controlled Execution, ACE( Fonctionnalité : donne réellement aux contrats intelligents sur la chaîne le pouvoir de contrôler l'ordre d'exécution des transactions.

Imitation 1 : Mécanisme de tri des transactions

) La solution ultime d'ICM : exécution contrôlée des applications (ACE)

La feuille de route ICM propose le concept d'ACE###Application Controlled Execution(, qui consiste à déléguer le droit de tri des transactions aux applications sur chaque chaîne, permettant aux applications de décider comment trier et exécuter les transactions liées à leur propre application. À l'avenir, sur Solana, qui mettra en œuvre ACE, les contrats DeFi pourront réaliser les règles de tri des transactions personnalisées suivantes :

• Mise à jour des prix Oracle : Les applications DeFi peuvent insérer une transaction pour obtenir le prix le plus récent auprès de l'oracle avant de réaliser des transactions importantes, garantissant que les ordres sont exécutés au prix raisonnable le plus récent, empêchant ainsi les teneurs de marché de voir leurs cotations basées sur des prix obsolètes être exploitées.

• Priorité à l'annulation des ordres : l'application peut définir que les "demandes d'annulation" soient exécutées avant les nouvelles "transactions d'achat", permettant au maker d'avoir la possibilité de retirer ses ordres lorsque le marché est défavorable.

• Enchères à la fin de l'équipe : par exemple, lorsqu'un gros ordre d'achat apparaît et fait monter les prix, l'application DeFi mettra aux enchères les opportunités "qui suivent", celui qui souhaite retourner le plus d'avantages au protocole ) ou à l'utilisateur (, le protocole DeFi exécutera la transaction de celui qui a fait l'offre. L'application DeFi peut retourner les revenus des enchères aux utilisateurs, transformant ainsi le flux MEV toxique en revenus bénéfiques.

) BAM de JITO : plan de transition

Avant le lancement officiel d'ACE, Jito Labs a lancé une solution de transition appelée Block Assembly Marketplace (BAM). Le flux de travail de BAM est :

1. L'utilisateur envoie la transaction à un nœud exécutant le logiciel BAM ### plutôt qu'au Leader actuel (.

2. Les nœuds BAM collectent des transactions locales et exécutent divers plugins ) plugin ( pour le réarrangement des paquets de transactions ) Bundle ( sous protection de la vie privée. Les plugins s'exécutent dans un environnement TEE sécurisé, cachant le contenu des transactions à l'extérieur avant l'exécution ). Grâce aux plugins, les développeurs d'applications peuvent personnaliser différentes règles de tri pour leurs contrats, telles que la priorité d'annulation, la mise à jour des prix des oracles avant l'appariement, voire l'exécution d'enchères complexes au sein de l'application.

3. Le Bundle de transactions trié est ensuite envoyé au Leader de Solana pour être empaqueté sur la chaîne.

BAM peut être considéré comme un terrain d'expérimentation avant la mise en chaîne d'ACE, ses fonctionnalités étant très proches de l'ACE ultime, mais il fonctionne dans un réseau indépendant hors chaîne, et non intégré au protocole principal de Solana.

Il convient de noter que Jito a précédemment fourni une infrastructure destinée à l'extraction de MEV (, comme le Jito Block Engine ), dont le modèle commercial consiste à créer des opportunités pour les arbitrageurs en optimisant le tri des transactions et à partager les revenus. Cela constitue dans une certaine mesure une "lance" opposée aux utilisateurs ordinaires et aux victimes de l'arbitrage. Cependant, Jito a fermé au début de 2024 la fonctionnalité de pool de mémoire publique ( mempool ) destinée aux robots d'arbitrage, afin de réduire les externalités négatives telles que les attaques de sandwich. Cette initiative montre que la communauté Solana tend à réprimer le MEV nuisible et à maintenir l'équité des utilisateurs.

Le lancement de BAM s'inscrit parfaitement dans cette logique : il s'agit essentiellement de transformer le mécanisme de classement initialement destiné à l'arbitrage MEV en un "bouclier" pour protéger les fournisseurs de liquidité, tels que les teneurs de marché, en évitant prioritairement les annulations forcées pour ne pas nuire aux teneurs de marché et en introduisant des remises sur les enchères pour réduire les profits des courses. Les anciens chercheurs MEV qui souhaitent gagner de l'argent doivent donc changer de rôle et développer des plugins BAM au service des protocoles DeFi, en tirant profit des frais de plugin.

( consulter HYPERLIQUID

La pensée ACE/BAM mentionnée ci-dessus peut en fait être considérée comme une tentative de rattraper le mécanisme de mise en relation sur la chaîne de Hyperliquid. Hyperliquid est une chaîne dédiée )Appchain(, conçue dès le départ pour servir les DEX. De plus, le HLP Vault géré par l'équipe officielle de Hyperliquid est en réalité l'un des plus grands teneurs de marché de la plateforme, il n'est donc pas surprenant que les règles de la chaîne de Hyperliquid soient davantage orientées vers les fournisseurs de liquidité, ayant déjà mis en œuvre de nombreuses conceptions visant à protéger les teneurs de marché au niveau de la chaîne, par exemple :

• Priorité de protection des ordres en attente : les annulations et les ordres maker sont traités en priorité, évitant ainsi que les teneurs de marché ne soient désavantagés par des transactions non informées. La "priorité d'annulation" mentionnée par Solana ACE est déjà pratiquée depuis de nombreuses années par Hyperliquid.

• Garantie des prix les plus récents : le processus de liquidation et d'appariement de Hyperliquid met l'accent sur l'utilisation des derniers prix d'oracle et de l'état des marges pour effectuer une "double vérification". Par exemple, lorsque des ordres sont appariés, le système va à nouveau récupérer le dernier prix de l'oracle pour évaluer les marges des deux parties, afin de s'assurer qu'il n'y a pas de risques dus à un retard de prix. Cela ressemble à ACE qui insère la mise à jour de l'oracle avant l'exécution des transactions.

• Protection contre les transactions auto-exécutées : si une adresse achète et vend simultanément, Hyperliquid annule automatiquement au lieu de matcher, afin d'éviter le wash trading ou des frais inutiles.

L'ACE/BAM de Solana ICM est sans aucun doute une "leçon" tirée d'Hyperliquid. En tant que leader des CLOB sur la chaîne, Hyperliquid a mis en place une multitude de mécanismes favorables aux teneurs de marché grâce à une chaîne dédiée. Solana espère maintenant reproduire cet effet avec une chaîne universelle et des plugins modulaires, permettant à chaque application de bénéficier d'un contrôle de classement des transactions similaire à celui d'Hyperliquid.

Imitation II : finalité instantanée

) Comparaison des consensus existants

Solana utilise actuellement Tower BFT, la confirmation et la finalité sont probabilistes et progressives : un bloc reçoit 2/3 des votes est considéré comme "confirmé ### Confirmed (", mais il faut accumuler environ 32 blocs suivants sur la chaîne ) généralement environ 13 secondes ### pour être ancré comme "finalisé ( Finalized )". Pour certaines applications ( comme le trading haute fréquence ), un temps de confirmation finale de plusieurs secondes est encore trop long.

HyperBFT est l'algorithme de consensus développé par Hyperliquid, inspiré par le consensus HotStuff, qui utilise un système de vote en deux tours pour confirmer les blocs, réalisant ainsi une "finalité instantanée".

• Premier tour : prévote ( Prevote ) : après que le validateur ait reçu le bloc candidat diffusé par le proposeur, il effectue une validation rapide. Si la validation est réussie, chaque validateur émettra un vote de "prévote" ( Prevote ) pour ce bloc et le diffusera sur tout le réseau. Ce vote représente : "J'ai déjà jeté un coup d'œil, ce bloc est en ordre."

• Deuxième tour : pré-engagement ( Precommit ) : Une fois qu'un validateur a collecté les prévotes de plus des deux tiers des validateurs pour le même bloc candidat, il acquiert une confiance suffisante, croyant que la majorité des membres du réseau reconnaissent ce bloc. Ainsi, ce validateur émet un vote de "pré-engagement" ( Precommit ) plus significatif et le diffuse. Ce vote représente : "J'ai vu que la majorité du réseau est d'accord, je suis prêt à inscrire officiellement ce bloc dans le registre."

• Lorsqu'un validateur a reçu le Precommit de plus des deux tiers des validateurs pour le même bloc candidat, le consensus est atteint ! Ce bloc est considéré comme finalisé (Finalized). Il sera ajouté de manière permanente et irréversible à la blockchain.

Cela signifie que chaque bloc de Hyperliquid est un bloc final, sans possibilité de bifurcation ou de retour en arrière, avec un très faible délai de génération de blocs sur l'ensemble de la chaîne ------ Les informations officielles révèlent un délai de confirmation moyen d'environ 0,2 seconde, ne dépassant pas 0,9 seconde dans 99 % des cas. Cette détermination finale au niveau des millisecondes est très idéale pour le trading à haute fréquence, car une fois qu'une transaction est émise, elle peut être rapidement confirmée et ne peut plus être restructurée, ce qui améliore considérablement l'efficacité du capital.

( ALPENGLOW réalise la finalité instantanée.

Alpenglow est un nouveau protocole de consensus que Solana s'apprête à lancer, avec pour objectif d'accélérer la confirmation finale des blocs à 1-2 slots) environ 150 ms(, réalisant une finalité instantanée similaire à HyperBFT. Dans Alpenglow, le composant qui remplace TowerBFT pour le consensus est appelé Votor, qui est un système de vote à double voie :

• Voie rapide : Si lors du premier tour de vote d'un bloc, plus ou égal à 80 % des "droits" du réseau ), qui peuvent être compris comme le poids de vote représenté par le nombre de tokens SOL mis en jeu par les validateurs ###, votent tous en faveur de la validité de ce bloc, alors ce bloc sera immédiatement confirmé comme "finalité" (Finalize ).