ERPC ofrece acceso completo y sin lagunas al historial de Solana RPC en todas las regiones mediante la integración de Old Faithful

ERPC, operado por ELSOUL LABO B.V. (sede: Ámsterdam, Países Bajos; CEO: Fumitake Kawasaki) junto con Validators DAO, anuncia la disponibilidad oficial del acceso a datos históricos mediante Solana RPC.
En el endpoint
edge.erpc.global, el Solana RPC de ERPC ofrece datos históricos mediante History Access. Los usuarios con el Plan Free, con otras asignaciones gratuitas o con un plan de pago solicitan History Access para bloques y transacciones más antiguos añadiendo history=true a la URL edge.erpc.global.La mejora se logra integrando en la infraestructura RPC de ERPC Old Faithful, una tecnología de código abierto diseñada específicamente para archivar y distribuir datos históricos de Solana.
Retos estructurales del acceso a datos históricos mediante Solana RPC
Solana genera aproximadamente 500 GB de datos por epoch, que suele durar entre uno y dos días. Este volumen crece año tras año y exige cada vez más capacidad de almacenamiento y rendimiento de E/S a los nodos RPC.
Para mantener el rendimiento y la estabilidad operativa, la mayoría de los nodos RPC estándar solo conservan un número limitado de epochs recientes. En muchos casos, una configuración con unos 4 TB de almacenamiento solo puede guardar tres o cuatro epochs, aproximadamente una semana de historial. Por ello, al solicitar bloques, transacciones o estados de cuentas más antiguos se reciben con frecuencia respuestas incompletas o faltantes.
Estas limitaciones han planteado durante mucho tiempo problemas prácticos en casos que dependen del historial, como análisis on-chain, estudios de comportamiento a largo plazo, backtesting, auditorías e investigación.
Limitaciones prácticas de los métodos de archivo convencionales
Tradicionalmente, operar un nodo de archivo se consideraba la vía principal para acceder a todo el historial del ledger de Solana. Sin embargo, este enfoque requiere replicar enormes volúmenes de datos, una sincronización inicial prolongada y costes operativos elevados y continuos.
Las configuraciones basadas en Google Cloud Bigtable, en particular, implican costes sustanciales de migración al desplegarse y gastos importantes durante toda la operación. Para muchos desarrolladores y organizaciones, esto las ha hecho poco prácticas. Además, la fuerte dependencia de un único proveedor de nube también ha suscitado dudas desde la perspectiva de la descentralización, un principio fundamental de los sistemas blockchain.
El modelo de distribución histórica que permite Old Faithful
Old Faithful es una infraestructura de archivo de código abierto creada para afrontar estos retos en el ecosistema Solana. Genera y sirve archivos históricos en formato Content Addressable Archives (CAR) a partir de los archivos RocksDB producidos por los nodos de almacenamiento de Solana.
En el formato CAR, cada epoch, bloque, transacción y Shred se identifica de forma única mediante un hash de contenido. Esto permite verificar la integridad y confirmar que los datos obtenidos no se han manipulado, incluso si proceden de fuentes de distribución que no son de confianza.
Old Faithful está diseñado para manejar todo el historial del ledger de Solana, desde el génesis hasta la actualidad, y admite numerosos métodos de distribución, incluidos HTTP, CDN y sistemas de almacenamiento distribuido.
Integración de Old Faithful en ERPC
Al integrar Old Faithful en su infraestructura Solana RPC, ERPC ofrece acceso al historial mediante la interfaz Solana RPC existente. Los datos históricos proceden del mismo endpoint
edge.erpc.global y de los mismos métodos de Solana RPC que los datos recientes; una solicitud pide History Access añadiendo history=true a la URL del endpoint.La actualización se ha aplicado de forma uniforme a todas las regiones de ERPC, garantizando la misma disponibilidad del historial con independencia de la ubicación geográfica. Incluso en despliegues distribuidos globalmente, los usuarios pueden contar con la misma cobertura histórica en todas las regiones.
Características de rendimiento e investigación y desarrollo continuos
Debido al gran tamaño inherente de los datos históricos, algunas consultas pueden tardar más que las solicitudes de información reciente. Este comportamiento responde a las características estructurales del acceso al historial y no indica fallos del sistema ni una degradación del rendimiento.
ERPC sigue investigando cómo reducir los tiempos de respuesta al consultar el historial, incluida la evaluación de configuraciones con almacenamiento NVMe de gran capacidad y nueva generación. Las mejoras se introducirán gradualmente a partir de lo aprendido en operaciones reales.
Ampliación de los casos de uso admitidos
Con esta actualización, Solana RPC de ERPC admite más casos de uso además de las aplicaciones en tiempo real. Ya es posible realizar análisis a largo plazo, verificaciones históricas, investigaciones, auditorías y análisis del comportamiento de aplicaciones sin infraestructura adicional.
Ofrecer el acceso histórico como extensión natural del uso estándar de RPC amplía considerablemente la aplicabilidad práctica de los servicios Solana RPC de ERPC.
Uso
Para leer bloques y transacciones más antiguos, se añade
history=true a la URL del endpoint edge.erpc.global de una solicitud HTTP. Salvo getTransactionsForAddress, una solicitud sin history=true se responde desde el rango reciente que conserva cada nodo.Una solicitud HTTP puede llevar la API key en la URL:
text
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=truehttps://edge.erpc.global?api-key=<YOUR_API_KEY>&history=trueO bien la API key va en un encabezado Authorization, con
history=true en la URL:text
https://edge.erpc.global?history=truehttps://edge.erpc.global?history=trueEl encabezado es
Authorization: Bearer <YOUR_API_KEY>.Documentación RPC de ERPC: https://erpc.global/es/doc/rpc/general/
Salvo
getTransactionsForAddress en modo "full", una llamada respondida mediante History Access cuesta 640 tokens más que el precio normal de su método, y una llamada respondida desde el rango reciente que conserva cada nodo mantiene su precio normal, incluso con history=true. getTransactionsForAddress en modo "full" cuesta su precio normal más 640 tokens por cada transacción obtenida, reciente o antigua. Las asignaciones gratuitas, incluida la del Plan Free, tienen un límite para History Access.Una consulta de datos históricos puede tardar mucho más que una solicitud normal, en algunos casos segundos. ERPC ofrece History Access como una opción independiente que mantiene las consultas de datos históricos separadas de las solicitudes normales, para que las solicitudes normales sigan siendo rápidas.
Los usuarios pueden obtener y comprobar su API key de ERPC en el ERPC Web Dashboard.
Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
Sitio web oficial de ERPC: https://erpc.global/es


