Preguntas Frecuentes - Cierre directo

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 latencia real de la red basada en 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 su entorno no selecciona automáticamente la región óptima, contáctenos desde ERPC Dashboard.

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

Q. 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 su IP registrada desde los hosts proxy que se indican a continuación. Permita 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	`64.130.43.108`, `82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`64.130.41.236`, `151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`67.209.55.19`, `151.245.186.3`
🇬🇧 London	`64.130.63.211`, `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. Si se necesita otra ubicación geográfica, seleccione una región disponible durante la configuración inicial y configure como destino una dirección IPv4 pública válida y no vacía con su puerto. La región seleccionada permanece fija después de la configuración, y el destino puede actualizarse más adelante.

Usar un ERPC VPS cerca de este endpoint · Configurar UDP Forwarding Standard https://erpc.global/en/doc/shredstream/quickstart/

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 copia un ejemplo de cliente de otro proveedor, puede venir configurado con :443 o HTTPS por defecto. Si solo cambia el dominio, el puerto y la configuración TLS pueden quedar igual, lo que impedirá la conexión.

Los endpoints siguientes son ejemplos. Sustitúyalos por su propio endpoint mostrado en el dashboard. Úselo en formato HTTP, o especifique el puerto 80 si su 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 su dirección IP registrada. No añada 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: Sólo he usado WebSocket o Geyser gRPC (YellowStone) antes. ¿Tienes muestras?

Sí. Usted puede comenzar rápidamente a probar conexiones Shreds y desarrollo de aplicaciones usando SLV.

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

Guía de inicio rápido

P: ¿Puedo registrar dos direcciones IP?

Puede utilizar un endpoint por suscripción. Si desea utilizar dos direcciones IP, debe suscribirse a dos suscripciones separadas.

P. ¿Qué región recomienda?

No hay una única región mejor permanente. Solana es global, y el rol de líder rota entre validadores, slot a slot. Regiones con más validadores y mayor participación ven slots de líder más a menudo, lo que puede ayudar a las transacciones a aterrizar más rápido. El intercambio es que el tráfico competidor también se concentra allí, por lo que una región menos concurrida a veces puede ofrecer mejores resultados dependiendo de su estrategia.

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

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

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 seleccionada queda fija después de la configuración, pero el destino puede actualizarse más tarde.

Comprensión realista de los valores de ping: Los valores de ping indican las condiciones ideales y no reflejan la latencia real en la transmisión de las comunicaciones, que suelen experimentar alrededor de 5 veces la latencia de ping. Por ejemplo, un ping de 100ms en todos los continentes resulta de forma realista en unos 500ms de latencia. Por lo tanto, la infraestructura debe establecerse dentro de la misma región para alcanzar ~400ms de latencia.
- 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
  - La 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, debe realizar un seguimiento preciso de los calendarios de validadores en su región específica para identificar los slots con la latencia más baja. Para lograr una latencia mínima, 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, con la transmisión posible en sólo unos pocos milisegundos.
Seguimiento de la lista de líderes: Monitore continuamente el calendario de validadores líderes para su región utilizando la API de slot ERPC Leader ()getLeaderSlots). Proporciona datos en tiempo real sobre los próximos líderes, peso de stake, geolocalización de validadores y valores de ping de referencia, lo que le permite identificar con precisión los slots de trading óptimos con latencia mínima. Los datos de estilo de mapa público y las API nativas de RPC son útiles para una amplia visibilidad de la red, pero no son lo suficientemente precisas para el tiempo de ejecución. La API de slots de líder llena esa brecha con la granularidad necesaria para las decisiones de enrutamiento y negociación.
- Documentación de ERPC Leader Slot API
- ERPC Dashboard

Validators Solutions - Solana network data

Datos de red Solana: Validators Solutions

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

Para lograr con éxito el trading de cero bloques requiere estrategias más sofisticadas, como sigue:

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, monitorear los calendarios de líderes validador en la región donde se encuentra su infraestructura e identificar 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 validador, lo que resulta en una selección de líderes más frecuente y mayores oportunidades comerciales.

Utilice la API de slots de líder ERPC (ERPC)getLeaderSlots) para obtener calendarios de líder en tiempo real, peso de stake, datos de geolocalización de validadores, y valores de ping de referencia con mucha mayor precisión que las fuentes de datos de estilo de mapa público o APIs nativas de RPC. Esto le permite predecir las zonas de oportunidad con mayor precisión y ejecutar operaciones con latencia cercana a cero.
- Documentación de ERPC Leader Slot API
- ERPC 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 recomienda. Además, colocar su nodo dedicado dentro de la misma red que su 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 desea utilizar un endpoint específico, le recomendamos alquilar un servidor situado más cercano a 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, latencia tiende a ocurrir. 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 usted es el único usuario del recurso. Esto significa que no se ve afectado por otros usuarios, garantizando respuestas 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 su suscripción se mantiene activa, el precio promocional que fijó al registrarse permanece en vigor. Los entornos que se mantienen bajo la carga de trabajo en tiempo real de Solana son mundialmente escasos, y planeamos aumentar los precios de lista de acuerdo con la creciente demanda de hardware y red. Las configuraciones más altas y las regiones de alta demanda se venden más rápido, por lo que el bloqueo del precio promocional actual es la opción más rentable a largo plazo.

Q. Quiero pagar con cripto

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

Use esos ERPC Credits para activar o continuar planes de ERPC. Abra el dashboard, elija el pago con cripto, envíe la transferencia desde su wallet, y el dashboard verificará la transacción y aplicará los credits a su 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, pague con tarjeta de crédito.

ERPC Web Dashboard

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

Por diseño, Shreds no incluye cada transacción en la cadena de bloques Solana. La vigilancia de todas las transacciones requeriría desplegar numerosos proxies a nivel mundial y recibir Shreds de cada validador, 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 su 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, que pueden no ser realistas en la práctica.

Geyser gRPC ofrece fiabilidad superior al 99%, que es notablemente superior a Shreds, un hecho confirmado por muchos usuarios, incluyendo nosotros. Sin embargo, los fragmentos suelen proporcionar más del 90% de fiabilidad.

Aunque no capturan cada transacción, su ventaja clave es la capacidad de recuperar rápidamente la mayoría de las transacciones más rápido que Geyser gRPC.

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

P: Quiero el mejor ambiente posible.

Para la configuración óptima, recomendamos combinar un nodo dedicado de Shreds con nuestro servidores bare metal. Compartir la misma red, esta configuración logra una comunicación privada de cero distancia con retrasos alrededor de 0.1ms ping.

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

ERPC Dashboard

🔗 ERPC Dashboard

P: ¿Cómo es la latencia?

La latencia varía según el método de medición y su entorno de uso específico. En lugar de centrarse en valores numéricos exactos, es crucial asegurar que la latencia cumpla con sus 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 varían 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 su cliente.

Si encuentra nuestro servicio más lento, indícanos las condiciones específicas y los competidores que ha comparado con él a través de ERPC Dashboard. Identificaremos la causa y mejoraremos aún más la velocidad.

ERPC 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 necesita 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 encuentra 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?

Basado en los comentarios del cliente, la orden de rendimiento es:

Shreds / gRPC / WebSockets

Si su experiencia difiere, por favor infórmenos.

P: La latencia no es lo que esperaba.

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

Rust >= Go >= TypeScript (JavaScript) >= Python

Para las comparaciones detalladas, consulte:

Comparación de velocidad de lenguaje de programación

Recomendamos firmemente Rust para el máximo rendimiento.