ERPC publie Solana Stream SDK v4.0.0 pour accélérer le traitement des Shreds UDP et la reconnexion gRPC
ELSOUL LABO B.V. et Validators DAO ont officiellement publié Solana Stream SDK v4.0.0 le 6 novembre 2026. Ce SDK open source permet de traiter les données de streaming de Solana. Les benchmarks locaux ont mesuré un traitement interne des Shreds UDP en Rust environ 108 fois plus rapide et un débit multiplié par environ 4 pour la file d’événements TypeScript. Geyser gRPC reprend également la réception des mises à jour plus rapidement après une déconnexion. Le SDK est utilisable gratuitement, avec des exemples en Rust et en TypeScript pour aider les développeurs à démarrer.
Pour tirer parti d’un acheminement des données à faible latence dans une application, la vitesse de traitement des données entrantes compte également. La version 4.0.0 rend le traitement interne après l’arrivée des données plus efficace et améliore le rétablissement de la connexion après une déconnexion. Son utilisation avec ERPC Shreds UDP Forwarding Premium permet aux développeurs d’améliorer à la fois le chemin d’acheminement et l’implémentation de la réception dans leurs applications Solana.
Des améliorations du traitement et de la reconnexion mesurées dans trois tests
Dans le chemin de réception UDP en Rust, la v4 accélère le décodage des datagrammes, leur insertion dans un tampon interne et le deshredding, qui reconstruit les données à partir des Shreds. Elle réduit la charge de traitement en révisant le nettoyage de l’état interne et les lectures de l’horloge auparavant répétés pour chaque paquet, tout en conservant les durées de rétention des données. Dans la comparaison, le temps de traitement interne par datagramme est passé de 94 236 ns à 855–881 ns, soit une accélération d’environ 108 fois.
Le benchmark a été exécuté sur un Mac équipé d’une puce Apple série M, avec 403 200 datagrammes répartis sur 300 slots par exécution. Les résultats comparent les médianes de cinq exécutions. La mesure couvre le chemin interne decode→insert→deshred. Elle exclut le temps d’acheminement sur le réseau et le traitement ultérieur dans l’application de l’utilisateur. Réduire le travail nécessaire à la reconstruction des Shreds entrants permet aux développeurs de consacrer davantage de ressources de calcul à la logique applicative.
Les exemples et les projets de démarrage Geyser gRPC en TypeScript réduisent l’attente lorsque des événements sont encore présents dans la file, ce qui permet de récupérer plus efficacement les données reçues. Dans un test portant uniquement sur la file et traitant deux millions d’événements avec Node.js 24, le débit est passé de 5,7–7,4 millions à 24,8–29,4 millions d’événements par seconde, soit une amélioration d’environ un facteur 4.
Pour Geyser gRPC, le client chargé de la reconnexion et le délai avant la première nouvelle tentative ont été mis à jour. Lors d’un test provoquant 20 déconnexions sur un serveur tonic local, l’intervalle médian entre les mises à jour reçues avant et après chaque déconnexion est passé de 552 ms avec le runner 3.0 à 103 ms avec le runner 4.0. Cette mesure représente l’intervalle jusqu’à la reprise des mises à jour dans l’environnement de test local.
Ces trois résultats proviennent de tests distincts, dont les périmètres et les conditions diffèrent. Ils montrent respectivement les améliorations du traitement interne en Rust, de la file d’événements TypeScript et de la reconnexion gRPC. Les détails de l’implémentation et les conditions de test sont disponibles dans la PR #129, indiquée dans les liens utiles.
Maintien de la prise en charge d’Alpenglow et mise à jour des clients
La prise en charge d’Alpenglow a été introduite dans la v3.0.0. La version 4.0.0 conserve la distinction entre les marqueurs de bloc, qui représentent les mises à jour d’en-tête, de pied de bloc et de parent, et les entrées, qui contiennent les transactions. Les applications peuvent traiter les informations sur la structure des blocs séparément des entrées qu’elles doivent traiter.
La version 4.0.0 met les clients à jour vers Agave 4.4.1 et Yellowstone gRPC 17.x. Lors de la reconnexion, un événement
Disconnected peut signaler des informations permettant d’identifier les données partiellement reçues, ainsi que la position de reprise. Les applications disposent ainsi des informations nécessaires pour mettre en œuvre leur propre traitement des données retransmises en double et des données reçues seulement en partie.La migration de la v3 vers la v4 conserve les définitions protobuf de Geyser, tout en mettant à jour les événements de reconnexion et les types de messages et de transactions Solana utilisés en Rust. Le guide de migration publié décrit les modifications des gestionnaires d’événements et des versions des dépendances.
Rust pour UDP, Rust et TypeScript pour gRPC
Le paquet Rust publié solana-stream-sdk et le paquet TypeScript @validators-dao/solana-stream-sdk sont tous deux disponibles en v4.0.0. Les langages pris en charge pour chaque type de connexion sont indiqués ci-dessous.
| Type de connexion | Langages pris en charge |
|---|---|
| Shreds UDP | Rust |
| Geyser gRPC | Rust et TypeScript |
| Shreds gRPC | Rust et TypeScript |
Utilisez le client Rust pour recevoir des Shreds via UDP. L’exemple et le projet de démarrage UDP en Rust utilisent le SDK v4.0.0 publié et permettent d’essayer la réception des données, leur reconstruction à partir des Shreds et la détection des instructions d’un programme à surveiller. Modifiez le programme surveillé et le traitement qui suit la détection pour en faire le point de départ de votre propre application.
Pour le développement en TypeScript, vous pouvez utiliser Geyser gRPC ou Shreds gRPC. Les améliorations de la file d’événements de cette version sont intégrées aux exemples et aux projets de démarrage Geyser gRPC. Choisissez l’implémentation publiée qui correspond à votre langage et à votre mode d’acheminement.
Tirer parti de Shreds UDP Forwarding Premium
ERPC Shreds UDP Forwarding Premium relie plusieurs nœuds en maillage dans chaque région et transmet, pour chaque Shred, la copie reçue en premier par ce maillage. Le moment de l’arrivée par le chemin d’acheminement et le temps de reconstruction dans le SDK après cette arrivée influencent tous deux le délai avant que les données reçues soient exploitables. Les améliorations de la réception UDP en Rust peuvent être appliquées côté réception aux données transmises par Premium.
Lors de la comparaison à Francfort le 30 octobre 2026, Standard et Premium ont été capturés simultanément pendant 120 secondes sur une même machine, avec la même horloge. Les charges utiles UDP au contenu identique ont été appariées à partir de la capture pcap. Premium est arrivé en premier pour 98 % de cet ensemble commun, avec une différence d’arrivée médiane de 1,78 ms. Parmi les charges utiles observées sur Standard, 93,9 % l’ont également été sur Premium.
Le graphique Premium montre les différences d’heure d’arrivée entre les chemins d’acheminement, tandis que le graphique du SDK présente le traitement interne côté réception et le rétablissement de la connexion. Dans une application réelle, enregistrer à la fois l’arrivée des paquets et l’instant où une instruction pertinente est détectée permet de vérifier dans quelle mesure l’avance à l’acheminement se retrouve dans le résultat du traitement.
Comparer dans votre environnement avec la facturation horaire et les exemples
Shreds UDP Forwarding Premium est disponible avec une facturation horaire à 1,39 € par heure. Activez le service depuis le tableau de bord et vérifiez la réception avec le projet de démarrage UDP en Rust. En conservant la même région, le même serveur de réception et la même charge applicative, vous pouvez évaluer les différences d’heure d’arrivée séparément du temps de traitement après réception.
Enregistrez d’abord votre adresse IPv4 publique et votre port UDP dans le tableau de bord, puis autorisez le trafic entrant depuis les sources indiquées. Après avoir vérifié la réception des paquets et la reconstruction des données avec le projet de démarrage UDP en Rust, ajoutez les programmes que vous souhaitez surveiller et les traitements réels de votre application à l’évaluation. Associez les exemples au service d’acheminement pour mesurer le délai entre la réception et la détection dans votre propre environnement.
Liens utiles
- Exemple et projet de démarrage UDP en Rust : https://github.com/ValidatorsDAO/solana-stream/tree/main/temp-release/shreds-udp-rs
- Guide de migration vers Solana Stream SDK v4 : https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/migration-v4.md
- Améliorations des performances du SDK et résultats des tests : https://github.com/ValidatorsDAO/solana-stream/pull/129
- Documentation Shreds UDP Forwarding : https://erpc.global/fr/doc/shredstream/udp-forwarding/
- Utiliser Shreds UDP Forwarding Premium : https://dashboard.erpc.global/fr/user/shreds?plan=udp
- Tarifs ERPC : https://erpc.global/fr/price/
