Validators DAO met à jour le TypeScript Yellowstone Geyser client gRPC dans Solana Stream SDK. L'intégration NAPI-RS améliore la performance et la stabilité pour un flux de fréquence élevée

ELSOUL LABO B.V. (Siège: Amsterdam, Pays-Bas; PDG: Fumitake Kawasaki) et Validators DAO annoncez une mise à jour majeure de version au client TypeScript de l'open source Solana framework de diffusion en continu, en activant le TypeScript Yellowstone Geyser gRPC client pour utiliser NAPI-RS (implémentation native Rust).

Avec cette mise à jour, Solana Stream SDK améliore le traitement de la tête et la stabilité pour les charges de travail en streaming haute fréquence tout en préservant l'expérience de développement TypeScript. Même en cas de pic de circulation et d'éclatement continu, le système est conçu pour rester stable et résistant à la panne. En outre, le code de démarrage a été restructuré au-delà de simples échantillons de connectivité et est maintenant organisé comme une fondation Production-Ready, conçue pour le fonctionnement réel et l'extensibilité.

Les flux de Solana sont utilisés dans des domaines où la réactivité en temps réel se traduit directement en valeur, comme le trading, le suivi, l'analyse et la prise de décisions opérationnelles. En même temps, de nombreux environnements de développement du monde réel sont fondamentalement basés sur le web, faisant de TypeScript un choix fort en raison de la vitesse de développement, de la maintenance, de la flexibilité de l'équipe et de la facilité de transfert.

Ce qui importe donc, ce n'est pas simplement que les flux puissent être traités dans TypeScript, mais que les flux à haute fréquence puissent être traités de manière réaliste et durable dans TypeScript sans s'effondrer dans des conditions opérationnelles à long terme.

La diffusion à haute fréquence implique une réception continue, un traitement, un filtrage, un décodage et une exécution logique en aval, toutes simultanément. Dans ces conditions, un chemin d'exécution de Node.js à simple filetage est sujet à la contre-pression pendant les rafales ou les pics de charge à court terme.

Dans la pratique, cela se manifeste souvent par une augmentation de la latence, le traitement de l'arriéré, la chute des événements et des reconnexions fréquentes. Si TypeScript excelle dans la vitesse de développement et la maintenance, le principal défi opérationnel est de savoir si une salle de traitement suffisante peut être maintenue pendant les conditions de pointe. Cette mise à jour répond directement à ce défi.

Précédemment dans Solana Stream SDK, NAPI-RS a été principalement utilisé dans les client TypeScript Shreds gRPC. Avec cette mise à jour, NAPI-RS (Native Rust) a été étendu au client TypeScript Yellowstone Geyser gRPC largement utilisé.

Cette expansion augmente considérablement les portions du pipeline de streaming qui peuvent bénéficier d'une exécution native à faible overhead tout en conservant une interface basée sur TypeScript. Les repères internes montrent une amélioration substantielle de la tolérance à la contre-pression sous la charge maximale, la salle de traitement augmentant jusqu'à quatre fois. Le résultat clé n'est pas le multiplicateur numérique lui-même, mais le changement vers un comportement qui évite l'effondrement dans des conditions de pointe et peut être traité comme une base opérationnelle fiable.

Comparativement à des alternatives telles que WebAssembly (WASM), NAPI exécute le code natif directement, permettant une latence inférieure et un débit supérieur. Dans Solana Stream SDK, NAPI-RS joue un rôle central dans l'élévation des performances du flux en temps réel sans sacrifier l'expérience du développeur TypeScript.

Geyser gRPC est une interface de base pour recevoir des flux de transactions à faible latence, des mises à jour de compte et des événements de slot. Les retards ou la perte de données se traduisent directement par des occasions d'affaires manquées, des décisions de suivi et d'exploitation retardées et des coûts de développement et d'exploitation accrus.

Permettre le fonctionnement réaliste et résilient de cette interface centrale dans TypeScript n'est pas seulement une question de vitesse. Il réduit les frictions au niveau du développement et des opérations, ce qui permet aux équipes d'améliorer leurs systèmes sans changer de pile ni réécrire la logique de base.

Auparavant, le code de démarrage servait surtout de point d'entrée pour les tests rapides de connectivité. Toutefois, dans les opérations réelles, des problèmes tels que les déconnexions, les reconnexions, la continuité des flux, la duplication ou la perte, le filtrage des abonnements et le contrôle des pics de charge sont inévitables.

Si la structure initiale est trop légère, ces exigences réelles sont souvent ajoutées plus tard de manière ponctuelle, ce qui entraîne des distorsions structurelles et augmente les coûts d'entretien à long terme. Cette mise à jour réorganise le code de démarrage comme une fondation qui peut résister à de réelles demandes opérationnelles dès le départ.

Du côté de TypeScript, les responsabilités ont été clairement séparées pour rendre explicites les points d'extension. Le point d'entrée est maintenu minimal et axé sur le câblage et le démarrage, tandis que la logique de traitement est isolée dans les gestionnaires. Des crochets tels que onTransaction et onAccount définissent des points d'insertion clairs pour une logique personnalisée.

Cette structure permet de modifier localement et de façon prévisible la logique de trading, la logique de détection, les politiques de filtrage et les destinations de sortie. Les définitions d'abonnement ont également été unifiées en code TypeScript plutôt qu'en configuration JSON, améliorant la lisibilité et la sécurité du type. Des constructions lisibles comme le niveau d'engagement. PROCESSUS réduisent la dérive de configuration entre le code et le comportement d'exécution.

En haute fréquence, la vitesse seule est insuffisante; la résilience est également critique. Cette mise à jour continue d'offrir des mécanismes intégrés tels que les commandes de contre-pression (en files d'attente, l'enregistrement des chutes), les mesures pour les événements reçus, traités et abandonnés, le maintien de la connexion/pong), retrait exponentiel, et de la récupération des écarts basée sur slot.

Ce ne sont pas des améliorations facultatives, mais des exigences de base pour les systèmes de streaming de production. Traiter le code de démarrage comme étant Production-Ready signifie intégrer ces hypothèses dès le début plutôt que de les superposer plus tard.

Cette mise à jour cible les développeurs qui veulent exploiter des flux Solana en temps réel dans la production en utilisant TypeScript, des équipes construisant des systèmes de détection, de trading et de surveillance à faible latence avec Yellowstone Geyser gRPC, et les développeurs qui font face à des défis liés à la gestion de pointe et le comportement de reconnexion. L'objectif est d'accroître la viabilité opérationnelle du streaming basé sur TypeScript sans sacrifier ses avantages inhérents.

Les mises à jour de Solana Stream SDK sont disponibles sur GitHub. La retours est la bienvenue GitHub ou via la Discord officiel de Validators DAO.

ERPC fournit une infrastructure de diffusion en continu de Solana dans plusieurs régions. En utilisant le code de démarrage SDK Solana Stream, les développeurs peuvent valider le comportement directement contre réel Geyser gRPC environnement. Par ERPC L'essai gratuit, il est également possible d'évaluer l'infrastructure SDK et streaming ensemble dans des conditions proches de la production réelle. De plus amples renseignements sont disponibles sur site officiel d'ERPC.

Discord officiel de Validators DAO: https://discord.gg/C7ZQSrCkYR Solana Stream SDK (GitHub): https://github.com/ValidatorsDAO/solana-stream Site officiel d'ERPC: https://erpc.global/