Block Assembly Marketplace (BAM)

Points clés exploitables

• Aujourd’hui, les leaders Solana sont seuls maîtres de l’ordre des transactions pendant leurs slots, avec peu de transparence sur la construction des blocs. BAM introduit une alternative vérifiable et décentralisée qui rend la logique de séquençage auditable.
• Le réseau BAM sépare clairement les responsabilités : les nœuds BAM gèrent la collecte, la priorisation et le filtrage des transactions Solana, tandis que les validateurs BAM prennent en charge l’exécution, le consensus et la gestion de l’état. Cette approche rapproche Solana d’une architecture de type Proposer-Builder Separation (PBS).
• Le framework de plugins de BAM permet aux développeurs de définir une logique d’ordonnancement personnalisée et d’introduire de nouvelles primitives de planification. Il rend possible l’Application-Controlled Execution (ACE), qui permet aux applications d’imposer leurs propres règles de planification des transactions.
• Jito s’est engagé à terme à publier BAM en open source et à placer la transparence au cœur de sa conception. Il s’agit d’une amélioration majeure par rapport au moteur de blocs Jito actuel, dont le code est fermé et qui est exploité par une seule entité de confiance.
• Les nœuds BAM fonctionneront sur des processeurs AMD compatibles avec Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP). Grâce à l’accélération matérielle, SEV-SNP n’entraîne qu’un surcoût de 2 à 5 %, suffisamment faible pour un traitement en temps réel.
• Le premier planificateur mis en œuvre pour les nœuds BAM organisera des enchères périodiques intra-bloc au sein de leurs mempools, en divisant le bloc en N slots et en répartissant équitablement les CU entre chaque enchère.
• L’Application-Controlled Execution (ACE) pourrait réduire le besoin de rollups ou d’extensions réseau pour imposer une logique personnalisée, ce qui contribuerait à maintenir davantage d’activité sur le mainnet Solana. Elle élargit également considérablement les possibilités de conception de nouvelles applications exploitant un espace de bloc programmable.
• Jito prévoit de reverser 100 % des frais de protocole issus à la fois du Block Engine et du futur système BAM au trésor de la DAO Jito. Actuellement, Jito prélève 6 % sur les pourboires, répartis à parts égales entre Jito Labs et la DAO. Au deuxième trimestre 2025, la DAO a perçu 22 391,31 SOL (~4 millions de dollars) grâce à ces frais via le Tip Router.
• BAM s’inspire de BuilderNet de Flashbots et adopte une approche similaire de construction de blocs au sein d’environnements d’exécution de confiance. Sur le mainnet Ethereum, environ 40 % des blocs sont déjà construits dans des TEE.

Introduction

Block Assembly Marketplace (BAM) de Jito représente la refonte la plus ambitieuse à ce jour du processus de construction des blocs de Solana. Après plus de huit mois de développement, BAM est né de la volonté d’apporter davantage de confidentialité, de transparence et de déterminisme à l’exécution intra-slot sur Solana afin de permettre la prochaine vague d’applications avancées. Il en résulte un pipeline de transactions repensé, qui remplace le modèle actuel d’ordonnancement opaque piloté par les validateurs par un système de séquençage des transactions privé, programmable et dont l’équité peut être prouvée.

BAM introduit une mempool chiffrée exécutée dans des Trusted Execution Environments (TEE), où toutes les transactions restent confidentielles jusqu’à leur exécution. Cette architecture respectueuse de la confidentialité vise à réduire considérablement, voire à éliminer, bon nombre des formes de MEV les plus extractives, tout en offrant aux utilisateurs de meilleures garanties d’exécution et de meilleurs prix. Les validateurs peuvent proposer une exécution de meilleure qualité, tandis que les développeurs et les searchers peuvent construire directement sur une nouvelle couche d’espace de bloc programmable.

BAM introduit une logique d’application-controlled execution (ACE) au moyen d’un système de plugins. Celle-ci permet des cas d’usage tels que l’appariement prioritaire pour les makers sur les contrats perpétuels, les mises à jour d’oracles juste à temps, l’application de la durée de validité des ordres et d’autres formes de routage et d’exécution personnalisés. Grâce à un contrôle précis de l’ordre des transactions, les développeurs peuvent créer sur Solana des primitives financières plus sophistiquées et fiables, notamment des carnets d’ordres à cours limité, des dark pools et des couches d’agrégation.

BAM répond ainsi directement à de nombreuses critiques de longue date visant le modèle de production de blocs de Solana : comportement opaque des validateurs, qualité d’exécution inégale et prolifération de marchés gris par le biais de mempools privées et d’accords hors bande. Aujourd’hui, les leaders Solana contrôlent unilatéralement l’ordre des transactions pendant leurs slots, sans grande visibilité sur l’assemblage final des blocs. BAM remplace ce modèle par une alternative vérifiable et décentralisée qui s’intègre parfaitement à l’environnement d’exécution haute performance de Solana.

BAM s’appuie sur des précédents concrets et s’inspire de BuilderNet de Flashbots, en adoptant une approche similaire de construction de blocs au sein d’environnements d’exécution de confiance. Sur le mainnet Ethereum, environ 40 % des blocs sont déjà construits dans des TEE, tandis que ce chiffre atteint 100 % sur Unichain, le L2 personnalisé d’Uniswap. BAM étend ce modèle à Solana, avec l’avantage d’une prise en charge native de la programmabilité au niveau des applications, d’une exécution à faible latence et d’une intégration étroite avec les clients de validation Jito, qui sécurisent aujourd’hui plus de 89 % du stake total via Jito-Agave et Jito-Firedancer.

Surtout, Jito s’est engagé à terme à publier BAM en open source et à placer la transparence au cœur de sa conception. Il s’agit d’une amélioration majeure par rapport au moteur de blocs Jito actuel, dont le code est fermé et qui est exploité par une seule entité de confiance. BAM génère des attestations on-chain, c’est-à-dire des preuves signées cryptographiquement qui confirment précisément le code exécuté et la manière dont les transactions ont été ordonnées, afin que tout observateur puisse vérifier l’équité de l’exécution.

Vue d’ensemble de BAM

BAM est fondamentalement un réseau de séquençage des transactions. Les nœuds BAM gèrent la collecte, la priorisation et le filtrage des transactions Solana, tandis que les validateurs BAM se concentrent sur l’exécution, le consensus et la gestion de l’état. Cette séparation des responsabilités conserve au sein du validateur les fonctions essentielles à la disponibilité du réseau, tout en offrant davantage de flexibilité et de possibilités d’expérimentation autour de la logique de séquençage dans les nœuds BAM.

Le nœud BAM lui-même comprend une unité de traitement des transactions (TPU) et un planificateur de transactions, exécutés dans un TEE. Il exécute également un serveur gRPC pour communiquer avec les validateurs connectés. Le client Jito-validator modifié intègre un exécuteur premier entré, premier sorti (FIFO), optimisé pour la concurrence et le parallélisme grâce à un verrouillage tenant compte des comptes.

Chaque nœud BAM peut prendre en charge plusieurs validateurs, mais chaque validateur ne se connecte qu’à un seul nœud BAM à la fois. Jito exploite actuellement sept moteurs de blocs. Avec BAM, le réseau vise un changement d’échelle important, avec 50 à plus de 100 nœuds BAM répartis dans toutes les grandes régions géographiques afin d’améliorer la décentralisation et la redondance. La communication entre le nœud BAM et le validateur s’effectue via un flux gRPC bidirectionnel, les résultats d’exécution étant renvoyés en continu du validateur au nœud BAM pour fournir un retour en temps réel.

Toutes les transactions au sein des nœuds BAM sont chiffrées dans des Trusted Execution Environments (TEE) jusqu’au moment de leur exécution, afin que le flux de transactions reste privé jusque-là.

Pour garantir l’équité de l’exécution, l’ordre des transactions est enregistré de manière vérifiable à l’aide d’attestations. Il s’agit de preuves cryptographiques, signées et horodatées par les nœuds BAM, qui confirment que des événements ou conditions spécifiques ont été observés. Le résultat est une piste d’audit immuable qui permet aux observateurs de prouver que les transactions ont été exécutées dans le bon ordre.

La piste d’audit comprend les transactions transmises au validateur et leur séquençage. Par exemple, elle peut indiquer que les transactions A, B et C ont été envoyées au validateur Helius pendant ce slot. Le système propose des outils de surveillance et d’analyse en temps réel, permettant aux utilisateurs de suivre leurs transactions de l’envoi à l’exécution. Les utilisateurs et les applications pourront vérifier si le validateur BAM a respecté l’ordre prévu et connaître précisément le code exécuté dans le nœud BAM.

Les nœuds BAM sont visibles de manière transparente sur le réseau, à l’instar des relais Jito existants. Lorsqu’un validateur se connecte à BAM, il annonce l’instance BAM par l’intermédiaire de ses ports TPU et de transfert TPU, qui servent de points d’entrée pour recevoir les transactions.

Les utilisateurs peuvent toujours envoyer des transactions par l’intermédiaire de leurs clients RPC habituels. Toutefois, pour renforcer la sécurité, ils peuvent envoyer les transactions directement aux instances BAM, empêchant ainsi les validateurs malveillants d’intercepter ou de consulter les paquets de transactions.

Lorsqu’une transaction entre dans BAM, elle passe par un processus standard d’assainissement comprenant la déduplication, la vérification de la signature et des contrôles portant sur la validité du format, du blockhash, du payeur des frais, du nonce et des Address Lookup Tables.

Une fois validées, les transactions entrent dans la mempool de BAM, où elles participent à une enchère périodique fréquente. À la fin d’une enchère, les transactions sont envoyées aux validateurs. La séquence complète des transactions est signée par le logiciel BAM et enregistrée dans une base de données. Les validateurs renvoient ensuite les résultats d’exécution en continu par l’intermédiaire d’une API conçue sur le modèle de celle proposée par le planificateur modulaire d’Anza.

Grâce à un environnement de planification sécurisé et à un marché local des frais, les validateurs sont désormais soumis à un contrat d’adhésion bien plus strict. Ils reçoivent une séquence prédéfinie de transactions qui doit être planifiée exactement telle qu’elle a été fournie, ce qui supprime toute possibilité d’insérer ou de réordonner des transactions à des fins malveillantes.

Plusieurs mécanismes d’application sont à l’étude pour répondre aux comportements fautifs des validateurs, comme le sandwiching, sur la base des éléments de la piste d’audit. Bien qu’elles ne soient pas encore finalisées, les réponses possibles comprennent :

• Exclure le validateur fautif du réseau BAM.
• Exiger des validateurs une garantie sous forme de cautions, qui pourraient être réduites en cas de faute, bien que cela puisse accroître les barrières à l’entrée pour les nouveaux validateurs.
• Appliquer des listes noires ou grises pour restreindre ou limiter partiellement la participation des contrevenants.

Frais

Jito Labs et la Jito Foundation rédigent conjointement une Jito Improvement Proposal (JIP) visant à rediriger vers le trésor de la DAO Jito 100 % des frais de protocole collectés à la fois par le Block Engine et par le futur système BAM. Cette proposition, qui devrait être officiellement soumise dans les prochaines semaines, représente une évolution majeure du modèle économique de Jito et devra être approuvée par la DAO. Si elle est adoptée, elle renforcera le rôle central de la DAO et des détenteurs de tokens JTO dans l’écosystème Jito.

Actuellement, le protocole Jito prélève 6 % sur les pourboires, répartis à parts égales entre Jito Labs et la DAO. Rien qu’au deuxième trimestre 2025, la DAO a perçu 22 391,31 SOL (~4 millions de dollars) grâce à ces frais via le Tip Router. L’autre principale source de revenus de la DAO provient des frais jitoSOL, qui ont totalisé 13 223,73 SOL (~2,38 millions de dollars) sur la même période.

Trusted Execution Environments (TEE)

Un Trusted Execution Environment (TEE) est une architecture reposant sur le matériel et conçue pour garantir la confidentialité et l’intégrité des calculs comme de la mémoire. Également appelés enclaves, les TEE isolent l’exécution du code du système d’exploitation, du noyau et de l’hyperviseur du système hôte, généralement au moyen d’une séparation au niveau matériel. Cette isolation réduit considérablement la surface d’attaque, ce qui rend extrêmement difficile, sans pour autant être impossible, l’observation ou la modification des opérations de l’enclave.

Les TEE sont utilisés depuis les années 2000 dans des domaines tels que la gestion des droits numériques, la protection des contenus et les systèmes de paiement sécurisés. Aujourd’hui, ils sont largement employés dans les appareils grand public et les services cloud pour traiter en toute sécurité des données et du code sensibles. Sur les smartphones et les ordinateurs portables, Secure Enclave d’Apple et TrustZone d’Android protègent les données biométriques, les identifiants de paiement et les clés de chiffrement. Les consoles de jeu telles que PlayStation et Xbox utilisent des processeurs AMD ou basés sur Pluton pour empêcher les altérations et le piratage. Dans le cloud, des fournisseurs comme Azure et Google Cloud s’appuient sur AMD SEV-SNP, Intel TDX ou AWS Nitro Enclaves pour isoler les charges de travail et permettre le calcul confidentiel. Les portefeuilles crypto tels que Ledger et Trezor utilisent des éléments sécurisés pour protéger les clés privées, tandis que le nouveau téléphone Solana Seeker s’appuie sur des TEE dans le même but.

Les TEE constituent l’approche matérielle standard pour traiter les données privées et offrent une alternative pratique aux méthodes purement cryptographiques, telles que le chiffrement entièrement homomorphe (FHE) et le calcul multipartite sécurisé (MPC). Bien que FHE et MPC offrent de solides garanties théoriques, ils sont souvent difficiles à utiliser en pratique en raison de leur grande complexité et de leur coût en performances.

BAM s’appuie sur deux propriétés fondamentales des TEE :

Confidentialité : le code et les données à l’intérieur du TEE sont chiffrés et isolés du reste du système. Ni le système d’exploitation, ni l’hyperviseur, ni aucun logiciel externe ne peut accéder aux éléments exécutés dans l’enclave ou les inspecter.

Attestabilité : les TEE prennent en charge les attestations, un mécanisme qui produit une preuve cryptographique de l’origine et de l’état actuel de l’enclave. Des tiers peuvent ainsi vérifier qu’un résultat a été produit par un véritable TEE exécutant du code de confiance, et non par un environnement compromis ou émulé.

Mise en œuvre des TEE dans BAM

BAM fonctionnera sur des processeurs AMD compatibles avec Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP). Contrairement aux approches reposant sur des enclaves plus petites, SEV-SNP protège l’ensemble de l’application BAM avec un coût en performances minime, ce qui le rend particulièrement adapté aux systèmes de transactions à haut débit et à faible latence.

Grâce à l’accélération matérielle, SEV-SNP n’entraîne qu’un surcoût de 2 à 5 %, suffisamment faible pour un traitement en temps réel. Il peut prendre en charge des applications réseau complexes et avec état, et pas uniquement des calculs isolés. Cette technologie a fait ses preuves avec des déploiements auprès de grands fournisseurs cloud, notamment Google Cloud, Azure et AWS, et bénéficie de plusieurs années de recherche en sécurité et d’expérience opérationnelle.

SEV-SNP, utilisé dans BAM, fournit plusieurs garanties de sécurité essentielles. Chaque instance TEE s’exécute dans sa propre machine virtuelle isolée par le matériel, avec une mémoire chiffrée à l’exécution pour garantir une forte isolation au niveau de la VM. BAM s’appuie sur une attestation ancrée dans le matériel, qui permet à chaque TEE de prouver cryptographiquement qu’il exécute un code authentique et non modifié. Cette chaîne d’attestation est ancrée dans les clés racines matérielles d’AMD, physiquement intégrées au CPU lors de sa fabrication. De plus, les clés TLS sont générées à l’aide du générateur matériel interne de nombres aléatoires du processeur, ce qui garantit qu’elles ne sont jamais exposées dans une mémoire non chiffrée.

Lorsqu’un client se connecte à BAM, il reçoit un certificat TLS contenant le certificat de connexion standard, un rapport d’attestation AMD SEV-SNP et une preuve cryptographique que la clé privée TLS a été générée dans le TEE attesté. Cette chaîne de certificats est liée cryptographiquement à la racine de confiance matérielle d’AMD. Elle ne peut pas être falsifiée sans accès aux clés racines privées d’AMD, ce qui élimine le besoin de faire confiance à un intermédiaire au-delà du processus de fabrication des puces d’AMD.

Plugins

Aujourd’hui, les applications sur Solana ne peuvent influencer l’ordre des transactions qu’au moyen des frais de priorité ou de transactions regroupées accompagnées de pourboires. Avec plusieurs séquenceurs en jeu dans des clients comme Agave et Firedancer, rien ne garantit la logique d’ordonnancement qui sera appliquée. Les applications disposent donc d’un contrôle limité sur l’ordre de leurs transactions.

Les plugins résolvent ce problème. 

Grâce au framework de plugins de BAM, les développeurs peuvent mettre en œuvre une logique d’ordonnancement sur mesure et introduire de nouvelles primitives de planification. Ces plugins permettent l’Application-Controlled Execution (ACE), qui autorise les applications à définir des politiques personnalisées de planification des transactions. L’ACE offre de nombreux cas d’usage potentiels, mais le plus connu et le plus discuté est la priorité accordée aux annulations dans les carnets d’ordres, un mécanisme qui réduit la sélection adverse et permet de resserrer les spreads.

Priorité aux annulations des makers dans les carnets d’ordres

Aujourd’hui, les teneurs de marché des carnets d’ordres on-chain sur Solana sont désavantagés. Les teneurs de marché gèrent le risque en mettant constamment à jour ou en annulant les cotations obsolètes lorsque le juste prix évolue. Lorsque le prix du marché change, ils doivent annuler les ordres existants avant que des takers informés puissent profiter de l’occasion.  

Sans contrôle précis de l’ordre des transactions, leurs cotations sont exposées à un flux toxique qui exploite leurs prix obsolètes. Les teneurs de marché peuvent subir des pertes même lorsqu’ils réagissent rapidement, car les enchères Jito donnent la priorité aux offres plutôt qu’à l’intention. En pratique, la partie qui paie le plus est séquencée en premier.

Cette dynamique contraint les teneurs de marché à élargir leurs spreads pour gérer le risque, ce qui réduit la liquidité globale et dégrade les prix proposés aux utilisateurs. Ces transactions toxiques, dans lesquelles le taker tire profit d’un prix obsolète et la contrepartie regrette presque immédiatement la transaction, apportent peu à l’expérience utilisateur, mais accroissent considérablement les frictions pour les teneurs de marché et les fournisseurs de liquidité.

Les plugins BAM permettent d’appliquer au niveau de l’application des politiques de type « annuler avant de prendre ». En donnant aux programmes un contrôle précis de l’ordre des transactions, les applications peuvent choisir de traiter les annulations des makers avant les transactions des takers. Ce simple changement de politique a des conséquences majeures :

• Réduit la sélection adverse : les makers ne sont plus systématiquement pris à revers lorsque le marché évolue.
• Filtre les flux toxiques : même si le volume global peut diminuer en raison de la baisse du nombre de transactions toxiques, la qualité du flux et de l’exécution s’améliore.
• Permet de resserrer les spreads : avec un risque réduit, les makers peuvent proposer des cotations plus agressives.
• Améliore la liquidité : les makers professionnels comme les traders particuliers ont davantage confiance pour proposer des cotations, ce qui renforce la profondeur de la liquidité.

Mises à jour des oracles juste à temps

La mise en œuvre prévue par Pyth de mises à jour d’oracles juste à temps constitue un autre exemple de plugin propre à une application. En tant que principal fournisseur d’oracles de Solana, Pyth gère plus de 1 700 flux de prix individuels. Tous les mettre à jour à chaque bloc serait extrêmement coûteux et inefficace en matière d’espace de bloc.

Avec BAM, Pyth peut mettre à jour des flux de prix spécifiques exactement au moment où ils sont nécessaires, en insérant la mise à jour de l’oracle juste avant la transaction d’un utilisateur au sein du même bloc. Cela réduit les risques liés à l’obsolescence des données d’oracle, tels que les liquidations inefficaces et la manipulation des oracles, et permet aux applications DeFi de fonctionner de manière plus fiable et compétitive.

Autres plugins

À terme, BAM vise à devenir une plateforme sans permission sur laquelle les développeurs d’applications pourront créer, tester et déployer des plugins pour contrôler le séquençage de leurs transactions. De nombreux autres plugins devraient suivre, et les nœuds BAM finiront par prendre en charge des centaines d’extensions personnalisables. Si la plupart des applications continueront à utiliser le planificateur par défaut, celles qui ont besoin d’une logique de séquençage personnalisée devront développer et maintenir leurs propres plugins. 

En outre, les applications pourront monétiser les fonctionnalités des plugins en facturant des frais, avec la possibilité de partager une partie des revenus avec les détenteurs de tokens de gouvernance ou les validateurs.

Plugins généralistes envisagés

Les plugins ne sont pas limités à une seule application. Jito a déjà proposé plusieurs exemples de plugins généralistes et inter-applications qui pourraient être développés pour BAM :

Contrats à terme sur l’espace de bloc : permettent aux utilisateurs et aux applications de réserver ou de négocier le droit d’utiliser de l’espace de bloc à une date ultérieure, afin de bénéficier d’un accès et de tarifs prévisibles même pendant les périodes de forte demande sur le réseau.

Durée de validité (TIF) : désigne la période pendant laquelle un ordre reste actif avant d’être automatiquement annulé s’il n’est pas entièrement exécuté. Il serait par exemple possible de limiter la validité d’une transaction de carnet d’ordres à 20 millisecondes. Une version rudimentaire de ce mécanisme est aujourd’hui possible sur Solana en utilisant délibérément d’anciens blockhashes afin qu’une transaction ne soit valide que pour le ou les blocs les plus récents.

Préconfirmations : les utilisateurs peuvent être avertis lorsque leur transaction est transmise à un validateur, avant qu’elle ne soit exécutée et propagée sur le réseau. Cela permet de confirmer plus tôt les transactions avec un certain niveau de confiance.

Transactions sans frais : permettent aux utilisateurs de couvrir les coûts des transactions avec un token SPL, par exemple des stablecoins, plutôt qu’avec SOL. Elles masquent ainsi les exigences liées au token natif et offrent un paiement flexible des frais.

Agrégateur à faible latence et demande de cotation (RFQ) : les utilisateurs envoient leurs intentions de transaction directement à BAM, où un agrégateur exécuté localement détermine l’itinéraire optimal.

Annulation et remplacement de transactions : les utilisateurs peuvent envoyer des transactions comportant des marqueurs spéciaux qui leur permettent d’annuler, d’abandonner ou de remplacer des transactions précédemment envoyées.

Déploiement

Pendant la phase de lancement, Jito Labs exploitera le premier ensemble de nœuds BAM afin de garantir la stabilité, les performances et la sécurité. Un groupe autorisé de premiers validateurs partenaires, comprenant Helius, SOL Strategies, Triton One et Figment, exécutera le client BAM et sécurisera peu après le lancement un pourcentage élevé à un chiffre du stake total du réseau. 

En parallèle, un premier groupe d’applications Solana, comprenant Drift, Pyth et DFlow, commencera à concevoir et à tester la première vague de plugins. À la fin de la phase de lancement, BAM devrait avoir validé ses fonctionnalités essentielles et posé les bases d’une participation plus large des opérateurs de nœuds et des validateurs. 

Les validateurs, les développeurs d’applications ou les searchers souhaitant participer à BAM peuvent remplir ce formulaire.

Un comité consultatif de l’écosystème, composé d’acteurs majeurs de la communauté des validateurs et des développeurs Solana, dont la Solana Foundation, conseillera Jito Labs. Ce comité contribuera à orienter l’expansion de BAM, à promouvoir la décentralisation et à encourager l’innovation portée par la communauté.

À ce jour, le code source de BAM reste fermé, mais il est prévu de l’ouvrir prochainement afin de permettre le développement de plugins tiers. Une fois BAM publié en open source, les contributions de la communauté seront les bienvenues dans plusieurs domaines clés :

• Développement de plugins : créer des plugins personnalisés pour étendre les capacités de BAM.
• Algorithmes de planification : concevoir et proposer de nouvelles stratégies d’ordonnancement des transactions adaptées à des cas d’usage spécifiques.
• Bibliothèques d’intégration : développer des SDK dans plusieurs langages de programmation afin de simplifier l’intégration de BAM.
• Outils d’analyse : créer des tableaux de bord et des systèmes de surveillance qui exploitent les données d’attestation de BAM.
• Contributions à la recherche : proposer et mettre en œuvre de nouvelles approches pour atténuer le MEV et optimiser le système.

Implications

BAM représente un tournant décisif pour Solana, susceptible de libérer une vague d’innovation en répondant aux préoccupations liées à l’exploitation de la MEV et à l’optimisation du remplissage des blocs. Le séquençage sécurisé par TEE et le framework de plugins de BAM pourraient réduire l’intérêt, pour les équipes applicatives, de créer des extensions réseau, des rollups ou des environnements Solana permissionnés afin d’imposer leur propre logique ou leur propre conception de l’espace de bloc, ce qui permettrait de maintenir davantage d’activité sur le mainnet de Solana. En outre, avec l’augmentation des limites de calcul par bloc et la demande croissante de programmes de tokens et de frameworks plus efficaces utilisant moins de CU (par exemple, la popularité grandissante de Pinocchio et de p-token), la bande passante disponible sur le mainnet augmentera, ce qui réduira encore l’intérêt pour les développeurs de créer des solutions personnalisées.

Les fonctionnalités de confidentialité de BAM devraient également réduire considérablement la fréquence des attaques sandwich, car les transactions restent masquées jusqu’à leur exécution, limitant ainsi la capacité des bots à devancer les utilisateurs. Cela devrait améliorer l’efficacité des DEX et offrir des prix plus compétitifs aux utilisateurs. Il est toutefois peu probable que BAM élimine entièrement la MEV. La MEV est par nature un jeu du chat et de la souris, et les opérateurs d’attaques sandwich s’adapteront, peut-être au moyen d’exploitations subtiles de plugins ou en manipulant des oracles externes (c’est-à-dire des oracles qui ne disposent pas de leur propre plugin), puisque ceux-ci ne font pas partie du pipeline chiffré. 

La réduction de la MEV grâce à BAM pourrait affecter négativement les revenus de Jito, comme lors de la fermeture de son mempool en 2024, qui a réduit ses revenus à court terme, mais a finalement profité au réseau. Les améliorations apportées par BAM pourraient compenser cet effet en stimulant le volume global des transactions et les frais de plugins, augmentant ainsi les revenus à long terme grâce à une meilleure adoption. Toutefois, la mise en œuvre exacte de BAM, son déploiement progressif et son modèle économique présentent des risques potentiels de centralisation et soulèvent des questions que nous examinons dans les sections suivantes. Ces risques et questions sont néanmoins contrebalancés par différents avantages, chacun ayant ses propres implications concernant la redistribution de la MEV, la PBS et le développement d’un « nouveau » client.

Redistribution de la MEV

BAM transforme fondamentalement le paysage de la MEV sur Solana, en passant d’une extraction incontrôlée à un modèle de redistribution plus structuré. Dans les configurations traditionnelles, la MEV capte souvent de la valeur au détriment des utilisateurs par le frontrunning ou le spam, les validateurs ou les bots s’appropriant cette valeur au moyen de pratiques nuisibles telles que les attaques sandwich. Le mempool de BAM, chiffré par TEE, masque toutefois les transactions jusqu’à leur exécution, ce qui limite la visibilité nécessaire à la MEV négative. La valeur est plutôt internalisée au moyen de plugins et d’un séquençage personnalisé. Cela permet aux applications, aux développeurs et aux searchers de capter des formes positives de MEV qui améliorent l’efficacité de l’écosystème (par exemple, des spreads DeFi plus serrés et une réduction du spam des oracles).

Cette redistribution réinjecte les bénéfices de la MEV vers ses parties prenantes, car les frais de plugins sont partagés entre les opérateurs de BAM Nodes, les validateurs, les stakers et la DAO de Jito. Cela pourrait créer des sources de revenus durables. Par exemple, un DEX pourrait disposer d’un plugin qui optimise l’appariement des ordres et convertit la MEV potentiellement extraite par les validateurs en frais générés par l’application, lesquels pourraient être redistribués aux détenteurs de tokens. Cette approche « protégée » des activités de trading pourrait transformer la MEV, actuellement un jeu à somme nulle, en un mécanisme qui renforce la liquidité et attire les capitaux institutionnels.

Cette redistribution comporte toutefois des risques. Il est important de souligner que BAM ne supprime pas la MEV : il la déplace. Ce déplacement pourrait permettre aux premiers auteurs de plugins, aux opérateurs de BAM Nodes et aux entités liées à Jito d’accumuler des gains disproportionnés. Bien que ces acteurs soient contraints par des attestations cryptographiques, l’apparition de vulnérabilités des TEE (par exemple, des attaques par canal auxiliaire) pourrait offrir aux searchers un accès privilégié et ouvrir de nouveaux vecteurs d’extraction subtils, compromettant ainsi les garanties de confidentialité. Cela ouvre également la voie à des formes « protégées » de backrunning, dans lesquelles les searchers peuvent déployer du code pour ajouter des transactions après celle d’un utilisateur (par exemple, afin de capter une opportunité d’arbitrage issue d’un swap modifiant le prix), sans révéler leurs stratégies ni permettre le frontrunning. De plus, en l’absence de slashing programmatique, des attaquants adaptatifs pourraient mettre en œuvre des stratégies nuisibles autour des attestations, qui interviennent après l’exécution et reposent actuellement sur l’application des règles par la communauté.

En définitive, si la redistribution de la MEV fait de BAM un catalyseur de l’objectif ultime de Solana (à savoir, un NASDAQ décentralisé), sa réussite dépend de l’adoption de modèles de frais équitables et d’une sécurité TEE robuste. Une mauvaise mise en œuvre pourrait fragmenter le réseau, éroder la confiance des utilisateurs et susciter des interrogations sur les activités « protégées », mais opaques, des searchers.

Séparation entre proposant et constructeur (PBS)

La plupart des blockchains sont conçues de sorte qu’une même entité propose et construise les blocs, ce qui lui confère un contrôle monopolistique sur l’ordre et l’inclusion des transactions dans les slots qui lui sont attribués. Cette situation avantage ces entités, qui peuvent librement censurer ou manipuler les flux de transactions. Elles pourraient, par exemple, proposer et construire des blocs en recourant à des stratégies sophistiquées, mais nuisibles, afin d’inclure les transactions dans un ordre précis et de maximiser ainsi la MEV.

La séparation entre proposant et constructeur (Proposer-Builder Separation, PBS) est un modèle de conception qui résout ce problème en dissociant la construction des blocs de leur proposition. Dans ce modèle, les constructeurs de blocs créent des listes ordonnées de transactions et soumettent des offres pour ces blocs. Les proposants de blocs, généralement des validateurs, acceptent et valident ensuite le bloc associé à l’offre la plus élevée, redistribuant la MEV par l’intermédiaire d’enchères ou de pourboires sans devoir eux-mêmes exécuter des stratégies de séquençage sophistiquées. 

La PBS est mise en œuvre hors protocole sur Ethereum au moyen de MEV-Boost depuis The Merge en 2022. MEV-Boost est un « sidecar » exécuté parallèlement aux deux logiciels clients d’un validateur, l’un pour la couche d’exécution et l’autre pour la couche de consensus. Les validateurs exécutant MEV-Boost peuvent se connecter à plusieurs relais et accepter des blocs préconstruits provenant de constructeurs de blocs. Ils ne voient pas le contenu d’un bloc avant son inclusion on-chain, car les relais ne leur transmettent que le montant de la récompense et l’en-tête du bloc. Il convient de noter que cette conception fait encore l’objet de recherches actives, car la PBS attend son intégration complète au protocole (ePBS), qui pourrait inclure des fonctionnalités telles que des listes d’inclusion afin d’atténuer davantage la censure.

Avec BAM, Solana s’oriente vers un avenir proche de la PBS, qui sépare la construction des blocs (c’est-à-dire le séquençage dans des BAM Nodes sécurisés par TEE) de l’exécution, laquelle reste du ressort des validateurs. Cela pourrait démocratiser les formes positives de MEV pour les applications et les searchers grâce aux plugins. Toutefois, ce modèle risque aussi d’accentuer la centralisation du stake de Solana si l’économie des plugins favorise les acteurs établis. Ce phénomène est manifeste sur Ethereum, où trois constructeurs (à savoir Titan Builder, BuilderNet et Beaverbuild) dominent désormais plus de ~90 % de l’ensemble des blocs, ce qui crée des problèmes de confiance envers les relais et des barrières pour les plus petits participants. 

Bien que MEV-Boost ait introduit la PBS sur Ethereum, BuilderNet constitue ici une comparaison plus pertinente. Il s’agit d’un réseau décentralisé de construction de blocs lancé en novembre 2024 et exploité par Flashbots, Beaverbuild et Nethermind. BuilderNet utilise des TEE pour construire des blocs de manière privée, ce qui décentralise le processus entre plusieurs opérateurs de nœuds afin de neutraliser les accords exclusifs sur les flux d’ordres et de réduire la centralisation. Le réseau privilégie la création de valeur (c’est-à-dire le partage des remboursements de MEV avec les fournisseurs de flux excédentaires, comme les utilisateurs, les wallets et les applications) plutôt que la concurrence pour les flux d’ordres (par exemple, la course aux accords privés). BuilderNet utilise toujours les relais de MEV-Boost, mais ceux-ci ne sont pas strictement indispensables, ce qui permet aux constructeurs et aux proposants d’interagir directement dans des TEE. 

Le déploiement progressif et permissionné de BAM doit donner la priorité à des frais équitables et à des plugins open source afin d’éviter ces écueils rencontrés par Ethereum. Cela est d’autant plus important en raison de sa dépendance au matériel (les TEE, par opposition aux relais logiciels d’Ethereum), qui entraîne des risques de dépendance envers les fournisseurs et des coûts de maintenance. Solana espère éviter la concurrence pour les flux d’ordres et passer directement à un système semblable à BuilderNet, axé sur la création de valeur. 

En définitive, cette évolution de la construction et de la proposition des blocs réduit le rôle des validateurs en leur retirant la complexité du séquençage, mais risque aussi de limiter leur autonomie et leurs revenus si les frais ne sont pas largement partagés. Nous approfondissons ce sujet dans la section intitulée Le rôle réduit des validateurs.

Ci-dessus : comparaison entre la PBS d’Ethereum et BAM de Solana

L’émergence d’un « nouveau » client

Le client Jito-Agave reproduit fidèlement la base de code principale d’Agave et s’en distingue principalement par l’ajout de fonctionnalités de MEV. Le modèle « Agave plus MEV » de Jito a permis à son client de s’intégrer facilement à l’écosystème existant des validateurs de Solana, augmentant les récompenses tout en réduisant au minimum les modifications apportées à l’architecture de base. Le client Jito-Agave domine donc désormais le réseau avec un taux d’adoption de 79 % parmi les validateurs au moment de la rédaction. Les validateurs peuvent ainsi s’appuyer sur la logique fondamentale d’Agave tout en profitant des sources de revenus supplémentaires de Jito.

BAM marque une rupture avec l’approche antérieure de Jito, qui consistait à reproduire fidèlement Agave. L’introduction d’un réseau dédié de BAM Nodes établit une nouvelle couche d’infrastructure. Cette évolution fait passer Jito du statut de simple « Agave amélioré » à celui de client plus distinct, doté de son propre écosystème programmable pour intégrer une logique propre aux applications.

Cette divergence apparaît clairement dans les prochaines interfaces de scheduler d’Agave, annoncées par Anza en mai. Les implémentations de schedulers personnalisés sont de plus en plus courantes à mesure que la MEV gagne en maturité sur Solana. Si les schedulers personnalisés peuvent accroître les revenus de leurs opérateurs, leurs implémentations actuelles présentent plusieurs inconvénients, notamment la nécessité d’exécuter un binaire correspondant à une autre version du validateur, la dépendance à du code source fermé et de potentiels problèmes de disponibilité. 

Les prochaines interfaces de scheduler d’Anza introduisent de la modularité en permettant aux validateurs de se connecter à des services externes de construction de blocs sans modifier le binaire principal du validateur, ce qui permet de prendre en charge des schedulers personnalisés. Cette conception favorise la transparence, la sécurité et la simplification du DevOps. Cependant, BAM dispense les utilisateurs de Jito d’utiliser ces interfaces, puisque le séquençage est géré en amont par le scheduler du BAM Node. BAM contourne ainsi les interfaces de scheduler prévues par Agave, ce qui pourrait simplifier les opérations, mais soulève des questions sur une éventuelle fragmentation future de l’écosystème en raison de l’écart avec les efforts de normalisation d’Anza (par exemple, en compliquant les intégrations de Firedancer).

Jito présente toutefois BAM comme un élément d’un client de validation unifié. Les validateurs BAM exécuteront une version mise à jour du client Agave qui intègre le scheduler de BAM et n’accepte que les transactions transmises par les BAM Nodes dans l’ordre FIFO. Cette conception évite la fragmentation des clients tout en renforçant la résilience du système. Jito prévoit de publier son client compatible avec BAM avant le déploiement du scheduler modulaire d’Anza. Cette décision souligne le double impact de BAM : il stimule l’innovation et fait progresser l’infrastructure MEV de Solana, mais risque également de renforcer davantage la position de Jito en tant que client de validation dominant.

Il est également possible que BAM utilise ces interfaces. Si BAM fonctionne au sein du scheduler modulaire, la prise en charge de Firedancer devient triviale et une nouvelle question se pose : Jito a-t-il réellement besoin d’un client de validation ? Seul l’avenir le dira, alors que nous attendons l’implémentation open source et le déploiement de BAM.

Questions en suspens

Le rôle réduit des validateurs

La conception de BAM transforme fondamentalement le paysage des validateurs de Solana en transférant le séquençage des transactions à un réseau distinct de BAM Nodes sécurisés par TEE. Les validateurs restent ainsi principalement responsables de l’exécution, du consensus et de la gestion de l’état. Cette séparation profite aux applications, car elle permet un séquençage personnalisé et offre des possibilités de partage des revenus avec les détenteurs de tokens. Elle profite également aux utilisateurs en réduisant la MEV négative et en proposant des prix plus avantageux. Elle soulève toutefois des questions concernant la réduction de l’autonomie des validateurs et de leurs incitations économiques.

Lorsqu’ils produisent des blocs en tant que leaders, les validateurs disposent actuellement d’une totale liberté pour ordonner les transactions, ce qui leur permet d’exécuter des schedulers personnalisés afin d’optimiser leurs blocs comme ils l’entendent. BAM retire cette responsabilité aux validateurs. Ceux-ci reçoivent désormais des transactions préséquencées qu’ils doivent exécuter dans un ordre FIFO strict, perdant ainsi leur autonomie sur la construction des blocs. Dans le cas le plus extrême, si toutes les transactions passent par BAM, les validateurs deviennent de simples « chambres d’enregistrement », ce qui remet en question la nécessité même de disposer de validateurs décentralisés. 

Des facteurs compensatoires existent toutefois. Les frais de plugins créent notamment de nouvelles sources de revenus partagées avec les validateurs et les stakers. Le client unifié de BAM et ses mécanismes de repli automatisés alignent les intérêts individuels sur la santé du réseau, améliorant ainsi sa résilience globale. Le déploiement progressif et facultatif préserve également la liberté de choix, tandis que le passage à l’open source à long terme permet aux validateurs de participer au développement de BAM, favorisant les améliorations portées par la communauté et préservant certains aspects de leur autonomie. Les validateurs pourront également proposer des améliorations du scheduler à BAM, ce qui pourrait leur permettre de percevoir des frais sur des volumes plus élevés. En outre, l’idée selon laquelle les validateurs ne seraient que de simples chambres d’enregistrement est probablement exagérée, puisqu’ils jouent toujours un rôle essentiel dans le consensus et le choix des forks. La véritable question est la suivante : quel degré d’autonomie les validateurs perdront-ils réellement ? BAM pourrait-il au contraire leur permettre de mieux se concentrer sur la disponibilité et l’intégrité de l’état ?

Plusieurs questions restent en suspens :

• Comment les validateurs peuvent-ils se différencier au-delà du matériel et de la disponibilité si les BAM Nodes gèrent le séquençage et l’extraction de la MEV ? 
• Dans un scénario d’adoption élevée, le rôle des validateurs limité à l’exécution réduira-t-il la décentralisation globale de Solana et, si oui, quelles métriques permettraient de mesurer cette réduction ?
• Si BAM pousse les validateurs à explorer des voies plus malveillantes pour générer des revenus, quelles mesures de protection, au-delà des attestations, peuvent empêcher ce phénomène sans réduire davantage les incitations ?
• Des vulnérabilités des TEE ou des exploitations de plugins pourraient-elles entraîner des sanctions injustes à l’encontre des validateurs ? 
• En s’appuyant sur l’expérience d’Ethereum avec la PBS, que peut faire Solana pour contrer la réduction de l’autonomie des validateurs ?

Opérateurs de nœuds malveillants

L’architecture de BAM introduit de nouvelles hypothèses de confiance concernant les validateurs. Elle suppose notamment que les validateurs n’agiront pas de manière malveillante lors de leurs interactions avec les BAM Nodes, par exemple en altérant les transactions préséquencées ou en divulguant des données. Lors de son lancement, BAM reposera sur un ensemble permissionné d’opérateurs en raison des limites des TEE. Cet ensemble permissionné sera chargé d’exécuter une version mise à jour du client Jito-Solana et de traiter fidèlement les transactions transmises. Ces validateurs devront faire confiance aux BAM Nodes pour ne pas manipuler les flux entrants, ce qui crée une confiance à deux niveaux (les BAM Nodes avant le TEE et les validateurs après le TEE) et augmente le risque dans une configuration permissionnée. La question essentielle est la suivante : qu’est-ce qui empêche les opérateurs de BAM Nodes d’examiner les transactions avant leur arrivée dans le TEE ? La réponse réside dans le chiffrement QUIC pour les nœuds vérifiés : ils intégreront l’attestation dans le certificat QUIC. Une autre façon de vérifier l’honnêteté des BAM Nodes consiste à comparer leurs hash avec le dépôt open source de BAM afin de déterminer si un BAM Node donné exécute bien le logiciel qu’il prétend exécuter. En supposant que personne n’ait compromis le TEE, les certificats QUIC du TPU seront générés à l’intérieur du TEE. Tout le trafic entrant et sortant sera donc chiffré.

La censure et la manipulation sélective des paquets de transactions aux points d’entrée et de sortie du réseau constituent toutefois des préoccupations importantes. Les opérateurs malveillants conservent des capacités de censure significatives, même s’ils ne peuvent pas consulter les détails des transactions chiffrées. Ils pourraient identifier les types de protocoles à partir des signatures TLS, appliquer des filtres selon les endpoints de connexion, effectuer des analyses temporelles pour repérer certains schémas et bloquer toutes les données chiffrées correspondant à certaines caractéristiques. L’opérateur malveillant peut donc ignorer la nature exacte des transactions transmises, tout en étant capable de supprimer des paquets en fonction des métadonnées et de certains schémas de trafic. Pour atténuer ce risque, les capacités de filtrage et d’horodatage des paquets de DoubleZero pourraient renforcer la transparence. En définitive, l’atténuation des attaques de censure du réseau constitue une raison valable d’opter pour un déploiement permissionné.

L’accès physique introduit également de nouvelles hypothèses de confiance, car il constitue presque toujours une faille de sécurité, et les TEE ne font pas exception. Bien que les TEE offrent de solides garanties de sécurité, ils peuvent tout de même être compromis si un attaquant obtient un accès physique au serveur. Des partenariats exclusifs avec des fournisseurs conformes à la norme SOC 2 contribueront à atténuer ce risque en garantissant une sécurité robuste et multicouche au niveau du centre de données.

Plusieurs questions restent en suspens :

• Si un opérateur malveillant censure des paquets ou divulgue des données, comment les règles seront-elles appliquées ?
• Pendant la phase permissionnée, comment la sélection des opérateurs évitera-t-elle la collusion et quelles métriques permettront de mesurer les progrès vers la décentralisation ? 

Composabilité et interaction entre les plugins

L’une des principales questions en suspens concernant BAM porte sur la manière dont les plugins interagiront concrètement entre eux. Une même transaction peut dépendre simultanément de plusieurs plugins, par exemple d’un plugin d’oracle pour obtenir des mises à jour de prix juste à temps, d’un plugin de DEX pour déterminer les routes de swap optimales et d’un plugin de token pour gérer certains comportements propres aux tokens SPL. Il est essentiel de garantir que ces composants fonctionnent ensemble de manière prévisible et sécurisée.

Pour fonctionner efficacement, les plugins peuvent avoir besoin de récupérer des données externes. Cela crée toutefois une surface d’attaque potentielle, car des plugins malveillants pourraient détourner des appels externes afin de divulguer des informations sensibles sur les transactions. Il est essentiel de définir des limites strictes quant aux données auxquelles les plugins peuvent accéder et qu’ils peuvent partager afin de préserver la confiance dans le système.

L’interaction entre la logique des plugins au niveau applicatif et les mécanismes de frais de Solana ajoute une couche de complexité. Comment l’ordre d’exécution des plugins, les pourboires Jito et les frais de priorité interagissent-ils lorsque plusieurs plugins cherchent à influencer la construction des blocs ? Ces dynamiques économiques doivent être clairement définies et appliquées de manière transparente afin d’éviter toute manipulation ou utilisation abusive involontaire.

Afin de gérer ces risques, le déploiement des plugins BAM devrait commencer dans un environnement permissionné. Cela permettra d’expérimenter et d’auditer le comportement des plugins à un stade précoce avant d’évoluer progressivement vers un modèle sans permission.

Confiance envers les TEE et responsabilité

Le recours aux TEE introduit de nouvelles hypothèses de confiance, car il utilise une enclave matérielle spéciale au lieu de créer un système sans confiance garantissant un calcul vérifiable. La dépendance à un seul fournisseur de matériel, tel qu’Intel ou AMD, entraîne des risques de monoculture : un rappel de firmware ou une exploitation pourrait interrompre BAM et éventuellement provoquer une indisponibilité de l’ensemble du réseau, selon le niveau d’adoption. Si ces vulnérabilités ne peuvent pas être corrigées par des mises à jour du firmware, du microcode ou du BIOS, le remplacement du matériel prend du temps et impose des dépenses d’investissement récurrentes aux opérateurs de BAM Nodes, aggravant davantage les conséquences d’une éventuelle indisponibilité. 

Ces préoccupations reposent sur des vulnérabilités historiques qui ont montré que les TEE pouvaient être défaillants et potentiellement exposer des données chiffrées. Par exemple, les Software Guard Extensions (SGX) d’Intel ont été affectées par de nombreux problèmes ayant eu des répercussions sur des blockchains. En août 2022, Secret Network était vulnérable aux failles xAPIC et MMIO. Ensemble, ces vulnérabilités pouvaient servir à extraire la seed de consensus, une clé maîtresse permettant de déchiffrer les transactions privées exécutées sur le réseau. 

Une multitude d’autres problèmes ont finalement conduit Intel à abandonner SGX sur les processeurs Intel Core de 11e et 12e générations. La technologie Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) d’AMD présente également plusieurs vulnérabilités rendues publiques. En février notamment, CVE-2024-56161 a été divulguée : cette vulnérabilité permettait l’injection malveillante de microcode avec un accès administrateur. 

Les mises à jour destinées à atténuer les vulnérabilités ne sont pas toujours rétrocompatibles et peuvent nécessiter des mises à niveau physiques. Par exemple, la divulgation de CVE02020-12967 et de CVE-2021-26311 révélait la possibilité d’exécuter du code arbitraire dans les machines virtuelles invitées sur les machines AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), l’implémentation TEE de génération précédente de l’entreprise. AMD n’a pas publié de firmware mis à jour pour corriger ces vulnérabilités et a fourni une mesure d’atténuation dans la fonctionnalité SEV-SNP, uniquement prise en charge par les processeurs AMD EPYC de 3e génération (à savoir « Milan »). 

L’infrastructure TEE de BAM repose sur l’architecture SEV-SNP de dernière génération, qui inclut les protections matérielles nécessaires pour prévenir ces exploitations connues. Il convient également de noter qu’en cas de découverte d’une vulnérabilité zero-day, le réseau pourrait rester opérationnel, car les Jito-Validators peuvent automatiquement se rabattre sur leur propre TPU lorsqu’ils sont déconnectés d’un BAM Node. Ce mécanisme de basculement permet aux validateurs de continuer à fonctionner pendant l’application des correctifs de sécurité.

Plusieurs questions restent en suspens :

• Compte tenu des exploitations passées, comment la dépendance de BAM envers les fournisseurs de matériel affecte-t-elle la confiance à long terme ? Des solutions telles que les Zero Trust Execution Environments (ZTEE) peuvent-elles réduire cette dépendance ?
• Qui assume la responsabilité des pertes financières si les données de transactions privées sont divulguées depuis un TEE compromis ?
• Comment restaurer la confiance en cas de défaillance des TEE ? Une autre solution pourrait-elle être proposée ?

Conclusion

Les validateurs restent libres d’exécuter le logiciel de leur choix. En tant qu’entreprises à but lucratif évoluant sur un marché très concurrentiel, leurs décisions dépendent des rendements potentiels, pour eux-mêmes comme pour leurs délégateurs, lesquels peuvent librement déplacer leur stake vers les validateurs offrant les meilleurs rendements. L’adoption généralisée du client Jito reflète cette dynamique : son succès repose en grande partie sur sa capacité à générer des revenus supplémentaires pour les opérateurs comme pour les délégateurs. L’adoption de BAM dépendra de facteurs similaires. Si l’exécution de BAM s’avère durablement plus rentable que le statu quo, les validateurs l’adopteront. Dans le cas contraire, ils pourraient hésiter à migrer, même si BAM parvient à apporter des avantages considérables aux autres parties prenantes.

BAM n’ayant été annoncé que récemment, de nombreuses questions concernant sa conception et son fonctionnement restent sans réponse. Nous attendons avec intérêt davantage de détails, de documentation et d’échanges avec la communauté dans les mois à venir au sujet de cette évolution prometteuse.

Ressources complémentaires

• Présentation de BAM : l’avenir de la construction de blocs sur Solana - Jito
• Série de présentations sur tableau blanc consacrée à BAM - Jito Learn
• Jito BAM et l’avenir de Solana - 0xResearch