ERPC améliore considérablement l'infrastructure du réseau Solana. Plateforme de proxy haute performance Rust entièrement améliorée, déployée dans toutes les régions pour RPC partagé, gRPC et ShredStream. Mises à jour Zero-Downtime réalisées

ERPC, exploités par ELSOUL LABO B.V. (Siège: Amsterdam, Pays-Bas; PDG: Fumitake Kawasaki) et Validators DAO, a achevé une importante modernisation de son infrastructure de réseau Solana.

Cette mise à niveau a déjà été appliquée à toutes les régions et à tous les endpoints partagés fournis par ERPC (Solana RPC, Geyser gRPC et ShredStream). Nous avons mis à jour les comportements d'infrastructure qui ont tendance à influencer directement les résultats du monde réel en tant que système intégré, y compris l'initiation de la connexion, le traitement TLS, le contrôle du cache, HTTP/1.1 et HTTP/2 transport, comportement de connexion de longue durée, et mesures pour l'observation et le dépannage.

Tout en maintenant la réactivité quotidienne comme base de référence, nous avons également réorganisé le comportement réseau sous-jacent de sorte qu'il est moins susceptible de devenir biaisé ou instable dans des scénarios où les résultats tendent à se dégrader – comme la volatilité de la charge de pointe, l'instabilité en exploitation soutenue, et les cascades déclenchées par des déconnexions et des reconnexions. Par conséquent, l'environnement est maintenant mieux structuré pour maintenir à la fois la performance et la stabilité dans les opérations pratiques de Solana.

De plus, nous sommes passés à une architecture opérationnelle qui permet d'appliquer des modifications de configuration du réseau et des mises à niveau de plate-forme avec un temps d'arrêt nul. Il n'y a pas de changements aux prix, aux spécifications, à l'authentification ou aux limites tarifaires, ni aux prix ERPC les clients reçoivent les avantages de la mise à niveau sans aucun changement de configuration ou d'exploitation supplémentaire.

Historique

Dans les opérations pratiques de Solana, le temps de réponse moyen et la latence normale sont des exigences de base essentielles. Dans le même temps, il existe des scénarios dans lesquels le comportement de l'infrastructure réseau sous-jacente détermine elle-même les résultats, tels que les moments de charge concentrée, les connexions à longue durée de vie et les phases dans lesquelles se déconnectent et se reconnectent.

Les endpoints partagés en particulier doivent tenir compte à la fois des ruptures de la soumission de la transaction dans des fenêtres à court terme et des connexions toujours disponibles via WebSocket et gRPC. Dans ces conditions, le comportement au niveau de l'infrastructure – initiation à la connexion, poignées de main TLS, comportement de transport, manipulation du cache et récupération à partir d'états inactifs – se reflète directement dans l'expérience utilisateur et les résultats d'exécution.

Avec la réactivité moyenne comme référence explicite, les résultats du monde réel peuvent encore être déterminés par différents facteurs pendant les pics ou en cours d'exploitation. Par conséquent, les opérations pratiques exigent que l'utilisation quotidienne et la continuité des scénarios de défaillance soient réalisées simultanément.

ERPC a conçu et exploité sa propre plate-forme proxy haute performance Rust comme base pour les communications Solana, en maintenant une architecture qui applique la même approche dans toutes les régions tout en évoluant en permanence la plate-forme. Cette mise à niveau réexamine les questions opérationnelles observées en tant que système unifié, depuis l'initiation de la connexion jusqu'à l'exploitation de longue durée, et réorganise en conséquence l'ensemble des fondations du réseau.

Ce qui change ERPC clients

Avec cette mise à jour, ERPC les clients verront d'abord un comportement stabilisé à l'initiation de la connexion. Lors de l'établissement de connexion, y compris TLS, les conditions erronées et les retraits inutiles sont moins susceptibles de se produire, ce qui facilite le traitement fiable des transactions et des flux au début.

Ensuite, nous avons réorganisé les comportements d'infrastructure qui ont tendance à provoquer la volatilité pendant la charge maximale. En combinant le filtrage précoce des connexions inutiles avec des mises à jour simultanées vers HTTP/1.1 et HTTP/2 la cohérence du transport et du délai, la santé de la piscine de connexion, le comportement de cache en litige, et les mesures pour l'observation et le dépannage, nous avons renforcé les conditions qui aident à prévenir le comportement biaisé même lorsque la charge se concentre.

Pour une longue vie WebSocket et gRPC la continuité des connexions s'est améliorée. Fréquence de déconnexion/reconnect/resync les événements — et la probabilité de ces événements en cascade dans les résultats — ont été réduits, ce qui a facilité la mise en place des opérations sur la base d'un temps d'exécution soutenu.

Les améliorations apportées au contrôle des caches et au comportement de transport réduisent également la probabilité de refetches inutiles et de traitement gaspillé pendant la congestion. La largeur de bande et la salle de tête de traitement sont plus susceptibles de rester utilisables et stables, et les mesures élargies et l'observabilité rendent plus facile l'identification des causes profondes et les délais de récupération.

En outre, en permettant des modifications de configuration et des mises à niveau de plate-forme sans temps d'arrêt, nous avons établi des conditions opérationnelles qui facilitent l'amélioration des performances, de la stabilité et de la qualité globale de la plate-forme à haute fréquence. La capacité de continuer à s'améliorer sans arrêter la plate-forme renforce encore la continuité pour les clients.

Détails des améliorations

Cette mise à jour n'est pas présentée comme une version conduite par des noms de fonctionnalités spécifiques ou des numéros de version. Au lieu de cela, il décompose les scénarios qui tendent à dominer les résultats de Solana dans le monde réel dans les couches suivantes – initiation de connexion, TLS, la L4/HTTP frontière, H1/H2 transport, cache, observabilité, comportement d'échec et prérequis opérationnels à long terme – et met à jour la plateforme pour que ces couches se connectent sans contradiction.

Ci-dessous, nous expliquons les améliorations intégrées en ce qui concerne la façon dont elles contribuent à l'expérience client et aux résultats opérationnels.

Améliorations à l'ouverture de connexion et à la manipulation des TLS

Nous avons élargi le contexte TLS géré pendant l'établissement de connexion et mis à jour la structure afin que l'état requis puisse être conservé et appliqué correctement. Il en résulte des conditions erronées et des retraits inutiles moins probables au début de la connexion.

Nous avons également réorganisé la manipulation des SLT, y compris la vérification des certificats et la vérification du nom d'hôte, de sorte que les exigences de sécurité peuvent être satisfaites tout en réduisant les conditions dans lesquelles les défaillances de poignées de main ou les incohérences de manipulation créent des pertes d'initiation qui se transforment en résultats. Il ne s'agit pas seulement d'une amélioration de la sécurité; elle contribue à stabiliser le comportement depuis le début de la connexion jusqu'à l'entrée dans le traitement des charges de travail de Solana.

Nous avons également renforcé les mécanismes qui facilitent l'observation et le dépannage du comportement adjacent aux TLS. Dans les scénarios où l'initiation domine les résultats, la capacité de reproduire les problèmes, d'identifier les causes et de refléter les corrections devient rapidement la capacité qui préserve la qualité de l'expérience.

Préservation de la salle de tête grâce au filtrage précoce des connexions inutiles

Nous avons introduit un mécanisme pour filtrer les connexions TCP à un stade précoce, mettant à jour la plate-forme si illégitimes ou inutiles connexions sont moins susceptibles de pression sur le trafic légitime. Dans les endpoints partagés, les demandes de connexion peuvent augmenter en raison de facteurs externes ou de biais temporaires.

Le filtrage précoce permet de s'assurer que les connexions légitimes sont moins susceptibles de décroître au début, ce qui améliore la probabilité que la tête reste disponible pendant la charge maximale. En conséquence, le comportement est moins susceptible de devenir biaisé même dans les scénarios de charge concentrée, et les conditions pour une distribution de latence stable sont renforcées.

Clarifier le modèle de connexion en réorganisant L4/HTTP Limite

L'infrastructure réseau ne se termine pas à HTTP. L'établissement et la continuité des connexions dépendent de L4 les conditions, et la volatilité à cette couche se propage dans l'expérience de protocole de niveau supérieur.

Dans cette mise à jour, nous avons résumé L4 la gestion du flux et la réorganisation de la structure afin que le modèle de connexion puisse être traité plus explicitement. Il est ainsi plus facile pour la plate-forme de maintenir un comportement cohérent dans tous les scénarios où les connexions continuent de croître, les implémentations des clients varient et l'opération de longue durée provoque des transitions d'état.

Le comportement de réessayer a également été réorganisé pour réduire les modèles dans lesquels la volatilité de courte durée cascades en expérience utilisateur. La stabilité pratique dépend moins de l'élimination des défaillances isolées et plus de la prévention des cascades d'échec.

Améliorations à HTTP/1.1 et HTTP/2 Transport et comportement long-courrier

Nous avons ajouté des mesures qui permettent de suivre de façon cohérente le volume de données transférées à travers HTTP/1.1 et HTTP/2. Il est ainsi plus facile d'identifier les endroits où se produisent des décrochages ou des goulets d'étranglement dans le pipeline de transport, en améliorant à la fois le dépannage et la vitesse à laquelle des correctifs peuvent être appliqués.

Nous avons également réorganisé HTTP/2 comportement de temporisation de l'écriture corporelle de sorte que les décrochages et les accrochages non naturels sont moins probables pendant la charge concentrée ou le flux de longue durée. En fonctionnement à long terme, ce qui importe n'est pas la performance maximale dans les états idéaux, mais la capacité d'empêcher le comportement de s'effondrer pendant les transitions d'état.

Le comportement d'arrêt du temps d'arrêt et la manipulation de la piscine de connexion ont également été examinés, éliminant les facteurs d'instabilité qui tendent à s'accumuler pendant un temps d'exécution soutenu. Sur le HTTP/1.1 côté, nous avons réorganisé un comportement d'arrêt sûr pour les connexions qui détiennent des demandes incomplètes, réduisant les sources de volatilité dans l'utilisation des ressources et le comportement.

Amélioration du contrôle des caches et de la qualité opérationnelle

Nous avons amélioré la capacité de suivre pourquoi un actif n'est pas mis en cache, augmentant la capacité d'explication du comportement de cache. Dans la pratique, ce qui domine, ce n'est pas si la mise en cache existe, mais dans quelles conditions elle est appliquée et dans quelles conditions elle tombe.

Nous avons réorganisé le comportement des verrous, la manipulation de l'impasse et les modèles de revalidation de sorte que l'expérience de dégradation est moins susceptible de cascader lorsque la discorde se produit sous la charge maximale. Nous avons également organisé des contrôles d'expulsion pour les cas où le nombre d'actifs mis en cache augmente, et affiné les comportements de contenu partiel (y compris les demandes de portée), renforçant les conditions qui réduisent les refetches inutiles et la latence sous les charges de travail du monde réel.

Ces améliorations réduisent les cas où le comportement de cache devient plus aberrant, ce qui rend moins probable que les clients doivent concevoir des opérations autour de l'incertitude au niveau de l'infrastructure.

Améliorations du comportement en cas d'échec, de l'exploitation forestière et de l'observation

Le comportement d'échec et l'enregistrement ont été réorganisés de sorte qu'il est plus facile de comprendre ce qui s'est passé lorsque des problèmes se produisent. Modèles dans lesquels les erreurs en aval s'affaissent en cache/transport Le comportement et l'expérience sont réduits, ce qui facilite la localisation du rayon d'explosion.

L'observation et l'amélioration du dépannage ne visent pas à réclamer des incidents nuls, mais à raccourcir le délai de récupération en cas d'incidents. Cela réduit les risques dans les scénarios de pointe et d'exploitation soutenue.

Mises à jour de la dépendance et corrections de sécurité comme prérequis de fonctionnement à long terme

Nous avons intégré des mises à jour de dépendance et des corrections de sécurité pour maintenir les conditions préalables pour le fonctionnement à long terme de la plate-forme. Cela comprend des mises à jour liées à la version Rust minimale supportée (MSRV) et l'alignement CI, renforçant la fondation nécessaire pour évoluer en permanence la plate-forme.

La capacité de se tenir à jour en toute sécurité est elle-même une exigence de qualité à long terme.

Transition vers des opérations Zéro-Downtime

Auparavant, des temps d'arrêt courts pouvaient survenir lors de modifications de configuration du réseau ou de mises à niveau de la plate-forme. Avec cette mise à jour, nous sommes passés à une architecture où ces opérations peuvent être appliquées avec un temps d'arrêt zéro complet.

Les endpoints partagés ont toujours des connexions et des moments continus où le timing compte. Même les temps d'arrêt courts peuvent déclencher des déconnexions, des reconnexions et des cascades de résync, et ce coût peut se propager dans les résultats. Les mises à jour à temps zéro réduisent la probabilité de ces cascades et empêchent la fragmentation des opérations de longue durée.

En même temps, ERPC Il existe maintenant des conditions opérationnelles qui permettent de traduire rapidement les problèmes observés en améliorations. Une fréquence d'itération plus élevée nous permet d'éliminer en permanence la volatilité et le comportement de pointe dans les opérations de production.

Impact par service

Solana RPC (HTTP/ WebSocket)

Les améliorations à l'initiation de connexion, TLS, contrôle de cache et comportement de transport affectent à la fois la lecture des données et la soumission de transaction. Tout en maintenant la facilité d'utilisation au jour le jour, on réduit les facteurs qui faussent les résultats au cours de la charge maximale et on renforce les conditions de conservation de la tête pendant la congestion.

Geyser gRPC

La continuité de connexion s'est améliorée pour une utilisation en continu longue durée. HTTP/2 le transport, la cohérence des délais, la santé de la piscine de raccordement et les mesures élargies du transport travaillent ensemble pour réduire la probabilité de reconnecter/resync les coûts se propagent aux résultats.

ShredStream (Direct Shreds)

Avec la gestion des connexions et les améliorations d'initiation conçues pour une livraison continue, les conditions sont renforcées de sorte que les données manquantes ou les latences sont moins probables sous congestion. Une continuité stable pour la détection et le suivi devient plus facile à maintenir.

R-D et opérations de production

La fondation des systèmes distribués qui comprend ERPC a été reconnu comme un projet de R & D sous le gouvernement néerlandais. WBSO programme. On établit une structure dans laquelle les questions d'observation opérationnelle peuvent être intégrées comme sujets de recherche et améliorées par la vérification et l'itération.

Cette mise à jour de la fondation du réseau est une telle itération appliquée dans toutes les régions, reflétée dans la performance pratique et la stabilité. Le maintien des opérations et le raccordement à la R-D est une condition préalable à la connexion continue de ce qui est observé dans la production à la prochaine mise à jour, plutôt que de s'arrêter à des améliorations ponctuelles.

Dans ERPC, les modes d'utilisation réels, la variabilité de la charge et le comportement en mode de défaillance sont intégrés dans des cycles de vérification et d'amélioration répétés qui augmentent progressivement la qualité de la fondation du réseau. Cette mise à jour a été effectuée dans le cadre intégré des activités de R-D et de production.

Informations pour les clients

Cette mise à jour a déjà été appliquée à toutes les régions et à tous les endpoints partagés. Existence ERPC les clients n'ont pas besoin de modifier la configuration ou les opérations. Il n'y a aucun changement aux prix, spécifications, authentification ou limites tarifaires.

Comme les endpoints partagés doivent prendre en charge simultanément des pics courts et des connexions à longue durée de vie, les conditions ont été réorganisées de sorte que le comportement est moins susceptible de devenir biaisé sous ces charges de travail mixtes. Même lorsque des modifications de configuration ou des mises à jour de plate-forme se produisent pendant les opérations, les modifications sont appliquées avec un temps d'arrêt zéro, de sorte que les clients n'ont pas besoin de planifier pour la fragmentation de connexion ou résync-by-design.

Pour toute question concernant l'architecture, l'optimisation spécifique de la charge de travail ou les retours opérationnelle, veuillez communiquer avec: Discord officiel de Validators DAO.

En connectant continuellement les observations de production et les retours aux améliorations, ERPC a progressivement augmenté sa qualité de fondation. Nous continuerons d'accumuler des améliorations sans temps d'arrêt et de fournir une infrastructure de réseau qui soutient les résultats réels de Solana.

Discord officiel de Validators DAO: https://discord.gg/C7ZQSrCkYR Site officiel d'ERPC: https://erpc.global/en