Au fil du temps, les difficultés liées au code de Solana ont progressivement été surmontées, entraînant une réduction sensible des temps de création de bloc — c’est-à-dire la durée nécessaire au réseau pour valider un nouveau bloc de transactions —, qui sont même passés en dessous du seuil théorique de 400 ms selon certaines analyses.

Mais, au cours du dernier mois, une évolution notable est apparue : le temps médian de production des blocs a fortement augmenté, ralentissant ainsi le rythme d’intégration des transactions dans la blockchain Solana. Ce phénomène est attribuable à une nouvelle pratique parmi les validateurs Solana, qui ont découvert qu’il pouvait être plus rentable de ralentir la production des blocs. Selon Blockworks, Anza, Jito et Marinade se penchent actuellement sur des solutions pour remédier à ce problème.

La durée des epochs sur Solana a connu un pic en juin. Source : Kamino

Sur Solana, chaque bloc est produit par un validateur désigné comme leader : il collecte les transactions, construit le bloc et le diffuse dans le réseau. Les leaders perçoivent les frais de transaction provenant des blocs qu’ils génèrent. Plus le volume d’ordres traités est important, plus les opportunités de gains sur les frais augmentent ; il est donc souvent plus avantageux financièrement pour les validateurs de traiter, par exemple, 500 ms de transactions que 300 ms.

De façon concrète, certains validateurs Solana attendent délibérément le maximum de temps pour remplir leurs blocs, cherchant à optimiser leur rendement, ce qui allonge la durée des epochs sur le réseau.

Cette situation contrevient à l’objectif de rapidité affiché par le réseau, qui aspire à être aussi rapide que le Nasdaq. Moins d’epochs par an signifie également moins d’occasions pour les récompenses de staking de s’accumuler, comme l’a souligné Max Kaplan, directeur technique de Sol Strategies.

Solana prévoit une période dite de « tolérance » (« grace ticks »), durant laquelle le leader peut encore valider et soumettre un bloc avec succès. Ce dispositif vise à éviter de pénaliser injustement les validateurs les plus éloignés géographiquement, mais il ouvre aussi la voie à des retards volontaires de la part de certains validateurs.

Le client alternatif de Solana, Frankendancer, a récemment introduit un ordonnanceur visant à maximiser le revenu des validateurs. Selon Kaplan, ceux ayant adopté ce client prennent un peu plus de temps que la normale pour assembler leurs blocs.

Kaplan précise néanmoins que le retard dû à Frankendancer demeure limité comparativement à d’autres validateurs plus opportunistes, et il ne considère pas cela comme « problématique ». Par ailleurs, le retardement des blocs n’est pas une nouveauté dans les blockchains à preuve d’enjeu. Il est probable, toutefois, que l’arrivée de la mise à jour Firedancer ait mis davantage en lumière cette stratégie sur Solana. Jump n’a pas souhaité faire de commentaire dans l’immédiat.

De façon intéressante, Michael McGee, ingénieur logiciel chez Firedancer, a décrit ce phénomène lors de l’dernier épisode du podcast Lightspeed.

« Nous avons observé, avec notre validateur actuel… [que les validateurs] peuvent souvent rendre un bloc plus rentable en différant l’exécution des transactions », a indiqué McGee.

Victor Pham, analyste chez Blockworks Research, observe que les validateurs Solana qui retardent leur production de blocs de façon sensiblement marquée utilisent souvent des versions personnalisées du client Agave-Jito.

Par exemple, lors de l’epoch 802 à la mi-juin, le temps médian de création de bloc pour Galaxy et Kiln dépassait chacun 570 ms. Plusieurs validateurs non identifiés affichaient également des performances lentes, tandis que chez Temporal, le temps médian observé atteignait 475 ms, selon les données de Solana Compass.

Ernest Oppetit, cofondateur de Kiln, a admis que le validateur — le sixième plus important du réseau par la taille des mises — avait temporairement retardé les slots, mais qu’il avait désormais cessé cette pratique.

« Chez Kiln, nous avons à cœur d’offrir le meilleur rendement de staking du marché sans jamais faire de compromis sur la sécurité. Nous avons mené des travaux de recherche et développement sur plusieurs composantes, dont l’optimisation du timing, et nous échangeons en permanence avec nos clients, les équipes techniques et la fondation à ce sujet. À ce jour, nous nous conformons strictement aux spécifications et ne pratiquons plus de retards, même si beaucoup d’autres acteurs le font encore. Nous pensons que la question des incitations (le fait que produire des blocs rapidement engendre moins de récompenses) doit, au fond, être traitée au niveau du protocole », a détaillé Oppetit.

Interrogé sur l’implication apparente de Temporal dans la tendance aux blocs lents, Ben Coverston, directeur de l’ingénierie chez Temporal, a précisé : « Ce n’est pas à cause de nous que la pratique est connue. »

« En tant que fournisseur de services, nous proposons des configurations de validateurs qui visent à maximiser la performance du staking pour nos clients. Sur Solana, cela peut signifier proposer des blocs légèrement plus lents pour optimiser la capture des récompenses. Galaxy reste également attentif aux retours de la communauté et a depuis réduit le temps de production des blocs à un niveau convenable », a ajouté un porte-parole de Galaxy.

La communauté des validateurs Solana considère que ralentir le réseau n’est pas acceptable, et ceux qui retardent les blocs s’exposent désormais à une vive réprobation publique.

Des sanctions plus concrètes pourraient être appliquées prochainement. Blockworks a appris que Jito prévoit d’exclure de son pool de staking — le plus important sur Solana — les validateurs trop lents.

Briant Smith, président de la Jito Foundation, a indiqué que l’organisation « prépare une proposition de gouvernance permettant à un comité d’exclure les validateurs à la traîne du set de délégation JitoSOL. Elle devrait être accessible pour une consultation communautaire sous peu ».

Michael Repetny, cofondateur du troisième plus grand pool de staking de Marinade, a quant à lui déclaré que l’opérateur envisage « de soumettre une proposition au vote afin de débattre de l’instauration de [validateurs lents] comme règle stricte, voire comme motif d’exclusion de la stratégie de délégation ».

Des solutions sont également en préparation au niveau du protocole. Le dépôt GitHub d’Anza met en avant une nouvelle proposition visant à réduire de moitié la période de tolérance sur Solana (« grace tick period »). De plus, la réforme en projet du mécanisme de consensus devrait permettre de remédier à ces dérives.

« Alpenglow réglera la question en permettant l’activation des votes de saut (« skip votes ») », assure Brennan Watt, vice-président engineering core d’Anza.

Watt a indiqué lors d’un épisode récent du podcast Lightspeed qu’Anza ambitionne de mettre Alpenglow en ligne sur le mainnet à l’occasion de la conférence Breakpoint de Solana, en décembre prochain.

Avertissements :

1. Cet article est republié depuis [Blockworks]. Tous les droits sont réservés à l’auteur original [Jack Kubinec]. Pour toute objection à cette republication, veuillez contacter l’équipe Gate Learn.
2. Avertissement : Les opinions exprimées dans cet article n’engagent que l’auteur et ne constituent en aucun cas un conseil en investissement.
3. Les traductions de cet article dans d’autres langues sont assurées par l’équipe Gate Learn. Sauf mention contraire, toute reproduction, distribution ou plagiat des articles traduits est interdite.