Critique de la feuille de route de Solana pour le "Marché des capitaux Internet" : un "spectacle d'imitation" pour rattraper Hyperliquid.

🚀 Introduction : les pros de SOLANA se réunissent

Récemment, un événement très intéressant s’est produit dans l’écosystème Solana. Des pro tels que la Fondation Solana, Anza, Jito Labs et d’autres se sont réunis pour publier 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(Application Controlled Execution, ACE)”, en d’autres termes, donner aux applications sur la chaîne le droit de tri autonome des transactions au niveau de la milliseconde, créant ainsi un “Wall Street décentralisé” sur la chaîne.

Cependant, ce qui est intéressant, c’est que en lisant l’ensemble de la feuille de route, bien que Hyperliquid ne soit pas mentionné directement, la conception à l’intérieur vise presque partout les forces de Hyperliquid. C’est comme si Solana disait : “Ce que vous avez dans Hyperliquid, nous devons aussi l’avoir, et nous devons le faire mieux !”

Il faut savoir que Hyperliquid occupe une position dominante sur le marché des contrats perpétuels en chaîne, avec un volume de transactions représentant environ 65 % de l’ensemble du marché des contrats perpétuels décentralisés. Évidemment, face à un tel concurrent, Solana ne peut pas se contenter d’être dépassé par un nouvel arrivant, c’est pourquoi elle a lancé cette feuille de route ICM.

Alors, de quoi s’agit-il exactement dans ce “spectacle d’imitation” ? Solana peut-elle vraiment rattraper voire dépasser Hyperliquid ? Aujourd’hui, nous allons approfondir ce sujet.

📋 Contexte et contenu de l’ICM

Qui dirige cette transformation ?

Tout d’abord, voyons qui a élaboré cette feuille de route. Les participants sont tous des poids lourds de l’écosystème Solana :

• Fondation/Labs Solana : Pas besoin d’en dire plus, le “vrai papa” de Solana, responsable de la coordination globale et du développement du protocole central.
• Anza : une entreprise de développement fondée par d’anciens membres de Solana Labs, un peu comme ConsenSys pour Ethereum. Ils ont pris en charge de nombreux travaux techniques essentiels dans cette feuille de route, comme le nouveau protocole de consensus Alpenglow.
• Jito Labs : Fournisseur d’infrastructure MEV sur Solana, ayant une énorme influence, contrôlant presque tous les flux MEV sur Solana avec le “pouvoir de vie et de mort”. Cette fois, ils ont dominé la fourniture du Block Assembly Marketplace (BAM) et d’autres solutions de tri des transactions.
• Multicoin Capital : célèbre institution d’investissement en cryptomonnaie et également l’un des premiers soutiens de Solana. En raison de sa détention d’un grand nombre de SOL et de droits sur des projets écologiques, elle a également une voix considérable dans les orientations techniques.
• DoubleZero : une équipe dédiée à l’accélération des communications réseau, offrant des solutions de réseau en fibre optique pour améliorer la vitesse de communication entre les nœuds de validation Solana.
• Drift : le projet DEX de contrats perpétuels de premier plan sur Solana. Auparavant, Drift adoptait un modèle de correspondance hors chaîne, et face à Hyperliquid entièrement sur chaîne, il semblait un peu en difficulté. Cette fois, en participant à l’élaboration de la feuille de route, il est évident qu’il espère se redresser grâce à une mise à niveau de la couche sous-jacente.

Le problème central à résoudre

La feuille de route se concentre sur l’amélioration de la structure micro du marché, en d’autres termes, le mécanisme actuel des transactions sur la chaîne n’est pas assez favorable aux Market Makers. En effet, les Takers qui initient activement les transactions en profitent, tandis que les Market Makers (做市商) qui placent des ordres en attente subissent des pertes. Cela est dû au fait que les Takers ont souvent accès aux informations les plus récentes et augmentent activement les frais de transaction pour garantir que leurs transactions soient exécutées en priorité, tandis que les Makers n’ont souvent pas le temps d’annuler leurs ordres et sont contraints d’exécuter à des prix défavorables.

Certains arbitragistes à haute fréquence vont exploiter cette asymétrie pour lancer des attaques de “trafic toxique”. Par exemple, si le prix sur la chaîne n’est pas encore mis à jour, mais que le prix hors chaîne a déjà changé, l’arbitragiste peut prendre les ordres des market makers à l’ancien prix, faisant ainsi subir une perte aux market makers. En conséquence, le Maker, pour se protéger, doit soit élargir l’écart entre les prix d’achat et de vente, soit réduire le volume des ordres en attente, ce qui entraîne une détérioration de la liquidité du marché.

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

La démarche en trois étapes d’ICM

Solana a divisé ce grand plan en trois phases :

Court terme (1-3 mois) : Il s’agit principalement d’optimiser l’expérience de transaction sur la chaîne existante, de rendre les applications de type carnet de commandes plus faciles à utiliser et de réduire l’interférence malveillante de MEV. Cela inclut spécifiquement :

• Le module Block Assembly Marketplace (BAM) de Jito Labs est maintenant en ligne sur le mainnet. Ce module a pour but de fournir un système externe temporaire avant le lancement du ACE ultime (Application Controlled Execution), permettant aux contrats intelligents sur Solana d’avoir leur propre contrôle sur l’ordre des transactions.
• L’équipe Anza optimise le taux de réussite de “l’entrée des transactions dans le même Slot”, réduisant ainsi le slippage 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 haute vitesse dédié et d’un nouveau consensus, réduction significative de la latence et amélioration du débit :

• Déployer un réseau de fibre optique dédié à DoubleZero, offrant aux validateurs une communication à haute vitesse avec presque aucune fluctuation et une réduction de la latence allant 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 programmes asynchrones ( Exécution de programmes asynchrones, APE ), réduisant le 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 de base de Solana, avec pour objectif de l’atteindre autour de 2027 :

• Leaders Multiples Concurrentiels, MCL( : Permet à plusieurs validateurs de proposer des transactions simultanément dans leur propre pipeline, puis de fusionner et trier ces blocs parallèles selon les frais prioritaires. Cela permet de réduire le monopole d’un seul empaqueteur et d’améliorer la résistance à la censure.
• Exécution contrôlée par l’application )Application Controlled Execution, fonctionnalité ACE( : donne vraiment le pouvoir aux contrats intelligents sur la chaîne de contrôler l’ordre d’exécution des transactions.

L’analyse jusqu’ici amène l’auteur à penser que l’histoire derrière la proposition de la feuille de route ICM devrait être la suivante : le DEX historique Drift sur Solana a été surpassé par le nouvel arrivant Hyperliquid, qui offre une excellente expérience qualifiée de “Binance on-chain”. Drift, incapable de rivaliser, a dû demander de l’aide à des “pros” comme Solana Labs, Anza et Jito. Les “pros” ont proposé un plan de transformation technique sous la forme de l’ICM, affirmant qu’ils allaient reproduire toutes les compétences clés d’Hyperliquid pour les fournir à Drift, afin de l’aider à se battre à nouveau sur le marché DEX. Cependant, les “pros” ont également déclaré que cette transformation technique serait extrêmement difficile, c’est pourquoi ils ont divisé le plan technique en trois étapes stratégiques, et que l’équipement que l’on pourrait fournir à Drift dans un avenir proche serait seulement le BAM de Jito, permettant à Drift de se débrouiller et de faire quelques comparaisons avec Hyperliquid.

Ayant clarifié le contexte de l’histoire, dans les chapitres suivants, l’auteur analysera en détail quelles compétences de prédilection ICM a réellement imitées et reproduites de Hyperliquid.

) 🎭 Imitation 1 : Mécanisme de tri des transactions

Problème : Comme mentionné précédemment, la chaîne actuelle favorise le taker, laissant le maker souffrir du “flux toxique”. Les utilisateurs qui prennent activement des ordres peuvent, en se basant sur le dernier prix hors chaîne, initier instantanément une transaction sur les ordres en attente sur la chaîne, et en augmentant les frais de transaction, obtenir une exécution prioritaire. En revanche, les teneurs de marché n’ont souvent pas le temps de mettre à jour ou d’annuler leurs ordres. Le résultat est que les teneurs de marché doivent soit élargir l’écart, soit tout simplement retirer la liquidité, ce qui dégrade la profondeur du marché.

La solution ultime d’ICM : application d’exécution contrôlée ###ACE(

La feuille de route ICM propose le concept de ACE (Application Controlled Execution), qui consiste à décentraliser le pouvoir de tri des transactions vers chaque application sur la chaîne, permettant à l’application de décider elle-même comment trier et exécuter les transactions liées à cette application. Par exemple, sur Solana, qui mettra en œuvre ACE à l’avenir, les contrats DeFi pourront appliquer des règles de tri de transactions personnalisées comme suit :

• Insertion de mise à jour des prix d’Oracle : Les applications DeFi peuvent insérer d’abord une transaction pour obtenir le dernier prix auprès de l’oracle avant de réaliser des transactions de grande taille, garantissant que les ordres sont exécutés au prix raisonnable le plus récent, empêchant ainsi les teneurs de marché de faire des offres basées sur des prix obsolètes et d’être victimes d’arbitrage.
• Exécution prioritaire des annulations : L’application peut définir que les “demandes d’annulation” ont la priorité sur l’exécution des nouvelles “transactions de prise de commande”, permettant ainsi au maker d’avoir la possibilité de retirer rapidement son ordre en cas de conditions de marché défavorables.
• Enchères à la fin de la file : Par exemple, après qu’un gros ordre d’achat ait fait grimper le prix, l’application DeFi mettra en vente l’opportunité de “suivre de près”, celui qui est prêt à retourner le plus d’avantages au protocole (ou à l’utilisateur), le protocole DeFi exécutera l’ordre de celui-ci juste après le gros ordre. Les applications DeFi peuvent renvoyer les revenus des enchères aux utilisateurs, transformant ainsi le flux MEV toxique en revenus bénéfiques.

)# BAM de JITO : Solution 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 (et non directement au Leader actuel).
2. Les nœuds BAM collectent les transactions locales et exécutent divers plugins )plugin ( pour effectuer une recommandation sous protection de la vie privée sur les paquets de transactions (Bundle) (les plugins s’exécutent dans un environnement TEE sécurisé, cachant le contenu des transactions avant l’exécution). Grâce aux plugins, les développeurs d’applications peuvent personnaliser diverses règles de tri pour leurs contrats, telles que la priorité des annulations, la mise à jour des prix des oracles avant le rapprochement, 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 champ d’expérimentation avant la mise en chaîne de l’ACE, ses fonctionnalités étant très proches de l’ACE ultime, mais il fonctionne sur un réseau indépendant hors chaîne, plutôt que d’être intégré au protocole de la chaîne principale de Solana.

Il est à noter que Jito a précédemment fourni une infrastructure axée sur l’extraction MEV (comme le Jito Block Engine), dont le modèle commercial consiste à créer des opportunités pour les arbitragistes en optimisant le tri des transactions et en partageant les bénéfices. Cela représente, dans une certaine mesure, une “lance” qui se dresse contre les utilisateurs ordinaires et ceux qui sont arbitragés. Cependant, Jito a fermé au début de 2024 la fonctionnalité de pool de mémoire publique pour les robots d’arbitrage )mempool( afin de réduire les externalités négatives telles que les attaques par sandwich. Cette initiative montre que la communauté Solana a tendance à réprimer le MEV nuisible et à maintenir l’équité pour les utilisateurs.

Le lancement de BAM s’inscrit parfaitement dans cette logique : il transforme essentiellement le mécanisme de classement utilisé à l’origine pour l’arbitrage MEV en un “bouclier” pour protéger les teneurs de marché et autres fournisseurs de liquidité, par exemple en priorisant l’annulation forcée pour éviter les pertes des teneurs de marché, ou en introduisant des incitations à la mise aux enchères pour réduire les profits des coureurs. Les chercheurs MEV d’origine, s’ils veulent gagner de l’argent, doivent changer de rôle, en développant des plugins BAM pour servir les protocoles DeFi et en tirant profit des frais de plugin.

)# apprendre de HYPERLIQUID

L’idée ci-dessus du modèle ACE/BAM peut en fait être considérée comme une sorte de rattrapage du mécanisme de mise en correspondance sur la chaîne Hyperliquid. Hyperliquid est une chaîne dédiée ###Appchain(, conçue spécialement pour servir les DEX. De plus, le HLP Vault géré par 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 Hyperliquid soient plus orientées vers les fournisseurs de liquidité, ayant déjà mis en œuvre de nombreux designs visant à protéger les teneurs de marché au niveau de la chaîne, tels que :

• Protection prioritaire des ordres en attente : Les annulations d’ordres et les ordres de type maker sont traités en priorité, afin d’éviter que les teneurs de marché ne subissent des transactions défavorables sans en être informés. Le “traitement prioritaire des annulations d’ordres” mentionné par Solana ACE est déjà pratiqué par Hyperliquid depuis de nombreuses années.
• Garantie des prix les plus récents : Le processus de liquidation et de correspondance de Hyperliquid met l’accent sur l’utilisation des derniers prix de référence et de l’état des marges pour effectuer une “double vérification”. Par exemple, lorsqu’un ordre est exécuté, le système récupère à nouveau le dernier prix du oracle pour évaluer les marges des deux parties, s’assurant ainsi qu’il n’y a pas de risque dû à un retard des prix. Cela ressemble à l’insertion par ACE de mises à jour des oracle avant l’exécution des transactions.
• Protection contre les auto-transactions : Si une adresse achète et vend en même temps, Hyperliquid annule automatiquement au lieu de faire correspondre, afin d’éviter les faux volumes ou des frais inutiles.

L’ACE/BAM de Solana ICM est sans aucun doute une source d’inspiration pour Hyperliquid. En tant que leader du CLOB sur la chaîne, Hyperliquid a mis en place de nombreux mécanismes favorables aux teneurs de marché grâce à une chaîne dédiée. Solana souhaite maintenant reproduire cet effet grâce à une chaîne universelle et des plugins modulaires - c’est-à-dire permettre à chaque application de bénéficier d’un contrôle similaire à celui d’Hyperliquid sur le classement des transactions.

) ⚡ Imiter 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 pour être considéré comme “confirmé###Confirmed(”, mais il faut accumuler environ 32 blocs ultérieurs 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), une dizaine de secondes de temps de confirmation finale est encore trop long.

HyperBFT est l’algorithme de consensus développé par Hyperliquid. Inspiré par le consensus HotStuff, il utilise une confirmation de bloc en deux tours de vote pour réaliser une « finalité instantanée ».

• Première phase : prévote ) Prevote ( : Les validateurs, après avoir reçu le bloc candidat diffusé par le Proposer, procéderont à une validation rapide. Si la validation est réussie, chaque validateur émettra un “prévote” ) Prevote ( et le diffusera à l’ensemble du réseau. Ce vote représente : “J’ai jeté un coup d’œil, ce bloc ne pose pas de problème.”
• Deuxième tour : Pré-soumission ) Precommit ( : Une fois qu’un validateurs a recueilli les votes Prevote de plus de deux tiers des validateurs pour le même bloc candidat, il acquiert suffisamment de confiance, croyant que la majorité des membres du réseau approuve ce bloc. Ainsi, ce validateur émet un vote “pré-soumission” ) Precommit ( plus pondéré 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 collecté des Precommits 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 fork ou de rollback, avec un délai de production de blocs très faible——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 finalité en millisecondes est idéale pour le trading haute fréquence, car une fois qu’une transaction est émise, elle peut être confirmée rapidement et ne peut plus être réorganisée, ce qui améliore considérablement l’efficacité du capital.

)# ALPENGLOW réalise une finalité instantanée

Alpenglow est un nouveau protocole de consensus que Solana s’apprête à lancer, visant à 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 responsable du consensus en remplacement de TowerBFT 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 de 80 % ou autant des “droits” du réseau (que l’on peut comprendre comme le poids des votes représentés par la quantité de tokens SOL que les validateurs ont mis en jeu) votent pour approuver que ce bloc est valide, alors ce bloc sera immédiatement confirmé comme ayant une “finalité” (Finalize).
• Canal lent : Si, lors du premier tour de vote, le pourcentage de droits exprimant un accord n’atteint pas 80 %, mais est supérieur ou égal à 60 %, Votor lancera le deuxième tour de vote. Si, après la fin du deuxième tour de vote, le pourcentage de droits en accord avec le bloc reste à 60 % ou plus, alors ce bloc sera également confirmé de manière définitive.

Votor équivaut à dire : “Nous confirmons qu’un tour de vote est suffisant par défaut, mais si les conditions ne sont pas parfaites, nous lançons un processus de vote en deux tours presque identique à HyperBFT comme assurance.” En fait, c’est une imitation du mécanisme de vote d’Hyperliquid.

Le coût et les contre-mesures de la finalité instantanée

Hyperliquid peut effectuer deux tours de vote, avec un prérequis important : il utilise un ensemble de validateurs très réduit, contrôlé au départ par moins de 5 entités, un réseau à échelle limitée peut considérablement réduire le coût de communication du consensus BFT.

Mais si le nombre de nœuds est élargi à des dizaines, voire des centaines, la complexité du processus de vote augmentera rapidement, car la complexité de chaque tour de vote est proportionnelle au carré du nombre de nœuds participants à la communication. Solana possède des milliers de nœuds de validation, et réaliser deux tours de vote tout en maintenant un degré élevé de décentralisation est techniquement beaucoup plus difficile que Hyperliquid. Par conséquent, Solana doit faire beaucoup de travail sur la communication réseau. Plusieurs mesures sont mentionnées dans la feuille de route :

• Alpenglow inclut également un composant Rotor, qui remplace l’ancien protocole de distribution de données Turbine. Contrairement à Turbine qui nécessite des relais multi-niveaux, Rotor adopte un mode de “relais à saut unique” permettant aux blocs de données d’atteindre plus rapidement les validateurs cibles, réduisant ainsi considérablement la latence de transmission. De plus, sous le mécanisme actuel de Turbine, la position des nœuds dans l’arbre de distribution des données est principalement déterminée par le poids du stake, les nœuds avec plus de stake étant placés à des niveaux plus élevés et recevant en priorité des fragments de données (shreds), mais cela implique également qu’ils doivent assumer davantage de tâches de relais en aval, ce qui consomme plus de bande passante. L’hypothèse derrière ce design est que les nœuds avec beaucoup de stake sont souvent des “pro”, et qu’ils possèdent probablement un matériel plus puissant et des ressources de bande passante plus abondantes. Rotor a mis à jour cette logique, ne se fiant plus uniquement à la taille du stake, mais prenant en compte la bande passante réelle et les performances de communication de chaque nœud. Ceux qui se distinguent par de meilleures performances dans le réseau en temps réel seront dynamiquement placés à des emplacements clés, permettant ainsi à l’ensemble du réseau de planifier intelligemment le chemin de propagation des données optimal, réalisant un service de “livraison” à la fois rapide et stable.
• DoubleZero réseau haute vitesse basé sur un réseau de fibres optiques dédié + technologie de multicast, offre une communication à faible latence qui est un ordre de grandeur plus rapide que celle de l’internet public. Cela réduit la latence et le jitter des messages entre les nœuds géographiquement dispersés, rendant ainsi la base physique du consensus rapide plus solide.

Même dans ce cas, il est extrêmement difficile pour Solana de réaliser à la fois “une grande décentralisation + une finalité en millisecondes”. C’est pourquoi Alpenglow s’attend à avoir besoin de plus d’un an de développement, et prévoit un lancement au début de 2026 (espérons-le).

🔄 Imiter trois : exécution asynchrone de la chaîne de traitement

Pipeline asynchrone de HYPERLIQUID

Les blockchains traditionnelles sont mono-threadées, un bloc doit être entièrement exécuté et vérifié avant que le bloc suivant puisse commencer à être traité. L’objectif de cette approche est d’éliminer l’incertitude introduite par le multi-threading, garantissant que tous les nœuds obtiennent les mêmes résultats dans un ordre exactement identique. Cependant, l’inconvénient est que cela limite la performance des CPU modernes multi-cœurs.

Hyperliquid adopte une approche non conventionnelle en introduisant le multi-threading, décomposant le flux de travail en deux pipelines parallèles : “tri (consensus)” et “exécution”. Le processus d’exécution est le suivant :

1. Point temporel T1 :

   • Pipeline de consensus : Les validateurs s’accordent sur le contenu et l’ordre des transactions du bloc N-1.

2. Point temporel T2 (l’endroit où la magie commence) :

   • Pipeline de consensus: Commence à traiter le bloc N. Il regroupe et trie les transactions dans le réseau, puis vote et parvient à un consensus sur cet ordre. Il ne se soucie absolument pas du résultat d’exécution du bloc N-1.
   • Exécution de la chaîne de blocs: Obtenir le bloc N-1 pour lequel un consensus a déjà été atteint au moment T1, commencer à exécuter les transactions qu’il contient.

3. Point temporel T3 (fonctionnement continu de la chaîne de montage) :

   • Pipeline de consensus : A terminé le consensus sur le bloc N et a transmis le résultat du consensus (une liste de transactions triées) à la pipeline d’exécution. Ensuite, il a immédiatement commencé à traiter le bloc N+1.
   • Exécuter le pipeline : A terminé l’exécution du bloc N-1 et a finalement confirmé l’état. Ensuite, il se connecte sans couture, récupère immédiatement le bloc N qui vient d’être complété par le pipeline de consensus et commence à exécuter ses transactions.

Dans ce mode Pipeline, différents cœurs du CPU peuvent être efficacement utilisés. Certains cœurs peuvent être spécifiquement dédiés au traitement des messages réseau et aux votes de consensus (tri), tandis que d’autres cœurs peuvent se concentrer pleinement sur le calcul d’état (exécution), les deux pipelines fonctionnant en même temps, maximisant ainsi l’efficacité matérielle.

Le plan APE d’ICM

exécution

Cependant, réaliser une exécution sécurisée et parallèle/asynchrone sur une chaîne décentralisée représente déjà un défi technique de grande envergure : Pour que tous les nœuds du monde parviennent à un accord complet sur le résultat des transactions, il est impératif d’éliminer tout facteur pouvant entraîner des résultats différents en raison d’un ordre d’exécution différent.

La raison pour laquelle le schéma de pipeline asynchrone a réussi sur Hyperliquid est que Hyperliquid, en tant que chaîne d’application fonctionnelle unique, a un modèle d’état simple et clair (principalement le livre des ordres des différents marchés de trading et les positions des utilisateurs). L’équipe de développement peut clairement définir quelles opérations peuvent être effectuées en parallèle et lesquelles ont des dépendances, et concevoir ainsi un pipeline efficace.

Cependant, Solana, en tant que chaîne polyvalente, a des dépendances dans les transactions qui sont beaucoup plus complexes qu’un système de carnet de commandes. Par conséquent, pour que Solana reproduise les performances d’Hyperliquid dans un environnement général, les défis d’ingénierie sont bien plus difficiles, nécessitant le développement de nombreux codes, ce qui ne pourra pas être réalisé à court terme. Ainsi, dans la feuille de route ICM, cela ne peut être classé que comme une planification à moyen terme. Néanmoins, le véritable lancement d’APE nécessitera de surmonter une série de problèmes :

• Complexité extrême du code : Faire en sorte que les systèmes distribués prennent en charge l’exécution asynchrone et parallèle nécessite d’importantes modifications au niveau inférieur. Une fois que le parallélisme multithread est introduit, la complexité logicielle du client de nœud de validation Solana augmentera de manière exponentielle, et le risque de bugs inconnus augmentera également. Une condition de concurrence mal gérée peut entraîner des erreurs de consensus, dont les conséquences peuvent être catastrophiques.
• Exigences matérielles accrues : L’exécution parallèle nécessite un processeur multicœur puissant et plus de mémoire pour exécuter plusieurs threads d’exécution simultanément, maintenir plusieurs états temporaires et points de restauration. Les nœuds Solana ont déjà un seuil d’entrée élevé, et si cela augmente encore, cela affectera la décentralisation du réseau.
• Gestion des pires scénarios : Le pire des cas pour l’exécution en parallèle est qu’un grand nombre de transactions se disputent le même état. Par exemple, si certaines contrats populaires (comme des DEX populaires ou des contrats de précommande) amènent toutes les transactions à lire et écrire le même compte, alors le planificateur parallèle continuera à détecter des conflits, à revenir en arrière et à rejouer, ce qui pourrait être plus lent que l’exécution en série. Comment dégrader gracieusement dans les pires cas, sans laisser le système sombrer dans un état de blocage ou une chute de performance, est un défi de conception architecturale.
• Difficulté de développement et d’audit : La vérification de la sécurité dans un environnement asynchrone et multithread est très difficile. La communauté Solana doit investir des ressources supplémentaires pour auditer le nouveau modèle d’exécution afin de prévenir l’exploitation malveillante des vulnérabilités de consensus dues à la parallélisation.

🤔 Ce spectacle d’imitation pourra-t-il réussir ?

En résumé, la feuille de route de Solana ICM est en réalité une profonde “imitation” de l’architecture technique de Hyperliquid. L’équipe centrale de Solana prévoit de reproduire toutes les compétences phares de Hyperliquid et de les fournir à Drift, afin de l’aider à rivaliser à nouveau sur le marché des DEX avec Hyperliquid. Cependant, je ne suis pas optimiste quant aux perspectives de cette imitation.

Augmentation exponentielle de la difficulté technique

Le succès d’Hyperliquid repose en grande partie sur ses conditions intrinsèques favorables :

• En tant que chaîne dédiée, elle peut optimiser le consensus et l’exécution autour d’une seule application, sans avoir à prendre en compte les divers besoins des contrats intelligents.
• En tant que chaîne émergente, elle peut même sacrifier un certain degré de décentralisation pour obtenir des performances (les validateurs initiaux sont contrôlés par l’équipe, et la plupart des utilisateurs acceptent tacitement cela).

En revanche, pour Solana, atteindre le niveau de Hyperliquid tout en maintenant l’universalité d’une blockchain publique et un degré de décentralisation, la difficulté technique augmente de manière exponentielle. Par exemple, le consensus HyperBFT de Hyperliquid peut atteindre une latence de 0,2 seconde avec moins de 5 nœuds, tandis que Solana doit dépasser les limites de communication du réseau pour que 2000 nœuds atteignent la même latence ; le moteur de correspondance de Hyperliquid ne sert que la logique de sa propre bourse, tandis que l’ACE/BAM de Solana doit s’adapter à une multitude de protocoles DeFi.

On peut dire que Solana comble les lacunes de Hyperliquid, et la difficulté des cours est bien plus élevée que celle que Hyperliquid a initialement rencontrée, “je ne sais pas jusqu’où cela a monté”. La feuille de route ICM décompose ces tâches jusqu’en 2027, ce qui montre que l’équipe officielle est consciente que ce n’est pas un travail de courte durée.

La contradiction entre décentralisation et efficacité

Une autre différence entre Solana et Hyperliquid réside dans le rythme de la gouvernance et des mises à niveau. L’équipe de Hyperliquid est petite, la prise de décision est centralisée et il n’y a pas de contrepoids externe, ce qui permet d’agir très rapidement. En mars de cette année, lorsque Hyperliquid a rencontré l’incident de manipulation du contrat JELLY, l’équipe a réagi immédiatement en retirant les marchés concernés en quelques heures, protégeant ainsi la sécurité des fonds. Cela démontre pleinement que, bien que la prise de décision centralisée soit “politiquement incorrecte”, elle peut être efficace et utile en temps de crise.

En tant que chaîne publique, Solana a une fondation, un développement central et une communauté qui interagissent de manière complexe, rendant le processus de mise à niveau relativement lent et conservateur. Par exemple, le très attendu Firedancer (le client haute performance de Solana développé par Jump) est en phase de test depuis son lancement en 2022 et ne sera pas complètement opérationnel avant la mi-2025 ; tout changement impliquant le consensus nécessite un audit prolongé et un fonctionnement sur le réseau de test. Les modifications prévues dans la feuille de route d’ICM sont encore plus importantes : il s’agit de remplacer l’algorithme de consensus central, d’introduire une exécution parallèle complètement nouvelle et de décentraliser le pouvoir clé, la difficulté et le risque n’étant que plus élevés. On peut s’attendre à ce que, dans les deux à trois prochaines années, l’équipe de Solana doive faire avancer progressivement ces mises à niveau, chaque étape pouvant rencontrer des défis techniques inattendus ou des résistances de la communauté.

Par exemple, pour que BAM lancé par Jito bénéficie réellement aux utilisateurs, la plupart des validateurs doivent passer à un client prenant en charge BAM. Sinon, les transactions des utilisateurs passeront parfois par BAM et parfois non, ce qui entraînera une expérience incohérente et même des failles d’arbitrage. Le problème est que Solana ne peut pas forcer les nœuds de validation à mettre à jour leurs clients. Par conséquent, même si BAM est développé avec succès, sa vitesse de promotion est difficile à prévoir. Ainsi, le calendrier dans l’ICM n’est qu’une planification optimiste, et sa réalisation pourrait être retardée encore et encore, et il n’est pas certain que tous les objectifs soient atteints avant longtemps.

Même si tout se passe bien, même si Solana réalise des choses comme ACE d’ici 2027, ce ne sera qu’un “rattrapage réussi” - rattraper les fonctionnalités déjà offertes par Hyperliquid en 2023-2024. Et Hyperliquid lui-même ne s’arrêtera pas : par exemple, la proposition HIP-3 sera lancée au second semestre de 2025, permettant à la communauté de proposer elle-même un marché de contrats perpétuels. Ces diverses innovations élargiront encore la couverture du marché d’Hyperliquid. Lorsque Solana aura enfin réalisé les fonctionnalités actuelles d’Hyperliquid, peut-être qu’Hyperliquid aura déjà ouvert de nouveaux avantages de leader.

Dépasser la compétition technologique

Bien que cet article se concentre sur la confrontation technique entre Solana et Hyperliquid, nous devons également reconnaître que le succès d’Hyperliquid ne repose pas uniquement sur un facteur technique. Hyperliquid présente de nombreux atouts en termes d’exploitation et d’écosystème :

• Par exemple, dans l’économie des tokens, Hyperliquid n’a pas de financement par des VC, plus de 76 % des tokens sont répartis entre la communauté. Les bénéfices des frais perçus par la plateforme peuvent être utilisés pour racheter des tokens HYPE, assurant ainsi un véritable partage des intérêts avec les utilisateurs, sans le problème d’exploitation excessive des utilisateurs par les capitalistes. Cela a valu à Hyperliquid la réputation de gagner de nombreux utilisateurs fidèles.
• De plus, l’équipe de Hyperliquid est extrêmement réceptive aux besoins du marché : lorsque les NFT sont populaires, ils lancent l’indice NFT ; lorsque SocialFi est en vogue, ils introduisent l’indice FriendTech ; le HIP-2 résout le problème de “démarrage difficile des nouveaux tokens et du manque de liquidité initiale” ; Hyperps traite le défi de fournir des contrats à terme pour les actifs qui ne sont pas encore officiellement lancés ; la mise à niveau HIP-3 prévue pour cette année permettra à n’importe quel projet d’émettre son propre marché de contrats perpétuels. L’innovation produit est constante, et ces catégories de trading variées et ces nouvelles façons de jouer renforcent considérablement l’attrait de Hyperliquid en tant que plateforme de trading — les utilisateurs viennent ici non seulement pour la rapidité, mais aussi pour des opportunités de gains qu’ils ne trouvent nulle part ailleurs.

En revanche, sur la scène des DEX de Solana, des DEX natifs comme Drift n’ont en réalité pas d’avantages significatifs en termes de conception de produits et de mécanismes d’incitation. Se contenter de reproduire avec succès la technologie de Hyperliquid et d’atteindre les performances de la chaîne ne suffira pas ; sans des fonctionnalités distinctives qui résolvent les problèmes des utilisateurs, cela ne conduira pas automatiquement à un retour massif des utilisateurs, après tout, la migration des utilisateurs a aussi un coût.

Ainsi, si l’on se contente de suivre docilement le chemin de Hyperliquid, on ne fera que rester derrière à manger de la poussière. La véritable opportunité de la feuille de route ICM de Solana ne réside pas dans le domaine des contrats perpétuels ou des carnets de commandes. Il reste encore de nombreux domaines dans l’écosystème Solana que Hyperliquid n’a pas encore explorés, tels que les plateformes de lancement de MEME, les protocoles de prêt, etc., qui peuvent également tirer parti des améliorations apportées par l’ICM pour offrir une expérience utilisateur plus fluide. Si Solana peut innover des fonctionnalités dans ces domaines et résoudre les points de douleur des utilisateurs, alors même si elle ne parvient pas immédiatement à regagner du terrain sur le marché des contrats perpétuels, elle pourra néanmoins renforcer la réalisation de sa vision de “marché de capitaux Internet”. Après tout, peu importe la puissance de Hyperliquid, ce n’est qu’une chaîne d’application dans un domaine vertical, tandis que Solana possède une vaste et diverse carte des applications, ce qui constitue son plus grand atout à long terme.

🏁 Conclusion : Il est facile d’imiter, mais difficile de surpasser.

La feuille de route ICM de Solana met en avant la détermination de la communauté Solana à ne pas se laisser distancer et à rattraper son retard. De ACE à Alpenglow, puis à APE, chacun correspond aux fonctionnalités distinctives de Hyperliquid, ce qui implique effectivement une sorte de “mimétisme ciblé”.

Cependant, imiter est facile, surpasser est difficile. Pour que Solana réussisse à interpréter ce spectacle d’imitation, elle doit déployer des efforts dans les domaines de la technologie, de la coopération écologique et de la stratégie de marché. À court terme, Solana pourra peut-être améliorer l’expérience de trading en chaîne grâce à BAM et récupérer une partie de ses utilisateurs. Mais pour vraiment ébranler la position de leader de Hyperliquid, cela pourrait nécessiter plus de temps et d’innovations.

Au moins pour l’instant, Hyperliquid continue d’étendre son territoire grâce à son avantage en part de marché, tandis que Solana est en train d’accélérer le processus de transformation de son moteur, et il est à craindre que ce processus de transformation prenne encore du temps.

La feuille de route d’ICM dessine un avenir prometteur, mais la possibilité de réaliser un “dépassement dans un virage” reste à prouver avec le temps. En tant qu’utilisateurs ordinaires, nous pouvons espérer que cette compétition apporte une meilleure expérience d’échange sur la chaîne - peu importe qui l’emporte au final, les utilisateurs en seront les bénéficiaires.

Cet article est basé sur des informations publiques et ne constitue pas un conseil en investissement. L’investissement en cryptomonnaies comporte des risques importants, veuillez prendre des décisions prudentes, DYOR.

Si vous aimez cet article, n’hésitez pas à suivre, aimer et partager pour soutenir !