Resumen
Elegir un proveedor de RPC de zkSync implica equilibrar fiabilidad, rendimiento y características específicas de zkSync. Esta guía explica qué buscar en un proveedor, compara opciones públicas, compartidas y dedicadas, y te ayuda a decidir cuál se adapta a tu carga de trabajo. Cubrimos configuraciones de cadena, métodos RPC clave y errores comunes a evitar al construir en ZKsync.
Recomendación rápida: adapta el proveedor a tu carga de trabajo
Antes de comparar proveedores, decide qué necesita realmente tu aplicación de un proveedor de RPC de zkSync. Una billetera o un frontend de dApp simple a menudo puede funcionar con un endpoint público. Un bot de trading, indexador o servicio de análisis que emite miles de solicitudes por segundo necesitará un nodo dedicado o un proveedor con límites de tasa generosos y datos de archivo.
Hazte estas preguntas:
- ¿Cuántas solicitudes por segundo esperas? Los endpoints públicos suelen limitar a 10-100 RPS por cliente. Si tu tráfico es ráfagas o sostenido, necesitas un proveedor que pueda escalar.
- ¿Necesitas estado histórico? Los indexadores y herramientas de análisis a menudo requieren
eth_getLogsen rangos grandes o datos de archivo. No todos los proveedores ofrecen nodos de archivo. - ¿Necesitas soporte de WebSocket? Las aplicaciones en tiempo real como libros de órdenes o escuchas de eventos dependen de
eth_subscribe. Verifica que el proveedor soporte WSS y sus límites de suscripción. - ¿Cuál es tu tolerancia al tiempo de inactividad? Si tu aplicación está en producción, un solo endpoint público es arriesgado. Considera un proveedor con múltiples endpoints, conmutación por error o un clúster dedicado.
Para la mayoría de las cargas de trabajo de producción, un proveedor de RPC gestionado como OnFinality ofrece un equilibrio entre fiabilidad y escalabilidad. Obtienes un endpoint estable, acceso a múltiples redes y la opción de actualizar a un nodo dedicado cuando superes la infraestructura compartida. Consulta Precios de RPC y redes compatibles para más detalles.
Conceptos básicos de RPC de zkSync: a qué te estás conectando
ZKsync es una solución de escalado de Capa 2 de Ethereum que utiliza rollups de conocimiento cero (ZK rollups) para aumentar el rendimiento y reducir los costos de transacción. Es compatible con EVM, lo que significa que la mayoría de las herramientas de Ethereum funcionan con cambios mínimos. Sin embargo, ZKsync tiene su propia API JSON-RPC que extiende la API estándar de Ethereum con métodos específicos de L2.
Cuando interactúas con ZKsync, envías solicitudes JSON-RPC a un endpoint. El endpoint puede ser un nodo público, un proveedor compartido o un nodo dedicado que ejecutas tú mismo. El proveedor maneja la infraestructura subyacente del nodo, incluida la sincronización, el almacenamiento y la conectividad de red.
Configuración de cadena de un vistazo
Si estás configurando una billetera o una dApp, necesitas los detalles de cadena correctos. Aquí están las configuraciones oficiales para la red principal y la red de pruebas de ZKsync:
| Red | ID de cadena | Moneda nativa | Explorador | URL de RPC pública |
|---|---|---|---|---|
| ZKsync Mainnet | 324 | ETH | https://explorer.zksync.io | https://zksync.api.onfinality.io/public |
| ZKsync Sepolia | 300 | ETH | https://sepolia.explorer.zksync.io | https://zksync-sepolia.api.onfinality.io/public |
Estas URL son endpoints públicos proporcionados por OnFinality. Para uso en producción, debes obtener una clave de API dedicada para evitar límites de tasa y garantizar la fiabilidad. Consulta la página de red de ZKsync para más detalles.
Qué buscar en un proveedor de RPC de zkSync
No todos los proveedores de RPC son iguales. Aquí están los criterios clave a evaluar al elegir un proveedor para ZKsync:
| Criterio | Qué verificar | Por qué importa |
|---|---|---|
| Fiabilidad | Historial de tiempo de actividad, endpoints redundantes, conmutación por error | El tiempo de inactividad rompe tu aplicación y pierde la confianza del usuario |
| Rendimiento | Límites de tasa (RPS), capacidad de ráfagas, opciones dedicadas | Las aplicaciones de alto tráfico necesitan un rendimiento constante |
| Disponibilidad de datos | Nodos de archivo, soporte de eth_getLogs, datos históricos | Los indexadores y análisis necesitan historial completo |
| Transporte | Soporte de HTTPS y WebSocket | Las aplicaciones en tiempo real necesitan suscripciones WSS |
| Métodos específicos de zkSync | Soporte para zks_getBlockDetails, zks_getTransactionDetails, etc. | Algunas aplicaciones necesitan datos específicos de L2 |
| Precios | Nivel gratuito, pago por uso, precios dedicados | El costo debe escalar con tu uso |
| Soporte | Documentación, SLA, comunidad | Necesitas ayuda cuando algo sale mal |
Público vs. compartido vs. dedicado
- Endpoints públicos son gratuitos y fáciles de usar, pero tienen límites de tasa y no son adecuados para producción. Son buenos para pruebas y proyectos pequeños.
- Proveedores de RPC compartidos ofrecen un endpoint gestionado con límites de tasa más altos y características adicionales como datos de archivo y soporte de WebSocket. Son una buena opción predeterminada para la mayoría de las aplicaciones de producción.
- Nodos dedicados te dan un nodo de un solo inquilino sin recursos compartidos. Ofrecen el mayor rendimiento y fiabilidad, pero a un costo más alto. Son ideales para aplicaciones de alto rendimiento, indexadores y empresas.
OnFinality ofrece opciones tanto compartidas como dedicadas. Puedes comenzar con un endpoint compartido y actualizar a un nodo dedicado a medida que tus necesidades crezcan. Consulta Precios de RPC para más detalles.
Cómo conectarse a ZKsync con un proveedor
Una vez que hayas elegido un proveedor, debes configurar tu aplicación para usar el endpoint. Aquí hay un ejemplo usando ethers.js para conectarse a la red principal de ZKsync:
const { ethers } = require("ethers");
// Reemplaza con el endpoint de tu proveedor
const RPC_URL = "https://zksync.api.onfinality.io/public";
const provider = new ethers.JsonRpcProvider(RPC_URL);
async function getBlockNumber() {
const blockNumber = await provider.getBlockNumber();
console.log("Número de bloque actual:", blockNumber);
}
getBlockNumber();
Para soporte de WebSocket, usa ethers.WebSocketProvider:
const { ethers } = require("ethers");
const WSS_URL = "wss://zksync.api.onfinality.io/public";
const provider = new ethers.WebSocketProvider(WSS_URL);
provider.on("block", (blockNumber) => {
console.log("Nuevo bloque:", blockNumber);
});
Ten en cuenta que el endpoint público puede no soportar WebSocket. Consulta con tu proveedor la URL WSS correcta.
Métodos RPC clave de zkSync que usarás
ZKsync soporta los métodos JSON-RPC estándar de Ethereum, además de algunos específicos de L2. Aquí están los más comunes:
eth_blockNumber– obtener el número de bloque más recienteeth_getBalance– obtener el saldo de una direccióneth_call– ejecutar una llamada de contrato de solo lecturaeth_sendRawTransaction– enviar una transacción firmadaeth_getTransactionReceipt– obtener el recibo de una transaccióneth_getLogs– consultar registros (útil para indexación)zks_getBlockDetails– obtener información detallada sobre un bloque (específico de L2)zks_getTransactionDetails– obtener información detallada sobre una transacción (específico de L2)
Puedes probar estos métodos con una simple solicitud curl:
curl -X POST https://zksync.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
Errores comunes al usar RPC de zkSync
Incluso con un buen proveedor, puedes encontrar problemas. Aquí hay algunos errores comunes y cómo evitarlos:
- Límite de tasa: Los endpoints públicos a menudo limitan las solicitudes por segundo. Si alcanzas el límite, obtendrás errores. Usa un proveedor con límites más altos o implementa lógica de reintento.
- Falta de datos de archivo: Algunos proveedores solo ofrecen nodos completos, que no almacenan el estado histórico. Si necesitas consultar bloques antiguos, necesitas un nodo de archivo.
- Desconexiones de WebSocket: Las conexiones WebSocket pueden caerse. Implementa lógica de reconexión en tu aplicación.
- ID de cadena incorrecto: Asegúrate de usar el ID de cadena correcto (324 para mainnet, 300 para Sepolia). Usar el incorrecto hará que las transacciones fallen.
- Métodos específicos de L2: No todos los proveedores soportan métodos
zks_*. Si los necesitas, verifica que tu proveedor los soporte.
Lista de verificación de preparación para producción
Antes de lanzar tu aplicación, revisa esta lista:
- Elige un proveedor que cumpla con tus necesidades de rendimiento y datos
- Obtén una clave de API dedicada (no el endpoint público)
- Configura monitoreo para tus endpoints RPC
- Implementa lógica de reintento para límites de tasa y errores de red
- Usa WebSocket con reconexión para funciones en tiempo real
- Prueba primero en ZKsync Sepolia
- Ten un proveedor de respaldo en caso de tiempo de inactividad
Conclusiones clave
- ZKsync es un L2 compatible con EVM con su propia API JSON-RPC.
- Elige un proveedor según tu carga de trabajo: público para pruebas, compartido para producción, dedicado para alto rendimiento.
- Verifica datos de archivo, soporte de WebSocket y métodos específicos de zkSync.
- Usa el ID de cadena y el endpoint correctos para mainnet vs. testnet.
- Monitorea tus endpoints y ten un plan de respaldo.
Preguntas frecuentes
¿Cuál es el mejor proveedor de RPC de zkSync?
El mejor proveedor depende de tus necesidades. Para producción, busca un proveedor con alta fiabilidad, buen rendimiento y soporte para métodos específicos de zkSync. OnFinality ofrece opciones tanto compartidas como dedicadas.
¿Puedo usar un endpoint RPC público de zkSync para producción?
Los endpoints públicos tienen límites de tasa y no se recomiendan para producción. Son buenos para pruebas y desarrollo.
¿OnFinality soporta ZKsync?
Sí, OnFinality soporta la red principal de ZKsync y la red de pruebas Sepolia. Consulta la página de red de ZKsync para más detalles.
¿Cuál es el ID de cadena para la red principal de ZKsync?
El ID de cadena es 324.
¿Cómo obtengo un nodo RPC dedicado de zkSync?
Puedes obtener un nodo dedicado de OnFinality. Consulta nodo dedicado para más información.