Solana«Read Layer, reconstruido: un análisis en profundidad de la caché en memoria de Quicknode »

Quicknode

5 de mayo de 2026 — 13 minutos de lectura

Compartir

Añadir como fuente preferida

Solana Los desarrolladores se topan con obstáculos al utilizar métodos que devuelven grandes cantidades de datos o que requieren analizar el conjunto completo de cuentas. getProgramAccounts se limita o se desactiva. getLargestAccounts nunca devuelve ningún resultado. La causa fundamental es de carácter estructural. Los nodos RPC de Agave son sistemas optimizados para la escritura, y limitar los métodos de lectura que consumen muchos recursos es una necesidad, no una elección estratégica. Las aplicaciones acaban compensando esta situación con lógicas de reintento, capas de almacenamiento en caché e intervalos de sondeo que existen únicamente para sortear las limitaciones de la infraestructura de su proveedor de blockchain.

Aunque el ecosistema en general está empezando ahora a abordar este problema, Quicknode ya ha desarrollado la capa de lectura que el ecosistema de Solana realmente necesita. Dos años de trabajo iterativo, una arquitectura en memoria diseñada específicamente para este fin y unos resultados entre 10 y más de 1.000 veces más rápidos que los valores predeterminados de Agave.

Si eres cliente de « Quicknode », no es necesario que te inscribas para disfrutar de estas ventajas. Tu tarjeta « endpoint » ya te las ofrece.

El problema estructural de la capa de lectura de « Solana »

Los nodos RPC de Agave están diseñados para procesar transacciones, alcanzar el consenso y avanzar en el libro mayor. El estado de las cuentas que mantienen es un subproducto de ese proceso, no un almacén optimizado para la lectura. No hay planificador de consultas, ni índices secundarios nativos, ni separación entre las operaciones de E/S de lectura y escritura.

El escalado de hardware no resuelve este problema. Las consultas de lectura y las tareas de consenso compiten por la misma CPU en la misma máquina, por lo que disponer de más hardware implica asumir los costes propios de un validador (768 GB de RAM, NVMe de alta velocidad, red de gran ancho de banda) sin eliminar la contienda.

Añadir más nodos RPC agrava el problema: los nodos adicionales aumentan la carga en las redes «gossip» y «turbine» de Solana, lo que ralentiza la propagación del estado para los validadores que realmente la necesitan. Escalar la capa de lectura a través de la arquitectura de validadores degrada de forma activa la capa de escritura.

La paginación de datos supone un riesgo de coherencia. Cuando aparecen nuevos bloques entre páginas, el estado de la cuenta subyacente a la respuesta cambia en mitad de la lectura. Las aplicaciones que recorren conjuntos de resultados de gran tamaño reciben datos que se han desplazado antes de que hayan terminado de leerlos.

Cómo « Quicknode » creó una capa de lectura mejorada

Quicknode Se identificó este problema desde el principio, separando las cargas de trabajo de lectura del validador y gestionándolas desde una infraestructura diseñada específicamente para ello. La arquitectura que gestiona el tráfico en la actualidad es la tercera versión de esos esfuerzos. Cada una de ellas se ha ido acercando más a los datos, eliminando las capas de abstracción que añadían latencia sin aportar valor, y el trabajo sigue en marcha.

Iteración 1: Bases de datos relacionales

La primera iteración siguió el enfoque convencional: transferir el estado de las cuentas y los datos del libro mayor a una base de datos relacional, crear índices y realizar consultas en ella. Esto resolvió de inmediato el problema de la contienda por los recursos. Los validadores podían centrarse en el consenso, mientras que un sistema independiente se encargaba de las lecturas. Sin embargo, las bases de datos relacionales conllevan una sobrecarga que resulta significativa a la escala de Solana: planificación de consultas, bloqueo de filas, gestión del registro de escritura anticipada (WAL), autovacuum y la latencia inherente al almacenamiento en disco. Para una cadena de bloques que genera bloques cada 400 milisegundos, cada microsegundo de latencia en la lectura se acumula en los millones de solicitudes diarias. A medida que el tráfico de Solana crecía, la E/S de disco se convirtió en el siguiente obstáculo que había que superar.

Iteración 2: Bases de datos especializadas de alto rendimiento

La siguiente fase comenzó con el propio esquema. El equipo de equipe simplificó y desnormalizó el modelo de datos para adaptarlo a los patrones de acceso reales de Solana, eliminando la estructura relacional que ya no resultaba rentable. Esa reestructuración permitió dar el salto a una base de datos NoSQL de alto rendimiento, diseñada para la ingesta con gran volumen de escrituras y lecturas puntuales de baja latencia, sin la sobrecarga que conllevaba el enfoque relacional en cuanto a planificación de consultas, bloqueo de filas y escritura anticipada.

Tanto el rendimiento como la latencia mejoraron notablemente, y desaparecieron los problemas operativos que conllevaba gestionar un sistema relacional a gran escala (bloqueos de autovacuum, picos de contienda por bloqueos y sobrecarga del WAL).

Iteración 3: Arquitectura totalmente en memoria

La motivación para el siguiente paso fue otra. Los sistemas basados en disco, por muy bien optimizados que estén, comparten un límite insuperable: cada operación de lectura acaba recurriendo a un medio de almacenamiento que es varios órdenes de magnitud más lento que la RAM. Para superar ese límite, la propia ruta de lectura tenía que prescindir del disco.

La arquitectura actual elimina por completo el disco de la ruta de lectura. El estado de AccountsDB reside en memoria, indexado mediante estructuras de datos diseñadas a medida y creadas específicamente para los patrones de consulta específicos de Solana. No hay planificador de consultas, ni recorrido de árboles B, ni fallos en la caché de páginas: solo acceso directo desde la memoria a datos preindexados.

El cambio a una arquitectura totalmente en memoria fue una decisión deliberada para optimizar un único objetivo: el rendimiento bruto de lectura.

La caché de LedgerDB (que almacena el historial de bloques, transacciones y metadatos de cada slot) sigue la misma filosofía de diseño, pero con una estrategia de almacenamiento diferente. El libro mayor de Solana es demasiado grande para caber íntegramente en la memoria, por lo que utiliza un diseño por niveles: los datos de la punta de la cadena se mantienen activos en la memoria, mientras que los datos históricos se sirven desde una base de datos distribuida de alto rendimiento optimizada para esa carga de trabajo.

Cómo funciona: la caché en memoria de Quicknode

Quicknode Solana Cache es un único binario autónomo que gestiona todos los métodos de «tip-of-chain» sin dependencias externas. Solo las consultas al historial del libro mayor acceden a una base de datos externa.

La caché de AccountsDB (que almacena el estado actual de cada cuenta) se encuentra íntegramente en memoria, y las decisiones de diseño que la hacen rápida no son casualidades. Cuatro mecanismos actúan conjuntamente para eliminar todas las fuentes evitables de latencia en las rutas de lectura y escritura.

Por delante de la cadena

La actualidad de los datos es una propiedad de rendimiento, y comienza antes de que llegue cualquier solicitud de lectura. La caché se alimenta directamente desde una fuente de datos «shred-stream», recibiendo las actualizaciones de las cuentas entre 200 y 400 ms antes de lo que tardarían en aparecer en un nodo RPC típico de Agave, que espera a que se formen bloques completos. Dichas actualizaciones llegan a través de una ruta de escritura de baja latencia (escrituras en memoria con un diseño « near » sin bloqueos), de modo que la ventaja inicial se mantiene de principio a fin, en lugar de verse absorbida por la sobrecarga de la ingesta.

El efecto combinado es apreciable en la punta de la red: en condiciones de tráfico de producción, la última ranura observable de la caché se mantiene de forma constante entre 1 y 2 ranuras por delante de un nodo RPC de Agave con una configuración similar. Para cargas de trabajo en las que la pregunta es «¿cuál es el estado actual?», como en el caso de los sistemas de negociación, el MEV, los motores de liquidación y los paneles de control en tiempo real, esto supone la diferencia entre actuar en función del estado en tiempo real y hacerlo basándose en datos que ya están desactualizados.

Estructuras de datos personalizadas

Los índices que permiten la búsqueda de cuentas, las consultas de tokens y el filtrado de cuentas por parte de los programas se construyen a partir de estructuras de datos de bajo nivel seleccionadas mediante pruebas de rendimiento; no se trata de la opción más general, sino de la que ha dado mejores resultados en cuanto a velocidad para los patrones de acceso que el sistema experimenta realmente. El estado compartido utiliza un bloqueo mínimo siempre que es posible, lo que evita que los lectores simultáneos se interfieran entre sí.

Optimizado para el hardware

El sistema profundiza en la utilización del hardware asignando las tareas de ingesta, indexación y respuesta a consultas a núcleos de CPU dedicados, con el fin de minimizar la sobrecarga derivada del cambio de contexto, y seleccionando los asignadores de memoria para cada componente en función de sus perfiles de asignación específicos, con el objetivo de reducir la fragmentación bajo carga.

Cálculo previo

Siempre que es posible, el sistema precalcula y mantiene vistas derivadas a medida que se incorporan los datos del estado de las cuentas: agregados de oferta, listas de cuentas ordenadas, cachés de programas filtrados. Esto desplaza la carga de la CPU de la ruta de lectura, sensible a la latencia, a la ruta de escritura, orientada al rendimiento. Las consultas nunca activan ningún cálculo. Simplemente leen los resultados que ya están ahí. Los 17 ms getSupply La respuesta en las pruebas de rendimiento se debe a este mecanismo en la práctica: el agregado ya existe cuando llega la consulta.

getProgramAccounts: el problema más difícil

getProgramAccounts Realiza una tarea que parece sencilla: devolver todas las cuentas que pertenecen a este programa y que se ajustan a estos filtros. La dificultad radica en que es complicado indexarla correctamente. El programa podría ser cualquiera de los miles de programas implementados, cada uno con su propio esquema de cuentas.

Los filtros suelen ser memcmp operaciones en direcciones de byte específicas, direcciones que solo tienen sentido si se conoce la estructura interna de los datos del programa. A memcmp El desplazamiento 32 significa una cosa en SPL Token y algo totalmente distinto en un programa DEX.

No existe una estrategia de indexación universal que sirva para todos ellos. La indexación getProgramAccounts Para hacerlo de forma eficaz, es necesario comprender cómo son las cuentas de cada programa. El indexador de Quicknode aborda esta cuestión mediante dos estrategias que funcionan conjuntamente:

Programas indexados de forma nativa

En el caso de un pequeño conjunto de programas muy visitados y bien conocidos, Quicknode crea y mantiene de forma continua índices nativos específicos a medida que se actualizan las cuentas. Estos son los programas que dominan el tráfico de Solana : SPL Token (antiguo), SPL Token-2022 y el programa Stake.

Se conocen las estructuras de las cuentas, se conocen los patrones de filtrado que utilizan los clientes, y Quicknode diseñó los índices para aprovechar directamente esas características específicas. Estos índices resuelven las consultas en menos de un milisegundo, independientemente de los millones de cuentas que tenga el programa, y cubren la gran mayoría de getProgramAccounts tráfico, ya que las consultas más populares se concentran en un número reducido de programas.

Programas con indexación dinámica

Para todo lo demás —como cada protocolo DeFi personalizado, cada programa implementado la semana pasada o cada caso de uso específico—, el indexador utiliza una estrategia dinámica. La primera vez que un solicitante pide una combinación de filtros para un programa determinado, la caché crea automáticamente un nuevo índice sobre la marcha. Esa primera solicitud se ejecuta sin optimizar. El indexador tiene que escanear las cuentas del programa y crear el índice antes de poder responder, por lo que el solicitante asume el coste puntual de calentar la caché. E incluso esa ruta en frío supera a Agave.

Cada solicitud posterior del mismo filtro se atiende desde una caché activa, que se actualiza de forma incremental y se mantiene al día a medida que las cuentas cambian en la cadena de bloques. Las actualizaciones se flow a través del mismo canal de transmisión que alimenta los programas indexados de forma nativa, por lo que la vista almacenada en caché nunca se desvía de la realidad.

A partir de ese momento, la latencia es prácticamente constante, independientemente del tamaño de la carga útil o de la popularidad del programa. Un filtro que devuelve diez cuentas y otro que devuelve un millón de cuentas responden con el mismo orden de magnitud, ya que el trabajo ya está hecho. Las respuestas se transmiten directamente desde la memoria preconfigurada, sin que sea necesario volver a calcularlas para cada solicitud.

Los nuevos programas son compatibles desde el mismo día en que se implementan. No es necesaria ninguna integración de esquemas, ninguna configuración manual ni hay que esperar a que un ingeniero equipe añada la compatibilidad. El primer cliente que consulta un nuevo programa inicia la indexación, y todos los clientes posteriores se benefician de ella.

Los índices nativos ofrecen el máximo rendimiento para la mayor parte del tráfico real. El indexador dinámico garantiza que no haya ningún programa ni patrón de filtro que no sea compatible.

p50

p99

getProgramAccounts Es el problema más complejo de la superficie de AccountsDB, por lo que cuenta con su propia estrategia de optimización. Todo lo demás (búsquedas de puntos, agregados, consultas de tokens y metadatos de bloques y ranuras) se gestiona desde el mismo estado en memoria siguiendo los mismos principios de diseño: precalculado siempre que sea posible, sin bloqueos en la ruta de lectura y resuelto mediante una única búsqueda en lugar de un escaneo.

Qué aporta esto en la fase de producción

El resultado es que todos los métodos de AccountsDB, no solo los más destacados, se ejecutan a la velocidad de la memoria bajo carga concurrente. No hay ningún método compatible cuyo rendimiento se vea afectado por la carga a medida que aumenta el tráfico o crece el conjunto de cuentas.

Las cifras que se muestran a continuación proceden de una comparación con un validador Agave de referencia en la misma red. La diferencia de rendimiento se debe a la arquitectura, no a un hardware superior.

Para búsquedas sencillas de puntos, getAccountInfo, getBalance, y getTokenAccountBalance, El indexador de Quicknode iguala a Agave en un tiempo de 2-4 ms. La ruta más frecuente para estos métodos es una única lectura indexada. El tiempo de respuesta viene determinado principalmente por el tiempo de ida y vuelta de la red, y no por el trabajo que varía en función del conjunto de cuentas. El rendimiento varía en los métodos que requieren agregados, vistas ordenadas o índices secundarios que el validador no mantiene.

Hay tres resultados que destacan:

getTokenLargestAccounts En el caso de USDC: Agave tarda casi 100 segundos. Cada solicitud obliga al validador a recorrer todo el programa del token SPL, filtrar por emisión, ordenar y devolver los 20 primeros sin resultados almacenados en caché ni índice ordenado. El indexador de Quicknode mantiene un conjunto ordenado por emisión que se actualiza de forma incremental a medida que cambian los saldos.

getLargestAccounts no se completa en Agave en un plazo de cinco minutos. El validador vuelve a calcular desde cero un agregado ordenado sobre el conjunto completo de cuentas en cada solicitud. El indexador de Quicknode lo mantiene como un índice activo.

getTokenAccountsByDelegate No es compatible con Agave. El indexador de Quicknode lo sirve en milisegundos de un solo dígito.

Las cifras de latencia reflejan la velocidad de cada solicitud individual. El panorama en cuanto a la concurrencia es diferente, pero igual de importante. Cuando un único Agave getTokenLargestAccounts La consulta tarda 97 segundos; esa solicitud ocupa un canal de servicio y retrasa todas las consultas posteriores: una sola solicitud lenta provoca picos de latencia en cadena para todos los usuarios que realizan consultas simultáneas.

QuicknodeEl indexador de ' no presenta ese fallo mode. Todas las consultas se atienden desde un índice en memoria creado previamente, por lo que ninguna solicitud tarda tanto en ejecutarse como para saturar el tráfico simultáneo. Bajo una carga sostenida, la caché de AccountsDB atiende decenas de miles de solicitudes por segundo, manteniendo la latencia P50 por debajo de los 10 ms, y con un rendimiento limitado por la capacidad del hardware, más que por el tamaño del conjunto de cuentas o la complejidad de las consultas.

No todos los métodos tienen una respuesta inferior a 10 ms. Las solicitudes «en frío» a programas que no forman parte del conjunto indexado de forma nativa conllevan un coste de inicialización de entre 11 y 40 segundos en la primera llamada, mientras se establece la suscripción y se rellena la caché filtrada. Todas las solicitudes posteriores al mismo filtro se atienden desde una caché «en caliente» en memoria.

Las consultas del programa Stake a gran escala ilustran el rango medio. Las 81 000 cuentas de Stake de Marinade se resuelven en aproximadamente un segundo en el indexador de Quicknode, frente a los 6,7 segundos que tarda en Agave. La búsqueda en el índice sigue siendo rápida, pero ensamblar y serializar una respuesta con ese volumen supone un trabajo real para la CPU.

Las respuestas a la escala de Raydium V4 (aprox. 705 000 cuentas, aprox. 869 MB de JSON) alcanzan un límite diferente: el tiempo hasta el primer byte es de 1,5 segundos, y la entrega completa tarda aún más, limitada por las restricciones físicas que supone transferir 869 MB por una conexión.

Las mejoras de rendimiento son espectaculares en todos los ámbitos. Todos los métodos se ejecutan entre 10 y 1.000 veces más rápido que un validador Agave predeterminado. En las pruebas de carga con un solo método, una sola instancia soporta 350.000 getTransaction solicitudes por segundo con una latencia inferior a 40 ms, y 120 000 getAccountInfo solicitudes por segundo con un P50 inferior a 20 ms.

En conjunto, las cachés de AccountsDB y LedgerDB cubren aproximadamente el 95 % del tráfico RPC en producción y aproximadamente el 90 % de la especificación JSON-RPC de Solana .

Esto no es la meta

Lo que existe hoy en día es el resultado de dos años de iteraciones. No es el estado final. La inversión de Quicknode en la capa de lectura de Solana es continua. La arquitectura seguirá ganando velocidad, la cobertura de métodos seguirá ampliándose y el trabajo para reducir la brecha entre lo que necesitan los desarrolladores y lo que ofrece la infraestructura no cesa.

Conclusión

SolanaLas cargas de trabajo de lectura y escritura son problemas fundamentalmente diferentes. Merecen arquitecturas fundamentalmente diferentes. Quicknode ha creado desde cero, a lo largo de dos años y sin renunciar al rendimiento, la capa de lectura que el ecosistema de Solana realmente necesita. Las mejoras continuas de esta infraestructura no son algo opcional. Es lo que ya ofrecen todos los Quicknode Solana endpoint .

Crea un « Solana » (endpoint ) en Quicknode y empieza a desarrollar sobre una capa de lectura diseñada específicamente y optimizada continuamente para esta carga de trabajo concreta.