SLV achève la prise en charge de Solana v4 avec XDP et un BLS prêt pour Alpenglow

ELSOUL LABO B.V. (siège : Amsterdam, Pays-Bas ; CEO : Fumitake Kawasaki) et Validators DAO ont le plaisir d'annoncer que SLV, l'outil open source d'exploitation Solana, a achevé la prise en charge de Solana v4 (Agave 4.x).

Avec cette mise à jour, les optimisations sur lesquelles s'appuient les validateurs Solana les plus performants — l'accélération de la retransmission Turbine par XDP signée Anza et le workflow d'enregistrement de clé publique BLS prêt pour Alpenglow défini dans SIMD-0387 — peuvent désormais être exécutées par tout opérateur grâce à la même recette opérationnelle éprouvée, via des conversations avec un agent IA ou une exploitation directe en CLI. Le réglage avancé qui exigeait autrefois une expertise approfondie de Linux et de Solana est consolidé dans SLV, de sorte que même les opérateurs sans ce bagage spécialisé peuvent le reproduire par la seule conversation.

Site officiel de SLV : https://slv.dev/fr SLV GitHub : https://github.com/validatorsDAO/slv

Démocratiser l'exploitation des validateurs de premier rang — une optimisation de classe mondiale, reproductible par tous

SLV est une démarche open source visant à exploiter des validateurs Solana aux côtés d'agents IA, en assurant la plus haute qualité de maintenance à faible coût, partout dans le monde.

Sur Solana, l'écart entre la performance brute d'un validateur et le savoir-faire opérationnel qui la sous-tend n'a cessé de se creuser. Réseau à faible latence, réglage du noyau et du NIC, préparation minutieuse aux mises à niveau de protocole — les opérations qui mènent à une performance de validateur de premier rang ont exigé une connaissance spécialisée approfondie de Linux et de Solana, ainsi qu'un travail manuel continu. En conséquence, les plus hauts niveaux d'exploitation avaient tendance à rester accessibles uniquement à un groupe restreint d'opérateurs disposant de cette expertise.

SLV existe pour combler cet écart. En consolidant le savoir-faire opérationnel accumulé par les exploitations de validateurs de classe mondiale en compétences pour un agent IA, chacun peut reproduire la même recette opérationnelle par la seule conversation. Cette prise en charge de Solana v4 applique directement cette idée aux dernières optimisations : XDP et BLS, les technologies mêmes que les validateurs les plus performants adoptent, sont désormais à la portée de tout opérateur qui utilise SLV — sans renoncer à son propre choix de client ou d'environnement.

Ce qu'apporte la prise en charge de Solana v4 — XDP, BLS et sécurité au redémarrage, tout est pris en charge pour vous

Solana v4 (Agave 4.x) est la dernière génération du client validateur, recommandée par Anza pour le mainnet ; elle relève la performance fondamentale tout en préparant le réseau à des blocs plus grands et à la prochaine mise à niveau de consensus Alpenglow. La prise en charge de la v4 par SLV couvre les trois domaines qui comptent le plus pour les opérateurs qui passent à cette base.

Accélération de la retransmission Turbine par XDP — activation clé en main du chemin réseau haute performance qui accélère la propagation des blocs.
Enregistrement de clé publique BLS prêt pour Alpenglow (SIMD-0387) — préparation à l'avance du workflow d'enregistrement, afin que les validateurs soient prêts à enregistrer dès que le feature gate d'Alpenglow s'active.
Sécurité au redémarrage pour Agave 4.1+ — ajustement de la plage de ports et conditionnement des flags réservés au redémarrage de cluster, afin que le passage au nouveau client n'introduise pas d'échecs de démarrage évitables.

Chacun de ces points est pris en charge par le même workflow SLV — conversation avec l'agent IA ou CLI — de sorte que le passage à Solana v4 ne devienne pas un projet manuel et propice aux erreurs. La dernière version de SLV embarque tout ce qui précède dans le cadre de la série v2026.6.6 — BLS, XDP et les correctifs de sécurité au redémarrage arrivent en premier, suivis dans la même série par la robustesse de Firedancer et du RPC.

Qu'est-ce que XDP — un chemin rapide du noyau Linux qui accélère Turbine

XDP (eXpress Data Path) est une technologie du noyau Linux qui permet à du code réseau haute performance de contourner une grande partie du chemin habituel de traitement des paquets du noyau. En réduisant les copies de données et les changements de contexte, il traite les paquets avec bien moins de surcharge que la pile réseau standard.

Dans Agave, XDP est appliqué à Turbine, le protocole qui propage les blocs à travers le réseau de validateurs. Les shreds entrants sont traités par un programme eBPF attaché au plus près de la carte d'interface réseau (NIC) et mappés dans des buffers de l'espace utilisateur via AF_XDP, tandis que les shreds sortants sont envoyés directement à l'aide de XDP_TX — éliminant les appels système et les copies sur le chemin critique. Anza a introduit XDP pour Turbine dans la série Agave 3.x (à partir de v3.0.9) et le reconduit dans la base Agave 4.0.

Selon le guide de configuration d'Anza, les grands validateurs peuvent approcher 150,000 paquets sortants par seconde avec XDP. Anza positionne XDP comme une partie de la marge qui prépare les validateurs aux blocs 100M-CU et fait avancer la feuille de route IBRL (Increase Bandwidth, Reduce Latency), et a publié un guide de configuration officiel pour les opérateurs qui l'adoptent.

Anza Agave XDP Setup Guide : https://www.anza.xyz/blog/agave-xdp-setup-guide

SLV rend XDP clé en main — activez-le avec une conversation et quelques variables d'inventaire

Adopter XDP à la main n'a rien d'anodin. Cela nécessite un noyau récent (6.14+ pour le pilote igb, 6.8+ pour les autres), un NIC compatible XDP, les bonnes capabilities systemd pour le processus validateur et les bons flags de démarrage — et l'épinglage des cœurs CPU (y compris le cœur PoH) doit être choisi correctement pour que le chemin soit performant. C'est exactement le type de travail spécialisé qui a maintenu l'optimisation avancée hors de portée de nombreux opérateurs.

SLV en fait une étape clé en main. L'accélération de la retransmission XDP s'active en opt-in via des variables d'inventaire par hôte — xdp_enabled, xdp_interface, xdp_cpu_cores, xdp_zero_copy et xdp_poh_pinned_cpu_core. Une fois activé, SLV applique les flags de démarrage XDP adaptés à la version Agave/Jito cible et accorde automatiquement les capabilities systemd requises (CAP_NET_RAW, CAP_NET_ADMIN, CAP_BPF, CAP_PERFMON). Ces variables s'appliquent aux validateurs Agave et Jito ; Firedancer utilise XDP nativement et ne nécessite aucune activation distincte. (XDP a mûri au fil des versions d'Agave — il n'est plus expérimental à partir d'Agave 4.1, et les noms de flags correspondants ont changé en cours de route — de sorte que SLV suit les flags corrects pour chaque version, et les opérateurs n'ont pas à s'en soucier.)

Du côté de l'opérateur, tout cela peut être piloté entièrement par la conversation. Lancez l'AI Console et dites quelque chose comme « Active l'accélération de la retransmission XDP sur ce validateur », et l'agent IA sélectionne et applique la configuration nécessaire. Des commandes correspondantes sont également fournies pour les utilisateurs orientés CLI, de sorte que les workflows n'impliquant pas d'agents IA sont pleinement pris en charge. La même optimisation réseau qu'utilisent les validateurs les plus performants devient quelque chose que tout opérateur SLV peut activer.

Enregistrement BLS prêt pour Alpenglow — prise en charge anticipée de SIMD-0387

Alpenglow est le protocole de consensus de prochaine génération de Solana. Pour agréger efficacement les votes des validateurs — par exemple, pour prouver de façon concise que 60 % des validateurs ont voté pour ignorer un slot — Alpenglow remplace les signatures ed25519 actuelles par le schéma de signature agrégée BLS (Boneh–Lynn–Shacham) pour les votes. SIMD-0387 définit comment les validateurs enregistrent une clé publique BLS dans leur vote account afin d'être prêts à voter dès qu'Alpenglow est activé.

Selon SIMD-0387, l'enregistrement d'une clé publique BLS devient possible une fois que le feature gate de la proposition est actif, et chaque validateur doit en posséder une dans son vote account avant la mise en service d'Alpenglow afin de continuer à voter. La paire de clés BLS est dérivée de la paire de clés vote authority (ou de la paire de clés identity à défaut), et l'enregistrement est effectué on-chain avec un Proof of Possession (PoP) — une preuve cryptographique liant la clé au vote account, qui prévient les rogue-key attacks. À l'heure actuelle, SIMD-0387 est au stade de la revue et son feature gate n'est pas encore actif sur le mainnet (son activation est suivie pour le devnet), de sorte qu'aucune clé BLS ne peut encore être enregistrée sur le mainnet ; ce qui compte aujourd'hui, c'est d'avoir le workflow prêt pour le moment où le gate s'ouvrira.

C'est précisément là que la préparation anticipée fait la différence. Une fois Alpenglow en service, un vote account sans clé BLS enregistrée se comporterait comme s'il était unstaked. Avoir le workflow d'enregistrement en place à l'avance, plutôt que de se précipiter quand le gate s'ouvre, est ce qui maintient une exploitation en sécurité tout au long de la transition.

Le register:bls de SLV — préparé automatiquement au moment du déploiement

SLV met cette préparation en place pour vous. La nouvelle commande slv v register:bls est le workflow qui enregistre la clé publique BLS — dérivée de la paire de clés authorized-voter ou identity — sur chaque vote account une fois le feature gate actif. Elle s'exécute également automatiquement à la fin de slv v deploy, de sorte qu'un validateur construit ou mis à jour via SLV franchit cette étape dans le cadre du flux normal.

L'opération est conçue pour être sûre à exécuter à tout moment. Sur un cluster où le feature gate n'est pas encore activé, elle se déroule sans risque comme un no-op ; une fois le gate activé, le même workflow enregistre la clé. Elle est idempotente, de sorte que l'exécuter tôt ne comporte aucun risque et qu'il n'est pas nécessaire d'en caler précisément le moment par rapport à la mise à niveau. Comme pour XDP, cette même étape peut être pilotée par la conversation avec l'agent IA ou via la CLI. Les fondations qui déterminent si un validateur peut continuer à voter à travers la transition Alpenglow sont en place à l'avance, sans gestion manuelle des clés.

Sécurité au redémarrage renforcée pour Agave 4.1+

Passer à une nouvelle génération de client peut faire apparaître de subtils échecs de démarrage, et la prise en charge de la v4 par SLV y répond directement. Pour Agave 4.1+ (et les validateurs Jito sur la même base), le dynamic_port_range est élargi à au moins 27 ports (8000–8030 / 8900–8930), résolvant un cas où Agave/Jito 4.1.0+ rejette une plage plus étroite au démarrage avec « Port range is too small » — un échec qui plaçait validateurs et nœuds RPC en crash-loop. Le correctif couvre tous les scripts de démarrage validator, RPC et pythnet, ainsi que les valeurs par défaut d'init et d'inventaire.

De plus, les flags réservés au redémarrage de cluster sont désormais conditionnés : --wait-for-supermajority et --expected-bank-hash ne sont émis que lorsqu'ils sont explicitement définis, de sorte qu'un slot ou un bank hash périmé ne peut plus bloquer un nœud, ni le faire paniquer sur une non-concordance de bank hash, lors d'un redémarrage ordinaire. Ce sont précisément le genre de détails qui, traités à la main, transforment une mise à niveau de routine en incident — et dont SLV se charge désormais dans le cadre de la recette standard.

Ce durcissement se poursuit à travers la recette. Une version ultérieure étend la même robustesse opérationnelle aux chemins Firedancer et RPC — gestion de version de Firedancer tenant compte du réseau, nettoyage d'un conflit de build Jito et corrections des scripts de démarrage RPC — afin que le passage à la dernière base reste fluide quel que soit le client exploité par un opérateur.

En finir avec la réinvention de la roue — consolider le savoir-faire de premier rang dans l'agent IA

Dans l'écosystème Solana, de nombreux projets consacrent du temps au travail partagé d'exploitation des validateurs et des nœuds, distinct du développement de leur produit réel. Construire, déployer, surveiller, mettre à jour et migrer les clients — pour chaque projet, ce sont des répétitions similaires des mêmes tâches, une sorte de réinvention de la roue.

L'activation de XDP et l'enregistrement BLS prêt pour Alpenglow en sont de parfaits exemples. Ils sont avancés, faciles à mal exécuter, et chaque opérateur doit sinon les rechercher et les redériver de manière indépendante. En consolidant ce savoir-faire opérationnel en compétences SLV pour l'agent IA, la même recette éprouvée peut être reproduite par n'importe qui, par la seule conversation — et le coût humain de l'exploitation baisse structurellement. Avec cette version, la compétence validateur de SLV — le savoir auquel l'agent IA fait appel — a été mise à jour pour BLS (SIMD-0387) et XDP, de sorte que l'agent applique la procédure actuelle et correcte plutôt qu'une procédure obsolète. C'est ce que signifie en pratique « la plus haute qualité de maintenance, à faible coût ».

SLV continuera de résoudre, un par un, les fardeaux opérationnels communs aux projets Solana, aux côtés de SLV AI — afin que chaque projet puisse se concentrer sur le développement essentiel de son propre produit.

À la fois CLI et agent IA — la stabilité soutient les deux

SLV fonctionne de manière stable non seulement en tant qu'agent IA, mais aussi en tant que CLI. Pour les utilisateurs qui préfèrent ne pas s'appuyer sur des agents IA, ou qui souhaitent intégrer SLV dans des flux d'automatisation scriptés, SLV reste une base d'exploitation pratique.

Cette stabilité au niveau de la CLI est précisément ce qui soutient la fiabilité de l'exploitation par agent IA. Chaque fonctionnalité de SLV est compatible MCP (Model Context Protocol), et l'agent IA invoque via MCP les mêmes interfaces que la CLI. Quand la CLI est stable, l'agent IA est stable — ce principe de conception soutient la fiabilité de l'exploitation par agent IA de SLV. L'activation de XDP et register:bls, eux aussi, peuvent être gérés de la même manière depuis la CLI et l'agent IA, sur la même base MCP.

Une base d'exploitation qui appuie un engagement envers la performance — le validateur Epics DAO a atteint la 3e place mondiale

Le validateur Epics DAO, exploité comme source de l'endpoint SWQoS d'ERPC et d'Epic Shreds, a atteint le rang mondial n°3 (score 99.93) dans le Shinobi Performance Pool parmi tous les validateurs Solana, avec des scores liés au vote dépassant 99%.

Ce résultat est l'aboutissement cumulé de multiples améliorations : choix du matériel, optimisation des paramètres du noyau, réglage de la pile réseau, ajustement de l'affinité IRQ, adoption de DoubleZero et optimisations réseau exactement du type que XDP incarne. SLV consolide ce savoir-faire opérationnel dans l'agent IA et le délivre sous une forme que chacun peut reproduire comme la même recette opérationnelle. Les optimisations décrites ici ne sont pas théoriques — elles proviennent d'une exploitation qui a atteint le sommet du réseau.

En combinaison avec la plateforme ERPC

La prise en charge de Solana v4 par SLV fonctionne dans n'importe quel environnement, et elle se marie particulièrement bien avec la plateforme ERPC. ELSOUL LABO exploite un centre de données dédié à Solana sous son propre ASN (AS200261), accordé par RIPE NCC, dans le cadre de la plateforme ERPC — et vous pouvez y utiliser ensemble les optimisations v4, l'automatisation de l'exploitation par SLV et la plateforme ERPC.

ERPC supprime la latence induite par la distance dès l'étape de conception en plaçant les validateurs sources, les endpoints récepteurs et les nœuds de traitement à l'intérieur de centres de données premium où les validateurs Solana sont densément concentrés. Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, serveurs bare metal, SWQoS, l'API Price compatible Pyth, ainsi que Jet Analytics & Indexed RPC peuvent tous être combinés sur la même plateforme. Exploiter un validateur v4 construit avec SLV sur la plateforme ERPC vous permet de combiner les optimisations de SLV avec la vitesse au niveau de la conception d'ERPC, dans le même environnement.

Site officiel d'ERPC : https://erpc.global/fr

Commencez dès maintenant avec les SLV AI Tokens

L'agent IA de SLV fonctionne avec des SLV AI tokens. Vous pouvez commencer gratuitement — une autorisation de 5 € fournit 100,000 tokens, un volume suffisant pour faire l'expérience de l'activation de XDP, de la préparation de l'enregistrement BLS et de l'exploitation d'un validateur Solana v4 par des conversations avec l'agent IA.

ERPC SLV AI Plans : https://erpc.global/fr/price/

Les connexions via les tokens d'API ChatGPT et Claude sont également prises en charge, de sorte que vous pouvez faire fonctionner SLV AI avec vos propres clés d'API.

Vos retours façonnent SLV

SLV évolue chaque jour grâce à vos retours. Cette prise en charge de Solana v4, elle aussi, a pris forme à travers les voix partagées sur le Discord officiel de Validators DAO et grâce à l'exploitation de validateurs au sommet du réseau. Essayez-le et partagez vos avis et demandes avec nous sur le Discord officiel de Validators DAO.

Merci, comme toujours. Nous vous remercions de votre soutien continu à SLV et ERPC.

Contact

Pour toute question concernant SLV et ERPC, veuillez ouvrir un ticket de support sur le Discord officiel de Validators DAO.

Discord officiel de Validators DAO : https://discord.gg/C7ZQSrCkYR

Liens

Site officiel de SLV : https://slv.dev/fr
SLV Getting Started : https://slv.dev/fr/doc/general/getting-started/
SLV GitHub : https://github.com/validatorsDAO/slv
Anza Agave XDP Setup Guide : https://www.anza.xyz/blog/agave-xdp-setup-guide
SIMD-0387 (BLS Pubkey Management in Vote Account) : https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0387-bls-pubkey-management-in-vote-account.md
Site officiel d'ERPC : https://erpc.global/fr
ERPC SLV AI Plans : https://erpc.global/fr/price/
Site officiel d'Epics DAO : https://epics.dev/fr
Discord officiel de Validators DAO : https://discord.gg/C7ZQSrCkYR

SLV achève la prise en charge de Solana v4 — accélération de Turbine par XDP et enregistrement BLS prêt pour Alpenglow, reproductibles par n'importe quel validateur grâce aux conversations avec un agent IA