ERPC mejora significativamente la infraestructura de red de Solana: actualiza por completo su proxy de alto rendimiento en Rust en todas las regiones para RPC, gRPC y ShredStream compartidos, sin tiempo de inactividad
ERPC, operado por ELSOUL LABO B.V. (sede: Ámsterdam, Países Bajos; CEO: Fumitake Kawasaki) y Validators DAO, ha completado una importante actualización de su infraestructura de red de Solana.
La actualización ya se ha aplicado a todas las regiones y a todos los endpoints compartidos de ERPC (Solana RPC, Geyser gRPC y ShredStream). Hemos actualizado como sistema integrado los comportamientos de infraestructura que suelen influir directamente en los resultados reales: inicio de conexiones, procesamiento TLS, control de caché, transporte HTTP/1.1 y HTTP/2, conexiones de larga duración y métricas de observabilidad y diagnóstico.
Al tiempo que mantenemos como base la capacidad de respuesta cotidiana, también hemos reorganizado el comportamiento subyacente de la red para reducir el riesgo de sesgo o inestabilidad en situaciones donde los resultados tienden a degradarse, como la volatilidad durante los picos, la inestabilidad bajo operación sostenida y las cascadas provocadas por desconexiones y reconexiones. El entorno queda así mejor estructurado para sostener tanto el rendimiento como la estabilidad en operaciones reales de Solana.
Además, hemos adoptado una arquitectura operativa que permite aplicar cambios de configuración de red y actualizaciones de plataforma sin tiempo de inactividad. No cambian los precios, las especificaciones, la autenticación ni los límites de solicitudes, y los clientes actuales de ERPC reciben las mejoras sin ninguna configuración adicional ni cambios operativos.
Contexto
En las operaciones reales de Solana, el tiempo medio de respuesta y la latencia en condiciones normales son requisitos básicos fundamentales. Al mismo tiempo, hay situaciones —como los picos de carga, las conexiones de larga duración y las fases de desconexión y reconexión— en las que el propio comportamiento de la infraestructura de red subyacente determina los resultados.
Los endpoints compartidos deben atender tanto ráfagas de envío de transacciones en ventanas breves como conexiones permanentes mediante WebSocket y gRPC. En estas condiciones, el comportamiento de la infraestructura —inicio de conexiones, handshakes TLS, transporte, gestión de caché y recuperación desde estados inactivos— se refleja directamente en la experiencia del usuario y en los resultados de ejecución.
Aunque la capacidad de respuesta media sea una base explícita, durante los picos o la operación sostenida otros factores pueden decidir los resultados reales. Por ello, las operaciones prácticas deben lograr a la vez la facilidad de uso diaria y la continuidad en situaciones propensas a fallos.
ERPC ha diseñado y opera su propia plataforma de proxy de alto rendimiento en Rust como base de las comunicaciones de Solana. Mantiene una arquitectura que aplica el mismo enfoque en todas las regiones mientras la plataforma sigue evolucionando. Esta actualización vuelve a examinar como un sistema unificado los problemas observados en la operación, desde el inicio de la conexión hasta su funcionamiento prolongado, y reorganiza en consecuencia toda la base de red.
Qué cambia para los clientes de ERPC
Con esta actualización, los clientes de ERPC percibirán primero un comportamiento más estable al iniciar las conexiones. Durante su establecimiento, incluido TLS, se reducen las condiciones incompatibles y los reintentos innecesarios, lo que facilita que las transacciones y los streams entren de forma fiable en el procesamiento desde el principio.
También reorganizamos los comportamientos de infraestructura que suelen causar volatilidad durante los picos. Combinamos el filtrado temprano de conexiones innecesarias con mejoras simultáneas en el transporte y la consistencia de los timeouts de HTTP/1.1 y HTTP/2, el estado del pool de conexiones, la caché bajo contención y las métricas de observabilidad y diagnóstico. Así reforzamos las condiciones que ayudan a evitar comportamientos sesgados incluso cuando se concentra la carga.
Ha mejorado la continuidad de conexión de los streams WebSocket y gRPC de larga duración y de las cargas de monitorización siempre activas. Se han reducido tanto la frecuencia de las desconexiones, reconexiones y resincronizaciones como la probabilidad de que estos eventos se propaguen en cascada hasta los resultados, lo que facilita diseñar operaciones sobre la premisa de un funcionamiento sostenido.
Las mejoras en el control de la caché y el transporte también reducen la probabilidad de recargas innecesarias y trabajo de procesamiento innecesario durante la congestión. El ancho de banda y el margen de procesamiento tienen así más probabilidades de mantenerse disponibles y estables; además, la ampliación de las métricas y la observabilidad permite identificar antes las causas raíz y acortar los tiempos de recuperación.
Además, al permitir cambios de configuración y actualizaciones de la plataforma sin tiempo de inactividad, hemos establecido condiciones operativas que facilitan mejorar con frecuencia el rendimiento, la estabilidad y la calidad general de la plataforma. La capacidad de seguir mejorando sin detenerla refuerza aún más la continuidad para los clientes.
Detalles de las mejoras
Esta actualización no se presenta como una versión definida por nombres de funciones o números concretos. Descompone los escenarios que suelen dominar los resultados reales de Solana en las capas siguientes —inicio de conexiones, TLS, límite L4/HTTP, transporte H1/H2, caché, observabilidad, comportamiento ante fallos y requisitos operativos a largo plazo— y actualiza la plataforma para que se conecten sin contradicciones.
A continuación, explicamos las mejoras incorporadas en términos de cómo contribuyen a la experiencia del cliente y los resultados operativos.
Mejoras en el inicio de conexiones y la gestión de TLS
Ampliamos el contexto TLS gestionado durante el establecimiento de la conexión y actualizamos la estructura para conservar y aplicar correctamente el estado necesario. Esto reduce las incompatibilidades y los reintentos innecesarios al iniciar una conexión.
También reorganizamos la gestión de TLS, incluidas la verificación de certificados y del nombre de host, para cumplir los requisitos de seguridad y reducir las situaciones en las que los fallos del handshake o las incoherencias de gestión generan pérdidas al inicio que se propagan hasta los resultados. No es solo una mejora de seguridad: estabiliza el comportamiento desde el comienzo de la conexión hasta la entrada en procesamiento de las cargas de Solana.
Además, reforzamos los mecanismos que facilitan la observación y el diagnóstico del comportamiento relacionado con TLS. En los escenarios donde el inicio de la conexión domina los resultados, la capacidad de reproducir problemas, identificar sus causas y aplicar rápidamente las correcciones es lo que preserva la calidad de la experiencia.
Preservar el margen mediante el filtrado temprano de conexiones innecesarias
Introdujimos un mecanismo que filtra las conexiones TCP en una fase temprana, de modo que las conexiones ilegítimas o innecesarias tengan menos posibilidades de ejercer presión sobre el tráfico legítimo. En los endpoints compartidos, las solicitudes de conexión pueden dispararse por factores externos o desequilibrios temporales.
El filtrado en la fase inicial reduce el riesgo de que las conexiones legítimas se bloqueen al arrancar y aumenta la probabilidad de conservar margen durante los picos. Así, el comportamiento tiene menos posibilidades de sesgarse incluso cuando se concentra la carga y se refuerzan las condiciones para una distribución estable de la latencia.
Clarificación del modelo de conexión mediante la reorganización del límite L4/HTTP
La infraestructura de red no termina en HTTP. El establecimiento y la continuidad de la conexión dependen de las condiciones L4, y la volatilidad en esa capa se propaga a la experiencia de los protocolos de nivel superior.
En esta actualización, abstrajimos la gestión de streams L4 y reorganizamos la estructura para tratar el modelo de conexión de forma más explícita. Esto facilita que la plataforma mantenga un comportamiento uniforme en escenarios donde sigue creciendo el número de conexiones, varían las implementaciones de cliente y el funcionamiento prolongado provoca transiciones de estado.
También reorganizamos el comportamiento de los reintentos para reducir los patrones en los que una volatilidad breve se propaga hasta la experiencia del usuario. La estabilidad práctica depende menos de eliminar fallos aislados que de impedir sus cascadas.
Mejoras en el comportamiento de transporte y de larga duración de HTTP/1.1 y HTTP/2
Añadimos mediciones que permiten rastrear de forma uniforme el volumen de datos transferidos en HTTP/1.1 y HTTP/2. Esto facilita identificar dónde se producen esperas o cuellos de botella en el pipeline de transporte y mejora tanto el diagnóstico como la velocidad con que pueden aplicarse las correcciones.
También reorganizamos el comportamiento del timeout de escritura del cuerpo de HTTP/2 para reducir el riesgo de bloqueos y esperas anómalas durante los picos de carga o el streaming de larga duración. En el funcionamiento prolongado, lo importante no es el rendimiento máximo en condiciones ideales, sino la capacidad de evitar que el comportamiento se desplome durante las transiciones de estado.
También revisamos los timeouts de inactividad y la gestión del pool de conexiones para eliminar factores de inestabilidad que tienden a acumularse durante el funcionamiento sostenido. Del lado de HTTP/1.1, reorganizamos el cierre seguro de las conexiones con solicitudes incompletas, reduciendo fuentes de volatilidad tanto en el uso de recursos como en el comportamiento.
Mejoras en el control de caché y la calidad operativa
Hemos mejorado la capacidad de rastrear por qué un recurso no se almacena en caché, aumentando la explicabilidad de su comportamiento. En la práctica, lo decisivo no es si existe una caché, sino en qué condiciones se aplica y en cuáles deja de hacerlo.
Reorganizamos los bloqueos, la gestión de contenido obsoleto y los patrones de revalidación para reducir el riesgo de que la degradación se propague en cascada cuando aparece contención durante los picos. También ordenamos los controles de expulsión cuando crece el número de recursos almacenados y refinamos el comportamiento del contenido parcial, incluidas las solicitudes Range. Así reforzamos las condiciones que reducen las recargas innecesarias y la latencia bajo cargas reales.
Estas mejoras reducen los casos en que el comportamiento de la caché se convierte en un fenómeno excepcional, lo que hace menos probable que los clientes tengan que diseñar operaciones en torno a la incertidumbre a nivel de infraestructura.
Mejoras en el comportamiento ante fallos, los registros y la observabilidad
Hemos reorganizado el comportamiento ante fallos y los registros para facilitar la comprensión de lo ocurrido cuando surge un problema. Se reducen los patrones en los que los errores de sistemas posteriores se propagan en cascada hacia la caché o el transporte y empeoran la experiencia, lo que facilita delimitar el radio de impacto.
Las mejoras de observabilidad y diagnóstico no pretenden afirmar que habrá «cero incidentes», sino acortar el tiempo de recuperación cuando ocurran. Esto reduce el riesgo durante los picos y la operación sostenida.
Actualizaciones de dependencias y correcciones de seguridad como requisitos para el funcionamiento a largo plazo
Incorporamos actualizaciones de dependencias y correcciones de seguridad para mantener los requisitos del funcionamiento a largo plazo de la plataforma. Esto incluye actualizaciones relacionadas con la versión mínima compatible de Rust (MSRV) y la alineación con CI, y refuerza las bases necesarias para que la plataforma siga evolucionando.
La capacidad de mantenerse actualizado con seguridad es en sí misma un requisito para la calidad a largo plazo.
Transición a operaciones sin tiempo de inactividad
Antes podía producirse un breve tiempo de inactividad durante los cambios de configuración de red o las actualizaciones de plataforma. Con esta actualización, hemos pasado a una arquitectura que permite aplicar estas operaciones sin ninguna interrupción.
Los endpoints compartidos mantienen conexiones permanentes y un flujo continuo de momentos en los que el tiempo importa. Incluso una breve interrupción puede desencadenar desconexiones, reconexiones y cascadas de resincronización cuyo coste se propaga hasta los resultados. Las actualizaciones sin tiempo de inactividad reducen la probabilidad de estas cascadas y evitan fragmentar las operaciones de larga duración.
Al mismo tiempo, ERPC dispone ahora de condiciones operativas que permiten convertir rápidamente los problemas observados en mejoras. Una mayor frecuencia de iteración nos permite eliminar continuamente la volatilidad y los comportamientos de casos límite en la operación de producción.
Impacto por servicio
Solana RPC (HTTP / WebSocket)
Las mejoras del inicio de conexiones, TLS, el control de caché y el transporte afectan tanto a la lectura de datos como al envío de transacciones. Sin perder la facilidad de uso diaria, se reducen los factores que sesgan los resultados durante los picos y se refuerzan las condiciones para conservar margen durante la congestión.
Geyser gRPC
La continuidad de la conexión ha mejorado para el streaming de larga duración. El transporte HTTP/2, la coherencia de los timeouts, el estado del pool de conexiones y la ampliación de las mediciones de transporte actúan conjuntamente para reducir la probabilidad de que los costes de reconexión y resincronización repercutan en los resultados.
ShredStream (Direct Shreds)
Gracias a una gestión y un inicio de conexiones mejorados para la entrega continua, se refuerzan las condiciones que reducen la probabilidad de perder datos o sufrir un aumento de latencia durante la congestión. Resulta más sencillo mantener una continuidad estable en la detección y el seguimiento.
Conexión de las operaciones de I+D y producción
La base de sistemas distribuidos que incluye ERPC ha sido reconocida como proyecto de I+D dentro del programa WBSO del Gobierno neerlandés. Existe una estructura que permite incorporar como temas de investigación los problemas observados en la operación y mejorarlos mediante verificación e iteración.
Esta actualización de la base de red es una de esas iteraciones, aplicada en todas las regiones y reflejada en el rendimiento y la estabilidad reales. Mantener conectadas la operación y la I+D es un requisito para trasladar continuamente lo observado en producción a la siguiente actualización, en vez de detenerse en mejoras aisladas.
En ERPC, los patrones de uso reales, la variabilidad de la carga y el comportamiento de los modos de fallo se incorporan a ciclos repetidos de verificación y mejora que elevan progresivamente la calidad de la base de red. Esta actualización se ejecutó dentro de ese marco integrado de I+D y operación de producción.
Información para los clientes
La actualización ya se ha aplicado a todas las regiones y a todos los endpoints compartidos. Los clientes actuales de ERPC no necesitan cambiar su configuración ni sus operaciones. No cambian los precios, las especificaciones, la autenticación ni los límites de solicitudes.
Como los endpoints compartidos deben sostener simultáneamente picos breves y conexiones de larga duración, hemos reorganizado las condiciones para reducir el riesgo de sesgo bajo estas cargas mixtas. Incluso cuando se realizan cambios de configuración o actualizaciones de plataforma durante la operación, se aplican sin tiempo de inactividad; los clientes no tienen que planificar de antemano la fragmentación de conexiones o la resincronización.
Para consultas sobre arquitectura, optimización específica de cargas de trabajo o comentarios operativos, póngase en contacto mediante el Discord oficial de Validators DAO.
Al convertir continuamente las observaciones y los comentarios de producción en mejoras, ERPC ha elevado de forma progresiva la calidad de su base. Seguiremos acumulando mejoras sin tiempo de inactividad y ofreciendo una infraestructura de red que sostenga los resultados reales de Solana.
Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
Sitio web oficial de ERPC: https://erpc.global/es
