RPC de Polygon: Cómo elegir un endpoint que soporte tráfico de producción

Los RPC de Polygon son los endpoints JSON-RPC que tu aplicación llama para leer el estado, enviar transacciones y suscribirse a eventos en la red Polygon PoS. Si buscaste "rpc de polygon", probablemente necesites una de tres cosas: un endpoint que funcione ahora mismo, una forma de comparar endpoints antes de comprometerte, o una solución para un endpoint que comenzó a comportarse mal bajo carga. Esta página cubre las tres, comenzando por la decisión que más importa.

Recomendación rápida: qué RPC de Polygon se adapta a tu carga de trabajo

Adapta el endpoint a lo que tu aplicación realmente hace, no a lo que usó un tutorial.

Si aún estás prototipando, un endpoint público está bien. Una vez que usuarios reales o dinero real tocan la aplicación, pasa a una API RPC administrada como el servicio RPC de OnFinality, y considera un nodo dedicado cuando tu tráfico sea predecible y pesado.

Qué es realmente un endpoint RPC de Polygon

Polygon PoS es una cadena compatible con EVM, por lo que su superficie RPC es la interfaz JSON-RPC estándar de Ethereum. Tu cliente envía un cuerpo JSON a través de HTTP POST (o abre un WebSocket) y recibe un resultado. El ID de cadena para Polygon Mainnet es 137, la moneda nativa es POL, y el explorador canónico es polygonscan.com.

Un endpoint público de OnFinality para Polygon Mainnet se ve así:

https://polygon.api.onfinality.io/public

Esa URL acepta tráfico HTTP y WebSocket. Para cualquier cosa más allá de pruebas ligeras, normalmente usarías una clave API para que tu tráfico se atribuya a tu cuenta en lugar de a capacidad compartida.

Configuración de la cadena de un vistazo

Usa estos valores al agregar Polygon a una billetera o a una configuración de cliente.

Para trabajo en testnet, el endpoint de Amoy es https://polygon-amoy.api.onfinality.io/public con ID de cadena 80002 y explorador https://amoy.polygonscan.com. Mantén las configuraciones de mainnet y testnet en archivos de entorno separados para que un ID de cadena errante nunca llegue a producción.

Una configuración mínima de billetera o cliente en JavaScript:

const polygon = {
  chainId: "0x89", // 137
  chainName: "Polygon Mainnet",
  nativeCurrency: { name: "POL", symbol: "POL", decimals: 18 },
  rpcUrls: ["https://polygon.api.onfinality.io/public"],
  blockExplorerUrls: ["https://polygonscan.com"],
};

Lectura y escritura: las llamadas que dominan tu tráfico

La mayor parte del tráfico RPC de Polygon es un conjunto pequeño de métodos. Saber cuáles llamas más te dice qué optimizar.

• eth_chainId y net_version para verificaciones de conectividad.
• eth_blockNumber y eth_getBlockByNumber para seguimiento de la cabeza de la cadena.
• eth_getBalance, eth_call y eth_getCode para lecturas.
• eth_getLogs para indexación de eventos, a menudo la llamada más pesada.
• eth_sendRawTransaction para escrituras.
• eth_subscribe sobre WebSocket para nuevas cabezas y logs.

Una verificación rápida de conectividad con curl:

curl -s https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Si eso devuelve un número de bloque en hexadecimal, tu endpoint es accesible. Si se cuelga, el problema suele ser la ruta de red o la disponibilidad del endpoint, no tu payload.

Dónde fallan los RPC de Polygon bajo tráfico real

Los problemas de endpoint rara vez aparecen en una prueba de hello-world. Aparecen cuando la concurrencia, los rangos de logs o las suscripciones crecen.

Una sonda de monitoreo simple detecta la mayoría de estos antes que los usuarios:

async function probe(url) {
  const start = Date.now();
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] }),
  });
  const body = await res.json();
  return { ok: res.ok, ms: Date.now() - start, block: body.result };
}

Ejecuta esto contra cada endpoint del que dependas, registra la latencia y la altura del bloque, y alerta cuando un proveedor se quede atrás de los demás.

Suscripciones WebSocket y cuándo usarlas

Hacer polling de eth_blockNumber funciona, pero desperdicia solicitudes. Si tu aplicación necesita actualizaciones en vivo, abre un WebSocket y suscríbete:

const ws = new WebSocket("wss://polygon.api.onfinality.io/public");
ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0", id: 1,
    method: "eth_subscribe",
    params: ["newHeads"],
  }));
};
ws.onmessage = (event) => console.log(JSON.parse(event.data));

Las conexiones WebSocket tienen estado, así que planifica reconexiones, retroceso y manejo de eventos duplicados. Si tu proveedor no admite WebSocket, estás atascado con polling, lo que aumenta el volumen de solicitudes y el costo.

Evaluación de proveedores de RPC de Polygon

Cuando compares proveedores, compara con tu carga de trabajo, no con una lista genérica de características. OnFinality aparece primero aquí porque es la opción en torno a la cual se construye esta página, pero los criterios se aplican a cualquier proveedor.

Pregunta a cada proveedor lo mismo: cuál es la tasa de solicitudes sostenida por plan, si se incluyen datos de archivo, si se exponen los métodos debug y trace, cómo se cuentan las conexiones WebSocket, y qué sucede durante una actualización de cadena o una reorganización. Puedes leer un marco más completo en cómo elegir un proveedor de RPC.

Failover y redundancia sin sobreingeniería

Un solo endpoint es un único punto de falla. No necesitas una malla compleja, pero sí necesitas un respaldo.

1. Mantén un endpoint primario y uno secundario de un proveedor o región diferente.
2. Verifica la salud de ambos según un calendario y enruta al que esté saludable.
3. Para escrituras, reintenta con la misma transacción firmada en lugar de volver a firmar.
4. Registra qué endpoint atendió cada solicitud para que los incidentes sean rastreables.
5. Vuelve a probar el failover después de cada cambio de proveedor o plan.

Esto es suficiente para la mayoría de las dApps en producción. Los equipos con necesidades estrictas de tiempo de actividad generalmente pasan a un nodo dedicado para que la capacidad no se comparta.

Planificación de costos y capacidad

El costo de RPC sigue el volumen de solicitudes, el peso del método y el número de conexiones. Las lecturas son baratas; eth_getLogs sobre rangos amplios y las consultas de archivo son costosas. Antes de escalar, estima tus solicitudes máximas por segundo, tu rango de logs promedio y cuántos clientes WebSocket mantienes abiertos. Luego elige un plan que deje margen, y revisa precios de RPC contra esa estimación en lugar de adivinar. Si tu uso es irregular, una API administrada absorbe mejor los picos que un nodo de tamaño fijo.

Puntos clave

• Los RPC de Polygon son endpoints JSON-RPC EVM estándar; ID de cadena 137, moneda nativa POL.
• Los endpoints públicos sirven para pruebas; las aplicaciones en producción deben usar un endpoint administrado con clave.
• eth_getLogs, las lecturas de archivo y las suscripciones WebSocket son las llamadas con más probabilidades de fallar bajo carga.
• Compara proveedores en rendimiento, profundidad de archivo, soporte de trace, límites de WebSocket y failover.
• Mantén un endpoint secundario y verifica su salud antes de necesitarlo.
• OnFinality ofrece una API RPC administrada y nodos dedicados para Polygon; consulta redes RPC compatibles para la lista actual.

Preguntas frecuentes

¿Cuál es el endpoint RPC de Polygon Mainnet?

El endpoint público de OnFinality para Polygon Mainnet es https://polygon.api.onfinality.io/public, compatible con HTTP y WebSocket. Para producción, usa un endpoint con clave desde la página de la red Polygon.

¿Qué ID de cadena usa Polygon?

Polygon Mainnet usa el ID de cadena 137 (0x89). La testnet Amoy usa 80002.

¿Necesito un nodo de archivo para Polygon?

Solo si consultas estado histórico o rangos amplios de logs. Las lecturas estándar y los bloques recientes funcionan en nodos que no son de archivo.

¿Puedo usar WebSocket con los RPC de Polygon?

Sí. El endpoint de Polygon de OnFinality admite WebSocket, lo cual es útil para eth_subscribe en nuevas cabezas y logs.

¿Cómo soluciono los errores 429 de un RPC de Polygon?

Las respuestas 429 significan que alcanzaste un límite de velocidad. Pasa a un endpoint administrado con clave, reduce el volumen de solicitudes o agrupa llamadas cuando sea posible.

¿Cuándo debo usar un nodo dedicado de Polygon en lugar de un endpoint compartido?

Cuando tu tráfico es pesado y predecible, cuando necesitas capacidad aislada, o cuando los límites de velocidad compartidos interfieren con la producción. Consulta nodos dedicados.