Cómo diseñamos para la escalabilidad en Solana

Solana no se parece a ninguna otra blockchain. Su arquitectura fue diseñada desde el primer día para llevar el throughput a los límites del hardware: ejecución paralela, control de tiempo integrado, envío de transacciones sin mempool, todo funcionando en conjunto para entregar miles de transacciones por segundo con finalidad en menos de un segundo. Y con Firedancer ya en mainnet y Alpenglow en el horizonte, ese límite está por elevarse drásticamente.

Construir infraestructura que se mantenga a ese ritmo requiere más que nodos rápidos. Requiere diseñar cada capa del stack asumiendo que la carga de mañana superará ampliamente la de hoy.

Así es como abordamos la escalabilidad cuando reconstruimos nuestra plataforma de Solana desde cero, y así es como la estamos posicionando para lo que viene.

El modelo de escalabilidad de Solana es fundamentalmente distinto

Gran parte de la infraestructura blockchain está diseñada en torno al modelo de ejecución de Ethereum: procesamiento secuencial de transacciones, un trie de estado global y una salida de datos relativamente modesta. Solana rompe todas esas suposiciones.

Sealevel, el runtime paralelo de Solana, requiere que cada transacción declare de antemano sus conjuntos de lectura y escritura, lo que permite que transacciones sin superposición se ejecuten simultáneamente en distintos núcleos de CPU. Proof of History integra un reloj criptográfico directamente en el ledger, eliminando la sobrecarga de coordinación que ralentiza el consenso en otras cadenas. Y Gulf Stream envía las transacciones directamente al próximo productor de bloques en lugar de dejarlas esperando en un mempool, reduciendo aún más la latencia de confirmación.

El resultado es una red que produce enormes cantidades de datos a una velocidad extremadamente alta: más de 4 petabytes al año en los momentos de mayor actividad. La infraestructura que sirve estos datos no puede tratarlos como si fuera Ethereum con un esquema de RPC distinto. Necesita estar diseñada específicamente en torno a los patrones de datos, las características de acceso y la escala propios de Solana.

Esa comprensión guió cada decisión que tomamos.

Diseñar en función de las características de datos de Solana

El perfil de datos de Solana plantea un conjunto específico de desafíos de infraestructura. Los bloques son grandes y densos. Las consultas históricas abarcan rangos enormes. Los desarrolladores necesitan tanto búsquedas puntuales aleatorias (obtener una sola transacción por firma) como escaneos secuenciales masivos (recorrer el historial completo de firmas de una dirección). Y todo esto tiene que ocurrir con baja latencia, a nivel global.

Cubrimos los detalles técnicos profundos de nuestra arquitectura de archivo en una publicación técnica aparte: la migración a HBase, la ingesta con triple verificación, los pipelines de autorreparación y las optimizaciones específicas que nos permitieron alcanzar más de 100,000 RPS por región en getTransaction. Esta publicación trata sobre los principios de diseño detrás de esas decisiones.

El principio central: separar las responsabilidades que necesitan escalar de forma independiente. La infraestructura tradicional de Solana agrupa la ingesta de datos, el almacenamiento y el servicio en un único nodo validador monolítico. Ese acoplamiento significa que no se pueden escalar las lecturas fácilmente, no se puede reiniciar un servicio sin horas de inactividad, y no se puede optimizar el diseño del almacenamiento sin tocar todo el stack.

Descompusimos el sistema en servicios independientes: servidores RPC livianos que arrancan en segundos, ingestores dedicados con control granular sobre qué tipos de datos maneja cada instancia, y una capa de almacenamiento diseñada específicamente para los patrones de acceso de Solana. Cada capa escala según sus propios términos. Cuando el tráfico aumenta, agregamos instancias RPC adicionales en segundos sobre la misma capa de datos. Cuando una nueva región necesita entrar en línea, la capa de almacenamiento se replica de forma independiente respecto a la capa de servicio.

La confiabilidad como requisito previo para la escalabilidad

Hay un patrón recurrente en infraestructura: los equipos optimizan para velocidad, chocan con un límite de escala y luego se dan cuenta de que ese límite en realidad era un problema de confiabilidad. Las conexiones interrumpidas, los datos incompletos y las fallas silenciosas bajo carga son, en el fondo, fallas de escalabilidad disfrazadas.

Diseñamos pensando en esto desde el principio. Nuestra arquitectura multi-región incluye de 3 a 5 capas de failover autónomo: si un nodo, un rack o una región completa se degrada, el tráfico se redirige automáticamente.

En cuanto a la integridad de los datos, cada registro se escribe dos veces, se valida de forma programática y se escanea continuamente para verificar que esté completo. Si aparece una discrepancia, nuestros pipelines de autorreparación reingieren y corrigen la brecha automáticamente, verificando de forma cruzada hasta 30-50 direcciones relacionadas por bloque. Todo el proceso de reparación es automatizado y funciona de forma continua. No es un panel de monitoreo estático con alertas.

La integridad de los datos en Solana es un problema más difícil de lo que la mayoría reconoce. El volumen y la velocidad de los datos son tales que incluso pequeñas brechas se acumulan rápidamente, y es un punto de dolor común entre los equipos de desarrollo, muchos de los cuales han reportado datos faltantes o inconsistentes por parte de sus proveedores de infraestructura. Es uno de esos problemas que resultan invisibles hasta que la aplicación de un desarrollador falla porque una transacción no se indexó o un historial de firmas está incompleto. Tratamos la corrección de los datos como algo no negociable, no como un esfuerzo de "mejor intento".

El resultado es un 99.99% de tiempo de actividad, respaldado por el mismo rigor operativo que hemos aplicado durante más de 8 años potenciando aplicaciones como Polymarket en la noche de las elecciones y el lanzamiento de mainnet de World. La confiabilidad a este nivel no es una funcionalidad: es lo que hace posible el resto de la historia de escalabilidad.

Diseñar para la próxima era de throughput de Solana

El throughput actual de Solana se mide en miles de transacciones por segundo. La hoja de ruta del protocolo apunta a órdenes de magnitud más, y la infraestructura que no esté diseñada para esa trayectoria se convertirá en el cuello de botella.

Firedancer, el cliente validador independiente de Jump Crypto escrito en C, entró en producción en mainnet a fines de 2025. En condiciones de laboratorio, ha demostrado más de 1 millón de transacciones por segundo. Su arquitectura modular basada en tiles, su red con kernel-bypass y su verificación paralela de firmas representan un replanteamiento fundamental de cómo el software validador utiliza el hardware. A fines de 2025, aproximadamente el 21% del stake de Solana ya corría Firedancer, y la adopción se está acelerando.

Junto con Firedancer, la actualización del protocolo Alpenglow busca reescribir el mecanismo de consenso de Solana y reducir la finalidad de bloque a aproximadamente 150 milisegundos. Y propuestas como SIMD-0370 eliminarían por completo el límite de cómputo a nivel de bloque, permitiendo que los bloques escalen según lo que el hardware pueda procesar realmente, en lugar de un límite artificial impuesto por software.

Además, la compresión ZK, desarrollada por Light Protocol, permitirá comprimir múltiples estados de cuenta en una sola cuenta onchain usando pruebas de conocimiento cero. Esto aborda el creciente desafío de almacenamiento de estado de Solana y abre patrones de diseño de aplicaciones completamente nuevos.

Nuestra infraestructura está diseñada teniendo en cuenta estas actualizaciones. La arquitectura descompuesta nos permite escalar cada capa de forma independiente a medida que crecen los requisitos de throughput. El despliegue multi-región proporciona la distribución geográfica necesaria para manejar tráfico global a volúmenes más altos. Esto nos da una ventaja de throughput 2x sobre otros proveedores de RPC de Solana, que es un punto de partida, no un techo.

Qué habilita una infraestructura escalable para los builders

La escalabilidad determina directamente qué pueden construir los desarrolladores. Durante los últimos ocho años, hemos acompañado a builders desde su primera llamada a la API a través de cada punto de inflexión que siguió. Equipos como Circle, Robinhood y OpenSea escalaron en Alchemy desde prototipos iniciales hasta productos que sirven a cientos de millones de usuarios.

• Las consultas de archivo en milisegundos permiten que las wallets muestren historiales de transacciones completos de forma instantánea.
• Las consultas orientadas a lo reciente eliminan la necesidad de escanear años de datos antiguos solo para mostrar la actividad más reciente de un usuario.
• getTokenLargestAccounts devolviendo 1,000 resultados en lugar de 20 les da a las plataformas de analítica vistas mucho más completas de la distribución de tokens.
• Las transacciones sin gas nativas eliminan la fricción de onboarding que reduce la conversión.
• Las escrituras 100% staked aseguran que las transacciones lleguen a productores de bloques reales, mejorando la confiabilidad de confirmación.

Estas capacidades existen porque tratamos la escalabilidad como un principio fundamental.

El camino por delante

Solana está evolucionando rápido. La capacidad de la red aumentará, y las aplicaciones construidas sobre ella serán cada vez más exigentes a escala.

Nuestro compromiso es mantenernos a la vanguardia, invirtiendo en menor latencia, mayor throughput, acceso a datos más profundo y nuevas capacidades que habiliten casos de uso que hoy todavía no son posibles. La infraestructura nunca debería ser la razón por la que un builder tenga que comprometer su producto.

Todo lo que describimos está disponible hoy.

• Empieza en alchemy.com/solana
• Contáctanos para benchmarking personalizado, precios especializados o más información.

Preguntas frecuentes

¿Qué hace que la escalabilidad de Solana sea diferente a la de otras blockchains?

Solana usa ejecución paralela de transacciones a través del runtime Sealevel, Proof of History para el control de tiempo integrado, y Gulf Stream para evitar los mempools, lo que permite miles de transacciones por segundo con finalidad en menos de un segundo, y produce más de 4 petabytes de datos al año en los momentos de mayor actividad.

¿Cómo mejora la arquitectura descompuesta de Alchemy la escalabilidad en Solana?

Alchemy separa la ingesta de datos, el almacenamiento y el servicio en servicios independientes que escalan según sus propios términos, lo que permite que los servidores RPC arranquen en segundos, que el tráfico escale sin tiempo de inactividad, y que se desplieguen nuevas regiones sin tocar todo el stack.

¿Qué es Firedancer y cómo impacta el throughput de Solana?

Firedancer es el cliente validador independiente de Jump Crypto, escrito en C, que entró en producción en mainnet a fines de 2025, demostrando más de 1 millón de transacciones por segundo en condiciones de laboratorio gracias a su arquitectura modular, red con kernel-bypass y verificación paralela de firmas.

¿Cómo garantiza Alchemy la integridad de los datos a la escala de Solana?

Cada registro se escribe dos veces, se valida de forma programática y se escanea continuamente para verificar que esté completo, con pipelines de autorreparación que reingieren y corrigen automáticamente cualquier brecha verificando de forma cruzada hasta 30-50 direcciones relacionadas por bloque.

¿Qué es la compresión ZK y por qué es importante para Solana?

La compresión ZK, desarrollada por Light Protocol, permite comprimir múltiples estados de cuenta en una sola cuenta onchain usando pruebas de conocimiento cero, lo que aborda el creciente desafío de almacenamiento de estado de Solana y habilita nuevos patrones de diseño de aplicaciones.

¿Cómo logra Alchemy consultas de archivo más rápidas en Solana?

Usamos una capa de almacenamiento basada en HBase optimizada para los patrones de acceso de Solana, consultas orientadas a lo reciente y una arquitectura multi-región para entregar consultas de archivo en milisegundos a más de 100,000 RPS por región en métodos como getTransaction.

¿Qué hace que la infraestructura de Solana de Alchemy sea confiable a escala?

Una arquitectura multi-región con de 3 a 5 capas de failover autónomo, pipelines de autorreparación automatizados y validación continua de datos entregan un 99.99% de tiempo de actividad, garantizando que el tráfico se redirija automáticamente si un nodo, un rack o una región completa se degrada.

¿Qué funcionalidades para desarrolladores habilita la infraestructura escalable de Alchemy?

Consultas de archivo en milisegundos, consultas orientadas a lo reciente, getTokenLargestAccounts devolviendo 1,000 resultados en lugar de 20, transacciones sin gas nativas, y escrituras 100% staked para una confiabilidad de confirmación mejorada.