𝗧𝗼 𝗕𝗔𝗠 𝗼𝗿 𝗻𝗼𝘁 𝘁𝗼 𝗕𝗔𝗠 💥🤔 En suivant le conseil de @0xMert, l'équipe a rédigé un article de blog qui présente chaque contre-argument contre BAM. Référez-vous au lien ci-dessous. Plongeons-y 🧵 ⬇️

"𝗕𝗔𝗠 𝗲𝘀𝘁 𝘂𝗻 𝘀𝗲𝗾𝘂𝗲𝗻𝗰𝗲𝗿 𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘀𝗲́ 𝗮𝘃𝗲𝗰 𝘂𝗻 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗲 𝗱𝗲 𝗯𝗹𝗼𝗰𝗸-𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Cette critique soutient que BAM introduit un seul séquenceur qui s'occupera de toute la planification des transactions pour Solana. Même si l'infrastructure est distribuée, les règles de planification proviennent d'un seul système, qui est contrôlé par Jito. Les parties prenantes craignent que cela ne compromette la diversité naturelle des planificateurs de Solana en un seul qui pourrait se comporter comme un séquenceur centralisé, devenant un point de défaillance unique et concentrant trop d'influence dans un seul planificateur et une seule partie. BAM est conçu de manière à ce qu'aucune entité unique ne puisse contrôler l'ordre des transactions. Le système décentralisera son fonctionnement et la gouvernance de la logique de planification grâce à : • 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻 𝗼𝗽𝗲𝗻𝗲 : tout opérateur éligible peut participer et faire fonctionner son propre nœud BAM. • 𝗰𝗼𝘃𝗲𝗿𝘁𝘂𝗿𝗲 𝗴𝗹𝗼𝗯𝗮𝗹𝗲 : les nœuds BAM seront déployés à travers un réseau d'opérateurs géographiquement diversifié. • 𝗽𝗹𝗮𝗻𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲, 𝘃𝗲𝗿𝗶𝗳𝗶𝗮𝗯𝗹𝗲 : tout le code BAM sera open source et auditable via des attestations cryptographiques. Bien qu'il soit vrai que les nœuds BAM soient actuellement uniquement gérés par Jito, à partir du T1 '26, la base de code sera open source et des opérateurs indépendants seront intégrés.

“𝗘𝗻 𝘁𝗮𝗻𝘁 𝗾𝘂𝗲 𝗻𝗼𝘁𝗿𝗲 𝗮𝗰𝘁𝗲𝘂𝗿, 𝗕𝗔𝗠 𝘁𝗶𝗲 𝗺𝗲 𝘂𝗽 𝘁𝗼 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Cette critique dit qu'en optant pour BAM, un validateur renonce effectivement au contrôle de l'ordre des transactions au profit d'un seul planificateur. Au lieu de pouvoir exécuter ou adopter différents planificateurs, expérimenter avec leurs propres stratégies ou passer d'un design concurrent à un autre, ils sont liés à un seul système. Pour permettre les marchés de capitaux Internet, Solana a besoin de règles d'ordre déterministes et transparentes. La fragmentation nuit aux utilisateurs. BAM rend cela possible avec une construction de blocs standardisée et vérifiable requise par les applications à haute performance. Les faits sont : • BAM est strictement sur option. • Les validateurs peuvent revenir aux clients Agave, Jito-Solana ou Firedancer. • Ils peuvent se déconnecter de BAM à tout moment. Les plugins BAM offrent une plateforme pour l'optimisation et l'innovation des développeurs qui bénéficient à l'ensemble de Solana.

"𝗕𝗔𝗠 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝘇𝗲𝘀 𝗦𝗼𝗹𝗮𝗻𝗮 𝗼𝗿𝗱𝗲𝗿𝗳𝗹𝗼𝘄." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les parties prenantes soutiennent que l'agrégation des transactions publiques dans un seul pipeline crée un point de congestion central par lequel tout le flux de commandes passe et donne des avantages à ceux qui le contrôlent. Même si c'est neutre au départ, BAM contrôle le flux de commandes, ce qui peut renforcer sa position concurrentielle et empêcher d'autres solutions de gagner en traction. BAM collecte les transactions en utilisant le mécanisme standard TPU de Solana. Il n'y a pas de distinction entre les "transactions BAM" et les transactions publiques. Les validateurs reçoivent le même flux public, simplement programmé à travers une couche vérifiable. Les validateurs peuvent revenir instantanément à leur TPU natif sans coûts de changement, maintenant le flux de commandes public plutôt que fragmenté en canaux privés.

“𝗕𝗔𝗠 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗲𝘅𝘁𝗿𝗮 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝘃𝘀. 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿’𝘀 𝗻𝗮𝘁𝗶𝘃𝗲 𝗧𝗣𝗨.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les parties prenantes soutiennent que l'un des avantages de performance de Solana provient des transactions qui circulent directement vers le TPU du leader avec un minimum d'étapes. Tout niveau de routage intermédiaire, même rapide, risque d'ajouter de la latence, du jitter et de nouveaux points de défaillance sous charge, et pourrait affaiblir la mission IBRL par rapport à la planification native TPU. BAM garantit une latence minimale grâce à une empreinte mondiale de plus de 100 nœuds et à une co-localisation stratégique, maintenant les temps de réponse en dessous de 5 ms. Notre pile TEE est hautement optimisée grâce à l'affectation de threads et à l'isolation CPU, atteignant une parité de performance avec Agave. Avec la migration à venir vers DoubleZero, nous nous attendons à dépasser les benchmarks de performance bare metal.

“𝗕𝗔𝗠 𝗽𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗲𝘀𝘀 𝗿𝗲𝘄𝗮𝗿𝗱𝘀 𝘃𝘀. 𝗼𝘁𝗵𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁𝘀” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les validateurs ont exprimé des préoccupations selon lesquelles la logique de planification de BAM pourrait réduire les pourboires et les récompenses globales par rapport à d'autres opportunités de construction de blocs ou de planification. De plus, les marchés de frais de Plugin ne sont pas encore actifs, rendant le potentiel théorique tandis que le risque semble immédiat. Nous privilégions la maximisation des profits à long terme. Les récompenses de BAM sont déjà comparables à celles de Jito-Agave. Les disparités passées étaient dues à des planificateurs temporaires et extractifs ailleurs qui sont en cours de dépréciation. Les rendements futurs seront déterminés par les Plugins et ACE, débloquant des flux de frais durables provenant d'une nouvelle activité économique plutôt que de jeux à court terme.

“En tant que validateur, je dois donner à mes stakers le rendement le plus élevé.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les stakers choisissent souvent des validateurs uniquement en fonction des récompenses. Même une petite diminution des pourboires ou une variation des gains au cours d'une époque peut entraîner un flux de mise déléguée ailleurs. Les validateurs craignent qu'adopter le BAM tôt puisse les désavantager par rapport à leurs pairs si ceux-ci retardent leur adoption. Nous comprenons que les validateurs doivent maximiser le rendement pour eux-mêmes et leurs stakers, mais ils doivent également prendre en compte les effets d'ordre secondaire de leurs actions. Le hacking de rendement à court terme (sandwiching, slot-lagging) dégrade la qualité d'exécution globale et éloigne la liquidité. Le seul chemin durable vers un rendement plus élevé est une activité on-chain plus profonde, qui ne peut être rendue possible que par de meilleures applications, une liquidité plus profonde et des spreads plus serrés.

"𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻-𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 (𝗔𝗖𝗘) 𝗶𝘀 𝗻𝗼𝘁 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les parties prenantes soutiennent que les applications Solana fonctionnent déjà bien sous les mécanismes d'inclusion des frais prioritaires et des pourboires. L'introduction de l'ACE pourrait augmenter la complexité et créer des garanties d'exécution inégales entre les applications sophistiquées et les petits développeurs. Ils craignent que permettre aux applications de définir la logique d'ordre puisse conduire à un privilège de BAM pour certains acteurs. Les applications sophistiquées ont besoin de garanties telles que la priorité d'annulation ou la priorité de liquidation pour fonctionner en toute sécurité. Hyperliquid réalise 10 à 15 fois le volume des contrats à terme Solana spécifiquement en raison de son ensemble de validateurs autorisés qui impose un ordre strict. Sans l'ACE, ces applications migreront vers des L1 ou L2 personnalisés pour obtenir ces garanties.

“𝗙𝗜𝗙𝗢 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗮𝗶𝗿𝗲𝘀𝘁 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗹𝗼𝗴𝗶𝗰” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les parties prenantes soutiennent que l'ordre FIFO (premier arrivé, premier servi) est la manière la plus équitable et neutre de programmer les transactions sur Solana. Cela reflète la priorité temporelle des marchés traditionnels, est facile à comprendre pour les utilisateurs (“si ma tx arrive en premier, elle s'exécute en premier”), et évite les dynamiques de “payer pour gagner” de la plupart des blockchains. Bien que le FIFO semble le plus équitable en traitant les transactions dans l'ordre où elles sont reçues, il encourage les utilisateurs à spammer le réseau pour sécuriser une position favorable, entraînant congestion et courses de latence coûteuses. Cela se dégrade lorsque la demande sur le réseau est élevée, provoquant des retards imprévisibles pour tous les utilisateurs à mesure que les files d'attente s'allongent. L'approche universelle du FIFO ne répond pas aux besoins des applications qui nécessitent un ordre de transaction spécifique pour fonctionner de manière optimale.

"Les 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 (𝗧𝗘𝗘𝘀) de BAM ne sont-ils pas vulnérables aux attaques ?" 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯 : Les TEEs ont une histoire de vulnérabilités par canaux auxiliaires, de bogues de firmware et de risques liés à la chaîne d'approvisionnement. Les parties prenantes soutiennent que s'appuyer sur les TEEs pour la planification des blocs pourrait introduire des modes de défaillance corrélés : si une exploitation matérielle affecte SEV-SNP, BAM en tant que réseau pourrait être compromis. Ils soutiennent également que les TEEs transfèrent la confiance aux fournisseurs de matériel et aux fournisseurs de centres de données. BAM fonctionne sur AMD SEV-SNP avec des attestations cryptographiques dans des centres de données sécurisés et conformes (ISO 27001/SOC 2). Même dans le pire des cas de compromission matérielle, les clés des validateurs restent sécurisées et l'historique de la chaîne ne peut pas être réécrit, seule la confidentialité de l'ordre sur ce nœud spécifique est affectée. Les validateurs vérifient le "TCB mesuré" et peuvent rejeter un mauvais firmware via attestation.

@0xmert L'avenir de la construction de blocs passe d'une planification fragmentée à un marché transparent et vérifiable. BAM est la solution. Des milliards doivent BAM ! 💥