Logo
Nuevos usuarios de RPC: 35% de descuento el primer mesVer oferta
OnFinality Learn
Guías de Red y Protocolo12 min de lectura

Polygon WebSocket RPC: Endpoints WSS, eth_subscribe y Reconexión

Aprende a conectarte a los endpoints WebSocket RPC de Polygon PoS, suscribirte a newHeads y logs, manejar reconexiones y evitar errores comunes.

TL;DR

Esta guía explica cómo usar Polygon WebSocket RPC para datos en tiempo real en Polygon PoS, cubriendo endpoints WSS, métodos eth_subscribe, ciclo de vida de la conexión y un ejemplo ejecutable en Node.js con lógica de reconexión.

Respuesta directa: Lo que necesitas saber sobre Polygon WebSocket RPC

Polygon WebSocket RPC (WSS) te permite recibir eventos de blockchain en tiempo real de la red Polygon PoS. El endpoint WSS principal para la red principal de Polygon es wss://polygon-bor-rpc.publicnode.com, y para la testnet Amoy es wss://polygon-amoy-bor-rpc.publicnode.com. También puedes usar endpoints específicos de proveedores como OnFinality, Ankr o Dwellir. Con eth_subscribe, puedes escuchar nuevos bloques, transacciones pendientes y logs que coincidan con filtros específicos. Esta guía cubre los mecanismos, un ejemplo ejecutable y la solución de problemas comunes de desconexión.

Importante: Este artículo trata sobre la blockchain de Polygon (MATIC/POL). No se trata de polygon.io, un proveedor separado de datos del mercado de valores. Si buscas datos de mercados financieros, ese es un servicio diferente.

  • WSS Mainnet: wss://polygon-bor-rpc.publicnode.com
  • WSS Testnet (Amoy): wss://polygon-amoy-bor-rpc.publicnode.com
  • Métodos: eth_subscribe con newHeads, logs, newPendingTransactions, syncing

Arquitectura de Polygon: Bor y Heimdall

Polygon PoS utiliza una arquitectura de dos capas: Bor (la capa de producción de bloques, compatible con EVM) y Heimdall (la capa de validadores, basada en Tendermint). Bor produce bloques a un ritmo rápido (aproximadamente 2 segundos), mientras que Heimdall periódicamente hace checkpoint de estos bloques hacia Ethereum. Esto significa que cuando te suscribes a newHeads en un endpoint WSS de Polygon, recibirás una notificación por cada bloque de Bor, pero los datos pueden no ser finales hasta que se confirme un checkpoint de Heimdall. Para la mayoría de los casos de uso, esto es suficiente, pero ten en cuenta posibles reorganizaciones en Bor.

El tiempo de bloque en Polygon PoS es de alrededor de 2 segundos, por lo que puedes esperar un alto volumen de notificaciones newHeads. Esto es importante para la limitación de velocidad y la estabilidad de la conexión.

  • Bor: produce bloques cada ~2 segundos
  • Heimdall: hace checkpoint de bloques hacia Ethereum, proporcionando finalidad
  • Frescura de datos: newHeads es en tiempo real pero no final hasta el checkpoint

Endpoints WSS para Polygon Mainnet y Testnet

Puedes usar endpoints públicos o de proveedores. Los endpoints públicos son gratuitos pero a menudo tienen límites de velocidad y pueden cerrar conexiones inactivas. Los endpoints de proveedores (como OnFinality) ofrecen mayor fiabilidad y soporte dedicado. Siempre consulta la documentación más reciente para obtener URLs actualizadas.

Aquí hay algunos endpoints WSS de uso común (documentados por los respectivos proveedores):

  • PublicNode: wss://polygon-bor-rpc.publicnode.com (mainnet), wss://polygon-amoy-bor-rpc.publicnode.com (testnet Amoy)
  • Ankr: wss://rpc.ankr.com/polygon (mainnet), wss://rpc.ankr.com/polygon_amoy (testnet)
  • Dwellir: wss://polygon-rpc.dwellir.com (mainnet)
  • OnFinality: disponible con tu clave API, consulta servicio API

eth_subscribe: Métodos y cargas útiles

El método eth_subscribe te permite suscribirte a eventos en tiempo real. Las suscripciones estándar son:

newHeads: Notifica nuevos encabezados de bloque. La carga útil incluye el número de bloque, hash, hash padre, timestamp y otros campos del encabezado.

logs: Notifica logs que coinciden con un filtro (dirección y topics). Esto es útil para rastrear eventos de contratos.

newPendingTransactions: Notifica hashes de transacciones que entran en el pool de transacciones. Ten en cuenta que esto puede ser de alto volumen y puede no ser soportado por todos los proveedores.

syncing: Notifica cuando el nodo comienza o deja de sincronizar. Raramente usado.

  • Formato de solicitud: {"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["newHeads"]}
  • Respuesta: {"jsonrpc":"2.0","id":1,"result":"0x9cef..."} (ID de suscripción)
  • Notificación: {"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0x9cef...","result":{...}}}
// Ejemplo de solicitud de suscripción para logs
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_subscribe",
  "params": ["logs", {"address": "0x...", "topics": ["0x..."]}]
}

Conexión con ethers.js y web3.js

Puedes usar ethers.js o web3.js para conectarte a un endpoint WSS. Con ethers.js, usa new ethers.WebSocketProvider(url). Con web3.js, usa new Web3.providers.WebsocketProvider(url). Ambos soportan eth_subscribe a través del método on del proveedor.

A continuación se muestra un ejemplo ejecutable en Node.js usando ethers.js que se conecta a la red principal de Polygon, se suscribe a newHeads y logs, e incluye un bucle de reconexión con resuscripción.

const { ethers } = require('ethers');

const WSS_URL = 'wss://polygon-bor-rpc.publicnode.com';
let provider;
let subscriptionIds = [];

async function connect() {
  console.log('Conectando a Polygon WSS...');
  provider = new ethers.WebSocketProvider(WSS_URL);

  provider.on('error', (error) => {
    console.error('Error de WebSocket:', error);
    reconnect();
  });

  provider.on('close', () => {
    console.log('WebSocket cerrado. Reconectando...');
    reconnect();
  });

  // Suscribirse a newHeads
  const headSub = await provider.send('eth_subscribe', ['newHeads']);
  subscriptionIds.push(headSub);
  provider.on('newHeads', (head) => {
    console.log('Nuevo bloque:', head.number);
  });

  // Suscribirse a logs (ejemplo: eventos de transferencia USDT)
  const logSub = await provider.send('eth_subscribe', ['logs', {
    address: '0xc2132D05D31c914a87C6611C10748AEb04B58e8F', // USDT en Polygon
    topics: [ethers.id('Transfer(address,address,uint256)')]
  }]);
  subscriptionIds.push(logSub);
  provider.on('logs', (log) => {
    console.log('Log:', log.transactionHash);
  });

  console.log('Suscripciones activas:', subscriptionIds);
}

function reconnect() {
  if (provider) {
    provider.removeAllListeners();
    provider.destroy();
  }
  setTimeout(connect, 5000); // esperar 5 segundos antes de reconectar
}

connect();

// Salida esperada: registros de nuevos números de bloque y hashes de transacción
// El script seguirá ejecutándose y se reconectará en caso de desconexión.

Estrategias de reconexión y resuscripción

Los endpoints WSS públicos a menudo cierran conexiones inactivas después de un tiempo de espera (por ejemplo, 60 segundos) o cuando el cliente excede los límites de velocidad. Para mantener un flujo confiable, debes implementar un heartbeat y lógica de reconexión. El ejemplo anterior se reconecta al cerrarse, pero también debes enviar un ping periódicamente para mantener la conexión viva. Muchas bibliotecas lo hacen automáticamente, pero también puedes usar un temporizador para enviar eth_subscribe nuevamente si no has recibido notificaciones dentro de un intervalo determinado.

Al reconectar, debes volver a suscribirte a todas las suscripciones porque los IDs de suscripción anteriores son inválidos. Además, prepárate para manejar notificaciones duplicadas: si te reconectas y vuelves a suscribirte, podrías recibir el mismo bloque o log dos veces. Usa procesamiento idempotente (por ejemplo, rastrear números de bloque o hashes de transacción ya vistos) para evitar doble conteo.

  • Heartbeat: enviar un ping cada 30-60 segundos (por ejemplo, provider.send('eth_subscribe', ['newHeads']) como keepalive, o usar un ping de WebSocket)
  • Resuscripción: al reconectar, re-emitir todas las suscripciones
  • Manejo de duplicados: mantener un conjunto de números de bloque o hashes de log vistos
  • Backoff: usar backoff exponencial para los intentos de reconexión para evitar abrumar al servidor

Fallos comunes y solución de problemas

Aquí hay problemas comunes que podrías encontrar y cómo solucionarlos.

Códigos de exceso de suscripción: Algunos proveedores devuelven códigos de error como -32005 (límite excedido) cuando tienes demasiadas suscripciones. Reduce el número de suscripciones o usa un solo filtro con múltiples direcciones/topics.

Límites de conexión por IP: Los endpoints públicos a menudo limitan el número de conexiones concurrentes por IP. Si llegas a este límite, usa un proveedor con límites más altos o rota endpoints.

Retraso en la altura del bloque: Si tu nodo está atrasado, podrías recibir datos obsoletos. Verifica el estado de sincronización de tu proveedor y considera usar un endpoint dedicado.

  • Error -32005: Demasiadas suscripciones. Consolida filtros.
  • Límite de conexión: Usa un proveedor con límites más altos o múltiples endpoints.
  • Retraso: Monitorea la altura del bloque y compárala con una referencia (por ejemplo, Polygonscan).
  • Desconexiones por inactividad: Implementa heartbeat y reconexión.
  • Limitación de velocidad: Usa un proveedor con límites más altos o reduce la frecuencia de solicitudes.

Compensaciones y limitaciones

WebSocket RPC es ideal para aplicaciones en tiempo real, pero tiene limitaciones. Los endpoints públicos pueden no soportar newPendingTransactions debido al alto volumen. Además, la suscripción a logs puede ser pesada si te suscribes a un contrato popular como USDT. Usa filtros para reducir los datos.

Para uso de producción de alto rendimiento, considera usar un proveedor dedicado como OnFinality, que ofrece precios de RPC y servicio API con tiempo de actividad garantizado. También ten en cuenta que las conexiones WebSocket son stateful, por lo que debes manejar las reconexiones con elegancia.

Para más sobre soluciones de desconexión, consulta nuestra guía genérica de soluciones de desconexión WebSocket RPC. Para consideraciones de rendimiento, consulta latencia y rendimiento de Polygon RPC.

Próximos pasos y lecturas adicionales

Ahora que entiendes Polygon WebSocket RPC, puedes construir aplicaciones en tiempo real como monitores de transacciones, bots de arbitraje DEX o rastreadores de acuñación de NFT. Para más detalles, consulta la documentación oficial de Polygon en docs.polygon.technology.

Explora más guías en el centro de aprendizaje de OnFinality. Si necesitas ayuda con Polygon RPC, consulta nuestra guía de Polygon RPC (Asistente de RPC). Para información general de la red Polygon, visita página de red Polygon.

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar