---
title: "Nodo RPC"
description: "Un nodo RPC ofrece a carteras y aplicaciones una interfaz de petición y respuesta para consultar datos de la cadena de bloques y difundir transacciones. Aprende qué puede resolver un cambio de endpoint, qué no puede resolver y cómo reducir los riesgos de disponibilidad, privacidad y seguridad."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Nodo RPC

> Solo con fines educativos; no constituye asesoramiento de inversión. Un endpoint RPC incorrecto o malicioso puede exponer actividad, devolver datos engañosos o interrumpir el envío de transacciones, y las transacciones con activos digitales pueden causar pérdidas irreversibles.

<a id="answer"></a>

## Respuesta directa

Un nodo RPC es un nodo de cadena de bloques, o un servicio situado delante de uno o varios nodos, que acepta llamadas a procedimientos remotos de carteras, exploradores y aplicaciones. En redes compatibles con Ethereum, la interfaz habitual es JSON-RPC. Permite que el software lea datos del nodo, simule llamadas, estime gas y entregue bytes de transacciones firmadas para su difusión sin mantener un nodo propio.

La URL configurada en una cartera es un **endpoint RPC**, no la propia cadena de bloques. Cambiarla puede sortear una caída del proveedor, un nodo desactualizado, un límite de solicitudes, un método no admitido o un problema de conexión. No puede cambiar las reglas de un contrato, recuperar una transacción revertida, deshacer una transferencia confirmada ni reparar una interrupción de toda la red. El nuevo endpoint debe servir la red y el ID de cadena previstos.

<a id="mechanism"></a>

## Cómo funciona

El cliente envía una petición mediante un transporte admitido, como HTTP o WebSocket. Una petición JSON-RPC nombra un método, aporta parámetros e incluye un identificador que se repite en la respuesta. El nodo ejecuta el método contra su vista local de la cadena y devuelve un resultado o un error. Las conexiones WebSocket también pueden admitir suscripciones si el cliente y el endpoint las ofrecen.

Los métodos de lectura tienen significados y requisitos de datos distintos. Por ejemplo, `eth_blockNumber` informa del bloque más reciente conocido por el nodo, mientras que `eth_getBalance` lee el saldo de una dirección en una etiqueta o número de bloque concreto. Los resultados pueden diferir temporalmente entre nodos sanos porque varían sus cabeceras actuales, pools pendientes, modos de poda o extensiones. Un proveedor alojado también puede imponer autenticación, cuotas, límites de tamaño o restricciones de métodos que no son reglas de consenso.

En una transacción típica, la cartera la construye y firma localmente y envía los bytes firmados mediante `eth_sendRawTransaction`. El nodo RPC comprueba la petición e intenta propagar la transacción a sus pares. Que devuelva un hash significa que aceptó los bytes para su envío; no demuestra inclusión, ejecución correcta ni finalidad. La inclusión y el estado deben comprobarse de forma independiente en la cadena correcta.

Por tanto, el endpoint es una dependencia de confianza y disponibilidad. Puede observar direcciones consultadas, información de IP, horarios y transacciones enviadas; puede omitir o retrasar datos y mostrar una vista antigua o incompleta. Las firmas criptográficas impiden que cambie silenciosamente una transacción bien firmada, pero no hacen veraces las respuestas de lectura ni protegen los metadatos sin firmar o la privacidad.

<a id="example"></a>

## Ejemplo

Una cartera puede pedir el número de bloque a un cliente de ejecución de Ethereum con esta petición:

```json
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
```

Una respuesta válida podría ser:

```json
{"jsonrpc":"2.0","id":1,"result":"0x12ab34"}
```

El resultado hexadecimal es el último bloque conocido por ese endpoint. Si el proveedor habitual agota el tiempo de espera, pero un segundo endpoint fiable devuelve un bloque más nuevo y el ID de cadena esperado, el cambio puede restaurar las consultas de saldo y el envío de transacciones. Si ambos muestran el mismo recibo revertido, cambiar de RPC no altera ese resultado en cadena.

<a id="risks"></a>

## Riesgos y controles

- **Red equivocada:** un endpoint copiado puede servir otra cadena o bifurcación. Antes de firmar, verifica mediante una fuente independiente el ID de cadena, el nombre de la red, el activo nativo y un bloque reciente.
- **Lecturas falsas o antiguas:** un endpoint defectuoso o malicioso puede devolver saldos viejos, omitir registros o falsear simulaciones. Compara lecturas importantes con otro proveedor o nodo propio y fija un bloque explícito cuando necesites reproducibilidad.
- **Pérdida de privacidad:** las consultas pueden vincular la actividad de una cartera con metadatos de red. Evita enviar direcciones innecesarias, revisa las políticas de retención y considera un endpoint propio de confianza si la privacidad compensa el coste operativo.
- **Censura o retraso:** el endpoint puede negarse a difundir o demorarse. Guarda el hash firmado, consulta exploradores o nodos independientes y usa una segunda vía fiable si la transacción no aparece. No firmes un reemplazo sin comprobar el nonce y las consecuencias sobre comisiones.
- **Credenciales expuestas:** las claves API en código público pueden robarse y agotar cuotas. Restringe las claves por origen o servicio cuando sea posible, mantén las credenciales privilegiadas fuera del cliente y rota las filtradas.
- **Exposición peligrosa del nodo:** publicar una interfaz administrativa o demasiado amplia aumenta la superficie de ataque. Vincula el RPC propio a la interfaz local por defecto, expón solo los espacios de nombres necesarios, añade autenticación y controles de red, y nunca expongas cuentas desbloqueadas.
- **Engaño de la cartera:** una URL de endpoint no necesita frase semilla ni clave privada. Rechaza cualquier servicio que las pida, revisa los campos de la transacción en la cartera y no identifiques un contrato de destino solo por una respuesta RPC.

<a id="misconceptions"></a>

## Errores comunes

- **«RPC es la cadena de bloques».** Es una interfaz hacia la vista que tiene un nodo de ella.
- **«Un hash implica confirmación».** Normalmente solo prueba que un endpoint aceptó los bytes firmados; ejecución y finalidad son etapas distintas.
- **«Cambiar de RPC cambia las comisiones o el contrato».** Puede cambiar estimaciones o calidad de acceso, pero la ejecución real depende de la transacción y las reglas del protocolo.
- **«Todos los endpoints devuelven los mismos datos».** Pueden diferir el estado de sincronización, los pools pendientes, el historial conservado, las extensiones y las políticas.
- **«HTTPS hace fiable toda respuesta».** HTTPS protege la conexión con el servidor nombrado, pero no demuestra que sus datos de cadena sean completos o correctos.

<a id="related"></a>

## Temas relacionados

- [Nodo completo](/crypto/full-node/)
- [Cadena de bloques](/crypto/blockchain/)
- [Mempool](/crypto/mempool/)
- [RPC de transacciones privadas](/crypto/private-transaction-rpc/)
- [Explorador de bloques](/crypto/block-explorer/)

<a id="sources"></a>

## Fuentes

- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultado: 2026-08-21)
- [Especificación de la API de ejecución](https://ethereum.github.io/execution-apis/docs/quickstart/) - Ethereum Execution APIs (consultado: 2026-08-21)
- [Servidor JSON-RPC](https://geth.ethereum.org/docs/interacting-with-geth/rpc) - go-ethereum (consultado: 2026-08-21)
- [Ejecutar un nodo de Ethereum propio](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consultado: 2026-08-21)

Source: https://wiki.fcontext.com/es/crypto/rpc-node/index.mdx