Feuille de route ICM de Solana : un "show d'imitation" pour Hyperliquid
Introduction : Les grands du Solana se réunissent
Récemment, un événement intéressant s'est produit dans l'écosystème Solana. Des membres importants tels que la Fondation Solana, Anza et un certain laboratoire renommé se sont réunis pour publier une feuille de route technique intitulée "Internet Capital Markets, ICM(". L'idée centrale de cette feuille de route est "Application Controlled Execution, ACE)", en d'autres termes, permettre aux applications sur la chaîne de disposer d'un droit de tri des transactions autonome en millisecondes, créant ainsi un "Wall Street décentralisé".
Il est intéressant de noter qu'en lisant l'intégralité de la feuille de route, bien qu'Hyperliquid ne soit pas mentionné directement, la conception à l'intérieur vise presque partout les points forts d'Hyperliquid. C'est comme si Solana disait : "Ce que Hyperliquid a, 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 à terme perpétuels en chaîne, avec un volume de transactions atteignant environ 65 % de l'ensemble du marché des contrats à terme décentralisés. Évidemment, face à un tel concurrent, Solana ne souhaite pas être dépassé par un nouvel entrant, c'est pourquoi il a lancé cette feuille de route ICM.
Alors, que se passe-t-il vraiment avec ce "spectacle d'imitation" ? Solana peut-elle vraiment rattraper voire dépasser Hyperliquid ? Aujourd'hui, nous allons discuter en profondeur de ce sujet.
Contexte et contenu de l'ICM
( Qui dirige cette transformation ?
Tout d'abord, examinons qui a élaboré cette feuille de route. Les participants sont tous des acteurs majeurs de l'écosystème Solana :
Solana Foundation/Labs : pas besoin d'en dire plus, le "papa" de Solana, responsable de la coordination globale et du développement du protocole central.
Anza : une société de développement fondée par d'anciens membres de Solana Labs, un peu comme ConsenSys d'Ethereum. Ils ont pris en charge de nombreux travaux fondamentaux sur la technologie dans cette feuille de route, comme le nouveau protocole de consensus Alpenglow.
Un laboratoire bien connu : un fournisseur d'infrastructure MEV sur Solana, ayant une grande influence, contrôlant presque tout le flux MEV sur Solana et détenant le "pouvoir de vie et de mort". Cette fois, ils ont dirigé la fourniture de solutions de tri de transactions telles que Block Assembly Marketplace )BAM###.
Un capital bien connu : une célèbre institution d'investissement en cryptomonnaie, également l'un des premiers supporters de Solana. En raison de sa détention d'un grand nombre de SOL et de droits dans des projets écologiques, elle a également un poids considérable en matière de direction technique.
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 de Solana.
Une plateforme de contrats à terme perpétuels : un projet DEX de contrats à terme perpétuels de premier plan sur Solana. Auparavant, cette plateforme utilisait un modèle de correspondance hors chaîne, et face à Hyperliquid entièrement sur chaîne, elle semblait un peu en difficulté. Cette fois-ci, en participant à l'élaboration de la feuille de route, il est clair qu'elle 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 microstructure du marché, en d'autres termes, le mécanisme de transaction en chaîne actuel n'est pas assez favorable aux Market Makers, c'est-à-dire que les Takers, qui initient activement les transactions, en profitent, tandis que les Market Makers perdent. Cela est dû au fait que les Takers ont souvent accès aux dernières informations 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 profitent de cette asymétrie pour lancer une attaque de "flux toxiques". 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 des ordres des teneurs de marché à l'ancien prix, faisant ainsi subir des pertes aux teneurs de marché. En conséquence, le Maker doit se protéger en élargissant l'écart entre les prix d'achat et de vente ou en réduisant le volume des ordres, ce qui dégrade la liquidité globale du marché.
La feuille de route ICM vise à équilibrer ce schéma et à attirer une liquidité de haute qualité sur la chaîne.
) La stratégie en trois étapes d'ICM
Solana a divisé ce grand projet en trois phases :
Court terme (1-3 mois) : principalement optimiser l'expérience de trading en chaîne existante, améliorer l'utilité des applications de type carnet de commandes et réduire les interférences MEV malveillantes. Cela inclut spécifiquement :
Le module Block Assembly Marketplace (BAM) d'un laboratoire renommé est désormais en ligne sur le réseau principal. Ce module a pour but de fournir un système externe temporaire avant le lancement de l'ACE (Application Controlled Execution) ultime, permettant aux contrats intelligents sur Solana d'avoir leur propre pouvoir de tri des transactions.
L'équipe Anza optimise le taux de succès de "l'entrée 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 augmentation du débit :
Déployer un réseau de fibre optique dédié à DoubleZero, offrant aux validateurs une communication à haute vitesse avec presque aucune jitter et une réduction de latence allant jusqu'à 100ms.
Lancement du protocole de consensus Alpenglow, réduisant le temps de confirmation final d'environ 12,8 secondes à environ 0,15 seconde.
Développer l'exécution de programmes asynchrones ### Exécution de programmes asynchrones, APE ###, réduire le blocage de l'exécution des transactions sur le consensus.
À long terme (9-30 mois) : mise à niveau révolutionnaire de l'architecture de base de Solana, avec pour objectif de réaliser cela d'ici 2027.
Leaders Concurrentiels Multiples, MCL( : Permet à plusieurs validateurs de proposer des transactions simultanément dans leurs propres pipelines, puis de trier ces blocs parallèles en fonction des frais prioritaires. Cela permet d'affaiblir le monopole d'un seul emballeur et d'améliorer la résistance à la censure.
Applications natives à exécution contrôlée )Exécution contrôlée par l'application, ACE( Fonction : donne réellement aux contrats intelligents sur la chaîne le pouvoir de contrôler l'ordre d'exécution des transactions.
L'analyse en arrive ici, l'auteur pense que l'histoire derrière la proposition de la feuille de route ICM devrait être la suivante : les DEX établis sur Solana ont été dépassés par le nouvel arrivant Hyperliquid grâce à l'excellente expérience d'un "plateforme d'échange sur chaîne". Les DEX établis, incapables de rivaliser, n'ont d'autre choix que de solliciter l'aide de "grands noms" comme Solana Labs et Anza. Les "grands noms" ont proposé un plan de transformation technique ICM, affirmant qu'ils allaient reproduire les compétences clés d'Hyperliquid pour les DEX établis, afin de leur permettre de revenir sur le marché des DEX. Cependant, les "grands noms" ont également déclaré que cette transformation technique était extrêmement difficile, c'est pourquoi ils ont divisé le plan technique en une stratégie en trois étapes, et l'équipement que l'on peut fournir aux DEX établis dans un avenir proche n'est que le BAM d'un célèbre laboratoire, laissant les DEX établis s'en débrouiller et comparer avec Hyperliquid.
Après avoir clarifié le contexte de l'histoire, dans les chapitres suivants, l'auteur analysera en détail quelles compétences clés ICM a réellement imitées et reproduites de Hyperliquid.
Imiter un : Mécanisme de tri des transactions
Problème : Comme mentionné précédemment, la chaîne actuelle favorise les takers, laissant les makers souffrir du "flux toxique". Les utilisateurs qui passent des ordres actifs peuvent, en fonction des derniers prix hors chaîne, initier instantanément des transactions sur les ordres placés sur la chaîne, en augmentant les frais de transaction pour être prioritaires, tandis que les market makers n'ont souvent pas le temps de mettre à jour ou de retirer leurs ordres. Le résultat est que les market makers doivent soit élargir l'écart, soit retirer complètement la liquidité, ce qui dégrade la profondeur du marché.
) La solution ultime d'ICM : application d'exécution contrôlable (ACE)
La feuille de route ICM propose le concept d'ACE (Application Controlled Execution), qui décentralise le droit de tri des transactions aux différentes applications sur la chaîne, permettant à chaque application de décider comment trier et exécuter les transactions liées à elle. Par exemple, sur Solana, qui mettra en œuvre l'ACE dans le futur, 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 dernier prix auprès de l'oracle avant de réaliser des transactions de grande envergure, garantissant que les ordres sont exécutés au dernier prix raisonnable, afin d'éviter que les cotations des teneurs de marché ne soient basées sur des prix obsolètes et ne soient sujettes à l'arbitrage.
Priorité d'exécution des annulations de commande : l'application peut définir que les "demandes d'annulation" sont prioritaires par rapport aux nouvelles "transactions de prise de commande", permettant ainsi au maker de retirer rapidement un ordre en cas de conditions de marché défavorables.
Enchères à la fin de la file : par exemple, après qu'un ordre d'achat énorme ait fait monter le prix, l'application DeFi mettra en vente l'opportunité "suivante", et celui qui est prêt à restituer le plus d'avantages au protocole (ou aux utilisateurs) verra son ordre exécuté juste après le gros ordre. Les applications DeFi peuvent restituer les bénéfices des enchères aux utilisateurs, transformant ainsi le flux MEV toxique en revenus bénéfiques.
BAM d'un laboratoire renommé : plan de transition
Avant le lancement officiel d'ACE, un laboratoire renommé a lancé une solution de transition appelée Block Assembly Marketplace (BAM). Le flux de travail de BAM est :
L'utilisateur envoie la transaction à un nœud exécutant le logiciel BAM (plutôt qu'au Leader actuel).
Les nœuds BAM collectent les transactions locales et exécutent divers plugins ###plugin( pour réorganiser les paquets de transactions (Bundle) sous protection de la vie privée (les plugins fonctionnent dans un environnement TEE sécurisé et cachent 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é aux annulations, la mise à jour des prix des oracles avant l'appariement, voire l'exécution de mises aux enchères complexes au sein de l'application.
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 que l'ACE ne soit mis en chaîne, ses fonctionnalités étant très proches de l'ACE ultime, mais il fonctionne dans un réseau indépendant hors chaîne, plutôt que d'être intégré au protocole principal de Solana.
Il est à noter qu'un laboratoire bien connu fournissait auparavant une infrastructure axée sur l'extraction MEV (comme un certain moteur de bloc), dont le modèle commercial consiste à créer des opportunités pour les arbitragistes en optimisant l'ordre des transactions et en partageant les bénéfices. Cela représente, dans une certaine mesure, une "lance" opposée aux utilisateurs ordinaires et aux victimes d'arbitrage. Cependant, ce laboratoire a fermé début 2024 la fonction 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 mesure indique que la communauté Solana a tendance à réprimer les MEV nuisibles et à protéger l'équité des utilisateurs.
Le lancement de BAM s'inscrit parfaitement dans cette logique : il transforme essentiellement le mécanisme de classement initialement utilisé pour l'arbitrage MEV en un "bouclier" pour protéger les fournisseurs de liquidité tels que les teneurs de marché, par exemple en priorisant les annulations forcées pour éviter que les teneurs de marché ne subissent des pertes, et en introduisant des remises sur les enchères pour réduire les profits des arbitrages. Les chercheurs MEV d'origine qui souhaitent gagner de l'argent doivent désormais changer de rôle, en développant des plugins BAM pour servir les protocoles DeFi et en tirant des bénéfices des frais de plugin.
) demander conseil à Hyperliquid
La pensée ACE/BAM ci-dessus peut en fait être considérée comme une tentative de rattraper le mécanisme de correspondance en ligne 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 Hyperliquid, est en réalité l'un des plus grands teneurs de marché de cette plateforme, il n'est donc pas surprenant que les règles de la chaîne Hyperliquid soient davantage axées sur 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, telles que :
Protection prioritaire des ordres en attente : les annulations et les ordres de maker sont traités en priorité, évitant ainsi que les teneurs de marché subissent des exécutions défavorables à leur insu. La "priorité d'exécution des annulations" mentionnée par Solana ACE est déjà pratiquée par Hyperliquid depuis de nombreuses années.
Garantie de prix la plus récente : Le processus de règlement et d'appariement de Hyperliquid met l'accent sur l'utilisation des derniers prix des oracles et de l'état des marges pour effectuer un "double contrôle". Par exemple, lorsque des ordres sont appariés, le système récupère à nouveau le dernier prix de l'oracle pour évaluer les marges des deux parties, afin de s'assurer qu'il n'y a pas de risque dû à un retard de prix. Cela ressemble à la façon dont ACE insère une mise à jour de l'oracle avant l'exécution des transactions.
Protection contre les transactions automatiques : si une même adresse achète et vend en même temps, Hyperliquid annule automatiquement plutôt que d'exécuter, afin d'éviter le gonflage des volumes ou des frais inutiles.
Solana ICM de l'ACE/BAM, sans aucun doute, s'inspire de Hyperliquid. En tant que leader des CLOB sur la chaîne, Hyperliquid a mis en place diverses mécanismes favorables aux teneurs de marché grâce à une chaîne dédiée. Solana espère maintenant utiliser une chaîne universelle avec des plugins modulaires pour reproduire cet effet ------ c'est-à-dire donner à chaque application un contrôle similaire à celui de Hyperliquid sur le classement des transactions.
Imiter deux : 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 et est considéré comme "confirmé(Confirmed)", mais environ 32 blocs suivants doivent être accumulés sur la chaîne (généralement environ 13 secondes) pour être ancrés comme "finalisé###Finalized(". Pour certaines applications (comme le trading haute fréquence), une durée de confirmation finale de quelques secondes est encore trop longue.
HyperBFT est l'algorithme de consensus développé par Hyperliquid, inspiré par le consensus HotStuff, qui utilise deux tours de vote pour confirmer les blocs et réaliser une "finalité instantanée".
Premier tour : prévote ) Prevote ( : après que le validateurs aient reçu le bloc candidat diffusé par le proposeur, ils procéderont à une vérification rapide. Si la vérification est réussie, chaque validateur votera pour ce bloc avec un "vote préliminaire" ) Prevote ( et le diffusera à l'ensemble du réseau. Ce vote représente : "J'ai examiné brièvement
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
5
Reposter
Partager
Commentaire
0/400
TheMemefather
· Il y a 3h
Il vaut mieux innover de manière autonome que de copier.
Solana ICM feuille de route vs Hyperliquid : bataille des transactions off-chain
Feuille de route ICM de Solana : un "show d'imitation" pour Hyperliquid
Introduction : Les grands du Solana se réunissent
Récemment, un événement intéressant s'est produit dans l'écosystème Solana. Des membres importants tels que la Fondation Solana, Anza et un certain laboratoire renommé se sont réunis pour publier une feuille de route technique intitulée "Internet Capital Markets, ICM(". L'idée centrale de cette feuille de route est "Application Controlled Execution, ACE)", en d'autres termes, permettre aux applications sur la chaîne de disposer d'un droit de tri des transactions autonome en millisecondes, créant ainsi un "Wall Street décentralisé".
Il est intéressant de noter qu'en lisant l'intégralité de la feuille de route, bien qu'Hyperliquid ne soit pas mentionné directement, la conception à l'intérieur vise presque partout les points forts d'Hyperliquid. C'est comme si Solana disait : "Ce que Hyperliquid a, 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 à terme perpétuels en chaîne, avec un volume de transactions atteignant environ 65 % de l'ensemble du marché des contrats à terme décentralisés. Évidemment, face à un tel concurrent, Solana ne souhaite pas être dépassé par un nouvel entrant, c'est pourquoi il a lancé cette feuille de route ICM.
Alors, que se passe-t-il vraiment avec ce "spectacle d'imitation" ? Solana peut-elle vraiment rattraper voire dépasser Hyperliquid ? Aujourd'hui, nous allons discuter en profondeur de ce sujet.
Contexte et contenu de l'ICM
( Qui dirige cette transformation ?
Tout d'abord, examinons qui a élaboré cette feuille de route. Les participants sont tous des acteurs majeurs de l'écosystème Solana :
Solana Foundation/Labs : pas besoin d'en dire plus, le "papa" de Solana, responsable de la coordination globale et du développement du protocole central.
Anza : une société de développement fondée par d'anciens membres de Solana Labs, un peu comme ConsenSys d'Ethereum. Ils ont pris en charge de nombreux travaux fondamentaux sur la technologie dans cette feuille de route, comme le nouveau protocole de consensus Alpenglow.
Un laboratoire bien connu : un fournisseur d'infrastructure MEV sur Solana, ayant une grande influence, contrôlant presque tout le flux MEV sur Solana et détenant le "pouvoir de vie et de mort". Cette fois, ils ont dirigé la fourniture de solutions de tri de transactions telles que Block Assembly Marketplace )BAM###.
Un capital bien connu : une célèbre institution d'investissement en cryptomonnaie, également l'un des premiers supporters de Solana. En raison de sa détention d'un grand nombre de SOL et de droits dans des projets écologiques, elle a également un poids considérable en matière de direction technique.
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 de Solana.
Une plateforme de contrats à terme perpétuels : un projet DEX de contrats à terme perpétuels de premier plan sur Solana. Auparavant, cette plateforme utilisait un modèle de correspondance hors chaîne, et face à Hyperliquid entièrement sur chaîne, elle semblait un peu en difficulté. Cette fois-ci, en participant à l'élaboration de la feuille de route, il est clair qu'elle 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 microstructure du marché, en d'autres termes, le mécanisme de transaction en chaîne actuel n'est pas assez favorable aux Market Makers, c'est-à-dire que les Takers, qui initient activement les transactions, en profitent, tandis que les Market Makers perdent. Cela est dû au fait que les Takers ont souvent accès aux dernières informations 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 profitent de cette asymétrie pour lancer une attaque de "flux toxiques". 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 des ordres des teneurs de marché à l'ancien prix, faisant ainsi subir des pertes aux teneurs de marché. En conséquence, le Maker doit se protéger en élargissant l'écart entre les prix d'achat et de vente ou en réduisant le volume des ordres, ce qui dégrade la liquidité globale du marché.
La feuille de route ICM vise à équilibrer ce schéma et à attirer une liquidité de haute qualité sur la chaîne.
) La stratégie en trois étapes d'ICM
Solana a divisé ce grand projet en trois phases :
Court terme (1-3 mois) : principalement optimiser l'expérience de trading en chaîne existante, améliorer l'utilité des applications de type carnet de commandes et réduire les interférences MEV malveillantes. Cela inclut spécifiquement :
Le module Block Assembly Marketplace (BAM) d'un laboratoire renommé est désormais en ligne sur le réseau principal. Ce module a pour but de fournir un système externe temporaire avant le lancement de l'ACE (Application Controlled Execution) ultime, permettant aux contrats intelligents sur Solana d'avoir leur propre pouvoir de tri des transactions.
L'équipe Anza optimise le taux de succès de "l'entrée 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 augmentation du débit :
Déployer un réseau de fibre optique dédié à DoubleZero, offrant aux validateurs une communication à haute vitesse avec presque aucune jitter et une réduction de latence allant jusqu'à 100ms.
Lancement du protocole de consensus Alpenglow, réduisant le temps de confirmation final d'environ 12,8 secondes à environ 0,15 seconde.
Développer l'exécution de programmes asynchrones ### Exécution de programmes asynchrones, APE ###, réduire le blocage de l'exécution des transactions sur le consensus.
À long terme (9-30 mois) : mise à niveau révolutionnaire de l'architecture de base de Solana, avec pour objectif de réaliser cela d'ici 2027.
Leaders Concurrentiels Multiples, MCL( : Permet à plusieurs validateurs de proposer des transactions simultanément dans leurs propres pipelines, puis de trier ces blocs parallèles en fonction des frais prioritaires. Cela permet d'affaiblir le monopole d'un seul emballeur et d'améliorer la résistance à la censure.
Applications natives à exécution contrôlée )Exécution contrôlée par l'application, ACE( Fonction : donne réellement aux contrats intelligents sur la chaîne le pouvoir de contrôler l'ordre d'exécution des transactions.
L'analyse en arrive ici, l'auteur pense que l'histoire derrière la proposition de la feuille de route ICM devrait être la suivante : les DEX établis sur Solana ont été dépassés par le nouvel arrivant Hyperliquid grâce à l'excellente expérience d'un "plateforme d'échange sur chaîne". Les DEX établis, incapables de rivaliser, n'ont d'autre choix que de solliciter l'aide de "grands noms" comme Solana Labs et Anza. Les "grands noms" ont proposé un plan de transformation technique ICM, affirmant qu'ils allaient reproduire les compétences clés d'Hyperliquid pour les DEX établis, afin de leur permettre de revenir sur le marché des DEX. Cependant, les "grands noms" ont également déclaré que cette transformation technique était extrêmement difficile, c'est pourquoi ils ont divisé le plan technique en une stratégie en trois étapes, et l'équipement que l'on peut fournir aux DEX établis dans un avenir proche n'est que le BAM d'un célèbre laboratoire, laissant les DEX établis s'en débrouiller et comparer avec Hyperliquid.
Après avoir clarifié le contexte de l'histoire, dans les chapitres suivants, l'auteur analysera en détail quelles compétences clés ICM a réellement imitées et reproduites de Hyperliquid.
Imiter un : Mécanisme de tri des transactions
Problème : Comme mentionné précédemment, la chaîne actuelle favorise les takers, laissant les makers souffrir du "flux toxique". Les utilisateurs qui passent des ordres actifs peuvent, en fonction des derniers prix hors chaîne, initier instantanément des transactions sur les ordres placés sur la chaîne, en augmentant les frais de transaction pour être prioritaires, tandis que les market makers n'ont souvent pas le temps de mettre à jour ou de retirer leurs ordres. Le résultat est que les market makers doivent soit élargir l'écart, soit retirer complètement la liquidité, ce qui dégrade la profondeur du marché.
) La solution ultime d'ICM : application d'exécution contrôlable (ACE)
La feuille de route ICM propose le concept d'ACE (Application Controlled Execution), qui décentralise le droit de tri des transactions aux différentes applications sur la chaîne, permettant à chaque application de décider comment trier et exécuter les transactions liées à elle. Par exemple, sur Solana, qui mettra en œuvre l'ACE dans le futur, 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 dernier prix auprès de l'oracle avant de réaliser des transactions de grande envergure, garantissant que les ordres sont exécutés au dernier prix raisonnable, afin d'éviter que les cotations des teneurs de marché ne soient basées sur des prix obsolètes et ne soient sujettes à l'arbitrage.
Priorité d'exécution des annulations de commande : l'application peut définir que les "demandes d'annulation" sont prioritaires par rapport aux nouvelles "transactions de prise de commande", permettant ainsi au maker de retirer rapidement un ordre en cas de conditions de marché défavorables.
Enchères à la fin de la file : par exemple, après qu'un ordre d'achat énorme ait fait monter le prix, l'application DeFi mettra en vente l'opportunité "suivante", et celui qui est prêt à restituer le plus d'avantages au protocole (ou aux utilisateurs) verra son ordre exécuté juste après le gros ordre. Les applications DeFi peuvent restituer les bénéfices des enchères aux utilisateurs, transformant ainsi le flux MEV toxique en revenus bénéfiques.
BAM d'un laboratoire renommé : plan de transition
Avant le lancement officiel d'ACE, un laboratoire renommé a lancé une solution de transition appelée Block Assembly Marketplace (BAM). Le flux de travail de BAM est :
L'utilisateur envoie la transaction à un nœud exécutant le logiciel BAM (plutôt qu'au Leader actuel).
Les nœuds BAM collectent les transactions locales et exécutent divers plugins ###plugin( pour réorganiser les paquets de transactions (Bundle) sous protection de la vie privée (les plugins fonctionnent dans un environnement TEE sécurisé et cachent 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é aux annulations, la mise à jour des prix des oracles avant l'appariement, voire l'exécution de mises aux enchères complexes au sein de l'application.
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 que l'ACE ne soit mis en chaîne, ses fonctionnalités étant très proches de l'ACE ultime, mais il fonctionne dans un réseau indépendant hors chaîne, plutôt que d'être intégré au protocole principal de Solana.
Il est à noter qu'un laboratoire bien connu fournissait auparavant une infrastructure axée sur l'extraction MEV (comme un certain moteur de bloc), dont le modèle commercial consiste à créer des opportunités pour les arbitragistes en optimisant l'ordre des transactions et en partageant les bénéfices. Cela représente, dans une certaine mesure, une "lance" opposée aux utilisateurs ordinaires et aux victimes d'arbitrage. Cependant, ce laboratoire a fermé début 2024 la fonction 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 mesure indique que la communauté Solana a tendance à réprimer les MEV nuisibles et à protéger l'équité des utilisateurs.
Le lancement de BAM s'inscrit parfaitement dans cette logique : il transforme essentiellement le mécanisme de classement initialement utilisé pour l'arbitrage MEV en un "bouclier" pour protéger les fournisseurs de liquidité tels que les teneurs de marché, par exemple en priorisant les annulations forcées pour éviter que les teneurs de marché ne subissent des pertes, et en introduisant des remises sur les enchères pour réduire les profits des arbitrages. Les chercheurs MEV d'origine qui souhaitent gagner de l'argent doivent désormais changer de rôle, en développant des plugins BAM pour servir les protocoles DeFi et en tirant des bénéfices des frais de plugin.
) demander conseil à Hyperliquid
La pensée ACE/BAM ci-dessus peut en fait être considérée comme une tentative de rattraper le mécanisme de correspondance en ligne 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 Hyperliquid, est en réalité l'un des plus grands teneurs de marché de cette plateforme, il n'est donc pas surprenant que les règles de la chaîne Hyperliquid soient davantage axées sur 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, telles que :
Protection prioritaire des ordres en attente : les annulations et les ordres de maker sont traités en priorité, évitant ainsi que les teneurs de marché subissent des exécutions défavorables à leur insu. La "priorité d'exécution des annulations" mentionnée par Solana ACE est déjà pratiquée par Hyperliquid depuis de nombreuses années.
Garantie de prix la plus récente : Le processus de règlement et d'appariement de Hyperliquid met l'accent sur l'utilisation des derniers prix des oracles et de l'état des marges pour effectuer un "double contrôle". Par exemple, lorsque des ordres sont appariés, le système récupère à nouveau le dernier prix de l'oracle pour évaluer les marges des deux parties, afin de s'assurer qu'il n'y a pas de risque dû à un retard de prix. Cela ressemble à la façon dont ACE insère une mise à jour de l'oracle avant l'exécution des transactions.
Protection contre les transactions automatiques : si une même adresse achète et vend en même temps, Hyperliquid annule automatiquement plutôt que d'exécuter, afin d'éviter le gonflage des volumes ou des frais inutiles.
Solana ICM de l'ACE/BAM, sans aucun doute, s'inspire de Hyperliquid. En tant que leader des CLOB sur la chaîne, Hyperliquid a mis en place diverses mécanismes favorables aux teneurs de marché grâce à une chaîne dédiée. Solana espère maintenant utiliser une chaîne universelle avec des plugins modulaires pour reproduire cet effet ------ c'est-à-dire donner à chaque application un contrôle similaire à celui de Hyperliquid sur le classement des transactions.
Imiter deux : 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 et est considéré comme "confirmé(Confirmed)", mais environ 32 blocs suivants doivent être accumulés sur la chaîne (généralement environ 13 secondes) pour être ancrés comme "finalisé###Finalized(". Pour certaines applications (comme le trading haute fréquence), une durée de confirmation finale de quelques secondes est encore trop longue.
HyperBFT est l'algorithme de consensus développé par Hyperliquid, inspiré par le consensus HotStuff, qui utilise deux tours de vote pour confirmer les blocs et réaliser une "finalité instantanée".