SLV publie un guide officiel sur les points critiques qui influencent l’évaluation et les critères de participation des validateurs Solana testnet
ELSOUL LABO B.V. (siège : Amsterdam, Pays-Bas ; PDG : Fumitake Kawasaki) et Validators DAO ont publié dans SLV, leur plateforme open source d’exploitation des nœuds Solana, un guide officiel qui présente les points critiques de l’exploitation des validateurs Solana testnet.
Ce guide rassemble les contraintes opérationnelles et les points à connaître lorsque l’exploitation sur testnet constitue un prérequis d’évaluation et de participation, notamment dans le Solana Foundation Delegation Program (SFDP) et pour l’utilisation de BAM Testnet.
Le testnet applique des prérequis d’évaluation et de participation
Le testnet de Solana n’est pas un simple réseau de vérification. Dans plusieurs programmes, dont le SFDP, l’exploitation d’un validateur sur testnet constitue un prérequis pour la délégation de stake et l’évaluation.
L’évaluation ne porte pas seulement sur la capacité d’un nœud à démarrer, mais sur le maintien de configurations et de comportements proches de la production ainsi que sur les incohérences susceptibles d’apparaître pendant les mises à niveau et transitions. Seuls les résultats observés comptant, indépendamment des intentions ou des efforts de l’opérateur, poursuivre l’exploitation avec des configurations ou décisions erronées peut produire des résultats défavorables.
Exigences fondamentales pour les validateurs testnet participant au SFDP
Les validateurs participant au SFDP doivent conserver sur testnet la même catégorie de client que sur mainnet. L’évaluation ne porte pas uniquement sur la disponibilité fonctionnelle, mais aussi sur un comportement et une stabilité proches de la production.
SLV prend en charge les configurations testnet Agave, Firedancer et BAM. Simplifier une configuration au seul motif qu’il s’agit du testnet, ou mélanger différentes familles de clients, peut toutefois influer sur les critères d’évaluation et de participation. Le guide formalise explicitement ces précautions opérationnelles.
Méconnaître les contraintes propres au testnet constitue un risque
Les environnements testnet imposent des contraintes absentes du mainnet. Beaucoup sont mal documentées ; commencer l’exploitation sans les comprendre peut involontairement exclure le validateur de l’évaluation ou l’empêcher de satisfaire aux conditions de participation.
La bonne volonté ou les efforts ne suffisent pas à éviter ces conséquences. Exploiter un validateur sans comprendre les contraintes et les décisions propres au testnet constitue en soi un risque qui se reflète dans l’évaluation.
Réalité des contraintes géographiques de BAM Testnet
BAM Testnet impose des contraintes strictes de latence réseau. À l’heure actuelle, maintenir un ping stable inférieur à 35 ms vers les nœuds BAM constitue de fait un prérequis.
Les connexions depuis les régions qui ne satisfont pas cette exigence échouent souvent à s’établir ou ne tiennent pas dans la durée. Avant d’utiliser BAM Testnet, l’opérateur doit mesurer la latence depuis la région visée et ne pas présumer que le service sera utilisable si les conditions ne sont pas réunies.
Déploiement des nœuds BAM Testnet en janvier 2026
En janvier 2026, les nœuds BAM Testnet accessibles au public sont déployés dans trois régions : Dallas, New York et Salt Lake City. Les choix réalistes de déploiement se limitent donc à ces régions et à des régions américaines proches, telles que Chicago ou Los Angeles.
Une expansion dans les régions EMEA et en Asie est prévue, mais elle ne doit pas encore être considérée comme acquise pour l’exploitation. Le guide présente ces contraintes comme temporaires, et non permanentes.
Pourquoi formaliser maintenant ces recommandations testnet dans un guide officiel
Avec la transition de Solana vers la série v3 et l’introduction de BAM, les conditions d’exploitation sur testnet ont changé. Des configurations et choix de région auparavant sans conséquence influent désormais directement sur l’évaluation et la participation.
Plutôt que de dépendre de demandes individuelles ou d’informations fragmentées, nous avons jugé nécessaire de rendre ces recommandations publiques afin que les opérateurs comprennent les risques à l’avance et évitent des échecs inutiles.
Ce que couvre SLV et ce qui relève des opérateurs
SLV fournit une base reproductible pour la configuration du système d’exploitation et les procédures opérationnelles. En revanche, le choix de la région testnet et les décisions de configuration liées à des contraintes extérieures relèvent de l’opérateur.
Ce guide distingue clairement le périmètre pris en charge par SLV des domaines où l’opérateur doit décider lui-même en fonction des contraintes propres au testnet. Cette séparation clarifie les responsabilités et facilite des décisions opérationnelles solides.
La valeur de l’open source
La qualité opérationnelle du réseau Solana ne repose pas uniquement sur quelques nœuds très performants ou quelques opérateurs chevronnés. Elle résulte, au quotidien, du niveau d’exploitation cumulé d’un grand nombre de validateurs et de nœuds RPC.
Lorsque les connaissances et les implémentations restent fermées, la qualité d’exploitation tend à se concentrer dans un groupe restreint. Les configurations et comportements des nœuds divergent alors, ce qui se manifeste par des votes instables ou des traitements incohérents. Ces problèmes sont structurels, quelles que soient les intentions de chaque opérateur.
SLV est publié en open source afin que chacun puisse accéder aux mêmes implémentations et méthodes d’exploitation. La publication et la vérifiabilité de ces détails évitent les boîtes noires et permettent aux opérateurs de fonder leurs décisions, en cas de problème, sur le comportement observé et l’implémentation. Cette transparence sépare l’exploitation de l’intuition ou de la dépendance à une personne et rend possible une amélioration continue et concrète.
Les implémentations ouvertes évitent aussi que les opérations de qualité restent confinées au savoir-faire interne de quelques organisations : chacun peut les choisir. Les écarts de configuration et de comportement diminuent alors, ce qui permet à de nombreux validateurs et nœuds RPC de fonctionner avec un niveau de qualité stable.
Le choix de l’open source pour SLV met transparence, vérifiabilité et reproductibilité au service des environnements réels. En permettant à chacun d’adopter des normes opérationnelles de premier ordre, Solana peut améliorer en continu la qualité d’exploitation de l’ensemble de la chaîne.
Positionnement du présent guide
Ce guide sert de liste de contrôle pour éviter, dans l’exploitation des validateurs Solana testnet, les erreurs susceptibles d’affecter l’évaluation ou la participation. Comprendre à l’avance les contraintes et points de décision aide à éviter une dégradation inutile de l’évaluation, une perte de stake ou une disqualification.
Le guide est publié dans la dernière documentation de SLV. Pour participer à la communauté des utilisateurs de SLV et obtenir les informations associées, consultez le Discord officiel de Validators DAO.
- Guide des recommandations d’exploitation des validateurs Solana testnet : https://slv.dev/fr/doc/testnet-validator/operational-notes/
- Discord officiel de Validators DAO : https://discord.gg/C7ZQSrCkYR
- Site officiel de SLV : https://slv.dev/fr
