Solana est déjà assez rapide, avec un volume suffisamment important. Alors, est-ce vraiment "suffisant" ?
Lorsque nous examinons ces transactions, une question persiste : ces transactions créent-elles vraiment de la valeur ?
Le volume important de Solana ne provient pas d'une réelle demande de trading, mais des arbitragistes haute fréquence qui tirent profit des différences d'information de l'ordre de la milliseconde. Ces "traders toxiques" (Toxic-takers) utilisent un avantage technologique pour augmenter le Gas juste avant que les market makers (Maker) ne retirent leurs ordres, permettant ainsi à leurs transactions d'être traitées en premier, réalisant des arbitrages et faisant subir des pertes aux market makers. Pour compenser ces pertes, les market makers n'ont d'autre choix que d'élargir l'écart entre les prix d'achat et de vente.
Finalement, ce sont les utilisateurs ordinaires qui en paient le prix. Solana a toujours eu le rêve de réaliser un carnet de commandes sur la chaîne, remplaçant les CEX. Mais cela signifie que les "traders toxiques" deviennent un obstacle à la réalisation de ce rêve. Voici le nouveau défi auquel Solana est confronté : volume ≠ liquidité. Un marché véritablement sain n'a pas besoin de plus de transactions, mais de meilleures transactions.
Comment peut-on éliminer les transactions toxiques pour mieux protéger la liquidité ?
Dans le système actuel, les preneurs (Takers) bénéficient d'une réelle priorité en raison du mécanisme d'enchères périodiques de consensus de Solana, ce qui affecte l'équité du marché en raison de l'impact malveillant du MEV.
Comment comprendre ?
Dans le consensus actuel de Solana, au sein de chaque période de Slot, les transactions sont triées selon les frais de Gas prioritaires payés ; celui qui offre le prix le plus élevé voit sa transaction exécutée en premier. Cette enchère est périodique, avec un Slot toutes les 400 millisecondes.
Au cours de ce processus, les teneurs de marché doivent ajuster fréquemment leurs cotations, annuler des ordres et en placer de nouveaux. Les prix du marché doivent être mis à jour immédiatement lors des fluctuations.
Les preneurs (Taker), en particulier les arbitragistes à haute fréquence, surveillent les différences de prix et passent immédiatement des ordres lorsqu'ils détectent une opportunité. Par conséquent, les arbitragistes peuvent réaliser des transactions en payant des frais plus élevés pour devancer les annulations. Cela entraîne souvent des "snipes" sur les teneurs de marché, qui subissent des pertes.
Pour un carnet de commandes DEX, le tri 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. C'est quelque chose que le consensus de Solana ne peut actuellement pas réaliser à un niveau microscopique.
Et au niveau des prix des oracles, c'est la même chose. Dans l'idéal, il faudrait d'abord mettre à jour le prix des oracles, puis exécuter les transactions qui dépendent de ce prix. Mais dans l'intervalle actuel de 400 millisecondes, le marché peut connaître des fluctuations brutales, ce qui peut entraîner des transactions au prix initial.
Pour les protocoles de prêt, il est préférable de d'abord ajouter une marge, puis de procéder à la liquidation.
Donc, il est préférable d'avoir un moyen permettant à différents protocoles de trier les transactions selon les besoins, c'est-à-dire l'exécution contrôlée par l'application (Application-Controlled Execution) que Solana souligne toujours.
BAM (Block Assembly Marketplace, marché d'assemblage de blocs) est la réponse de Solana.
BAM a construit une couche de tri, ou couche de prétraitement, entre l'application sur la chaîne Solana et le réseau principal.
Utiliser des environnements d'exécution de confiance (Trusted Execution Environments, TEEs) pour construire une boîte à sable de confidentialité, dans laquelle les transactions sont triées selon des règles de classement prédéfinies, ou FIFO (premier entré, premier sorti).
Mieux servir les carnets de commandes (CLOBs), les bourses de contrats perpétuels (Perpetual Exchanges) et les protocoles de dark pools.
Solana généralement le regroupement des transactions par rapport au mode BAM
Comment comprendre que BAM a construit une couche de tri entre les applications et la blockchain principale de Solana ? Commençons par une comparaison intuitive.
Processus de transaction normal de Solana,
1）L'utilisateur confirme la transaction dans le portefeuille,
2）Transaction envoyée au nœud RPC,
RPC envoie au Leader node du réseau principal Solana pendant la période actuelle du Slot,
Le Leader collecte les transactions du pool de transactions, les trie, les empaquette en blocs et les diffuse.
Vote des nœuds restants.
Si une application intègre BAM, le processus de transaction est le suivant,
L'utilisateur confirme la transaction dans le portefeuille,
2）Transaction envoyée au nœud RPC,
Transférer les transactions vers le réseau BAM et les trier dans la confidentialité TEE. Pendant ce processus, les nœuds peuvent ajouter des transactions supplémentaires via des plugins, comme la mise à jour des prix des oracles, puis générer des preuves,
Le paquet de données de transaction est soumis au nœud Leader du réseau principal Solana,
Lorsque le Leader collecte des transactions, il collecte des paquets de données BAM, les regroupe en blocs et les diffuse.
6）Vote des autres nœuds.
Donc, en réalité, BAM ne contredit pas le processus de consensus actuel de la chaîne principale Solana, mais agit plutôt comme une "option". BAM ne fonctionne pas directement sur la chaîne principale Solana, mais utilise ce qu'on appelle une méthode "hors chaîne" pour trier les transactions à l'avance, regrouper les transactions, puis les soumettre à la chaîne principale Solana.
BAM mode de tri des volumes
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 suivent strictement le tri FIFO (premier arrivé, premier servi).
Le cœur du modèle BAM comprend les points suivants :
Environnements d'exécution de confiance TEEs : vie privée et équité Utiliser des environnements d'exécution de confiance TEEs pour créer un environnement de confidentialité et trier les transactions. L'autre face de la vie privée s'appelle l'équité.
2）Système de plugins Plugin : Tri complexe Grâce au système de plugins, BAM permet aux applications de construire une logique de tri des transactions personnalisée. Et ce tri personnalisé ne signifie pas que les nœuds peuvent trier comme ils le souhaitent, mais qu'il est effectué selon des règles prédéfinies.
Le plan de plugin vise à réaliser un tri complexe des transactions tout en maintenant les garanties de sécurité de l'environnement TEE. Il est actuellement en phase de développement précoce.
Comme mentionné précédemment,
Pour un carnet de commandes DEX, l'ordre idéal devrait être d'exécuter d'abord tous les annulations, puis les nouvelles commandes, et enfin les transactions, en fonction des fluctuations de prix. C'est quelque chose que le consensus de Solana ne peut pas accomplir actuellement à un niveau microscopique.
Et au niveau des prix des oracles, c'est la même chose. Dans l'idéal, il faudrait d'abord mettre à jour le prix des oracles, puis exécuter les transactions qui dépendent de ce prix. Cependant, dans l'intervalle actuel de 400 millisecondes, le marché peut fluctuer de manière si violente que les transactions sont toujours exécutées au prix d'origine.
Pour les protocoles de prêt, il est préférable de d'abord fournir une garantie, puis de procéder à la liquidation. Cela réalise en fait la fonctionnalité de contrôle d'exécution de l'application ACE.
Alors, qu'est-ce que BAM a vraiment réalisé ?
Par exemple,
1）Protection de la liquidation des prêts
Pour les protocoles de prêt, après avoir détecté un risque de liquidation, il est prioritaire d'exécuter des opérations de complément de garantie, puis de procéder à un contrôle de liquidation.
Combinaisons de transactions atomiques
Pour DEX, mettez d'abord à jour le prix de l'oracle, puis exécutez les transactions qui dépendent de ce prix. S'il s'agit d'un DEX de contrat, les produits dérivés connexes peuvent également être réglés. Toutes les opérations ci-dessus sont effectuées dans la même fenêtre de temps.
Protection contre la volatilité des prix
Pour le DEX, détectez les ordres anormaux de grande taille, divisez les gros ordres en petites portions et exécutez-les par lots, afin de donner du temps au marché pour réagir et éviter le cycle de liquidation en chaîne ou l'arbitrage qui pourrait causer une spirale mortelle.
4）Protection des teneurs de marché
Un événement inattendu se produit, annulation de l'ordre en millisecondes, mise à jour du prix par l'oracle, le market maker remet des ordres. Évitez d'être victime d'arbitrage malveillant, réduisez l'écart de prix.
BAM devait initialement être lancé à la fin juillet.
De plus, avec le déploiement de BAM, l'expérience de trading sur Solana sera considérablement améliorée. BAM rendra l'expérience des applications sur le réseau principal de Solana plus proche de celle des CEX.
En résumé,
BAM apporte vérifiabilité, protection de la vie privée et programmabilité au processus de traitement des transactions de Solana, permettant aux développeurs de construire des livres de commandes à limitation centrale (CLOBs), des bourses de contrats perpétuels (Perpetual Exchanges), des pools sombres (Dark Pools) et d'autres infrastructures financières nécessitant un contrôle de tri, 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.
Interpréter le marché d'assemblage des blocs Solana BAM : lorsque la vitesse n'est plus la seule quête.
Solana est déjà assez rapide, avec un volume suffisamment important. Alors, est-ce vraiment "suffisant" ?
Lorsque nous examinons ces transactions, une question persiste : ces transactions créent-elles vraiment de la valeur ?
Le volume important de Solana ne provient pas d'une réelle demande de trading, mais des arbitragistes haute fréquence qui tirent profit des différences d'information de l'ordre de la milliseconde. Ces "traders toxiques" (Toxic-takers) utilisent un avantage technologique pour augmenter le Gas juste avant que les market makers (Maker) ne retirent leurs ordres, permettant ainsi à leurs transactions d'être traitées en premier, réalisant des arbitrages et faisant subir des pertes aux market makers. Pour compenser ces pertes, les market makers n'ont d'autre choix que d'élargir l'écart entre les prix d'achat et de vente.
Finalement, ce sont les utilisateurs ordinaires qui en paient le prix. Solana a toujours eu le rêve de réaliser un carnet de commandes sur la chaîne, remplaçant les CEX. Mais cela signifie que les "traders toxiques" deviennent un obstacle à la réalisation de ce rêve. Voici le nouveau défi auquel Solana est confronté : volume ≠ liquidité. Un marché véritablement sain n'a pas besoin de plus de transactions, mais de meilleures transactions.
Comment peut-on éliminer les transactions toxiques pour mieux protéger la liquidité ?
Dans le système actuel, les preneurs (Takers) bénéficient d'une réelle priorité en raison du mécanisme d'enchères périodiques de consensus de Solana, ce qui affecte l'équité du marché en raison de l'impact malveillant du MEV.
Comment comprendre ?
Dans le consensus actuel de Solana, au sein de chaque période de Slot, les transactions sont triées selon les frais de Gas prioritaires payés ; celui qui offre le prix le plus élevé voit sa transaction exécutée en premier. Cette enchère est périodique, avec un Slot toutes les 400 millisecondes.
Au cours de ce processus, les teneurs de marché doivent ajuster fréquemment leurs cotations, annuler des ordres et en placer de nouveaux. Les prix du marché doivent être mis à jour immédiatement lors des fluctuations.
Les preneurs (Taker), en particulier les arbitragistes à haute fréquence, surveillent les différences de prix et passent immédiatement des ordres lorsqu'ils détectent une opportunité. Par conséquent, les arbitragistes peuvent réaliser des transactions en payant des frais plus élevés pour devancer les annulations. Cela entraîne souvent des "snipes" sur les teneurs de marché, qui subissent des pertes.
Pour un carnet de commandes DEX, le tri 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. C'est quelque chose que le consensus de Solana ne peut actuellement pas réaliser à un niveau microscopique.
Et au niveau des prix des oracles, c'est la même chose. Dans l'idéal, il faudrait d'abord mettre à jour le prix des oracles, puis exécuter les transactions qui dépendent de ce prix. Mais dans l'intervalle actuel de 400 millisecondes, le marché peut connaître des fluctuations brutales, ce qui peut entraîner des transactions au prix initial.
Pour les protocoles de prêt, il est préférable de d'abord ajouter une marge, puis de procéder à la liquidation.
Donc, il est préférable d'avoir un moyen permettant à différents protocoles de trier les transactions selon les besoins, c'est-à-dire l'exécution contrôlée par l'application (Application-Controlled Execution) que Solana souligne toujours.
BAM (Block Assembly Marketplace, marché d'assemblage de blocs) est la réponse de Solana.
BAM a construit une couche de tri, ou couche de prétraitement, entre l'application sur la chaîne Solana et le réseau principal.
Utiliser des environnements d'exécution de confiance (Trusted Execution Environments, TEEs) pour construire une boîte à sable de confidentialité, dans laquelle les transactions sont triées selon des règles de classement prédéfinies, ou FIFO (premier entré, premier sorti).
Mieux servir les carnets de commandes (CLOBs), les bourses de contrats perpétuels (Perpetual Exchanges) et les protocoles de dark pools.
Solana généralement le regroupement des transactions par rapport au mode BAM
Comment comprendre que BAM a construit une couche de tri entre les applications et la blockchain principale de Solana ? Commençons par une comparaison intuitive.
Processus de transaction normal de Solana,
1）L'utilisateur confirme la transaction dans le portefeuille,
2）Transaction envoyée au nœud RPC,
RPC envoie au Leader node du réseau principal Solana pendant la période actuelle du Slot,
Le Leader collecte les transactions du pool de transactions, les trie, les empaquette en blocs et les diffuse.
Vote des nœuds restants.
Si une application intègre BAM, le processus de transaction est le suivant,
2）Transaction envoyée au nœud RPC,
Transférer les transactions vers le réseau BAM et les trier dans la confidentialité TEE. Pendant ce processus, les nœuds peuvent ajouter des transactions supplémentaires via des plugins, comme la mise à jour des prix des oracles, puis générer des preuves,
Le paquet de données de transaction est soumis au nœud Leader du réseau principal Solana,
Lorsque le Leader collecte des transactions, il collecte des paquets de données BAM, les regroupe en blocs et les diffuse.
6）Vote des autres nœuds.
Donc, en réalité, BAM ne contredit pas le processus de consensus actuel de la chaîne principale Solana, mais agit plutôt comme une "option". BAM ne fonctionne pas directement sur la chaîne principale Solana, mais utilise ce qu'on appelle une méthode "hors chaîne" pour trier les transactions à l'avance, regrouper les transactions, puis les soumettre à la chaîne principale Solana.
BAM mode de tri des volumes
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 suivent strictement le tri FIFO (premier arrivé, premier servi).
Le cœur du modèle BAM comprend les points suivants :
2）Système de plugins Plugin : Tri complexe Grâce au système de plugins, BAM permet aux applications de construire une logique de tri des transactions personnalisée. Et ce tri personnalisé ne signifie pas que les nœuds peuvent trier comme ils le souhaitent, mais qu'il est effectué selon des règles prédéfinies.
Le plan de plugin vise à réaliser un tri complexe des transactions tout en maintenant les garanties de sécurité de l'environnement TEE. Il est actuellement en phase de développement précoce.
Comme mentionné précédemment,
Pour un carnet de commandes DEX, l'ordre idéal devrait être d'exécuter d'abord tous les annulations, puis les nouvelles commandes, et enfin les transactions, en fonction des fluctuations de prix. C'est quelque chose que le consensus de Solana ne peut pas accomplir actuellement à un niveau microscopique.
Et au niveau des prix des oracles, c'est la même chose. Dans l'idéal, il faudrait d'abord mettre à jour le prix des oracles, puis exécuter les transactions qui dépendent de ce prix. Cependant, dans l'intervalle actuel de 400 millisecondes, le marché peut fluctuer de manière si violente que les transactions sont toujours exécutées au prix d'origine.
Pour les protocoles de prêt, il est préférable de d'abord fournir une garantie, puis de procéder à la liquidation. Cela réalise en fait la fonctionnalité de contrôle d'exécution de l'application ACE.
Alors, qu'est-ce que BAM a vraiment réalisé ?
Par exemple,
1）Protection de la liquidation des prêts
Pour les protocoles de prêt, après avoir détecté un risque de liquidation, il est prioritaire d'exécuter des opérations de complément de garantie, puis de procéder à un contrôle de liquidation.
Pour DEX, mettez d'abord à jour le prix de l'oracle, puis exécutez les transactions qui dépendent de ce prix. S'il s'agit d'un DEX de contrat, les produits dérivés connexes peuvent également être réglés. Toutes les opérations ci-dessus sont effectuées dans la même fenêtre de temps.
Pour le DEX, détectez les ordres anormaux de grande taille, divisez les gros ordres en petites portions et exécutez-les par lots, afin de donner du temps au marché pour réagir et éviter le cycle de liquidation en chaîne ou l'arbitrage qui pourrait causer une spirale mortelle.
4）Protection des teneurs de marché
Un événement inattendu se produit, annulation de l'ordre en millisecondes, mise à jour du prix par l'oracle, le market maker remet des ordres. Évitez d'être victime d'arbitrage malveillant, réduisez l'écart de prix.
BAM devait initialement être lancé à la fin juillet.
De plus, avec le déploiement de BAM, l'expérience de trading sur Solana sera considérablement améliorée. BAM rendra l'expérience des applications sur le réseau principal de Solana plus proche de celle des CEX.
En résumé,
BAM apporte vérifiabilité, protection de la vie privée et programmabilité au processus de traitement des transactions de Solana, permettant aux développeurs de construire des livres de commandes à limitation centrale (CLOBs), des bourses de contrats perpétuels (Perpetual Exchanges), des pools sombres (Dark Pools) et d'autres infrastructures financières nécessitant un contrôle de tri, 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.
C'est tout.