Solana« Read Layer, Rebuilt : dans les coulisses du cache en mémoire d'Quicknode »

Quicknode

5 mai 2026 — 13 min de lecture

Partager

Ajouter comme source préférée

Solana Les développeurs se heurtent à des obstacles lorsqu'ils utilisent des méthodes qui renvoient de grandes quantités de données ou qui nécessitent l'analyse de l'ensemble des comptes. getProgramAccounts est limité ou désactivé. getLargestAccounts ne revient jamais. La cause profonde est d'ordre structurel. Les nœuds RPC Agave sont des systèmes optimisés pour l'écriture, et la limitation des méthodes de lecture coûteuses est une nécessité, et non un choix stratégique. Les applications finissent par compenser cela à l'aide de logiques de réessai, de couches de mise en cache et d'intervalles d'interrogation qui n'existent que pour contourner les limites de l'infrastructure de leur fournisseur de blockchain.

Alors que l'écosystème dans son ensemble commence seulement à s'attaquer à ce problème, Quicknode a déjà mis au point la couche de lecture dont l'écosystème de Solana a réellement besoin. Deux années de travail itératif, une architecture en mémoire spécialement conçue à cet effet, et des performances de 10 à plus de 1 000 fois supérieures à celles des paramètres par défaut d'Agave.

Si vous êtes client d’ Quicknode , vous n’avez pas besoin de vous inscrire pour bénéficier de ces avantages. Votre compte endpoint vous les offre d’ores et déjà.

Le problème structurel de la couche de lecture d'Solana

Les nœuds RPC d'Agave sont conçus pour traiter les transactions, parvenir à un consensus et faire progresser le registre. L'état des comptes qu'ils gèrent est un sous-produit de ce processus, et non un magasin de données optimisé pour la lecture. Il n'y a ni planificateur de requêtes, ni index secondaires natifs, ni séparation entre les E/S de lecture et d'écriture.

L'évolutivité matérielle ne résout pas ce problème. Les requêtes de lecture et le processus de consensus se disputent le même processeur sur la même machine ; ainsi, augmenter la puissance matérielle revient à supporter les coûts associés à un validateur (768 Go de RAM, un disque NVMe rapide, une connexion réseau à haut débit) sans pour autant éliminer ce conflit d'accès.

L'ajout de nouveaux nœuds RPC aggrave le problème : ces nœuds supplémentaires alourdissent la charge des réseaux « gossip » et « turbine » de Solana, ce qui ralentit la propagation des états pour les validateurs qui en ont réellement besoin. L'évolutivité de la couche de lecture via l'architecture des validateurs entraîne une dégradation significative de la couche d'écriture.

La pagination des données présente un risque de cohérence. Lorsque de nouveaux blocs s'insèrent entre deux pages, l'état du compte sous-jacent à la réponse change en cours de lecture. Les applications qui parcourent des ensembles de résultats volumineux reçoivent des données qui ont été déplacées avant qu'elles n'aient fini de les lire.

Comment « Quicknode » a mis au point une couche de lecture plus performante

Quicknode a identifié ce problème très tôt, en séparant les charges de travail de lecture du validateur et en les traitant à partir d’une infrastructure spécialement conçue à cet effet. L’architecture qui gère aujourd’hui le trafic constitue la troisième itération de ces efforts. Chacune de ces itérations s’est rapprochée des données, en supprimant les couches d’abstraction qui ajoutaient de la latence sans apporter de valeur ajoutée, et ce travail se poursuit.

Itération 1 : Bases de données relationnelles

La première itération a suivi l’approche conventionnelle : transférer l’état des comptes et les données du grand livre dans une base de données relationnelle, créer des index et y effectuer des requêtes. Cela a immédiatement résolu le problème de contention des ressources. Les validateurs pouvaient se concentrer sur le consensus tandis qu’un système distinct gérait les lectures. Mais les bases de données relationnelles entraînent une surcharge qui pèse à l’échelle d’ Solana: planification des requêtes, verrouillage des lignes, gestion du journalisation anticipée (WAL), autovacuum et latence inhérente au stockage sur disque. Pour une blockchain produisant des blocs toutes les 400 millisecondes, chaque microseconde de latence en lecture s’accumule sur des millions de requêtes quotidiennes. À mesure que le trafic d’ Solana augmentait, les E/S disque sont devenues le prochain obstacle à surmonter.

Itération 2 : Bases de données spécialisées hautes performances

L'étape suivante a porté sur le schéma lui-même. L'équipe equipe a simplifié et dénormalisé le modèle de données afin de l'adapter aux modèles d'accès réels de Solana, en abandonnant la structure relationnelle qui n'était plus rentable. Cette refonte a permis de passer à une base de données NoSQL haute performance, conçue pour une ingestion à forte intensité d'écriture et des lectures ponctuelles à faible latence, sans les surcoûts liés à la planification des requêtes, au verrouillage des lignes et à l'écriture anticipée qui caractérisaient l'approche relationnelle.

Le débit et la latence se sont nettement améliorés, et les problèmes opérationnels liés à l'exploitation d'un système relationnel à grande échelle (blocages d'Autovacuum, pics de contention sur les verrous, gonflement du journal WAL) ont disparu.

Itération 3 : architecture entièrement en mémoire

La motivation derrière la prochaine étape était différente. Les systèmes s'appuyant sur des disques, aussi bien optimisés soient-ils, se heurtent à une limite infranchissable : chaque opération de lecture finit par passer par un support de stockage dont la vitesse est inférieure de plusieurs ordres de grandeur à celle de la mémoire vive. Pour dépasser cette limite, le chemin de lecture lui-même devait se passer du disque.

L'architecture actuelle élimine totalement le disque du chemin de lecture. L'état de la base de données AccountsDB réside en mémoire, indexé par des structures de données conçues sur mesure pour répondre aux modèles de requêtes spécifiques d'Solana. Il n'y a ni planificateur de requêtes, ni parcours d'arbres B, ni échec de mise en cache de pages : seulement un accès direct en mémoire aux données pré-indexées.

Le passage à une architecture entièrement en mémoire a été un choix délibéré visant à optimiser un seul objectif : les performances brutes en lecture.

Le cache de LedgerDB (qui stocke l'historique des blocs, des transactions et des métadonnées de chaque slot) suit la même philosophie de conception, mais avec une stratégie de stockage différente. Le registre de Solana est trop volumineux pour tenir entièrement en mémoire ; il utilise donc une architecture à plusieurs niveaux : les données de la pointe de la chaîne restent en mémoire active, tandis que les données historiques sont fournies par une base de données distribuée haute performance optimisée pour cette charge de travail.

Fonctionnement : le cache en mémoire d'Quicknode

QuicknodeLe cache « Solana » est un binaire autonome unique qui prend en charge toutes les méthodes « tip-of-chain » sans aucune dépendance externe. Seules les requêtes relatives à l'historique du grand livre accèdent à une base de données externe.

Le cache AccountsDB (qui stocke l'état actuel de chaque compte) est entièrement en mémoire, et les choix de conception qui lui confèrent sa rapidité ne sont pas le fruit du hasard. Quatre mécanismes agissent de concert pour éliminer toute source de latence évitable sur les chemins de lecture et d'écriture.

En tête de la chaîne

La fraîcheur des données est une caractéristique de performance qui commence avant même l'arrivée de toute requête de lecture. Le cache s'alimente directement à partir d'une source de données de type « shred-stream », recevant les mises à jour des comptes 200 à 400 ms plus tôt qu'elles n'apparaîtraient sur un nœud RPC Agave classique qui attend la formation complète des blocs. Ces mises à jour sont acheminées via un chemin d'écriture à faible latence (écritures en mémoire avec une conception sans verrouillage de type « near »), ce qui permet de préserver cette avance de bout en bout plutôt que de la voir absorbée par la surcharge liée à l'ingestion.

L'effet combiné est mesurable au niveau de la pointe : en conditions de trafic de production, le dernier créneau observable du cache affiche systématiquement une avance de 1 à 2 créneaux par rapport à un nœud RPC Agave configuré de manière comparable. Pour les charges de travail où la question est « quel est l'état actuel ? », comme c'est le cas pour les systèmes de trading, le MEV, les moteurs de liquidation et les tableaux de bord en temps réel, cela fait toute la différence entre agir en fonction d'un état en temps réel et agir sur la base de données déjà obsolètes.

Structures de données personnalisées

Les index qui permettent la recherche de comptes, les requêtes de jetons et le filtrage des comptes par programme sont construits à partir de structures de données de bas niveau sélectionnées à l’issue de tests de performance : il ne s’agit pas du choix le plus général, mais de celui qui s’est avéré le plus rapide pour les modèles d’accès réellement rencontrés par le système. L’état partagé utilise un verrouillage minimal dans la mesure du possible, afin que les lecteurs simultanés ne se gênent pas mutuellement.

Optimisé pour le matériel

Le système optimise en profondeur l'utilisation du matériel en affectant les opérations d'ingestion, d'indexation et de traitement des requêtes à des cœurs de processeur dédiés afin de minimiser la surcharge liée aux changements de contexte, et en sélectionnant des allocateurs de mémoire par composant en fonction de leurs profils d'allocation spécifiques afin de réduire la fragmentation en cas de charge élevée.

Précalcul

Dans la mesure du possible, le système précalcule et met à jour les vues dérivées au fur et à mesure que l'état des comptes est intégré : agrégats d'offre, listes de comptes triées, caches de programmes filtrés. Cela permet de transférer la charge de calcul du chemin de lecture, sensible à la latence, vers le chemin d'écriture, axé sur le débit. Les requêtes ne déclenchent jamais de calcul. Elles lisent des résultats qui sont déjà disponibles. Les 17 ms getSupply La réponse obtenue lors des tests de performance illustre ce mécanisme en pratique : l'agrégat existe déjà au moment où la requête arrive.

getProgramAccounts : le problème le plus difficile

getProgramAccounts Elle effectue une tâche qui semble simple : renvoyer tous les comptes gérés par ce programme qui correspondent à ces critères de filtrage. La difficulté réside dans le fait qu’il est complexe de bien l’indexer. Le programme en question peut être n’importe lequel parmi les milliers de programmes déployés, chacun disposant de son propre schéma de comptes.

Les filtres sont généralement memcmp des opérations à des décalages d'octets spécifiques, décalages qui n'ont de sens que si l'on connaît la structure interne des données du programme. A memcmp « à l'offset 32 » désigne une chose dans SPL Token et tout autre chose dans un programme DEX.

Il n'existe pas de stratégie d'indexation universelle qui convienne à tous ces cas. L'indexation getProgramAccounts Pour y parvenir efficacement, il faut comprendre la structure des comptes de chaque programme. L'indexeur de Quicknode répond à ce besoin grâce à deux stratégies qui fonctionnent de concert :

Programmes indexés en mode natif

Pour un petit ensemble de programmes très fréquentés et bien connus, Quicknode crée et met à jour en permanence des index natifs dédiés à mesure que les comptes sont mis à jour. Il s'agit des programmes qui dominent le trafic d'Solana : SPL Token (ancienne version), SPL Token-2022 et le programme Stake.

La structure des comptes est connue, les critères de filtrage utilisés par les clients sont connus, et Quicknode a conçu les index de manière à tirer directement parti de ces spécificités. Ces index traitent les requêtes en moins d'une milliseconde, quel que soit le nombre de millions de comptes gérés par le programme, et ils couvrent la grande majorité des getProgramAccounts le trafic, car les requêtes les plus fréquentes se concentrent sur un petit nombre de programmes.

Programmes à indexation dynamique

Pour tout le reste, comme chaque protocole DeFi personnalisé, chaque programme déployé la semaine dernière, chaque cas d'utilisation de niche, l'indexeur utilise une stratégie dynamique. La première fois qu'un appelant demande une combinaison de filtres pour un programme donné, le cache crée automatiquement un nouvel index à la volée. Cette première requête s'exécute sans optimisation. L'indexeur doit analyser les comptes du programme et construire l'index avant de pouvoir répondre ; c'est donc l'appelant qui supporte le coût ponctuel lié à la mise en température du cache. Et même ce parcours « à froid » surpasse Agave.

Chaque requête ultérieure concernant le même filtre est traitée à partir d'un cache actif, mis à jour de manière incrémentielle, qui reste à jour à mesure que les comptes évoluent sur la blockchain. Les mises à jour sont transmises à flow via le même pipeline de streaming qui alimente les programmes indexés en nat , de sorte que la vue mise en cache ne s'écarte jamais de la réalité.

À partir de ce moment-là, la latence reste pratiquement constante, quelles que soient la taille de la charge utile ou la popularité du programme. Un filtre renvoyant dix comptes et un autre renvoyant un million de comptes répondent dans le même ordre de grandeur, car le travail a déjà été effectué. Les réponses sont transmises directement à partir d'une mémoire pré-assemblée, et ne sont pas recalculées à chaque requête.

Les nouveaux programmes sont pris en charge dès le jour même de leur déploiement. Il n'y a ni intégration de schéma, ni configuration manuelle, ni attente d'une « equipe » technique pour ajouter la prise en charge. Le premier client qui interroge un nouveau programme déclenche l'indexation, et tous les clients suivants en bénéficient.

Les index natifs offrent des performances optimales pour la majeure partie du trafic réel. L'indexeur dynamique garantit qu'aucun programme ni modèle de filtre n'est pris en charge.

p50

p99

getProgramAccounts Il s'agit du problème le plus complexe au sein de la base de données AccountsDB, ce qui explique pourquoi il bénéficie d'une stratégie d'optimisation spécifique. Tout le reste (recherches ponctuelles, agrégats, requêtes de jetons, métadonnées de blocs et d'emplacements) est géré à partir du même état en mémoire, selon les mêmes principes de conception : précalculé dans la mesure du possible, sans verrouillage sur le chemin de lecture, et résolu en une seule recherche plutôt qu'en un balayage.

Ce que cela apporte en production

Il en résulte que toutes les méthodes d'AccountsDB, et pas seulement les plus importantes, s'exécutent à la vitesse de la mémoire sous une charge simultanée. Aucune des méthodes prises en charge ne subit de dégradation de performances lorsque la charge augmente, que ce soit en raison d'une hausse du trafic ou d'une augmentation du nombre de comptes.

Les chiffres ci-dessous proviennent d'une analyse comparative réalisée par rapport à un validateur Agave de référence sur le même réseau. La différence de performances est d'ordre architectural et ne résulte pas d'un matériel plus performant.

Pour les recherches simples par point, getAccountInfo, getBalance, et getTokenAccountBalance, L'indexeur de Quicknode affiche des performances comparables à celles d'Agave, avec un temps de 2 à 4 ms. Le chemin le plus intensif pour ces méthodes correspond à une simple lecture indexée. Le temps de réponse dépend principalement du temps de transit réseau, et non de la charge de travail qui évolue en fonction du nombre de comptes. Les performances divergent pour les méthodes nécessitant des agrégats, des vues triées ou des index secondaires que le validateur ne gère pas.

Trois résultats se démarquent :

getTokenLargestAccounts Pour l'USDC : Agave prend près de 100 secondes. Chaque requête oblige le validateur à parcourir l'intégralité du programme SPL Token, à filtrer par émission, à trier et à renvoyer les 20 premiers résultats, sans résultat mis en cache ni index trié. L'indexeur de Quicknode gère un ensemble trié par émission qui se met à jour de manière incrémentielle à mesure que les soldes évoluent.

getLargestAccounts ne s'exécute pas sur Agave en moins de cinq minutes. À chaque requête, le validateur recalcule à partir de zéro un agrégat trié sur l'ensemble des comptes. L'indexeur de Quicknode le gère sous forme d'index dynamique.

getTokenAccountsByDelegate n'est pas pris en charge sur Agave. L'indexeur de Quicknode le sert en quelques millisecondes.

Les chiffres relatifs à la latence indiquent la vitesse de traitement de chaque requête. La situation en matière de concurrence est différente, mais tout aussi importante. Lorsqu'un seul Agave getTokenLargestAccounts La requête prend 97 secondes ; cette requête monopolise un créneau de service et bloque toutes les requêtes qui la suivent : une seule requête lente entraîne des pics de latence pour tous les utilisateurs connectés simultanément.

QuicknodeL'indexeur ne présente pas ce problème mode. Chaque requête est traitée à partir d'un index en mémoire pré-construit ; ainsi, aucune requête ne s'exécute suffisamment longtemps pour saturer le trafic concurrent. Sous une charge soutenue, le cache AccountsDB traite des dizaines de milliers de requêtes par seconde tout en maintenant une latence P50 inférieure à 10 ms, le débit étant limité par la capacité matérielle plutôt que par la taille de l'ensemble de comptes ou la complexité des requêtes.

Toutes les méthodes ne sont pas inférieures à 10 ms. Les requêtes « à froid » adressées à des programmes ne figurant pas dans l'ensemble indexé nativement entraînent un coût d'initialisation de 11 à 40 secondes lors du premier appel, le temps que l'abonnement soit établi et que le cache filtré soit rempli. Chaque requête suivante adressée au même filtre est traitée à partir d'un cache « à chaud » en mémoire.

Les requêtes du programme « stake » à grande échelle illustrent bien cette fourchette intermédiaire. Les 81 000 comptes « stake » de Marinade sont traités en environ une seconde par l'indexeur d'Quicknode, contre 6,7 secondes sur Agave. La recherche dans l'index reste rapide, mais l'assemblage et la sérialisation d'une réponse à un tel volume sollicitent considérablement le processeur.

Les réponses à l'échelle de Raydium V4 (environ 705 000 comptes, environ 869 Mo de données JSON) atteignent une autre limite : le temps de réponse jusqu'au premier octet est de 1,5 seconde, et la transmission complète prend encore plus de temps, en raison des contraintes physiques liées au transfert de 869 Mo par réseau.

Les gains de performances sont spectaculaires à tous les niveaux. Chaque méthode s'exécute entre 10 et 1 000 fois plus vite qu'un validateur Agave standard. Lors de tests de charge portant sur une seule méthode, une seule instance peut traiter 350 000 getTransaction requêtes par seconde avec une latence inférieure à 40 ms, et 120 000 getAccountInfo requêtes par seconde avec un temps de réponse P50 inférieur à 20 ms.

À eux deux, les caches AccountsDB et LedgerDB couvrent environ 95 % du trafic RPC en production et environ 90 % de la spécification JSON-RPC de l'Solana .

Ce n'est pas la ligne d'arrivée

Ce qui existe aujourd'hui est le fruit de deux années d'itérations. Ce n'est pas une fin en soi. L'investissement d'Quicknode dans la couche de lecture d'Solana est permanent. L'architecture continuera de gagner en rapidité, la couverture des méthodes ne cessera de s'étendre, et le travail visant à combler l'écart entre les besoins des développeurs et ce qu'offre l'infrastructure se poursuit sans relâche.

En résumé

SolanaLes charges de travail de lecture et d'écriture constituent des problèmes fondamentalement différents. Elles méritent des architectures fondamentalement différentes. Quicknode a développé de toutes pièces, en deux ans, la couche de lecture dont l'écosystème de Solana a réellement besoin, sans faire de compromis sur les performances. Les améliorations continues apportées à cette infrastructure ne sont pas une option facultative. C'est ce que chaque Quicknode Solana endpoint offre déjà.

Créez une instance « Solana »endpoint sur Quicknode et commencez à développer en vous appuyant sur une couche de lecture spécialement conçue et optimisée en permanence pour répondre précisément à cette charge de travail.