ERPC mejora significativamente la infraestructura de red de Solana. Plataforma proxy Rust de alto rendimiento actualizada en todas las regiones para RPC, gRPC y Shredstream compartidos, con actualizaciones 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 mejora importante de su infraestructura de red de Solana.

Esta actualización ya se ha aplicado a todas las regiones y a todos los endpoints compartidos proporcionados por ERPC (Solana RPC, Geyser gRPC y Shredstream). Actualizamos como sistema integrado los comportamientos de infraestructura que influyen directamente en los resultados reales: inicio de conexiones, procesamiento TLS, control de caché, transporte HTTP/1.1 y HTTP/2, comportamiento de conexiones persistentes y métricas de observabilidad y diagnóstico.

Manteniendo la capacidad de respuesta cotidiana como referencia, también reorganizamos el comportamiento de la red subyacente para que sea menos propenso a volverse sesgado o inestable en escenarios donde los resultados tienden a degradarse, como la volatilidad de carga pico, la inestabilidad bajo operación sostenida y las cascadas provocadas por desconexiones y reconexiones. Como resultado, el entorno está ahora mejor estructurado para sostener tanto el rendimiento como la estabilidad en operaciones prácticas de Solana.

Además, hemos pasado a una arquitectura operativa que permite aplicar cambios de configuración de red y actualizaciones de plataforma sin tiempo de inactividad. No hay cambios en precios, especificaciones, autenticación ni límites de tasa, y los clientes actuales de ERPC reciben los beneficios de la actualización sin configuración adicional ni cambios operativos.

Antecedentes

En la práctica, las operaciones de Solana, el tiempo medio de respuesta y latencia normal son requisitos fundamentales de referencia. Al mismo tiempo, existen escenarios en los que el comportamiento de la infraestructura de red subyacente determina los resultados, como momentos de carga concentrada, conexiones de larga vida y fases en las que se producen desconexiones y reconexiones.

Los endpoints compartidos en particular deben acomodar tanto las ráfagas de la presentación de las transacciones dentro de las ventanas de corto tiempo y las conexiones siempre a través de WebSocket y gRPCEn estas condiciones, el comportamiento a nivel de infraestructura, la iniciación de la conexión, las maniobras TLS, el comportamiento del transporte, el manejo de caché y la recuperación de estados ociosos, refleja directamente en la experiencia del usuario y los resultados de la ejecución.

Con la capacidad de respuesta media como base explícita, los resultados del entorno real todavía pueden ser decididos por diferentes factores durante picos o bajo operación sostenida. Por lo tanto, las operaciones prácticas requieren que la usabilidad diaria y la continuidad en los escenarios propensas al fracaso se alcancen al mismo tiempo.

ERPC ha diseñado y operado su propia plataforma proxy de alto rendimiento de Rust como la base para las comunicaciones de Solana, manteniendo una arquitectura que aplica el mismo enfoque en todas las regiones y evolucionando continuamente la plataforma. Esta actualización reexamina las cuestiones operativamente observadas como un sistema unificado —desde la iniciación de la conexión a través de operaciones de larga duración— y reorganiza toda la base de red en consecuencia.

Qué cambia para los clientes de ERPC

Con esta actualización, los clientes de ERPC verán primero un comportamiento más estable al iniciar la conexión. Durante el establecimiento de conexiones, incluido TLS, es menos probable que se produzcan condiciones desajustadas y reintentos innecesarios, lo que facilita que las transacciones y los streams entren de forma fiable en procesamiento desde el inicio.

A continuación, reorganizamos los comportamientos de infraestructura que tienden a causar volatilidad durante la carga máxima. Combinando el filtrado temprano de conexiones innecesarias con actualizaciones simultáneas a HTTP/1.1 HTTP/2 congruencia de transporte y temporización, salud de conexión, comportamiento de caché bajo contención, y métricas para la observabilidad y solución de problemas, hemos fortalecido las condiciones que ayudan a prevenir el comportamiento sesgado incluso cuando la carga se concentra.

Para streams WebSocket y gRPC de larga duración y cargas de monitoreo siempre activas, ha mejorado la continuidad de las conexiones. Se redujeron la frecuencia de eventos de desconexión/reconexión/resync y la probabilidad de que esos eventos afecten los resultados, lo que facilita diseñar operaciones sobre la base de un tiempo de ejecución sostenido.

Las mejoras en el control de caché y el comportamiento del transporte también reducen la probabilidad de retches innecesarios y el tratamiento desperdiciado durante la congestión. El ancho de banda y el cuarto de tratamiento son más propensos a seguir siendo utilizables y estables, y las métricas ampliadas y la observabilidad facilitan la identificación de las causas profundas y los plazos de recuperación.

Además, al permitir cambios de configuración y actualizaciones de plataformas con tiempo de inactividad cero, hemos establecido condiciones operativas que facilitan aumentar el rendimiento, la estabilidad y la calidad general de la plataforma a alta frecuencia. La capacidad de seguir mejorando sin pausar la plataforma refuerza aún más la continuidad de los clientes.

Detalles de las mejoras

Esta actualización no se presenta como una versión impulsada por nombres de características específicos o números de versión. En cambio, descompone los escenarios que tienden a dominar los resultados de Solana del entorno real en las siguientes capas: iniciación de la conexión, TLS, L4/HTTP límite, H1/H2 transporte, caché, observabilidad, comportamiento de fracaso y requisitos operativos a largo plazo, y actualiza la plataforma para que estas capas se conecten sin contradicción.

A continuación, explicamos las mejoras incorporadas en términos de cómo contribuyen a la experiencia del cliente y los resultados operativas.

Mejoras para la iniciación de la conexión y el manejo de TLS

Ampliamos el contexto TLS manejado durante el establecimiento de conexión y actualizamos la estructura para que el estado requerido pueda ser retenido y aplicado adecuadamente. Esto hace que las condiciones desajustadas y los registros innecesarios sean menos probables al iniciar la conexión.

También reorganizamos el manejo de TLS, incluida la verificación de certificados y la verificación del nombre de anfitrión, para que se puedan cumplir los requisitos de seguridad al reducir las condiciones en las que los fallos del apretón de manos o la manipulación de inconsistencias crean pérdidas de iniciación que acuden a resultados. Esto no es simplemente una mejora de la seguridad; contribuye a estabilizar el comportamiento desde la conexión iniciando a través de la entrada en tratamiento para las cargas de trabajo de Solana.

Además fortalecimos mecanismos que facilitan el comportamiento de TLS-adjacent para observar y resolver problemas. En los escenarios donde la iniciación domina los resultados, la capacidad de reproducir temas, identificar causas y reflejar las correcciones se convierte rápidamente en la capacidad que preserva la calidad de la experiencia.

Preservar el aula mediante filtración temprana de conexiones innecesarias

Introducimos un mecanismo para filtrar las conexiones TCP en una etapa temprana, actualizando la plataforma tan ilegítima o innecesarias conexiones son menos propensos a presionar el tráfico legítimo. En los endpoints compartidos, las solicitudes de conexión pueden aumentar debido a factores externos o esquejes temporales.

El filtrado en estadio temprano ayuda a asegurar conexiones legítimas son menos propensos a detenerse en la iniciación, mejorando la probabilidad de que el cuarto de baño permanezca disponible durante la carga máxima. Como resultado, el comportamiento es menos propenso a hacerse parcial incluso en escenarios de carga concentrada, y se fortalecen las condiciones para una distribución estable de latencia.

Aclarar el modelo de conexión reorganizando L4/HTTP Boundary

La infraestructura de red no termina en HTTP. El establecimiento de conexión y la continuidad dependen de L4 las condiciones, y la volatilidad en esa capa se propaga a la experiencia de protocolo de alto nivel.

En esta actualización, hemos abstraído L4 manejo de flujo y reorganización la estructura para que el modelo de conexión pueda ser manejado más explícitamente. Esto hace que sea más fácil para la plataforma mantener un comportamiento consistente en escenarios donde las conexiones continúan creciendo, las implementaciones del cliente varían, y la operación de larga duración causa las transiciones estatales.

El comportamiento de reingreso también fue reorganizado para reducir patrones en los que cascadas de volatilidad de corta duración en la experiencia del usuario. La estabilidad práctica depende menos de eliminar los fracasos aislados y más de prevenir las cascadas de fracaso.

Mejoras en el HTTP/1.1 HTTP/2 Transporte y comportamiento de larga duración

Añadimos mediciones que permiten que el volumen de datos transferido se rastree sistemáticamente en HTTP/1.1 HTTP/2. Esto hace que sea más fácil identificar dónde se producen puestos o cuellos de botella en el pipeline de transporte, mejorando tanto la solución de problemas como la velocidad a la que se pueden aplicar las fijaciones.

También reorganizamos HTTP/2 cuerpo-escribir el comportamiento del tiempo fuera así que los puestos no naturales y las colchas son menos probables durante la carga concentrada o la transmisión de larga vida. En funcionamiento a largo plazo, lo que importa no es el rendimiento máximo en los estados ideales, sino la capacidad de evitar que el comportamiento colapse durante las transiciones estatales.

También se han revisado el comportamiento del tiempo de inactividad cero y el manejo de la pool de conexión, eliminando factores de inestabilidad que tienden a acumularse durante el tiempo de funcionamiento sostenido. En el HTTP/1.1 lado, reorganizamos el comportamiento de cierre seguro para conexiones que tienen solicitudes incompletas, reduciendo fuentes de volatilidad en el uso de los recursos y el comportamiento.

Mejoras en el Control de Caché y la Calidad Operativa

Mejoramos la capacidad de rastrear por qué un activo no está caché, aumentando la explicabilidad del comportamiento de caché. En la práctica, lo que domina no es si existe caching, sino en qué condiciones se aplica y en qué condiciones se cae.

Reorganizamos el comportamiento de bloqueo, el manejo de establos y los patrones de revalidación por lo que la experiencia de degradación es menos probable de cascada cuando la contención ocurre bajo carga máxima. También organizamos controles de desalojo para los casos en que el número de activos caché crece, y comportamientos refinados de contenido parcial (incluidas las solicitudes de rango), fortaleciendo las condiciones que reducen los rezones innecesarios y latencia bajo cargas de trabajo reales.

Estas mejoras reducen los casos en los que el comportamiento de caché se convierte en un factor más destacado, lo que hace menos probable que los clientes tengan que diseñar operaciones en torno a la incertidumbre a nivel de infraestructura.

Mejoras en comportamientos de fracaso, registro y observabilidad

El comportamiento y la tala han sido reorganizados así que es más fácil entender lo que sucedió cuando ocurren problemas. Patrones en los que los errores downstream cascadan en caché/transport comportamiento y empeorar la experiencia se reducen, lo que facilita la localización de radio de explosión.

La observabilidad y las mejoras en la solución de problemas no pretenden reclamar “incidentes cero”, sino acortar el tiempo a la recuperación cuando ocurren incidentes. Esto reduce el riesgo en escenarios de máxima carga y de cooperación sostenida.

Actualizaciones de dependencia y correcciones de seguridad como requisitos de funcionamiento a largo plazo

Incorporamos actualizaciones de dependencia y correcciones de seguridad para mantener los requisitos necesarios para la operación de plataforma a largo plazo. Esto incluye actualizaciones relacionadas con la versión mínima de Rust (MSRV) y alineación CI, fortaleciendo la base necesaria para evolucionar continuamente la plataforma.

La capacidad de mantener la actualización segura es en sí misma un requisito para la calidad a largo plazo.

Transición a operaciones de tiempo cero

Anteriormente, el tiempo de inactividad corto podría ocurrir durante cambios de configuración de la red o actualizaciones de la plataforma. Con esta actualización, hemos pasado a una arquitectura donde estas operaciones se pueden aplicar con cero tiempo de inactividad completo.

Los endpoints compartidos siempre tienen conexiones y momentos continuos donde el tiempo importa. Incluso el tiempo de inactividad breve puede desencadenar desconexiones, reconexiones y cascadas de resinc, y ese costo puede propagarse a resultados. Las actualizaciones de tiempo cero reducen la probabilidad de estas cascadas y evitan que las operaciones de larga vida se fragmenten.

Al mismo tiempo, ERPC ahora tiene condiciones operativas que permiten que las cuestiones observadas se reflejen rápidamente en mejoras. La mayor frecuencia de iteración nos permite eliminar continuamente la volatilidad y el comportamiento de los bordes dentro de las operaciones de producción.

Efectos por servicios

Solana RPC (HTTP / WebSocket)

Las mejoras en la iniciación de conexiones, TLS, control de caché y comportamiento del transporte afectan tanto las lecturas de datos como la presentación de transacciones. Si bien se mantiene la usabilidad cotidiana, se reducen los factores que sesgos durante la carga máxima y se refuerzan las condiciones para preservar el cuarto de baño durante la congestión.

Geyser gRPC

La continuidad de conexión ha mejorado para el uso de streaming de larga duración. HTTP/2 el transporte, la consistencia del tiempo, la salud de la pool de conexión y las mediciones de transporte ampliadas trabajan juntas para reducir la probabilidad de que vuelva a conectarse/resync los costos se propagan a los resultados.

Shredstream (Direct Shreds)

Con la gestión de conexiones y las mejoras de iniciación diseñadas para la entrega continua, se refuerzan las condiciones, por lo que los datos faltantes o latencia es menos probable bajo congestión. La continuidad estable para la detección y el seguimiento se vuelve más fácil de sostener.

Conexión de operaciones de producción y producción

La fundación de sistemas distribuidos que incluye ERPC ha sido reconocido como un proyecto de R–D bajo el gobierno holandés WBSO programa. Se establece una estructura en la que las cuestiones observadas operacionalmente pueden incorporarse como temas de investigación y mejorarse mediante la verificación y la iteración.

Esta actualización de la base de la red es una de esas iteraciones aplicadas en todas las regiones, reflejadas en el rendimiento práctico y la estabilidad. Mantener las operaciones y conectar el I+D es un requisito previo para conectar continuamente lo que se observa en la producción a la siguiente actualización, en lugar de detenerse en mejoras únicas.

Dentro ERPC, patrones de uso reales, variabilidad de carga y comportamiento de falla se incorporan en ciclos repetidos de verificación y mejora que aumentan progresivamente la calidad de la fundación de la red. Esta actualización se llevó a cabo dentro de ese marco integrado de operaciones de producción y producción de R cl.

Información para los clientes

Esta actualización ya se ha aplicado a todas las regiones y todos los endpoints compartidos. Existiendo ERPC los clientes no necesitan cambiar la configuración o las operaciones. No hay cambios en los precios, especificaciones, autenticación o límites de tasa.

Debido a que los endpoints compartidos deben mantener ambos picos cortos y conexiones de larga vida simultáneamente, las condiciones se han reorganizado así que el comportamiento es menos probable que se sesgada bajo esas cargas de trabajo mixtas. Incluso cuando los cambios de configuración o actualizaciones de la plataforma ocurren durante las operaciones, los cambios se aplican con tiempo de inactividad cero, por lo que los clientes no necesitan planificar la fragmentación de conexión o el diseño de resync.

Para preguntas sobre arquitectura, optimización del volumen de trabajo o feedback operativa, por favor contacte a través de la Discord oficial de Validators DAO.

Conectando continuamente las observaciones de producción y los comentarios en mejoras, ERPC ha aumentado progresivamente su calidad de fundación. Seguiremos acumulando mejoras con cero tiempo de inactividad y proporcionaremos infraestructura de red que sostenga los resultados de Solana en el entorno real.

Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
ERPC Sitio oficial: https://erpc.global/en