BAM de Solana : pas seulement à la recherche de la vitesse, mais également soucieux de la qualité des transactions

Solana est connue pour sa vitesse de transaction et son volume élevé, mais cela signifie-t-il qu'elle est déjà "suffisamment bonne" ? En examinant de près ces transactions, nous découvrirons un problème clé : ces transactions créent-elles toutes une valeur réelle ?

En réalité, une grande partie des transactions sur Solana ne provient pas d'une demande réelle, mais d'arbitragistes à haute fréquence qui profitent d'un écart d'information de quelques millisecondes. Ces "traders toxiques" exploitent un avantage technique en augmentant les frais de Gas juste avant que les teneurs de marché ne retirent leurs ordres, complétant ainsi leurs transactions en premier pour réaliser des bénéfices, ce qui entraîne des pertes pour les teneurs de marché. Pour compenser ces pertes, les teneurs de marché doivent élargir l'écart entre les prix d'achat et de vente, ce qui nuit finalement aux intérêts des utilisateurs ordinaires.

Solana a toujours rêvé de réaliser un livre de commandes sur la chaîne, remplaçant ainsi les échanges centralisés. Cependant, la présence de "traders toxiques" est devenue un obstacle à la réalisation de cet objectif. Voici le nouveau défi auquel Solana est confronté : le volume des transactions n'est pas égal à la liquidité. Un marché sain a besoin non pas de plus de transactions, mais de transactions de meilleure qualité.

Comment éliminer les transactions toxiques et protéger la liquidité du marché ?

Dans le système actuel de Solana, en raison des caractéristiques d'enchères périodiques du mécanisme de consensus, les preneurs d'ordres bénéficient en réalité d'un droit de priorité, ce qui entraîne une influence malveillante du MEV sur l'équité du marché.

Plus précisément, dans le consensus actuel de Solana, chaque période de 400 millisecondes correspond à un Slot (, et les transactions sont exécutées par ordre de frais de Gas payés. Dans ce processus, les teneurs de marché doivent ajuster fréquemment leurs offres, tandis que les arbitragistes haute fréquence réalisent des transactions immédiatement en surveillant les écarts de prix et en saisissant les opportunités. Cela conduit à ce que les arbitragistes puissent, en payant des frais plus élevés, exécuter des transactions avant que les teneurs de marché n'annulent leurs ordres, ce qui entraîne des pertes fréquentes pour les teneurs de marché.

Pour un échange décentralisé de type carnet de commandes )DEX(, l'ordre de transaction idéal devrait être le suivant : avec les fluctuations de prix, d'abord exécuter toutes les annulations, puis exécuter les nouveaux ordres, et enfin exécuter les transactions. Cependant, le mécanisme de consensus actuel de Solana ne peut pas réaliser cela à un niveau microscopique.

Le même problème existe également dans les cotations des oracles et les protocoles de prêt. Idéalement, le prix de l'oracle devrait être mis à jour avant d'exécuter les transactions dépendant de ce prix ; il faut d'abord reconstituer la marge, puis procéder à la liquidation.

Ainsi, Solana a besoin d'un mécanisme permettant à différents protocoles de trier les transactions en fonction des besoins, c'est ce que Solana met toujours en avant avec le contrôle d'application d'exécution )ACE(.

BAM: la solution de Solana

Pour résoudre ces problèmes, Solana a lancé le marché d'assemblage de blocs )BAM(. BAM construit une couche de tri ou une couche de prétraitement entre l'application sur la chaîne Solana et le réseau principal. Il utilise un environnement d'exécution de confiance )TEEs( pour créer un bac à sable de confidentialité, dans lequel les transactions sont triées selon des règles prédéfinies ou le principe du premier entré, premier sorti )FIFO(.

BAM prend en charge trois modes de fonctionnement :

1. Mode par défaut de Solana
2. Le mode Block-Engine ) est similaire à la solution MEV actuelle de Jito (.
3. Mode BAM) les validateurs sont strictement classés par FIFO(

Les caractéristiques principales du modèle BAM incluent :

1. Utiliser les TEE pour construire un environnement de confidentialité pour le tri des transactions, garantissant l'équité.
2. Permettre aux applications de construire une logique de tri personnalisée via le système de plugins, réalisant un tri complexe.
3. Mettre en œuvre la fonction ACE, permettant à l'application de contrôler l'ordre d'exécution des transactions.

![Interprétation du marché d'assemblage de blocs Solana BAM : lorsque la vitesse n'est plus la seule quête])https://img-cdn.gateio.im/webp-social/moments-80b3584e69b2d2874adfe16a0331ad66.webp(

Applications pratiques de BAM

Les cas d'utilisation de BAM incluent :

1. Protection de la liquidation des prêts : exécution prioritaire des opérations de complément de garantie, suivie d'un contrôle de liquidation.
2. Combinaison de transactions au niveau atomique : mettre à jour le prix de l'oracle, puis exécuter les transactions dépendant de ce prix.
3. Protection contre la volatilité des prix : décomposer les gros ordres en petites fractions pour les exécuter par lots, afin d'éviter des fluctuations de marché violentes.
4. Protection des market makers : permet des annulations et des nouvelles commandes en millisecondes, réduisant ainsi l'arbitrage malveillant.

Le déploiement de BAM améliorera considérablement l'expérience de trading sur Solana, la rapprochant du niveau d'expérience des échanges centralisés. Il apporte vérifiabilité, protection de la vie privée et programmabilité au processus de traitement des transactions de Solana, offrant aux développeurs la possibilité de construire diverses infrastructures financières telles que des livres d'ordres à cours limité centralisés, des bourses de contrats perpétuels et des dark pools.

Dans l'ensemble, le lancement de BAM marque le fait que Solana ne recherche plus uniquement la vitesse, mais accorde une plus grande importance à la qualité des transactions et à la santé du marché, ce qui stimulera davantage l'innovation et le développement de l'écosystème Solana.