Révélation des données : Les transferts Solana ralentissent, et si c'était les validateurs qui "trichent" ?

Auteur : Carlos 、 Luke Leasure

Titre original : La guerre de la construction de blocs sur Solana

Traduction et synthèse : BitpushNews

Le 5 janvier 2026, JITO a lancé un outil public nommé IBRL Explorer, destiné à mesurer le comportement des validateurs lors de l’assemblage des blocs sur Solana, et à révéler le « jeu de timing » jusque-là invisible dans la construction des blocs.

Tout d’abord, il est nécessaire de comprendre quelques éléments de contexte sur la structure du marché de Solana. Solana a été conçue comme un système de traitement en flux continu : idéalement, lors de la construction d’un bloc, le leader diffuse en permanence des fragments de données (petits paquets). Cette démarche vise à minimiser la latence de validation des transactions (le délai entre la réception d’une transaction par un validateur et son traitement). Cependant, la continuité réelle du pipeline de transactions sur Solana dépend en réalité de la façon dont les validateurs assemblent leurs blocs.

Jito définit du point de vue des validateurs le comportement optimal d’assemblage de blocs : construction rapide, transmission continue, diffusion précoce de l’état. Le score IBRL de Jito est une combinaison pondérée de ces trois variables :

• Slot Time (35%) : si le bloc du validateur est construit dans un délai inférieur à un seuil, il obtient un meilleur score : moins de 550 ms entre la prise en charge d’un slot par un autre validateur, ou moins de 380 ms pour un slot consécutif (c’est-à-dire un slot restant dans le cycle du leader).

• Packaging des transactions non-vote (40%) : lorsque les transactions sont réparties uniformément dans les 64 ticks d’un slot (et non concentrées dans les derniers ticks, ce qu’on appelle le « packaging retardé »), le validateur reçoit une récompense. C’est la variable la plus contestée dans le score IBRL, qui sera expliquée en détail plus loin.

• Vote précoce (25%) : si au moins 90% des transactions de vote sont traitées dans les 32 premiers ticks, le validateur obtient la note maximale. Si le vote est repoussé vers la fin du bloc, la note diminue.

L’IBRL Explorer montre que de nombreux validateurs pratiquent un packaging retardé des transactions non-vote, et dans certains cas, prolongent même la durée du slot. Ce retard dans le packaging retarde la diffusion de l’état, augmente la variance des résultats d’exécution, fragilise la conception en flux continu de Solana, et réduit la latence du réseau. Ce que vous obtenez n’est pas un flux de données continu, mais une explosion soudaine de données.

Dans un bloc optimal, comme dans l’exemple ci-dessous provenant d’un validateur Helius, la majorité 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-vote sont réparties de façon relativement uniforme dans les 64 ticks du slot (« transmission en flux continu »).

En revanche, le packaging retardé intentionnel est évident dans l’exemple du bloc Galaxy ci-dessous, où la majorité des transactions non-vote sont insérées dans les derniers ticks du slot. En procédant ainsi, le validateur privilégie la valorisation spéculative en retardant la diffusion de l’état, plutôt que la santé du réseau.

Selon Lucas Bruder, co-fondateur et CEO de Jito Labs, les validateurs sont incités à attendre la fin du slot pour observer davantage de transactions entrantes, et à choisir celles qui offrent les frais les plus élevés, afin de maximiser leur récompense.

Mais pourquoi cela devrait-il importer aux utilisateurs ? Bien que maximiser le profit soit une démarche rationnelle pour un validateur individuel, cette pratique introduit une censure implicite, retarde la diffusion de l’état, et oblige le prochain leader à « rattraper » le retard, ce qui ralentit l’ensemble du réseau.

Plus important encore, le packaging retardé est directement lié à la dynamique émergente du « paiement par flux d’ordre » (PFOF) sur Solana, déjà évoquée par Benedict Brady. Étant donné que les portefeuilles et applications génèrent souvent des transactions signées préalablement routées (avec des limites de slippage sur des ordres au marché), ces ordres intègrent des options de « post-exécution » de valeur. La pratique favorable aux utilisateurs consiste à vendre ce droit de post-exécution à des sociétés de trading, tandis que la pratique spéculative consiste en des « attaques en sandwich ». Dans les deux cas, il existe une motivation à ralentir la validation pour augmenter la valeur de ces options de post-exécution, ce que permet le packaging retardé.

Ce type d’incitation pousse Solana vers une structure de marché plus conflictuelle entre applications et utilisateurs. Elle affaiblit également les garanties clés sur lesquelles comptent les market makers, notamment en ce qui concerne l’annulation dans le bloc et l’exécution déterministe, ce qui élargit les spreads. Sans flux continu, peu importe la qualité de la logique applicative, le marché en temps réel reste inaccessible pour Solana.

Débat entre Temporal et Jito

Avant d’approfondir comment Solana pourrait résoudre ce problème, il faut reconnaître qu’un débat actif existe sur ce qu’est un « bon » processus de construction de blocs. Temporal, un contributeur principal de Harmonic, a contesté le cadre et la méthode de notation IBRL de Jito. Leur critique est que cette note intègre une préférence de conception spécifique, favorable à la façon dont Jito construit ses blocs, et suppose que Harmonic apparaît moins bien, ce qui se traduit par des validateurs utilisant Harmonic qui obtiennent systématiquement des scores plus faibles.

Selon un co-fondateur de Harmonic, leurs blocs sont construits de façon continue et sans retard, mais les fragments de données ne sont libérés qu’après environ 300 ms d’enchère. Cette méthode donne aux constructeurs de blocs suffisamment de temps pour faire concurrence, tout en laissant à d’autres parties du réseau le temps de rejouer les blocs Harmonic. La visualisation ci-dessous montre un exemple de ce même slot (391,822,619), avec un validateur Harmonic, Temporal Emerald.

D’après la perspective de la propagation du bloc (illustrée ci-dessus), la construction de Harmonic semble régulière. En d’autres termes, le constructeur construit le bloc en continu via une construction parallèle, mais la concentration des transactions dans les derniers ticks s’explique par le moment de la résolution de l’enchère.

Au cours des 30 derniers jours, Harmonic a surpassé Jito et Firedancer en termes de revenu moyen et médian par bloc (frais prioritaires + pourboires), offrant ainsi de meilleures récompenses aux validateurs et aux stakers. La question en suspens est de savoir si cette performance supérieure est le résultat du jeu de timing évoqué plus haut, au prix de l’intérêt des utilisateurs.

Source : https://reports.firedancer.io/

Plusieurs proposeurs concurrents (MCP) et BAM

Après avoir exposé les deux points de vue, une chose reste certaine : la transmission en flux continu est essentielle.

Harmonic ne prétend pas que la transmission en flux continu n’est pas importante, mais que IBRL ne capture pas la façon dont Harmonic y parvient, et pourrait mal classer son mécanisme d’enchère comme un « jeu de timing ». À ce stade, je ne dispose pas encore de suffisamment de connaissances techniques ou de données pour me faire une opinion tranchée, mais Solana développe déjà une solution interne visant à résoudre les problèmes d’incitations sous-jacents.

Cette solution est la architecture des plusieurs proposeurs concurrents (MCP), développée par Anatoly Yakovenko et Max Resnick. La motivation est simple : dans le modèle actuel à un seul leader, un proposeur contrôle le classement, et peut en réalité agir plus tard que les autres, ce qui permet le packaging retardé et renforce la dynamique PFOF évoquée plus haut. Le MCP élimine le monopole d’un seul leader en permettant à plusieurs proposeurs de construire indépendamment des blocs candidats en parallèle. Cette architecture empêche un leader unique de supprimer ou retarder les transactions à sa guise pour en tirer profit.

Autrement dit, une condition préalable au MCP est le lancement d’Alpenglow sur le réseau principal. La sortie d’Alpenglow est prévue pour 2026, mais la date reste incertaine. En attendant, BAM de Jito pourrait faire évoluer la situation en rendant la logique de classement auditée. BAM vise à étendre l’espace de conception microstructurel de Solana, permettant à des applications nécessitant un contrôle plus fin du classement (par exemple, la gestion des ordres d’annulation dans des plateformes de contrats perpétuels) tout en atténuant certains effets négatifs du MEV, comme le frontrunning. La figure ci-dessous présente la pipeline de traitement des transactions de BAM.

BAM (Agave-BAM) est actuellement le troisième client en parts de staking sur Solana (environ 12%), derrière Agave-Jito et Frankendancer-Jito. Environ 205 validateurs utilisent BAM, ce qui montre une adoption rapide dans la communauté des validateurs de Solana. À l’inverse, Harmonic reste de taille modeste, avec un peu plus de 3% de parts de staking et une vingtaine de validateurs.

Il sera intéressant d’observer comment la compétition pour la construction des blocs évoluera dans les prochains mois, et ce que cela signifiera pour la structure du marché de Solana.