Cómo Alchemy creó los métodos de archivo más rápidos en Solana

Hacia fines del año pasado, anunciamos nuestra nueva oferta de producto para Solana, y una de las características clave de ese producto es el rendimiento de nuestros métodos de archivo: hasta 20 veces más rápidos que cualquier otra solución del mercado.

Con nuestra oferta para Solana, los desarrolladores pueden consultar transacciones, bloques y firmas históricas a una velocidad sin precedentes mediante una interfaz JSON RPC estándar. Eso no fue fácil de construir, y en este post explicamos cómo lo hicimos.

¿Qué son los métodos de archivo en Solana?

En Solana, los métodos de archivo se refieren a llamadas RPC que recuperan datos históricos de la blockchain, como getTransaction, getBlock y getSignaturesForAddress.

Estos endpoints de archivo son la base de las aplicaciones onchain. Wallets, indexadores, proveedores de analítica, exploradores y muchos más dependen de estos datos históricos para ofrecer datos más completos a los usuarios y construir experiencias coherentes.

Sin embargo, el acceso a datos de archivo es notoriamente difícil de obtener en Solana. El conjunto de datos es enorme, está profundamente interconectado y es computacionalmente costoso de consultar. Para la mayoría de los desarrolladores, estos endpoints son donde aparecen primero, y de forma más aguda, los problemas de latencia e inconsistencia.

El problema de rendimiento con los métodos de archivo de Solana

Hoy en día, la mayoría de la infraestructura de Solana corre sobre Google Bigtable junto con nodos RPC basados en validadores.

Este stack es fácil de desplegar (por eso muchos equipos lo eligen), pero no está construido para escalar. Consume muchos recursos de CPU, requiere mucha memoria y tiene dificultades con solicitudes por lotes grandes. Al consultar a escala, estos métodos pueden limitar el throughput y hacer que tu app funcione muy lento, o incluso llegar a descartar datos en la respuesta.

Por eso, incluso proveedores reconocidos suelen devolver respuestas incompletas o desactualizadas al consultar datos históricos. Para los desarrolladores, esos bloques faltantes y llamadas lentas rápidamente se convierten en experiencias rotas dentro de la app.

Queríamos solucionar eso. No solo con más hardware (aunque también agregamos más), sino con una mejor arquitectura para toda nuestra infraestructura.

Nuestras dificultades de optimización con Google Bigtable

Como muchos proveedores de infraestructura de Solana, empezamos con Google Bigtable, y con el tiempo descubrimos los problemas de rendimiento mencionados arriba. Esos problemas se agravaban por dos factores.

Primero, el gran tamaño de los bloques de Solana. Bigtable rinde mejor cuando las filas son de ~1KB. Los datos de transacciones o estados de cuenta de Solana suelen ser mucho más grandes. Obtener un objeto binario grande requiere más I/O del almacenamiento subyacente de Google (Colossus).

Segundo, estaba la cuestión del precio. Las bases de datos en la nube son costosas. Mucha información en Solana (como las transacciones de votación) no tiene mucho valor, y no es económicamente viable mantener esos datos en la nube. Además, Google Bigtable cobra por uso, lo que agrega aún más presión y menos flexibilidad para ofrecer un mayor RPS.

A pesar de esas limitaciones, igual intentamos aplicar algunas optimizaciones a esta configuración. Por ejemplo, optimizamos la obtención de transacciones. En la configuración por defecto de Google Bigtable, cuando solicitás una transacción con getTransaction, se dispara una consulta a una tabla tx para obtener el ID de bloque a partir de la firma. Luego se obtienen todos los bloques para devolver una sola transacción. Es mucho trabajo para devolver una pequeña cantidad de datos desde una base de datos remota en la nube.

Para hacer esa solicitud común más eficiente, introdujimos una tabla adicional llamada tx-full donde almacenamos no solo una referencia a los bloques, sino la transacción completa. Eso marcó una gran diferencia en los tiempos de respuesta, pero seguíamos sufriendo un aumento de latencia debido a la ubicación geográfica remota del centro de datos.

Aunque nos esforzamos por adaptarnos al stack por defecto, el desarrollo era muy lento. Incluso una simple escritura realizada desde un nodo RPC/validador completo era un gran problema: cada cambio requería reiniciar completamente los nodos. Ese proceso podía tardar entre 30 minutos y varias horas. No tener la base de datos más cerca geográficamente, ni la posibilidad de controlar algunos de sus parámetros, también hacía todo mucho más difícil y costoso. Después de algunos intentos, decidimos que era mejor reescribir todo el stack, desde la ingesta de datos hasta el propio servidor RPC.

¿Nuestra solución? Un stack reescrito

Nuestro objetivo principal al asumir este trabajo era reducir el tiempo de desarrollo. Esto significaba eliminar los nodos RPC pesados que escriben y sirven datos. En cambio, separamos la escritura y el servicio de datos en pequeños servicios independientes y cambiamos a una base de datos open source autoalojada.

Ese nuevo sistema ofrece:

• Co-optimización de hardware y software: cada capa del stack, desde la disposición del disco hasta el acceso a memoria, está ajustada para maximizar el throughput y minimizar la sobrecarga de cómputo.
• Distribución de datos multirregión: los datos de archivo se distribuyen globalmente, lo que garantiza un acceso de baja latencia sin importar de dónde provengan las solicitudes.
• Ingesta con triple verificación: cada registro se escribe dos veces, se valida programáticamente en cuanto a precisión, y se escanea continuamente para verificar que esté completo.
• Pipelines autorreparables: si se detectan discrepancias, reingresamos automáticamente las entradas faltantes, cruzando hasta 30–50 direcciones relacionadas por bloque para garantizar la integridad de los datos.

Repasemos cada parte de la solución, que además publicamos como open source (este código existe en el repositorio de DexterLab, que fue adquirido por Alchemy el año pasado).

ArchivalRPC

Reconstruimos nuestro servicio de archivo desde cero, convirtiéndolo en un servicio mucho más eficiente que puede iniciarse o reiniciarse en pocos segundos. Una mejora drástica frente a los 30 minutos a varias horas de tiempo de arranque que enfrentábamos al trabajar con un nodo RPC completo.

Seguimos usando las mismas librerías oficiales de Solana para serializar y deserializar datos, así que este servicio siempre será compatible con los cambios que vayan surgiendo. Esto significa que, incluso con nuestro nuevo stack personalizado, no modificamos los datos en absoluto, garantizando que los datos que servimos no se corrompan durante el procesamiento.

Y al ser un servicio liviano que depende de una base de datos, es muy fácil escalarlo bajo demanda (en solo unos segundos) y absorber grandes volúmenes de tráfico. Esto es particularmente útil para aplicaciones con picos de tráfico, y con una sola instancia de base de datos, este servicio puede alcanzar cifras de 100,000-200,000 RPS dependiendo de la configuración de la base de datos.

Ingestor de ArchivalRPC

Esta parte del stack se encarga de extraer datos de Solana desde múltiples fuentes y escribirlos en nuestra capa de base de datos. Maneja tanto importaciones masivas (como archivos gzip de bloques crudos usados al inicializar nuevas instancias) como streams en tiempo real desde sistemas como Kafka.

También integramos controles granulares directamente en el ingestor, que nos permiten elegir exactamente qué tipos de datos debe almacenar una instancia (por ejemplo, solo bloques, solo firmas, solo transacciones, o cualquier combinación). Este modelo de ingesta selectiva reduce los puntos únicos de falla, mejora la confiabilidad y nos da palancas significativas para optimizar los costos de almacenamiento según el caso de uso.

Hbase

Una vez que mejoramos el rendimiento de lectura y escritura, dirigimos nuestra atención al siguiente desafío: la latencia de las bases de datos en la nube. ArchivalRPC fue diseñado desde el primer día para soportar múltiples backends de almacenamiento, lo que facilitó explorar alternativas.

Finalmente elegimos HBase, un reemplazo de BigTable open source y autoalojado, porque nos permitía colocar la base de datos junto a nuestros servidores RPC y reducir la latencia de almacenamiento prácticamente a cero. Esta implementación también nos permitió usar nuestros modelos de datos y principios de implementación existentes, dándonos los beneficios de rendimiento sin introducir riesgos arquitectónicos.

Pero incluso con las ventajas de HBase, seguimos encontrando algunos problemas. Por ejemplo, para manejar el gran tamaño de los bloques de Solana, originalmente intentamos usar BucketCache en Hbase, que puede configurarse para usar memoria off-heap o SSDs rápidos como una capa de caché secundaria y mantener más datos en un estado "warm".

Sin embargo, finalmente descubrimos que BucketCache no era confiable. Debido a la aleatoriedad de los datos y a la rapidez con la que cambiaban, ralentizaba nuestro sistema. En cambio, terminamos recurriendo a una solución diferente para manejar datos grandes: cambiamos directamente la forma en que se almacenan los bloques. En lugar de guardar blobs completos en nuestra base de datos (que no está diseñada para manejar estas estructuras de datos tan grandes), solo almacenamos los metadatos en la base de datos, los cuales apuntan a archivos CAR que pueden residir en cualquier almacenamiento y son muy escalables.

Optimizaciones de servicio y distribución multirregión

Construir una solución capaz de escalar a millones, e incluso miles de millones, de solicitudes requirió optimizaciones en todo el stack: cambiar una arquitectura de base de datos por otra no era suficiente por sí solo para lograr el rendimiento que buscábamos. Necesitamos probar muchos despliegues diferentes en distinto hardware y distintas arquitecturas. Con el tiempo, mejoramos nuestros servicios de ingesta y de servicio de datos, y obtuvimos los resultados deseados.

Optimizar nuestro hardware y software para manejar grandes volúmenes de solicitudes fue un desafío que tuvimos que resolver. Otro fue combatir la latencia. Para las llamadas de archivo más pesadas, encontramos que controlar la latencia requería expandir nuestro hardware a múltiples regiones para garantizar respuestas rápidas y consistentes en todo el mundo.

Esta configuración multirregión también mejora nuestra disponibilidad y nos ayuda a mantener estándares de confiabilidad más altos. Las interrupciones son inevitables, y tener opciones de respaldo distribuidas en distintas regiones geográficas asegura que, incluso si una región cae, podamos seguir sirviendo a nuestros clientes. Esta misma configuración multirregión también nos ayuda a escalar y distribuir el tráfico: si una región está llegando a su capacidad, podemos enrutar el tráfico a otra región a medida que escalamos el despliegue.

Ingesta con triple verificación

Gran parte del trabajo en este producto consistió en mejorar el rendimiento, pero eso es solo la mitad de la batalla. Un problema recurrente con los métodos de archivo de Solana es que los datos a menudo se pierden por completo. Tuvimos que mejorar la confiabilidad del sistema.

Muchos proveedores basados en Bigtable pierden bloques, firmas o transacciones de forma silenciosa a medida que sus pipelines de ingesta escalan. Esas pérdidas ocurren por la forma en que funciona la ingesta de datos por defecto desde un validador: cada reinicio puede generar huecos en las escrituras de datos.

Y si estás limitado a mantener múltiples validadores escribiendo los mismos datos, eso tampoco garantiza consistencia, porque no hay verificaciones secundarias de que los datos se estén escribiendo correctamente. Y como desarrollador que usa esa infraestructura, no te enterás de que faltan datos hasta que algo falla más adelante en el proceso.

Nuestra infraestructura previene ese problema por diseño. Después de escribir los datos, ejecutamos pipelines secundarios que leen cada registro y validan continuamente esos datos, reparándolos automáticamente si aparecen inconsistencias. También hacemos verificaciones completas de nuestras bases de datos después del arranque inicial, y seguimos haciendo verificaciones sobre las escrituras en vivo en tiempo casi real.

No solo construimos datos más rápidos. Construimos datos confiables.

Pipelines autorreparables

Para algunos datos complejos, como signatures, los métodos de respaldo no son confiables. Esto significa que el proceso de triple verificación mencionado a veces no alcanza.

Para resolver esto, usamos validación programática para cruzar transacciones en hasta 30-50 direcciones por bloque. Si nuestro sistema detecta una discrepancia, nuestro proceso de respaldo y recuperación repara automáticamente las entradas faltantes.

Ese proceso implica obtener un bloque que sirve como fuente de verdad y extraer de él todas las relaciones entre direcciones y firmas. Para optimizar el costo de escanear HBase en este paso, acumulamos estos mapeos por dirección a lo largo de un rango amplio de slots consecutivos y realizamos una consulta de escaneo en lugar de consultas individuales basadas en claves. Luego comparamos los resultados, lo que nos permite identificar huecos en el cluster SIGS.

Una vez que identificamos esos huecos, reenviamos ese bloque al pipeline de indexación (a un tópico de kafka adecuado para ese tipo de dato) y lo reindexamos. También agregamos un proceso de verificación de consistencia que repite esta operación si el hueco no se llena, y que eventualmente alerta a nuestro equipo si el estado de falla persiste.

Esta redundancia y capacidad de autorreparación garantiza que podés confiar en nuestros métodos como la fuente de datos históricos más completa y consistente en Solana.

Traduciendo el trabajo en throughput

Todo ese trabajo se ha traducido en capacidad concreta:

• 100,000 RPS por región para getTransaction
• 50,000 RPS por región para getSignaturesForAddress
• 2,000 RPS por región para getBlock

Seguimos invirtiendo en nuestra oferta para Solana y pronto nos expandiremos a más regiones para lograr aún mejor confiabilidad y latencia. Esto es solo el comienzo.

Probalo vos mismo

Si querés probar nuestros métodos de archivo en Solana, podés empezar gratis creando una cuenta en el dashboard para generar tu API key. Después podés explorar nuestros endpoints de Solana en nuestra documentación.

Preguntas frecuentes

¿Qué son los métodos de archivo en Solana?

Los métodos de archivo son llamadas RPC que recuperan datos históricos de la blockchain, como getTransaction, getBlock y getSignaturesForAddress. Estos endpoints permiten a los desarrolladores acceder a transacciones, bloques y firmas pasadas a través de una interfaz JSON RPC estándar.

¿Por qué los métodos de archivo de Solana suelen ser lentos?

La mayoría de la infraestructura de Solana corre sobre Google Bigtable, que consume muchos recursos de CPU, requiere mucha memoria y tiene dificultades con solicitudes por lotes grandes. Este stack no fue construido para escalar y puede limitar el throughput, ralentizar el rendimiento o incluso descartar datos en las respuestas.

¿Qué tan rápidos son los métodos de archivo de Alchemy en Solana?

Los métodos de archivo de Alchemy son hasta 20 veces más rápidos que otras soluciones, con capacidad para 100,000 RPS por región para getTransaction, 50,000 RPS para getSignaturesForAddress y 2,000 RPS para getBlock.

¿Cómo garantiza Alchemy la integridad y confiabilidad de los datos?

Usamos ingesta con triple verificación, donde cada registro se escribe dos veces, se valida programáticamente en cuanto a precisión, y se escanea continuamente para verificar que esté completo. Los pipelines autorreparables reingresan automáticamente las entradas faltantes cruzando hasta 30-50 direcciones relacionadas por bloque.

¿Qué base de datos usa Alchemy para los datos de archivo de Solana?

Usamos HBase, una base de datos open source y autoalojada que permite ubicar los datos junto a los servidores RPC para reducir la latencia de almacenamiento prácticamente a cero. Esto reemplazó a Google Bigtable para mejorar el rendimiento y reducir costos.

¿Cómo maneja Alchemy el gran tamaño de los bloques de Solana?

En lugar de almacenar bloques completos en la base de datos, Alchemy solo guarda metadatos que apuntan a archivos CAR, los cuales pueden residir en cualquier almacenamiento y son muy escalables. Este enfoque maneja mejor el gran tamaño de los bloques de Solana.

¿Por qué Alchemy reconstruyó todo el stack de archivo desde cero?

El stack por defecto, usando nodos RPC completos, requería entre 30 minutos y varias horas para reiniciarse, lo que hacía el desarrollo lento y costoso. Alchemy separó la escritura y el servicio de datos en pequeños servicios que pueden reiniciarse en segundos y escalar bajo demanda.

¿Cómo mantiene Alchemy una baja latencia a nivel global?

Los datos de archivo se distribuyen en múltiples regiones a nivel global, lo que garantiza un acceso de baja latencia sin importar de dónde provengan las solicitudes. Esta configuración multirregión también mejora la disponibilidad y ayuda a distribuir el tráfico durante períodos de alta demanda.