Resumen
Alchemy RPC es un servicio JSON-RPC alojado que conecta tu aplicación a nodos de blockchain sin que tengas que ejecutar los nodos tú mismo. Creas una aplicación en el panel de Alchemy, recibes un endpoint HTTPS (y a menudo un endpoint WebSocket) asociado a una red, y luego envías llamadas JSON-RPC estándar como eth_call, eth_getLogs o eth_sendRawTransaction a esa URL. Alchemy también añade características de producto sobre el RPC básico, incluidas API mejoradas, webhooks y herramientas de cuenta.
La mayoría de los desarrolladores que buscan "Alchemy RPC" intentan responder a una de tres preguntas prácticas: cómo obtengo un endpoint y lo llamo, qué límites o características incluye el servicio alojado, y si es el proveedor adecuado para mi carga de trabajo. Esta página responde a esas preguntas en ese orden y luego te ofrece una lista de verificación de evaluación que puedes aplicar a Alchemy o a cualquier otro proveedor de RPC, incluidos el servicio RPC API y los nodos dedicados de OnFinality.
Una advertencia inicial: los niveles de precios, los límites de velocidad y las redes compatibles cambian con frecuencia. Trata cualquier cifra que veas en blogs de terceros como un punto de partida y confirma los detalles actuales en las páginas de precios y documentación del propio proveedor antes de comprometerte.
Puntos clave
- Alchemy RPC es una puerta de enlace JSON-RPC alojada: obtienes una URL por aplicación y por red y llamas a métodos estándar de estilo Ethereum contra ella.
- La URL del endpoint es el punto de integración, por lo que cambiar de proveedor suele ser un cambio de configuración en lugar de una reescritura de código, si mantienes la URL en un solo lugar.
- Evalúa cualquier proveedor de RPC por la cobertura de métodos (archivo, trace, logs), el soporte de transporte (HTTPS vs WebSocket), los límites de rendimiento y cómo se exponen los fallos.
- El RPC alojado es la forma más rápida de empezar; los nodos dedicados tienen sentido cuando necesitas capacidad predecible o aislamiento de vecinos ruidosos.
- OnFinality ofrece una API RPC e infraestructura de nodos dedicados en muchas redes, para que puedas compararla con Alchemy usando los mismos criterios.
- Confirma siempre los precios actuales, los límites de velocidad y el soporte de redes en las páginas del propio proveedor antes de comprometerte.
Cómo encaja realmente un endpoint RPC de Alchemy en tu aplicación
Un endpoint RPC es simplemente una URL HTTP (o WebSocket) que acepta cargas útiles JSON-RPC. En una configuración de Alchemy, te registras, creas una aplicación, eliges una red y Alchemy emite una URL que incluye tu clave API. Tu aplicación luego envía solicitudes como eth_blockNumber o eth_getBalance a esa URL. El proveedor se encarga de la operación de los nodos, la sincronización y el enrutamiento entre bastidores.
Eso significa que la superficie de integración es pequeña. La mayoría de las bibliotecas —ethers, viem, web3.js o una llamada fetch sin procesar— toman una URL y un ID de cadena y hacen el resto. La consecuencia práctica es que la elección de proveedor es principalmente una decisión de configuración, no de arquitectura, siempre que mantengas el endpoint en un solo lugar.
- Endpoint HTTPS: se utiliza para llamadas de solicitud/respuesta como lecturas, estimación de gas y envío de transacciones.
- Endpoint WebSocket: se utiliza para suscripciones como nuevos bloques, transacciones pendientes o logs.
- Clave API: incrustada en la URL o enviada como encabezado; trátala como un secreto y mantenla fuera de los paquetes del lado del cliente cuando sea posible.
- Selección de red: cada aplicación normalmente está asociada a una red, por lo que las aplicaciones multicadena tienen varios endpoints.
Recomendación rápida: cuándo Alchemy RPC es una opción predeterminada razonable
Si estás creando un prototipo, ejecutando un proyecto de hackathon o lanzando una dApp pequeña en una cadena EVM importante, un proveedor de RPC alojado como Alchemy suele ser el camino más rápido. Obtienes un endpoint en minutos, documentación para métodos comunes y un panel para claves y uso.
La decisión se vuelve más interesante una vez que tienes tráfico de producción. En ese momento la pregunta no es "¿funciona?" sino "¿se comporta de manera predecible bajo mi carga de trabajo?". Usa la lista de verificación a continuación para decidir si quedarte en un nivel compartido alojado, subir dentro del mismo proveedor o evaluar alternativas como el RPC gestionado y los nodos dedicados de OnFinality.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Prototipo o dApp pequeña | Límites del nivel gratuito, redes compatibles, calidad de la documentación | El RPC alojado elimina las operaciones de nodos de tu ruta crítica mientras validas el producto |
| Tráfico de lectura en producción | Límites de rendimiento, opciones de caché, comportamiento multirregión | Las aplicaciones con muchas lecturas pueden alcanzar los límites compartidos durante picos de tráfico |
| Consultas de archivo o trace | Si los datos de archivo y los métodos trace/debug están incluidos en tu plan | Los saldos históricos y el trazado de transacciones a menudo requieren nodos de archivo y con frecuencia están restringidos |
| Características en tiempo real | Soporte de suscripciones WebSocket y límites de conexión | Los paneles en vivo y los bots dependen de suscripciones estables, no de sondeos |
| Capacidad predecible | Opciones de nodos dedicados y aislamiento de otros clientes | Los efectos de vecino ruidoso son la causa habitual de latencia inexplicable en niveles compartidos |
Una llamada mínima contra un endpoint de estilo Alchemy
La forma de la solicitud es JSON-RPC estándar, por lo que el mismo código funciona contra cualquier proveedor compatible una vez que cambias la URL. El ejemplo a continuación usa una URL de marcador de posición; reemplázala con el endpoint del panel de tu proveedor.
curl -X POST "$RPC_URL" -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'- En viem:
createPublicClient({ transport: http(process.env.RPC_URL) })luegoclient.getBlockNumber(). - En ethers:
new JsonRpcProvider(process.env.RPC_URL)luegoprovider.getBlockNumber(). - Mantén RPC_URL en una variable de entorno para que cambiar de proveedor sea un cambio de una línea.
Dónde suelen marcar la línea los planes de RPC alojado
La mayoría de los proveedores de RPC alojado, incluido Alchemy, estructuran los planes en torno a unidades de cómputo o recuentos de solicitudes, con ponderación a nivel de método. Los métodos baratos como eth_blockNumber cuestan poco; los caros como eth_getLogs sobre rangos de bloques amplios o llamadas de trace cuestan más. Entender esa ponderación importa más que el límite de solicitudes anunciado.
El otro límite común es el alcance de los datos. Los datos de archivo, las API de debug/trace y las consultas de logs grandes a menudo están restringidos a niveles superiores o requieren habilitación explícita. Si tu aplicación depende del estado histórico o del trazado de transacciones, confirma que esos métodos estén disponibles en tu plan antes de construir sobre ellos.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Método | Perfil de coste típico | La facturación ponderada significa que unas pocas llamadas pesadas pueden dominar tu uso |
| eth_blockNumber / eth_chainId | Peso bajo, normalmente incluido en todas partes | Las comprobaciones de estado y las lecturas simples rara vez son el cuello de botella |
| eth_getLogs | Límites de rango y ponderación por intervalo de bloques | Los indexadores y trabajos de análisis pueden agotar las cuotas rápidamente |
| debug_traceTransaction | Disponibilidad por plan y red | El trazado es caro y a menudo está restringido a niveles superiores |
| eth_getBalance (bloque histórico) | Requisito de nodo de archivo | Los nodos que no son de archivo no pueden responder a consultas de estado histórico |
Lista de verificación de preparación para producción antes de comprometerte
Usa esta lista para comparar Alchemy con cualquier alternativa en igualdad de condiciones. Es deliberadamente neutral respecto al proveedor para que puedas aplicarla también al RPC API o a los nodos dedicados de OnFinality.
- Cobertura de métodos: confirma el soporte de consultas de archivo, trace y logs en tus redes objetivo.
- Transporte: verifica la disponibilidad de WebSocket y los límites de conexión si necesitas suscripciones.
- Comportamiento ante fallos: conoce qué devuelve un endpoint sobrecargado (HTTP 429, error JSON-RPC o tiempo de espera) y cómo reintenta tu cliente.
- Observabilidad: comprueba si el panel expone el uso por método y las tasas de error.
- Conmutación por error: decide si necesitas un proveedor secundario o un nodo dedicado como respaldo.
- Coste de salida: mantén el endpoint en la configuración para que la migración sea un cambio de URL, no una refactorización.
Cuándo pasar de RPC compartido a infraestructura dedicada
El RPC alojado compartido es eficiente porque muchos clientes comparten un grupo de nodos. Eso está bien hasta que tu carga de trabajo se vuelve sensible al tráfico de otros clientes o necesitas garantías que un grupo compartido no puede darte. Las señales de que es hora de considerar nodos dedicados incluyen un volumen de solicitudes alto y sostenido, requisitos estrictos de latencia para trading o UX en tiempo real, y la necesidad de capacidad aislada durante lanzamientos.
OnFinality ofrece tanto endpoints RPC gestionados como infraestructura de nodos dedicados, para que puedas empezar con endpoints compartidos y mover cargas de trabajo específicas a nodos dedicados sin cambiar el código de tu aplicación. Revisa los precios de RPC y las redes compatibles para ver qué se adapta a tu stack.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Señal | RPC compartido | Nodo dedicado |
| Patrón de tráfico | Volumen constante y moderado | Volumen alto y explosivo o sostenido con necesidades de capacidad predecible |
| Sensibilidad a la latencia | La UX general tolera variaciones ocasionales | Trading, liquidaciones o paneles en tiempo real necesitan tiempos de respuesta estables |
| Aislamiento | Es aceptable compartir grupos de nodos | La carga de trabajo no debe verse afectada por otros clientes |
| Modelo de coste | Pago por solicitud o unidad de cómputo | El coste fijo de infraestructura puede ser más fácil de pronosticar a escala |
Puntos de control de migración si cambias de proveedor
Dado que la superficie de integración es una URL, cambiar de proveedor de RPC suele ser sencillo. El riesgo está en los detalles: diferencias de métodos, formatos de error y comportamiento de las suscripciones. Repasa estos puntos de control antes de hacer el cambio.
- Inventaría cada método RPC que llama tu aplicación, incluidos los trabajos en segundo plano y los indexadores.
- Prueba el nuevo endpoint con tus consultas más pesadas, especialmente los rangos de
eth_getLogsy las llamadas de trace. - Confirma el comportamiento de las suscripciones WebSocket y la lógica de reconexión ante conexiones caídas.
- Compara las respuestas de error para limitación de velocidad y parámetros inválidos para que tu lógica de reintento siga funcionando.
- Ejecuta ambos endpoints en paralelo durante un período y compara los resultados en los mismos bloques.
- Mantén el endpoint antiguo configurado como respaldo hasta que el nuevo haya demostrado ser estable en producción.
Preguntas frecuentes
¿Alchemy RPC es gratuito?
Alchemy ofrece un nivel gratuito con límites de uso y planes de pago para mayor volumen y características adicionales. Los límites y precios exactos cambian con el tiempo, así que consulta la página de precios actual de Alchemy antes de planificar en torno a un nivel específico.
¿Cuál es la diferencia entre Alchemy RPC y ejecutar mi propio nodo?
Un servicio RPC alojado como Alchemy opera los nodos, la sincronización y la disponibilidad por ti, y pagas por uso o plan. Ejecutar tu propio nodo te da control total y aislamiento, pero requiere trabajo continuo de operaciones, almacenamiento y monitoreo.
¿Puedo usar Alchemy RPC con ethers o viem?
Sí. Los endpoints de Alchemy hablan JSON-RPC estándar, por lo que cualquier biblioteca que acepte una URL de RPC funciona. Pasas la URL del endpoint y el ID de cadena al constructor de proveedor o transporte de la biblioteca.
¿Alchemy RPC admite suscripciones WebSocket?
Alchemy proporciona endpoints WebSocket para las redes compatibles, que se utilizan para suscripciones como nuevos encabezados o logs. La disponibilidad y los límites dependen de tu plan y red, así que confírmalo en el panel.
¿Cómo se compara OnFinality con Alchemy para RPC?
Ambos proporcionan acceso JSON-RPC alojado. OnFinality también ofrece infraestructura de nodos dedicados en las redes compatibles, lo que es útil cuando necesitas capacidad aislada. Compáralos por cobertura de métodos, soporte de transporte, límites y precios para tu carga de trabajo específica.
¿Cómo cambio de Alchemy a otro proveedor de RPC?
Mantén tu URL de RPC en una variable de entorno, apúntala al endpoint del nuevo proveedor y prueba tus métodos más pesados antes de hacer el cambio. Ejecuta ambos endpoints en paralelo brevemente para detectar diferencias de métodos o formatos de error.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
