¿Cómo funcionan las solicitudes RPC?

La explicación sencilla

Cuando pulsas «enviar» en una cartera de criptomonedas o compruebas el saldo de tus tokens en una herramienta de seguimiento de carteras, tu aplicación no tiene acceso directo a la cadena de bloques. Tiene que solicitar esa información a un nodo. El lenguaje que utiliza para realizar la solicitud se denomina JSON-RPC, un protocolo ligero que estructura las solicitudes y las respuestas como simples objetos JSON.

Así es como funciona la comunicación. Tu aplicación crea un objeto de solicitud con cuatro campos: la versión de JSON-RPC (siempre «2.0»), un nombre de método que indica al nodo qué operación debe realizar, una matriz de parámetros que proporcionan el contexto para dicha operación y un identificador único para que tu aplicación pueda asociar la respuesta a la solicitud. Envía este objeto mediante un método HTTP POST a la URL RPC endpoint . El nodo recibe la solicitud, busca o calcula la respuesta y devuelve un objeto de respuesta que contiene el mismo identificador y, o bien un campo de resultado (si se ha realizado correctamente), o bien un campo de error (si ha surgido algún problema).

Por ejemplo, para consultar el saldo en ETH de una dirección de monedero, tu aplicación envía una solicitud con el método «eth_getBalance» y dos parámetros: la dirección del monedero y «latest» (que se refiere al bloque más reciente). El nodo consulta el estado actual, busca el saldo asociado a esa dirección y lo devuelve como un valor hexadecimal. A continuación, tu aplicación convierte ese valor hexadecimal en un número legible para el usuario y lo muestra. El proceso completo suele tardar unas decenas de milisegundos con un proveedor de alto rendimiento.

×

Quicknode

□

Anatomía de los métodos RPC más comunes

Cada cadena de bloques define un conjunto de métodos RPC estándar que los nodos deben admitir. En Ethereum y en las cadenas compatibles con EVM, estos métodos siguen la convención de espacio de nombres «eth_». Las operaciones de lectura consultan el estado de la cadena de bloques sin modificarlo. «eth_blockNumber» devuelve la altura del último bloque. «eth_getBalance» devuelve el saldo de tokens nativos de una cuenta en un bloque determinado. «eth_call» ejecuta una función de contrato inteligente en modo de solo lectura mode, que es la forma en que tu aplicación recupera saldos de tokens, metadatos de NFT y estados de protocolos DeFi sin gastar gas.

Las operaciones de escritura envían datos a la red para que se incluyan en un bloque. «eth_sendRawTransaction» difunde una transacción firmada al mempool, donde los validadores la recogen para incluirla. «eth_estimateGas» simula una transacción para predecir cuánto gas consumirá, lo que ayuda a tu aplicación a establecer los límites de gas adecuados antes del envío.

Los métodos de suscripción permiten la comunicación en tiempo real a través de conexiones WebSocket. En lugar de que tu aplicación consulte repetidamente el nodo con «eth_blockNumber» para detectar nuevos bloques, puede llamar a «eth_subscribe» con el parámetro «newHeads» y el nodo enviará cada nueva cabecera de bloque a tu aplicación a medida que se genere. Esto es mucho más eficiente y presenta una menor latencia que las consultas repetidas, y constituye la base de experiencias de dapps en tiempo real, como flujos de transacciones en directo, detectores de eventos y actualizaciones instantáneas de saldos.

Solana utiliza un conjunto diferente de métodos optimizados para su modelo basado en cuentas. «getBalance» devuelve el saldo en SOL de una cuenta. «getTransaction» recupera una transacción confirmada mediante su firma. «getAccountInfo» devuelve los datos almacenados en una cuenta, que en Solana incluyen tanto los saldos de tokens como el estado del programa. A pesar de los diferentes nombres de los métodos, el patrón JSON-RPC subyacente es idéntico: solicitud con método y parámetros, respuesta con resultado o error.

×

Quicknode

□

El ciclo de vida de una solicitud: cómo funciona por dentro

Cuando tu aplicación envía una solicitud RPC, se producen varios pasos antes de que recibas una respuesta. En primer lugar, el cliente HTTP establece una conexión TCP con endpoint y realiza un protocolo de enlace TLS para cifrar el canal. A continuación, envía la carga útil JSON. El servidor RPC del nodo analiza la solicitud, valida el nombre del método y los parámetros, y la redirige al controlador adecuado. El controlador busca datos almacenados en caché, consulta la base de datos local del nodo o ejecuta cálculos (como una llamada a un contrato inteligente en la EVM). Una vez que el resultado está listo, el nodo lo serializa como JSON y lo envía de vuelta a través de la misma conexión.

Cada uno de estos pasos añade tiempo. La resolución de DNS, el protocolo de enlace TCP, la negociación TLS, la serialización de la solicitud, el procesamiento del nodo, la serialización de la respuesta y el tránsito por la red contribuyen todos ellos al tiempo total de respuesta. Por eso es importante la proximidad geográfica entre tu aplicación y el nodo RPC, por eso el uso de un grupo de conexiones y la multiplexación HTTP/2 mejoran el rendimiento, y por eso el almacenamiento en caché de los datos solicitados con frecuencia por tu parte reduce los viajes de ida y vuelta innecesarios.

Las solicitudes por lotes son una característica de la especificación JSON-RPC que permite enviar varias solicitudes en una sola llamada HTTP. En lugar de enviar cinco solicitudes independientes para consultar los saldos de cinco carteras diferentes, se agrupan las cinco en un array JSON y se envían juntas. El nodo procesa cada una de ellas y devuelve un array de respuestas. El procesamiento por lotes reduce la sobrecarga de HTTP y puede mejorar el rendimiento, aunque cada solicitud individual sigue consumiendo los mismos recursos de procesamiento por parte del nodo.

Gestión de errores y buenas prácticas

Las respuestas RPC incluyen códigos de error estándar cuando se produce un problema. Una solicitud mal formada devuelve un error de análisis. Un nombre de método no válido devuelve un error de «método no encontrado». La limitación de tasa suele devolver un estado HTTP 429 o un error JSON-RPC con el código -32005. Comprender estos códigos de error y gestionarlos adecuadamente en tu aplicación es esencial para desarrollar software de cadena de bloques fiable.

La lógica de reintentos con retroceso exponencial es una práctica recomendada para los fallos transitorios. Si una solicitud falla debido a un problema puntual en la red o a un nodo temporalmente sobrecargado, tu aplicación debería esperar un breve periodo de tiempo y volver a intentarlo, aumentando el tiempo de espera con cada reintento sucesivo. Esto evita que tu aplicación sature un nodo con problemas y agrave la situación. Establecer tiempos de espera razonables es igualmente importante, ya que una solicitud bloqueada que nunca se resuelve puede bloquear el bucle de eventos de tu aplicación.

También es importante elegir el método RPC adecuado para cada tarea. Un error habitual es llamar a «eth_getBlockByNumber» con el indicador de transacciones completas activado cuando tu aplicación solo necesita la cabecera del bloque. La respuesta con transacciones completas puede ser mucho mayor, lo que consume más ancho de banda y tarda más en analizarse. Del mismo modo, utilizar «eth_getLogs» con un rango de bloques excesivamente amplio puede devolver conjuntos de datos enormes que sobrecarguen tanto al nodo como a tu aplicación. Es una práctica habitual paginar las consultas de registros en rangos de bloques más pequeños.

¿Cuál es la diferencia entre las solicitudes RPC HTTP y WebSocket?

Las solicitudes RPC se transmiten a través de varios protocolos de transporte diferentes, y elegir el adecuado tiene un gran impacto en la latencia y la eficiencia. HTTP es un modelo de solicitud-respuesta: tu aplicación abre una conexión, envía una solicitud, recibe una respuesta y el intercambio finaliza. WebSocket mantiene abierta una única conexión persistente, de modo que el nodo puede enviar datos a tu aplicación en cuanto están disponibles. gRPC añade un protocolo binario de alto rendimiento para cargas de trabajo de baja latencia y alto rendimiento.

Si tu aplicación solo necesita lecturas ocasionales, el HTTP simple es la opción más sencilla. Si necesitas eventos en tiempo real de la cadena de bloques, una suscripción a WebSocket es mejor que saturar el nodo con llamadas repetidas. Para conocer con más detalle los tipos de conexión que ofrece un nodo, consulta qué es un RPC endpoint , y para conocer las ventajas e inconvenientes de realizar comprobaciones repetidas frente a la suscripción, consulta «polling vs streaming».

¿Por qué fallan las solicitudes RPC o se agota el tiempo de espera?

La mayoría de los errores de RPC se pueden clasificar en unas pocas categorías. La limitación de frecuencia devuelve un código HTTP 429 o un código JSON-RPC -32005 cuando se supera el límite de solicitudes permitido, por lo que es mejor esperar un rato y volver a intentarlo en lugar de volver a intentarlo inmediatamente. La indisponibilidad del nodo devuelve un 502 o un 503 cuando el nodo se está reiniciando, sincronizando o está sobrecargado. Las consultas demasiado grandes, como una eth_getLogs Las llamadas que atraviesan millones de bloques pueden agotar el tiempo de espera porque el nodo no puede preparar la respuesta a tiempo. Comprender Limitación de la velocidad de las RPC y combinar tu proveedor con una sólida fiabilidad de los nodos Estas prácticas hacen que estos fallos sean poco frecuentes y se puedan solucionar.

¿Cómo se pueden agilizar las solicitudes RPC?

La latencia de RPC es la suma del tiempo de tránsito por la red y el tiempo de procesamiento del nodo, y ambos son controlables. Dirige las solicitudes a un nodo geográficamente cercano a tus usuarios, reutiliza las conexiones mediante el uso de grupos y la multiplexación HTTP/2, agrupa las llamadas relacionadas en una sola solicitud y almacena en caché los datos que no cambian entre bloques. También resulta útil elegir el método más ligero para cada tarea: solicita una cabecera de bloque en lugar de transacciones completas cuando solo necesites la cabecera. Para obtener un desglose completo de los factores que ralentizan las solicitudes, consulta qué factores influyen en la latencia de RPC, o prescinde por completo del ajuste utilizando la API central deQuicknode , distribuida a nivel mundial.

¿Cuándo conviene utilizar RPC en lugar de la indexación o la transmisión?

RPC es la herramienta adecuada para consultas puntuales y operaciones de escritura: consultar un saldo concreto, leer el valor de un contrato o difundir una transacción. Sin embargo, resulta ineficaz cuando se necesitan grandes conjuntos de datos históricos o vistas agregadas, ya que reconstruir esos datos a partir de llamadas RPC sin procesar es lento y genera un gran número de solicitudes. Para consultas analíticas, un conjunto de datos indexado es mucho más eficiente, y en el caso de datos continuos en tiempo real, el streaming elimina por completo la sobrecarga de las solicitudes y respuestas. Consulta «RPC frente a indexación » para decidir entre llamadas en tiempo real y conjuntos de datos preparados.

Cómo optimiza « Quicknode » las solicitudes RPC

QuicknodeLa API principal de Quicknode está diseñada para que cada solicitud RPC sea lo más rápida y fiable posible. La infraestructura distribuida a nivel mundial de la plataforma redirige cada solicitud al nodo disponible más cercano, lo que minimiza el tiempo de tránsito en la red. Con tiempos de respuesta 2,5 veces más rápidos que los de la competencia de media y un SLA con un tiempo de actividad del 99,99 %, garantiza que las llamadas RPC de tu aplicación se resuelvan de forma rápida y constante, independientemente del volumen de tráfico.

Más allá del JSON-RPC estándar, Quicknode ofrece métodos de API mejorados que reducen el número de solicitudes que debe realizar tu aplicación. En lugar de llamar a varios métodos estándar para reconstruir el saldo completo de tokens de un monedero, una única llamada a la API mejorada puede devolver todos los datos en una sola respuesta. Quicknode Streams Va un paso más allá al eliminar por completo el patrón de solicitud-respuesta para los datos en tiempo real, enviando los eventos de la cadena de bloques directamente a tu aplicación o base de datos a medida que se producen. Para los desarrolladores que deseen optimizar su uso de RPC, Quicknode publica una guía detallada sobre llamadas RPC eficientes que abarca la paginación, el almacenamiento en caché, la gestión de errores y las mejores prácticas en la selección de métodos.

×

Quicknode

□

Preguntas frecuentes

¿Qué significa RPC en el contexto de la cadena de bloques?

RPC son las siglas de «Remote Procedure Call» (llamada a procedimiento remoto). Se trata de un patrón en el que tu aplicación llama a una función que se ejecuta en una máquina remota —en este caso, un nodo de cadena de bloques— como si se tratara de una función local. El nodo ejecuta el procedimiento sobre el estado de la cadena y devuelve el resultado.

¿Qué es JSON-RPC?

JSON-RPC es el protocolo ligero que utilizan la mayoría de las cadenas de bloques para RPC. Las solicitudes y las respuestas son objetos JSON sin formato. Una solicitud especifica un método y sus parámetros, y la respuesta contiene un resultado o un error, que se asocia a la solicitud mediante un identificador compartido.

¿Una solicitud RPC es lo mismo que una llamada a la API?

Se trata de un tipo específico de llamada a la API. Una API REST general expone recursos en diferentes URL, mientras que una API RPC de cadena de bloques expone métodos en una única URL endpoint y selecciona la operación a través del nombre del método en el cuerpo de la solicitud. El concepto de ida y vuelta de la solicitud-respuesta es el mismo.

¿Cuánto tiempo tarda una solicitud RPC?

Una simple lectura en un nodo cercano y bien abastecido suele completarse en unas decenas de milisegundos. Las llamadas más pesadas, como las consultas amplias de registros o las recuperaciones de bloques completos, tardan más tiempo, ya que el nodo tiene que recopilar y serializar más datos antes de responder.

¿Cuál es la diferencia entre un nodo RPC y un « endpoint » RPC?

Un nodo RPC es el servidor en ejecución que almacena los datos de la cadena de bloques y ejecuta las solicitudes. Un endpoint RPC es la URL a la que tu aplicación envía las solicitudes, y que las redirige a uno o varios nodos que se encuentran detrás de ella. Consulta qué es un nodo de cadena de bloques para conocer la infraestructura subyacente.

Lecturas recomendadas

Guía para realizar solicitudes RPC eficientes - Quicknode
Quicknode Documentación de la API
Comparación del rendimiento de los proveedores de RPC - Quicknode Guía
Quicknode API principal