Trois grandes initiatives techniques Web3 décryptées : Jito BAM, BRC2.0 et EIP-7999

Jito BAM sur Solana : Repenser l’architecture des blocs via une construction pluginisée

Le paysage MEV de Solana subit une restructuration majeure. Jito BAM — une couche d’infrastructure de construction de blocs — vise à résoudre une limitation architecturale fondamentale : le traitement séquentiel traditionnel des transactions. Contrairement au modèle PBS (Proposer-Builder Separation) d’Ethereum, BAM exploite le consensus unique POH (Proof of History) de Solana pour pré-assembler des blocs entiers dans un TEE (Trusted Execution Environment) avant leur distribution aux validateurs.

L’initiative représente une coalition de poids lourds de l’écosystème. Au-delà de Jito Labs, qui contrôle 90 % des validateurs de Solana, le casting de soutien inclut Triton One, SOL Strategies, Figment, Helius, Drift et Pyth. Cette poussée coordonnée répond à une menace concurrentielle urgente : des chaînes spécialisées comme Hyperliquid captent des parts de marché en optimisant les opérations natives de DEX sur carnet d’ordres — capacités que la production linéaire de blocs de Solana peine à reproduire.

L’architecture technique introduit un nouvel élément : un ordonnancement programmable des transactions via du code plugin. Cela signifie que les développeurs peuvent coder directement dans la structure du bloc des règles de séquencement spécifiques. Un fournisseur d’oracle pourrait garantir que les flux de prix s’exécutent en premier, minimisant les risques de données obsolètes. Un constructeur de DEX pourrait filtrer les transactions à haute probabilité d’échec lors de la phase TEE, réduisant ainsi les coûts pour l’utilisateur en cas d’échecs de swaps.

La feuille de route commence avec Jito Labs opérant des nœuds, puis s’étend progressivement à des validateurs représentant plus de 30 % du staking du réseau, pour évoluer vers une gouvernance décentralisée.

Cependant, des défis de scalabilité se profilent. La capacité TEE plafonne à quelques milliers de transactions par seconde, alors que les ambitions de Solana dépassent largement ce plafond. La gestion de plusieurs TEEs complexifie la récupération après sinistre, la gestion de la mémoire et la bande passante. De plus, à moins que des incitations économiques convaincantes ne se matérialisent, l’infrastructure pourrait peiner à être rentable — les revenus de Jito au Q2 2025 d’environ 4 millions USD via des tips soulignent des retours modestes actuels.

Les cas d’usage clés — fiabilité de l’ordonnancement oracle et immunité aux échecs de transaction — pourraient justifier des investissements de market makers et de plateformes de trading institutionnelles. Pourtant, le risque fondamental demeure : même une certitude de 99 % ne suffit pas pour des garanties déterministes lorsque la norme est une certitude de 100 %.

BRC2.0 : Exécution EVM ancrée sur Bitcoin

Bitcoin entre dans la course à la programmabilité avec une approche nettement différente. Prévu pour être activé le 2 septembre 2025, BRC2.0 redéfinit la conversation : plutôt que d’ajouter des couches computationnelles au-dessus de Bitcoin, il ancre des contrats programmables aux transactions Bitcoin tout en les exécutant dans un environnement hors-chaîne compatible EVM.

Les utilisateurs inscrivent des instructions sur des blocs BTC via des mécanismes d’inscription ou de commit-reveal. Un indexeur interprète ces instructions, les exécutant dans un runtime EVM modifié. Critiquement, aucun frais de gaz ne s’applique — seuls les frais de transaction Bitcoin comptent, car le paramètre EVM reste non décompressé.

La filiation du protocole remonte à Bestinslot, la plateforme de l’ère inscription qui a popularisé la théorie ordinal. La continuité philosophique avec BRC20 est évidente : étendre l’utilité de Bitcoin sans modifier le consensus. Cependant, l’exécution technique diffère substantiellement — elle cible l’exécution EVM plutôt que la simple émission de tokens.

Une question philosophique se pose : Bitcoin doit-il poursuivre la programmabilité ? Le compromis entre sécurité, consensus et décentralisation qui permet à Bitcoin de jouer le rôle de réserve de valeur diffère fondamentalement des chaînes à haut débit. Les chaînes à grande vitesse dépassent déjà la limite de performance de Bitcoin sur tous les plans. Le modèle de rareté de Bitcoin et son mécanisme de consensus à offre fixe créent un cadre d’évaluation unique — précisément parce que la programmabilité reste structurellement limitée. Ajouter des capacités d’exécution risque d’atténuer cette différenciation essentielle.

D’un point de vue technique, l’implémentation actuelle présente des vulnérabilités. Les appels récursifs de contrats n’ont pas de limite de profondeur, exposant théoriquement la VM à des scénarios de crash dus à une récursion non bornée. Bien que des correctifs soient simples, leur absence dans le code déployé doit inciter à la prudence.

EIP-7999 : Harmoniser le marché des frais multi-ressources d’Ethereum

La dernière proposition de Vitalik Buterin sur le marché des frais représente une réponse systématique à la fragmentation. Ethereum gère actuellement la tarification selon quatre dimensions : le gaz d’exécution (EIP-1559), le gaz blob (post-EIP-4844), les octets de calldata (différenciés depuis 2015), et les ressources de calcul.

Pour les utilisateurs et les développeurs de portefeuilles, cette complexité engendre des frictions UX. Les constructeurs de L2 font face à une crise réelle : une mauvaise calibration d’une seule dimension de frais peut faire échouer toute la transaction, indépendamment du budget total de frais. Une hausse soudaine du gaz blob pourrait provoquer un échec malgré une allocation suffisante de gaz d’exécution.

EIP-7999 introduit une tarification unifiée via un paramètre max_fee unique que l’EVM répartit dynamiquement entre les différentes ressources. La mise en œuvre nécessite de nouveaux types de transactions avec des définitions de champs restructurés, impactant l’encodage RLP, les en-têtes de blocs et les règles de validation du consensus.

L’approche s’apparente à une amélioration de l’UX par rapport à la complexité d’ERC-4337, bien que les délais d’adoption restent incertains. Une intégration complète nécessiterait probablement 1 à 2 hard forks majeurs, impliquant une adaptation de l’écosystème portefeuille et des changements au niveau des nœuds.

La réflexion économique mérite une analyse approfondie — les analyses de soutien de Vitalik contiennent des modèles sophistiqués d’utilisation des ressources, d’extraction des frais et de durabilité à long terme du réseau, qui méritent une étude approfondie par les développeurs de protocoles et les bâtisseurs d’écosystèmes naviguant dans la prochaine phase de scalabilité.

Ces trois initiatives — chacune issue d’écosystèmes blockchain distincts — reflètent une maturation plus large : les constructeurs évoluent au-delà du simple scaling pour s’orienter vers une optimisation architecturale, en équilibrant faisabilité technique et incitations économiques.