Validators DAO lance Solana Stream SDK v1.1.1 — Ouvrir un client de démarrage de Rust pour les shreds UDP les plus rapides
Validators DAO lance Solana Stream SDK v1.1.1 — Ouvrir un client de démarrage de Rust pour les shreds UDP les plus rapides

Solana Stream SDK, un client open source pour Solana développé et exploité par ELSOUL LABO B.V. (Siège: Amsterdam, Pays-Bas; PDG: Fumitake Kawasaki) et Validators DAO, a publié sa dernière version, v1.1.1. Avec cette version, un client de démarrage basé sur Rust qui gère directement UDP Shreds – la couche la plus rapide du réseau Solana – a été nouvellement open source.
Cette version présente un exemple concret d'implémentation qui reçoit Shreds sur UDP directement entre les validateurs, sans passer par le niveau supérieur API des couches telles que RPC, WebSocketou gRPC, et les traite par reconstruction et détection par le chemin le plus court possible. Pour les cas où la latence se traduit directement en valeur, cela fournit un point de départ pratique pour fonctionner à la couche la plus rapide dans les environnements réels.
Le lieu: différences dans le calendrier de détection
Sur Solana, même pour le même événement en chaîne, le moment auquel il peut être détecté varie considérablement selon l'endroit où il est observé, que ce soit à partir de Shreds, Geyser gRPC ou RPC / WebSocket. Du point de vue de l'heure de détection, on observe d'abord des shreds, suivis par Geyser gRPC, et puis RPC / WebSocket.
Les shreds représentent les données au stade où les fragments qui composent un bloc sont échangés directement entre les validateurs. Geyser gRPC livre des événements tels que les blocs, les journaux et les mises à jour de compte après Shreds ont été reçus et organisés en interne par un nœud. RPC / WebSocket Installez-vous au niveau le plus élevé, donnant accès à des données déjà stockées et organisées par des requêtes et des abonnements.
Pourquoi UDP Shreds forme le calque le plus rapide
Les shreds sont livrés sur UDP. UDP n'implique pas d'établissement de connexion, de contrôle de retransmission ou de commande de garanties, en maintenant les frais de protocole à un minimum absolu. Par conséquent, dans des conditions identiques, les données arrivent plus rapidement qu'avec gRPC ou WebSocket, qui sont basés sur TCP.
Lorsque l'on vise la détection la plus rapide possible sur Solana, UDP Shreds devient le premier choix par nécessité, guidé par ces caractéristiques de communication et la conception du réseau.
Pourquoi pump.fun est utilisé comme exemple
Validators DAO a reçu un grand nombre de demandes de renseignements concernant la détection la plus rapide possible en utilisant UDP Shreds. Parmi eux, la demande la plus courante a été de détecter les menthes en jeton et les premiers échanges sur pump.fun le plus rapidement possible.
Pour les menthes en jetons et les trades initiaux, les différences de l'ordre de dizaines de millisecondes peuvent avoir une incidence significative sur les résultats. pump.fun est donc un exemple concret où les caractéristiques et la valeur de la couche la plus rapide sont les plus clairement démontrées et où la demande est particulièrement concentrée. Dans cette version, le code de démarrage inclut la logique de détection basée sur pump.fun comme configuration par défaut, reflétant cette demande réelle. Cela ne limite pas l'utilisation de pump.fun, mais sert plutôt d'exemple pratique pour reproduire de façon réaliste la détection de couche la plus rapide.
Réagir à des événements significatifs, pas tout
Lorsqu'on traite les shreds UDP, un volume extrêmement important de transactions transite par le système, y compris beaucoup de transactions qui sont trop petites pour être importantes pour les décisions stratégiques ou UX.
Le code de démarrage adopte une conception qui permet de fixer un seuil de valeur, permettant la détection uniquement pour les transactions dépassant ce seuil. Ce filtrage n'est pas appliqué par post-hoc RPC les vérifications, mais directement à l'étape de l'évaluation immédiatement après la reconstruction des Shreds. Le seuil est facultatif: il permet de détecter toutes les transactions. Les utilisateurs peuvent définir la quantité de données à réagir en fonction de leur cas d'utilisation spécifique.

L'exemple ci-dessus montre des journaux qui détectent seulement les menthes et les trades liés à pump.fun avec des quantités de 1 SOL ou plus, illustrant un état où seules les informations pertinentes sont saisies à haute densité sur la couche la plus rapide.
L'échange de vitesse: information non confirmée
UDP Les shreds contiennent des informations avant qu'un bloc ne soit complètement finalisé. Par conséquent, des transactions en échec peuvent apparaître, et les données peuvent être manquantes ou arriver hors de la commande. Ce n'est pas un défaut, mais une propriété inhérente à la couche la plus rapide elle-même.
En traitant les données telles qu'elles circulent sans attendre la confirmation ou la normalisation, les changements peuvent être détectés plus tôt que sur toute autre couche. Ce code de démarrage reconnaît explicitement cette prémisse et démontre une implémentation qui réalise la détection en utilisant seul Shreds, sans compter sur RPC.
Une structure conçue pour la clarté
En interne, le traitement est organisé comme une séquence claire: recevez → tampon → reconstruire → évaluer → sortie. Les responsabilités telles que la réception UDP, le tamponnage FEC, le deshredding, la logique de la montre et la sortie sont séparées et traitées comme des éléments indépendants. Cette conception permet aux utilisateurs d'exécuter le code comme-est initialement, puis de modifier progressivement seulement les pièces qui deviennent nécessaires pour leur cas d'utilisation.
Ressources
GitHub (Solana Stream SDK): https://github.com/ValidatorsDAO/solana-stream
Rust: https://crates.io/crates/solana-stream-sdk
ERPC Site web: https://erpc.global/
Discord officiel de Validators DAO: https://discord.gg/C7ZQSrCkYR
Questions et commentaires concernant Solana Stream SDK v1.1.1 et le client UDP Shreds sont les bienvenus sur le Discord officiel de Validators DAO.


