Respuestas>Más información sobre RPC y API>¿Qué es un RPC ( endpoint)?
¿Qué es un RPC endpoint?
// Tags
RPC endpoint¿Qué es RPC?JSON-RPC
En resumen: un punto final RPC ( endpoint ) es una URL que utiliza tu aplicación para comunicarse con un nodo de la cadena de bloques. RPC son las siglas de «Remote Procedure Call» (llamada a procedimiento remoto), un protocolo que permite a un programa solicitar datos o acciones a otro programa a través de una red. En la cadena de bloques, los puntos finales RPC son el medio por el que las carteras comprueban los saldos, las dapps ejecutan contratos inteligentes y los desarrolladores leen y escriben datos en la cadena. Cada interacción que realizas con la cadena de bloques, te des cuenta o no, pasa por un punto final RPC ( endpoint).
La explicación sencilla
Cuando abres una aplicación de monedero y ves tu saldo de ETH, tu monedero no está «en» la cadena de bloques de ninguna manera. Se trata de una aplicación normal que se ejecuta en tu teléfono o navegador y que necesita consultar a la cadena de bloques cuál es tu saldo. Para hacer esa consulta, envía una solicitud a un RPC endpoint. El endpoint recibe la solicitud, el nodo que hay detrás busca la respuesta y la envía de vuelta. A continuación, tu monedero muestra el resultado.
Piensa en un RPC endpoint como la puerta principal de un restaurante. La cocina (el nodo de la cadena de bloques) es donde se lleva a cabo el trabajo real: verificar transacciones, mantener el estado y generar bloques. Pero no entras directamente en la cocina. Entras por la puerta principal (el RPC endpoint), haces tu pedido (tu solicitud) y un camarero (el protocolo RPC) te sirve la comida (la respuesta). El RPC endpoint es el punto de acceso que pone las capacidades del nodo a disposición del mundo exterior.
En términos técnicos, un RPC endpoint es una URL (como https://your-endpoint.quiknode.pro/your-token/) a la que tu aplicación envía solicitudes HTTP o WebSocket formateadas según la especificación JSON-RPC. JSON-RPC es un protocolo ligero que define cómo estructurar las solicitudes y respuestas como objetos JSON. Todas las principales cadenas de bloques utilizan alguna versión de este estándar, lo que significa que, una vez que comprendas cómo realizar una llamada RPC en Ethereum, el patrón es similar en Solana, Polygon, Arbitrum, Base y en docenas de otras cadenas.
Cómo funcionan las llamadas RPC
Una interacción RPC típica sigue un patrón sencillo de solicitud-respuesta. Tu aplicación crea una solicitud JSON-RPC en la que se especifica el método que deseas llamar y los parámetros que requiere, y luego la envía a la URL endpoint mediante un método POST de HTTP. El nodo procesa la solicitud, ejecuta la lógica correspondiente y devuelve una respuesta JSON con el resultado.
Por ejemplo, para obtener el número del último bloque en una cadena EVM, tu aplicación envía una solicitud con el método «eth_blockNumber» y una matriz de parámetros vacía. El nodo responde con el número de bloque actual en formato hexadecimal. Para comprobar el saldo de ETH de una cuenta, se llama a «eth_getBalance» con la dirección del monedero y un parámetro de bloque (como «latest» para el bloque actual). Para enviar una transacción, se llama a «eth_sendRawTransaction» con los datos de la transacción firmados.
Estos métodos estándar de JSON-RPC vienen definidos por las especificaciones de cada cadena de bloques. La API JSON-RPC de Ethereum incluye métodos para leer datos de bloques, consultar el estado de cuentas y contratos, calcular el gas, enviar transacciones, suscribirse a eventos a través de WebSocket y mucho más. Solana utiliza un conjunto de métodos RPC similar, aunque distinto, optimizado para su arquitectura basada en cuentas. Cada cadena tiene su propia interfaz API, pero el patrón de comunicación subyacente a través de los puntos finales RPC sigue siendo el mismo.
Las conexiones WebSocket son una extensión del patrón RPC básico que permiten la comunicación bidireccional en tiempo real. En lugar de que tu aplicación consulte repetidamente el nodo en busca de actualizaciones (lo cual es ineficaz y lento), una conexión WebSocket permite que el nodo envíe los nuevos datos a tu
la aplicación en tiempo real. Esto es esencial para casos de uso como la supervisión de los nuevos bloques a medida que se generan, la detección de eventos específicos de contratos inteligentes en tiempo real y la recepción de notificaciones de confirmación de transacciones.
Puntos finales de RPC públicos frente a privados
Los puntos finales RPC públicos son URL gratuitas y abiertas que mantienen fundaciones de blockchain o proyectos comunitarios. Cualquiera puede conectarse a ellos sin necesidad de autenticación. Son útiles para pruebas rápidas, la creación de prototipos y con fines educativos, pero no son adecuados para aplicaciones de producción. Los puntos finales públicos tienen una limitación de tasa muy estricta (lo que significa que restringen el número de solicitudes que se pueden enviar por segundo), suelen estar sobrecargados por miles de usuarios simultáneos y no ofrecen garantías en cuanto al tiempo de actividad, la latencia o la actualidad de los datos. Si tu aplicación depende de un endpoint público y este deja de funcionar durante un pico de tráfico, tu aplicación dejará de funcionar con él.
Los puntos finales RPC privados son conexiones dedicadas, normalmente proporcionadas por un servicio de infraestructura, que están reservadas para tu aplicación. Ofrecen tiempos de respuesta más rápidos, límites de tasa más altos, un rendimiento constante y garantías de disponibilidad respaldadas por acuerdos de nivel de servicio (SLA). Los puntos finales privados suelen incluir características adicionales como la autenticación basada en tokens, listas blancas de direcciones IP, paneles de análisis y acceso a API mejoradas que van más allá de la especificación estándar de JSON-RPC.
Para cualquier aplicación que gestione usuarios reales, fondos reales o datos en tiempo real, los puntos de conexión RPC privados son un requisito básico, no una mejora opcional. La diferencia entre un endpoint público y uno privado en entorno de producción es la misma que existe entre una red WiFi pública compartida y una línea de fibra óptica dedicada. Técnicamente, ambas te conectan a Internet, pero solo una de ellas es adecuada para gestionar un negocio.
Más allá del RPC básico
Aunque los métodos estándar de JSON-RPC cubren los aspectos fundamentales de la lectura y la escritura de datos de la cadena de bloques, la mayoría de las aplicaciones en producción necesitan algo más. Las API mejoradas amplían la especificación RPC básica con métodos de nivel superior que agregan datos y reducen el número de llamadas que debe realizar tu aplicación. En lugar de realizar docenas de llamadas individuales para reconstruir los saldos de tokens de un monedero, una API mejorada puede devolver todos los saldos de tokens en una sola solicitud.
Las arquitecturas de streaming y basadas en eventos representan la siguiente evolución más allá del RPC de solicitud-respuesta. En lugar de que tu aplicación consulte constantemente un « endpoint » de RPC en busca de nuevos bloques o eventos, un servicio de streaming envía los datos a tu aplicación a medida que están disponibles. Esto reduce la latencia, elimina las solicitudes innecesarias y simplifica tu arquitectura de backend.
gRPC Es otro protocolo que se utiliza junto con JSON-RPC o en su lugar en determinadas cadenas. Por ejemplo, Solana, Yellowstone ygRPC ofrecen una transmisión de datos con una latencia ultrabaja, optimizada para casos de uso de alta frecuencia, como los bots de trading y el análisis en tiempo real. gRPC utiliza Protocol Buffers en lugar de JSON, ya que son más compactos y se serializan más rápido, lo que lo hace ideal para aplicaciones en las que cada milisegundo de latencia cuenta.
El papel de « Quicknode »
QuicknodeLa API Core de ofrece puntos finales RPC de nivel de producción en más de 80 redes blockchain. Al crear un « endpoint » en Quicknode, obtienes una URL HTTPS y WebSocket que conecta tu aplicación a una infraestructura de nodos de alto rendimiento distribuida a nivel mundial, con un SLA de disponibilidad del 99,99 % y tiempos de respuesta 2,5 veces más rápidos que los de la competencia, de media. Cada endpoint incluye acceso completo a los datos y a los archivos, análisis en tiempo real, autenticación basada en tokens y funciones de seguridad como la lista blanca de referencias y el enmascaramiento de dominios.
Más allá del RPC estándar, Quicknode amplía la experiencia del desarrollador con Streams la entrega de datos de blockchain en tiempo real e históricos, Yellowstone gRPC datos ultrarrápidos de Solana , un ecosistema de complementos de Marketplace para datos de DeFi, API de NFT y herramientas de seguridad, y el Quicknode SDK para una integración optimizada en JavaScript y TypeScript. Tanto si necesitas un único endpoint para un proyecto de fin de semana como una infraestructura multicadena y multirregional para una plataforma empresarial, Quicknode proporciona la capa RPC sobre la que se construye todo lo demás.
¿Cuál es la diferencia entre un RPC endpoint y un nodo?
Los términos están relacionados, pero no son idénticos. Un nodo es el software que mantiene una copia de la cadena de bloques, valida las transacciones y realiza un seguimiento del estado. Un RPC ( endpoint ) es la dirección de red a la que te conectas para comunicarte con ese nodo. Un nodo puede estar detrás de muchos puntos finales, y un endpoint puede enrutar las solicitudes a través de un conjunto de nodos con equilibrio de carga para garantizar la redundancia. Cuando utilizas un proveedor gestionado, interactúas con el endpoint y nunca tienes que gestionar el nodo por tu cuenta. Para conocer más a fondo qué hay detrás de la URL, consulta «¿Qué es un nodo de blockchain?», y para conocer el ciclo de vida completo de una solicitud, consulta «Cómo funcionan las solicitudes RPC».
¿Qué protocolo de transporte RPC deberías utilizar: HTTP, WebSocket o gRPC?
Los puntos finales RPC admiten más de un protocolo de transporte, y la elección adecuada depende de si se realizan consultas puntuales o se consume un flujo continuo de datos. HTTP es el protocolo predeterminado universal para las llamadas de solicitud-respuesta. WebSocket mantiene abierta una conexión persistente para que el nodo pueda enviarte actualizaciones de forma proactiva. gRPC ofrece la menor latencia para cargas de trabajo de alta frecuencia en las cadenas compatibles. La tabla siguiente compara los tres a simple vista.
Transporte
Modelo de conexión
Ideal para
Compensación
HTTP
Solicitud y respuesta sin estado
Lecturas estándar, envío de transacciones, llamadas por lotes
No hay envío automático por parte del servidor, por lo que debes comprobar si hay actualizaciones
WebSocket
Persistente, bidireccional
Suscripciones a nuevos bloques, registros y transacciones pendientes
Las conexiones deben mantenerse activas y volver a establecerse en caso de desconexión.
gRPC
Persistencia y transmisión con Protocol Buffers
Fuentes de datos de latencia ultrabaja, como los bots de negociación y las herramientas de análisis
Configuración más compleja y limitada a las cadenas que la admiten
Si tu aplicación necesita un flujo continuo en lugar de consultas repetidas, una capa de streaming gestionada como Quicknode Streams puede enviar bloques, acuses de recibo y trazas directamente a tu backend sin que tengas que gestionar los ciclos de vida de los sockets.
¿Qué provoca la latencia y la limitación de velocidad en las llamadas RPC endpoint ?
Hay dos factores que suelen determinar la experiencia de uso de un RPC endpoint: la rapidez con la que responde y el número de solicitudes que admite. La latencia depende de la distancia geográfica al nodo, la complejidad del método que se invoca y el nivel de carga de la infraestructura subyacente. Los límites de tasa existen porque cada nodo tiene una capacidad finita, por lo que los proveedores limitan el número de solicitudes por segundo para proteger los recursos compartidos. Comprender ambos aspectos te ayuda a dimensionar correctamente un endpoint antes de que aumente el tráfico. Obtén más información sobre qué es la latencia RPC y qué es la limitación de tasa RPC.
¿Cuándo conviene utilizar la indexación en lugar del RPC sin procesar?
El RPC sin procesar es ideal para leer el estado actual y enviar transacciones, pero tiene dificultades con consultas analíticas como «todas las transferencias que ha realizado esta cartera en el último año». Responder a eso solo con RPC implica miles de llamadas secuenciales. La indexación resuelve este problema mediante el preprocesamiento de los datos de la cadena de bloques en una base de datos consultable, de modo que las búsquedas históricas y agregadas se obtienen en una sola consulta. Compara los dos enfoques en «RPC frente a indexación» y descubre por qué las consultas de gran volumen resultan difíciles a la hora de consultar datos de la cadena de bloques.
Preguntas frecuentes
¿Qué significa RPC?
RPC son las siglas de «Remote Procedure Call» (llamada a procedimiento remoto). Se trata de un protocolo que permite a un programa solicitar datos o activar una acción en otro programa a través de una red, como si estuviera llamando a una función local. En la cadena de bloques, tu aplicación utiliza RPC para pedir a un nodo que lea el estado o envíe una transacción.
¿Es lo mismo un RPC endpoint que una API?
Un RPC ( endpoint ) es un tipo específico de API. Expone la funcionalidad de un nodo de cadena de bloques a través del estándar JSON-RPC en una única URL. Muchos proveedores superponen API REST mejoradas o de nivel superior sobre la interfaz RPC básica, pero el endpoint principal es el que utiliza el protocolo JSON-RPC que el nodo entiende.
¿Es seguro utilizar puntos finales RPC públicos y gratuitos en entornos de producción?
Son adecuados para realizar pruebas y aprender, pero no están pensados para entornos de producción. Los puntos de conexión públicos tienen una limitación de velocidad muy estricta, suelen estar sobrecargados y no ofrecen garantías de disponibilidad ni de latencia. Si un punto de conexión público endpoint se ve afectado durante un pico de tráfico, tu aplicación se verá afectada con él; por eso, las aplicaciones en producción se basan en puntos de conexión privados dedicados.
¿Puede un RPC endpoint conectarse a varias cadenas de bloques?
Una URL de endpoint suele corresponder a una red, como Ethereum ,mainnet o Solana ,mainnet. Para admitir varias cadenas, hay que crear puntos finales independientes, uno por cada red. Dado que la mayoría de las cadenas comparten el patrón JSON-RPC, el código que se escribe para una endpoint suele poder adaptarse a las demás con pequeños cambios.
¿Cómo puedo recibir notificaciones de los eventos en la cadena de bloques sin tener que realizar consultas constantes?
Utiliza un mecanismo basado en notificaciones «push» en lugar de sondeos. Las suscripciones a WebSocket y los servicios basados en eventos, como Quicknode Webhooks avisan a tu backend en el momento en que se produce un bloque o un evento relevante, lo que reduce la latencia y elimina las solicitudes innecesarias. Si buscas tutoriales paso a paso, la «Guía para desarrolladores» explica los patrones más habituales.
