Solana rattrape Hyperliquid : une imitation ambitieuse
Récemment, un événement intéressant s'est produit dans l'écosystème Solana. La Fondation Solana, Anza, Jito Labs et d'autres acteurs de poids ont conjointement publié une feuille de route technique intitulée "Internet Capital Markets(Internet Capital Markets, ICM)". Le cœur de cette feuille de route est le concept d'"Exécution Contrôlée par l'Application(Application Controlled Execution, ACE)", dont l'objectif est de permettre aux applications en chaîne de contrôler le tri des transactions à la milliseconde, créant ainsi un "Wall Street en chaîne" décentralisé.
Bien que Hyperliquid ne soit pas mentionné directement dans la feuille de route, il est facile de voir que la conception s'adresse presque partout aux forces de Hyperliquid. C'est comme si Solana disait : "Vous avez Hyperliquid, nous devons aussi l'avoir, et nous devons le faire mieux !"
Il faut savoir que Hyperliquid a dominé le marché des contrats à terme perpétuels en chaîne, avec un volume de transactions atteignant environ 65 % du marché des contrats perpétuels décentralisés. Face à un concurrent aussi puissant, Solana ne semble clairement pas vouloir être dépassé, c'est pourquoi elle a lancé cette feuille de route ICM.
Alors, qu'est-ce que cette "répétition"? Solana peut-il vraiment rattraper ou même dépasser Hyperliquid? Analysons cela de plus près.
Contexte et contenu de l'ICM
Qui est à l'origine de cette transformation ?
Les acteurs majeurs de l'écosystème Solana participent à l'élaboration de la feuille de route :
Solana Foundation/Labs : le "papa" de Solana, responsable de la coordination générale et du développement du protocole central.
Anza: une entreprise de développement fondée par d'anciens membres de Solana Labs, similaire à ConsenSys d'Ethereum. Responsable de nombreux défis technologiques clés, tels que le nouveau protocole de consensus Alpenglow.
Jito Labs : fournisseur d'infrastructure MEV sur Solana, ayant une influence considérable. Il domine l'offre de solutions de tri de transactions telles que Block Assembly Marketplace (BAM).
Multicoin Capital : célèbre institution d'investissement en cryptomonnaies, premier supporter de Solana. Détient une grande quantité de SOL et des droits sur des projets écologiques, ayant un certain poids dans la 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 : projet DEX de contrats perpétuels de premier plan sur Solana. Auparavant, il adoptait un modèle de correspondance hors chaîne, mais il se trouve un peu en difficulté face à Hyperliquid entièrement sur chaîne, espérant renaître 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é, principalement pour résoudre le problème du mécanisme de transaction actuel sur la chaîne qui n'est pas assez amical pour les teneurs de marché. Actuellement, le Taker(, qui initie activement la transaction, a souvent l'avantage, tandis que le Maker), qui place des ordres en attente d'exécution, se trouve désavantagé. Cela est dû au fait que le Taker a généralement accès aux dernières informations et peut s'assurer que les transactions sont exécutées en priorité en augmentant les frais de transaction, tandis que le Maker n'a souvent pas le temps d'annuler ses ordres et se voit contraint d'exécuter à des prix défavorables.
Certains arbitrageurs à haute fréquence peuvent exploiter cette asymétrie en lançant des attaques de "trafic toxique". Par exemple, lorsque le prix sur la chaîne n'est pas encore mis à jour mais que le prix hors chaîne a déjà changé, l'arbitrageur peut utiliser l'ancien prix pour remplir les ordres des teneurs de marché, faisant ainsi supporter des pertes aux teneurs de marché. Pour se protéger, les teneurs de marché doivent 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é dans son ensemble.
La feuille de route ICM vise à équilibrer ce schéma et à attirer des liquidités de haute qualité sur la chaîne.
( Les trois étapes de l'ICM
Solana a divisé ce grand projet en trois étapes :
Court terme ) 1-3 mois ### : Optimiser principalement l'expérience des transactions sur la chaîne existante, rendre les applications de carnet de commandes plus fonctionnelles, réduire les interférences MEV malveillantes. Comprend :
Le marché Block Assembly de Jito Labs(BAM) a été lancé sur le réseau principal. Il s'agit d'un système externe temporaire avant le lancement de l'ACE ultime, permettant aux contrats intelligents Solana d'avoir un pouvoir autonome de tri 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 slippage et les pertes MEV.
Ces améliorations devraient être mises en œuvre successivement 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, augmentation du débit :
Déployer un réseau de fibre optique dédié à DoubleZero, offrant aux validateurs une communication à haute vitesse avec un jitter quasi nul 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é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 de base de Solana, avec pour objectif de l'atteindre d'ici 2027 :
Multiples Leaders Concurrentiels, MCL( : Permettre à plusieurs validateurs de proposer des transactions simultanément dans leurs propres pipelines, puis de fusionner et trier ces blocs parallèles selon les frais prioritaires. Cela peut atténuer le monopole d'un seul empaqueteur et renforcer la résistance à la censure.
Exécution contrôlée par l'application )Application Controlled Execution, ACE( Fonction : donne véritablement aux contrats intelligents sur la chaîne le pouvoir de contrôler l'ordre d'exécution des transactions.
À ce stade de l'analyse, l'histoire derrière cette feuille de route ICM pourrait être la suivante : le DEX établi sur Solana, Drift, a été surpassé par le nouvel arrivant Hyperliquid, qui offre une excellente expérience de "Binance on-chain". Drift ayant du mal à rivaliser, a dû demander de l'aide à des "grands noms" comme Solana Labs, Anza, Jito, etc. Ces "grands noms" ont proposé ce plan de transformation technique ICM, affirmant qu'ils allaient copier les compétences clés de Hyperliquid pour aider Drift à retrouver sa place sur le marché des DEX. Mais les "grands noms" ont également indiqué que cette transformation technique est extrêmement difficile, c'est pourquoi ils ont divisé le plan technique en une stratégie en trois étapes. Récemment, la seule chose que Jito peut offrir à Drift est le BAM, permettant à Drift de faire un compromis pour rivaliser un peu avec Hyperliquid.
Comprenant ce contexte, analysons en détail quels sont les avantages clés que l'ICM a imités et copiés de Hyperliquid.
Imiter un: Mécanisme de tri des transactions
Problème : Comme mentionné précédemment, la chaîne actuelle favorise les preneurs, laissant les fabricants souffrir du "flux toxique". Les utilisateurs qui prennent l'initiative de manger des ordres peuvent, en fonction du dernier prix hors chaîne, lancer instantanément une transaction sur les ordres en cours sur la chaîne, et prioriser l'exécution en augmentant les frais de transaction, tandis que 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é soit élargissent l'écart, soit retirent complètement 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 d'ACE###Application Controlled Execution(, qui décentralise le droit de tri des transactions aux différentes applications sur la chaîne, permettant aux applications de décider elles-mêmes comment trier et exécuter les transactions liées à leur application. Par exemple, dans le Solana qui mettra en œuvre l'ACE à l'avenir, les contrats DeFi peuvent mettre en œuvre 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 de l'oracle avant de conclure 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 baser leurs offres sur des prix obsolètes et d'être soumis à des arbitrages.
Priorité d'exécution des annulations de commande : les applications peuvent définir que les "demandes d'annulation" ont la priorité sur les nouvelles "transactions de prise d'ordre", permettant ainsi au maker de retirer rapidement ses ordres lorsque le marché est défavorable.
Enchères à la fin de l'équipe : par exemple, après l'apparition d'un énorme ordre d'achat qui fait monter le prix, l'application DeFi mettra en vente l'opportunité "qui suit de près", celui qui est prêt à rendre le plus d'avantages au protocole ) ou à l'utilisateur (, le protocole DeFi exécutera la transaction de celui-là juste après le gros ordre. 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 :
L'utilisateur envoie la transaction à un nœud fonctionnant avec le logiciel BAM ### plutôt qu'au Leader actuel (.
Les nœuds BAM collectent les 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é, masquant 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, ou même l'exécution d'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 champ d'expérimentation avant le déploiement de l'ACE, fonctionnellement très proche de l'ACE ultime, mais il fonctionne dans un réseau indépendant hors chaîne, et non intégré au protocole de la chaîne principale Solana.
Il convient de noter que Jito a auparavant fourni une infrastructure axée sur l'extraction de MEV (, comme Jito Block Engine ), dont le modèle commercial consiste à créer des opportunités pour les arbitrageurs en optimisant l'ordre des transactions et à partager les bénéfices. Cela représente, dans une certaine mesure, une "lance" qui se dresse contre les utilisateurs ordinaires et ceux qui sont soumis à l'arbitrage. Cependant, Jito a fermé début 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 a tendance à réprimer le MEV nuisible et à maintenir 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és tels que les teneurs de marché, par exemple en donnant la priorité aux annulations forcées pour éviter les pertes des teneurs de marché, et en introduisant des incitations à la mise en concurrence pour réduire les bénéfices des courses. Les chercheurs MEV précédents, s'ils veulent gagner de l'argent, doivent changer de rôle et créer des plugins BAM au service des protocoles DeFi, en tirant profit des frais de plugin.
( prendre des conseils de 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 Hyperliquid. Hyperliquid est une chaîne dédiée )Appchain(, conçue pour servir les DEX. De plus, le HLP Vault opéré par l'équipe officielle de Hyperliquid est en réalité l'un des plus grands market makers de la plateforme, il n'est donc pas surprenant que les règles de la chaîne Hyperliquid soient davantage orientées vers les fournisseurs de liquidité et qu'elles aient déjà mis en œuvre de nombreux designs pour protéger les market makers au niveau de la chaîne, tels que :
Protection prioritaire pour les ordres en attente : les annulations et les ordres maker sont traités en priorité, évitant ainsi que les teneurs de marché subissent des transactions défavorables sans en être informés. Le "traitement prioritaire des annulations" mentionné par Solana ACE est déjà pratiqué depuis de nombreuses années par Hyperliquid.
Garantie de prix la plus récente : Le processus de liquidation et d'appariement de Hyperliquid met l'accent sur l'utilisation des derniers prix de l'oracle et de l'état de la marge pour effectuer une "double vérification". Par exemple, lorsqu'une commande est appariée, le système récupère à nouveau le dernier prix de l'oracle pour évaluer la marge des deux parties, afin de s'assurer qu'il n'y a pas de risque dû à un retard de prix. Cela ressemble à l'insertion d'une mise à jour de l'oracle par ACE avant l'exécution de la transaction.
Protection contre l'auto-négociation : si une même adresse achète et vend, Hyperliquid annule automatiquement au lieu de matcher, afin de prévenir le wash trading ou des frais inutiles.
L'ACE/BAM de Solana ICM s'inspire sans aucun doute de Hyperliquid. En tant que leader des CLOB sur blockchain, Hyperliquid a mis en place divers mécanismes favorables aux market makers via une chaîne dédiée. Solana espère maintenant utiliser une chaîne universelle et 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.
Imitation 2 : Finalité immédiate
) 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 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 ), une dizaine de secondes de temps de confirmation finale est encore trop long.
HyperBFT est un algorithme de consensus développé en interne par Hyperliquid, inspiré par le consensus HotStuff, qui utilise un vote en deux tours pour confirmer les blocs et réaliser la "finalité instantanée".
Premier tour : Pré-vote ( Prevote ) : Après avoir reçu le bloc candidat diffusé par le Proposeur, les validateurs effectuent une validation rapide. Si la validation est réussie, chaque validateur émettra un "pré-vote" ( Prevote ) pour ce bloc et le diffusera à l'ensemble du réseau. Ce vote représente : "J'ai regardé rapidement, ce bloc ne pose pas de problème."
Deuxième tour : préengagement ( Precommit ) : Une fois qu'un validateur a collecté des Prevotes de plus des deux tiers des validateurs pour le même bloc candidat, il obtient suffisamment de confiance pour croire que la majorité des membres du réseau approuve ce bloc. Ainsi, ce validateur émet un vote de "préengagement" ( 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 grand livre."
Lorsqu'un validateur a recueilli le Precommit de plus de 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.
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.
16 J'aime
Récompense
16
3
Reposter
Partager
Commentaire
0/400
GateUser-aa7df71e
· 07-31 07:15
La laisse pour chien doit également avoir sa propre attitude.
Voir l'originalRépondre0
BearMarketBarber
· 07-29 19:06
On ne peut pas l'apprendre, c'est impressionnant ! C'est toujours le même goût.
Solana lance une feuille de route ICM qui imite complètement les avantages clés de Hyperliquid.
Solana rattrape Hyperliquid : une imitation ambitieuse
Récemment, un événement intéressant s'est produit dans l'écosystème Solana. La Fondation Solana, Anza, Jito Labs et d'autres acteurs de poids ont conjointement publié une feuille de route technique intitulée "Internet Capital Markets(Internet Capital Markets, ICM)". Le cœur de cette feuille de route est le concept d'"Exécution Contrôlée par l'Application(Application Controlled Execution, ACE)", dont l'objectif est de permettre aux applications en chaîne de contrôler le tri des transactions à la milliseconde, créant ainsi un "Wall Street en chaîne" décentralisé.
Bien que Hyperliquid ne soit pas mentionné directement dans la feuille de route, il est facile de voir que la conception s'adresse presque partout aux forces de Hyperliquid. C'est comme si Solana disait : "Vous avez Hyperliquid, nous devons aussi l'avoir, et nous devons le faire mieux !"
Il faut savoir que Hyperliquid a dominé le marché des contrats à terme perpétuels en chaîne, avec un volume de transactions atteignant environ 65 % du marché des contrats perpétuels décentralisés. Face à un concurrent aussi puissant, Solana ne semble clairement pas vouloir être dépassé, c'est pourquoi elle a lancé cette feuille de route ICM.
Alors, qu'est-ce que cette "répétition"? Solana peut-il vraiment rattraper ou même dépasser Hyperliquid? Analysons cela de plus près.
Contexte et contenu de l'ICM
Qui est à l'origine de cette transformation ?
Les acteurs majeurs de l'écosystème Solana participent à l'élaboration de la feuille de route :
Solana Foundation/Labs : le "papa" de Solana, responsable de la coordination générale et du développement du protocole central.
Anza: une entreprise de développement fondée par d'anciens membres de Solana Labs, similaire à ConsenSys d'Ethereum. Responsable de nombreux défis technologiques clés, tels que le nouveau protocole de consensus Alpenglow.
Jito Labs : fournisseur d'infrastructure MEV sur Solana, ayant une influence considérable. Il domine l'offre de solutions de tri de transactions telles que Block Assembly Marketplace (BAM).
Multicoin Capital : célèbre institution d'investissement en cryptomonnaies, premier supporter de Solana. Détient une grande quantité de SOL et des droits sur des projets écologiques, ayant un certain poids dans la 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 : projet DEX de contrats perpétuels de premier plan sur Solana. Auparavant, il adoptait un modèle de correspondance hors chaîne, mais il se trouve un peu en difficulté face à Hyperliquid entièrement sur chaîne, espérant renaître 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é, principalement pour résoudre le problème du mécanisme de transaction actuel sur la chaîne qui n'est pas assez amical pour les teneurs de marché. Actuellement, le Taker(, qui initie activement la transaction, a souvent l'avantage, tandis que le Maker), qui place des ordres en attente d'exécution, se trouve désavantagé. Cela est dû au fait que le Taker a généralement accès aux dernières informations et peut s'assurer que les transactions sont exécutées en priorité en augmentant les frais de transaction, tandis que le Maker n'a souvent pas le temps d'annuler ses ordres et se voit contraint d'exécuter à des prix défavorables.
Certains arbitrageurs à haute fréquence peuvent exploiter cette asymétrie en lançant des attaques de "trafic toxique". Par exemple, lorsque le prix sur la chaîne n'est pas encore mis à jour mais que le prix hors chaîne a déjà changé, l'arbitrageur peut utiliser l'ancien prix pour remplir les ordres des teneurs de marché, faisant ainsi supporter des pertes aux teneurs de marché. Pour se protéger, les teneurs de marché doivent 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é dans son ensemble.
La feuille de route ICM vise à équilibrer ce schéma et à attirer des liquidités de haute qualité sur la chaîne.
( Les trois étapes de l'ICM
Solana a divisé ce grand projet en trois étapes :
Court terme ) 1-3 mois ### : Optimiser principalement l'expérience des transactions sur la chaîne existante, rendre les applications de carnet de commandes plus fonctionnelles, réduire les interférences MEV malveillantes. Comprend :
Le marché Block Assembly de Jito Labs(BAM) a été lancé sur le réseau principal. Il s'agit d'un système externe temporaire avant le lancement de l'ACE ultime, permettant aux contrats intelligents Solana d'avoir un pouvoir autonome de tri 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 slippage et les pertes MEV.
Ces améliorations devraient être mises en œuvre successivement 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, augmentation du débit :
Déployer un réseau de fibre optique dédié à DoubleZero, offrant aux validateurs une communication à haute vitesse avec un jitter quasi nul 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é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 de base de Solana, avec pour objectif de l'atteindre d'ici 2027 :
Multiples Leaders Concurrentiels, MCL( : Permettre à plusieurs validateurs de proposer des transactions simultanément dans leurs propres pipelines, puis de fusionner et trier ces blocs parallèles selon les frais prioritaires. Cela peut atténuer le monopole d'un seul empaqueteur et renforcer la résistance à la censure.
Exécution contrôlée par l'application )Application Controlled Execution, ACE( Fonction : donne véritablement aux contrats intelligents sur la chaîne le pouvoir de contrôler l'ordre d'exécution des transactions.
À ce stade de l'analyse, l'histoire derrière cette feuille de route ICM pourrait être la suivante : le DEX établi sur Solana, Drift, a été surpassé par le nouvel arrivant Hyperliquid, qui offre une excellente expérience de "Binance on-chain". Drift ayant du mal à rivaliser, a dû demander de l'aide à des "grands noms" comme Solana Labs, Anza, Jito, etc. Ces "grands noms" ont proposé ce plan de transformation technique ICM, affirmant qu'ils allaient copier les compétences clés de Hyperliquid pour aider Drift à retrouver sa place sur le marché des DEX. Mais les "grands noms" ont également indiqué que cette transformation technique est extrêmement difficile, c'est pourquoi ils ont divisé le plan technique en une stratégie en trois étapes. Récemment, la seule chose que Jito peut offrir à Drift est le BAM, permettant à Drift de faire un compromis pour rivaliser un peu avec Hyperliquid.
Comprenant ce contexte, analysons en détail quels sont les avantages clés que l'ICM a imités et copiés de Hyperliquid.
Imiter un: Mécanisme de tri des transactions
Problème : Comme mentionné précédemment, la chaîne actuelle favorise les preneurs, laissant les fabricants souffrir du "flux toxique". Les utilisateurs qui prennent l'initiative de manger des ordres peuvent, en fonction du dernier prix hors chaîne, lancer instantanément une transaction sur les ordres en cours sur la chaîne, et prioriser l'exécution en augmentant les frais de transaction, tandis que 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é soit élargissent l'écart, soit retirent complètement 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 d'ACE###Application Controlled Execution(, qui décentralise le droit de tri des transactions aux différentes applications sur la chaîne, permettant aux applications de décider elles-mêmes comment trier et exécuter les transactions liées à leur application. Par exemple, dans le Solana qui mettra en œuvre l'ACE à l'avenir, les contrats DeFi peuvent mettre en œuvre 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 de l'oracle avant de conclure 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 baser leurs offres sur des prix obsolètes et d'être soumis à des arbitrages.
Priorité d'exécution des annulations de commande : les applications peuvent définir que les "demandes d'annulation" ont la priorité sur les nouvelles "transactions de prise d'ordre", permettant ainsi au maker de retirer rapidement ses ordres lorsque le marché est défavorable.
Enchères à la fin de l'équipe : par exemple, après l'apparition d'un énorme ordre d'achat qui fait monter le prix, l'application DeFi mettra en vente l'opportunité "qui suit de près", celui qui est prêt à rendre le plus d'avantages au protocole ) ou à l'utilisateur (, le protocole DeFi exécutera la transaction de celui-là juste après le gros ordre. 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 :
L'utilisateur envoie la transaction à un nœud fonctionnant avec le logiciel BAM ### plutôt qu'au Leader actuel (.
Les nœuds BAM collectent les 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é, masquant 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, ou même l'exécution d'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 champ d'expérimentation avant le déploiement de l'ACE, fonctionnellement très proche de l'ACE ultime, mais il fonctionne dans un réseau indépendant hors chaîne, et non intégré au protocole de la chaîne principale Solana.
Il convient de noter que Jito a auparavant fourni une infrastructure axée sur l'extraction de MEV (, comme Jito Block Engine ), dont le modèle commercial consiste à créer des opportunités pour les arbitrageurs en optimisant l'ordre des transactions et à partager les bénéfices. Cela représente, dans une certaine mesure, une "lance" qui se dresse contre les utilisateurs ordinaires et ceux qui sont soumis à l'arbitrage. Cependant, Jito a fermé début 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 a tendance à réprimer le MEV nuisible et à maintenir 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és tels que les teneurs de marché, par exemple en donnant la priorité aux annulations forcées pour éviter les pertes des teneurs de marché, et en introduisant des incitations à la mise en concurrence pour réduire les bénéfices des courses. Les chercheurs MEV précédents, s'ils veulent gagner de l'argent, doivent changer de rôle et créer des plugins BAM au service des protocoles DeFi, en tirant profit des frais de plugin.
( prendre des conseils de 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 Hyperliquid. Hyperliquid est une chaîne dédiée )Appchain(, conçue pour servir les DEX. De plus, le HLP Vault opéré par l'équipe officielle de Hyperliquid est en réalité l'un des plus grands market makers de la plateforme, il n'est donc pas surprenant que les règles de la chaîne Hyperliquid soient davantage orientées vers les fournisseurs de liquidité et qu'elles aient déjà mis en œuvre de nombreux designs pour protéger les market makers au niveau de la chaîne, tels que :
Protection prioritaire pour les ordres en attente : les annulations et les ordres maker sont traités en priorité, évitant ainsi que les teneurs de marché subissent des transactions défavorables sans en être informés. Le "traitement prioritaire des annulations" mentionné par Solana ACE est déjà pratiqué depuis de nombreuses années par Hyperliquid.
Garantie de prix la plus récente : Le processus de liquidation et d'appariement de Hyperliquid met l'accent sur l'utilisation des derniers prix de l'oracle et de l'état de la marge pour effectuer une "double vérification". Par exemple, lorsqu'une commande est appariée, le système récupère à nouveau le dernier prix de l'oracle pour évaluer la marge des deux parties, afin de s'assurer qu'il n'y a pas de risque dû à un retard de prix. Cela ressemble à l'insertion d'une mise à jour de l'oracle par ACE avant l'exécution de la transaction.
Protection contre l'auto-négociation : si une même adresse achète et vend, Hyperliquid annule automatiquement au lieu de matcher, afin de prévenir le wash trading ou des frais inutiles.
L'ACE/BAM de Solana ICM s'inspire sans aucun doute de Hyperliquid. En tant que leader des CLOB sur blockchain, Hyperliquid a mis en place divers mécanismes favorables aux market makers via une chaîne dédiée. Solana espère maintenant utiliser une chaîne universelle et 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.
Imitation 2 : Finalité immédiate
) 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 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 ), une dizaine de secondes de temps de confirmation finale est encore trop long.
HyperBFT est un algorithme de consensus développé en interne par Hyperliquid, inspiré par le consensus HotStuff, qui utilise un vote en deux tours pour confirmer les blocs et réaliser la "finalité instantanée".
Premier tour : Pré-vote ( Prevote ) : Après avoir reçu le bloc candidat diffusé par le Proposeur, les validateurs effectuent une validation rapide. Si la validation est réussie, chaque validateur émettra un "pré-vote" ( Prevote ) pour ce bloc et le diffusera à l'ensemble du réseau. Ce vote représente : "J'ai regardé rapidement, ce bloc ne pose pas de problème."
Deuxième tour : préengagement ( Precommit ) : Une fois qu'un validateur a collecté des Prevotes de plus des deux tiers des validateurs pour le même bloc candidat, il obtient suffisamment de confiance pour croire que la majorité des membres du réseau approuve ce bloc. Ainsi, ce validateur émet un vote de "préengagement" ( 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 grand livre."
Lorsqu'un validateur a recueilli le Precommit de plus de 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.