Auteur : Carlos, Luke Leasure
Titre original : Solana’s block-building wars
Compilation et organisation : BitpushNews
2026年1月5日, JITO a lancé un outil public appelé IBRL Explorer, visant à mesurer le comportement des validateurs de Solana en matière de construction de blocs et à révéler la "théorie des jeux temporels" auparavant invisible dans la construction des blocs.
Premièrement, nous devons comprendre certains contextes sur la structure du marché de Solana. Solana est conçu comme un système de traitement en flux : dans des conditions idéales, pendant la construction d'un bloc, le leader diffuse continuellement des fragments de données (c'est-à-dire de petits paquets de données). Ce comportement vise à minimiser le délai de traitement des transactions (c'est-à-dire l'intervalle entre le moment où un validateur reçoit une transaction et le moment où elle est traitée). Cependant, si le pipeline de transactions de Solana est vraiment continu dépend en réalité de la façon dont les validateurs assemblent leurs blocs.
Jito définit le comportement optimal de construction de blocs du point de vue du validateur : construction rapide, transmission continue en flux, diffusion précoce de l'état. Le score IBRL de Jito est un mélange pondéré de ces trois variables :
-
Temps de slot (35%) : Les validateurs obtiennent un score élevé si leur bloc est construit dans les seuils suivants : slot de relais repris d'un autre validateur inférieur à 550 millisecondes, ou slot continu (c'est-à-dire tout slot restant dans le tour du leader) inférieur à 380 millisecondes.
-
Inclusion des transactions non liées au vote (40%) : Les validateurs sont récompensés par des points lorsque les transactions sont réparties uniformément sur les 64 ticks du slot (plutôt que de regrouper la plupart des transactions non liées au vote dans les derniers ticks du slot, c'est-à-dire une "inclusion tardive"). C'est la variable la plus controversée du score IBRL, expliquée en détail plus loin.
-
Vote précoce (25%) : Les validateurs obtiennent un score parfait lorsque au moins 90% des transactions de vote sont traitées dans les 32 premiers ticks. Le score diminue si les votes sont reportés vers des parties plus tardives du bloc.
L'IBRL Explorer montre que de nombreux validateurs pratiquent l'inclusion tardive des transactions non liées au vote, prolongeant dans certains cas même le temps de slot. L'inclusion tardive retarde la propagation de l'état, augmente la variance des résultats d'exécution, perturbe la conception en flux de Solana et réduit ainsi la latence du réseau. Au lieu d'un flux de données continu, vous obtenez une éruption soudaine de données.
Dans un bloc optimal, comme l'exemple ci-dessous provenant du validateur Helius, la plupart des transactions de vote sont traitées dans la première moitié du bloc ("diffusion précoce de l'état"), tandis que les transactions non liées au vote sont réparties relativement uniformément sur les 64 ticks du slot ("transmission continue en flux").
Selon Lucas Bruder, co-fondateur et PDG de Jito Labs, les validateurs sont incités à attendre le dernier moment du slot pour observer plus de transactions entrantes, sélectionnant ainsi celles avec les frais les plus élevés, maximisant ainsi leurs récompenses.
Mais pourquoi les utilisateurs devraient-ils s'en soucier ? Bien que maximiser les profits soit un comportement rationnel pour un validateur individuel, ce comportement introduit une censure implicite, retarde la propagation de l'état et force le prochain leader à "rattraper son retard", ralentissant ainsi l'ensemble du réseau.
Plus important encore, l'inclusion tardive est également directement liée à la dynamique émergente du "Paiement pour Flux d'Ordres" (PFOF) sur Solana, comme l'a décrit Benedict Brady dans cet article. Parce que les portefeuilles et les applications génèrent généralement des transactions signées pré-routées (c'est-à-dire des ordres au marché avec des limites de slippage), une option précieuse de "backrun" est intégrée dans l'ordre. Il est bénéfique pour l'utilisateur de vendre ce droit de backrun à une firme de trading, tandis que l'approche extractive serait de mener une "attaque sandwich". Dans les deux cas, il y a une incitation à ralentir le traitement des transactions pour augmenter la valeur du backrun, ce que permet précisément l'inclusion tardive.
Cette incitation pousse Solana vers une structure de marché plus conflictuelle pour les applications et les utilisateurs. Elle affaiblit également les garanties clés sur lesquelles s'appuient les market makers, en particulier concernant les annulations intra-bloc et l'exécution déterministe, conduisant à un élargissement des spreads acheteur-vendeur. Sans transmission en flux, un marché véritablement en temps réel reste hors de portée pour Solana, quelle que soit la qualité de la logique applicative.
Le débat Temporal vs Jito
Avant d'approfondir la façon dont Solana résout ce problème, il faut reconnaître qu'il existe un débat actif sur ce qu'est une "bonne" construction de bloc. Temporal, contributeur principal de Harmonic, a contesté le cadre et la méthode de notation IBRL de Jito. Leur critique est que le score intègre un ensemble de préférences de conception spécifiques qui favorisent la façon dont Jito construit ses blocs et rend par défaut Harmonic moins performant, comme en témoignent les scores constamment bas des validateurs exécutant Harmonic.
Selon le co-fondateur de Harmonic, les blocs de Harmonic s'exécutent continuellement sans retard, mais les fragments de données ne sont libérés qu'après l'achèvement d'une enchère d'environ 300 millisecondes. Cette méthode donne suffisamment de temps aux constructeurs de blocs pour concourir et au reste du réseau pour rejouer le bloc de Harmonic. La visualisation ci-dessous montre le même slot (391,822,619) du validateur Temporal Emerald exécutant Harmonic.
Dans le contexte de la propagation du bloc (graphique du haut), l'exécution de Harmonic semble être uniformément espacée. En d'autres termes, le constructeur de blocs construit continuellement le bloc via une construction parallèle de blocs, et les transactions n'apparaissent groupées que dans les derniers ticks (graphique du bas) parce que c'est le moment où la résolution de l'enchère a lieu.
Au cours des 30 derniers jours, Harmonic a surpassé Jito et Firedancer en termes de revenu total moyen et médian par bloc (frais prioritaires + pourboires), générant ainsi des récompenses plus élevées pour les validateurs et les stakers. La question en suspens est de savoir si cette performance supérieure est obtenue au détriment des utilisateurs via la théorie des jeux temporels décrite ci-dessus.
Source : https://reports.firedancer.io/
Multi Concurrent Proposers (MCP) vs BAM
Après avoir exposé les deux points de vue, un point reste valable : la transmission continue en flux est cruciale.
L'affirmation de Harmonic n'est pas que la transmission en flux est sans importance, mais que l'IBRL ne capture pas comment Harmonic l'atteint et pourrait classer par erreur son mécanisme d'enchère comme de la "théorie des jeux temporels". À ce stade, je ne dispose pas encore de suffisamment de contexte technique ou de données pour former une opinion définitive, mais Solana développe déjà une solution intégrée au protocole visant à résoudre le problème sous-jacent d'incitation.
Cette solution est le Multi Concurrent Proposers (MCP), une architecture développée par Anatoly Yakovenko et Max Resnick. La motivation est simple : dans le modèle actuel à leader unique, un proposant contrôle le séquençage et peut effectivement agir plus tard que les autres, permettant ainsi l'inclusion tardive et renforçant la dynamique de type PFOF décrite ci-dessus. Le MCP élimine le monopole du leader unique en permettant à plusieurs proposants de construire des blocs candidats en parallèle et indépendamment. Cette architecture empêche un leader unique de supprimer unilatéralement des transactions ou de retarder l'exécution pour extraire des profits.
Cela dit, une condition préalable au MCP est le lancement d'Alpenglow sur le mainnet. Alpenglow est prévu pour 2026, mais le calendrier reste incertain. En attendant, le BAM de Jito pourrait favoriser le changement en rendant la logique de séquençage auditable. BAM vise à étendre l'espace de conception microstructurelle de Solana, permettant à des applications nécessitant un contrôle plus fin du séquençage (par exemple, prioriser les annulations d'ordres sur une place de marché de perpétuels) tout en aidant à atténuer les externalités négatives de MEV comme le front-running. Le schéma ci-dessous décrit le pipeline de transactions de BAM.
Il sera intéressant de voir comment la dynamique concurrentielle de la construction de blocs évoluera dans les prochains mois et ce que cela impliquera pour la structure de marché de Solana.
