RPC público de Polygon: cuándo usarlo y cuándo cambiar

¿Es el RPC público de Polygon el endpoint adecuado para tu carga de trabajo?

Un RPC público es la forma más rápida de comunicarse con Polygon, pero es un recurso compartido. Antes de pegar un endpoint en un archivo de configuración, compáralo con el trabajo que le vas a pedir.

Si estás prototipando, el endpoint público elimina toda fricción de configuración. Si estás lanzando a usuarios, trata el endpoint público como un respaldo, no como la ruta principal. OnFinality ofrece tanto una API RPC compartida como nodos Polygon dedicados, para que puedas empezar con el público y actualizar sin cambiar la lógica de tu aplicación.

Configuración de la cadena Polygon que necesitas para conectarte

Polygon PoS mainnet usa el ID de cadena 137 y el token de gas nativo POL. Mantén estos valores consistentes en billeteras, bibliotecas y configuraciones de despliegue, porque una discrepancia es una de las causas más comunes de errores de "red incorrecta".

Para trabajo en testnet, Polygon Amoy usa el ID de cadena 80002, el token POL y el explorador en https://amoy.polygonscan.com. Su endpoint público es https://polygon-amoy.api.onfinality.io/public. Consulta la página de red de Polygon para la lista actual de endpoints y soporte de transporte.

Una solicitud mínima contra el endpoint público

Comienza con una llamada de solo lectura. eth_chainId confirma que estás en la red correcta, y eth_blockNumber confirma que el endpoint está respondiendo.

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

Una respuesta saludable devuelve 0x89, que es 137 en hexadecimal. Si obtienes un valor diferente, estás apuntando a otra cadena. Si obtienes un HTTP 429 o un error JSON-RPC, el endpoint está limitando la velocidad o no está disponible temporalmente.

En JavaScript, la misma verificación se ve así con viem:

import { createPublicClient, http } from 'viem'
import { polygon } from 'viem/chains'

const client = createPublicClient({
  chain: polygon,
  transport: http('https://polygon.api.onfinality.io/public')
})

const chainId = await client.getChainId()
const block = await client.getBlockNumber()
console.log({ chainId, block })

Para la configuración de billeteras, los usuarios pueden agregar Polygon manualmente con los valores de la tabla anterior, o puedes solicitarlo con wallet_addEthereumChain. Mantén la URL del RPC en un solo lugar en tu frontend para que puedas cambiarla más tarde sin buscar en todos los componentes.

Lo que el endpoint público hace bien y dónde se tensiona

El endpoint público es una puerta de enlace compartida. Es excelente para lecturas, interacciones con billeteras y desarrollo. No está diseñado para tráfico paralelo sostenido o consultas pesadas de registros.

• Lecturas y escrituras simples: eth_call, eth_getBalance, eth_sendRawTransaction y eth_getTransactionReceipt se comportan normalmente.
• Consultas de registros: eth_getLogs sobre rangos amplios de bloques es el primer método que se limita, porque es costoso para el nodo servirla.
• Suscripciones WebSocket: existe soporte de transporte, pero las suscripciones compartidas pueden caerse bajo carga. La lógica de reconexión es obligatoria.
• Datos de archive: los endpoints públicos suelen servir estado reciente. Las consultas históricas profundas pueden fallar o agotar el tiempo de espera.
• Métodos de trace y debug: generalmente no están disponibles o están restringidos en endpoints públicos compartidos.

Si tu aplicación depende de cualquiera de los últimos tres, planifica un endpoint gestionado o dedicado en lugar de descubrir el límite en producción.

Síntomas que indican que es hora de dejar el RPC público

No necesitas un plan formal de capacidad para saber que el endpoint público ya no es suficiente. Estas señales aparecen temprano:

1. Respuestas 429 intermitentes durante horas pico, incluso con tasas de solicitud modestas.
2. Tiempos de espera en eth_getLogs cuando amplías un rango de bloques para un relleno.
3. Desconexiones de WebSocket que tu cliente no recupera limpiamente.
4. Latencia inconsistente que hace que los indicadores de carga de la UI se sientan aleatorios en lugar de predecibles.
5. Estado histórico faltante cuando un usuario abre una transacción o posición antigua.
6. Sin visibilidad sobre por qué falló una solicitud, porque los endpoints compartidos rara vez exponen métricas por clave.

Cuando aparecen dos o más de estos, la solución no es un bucle de reintento más largo. Es un endpoint con capacidad que tú controlas.

Pasar de RPC público a gestionado o dedicado de Polygon

La migración suele ser un cambio de configuración, no una reescritura. Mantén la interfaz idéntica y cambia el destino del transporte.

// Antes: endpoint público compartido
const transport = http('https://polygon.api.onfinality.io/public')

// Después: endpoint gestionado con tu propia clave
const transport = http(process.env.POLYGON_RPC_URL, {
  retryCount: 3,
  retryDelay: 250,
  timeout: 10_000
})

Un despliegue práctico:

1. Coloca el endpoint en una variable de entorno para poder cambiarlo sin un despliegue.
2. Ejecuta el endpoint gestionado en staging y compara tasas de error y latencia con la línea base pública.
3. Agrega un proveedor de respaldo o un segundo endpoint para failover.
4. Mueve primero las rutas de muchas lecturas, luego las escrituras, luego cualquier carga de trabajo de archive o trace.
5. Mantén el endpoint público como respaldo de último recurso, no como predeterminado.

Si necesitas rendimiento predecible, recursos aislados o acceso a archive y trace, los nodos dedicados te dan un nodo que no se comparte con otros clientes. Si quieres capacidad gestionada sin operar el nodo tú mismo, el servicio de API RPC es el camino intermedio. Compara planes en la página de precios de RPC.

Elegir entre endpoints públicos, compartidos y dedicados

Usa esta matriz para emparejar el tipo de endpoint con la carga de trabajo en lugar de con una línea de presupuesto.

OnFinality abarca los niveles compartido y dedicado: puedes comenzar con la API RPC compartida y pasar a infraestructura Polygon dedicada a medida que crece el tráfico, manteniendo la misma interfaz JSON-RPC. Para un marco de evaluación más amplio, consulta cómo elegir un proveedor de RPC.

Lista de verificación operativa antes de lanzar

Incluso en un endpoint gestionado, algunos hábitos previenen la mayoría de los incidentes:

• Fija el ID de cadena en la configuración de tu cliente para que una respuesta de red incorrecta falle rápido.
• Establece tiempos de espera y reintentos explícitos en lugar de confiar en los valores predeterminados de la biblioteca.
• Agrupa lecturas donde la biblioteca lo admita para reducir el número de solicitudes.
• Almacena en caché datos inmutables como recibos confirmados y registros antiguos.
• Monitorea la tasa de error y la latencia p95 por método, no solo en general.
• Alerta sobre 429s y reconexiones de WebSocket, ya que ambos preceden a fallos visibles para el usuario.
• Mantén un endpoint de respaldo configurado y probado, no solo documentado.

Una sonda de monitoreo simple puede detectar la degradación del endpoint antes que los usuarios:

#!/usr/bin/env bash
RPC="${POLYGON_RPC_URL:-https://polygon.api.onfinality.io/public}"
START=$(date +%s%3N)
RESP=$(curl -s -o /dev/null -w "%{http_code}" "$RPC" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
END=$(date +%s%3N)
echo "status=$RESP latency_ms=$((END-START))"

Ejecuta esto en un horario y registra la salida. Una tendencia de latencia creciente o una serie de respuestas no-200 es tu advertencia más temprana de que el endpoint actual ya no es suficiente.

Puntos clave

• El RPC público de Polygon en https://polygon.api.onfinality.io/public es un endpoint compartido adecuado para desarrollo, billeteras y scripts de bajo volumen.
• Polygon mainnet usa el ID de cadena 137 y POL como token nativo; la testnet Amoy usa el ID de cadena 80002.
• eth_getLogs, consultas de archive, métodos de trace y uso intensivo de WebSocket son las primeras cargas de trabajo que alcanzan los límites del endpoint compartido.
• 429s intermitentes, tiempos de espera y caídas de WebSocket son señales para pasar a un endpoint gestionado o dedicado.
• La migración suele ser un cambio de transporte más reintentos, tiempos de espera y un respaldo, no una reescritura de la aplicación.
• OnFinality ofrece RPC compartido y nodos Polygon dedicados, para que puedas escalar la capacidad sin cambiar tu interfaz JSON-RPC. Consulta redes RPC compatibles para cobertura.

Preguntas frecuentes

¿El RPC público de Polygon es gratuito?

Los endpoints públicos generalmente están abiertos para desarrollo y uso ligero sin una clave API. Son compartidos, por lo que no son apropiados para tráfico de producción o cargas de trabajo que necesitan capacidad consistente.

¿Cuál es el ID de cadena de Polygon mainnet?

Polygon PoS mainnet usa el ID de cadena 137. La testnet Polygon Amoy usa el ID de cadena 80002. Siempre confirma el ID de cadena con eth_chainId antes de enviar transacciones.

¿Por qué mi solicitud RPC de Polygon devuelve HTTP 429?

Un 429 significa que el endpoint está limitando la velocidad de tus solicitudes. En un endpoint público compartido esto sucede bajo carga. Reduce la frecuencia de solicitudes, agrupa lecturas o pasa a un endpoint gestionado con capacidad para tu tráfico.

¿Puedo usar el RPC público para eth_getLogs?

Los rangos pequeños de bloques suelen funcionar. Los rangos amplios para indexación o rellenos comúnmente se limitan o agotan el tiempo de espera. Usa un endpoint gestionado o dedicado con acceso a archive para cargas de trabajo con muchos registros.

¿El endpoint público admite suscripciones WebSocket?

Existe soporte de transporte, pero las suscripciones compartidas pueden desconectarse bajo carga. Si dependes de eth_subscribe, implementa lógica de reconexión y considera un endpoint dedicado para estabilidad.

¿Cuándo debo cambiar a un nodo Polygon dedicado?

Cambia cuando necesites rendimiento predecible, recursos aislados, acceso a archive o trace, o visibilidad por clave de los fallos. Los nodos dedicados eliminan la variable de capacidad compartida de tu ecuación de confiabilidad.

¿Cómo cambio el endpoint RPC en mi aplicación?

Mantén la URL en una variable de entorno y pásala a tu transporte HTTP. De esa manera puedes pasar de público a gestionado o dedicado sin tocar el código de la aplicación.