FAQ - Direct Shreds

P: Mi salida de Shreds / getBlock de repente se ve rota o devuelve -32015: ¿qué ha cambiado?

Solana Transaction v1 (SIMD-0385) entró en vigor en la mainnet de Solana el 15 de septiembre de 2026, en el epoch 1035. El formato wire de una transacción v1 empieza con el byte de prefijo de versión 0x81, las firmas van después del mensaje y ya no hay prefijo de longitud legacy.

Si decodificas tú mismo las entries de ShredStream, Direct Shreds o UDP Forwarding, un decodificador bincode o solana-entry anterior a la versión 4.2 interpreta ese byte 0x81 como el número de firmas, lo que se manifiesta como un error EOF, un desbordamiento de compact-length o un error "invalid message version". Los usuarios de Geyser gRPC que deserializan transacciones en bruto con crates anteriores a 4.2 tienen el mismo problema. Las llamadas RPC a getBlock y getTransaction con maxSupportedTransactionVersion: 0 devuelven -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress en modo full informa del mismo error en cada fila afectada. No te afecta si ya lees las respuestas JSON parseadas de ERPC con la versión 1 configurada.

Establece maxSupportedTransactionVersion en 1 dentro del objeto de opciones: el segundo parámetro de getBlock y getTransaction, y también las opciones de getTransactionsForAddress:

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Actualiza el Solana Stream SDK a 2.0.0: solana-stream-sdk de Rust en crates.io, o @validators-dao/solana-stream-sdk y @validators-dao/solana-shreds-client en npm. Actualiza @validators-dao/solana-entry-decoder a 2.5.0 por separado. 1.4.0 y entry-decoder 2.4.0 no soportan v1. Los decodificadores Rust propios deberían pasar a solana-entry 4.2.x.

P: ¿En qué regiones se encuentran sus nodos?

Actualmente operamos nodos en las siguientes regiones:

Frankfurt (FRA)
Amsterdam (AMS)
Londres (LON)
Dublín (DUB)
Nueva York (NY)
Chicago (CHI)
Salt Lake City (SLC)
Tokio (TY)
Singapur (SGP)
Sídney (SYD)

ERPC mide la latencia real de la red a partir de las rutas reales, seleccionando automáticamente la región con la latencia más baja en lugar de depender de la distancia en línea recta. Este enfoque no solo mejora la latencia de usuarios individuales, sino que también aumenta la eficiencia general de la red y refuerza la resiliencia global de ERPC ante posibles ataques.

Si tu entorno no selecciona automáticamente la región óptima, contáctanos desde el ERPC Web Dashboard.

ERPC Web Dashboard: https://dashboard.erpc.global/es

P: La latencia muestra 9999 ms y se selecciona una región no óptima. ¿Qué debo hacer?

Para seleccionar la región de Shreds, ERPC envía sondeos de latencia ICMP a tu IP registrada desde los hosts proxy que se indican a continuación. Permite solicitudes de eco ICMP entrantes desde todas las IP de origen indicadas. Si un firewall (ufw, firewall en la nube, grupo de seguridad, etc.) las bloquea, la medición puede mostrar 9999ms y podría seleccionarse una región no óptima. Varias IP en una misma región corresponden a hosts de sondeo distintos; todas son necesarias.

Región	IP de origen ICMP
🇳🇱 Amsterdam	`82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`151.245.186.3`
🇬🇧 London	`151.241.65.10`

Far Point seleccionado

El Far Point de Shared Shreds es una alternativa de capacidad limitada. Cada endpoint admite hasta 32 streams simultáneos mediante proxy entre todos los clientes; no son 32 cupos por cliente. La transmisión es más eficaz cuando el suscriptor se ejecuta cerca del endpoint de Shreds seleccionado; los streams de larga distancia mantienen ocupadas durante más tiempo las conexiones compartidas, las ventanas de control de flujo y la capacidad de salida. Para ayudar a mantener la capacidad de respuesta del entorno compartido, permite todas las direcciones IP de origen de las sondas ICMP regionales indicadas y vuelve a ejecutar la selección de región. Para un uso continuado, considera un ERPC VPS cerca del endpoint seleccionado. Para UDP Forwarding Standard, selecciona una región disponible durante la configuración inicial y configura como destino una dirección IPv4 pública válida y no vacía con su puerto. La región y el destino se pueden cambiar más adelante en el dashboard. Al cambiar la región, cambia la IP de origen del reenvío, por lo que el firewall del lado receptor debe permitir la nueva IP de origen del reenvío.

Usar un ERPC VPS cerca de este endpoint · Configurar UDP Forwarding Standard Leer la guía de inicio rápido de Direct Shreds

P: He permitido mi IP, pero todavía no puedo conectarme. ¿Qué debo comprobar?

Los endpoints gRPC y Shreds de ERPC usan HTTP sin TLS en el puerto 80, protegido por allowlist de IP. No usan HTTPS/TLS en el puerto 443.

Si copias un ejemplo de cliente de otro proveedor, puede venir configurado con :443 o HTTPS por defecto. Si solo cambias el dominio, el puerto y la configuración TLS pueden quedar igual, lo que impedirá la conexión.

Los endpoints siguientes son ejemplos. Sustitúyelos por tu propio endpoint mostrado en el dashboard. Úsalo en formato HTTP, o especifica el puerto 80 si tu cliente requiere host y puerto:

No válido: shreds-fra6-1.erpc.global:443
Válido: shreds-fra6-1.erpc.global:80
Formato URL válido: http://shreds-fra6-1.erpc.global

La autenticación se basa en tu dirección IP registrada. No añadas cabeceras x-token, token ni Authorization para endpoints gRPC o Shreds de ERPC, salvo que una página de producto específica lo indique explícitamente.

P: Solo he usado WebSocket o Geyser gRPC (YellowStone) antes. ¿Tienen ejemplos?

Sí. Con SLV puedes empezar enseguida a probar conexiones de Shreds y a desarrollar aplicaciones.

Consulta la siguiente guía para más detalles:

Guía de inicio rápido de Shreds

P: ¿Puedo registrar dos direcciones IP?

Puedes utilizar un endpoint por suscripción. Si deseas utilizar dos direcciones IP, debes contratar dos suscripciones independientes.

P: ¿Qué región recomiendan?

No existe una única región que sea siempre la mejor. Solana es global y el rol de líder rota entre validadores, slot a slot. Las regiones con más validadores y más stake reciben slots de líder con más frecuencia, lo que puede ayudar a que las transacciones se incluyan antes en un bloque. La contrapartida es que el tráfico de la competencia también se concentra allí, por lo que, según tu estrategia, una región menos concurrida a veces puede ofrecer mejores resultados.

Como punto de partida práctico, elige una región con alta densidad de validadores como Frankfurt o la costa este de los Estados Unidos cuando más importe recibir un flujo constante de slots de líder, o sitúate cerca de un validador objetivo específico cuando la ruta de ejecución más corta sea la prioridad. Usa Validators Solutions para entender la distribución pública de la red Solana y luego usa la ERPC Leader Slot API y las mediciones reales para decidir si es apropiado un despliegue en una sola región, en dos regiones o global.

P: Necesito latencia de al menos ~400ms o mejor.

Para lograr una latencia de aproximadamente 400ms o menos, ten en cuenta estos puntos esenciales:

Comprensión realista de los valores de ping: Los valores de ping reflejan condiciones ideales y no la latencia real de las comunicaciones en streaming, que suele rondar 5 veces la latencia del ping. Por ejemplo, un ping de 100ms entre continentes se traduce en la práctica en unos 500ms de latencia. Por lo tanto, para alcanzar ~400ms de latencia, la infraestructura debe estar en la misma región.
- Referencia típica del valor del ping:
  - Misma red: ~0.1ms
  - Interconexión de red privada (PNI): ~0.2ms
  - Mismo centro de datos: ~0.3ms
  - Misma ciudad: ~1ms
  - País vecino: ~5–10ms
  - Intercontinental: ~100–300ms
Evitar la trampa de la latencia media: Los validadores de Solana están geográficamente dispersos a nivel mundial, y el calendario de líderes cambia aleatoriamente con cada época. Confiar en la latencia media para alcanzar ~400ms es poco práctico. En su lugar, debes realizar un seguimiento preciso de los calendarios de validadores en tu región específica para identificar los slots con la latencia más baja. Para lograr una latencia mínima de forma constante, se necesita infraestructura en todas las regiones pertinentes. Dentro de la misma región, la adquisición de datos puede ocurrir en decenas de milisegundos, y la transmisión, en solo unos pocos milisegundos.
Seguimiento del calendario de líderes: Monitorea el calendario de validadores líderes de tu región con la ERPC Leader Slot API (getLeaderSlots). Devuelve el calendario de próximos líderes, el peso de stake de la época actual, la geolocalización estimada de los validadores y valores de ping de referencia, para que puedas identificar los slots de menor latencia a los que apuntar antes de que lleguen. Los datos públicos tipo mapa y las API RPC nativas son útiles para tener una visión amplia de la red, pero no son lo bastante precisos para sincronizar la ejecución. La Leader Slot API cubre ese hueco con la granularidad necesaria para las decisiones de enrutamiento y trading.
- Documentación de ERPC Leader Slot API
- ERPC Web Dashboard

Validators Solutions - Solana network data

Datos de red Solana: Validators Solutions

P: ¿Cómo puedo lograr el trading de cero bloques (cero-slot)?

Lograr con éxito el trading de cero bloques (cero-slot) requiere estrategias más sofisticadas, como las siguientes:

Identificar zonas de oportunidad: Los validadores de Solana se distribuyen globalmente, y es físicamente imposible alcanzar la latencia óptima para cada slot. Por lo tanto, monitorea los calendarios de validadores líderes en la región donde se encuentra tu infraestructura e identifica las zonas de oportunidad más favorables. El despliegue de infraestructura en varias regiones también puede ser ventajoso. Por ejemplo, Frankfurt es una región clave debido a su alta densidad de validadores, lo que resulta en una selección de líderes más frecuente y más oportunidades de trading.

Utiliza la ERPC Leader Slot API (getLeaderSlots) para consultar el calendario de próximos líderes, el peso de stake de la época actual, datos estimados de geolocalización de validadores y valores de ping de referencia, con mucha más precisión que las fuentes públicas de datos tipo mapa o las API RPC nativas. Así puedes identificar las zonas de oportunidad antes de que lleguen los slots y ejecutar operaciones con latencia cercana a cero.
- Documentación de ERPC Leader Slot API
- ERPC Web Dashboard
Usar nodos dedicados: Si te cuesta competir, considera desplegar nodos dedicados. Los nodos compartidos experimentan latencia debido al tráfico de otros usuarios, y por lo tanto no se recomiendan. Además, colocar tu nodo dedicado dentro de la misma red que tu aplicación reduce significativamente la latencia de la red y optimiza el rendimiento.

P: ¿Puedo usar un endpoint específico?

Para mantener un entorno de baja latencia, nuestro sistema selecciona automáticamente el nodo disponible más cercano. Si deseas utilizar un endpoint específico, te recomendamos alquilar un servidor situado lo más cerca posible de ese endpoint.

P: ¿Por qué los endpoints dedicados son más rápidos?

Los endpoints compartidos son utilizados por múltiples clientes que comparten los mismos recursos. A medida que aumenta el tráfico, tiende a aparecer latencia. Los recursos del servidor tienen límites físicos, y la cantidad de trabajo que pueden manejar es finita. Cuando llegan demasiadas solicitudes al mismo tiempo, deben ser procesadas secuencialmente, lo que resulta en tiempos de respuesta más lentos.

Aunque tomamos varias medidas para optimizar el rendimiento incluso en endpoints compartidos, con endpoints dedicados eres el único usuario del recurso. Esto significa que no te ves afectado en absoluto por otros usuarios, lo que garantiza respuestas siempre estables y rápidas.

Además, los endpoints dedicados ofrecen opciones de comunicación sin TLS, como HTTP. Al omitir el handshake TLS (unos 20 ms), la comunicación se vuelve aún más rápida en comparación con HTTPS.

P: ¿Se aumentará el precio de venta después de suscribirme?

Mientras tu suscripción siga activa, se mantiene el precio promocional que fijaste al registrarte. Los entornos capaces de soportar la carga de trabajo en tiempo real de Solana escasean en todo el mundo, y tenemos previsto subir los precios de lista a medida que crezca la demanda de hardware y de red. Las configuraciones de mayores prestaciones y las regiones con más demanda son las que antes se agotan, por lo que asegurarte el precio promocional actual es la opción más rentable a largo plazo.

P: Quiero pagar con cripto

Los pagos con cripto están disponibles desde el ERPC Web Dashboard cuando el país de tu dirección de facturación registrada es uno de los países miembros de la UE. Puedes usar SOL, USDC o EURC para comprar ERPC Credits.

Usa esos ERPC Credits para activar o continuar planes de ERPC. Abre el dashboard, elige el pago con cripto, envía la transferencia desde tu wallet y el dashboard verificará la transacción y aplicará los credits a tu cuenta.

Países admitidos: Alemania, Austria, Bélgica, Bulgaria, Chequia, Chipre, Croacia, Dinamarca, Eslovaquia, Eslovenia, España, Estonia, Finlandia, Francia, Grecia, Hungría, Irlanda, Italia, Letonia, Lituania, Luxemburgo, Malta, Países Bajos, Polonia, Portugal, Rumanía, Suecia.

Para los países que no están en la lista, paga con tarjeta de crédito.

ERPC Web Dashboard

P: ¿Por qué ShredStream no incluye todas las transacciones?

Por diseño, Shreds no incluye todas las transacciones de la cadena de bloques de Solana. Monitorizar todas las transacciones requeriría desplegar numerosos proxies en todo el mundo y recibir Shreds de todos los validadores, lo que no es práctico.

Por lo general, los usuarios operan con un subconjunto de los datos disponibles, ya que este enfoque es suficiente para la mayoría de las aplicaciones del entorno real. Si tu caso de uso exige una cobertura completa de datos sin pérdida alguna, Shreds podría no ser adecuado.

Para escenarios que requieren un monitoreo más completo, Geyser gRPC proporciona mayor fiabilidad en comparación con Shreds. Sin embargo, lograr una cobertura de datos del 100% en la cadena de bloques de Solana requiere desplegar numerosos servidores edge, lo que puede no ser realista en la práctica.

Geyser gRPC ofrece una fiabilidad superior al 99%, notablemente mayor que la de Shreds, algo que han confirmado muchos usuarios, incluidos nosotros. Aun así, Shreds suele ofrecer más del 90% de fiabilidad.

Aunque no capturan todas las transacciones, su principal ventaja es que permiten obtener la mayoría de ellas más rápido que Geyser gRPC.

Para un entendimiento más profundo, recomendamos explorar los protocolos Turbine y Gulf Stream de Solana:

P: Quiero el mejor entorno posible.

Para UDP Forwarding Standard, selecciona una región disponible durante la configuración inicial y configura como destino una dirección IPv4 pública válida y no vacía con su puerto. La región y el destino se pueden cambiar más adelante en el dashboard. Al cambiar la región, cambia la IP de origen del reenvío, por lo que el firewall del lado receptor debe permitir la nueva IP de origen del reenvío.

Contáctanos desde el ERPC Web Dashboard para más detalles.

ERPC Web Dashboard

🔗 ERPC Web Dashboard

P: ¿Cómo es la latencia?

La latencia varía según el método de medición y tu entorno de uso específico. En lugar de centrarte en valores numéricos exactos, es crucial asegurarte de que la latencia cumpla con tus requisitos operativos reales.

Proporcionamos herramientas fáciles de usar en TypeScript y Rust para medir la latencia.

P: ¿Es este RPC (gRPC, Shreds) más rápido que otros?

Diseñamos cada nivel de precio para la velocidad, y nos alegra que se mida en comparación directa con cualquier otro proveedor. Los resultados pueden variar según la región, el uso de un endpoint compartido o dedicado, el protocolo (WebSockets, gRPC o Shreds) y el lenguaje de programación de tu cliente.

Si encuentras nuestro servicio más lento, indícanos a través del ERPC Web Dashboard las condiciones específicas y los competidores con los que lo has comparado. Identificaremos la causa y mejoraremos aún más la velocidad.

ERPC Web Dashboard

P: ¿Qué plan ofrece el rendimiento más rápido?

En general, nuestro plan de más alto nivel proporciona el rendimiento más rápido debido a las CPU superiores, capacidades de memoria más altas y configuraciones de hardware robustas.

También ofrecemos soluciones personalizadas si necesitas servidores aún más potentes, pero nuestros planes estándar están diseñados para ofrecer relaciones precio-rendimiento óptimas.

Confiamos en ofrecer un rendimiento de clase mundial a cada nivel de precios. Si encuentras un proveedor más rápido dentro del mismo rango de precios, avísanos para que podamos investigar y hacer mejoras.

P: Estoy experimentando alta latencia. ¿Por qué?

La latencia aumenta significativamente con la distancia desde el endpoint. Recomendamos acceder desde un servidor situado más cerca del endpoint proporcionado. Los entornos más rápidos están disponibles a través de nuestros servidores bare metal y servicios VPS.

P: ¿Cuál es el más rápido: WebSockets, gRPC o Shreds?

Según los comentarios de los clientes, el orden de rendimiento es:

Shreds > gRPC > WebSockets

Si tu experiencia difiere, por favor, infórmanos.

P: La latencia no es lo que esperaba.

El rendimiento varía significativamente dependiendo del lenguaje de programación utilizado. En general, el orden de rendimiento es:

Rust > Go > TypeScript (JavaScript) > Python

Para comparaciones detalladas, consulta:

Comparación de velocidad de lenguaje de programación

Recomendamos firmemente Rust para el máximo rendimiento.