Datos de archivo de Solana: cómo consultar el historial completo de bloques y transacciones

Tarde o temprano, todo equipo que indexa Solana choca con la misma pared. Le pides a un nodo una transacción de hace unos meses y recibes un error de "block cleaned up", porque el nodo eliminó ese tramo del ledger hace semanas. Un nodo RPC de Solana estándar conserva aproximadamente los últimos dos días de la cadena y elimina todo lo anterior para mantenerse dentro de su presupuesto de disco. Dado que Solana produce más de cuatro petabytes de datos al año en velocidades máximas, ninguna máquina individual podría almacenar todo eso.

Los datos archivales son la forma de acceder a todo lo que el nodo descartó. Antes que nada, hay que dejar clara una definición. Los datos archivales de Solana son bloques y transacciones antiguos, no estado pasado de las cuentas. Si vienes de Ethereum, donde un nodo archival puede reportar el balance de cualquier cuenta en cualquier bloque histórico, esa diferencia importa la primera vez que diseñas un pipeline alrededor de un método que aquí no existe. El resto es práctico: dónde vive realmente el historial completo de Solana, qué métodos RPC llegan a él, cómo consultarlos, y cómo rellenar un índice desde el génesis sin dejar huecos.

¿Por qué un nodo estándar de Solana no puede servir el historial completo?

Un validador escribe el ledger en una base de datos local, y los operadores lo ejecutan con el flag --limit-ledger-size para que el disco no se llene. Con ese flag activado, el nodo purga primero los datos más antiguos. Su valor por defecto es 200 millones de shreds, los fragmentos en los que Solana divide los bloques para propagarlos por la red, lo cual mantiene el ledger en alrededor de 500 GB. Sin el flag, el nodo conserva todo lo que recibe hasta quedarse sin disco, lo cual, dada la tasa de datos de Solana, no tarda mucho.

Anza, el equipo que mantiene el cliente validador Agave, es directo respecto al motivo. Seis meses de datos de transacciones no se pueden almacenar en la práctica en el ledger local de un validador, así que el historial que un nodo conserva es "del orden de días". Todo lo más antiguo tiene que vivir en otro lugar.

Puedes encontrar el límite de cualquier nodo llamando a minimumLedgerSlot, que devuelve el slot más antiguo que aún conserva. Obsérvalo un rato y el número solo sube, porque la purga nunca se detiene. Si consultas por debajo de ese límite, obtienes el error "block cleaned up" en lugar de datos. Un disco más grande no cambia nada de esto. Servir la punta de la cadena y servir historial profundo son problemas de infraestructura distintos, y los sistemas archivales existen porque el segundo superó lo que un nodo puede manejar.

¿Qué significa "archival" en Solana, y en qué se diferencia de Ethereum?

Un nodo archival de Ethereum conserva cada versión histórica del trie de estado. Puedes preguntar cómo lucía el storage de un contrato o el balance de una wallet en cualquier bloque pasado, y el nodo responde con datos que guardó exactamente para ese propósito. Los equipos que llegan desde Ethereum tienden a asumir que Solana tiene un equivalente. No lo tiene, y esta única suposición arruina más planes de datos históricos que cualquier otra cosa.

Solana sobrescribe el estado de las cuentas en el lugar. Cuando una cuenta cambia, la nueva versión reemplaza a la anterior, y un proceso de limpieza en segundo plano en AccountsDB recolecta las versiones reemplazadas una vez que un slot posterior queda finalizado. No sobrevive ningún registro de lo que una cuenta tenía hace tres meses. Por eso la API RPC de Solana no tiene un método de "balance en el slot N", y por eso consultar el estado histórico de una cuenta lleva años como feature request abierto en el repositorio de Solana.

Lo que la infraestructura archival preserva es el ledger en sí, es decir, los bloques y las transacciones que contienen. Un archivo puede entregarte el bloque 150,000,000, o cada transacción que alguna vez tocó una dirección. No puede entregarte el balance en USDC de una wallet de marzo pasado. Esa pregunta sigue siendo respondible, pero se responde reproduciendo el historial de transacciones de la wallet con un indexer, no pidiéndole a un nodo un estado que nunca conservó.

¿Qué métodos RPC necesitan datos archivales?

Un método se convierte en una lectura archival en el momento en que el slot al que apunta cae por debajo del límite local del nodo. Estos son los que llegan al almacenamiento de largo plazo.

La mayoría de los pipelines históricos se construyen sobre dos de estos métodos. Se recorre hacia atrás el historial de una dirección con getSignaturesForAddress, y luego se obtiene el detalle de cada transacción con getTransaction. Dado que la llamada de firmas devuelve como máximo 1,000 resultados por llamada, recorrer una dirección con mucha actividad hasta su primera transacción implica una larga cadena de llamadas paginadas, y casi todas las que superan el slot mínimo del nodo se sirven desde el archivo.

Aquí es también donde se expone un archivo débil. Si el almacenamiento de largo plazo del proveedor tiene huecos, alguna llamada en un punto profundo de tu backfill devuelve un error de "slot skipped" o "missing in long-term storage", y a menos que lo estés verificando, tu índice queda incompleto sin que nadie lo note. Todos los proveedores exponen los mismos nombres de método. Lo que varía es si el almacenamiento detrás de ellos tiene huecos, y qué tan rápido responde cuando estás paginando a través de miles de llamadas seguidas.

¿Cómo se consulta el historial completo de bloques y transacciones?

Las consultas en sí son JSON-RPC ordinario. No existe una API archival separada ni un parámetro especial que desbloquee el historial. Llamas a los mismos métodos que usarías en la punta de la cadena, y el archivo del proveedor responde siempre que el slot caiga por debajo del límite local del nodo.

Obtener un bloque de historial profundo se ve así:

La respuesta trae el bloque completo, cada transacción que contiene, y el estado y los metadatos de cada transacción. Mantén maxSupportedTransactionVersion: 0 en los params en cada llamada. Sin él, la llamada falla en cualquier bloque que contenga transacciones versionadas, que en mainnet es la mayoría.

Recorrer el historial completo de una dirección es el patrón de dos métodos de la tabla anterior, ejecutado en un loop. Se pagina hacia atrás con getSignaturesForAddress hasta que vuelve vacío, y luego se obtiene el detalle de cada transacción:

Para una sola wallet, este loop es todo lo que necesitas, y corre bien desde una laptop. Deja de ser suficiente cuando la dirección es un programa con actividad intensa y millones de firmas, o cuando necesitas historial para cada dirección de la cadena. Ese es el problema de backfill, y las secciones siguientes cubren de dónde vienen los datos y cómo cargarlos sin dejar huecos.

¿Cómo se almacena realmente el historial completo de Solana?

Ningún validador conserva el ledger completo, así que el historial de largo plazo vive completamente fuera del nodo. En la práctica, dos sistemas se encargan de esto.

El más antiguo es el patrón de warehouse. Un nodo dedicado sube continuamente los bloques finalizados a Google Bigtable, y cuando un nodo RPC recibe una consulta por un slot que ya no conserva, cae de vuelta a ese almacén. Los slots recientes vienen de la base de datos local del nodo y todo lo más antiguo viene de Bigtable. La mayor parte del RPC de Solana en producción ha servido historial profundo así durante años. El costo es la concentración, ya que el pasado completo de la cadena termina dentro de una única base de datos propietaria en la nube.

El más reciente es Old Faithful, el archivo de código abierto liderado por Triton y el proyecto Yellowstone. Empaqueta cada bloque desde el génesis en archivos CAR direccionados por contenido, los distribuye a través de IPFS, Filecoin y almacenamiento compatible con S3, y los sirve mediante JSON-RPC y gRPC estándar de Solana. El proyecto existe para que el historial completo de Solana no dependa de la base de datos de una sola empresa, y los equipos que necesitan cobertura verificable desde el génesis lo tratan como el archivo de referencia.

Sea cual sea el backend detrás de tu proveedor, lo importante es entender que el archivo es un sistema separado del nodo. La profundidad y la completitud son propiedades de ese sistema, y vale la pena preguntarlas directamente en lugar de asumirlas.

¿Cómo se obtiene historial de cuentas y tokens a escala?

Los equipos que quieren "historial de Solana a escala" rara vez se refieren a bloques crudos. Quieren el balance de una wallet a lo largo del tiempo, cada transferencia que una dirección ha hecho, o el historial completo de holders de un token, servido con la velocidad suficiente para alimentar un dashboard o una exportación fiscal. Nada de eso existe en el ledger en forma consultable. Hay que derivarlo.

La receta apenas cambia entre proyectos. Se extrae el historial completo de transacciones de una dirección desde RPC archival, se reproducen esas transacciones en orden, y se calcula el estado que interesa a medida que se avanza: balances después de cada transacción, cambios de propiedad, flujos de transferencias. Se escriben los resultados en tu propia base de datos para que la reproducción costosa ocurra una sola vez en lugar de en cada solicitud. En cualquier cadena, este es el trabajo de un indexer de blockchain. En Solana es la única ruta hacia el estado histórico, porque el nodo no conserva ninguno.

Para la versión más precisa de la pregunta, qué tenía una wallet en un slot específico, ahora ofrecemos una respuesta directa. getTokenAccountsByOwnerAtSlot conserva la sintaxis del getTokenAccountsByOwner estándar y agrega un parámetro slot, devolviendo los balances exactos de tokens de la wallet en ese punto del historial en una sola llamada. Está respaldado por un índice histórico mantenido de forma continua en lugar de por reproducción, así que para holdings en un punto en el tiempo, todo el pipeline de reconstrucción anterior desaparece. El post de lanzamiento de balances históricos de tokens de Solana explica la mecánica.

Para las otras formas derivadas comunes, balances a lo largo del tiempo, transferencias y metadatos de tokens, Data APIs las sirve precalculadas y puedes saltarte el proyecto de indexación. Construye tu propio indexer cuando necesites datos derivados personalizados o control total del pipeline. Usa los métodos administrados cuando las formas estándar te cubran. Lo que no puede funcionar es pedirle a un nodo plano el estado pasado de una cuenta, porque el nodo nunca lo conservó. Toda respuesta que funciona es un índice construido sobre el historial.

¿Cómo se hace backfill de un índice desde el génesis sin que falle?

La parte difícil de un pipeline histórico es el arranque en frío. Tu índice está vacío, hay que cargar cientos de millones de slots, y la cadena sigue produciendo bloques nuevos mientras los cargas. Si el backfill y el feed en vivo no se encuentran de forma limpia, se abre un hueco entre donde terminó uno y donde empezó el otro.

Muchos equipos empiezan haciendo polling de RPC archival para todo el backfill, y a la escala del génesis esto se vuelve doloroso: límites de tasa, costo por solicitud multiplicado por cientos de millones de slots, y ninguna forma limpia de demostrar que no se perdió nada. El patrón que sobrevive al contacto con producción usa una fuente distinta para cada fase. El historial masivo viene directo de un archivo, y herramientas como Jetstreamer lo transmiten directamente desde Old Faithful. La punta de la cadena viene de un stream en vivo en lugar de más polling.

Para la mitad en vivo, un stream gRPC de Solana compatible con Yellowstone empuja nuevas transacciones y actualizaciones de cuentas a tu indexer a medida que ocurren, filtradas por cuenta, programa o firma. La costura entre el backfill y el stream es donde los pipelines suelen tener fugas, y el replay es lo que la sella. Nuestro gRPC permite que un cliente se reconecte con un parámetro from_slot y vuelva a recibir los slots que se perdió mientras estuvo caído, de modo que una conexión interrumpida no deja un hueco en tus datos. También construimos la capa de streaming para que resista failovers sin perder mensajes, que es el trabajo que de otro modo se convierte en un servicio separado de detección de huecos que corres junto a tu indexer. Una vez que el archivo cubre el pasado y el stream cubre la punta, el replay mantiene ambos cosidos entre sí.

¿Qué buscar en un proveedor de datos archivales de Solana?

La profundidad es lo primero que hay que precisar, y vale la pena preguntarle a cualquier proveedor exactamente esto: ¿indexan desde el génesis, o desde una altura más reciente en adelante? "Datos históricos completos" con un límite no especificado es algo común, y usualmente descubres ese límite cuando tu backfill se rompe contra él.

El resto de la lista de verificación se deriva de cómo funciona realmente un backfill. La completitud importa porque un solo hueco corrompe el índice que construiste encima. La velocidad importa porque un recorrido completo del historial de firmas son miles de lecturas archivales secuenciales, así que la latencia por llamada se multiplica en horas o días de tiempo real. El JSON-RPC estándar importa porque un endpoint histórico propietario ata tu pipeline a un solo proveedor, mientras que el RPC plano no requiere ninguna reescritura. Y el precio importa porque el historial profundo es, por naturaleza, intensivo en lecturas.

Construimos nuestro acceso archival siguiendo esa lista de verificación. Cubre historial completo de bloques y transacciones desde el génesis mediante JSON-RPC estándar, y nuestros benchmarks midieron a getTransaction histórico corriendo hasta 20 veces más rápido que otros proveedores, junto con getBlock hasta 3 veces más rápido y hasta 10 veces más rápido en llamadas pesadas como getProgramAccounts, sin cambios de código ni métodos propietarios de por medio. La historia de ingeniería de cómo construimos los métodos archivales más rápidos en Solana explica la arquitectura detrás de esos números. Para una comparación completa en profundidad, uptime, precios y herramientas, la guía de decisión de los nueve mejores proveedores de RPC de Solana cubre todo el panorama. Sea cual sea el proveedor que elijas, obtén por escrito las respuestas sobre profundidad desde el génesis y completitud antes de empezar el backfill.

Construye tu pipeline histórico de Solana en Alchemy

Un pipeline histórico funcional necesita dos cosas: un archivo lo bastante profundo para hacer backfill desde el génesis y un stream lo bastante rápido para mantener el ritmo de la punta de la cadena. Ambos corren como parte de la plataforma de Solana de Alchemy. Las lecturas archivales cubren el historial completo de bloques y transacciones mediante JSON-RPC estándar, así que apuntar tu cliente de Solana existente a un endpoint de Alchemy es toda la migración. El streaming gRPC de Solana es compatible con Yellowstone, con replay al reconectar, con precio pay-as-you-go de $75 por TB, sin mínimo mensual y sin requisito de plan.

Empieza en el nivel gratuito, sin contrato y sin llamada de ventas. Los equipos que construyen infraestructura de Solana también pueden postular a hasta $25,000 en créditos a través de nuestro $20M Solana Fund. Una vez que tu pipeline esté en producción, el historial que tu nodo descarta deja de ser tu problema.