Solana équilibre entre la vitesse des transactions et la création de valeur
Solana est connue pour sa rapidité de transaction et son volume élevé de transactions, mais cela signifie-t-il qu'elle a atteint la perfection ? Lorsque nous examinons ces transactions de près, une question clé se pose : ces transactions créent-elles toutes une valeur réelle ?
En réalité, un grand nombre de transactions sur Solana ne proviennent pas d'une demande réelle de transactions. Une part importante vient des arbitragistes à haute fréquence, qui tirent profit des différences d'information de l'ordre de la milliseconde. Ces soi-disant "traders toxiques" utilisent leur avantage technologique pour faire en sorte que leurs transactions soient priorisées en augmentant les frais de Gas au moment où les market makers s'apprêtent à annuler leurs ordres, réalisant ainsi un arbitrage, ce qui entraîne des pertes pour les market makers. Pour compenser ces pertes, les market makers doivent élargir l'écart entre les prix d'achat et de vente, coût supplémentaire finalement supporté par les utilisateurs ordinaires.
Solana a toujours eu pour vision de réaliser un carnet de commandes sur la chaîne, remplaçant ainsi les échanges centralisés. Cependant, la présence de "traders toxiques" est devenue le principal obstacle à la réalisation de cet objectif. Voici le nouveau défi auquel Solana est actuellement confronté : le volume des transactions n'est pas équivalent à la liquidité. Un marché véritablement sain n'a pas besoin de plus de transactions, mais de transactions de meilleure qualité.
Comment éliminer les transactions toxiques et mieux protéger la liquidité ?
Dans le système actuel, en raison du mécanisme de consensus de Solana qui utilise des enchères périodiques, les preneurs de commandes bénéficient en réalité d'une priorité, ce qui entraîne un comportement malveillant de MEV (valeur extractible par les mineurs) affectant l'équité du marché.
Plus précisément, dans le mécanisme de consensus de Solana, les transactions à l'intérieur de chaque période de temps (Slot) sont triées en fonction des frais de Gas prioritaires payés, les transactions avec les offres les plus élevées étant exécutées en premier. Ce mécanisme d'enchères a lieu toutes les 400 millisecondes. Au cours de ce processus, les teneurs de marché doivent ajuster fréquemment leurs offres, y compris annuler des ordres et en placer de nouveaux, pour s'adapter aux fluctuations des prix du marché.
Les traders à l'achat, en particulier les arbitragistes à haute fréquence, surveillent constamment les écarts de prix et procèdent immédiatement à des transactions dès qu'ils détectent une opportunité. Ils peuvent payer des frais plus élevés pour s'assurer que la transaction est exécutée avant que le teneur de marché n'annule son ordre, ce qui entraîne souvent des pertes pour les teneurs de marché.
Pour les échanges décentralisés (DEX) basés sur un carnet d'ordres, l'ordre idéal des transactions devrait être le suivant : avec les fluctuations de prix, toutes les annulations devraient d'abord être exécutées, suivies des nouveaux ordres, et enfin des transactions. Cependant, le mécanisme de consensus actuel de Solana ne peut pas réaliser cela au niveau microscopique.
Le même problème existe au niveau des prix des oracles. Idéalement, les prix des oracles devraient être mis à jour en premier, puis les transactions dépendant de ce prix devraient être exécutées. Cependant, dans l'intervalle actuel de 400 millisecondes, le marché peut subir des fluctuations violentes, ce qui entraîne la réalisation des transactions au prix initial.
Pour un protocole de prêt, la meilleure séquence d'opérations devrait être de d'abord ajouter des marges, puis de procéder à la liquidation.
Par conséquent, Solana a besoin d'un mécanisme permettant à différents protocoles de trier les transactions en fonction de leurs besoins respectifs. C'est le concept d'Exécution Contrôlée par l'Application (Application-Controlled Execution, ACE) que Solana a toujours souligné.
Pour résoudre ces problèmes, Solana a proposé la solution BAM (marché d'assemblage de blocs).
BAM : la nouvelle réponse de Solana
BAM a construit une couche de tri entre la couche d'application et le réseau principal de Solana, également appelée couche de prétraitement. Elle utilise un environnement d'exécution fiable (TEE) pour créer un bac à sable de confidentialité, où les transactions sont triées selon des règles prédéterminées ou selon le principe du premier entré, premier sorti (FIFO).
Cette innovation vise à mieux servir les protocoles tels que les carnets de commandes, les échanges de contrats perpétuels et les dark pools.
Comparaison entre le traitement traditionnel des transactions de Solana et le mode BAM
Pour mieux comprendre comment BAM construit une couche de tri entre les applications et le réseau principal de Solana, nous pouvons comparer le processus de transaction traditionnel de Solana et le processus après l'adoption de BAM :
Processus de transaction traditionnel de Solana :
L'utilisateur confirme la transaction dans le portefeuille
Transaction envoyée au nœud RPC
RPC envoie la transaction au nœud Leader du réseau principal Solana pour la période actuelle
Le Leader collecte les transactions dans le pool de transactions, les classe, les regroupe en blocs et les diffuse.
Autres nœuds votent
Processus de transaction après l'adoption de BAM :
L'utilisateur confirme la transaction dans le portefeuille.
Transaction envoyée au nœud RPC
Les transactions sont retransmises au réseau BAM et triées dans un environnement TEE. Pendant ce temps, les nœuds peuvent ajouter des transactions supplémentaires via des plugins (comme la mise à jour des prix des oracles), puis générer une preuve.
Le paquet de données de transaction est soumis au nœud Leader du réseau principal Solana.
Le leader inclut le paquet de données BAM lors de la collecte des transactions, le regroupe en blocs et le diffuse.
Autres nœuds votent
Il est important de noter que BAM ne contredit pas le processus de consensus du réseau principal Solana, mais agit comme une fonctionnalité optionnelle. BAM ne fonctionne pas directement sur le réseau principal Solana, mais effectue le tri des transactions "hors chaîne" à l'avance, puis soumet les transactions regroupées au réseau principal Solana.
Mode de tri des transactions de BAM
BAM prend en charge trois modes de fonctionnement :
Mode par défaut de Solana
Mode Block-Engine : La solution MEV actuelle de Jito repose sur un mécanisme d'enchères.
Mode BAM : Les validateurs trient strictement selon le principe du premier entré, premier sorti (FIFO)
Les caractéristiques clés du mode BAM incluent :
Environnements d'exécution de confiance (TEEs) : Utiliser des TEEs pour construire un environnement de confidentialité afin de trier les transactions, garantissant ainsi l'équité.
Système de plugins : Grâce au système de plugins, BAM permet aux applications de construire une logique de tri des transactions personnalisée. Ce tri personnalisé est basé sur des règles prédéfinies, et non sur un tri arbitraire par les nœuds. Le système de plugins prévoit la mise en œuvre d'un tri complexe des transactions tout en maintenant les garanties de sécurité de l'environnement TEE. Actuellement, ce système est encore en phase de développement précoce.
Applications réelles de BAM
Les applications pratiques de BAM incluent :
Protection contre le règlement de prêt : pour les contrats de prêt, après détection d'un risque de règlement, effectuer en priorité une opération de collatéral supplémentaire, puis procéder à un contrôle de règlement.
Combinaisons de transactions au niveau atomique : Pour un DEX, mettre à jour le prix de l'oracle, puis exécuter les transactions qui dépendent de ce prix. Pour un DEX de contrat, il est également possible de régler des produits dérivés connexes dans la même fenêtre temporelle.
Protection contre la volatilité des prix : pour DEX, détecter les ordres exceptionnellement importants, les diviser en petites transactions exécutées par étapes, donner au marché suffisamment de temps pour réagir, éviter le spirale de la mort causée par des liquidations en chaîne ou des arbitrages.
Protection des teneurs de marché : en cas d'événements imprévus, être capable d'annuler des ordres, de mettre à jour les prix des oracles et de repositionner les ordres des teneurs de marché en millisecondes, afin d'éviter les arbitrages malveillants et de réduire l'écart de prix.
Avec le déploiement de BAM, l'expérience de transaction de Solana devrait s'améliorer considérablement, rendant l'expérience de ses applications sur la chaîne principale plus proche de celle des échanges centralisés.
Dans l'ensemble, BAM a apporté vérifiabilité, protection de la vie privée et programmabilité au processus de traitement des transactions de Solana. Cela permet aux développeurs de créer des carnets de commandes à prix limite centralisés, des bourses de contrats perpétuels, des dark pools et d'autres infrastructures financières nécessitant un contrôle de l'ordre, une exécution déterministe et une protection de la vie privée, favorisant ainsi l'innovation et le développement de l'écosystème Solana.
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.
9 J'aime
Récompense
9
6
Reposter
Partager
Commentaire
0/400
blockBoy
· Il y a 7h
Se faire prendre pour des cons ne dépend pas de la vitesse.
Voir l'originalRépondre0
shadowy_supercoder
· Il y a 7h
Jouer avec les mots, c'est encore de l'innovation quand on se fait avoir.
Voir l'originalRépondre0
ThreeHornBlasts
· Il y a 7h
C'est juste une tumeur rapide.
Voir l'originalRépondre0
SchrödingersNode
· Il y a 7h
Les pièges à chien à haute fréquence sont vraiment nuls.
Voir l'originalRépondre0
AirdropHunter
· Il y a 7h
piège piégeage ! Arbitrage sur la terre ferme et c'est tout.
Voir l'originalRépondre0
GweiObserver
· Il y a 7h
Encore un coup de prendre les gens pour des idiots.
Le plan BAM de Solana : équilibrer des transactions rapides avec la création de valeur réelle
Solana équilibre entre la vitesse des transactions et la création de valeur
Solana est connue pour sa rapidité de transaction et son volume élevé de transactions, mais cela signifie-t-il qu'elle a atteint la perfection ? Lorsque nous examinons ces transactions de près, une question clé se pose : ces transactions créent-elles toutes une valeur réelle ?
En réalité, un grand nombre de transactions sur Solana ne proviennent pas d'une demande réelle de transactions. Une part importante vient des arbitragistes à haute fréquence, qui tirent profit des différences d'information de l'ordre de la milliseconde. Ces soi-disant "traders toxiques" utilisent leur avantage technologique pour faire en sorte que leurs transactions soient priorisées en augmentant les frais de Gas au moment où les market makers s'apprêtent à annuler leurs ordres, réalisant ainsi un arbitrage, ce qui entraîne des pertes pour les market makers. Pour compenser ces pertes, les market makers doivent élargir l'écart entre les prix d'achat et de vente, coût supplémentaire finalement supporté par les utilisateurs ordinaires.
Solana a toujours eu pour vision de réaliser un carnet de commandes sur la chaîne, remplaçant ainsi les échanges centralisés. Cependant, la présence de "traders toxiques" est devenue le principal obstacle à la réalisation de cet objectif. Voici le nouveau défi auquel Solana est actuellement confronté : le volume des transactions n'est pas équivalent à la liquidité. Un marché véritablement sain n'a pas besoin de plus de transactions, mais de transactions de meilleure qualité.
Comment éliminer les transactions toxiques et mieux protéger la liquidité ?
Dans le système actuel, en raison du mécanisme de consensus de Solana qui utilise des enchères périodiques, les preneurs de commandes bénéficient en réalité d'une priorité, ce qui entraîne un comportement malveillant de MEV (valeur extractible par les mineurs) affectant l'équité du marché.
Plus précisément, dans le mécanisme de consensus de Solana, les transactions à l'intérieur de chaque période de temps (Slot) sont triées en fonction des frais de Gas prioritaires payés, les transactions avec les offres les plus élevées étant exécutées en premier. Ce mécanisme d'enchères a lieu toutes les 400 millisecondes. Au cours de ce processus, les teneurs de marché doivent ajuster fréquemment leurs offres, y compris annuler des ordres et en placer de nouveaux, pour s'adapter aux fluctuations des prix du marché.
Les traders à l'achat, en particulier les arbitragistes à haute fréquence, surveillent constamment les écarts de prix et procèdent immédiatement à des transactions dès qu'ils détectent une opportunité. Ils peuvent payer des frais plus élevés pour s'assurer que la transaction est exécutée avant que le teneur de marché n'annule son ordre, ce qui entraîne souvent des pertes pour les teneurs de marché.
Pour les échanges décentralisés (DEX) basés sur un carnet d'ordres, l'ordre idéal des transactions devrait être le suivant : avec les fluctuations de prix, toutes les annulations devraient d'abord être exécutées, suivies des nouveaux ordres, et enfin des transactions. Cependant, le mécanisme de consensus actuel de Solana ne peut pas réaliser cela au niveau microscopique.
Le même problème existe au niveau des prix des oracles. Idéalement, les prix des oracles devraient être mis à jour en premier, puis les transactions dépendant de ce prix devraient être exécutées. Cependant, dans l'intervalle actuel de 400 millisecondes, le marché peut subir des fluctuations violentes, ce qui entraîne la réalisation des transactions au prix initial.
Pour un protocole de prêt, la meilleure séquence d'opérations devrait être de d'abord ajouter des marges, puis de procéder à la liquidation.
Par conséquent, Solana a besoin d'un mécanisme permettant à différents protocoles de trier les transactions en fonction de leurs besoins respectifs. C'est le concept d'Exécution Contrôlée par l'Application (Application-Controlled Execution, ACE) que Solana a toujours souligné.
Pour résoudre ces problèmes, Solana a proposé la solution BAM (marché d'assemblage de blocs).
BAM : la nouvelle réponse de Solana
BAM a construit une couche de tri entre la couche d'application et le réseau principal de Solana, également appelée couche de prétraitement. Elle utilise un environnement d'exécution fiable (TEE) pour créer un bac à sable de confidentialité, où les transactions sont triées selon des règles prédéterminées ou selon le principe du premier entré, premier sorti (FIFO).
Cette innovation vise à mieux servir les protocoles tels que les carnets de commandes, les échanges de contrats perpétuels et les dark pools.
Comparaison entre le traitement traditionnel des transactions de Solana et le mode BAM
Pour mieux comprendre comment BAM construit une couche de tri entre les applications et le réseau principal de Solana, nous pouvons comparer le processus de transaction traditionnel de Solana et le processus après l'adoption de BAM :
Processus de transaction traditionnel de Solana :
Processus de transaction après l'adoption de BAM :
Il est important de noter que BAM ne contredit pas le processus de consensus du réseau principal Solana, mais agit comme une fonctionnalité optionnelle. BAM ne fonctionne pas directement sur le réseau principal Solana, mais effectue le tri des transactions "hors chaîne" à l'avance, puis soumet les transactions regroupées au réseau principal Solana.
Mode de tri des transactions de BAM
BAM prend en charge trois modes de fonctionnement :
Les caractéristiques clés du mode BAM incluent :
Environnements d'exécution de confiance (TEEs) : Utiliser des TEEs pour construire un environnement de confidentialité afin de trier les transactions, garantissant ainsi l'équité.
Système de plugins : Grâce au système de plugins, BAM permet aux applications de construire une logique de tri des transactions personnalisée. Ce tri personnalisé est basé sur des règles prédéfinies, et non sur un tri arbitraire par les nœuds. Le système de plugins prévoit la mise en œuvre d'un tri complexe des transactions tout en maintenant les garanties de sécurité de l'environnement TEE. Actuellement, ce système est encore en phase de développement précoce.
Applications réelles de BAM
Les applications pratiques de BAM incluent :
Protection contre le règlement de prêt : pour les contrats de prêt, après détection d'un risque de règlement, effectuer en priorité une opération de collatéral supplémentaire, puis procéder à un contrôle de règlement.
Combinaisons de transactions au niveau atomique : Pour un DEX, mettre à jour le prix de l'oracle, puis exécuter les transactions qui dépendent de ce prix. Pour un DEX de contrat, il est également possible de régler des produits dérivés connexes dans la même fenêtre temporelle.
Protection contre la volatilité des prix : pour DEX, détecter les ordres exceptionnellement importants, les diviser en petites transactions exécutées par étapes, donner au marché suffisamment de temps pour réagir, éviter le spirale de la mort causée par des liquidations en chaîne ou des arbitrages.
Protection des teneurs de marché : en cas d'événements imprévus, être capable d'annuler des ordres, de mettre à jour les prix des oracles et de repositionner les ordres des teneurs de marché en millisecondes, afin d'éviter les arbitrages malveillants et de réduire l'écart de prix.
Avec le déploiement de BAM, l'expérience de transaction de Solana devrait s'améliorer considérablement, rendant l'expérience de ses applications sur la chaîne principale plus proche de celle des échanges centralisés.
Dans l'ensemble, BAM a apporté vérifiabilité, protection de la vie privée et programmabilité au processus de traitement des transactions de Solana. Cela permet aux développeurs de créer des carnets de commandes à prix limite centralisés, des bourses de contrats perpétuels, des dark pools et d'autres infrastructures financières nécessitant un contrôle de l'ordre, une exécution déterministe et une protection de la vie privée, favorisant ainsi l'innovation et le développement de l'écosystème Solana.