¿Qué debo saber sobre la red peaq?

Cuándo necesitas un endpoint RPC de peaq (y cuándo no)

La mayoría de los desarrolladores que buscan la red peaq se dividen en tres grupos: están evaluando peaq como capa de liquidación para un proyecto DePIN, ya tienen un contrato o pallet desplegado y necesitan una forma confiable de leer y escribir el estado de la cadena, o están conectando una billetera o indexador y se topan con problemas de conexión. La decisión que importa no es si peaq soporta RPC — lo hace, a través de una interfaz JSON-RPC basada en Substrate — sino cómo accederás a esa interfaz en producción.

Si estás prototipando, un endpoint público suele ser suficiente para desplegar un contrato, consultar saldos y probar extrinsics. Si ejecutas un servicio backend, un indexador o una flota de dispositivos que envía transacciones continuamente, querrás un proveedor de RPC gestionado o un nodo dedicado. La disyuntiva es operativa: un endpoint público es gratuito pero compartido y con límite de tasa, un endpoint gestionado es de pago pero monitoreado y con soporte, y un nodo dedicado te da capacidad aislada a costa de ejecutar la infraestructura tú mismo o pagar a un proveedor para que lo haga por ti.

Este artículo explica qué es peaq, cómo funciona su interfaz RPC, cómo conectarse y cómo decidir entre acceso público, gestionado y dedicado. No asume que ya conoces las herramientas de Substrate.

Qué es realmente la red peaq

peaq es una blockchain de Capa 1 diseñada para Redes de Infraestructura Física Descentralizada — redes de máquinas, sensores, vehículos y robots que necesitan identificarse, transaccionar y ser recompensados sin un operador central. Mientras que una cadena de propósito general trata a los dispositivos como cuentas ordinarias, peaq incorpora primitivas enfocadas en máquinas en la capa de protocolo.

Las primitivas más relevantes para los desarrolladores son:

• Identidad de máquina autosoberana. Los dispositivos pueden tener un identificador descentralizado (DID) y probar propiedad o control sin un registro centralizado.
• NFT de máquinas y activos tokenizados. Los activos físicos pueden representarse on-chain para poder financiarse, arrendarse o compartirse.
• Flujos de transacción autónomos. Las máquinas pueden pagarse entre sí por datos, energía o cómputo usando el token nativo de la red.
• Runtime basado en Substrate. peaq está construido con Substrate, lo que significa que expone la superficie JSON-RPC estándar de Substrate junto con herramientas compatibles con EVM donde sea compatible.

Debido a que peaq está basado en Substrate, la interfaz RPC no es idéntica a la de un nodo Ethereum. Verás métodos como chain_getHeader, state_getStorage y author_submitExtrinsic en lugar de solo eth_getBlockByNumber. Si tu aplicación asume un RPC con forma de Ethereum, verifica a qué capa de compatibilidad apuntas antes de escribir el código de integración.

Configuración de la cadena de un vistazo

Antes de conectarte, confirma los parámetros de red para el entorno al que apuntas. peaq tiene tanto mainnet como testnet (agung), y mezclarlos es una de las fuentes más comunes de errores confusos.

Si no estás seguro de qué entorno necesitas, comienza en la testnet. Despliega, prueba tu flujo de extrinsics y solo pasa a mainnet una vez que tu integración sea estable. OnFinality incluye peaq entre sus redes RPC compatibles, y la página de la red peaq es el lugar canónico para confirmar los detalles actuales del endpoint.

Conexión a peaq: configuración y código

Las herramientas de Substrate normalmente se conectan a través de Polkadot.js, bibliotecas RPC de Substrate o un endpoint WebSocket. El patrón a continuación muestra una conexión mínima y una consulta de saldo usando Polkadot.js. Reemplaza el marcador de posición del endpoint con el endpoint de tu proveedor o la página de la red peaq.

import { ApiPromise, WsProvider } from '@polkadot/api';

// Use the WebSocket endpoint issued by your RPC provider.
const provider = new WsProvider('wss://<your-peaq-endpoint>');
const api = await ApiPromise.create({ provider });

const [chain, nodeName, nodeVersion] = await Promise.all([
  api.rpc.system.chain(),
  api.rpc.system.name(),
  api.rpc.system.version(),
]);

console.log(`Connected to ${chain} via ${nodeName} v${nodeVersion}`);

// Query the balance of an SS58 address.
const { data: { free } } = await api.query.system.account('<SS58_ADDRESS>');
console.log(`Free balance: ${free.toHuman()}`);

Para una verificación rápida de conectividad sin instalar dependencias, una solicitud curl contra el endpoint HTTP confirma que el nodo es accesible y responde:

curl -sS -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_chain","params":[]}' \
  https://<your-peaq-endpoint>

Una respuesta saludable devuelve el nombre de la cadena. Si obtienes un error de conexión, el endpoint es incorrecto o inaccesible; si obtienes un error JSON-RPC, el método no es compatible con ese nodo. Esa distinción ahorra tiempo al depurar.

Lista de verificación para producción

Pasar de un prototipo en testnet a una carga de trabajo DePIN en vivo cambia lo que necesitas de un endpoint. Revisa esta lista antes de lanzar:

1. Separa las rutas de lectura y escritura. Los indexadores y paneles no deberían competir con el envío de transacciones por el mismo presupuesto de conexión.
2. Usa WebSocket para eventos. Los cambios de estado de dispositivos y las confirmaciones de extrinsics son más fáciles de rastrear mediante suscripciones que mediante polling.
3. Planifica reconexiones. Las conexiones WebSocket de larga duración se caen. Tu cliente debe reconectarse y volver a suscribirse automáticamente.
4. Monitorea la altura de bloque. Una métrica de altura de bloque estancada es la señal más rápida de que tu endpoint se ha quedado atrás.
5. Mantén un endpoint de respaldo. Si tu proveedor principal tiene un incidente, un segundo endpoint evita una caída total.
6. Confirma necesidades de archivo. Si consultas estado histórico, verifica que el endpoint sirva datos de archivo y no solo bloques recientes.
7. Prueba con carga realista. Una flota de dispositivos enviando transacciones se comporta de manera diferente a un único script de prueba.

Si alguno de estos puntos es difícil de satisfacer con un endpoint público, esa es la señal para pasar a infraestructura gestionada o dedicada. Las opciones de servicio API RPC y nodo dedicado de OnFinality están diseñadas exactamente para esta transición.

Acceso público, gestionado y dedicado comparados

No hay una única forma correcta de acceder a peaq. La elección correcta depende de cuánto control y confiabilidad necesitas frente a cuánto trabajo operativo quieres absorber.

OnFinality aparece primero aquí porque es la opción que opera este sitio; la comparación pretende ser factual y no promocional. La pregunta clave no es qué fila es "mejor" sino qué fila coincide con tu carga de trabajo. Un proyecto de hackathon y una flota de 10,000 dispositivos tienen requisitos muy diferentes.

Dónde suelen fallar las integraciones con peaq

La mayoría de los problemas de RPC con peaq no son exóticos. Se agrupan en unas pocas causas recurrentes:

• Red incorrecta. Una dirección de mainnet consultada contra un endpoint de testnet devuelve un saldo vacío, lo que parece un error pero es un error de configuración.
• HTTP usado para suscripciones. Las suscripciones de Substrate requieren WebSocket. Si tu listener de eventos nunca se dispara, revisa primero el transporte.
• Desajuste de formato de dirección. Las direcciones SS58 y de estilo EVM no son intercambiables. Valida el formato antes de enviar.
• Límite de tasa en endpoints compartidos. Las cargas de trabajo en ráfaga contra un endpoint público se limitan, lo que se manifiesta como timeouts intermitentes.
• Nodos obsoletos o sin archivo. Las consultas históricas contra un nodo podado fallan aunque las consultas recientes tengan éxito.
• Reconexiones no gestionadas. Un WebSocket caído que nunca se restablece hace que un servicio saludable parezca muerto.

Un hábito útil de depuración es aislar la capa. Ejecuta la verificación curl anterior contra tu endpoint. Si tiene éxito, el problema está en tu cliente o tu solicitud. Si falla, el problema es el endpoint o la red. Esa única prueba elimina la mitad de las causas posibles.

Elegir un proveedor de RPC para peaq

Si decides usar un proveedor gestionado, evalúa a los candidatos según los criterios que realmente afectan una carga de trabajo DePIN en lugar de las cifras llamativas.

• Soporte de transporte. Confirma que tanto HTTP como WebSocket estén disponibles, ya que las suscripciones son centrales para el seguimiento del estado de los dispositivos.
• Disponibilidad de archivo. Si necesitas estado histórico, pregúntalo explícitamente. No todos los proveedores sirven datos de archivo.
• Cobertura de métodos. Verifica que los métodos de Substrate de los que dependes estén expuestos, especialmente cualquier método de runtime personalizado.
• Conmutación por error y redundancia. Pregunta cómo maneja el proveedor los fallos de nodo y si puedes configurar un respaldo.
• Observabilidad. Quieres métricas sobre las que puedas alertar, no solo una página de estado.
• Modelo de soporte. Para DePIN en producción, un canal de soporte con expectativas de respuesta reales importa más que una pequeña diferencia de precio.

Para un marco más amplio, consulta cómo elegir un proveedor de RPC. Para planificación de costos, revisa precios de RPC y ajusta el nivel del plan a tu volumen esperado de solicitudes y suscripciones.

Puntos clave

• peaq es una Capa 1 basada en Substrate construida para DePIN y economías de máquinas, con identidad de máquina, activos tokenizados y primitivas de transacción autónoma.
• Su interfaz RPC tiene forma de Substrate, por lo que las suposiciones solo de Ethereum no se transferirán limpiamente.
• Usa WebSocket para suscripciones, HTTP para solicitud/respuesta, y confirma siempre si estás en mainnet o en la testnet agung.
• Los endpoints públicos sirven para prototipar; el RPC gestionado y los nodos dedicados sirven para cargas de trabajo en producción que necesitan monitoreo, soporte y aislamiento.
• La mayoría de los fallos de integración provienen de red incorrecta, transporte incorrecto, desajuste de formato de dirección o límite de tasa — todos diagnosticables con una única verificación de conectividad.
• OnFinality ofrece API RPC de peaq e infraestructura de nodo dedicado; comienza desde la página de la red peaq y redes compatibles.

Preguntas frecuentes

¿peaq es compatible con EVM? peaq está basado en Substrate y expone métodos JSON-RPC de Substrate. La compatibilidad con EVM depende del runtime específico y la capa de herramientas a la que apuntes, así que confirma el conjunto de métodos que tu aplicación necesita contra el endpoint que planeas usar antes de construir.

¿Necesito un nodo dedicado para construir sobre peaq? No. Para prototipado y pruebas de bajo volumen, un endpoint público o gestionado es suficiente. Los nodos dedicados tienen sentido cuando necesitas capacidad aislada, rendimiento predecible o un control más estricto sobre el entorno del nodo.

¿Por qué mi suscripción a peaq nunca se dispara? La causa más común es usar un endpoint HTTP donde se requiere un endpoint WebSocket. Las suscripciones de Substrate necesitan una conexión WebSocket persistente, y los clientes deben reconectarse y volver a suscribirse si la conexión se cae.

¿Cómo sé si estoy en mainnet o testnet? Consulta el nombre de la cadena con system_chain y compáralo con la red que pretendías usar. peaq mainnet y la testnet agung son redes separadas con tokens y estado separados.

¿Puedo usar OnFinality para peaq? Sí. OnFinality proporciona acceso gestionado a la API RPC e infraestructura de nodo dedicado para peaq. Consulta la página de la red peaq para detalles actuales del endpoint y precios de RPC para opciones de planes.