Si has desarrollado o usado cualquier aplicación blockchain — una wallet, un DEX, una plataforma de tokenización — has usado RPC sin saberlo. Cada vez que MetaMask muestra tu balance de ETH, cada vez que una DApp ejecuta una transacción, cada vez que un smart contract se despliega en Ethereum, hay una llamada RPC detrás. Es la infraestructura invisible que conecta el mundo de las aplicaciones con la blockchain.
A pesar de su importancia crítica, la mayoría de guías en español sobre RPC en blockchain son glosarios de 800 palabras que no explican realmente cómo funciona, qué métodos necesitas conocer ni cómo elegir un proveedor. Esta guía llena ese vacío.
¿Qué es RPC y por qué importa en blockchain?
RPC (Remote Procedure Call) es un protocolo de comunicación que permite a un programa ejecutar funciones en un servidor remoto como si fueran locales. En el contexto de blockchain, RPC es el mecanismo por el que tu aplicación (wallet, DApp, backend) se comunica con un nodo de la red para leer datos, enviar transacciones y ejecutar smart contracts.
La analogía más clara: imagina que la blockchain es una base de datos distribuida en miles de ordenadores. Tu aplicación no accede directamente a esa base de datos — envía peticiones a un nodo a través de un endpoint RPC, y ese nodo consulta la blockchain y devuelve la respuesta. Es el equivalente a una API REST, pero específica para redes blockchain.
Sin RPC, no hay interacción posible con la blockchain. No hay wallets, no hay DApps, no hay DeFi, no hay tokenización. Es la capa de comunicación fundamental de todo el ecosistema Web3.
¿Cómo funciona RPC en blockchain? Arquitectura completa
El flujo de una llamada RPC en blockchain sigue esta arquitectura:
[DApp / Wallet / Backend] → [Endpoint RPC] → [Nodo Blockchain] → [Red Blockchain]
1. La aplicación genera la petición: Tu DApp (frontend en JavaScript, backend en Python, wallet como MetaMask) construye una petición JSON-RPC con el método deseado y los parámetros necesarios.
2. La petición se envía al endpoint RPC: A través de HTTP (para consultas puntuales) o WebSocket (para suscripciones en tiempo real). El endpoint puede ser un nodo propio, un servicio gestionado (Alchemy, Infura) o un endpoint público gratuito.
3. El nodo procesa la petición: El nodo blockchain recibe la petición, la ejecuta contra su copia local de la blockchain (para lecturas) o la propaga a la red (para transacciones), y genera la respuesta.
4. La respuesta vuelve a la aplicación: El nodo devuelve un objeto JSON con el resultado, que la aplicación interpreta y presenta al usuario.
Este ciclo ocurre miles de veces por segundo en cada aplicación blockchain en producción. La latencia, fiabilidad y capacidad de tu endpoint RPC determinan directamente la experiencia de usuario de tu DApp.
JSON-RPC: el estándar de comunicación en Ethereum y redes EVM
JSON-RPC es un protocolo de llamada remota que usa JSON como formato de datos. Es ligero, sin estado (stateless) y independiente del transporte — funciona sobre HTTP, WebSocket o IPC. Ethereum lo adoptó como su estándar de comunicación, y todas las redes compatibles con EVM (Polygon, Arbitrum, Optimism, Base, BSC) usan el mismo protocolo.
Una petición JSON-RPC tiene esta estructura:
{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": ["0x742d35Cc6634C0532925a3b844Bc9e7595f2bD28", "latest"],
"id": 1
}
Y la respuesta:
{
"jsonrpc": "2.0",
"id": 1,
"result": "0x1a055690d9db80000"
}
Los campos clave: method indica qué función ejecutar, params son los argumentos, id identifica la petición (para correlacionar respuestas en llamadas asíncronas), y result contiene el dato devuelto (en hexadecimal para valores numéricos).
Métodos RPC esenciales que todo desarrollador debe conocer
| Método | Función | Ejemplo de uso |
|---|---|---|
eth_getBalance |
Obtener balance de una dirección | Mostrar saldo en wallet |
eth_blockNumber |
Número del último bloque | Verificar sincronización |
eth_call |
Ejecutar función de smart contract (lectura) | Leer estado de un token ERC-20 |
eth_sendRawTransaction |
Enviar transacción firmada | Transferir tokens, ejecutar swap |
eth_getTransactionReceipt |
Obtener recibo de transacción | Verificar confirmación |
eth_getLogs |
Obtener eventos/logs de contratos | Escuchar transferencias de tokens |
eth_estimateGas |
Estimar gas necesario | Calcular coste antes de enviar |
eth_gasPrice |
Precio actual del gas | Optimizar timing de transacciones |
eth_chainId |
ID de la red | Verificar que estás en la red correcta |
net_version |
Versión de la red | Validación de red |
eth_call es probablemente el método más usado. Permite ejecutar funciones de lectura en smart contracts sin gastar gas — consultar el balance de un token ERC-20, leer el estado de un contrato de tokenización, o verificar si un inversor está verificado en un contrato ERC-3643.
eth_sendRawTransaction es el método para escribir en la blockchain. Recibe una transacción firmada (serializada en hexadecimal) y la envía al nodo para su propagación y eventual inclusión en un bloque. Cada transferencia de tokens, cada interacción con DeFi y cada despliegue de smart contract usa este método.
eth_getLogs es esencial para aplicaciones que necesitan monitorear eventos on-chain: transferencias de tokens, cambios de estado en contratos, eventos de compliance en tokens ERC-3643. Se utiliza en combinación con filtros para escuchar solo los eventos relevantes.
Nodos RPC: públicos vs privados vs gestionados
La elección del tipo de endpoint RPC es una de las decisiones más importantes en la arquitectura de cualquier DApp:
| Tipo | Coste | Fiabilidad | Rendimiento | Rate Limits | Privacidad | Ideal para |
|---|---|---|---|---|---|---|
| Público | Gratis | Baja | Variable | Estrictos | Ninguna | Pruebas, desarrollo |
| Propio | Alto (infra + mantenimiento) | Alta | Total control | Sin límite | Total | Empresas con equipo DevOps |
| Gestionado | Medio ($49-$499+/mes) | Muy alta (SLA) | Dedicado | Configurables | Alta | Producción empresarial |
Endpoints públicos (como los de Chainlist.org) son gratuitos pero con limitaciones serias: rate limiting agresivo, sin SLA, peticiones compartidas con miles de usuarios, y zero privacidad — tu dirección IP y tus peticiones son visibles. Suficiente para desarrollo y pruebas, inaceptable para producción.
Nodos propios requieren mantener la infraestructura: servidores, almacenamiento (un nodo completo de Ethereum necesita >2TB de SSD), sincronización, actualizaciones y monitoreo. Ofrecen control total pero con un coste operativo significativo.
Proveedores gestionados (Alchemy, Infura, QuickNode) son el estándar para aplicaciones en producción. Ofrecen endpoints dedicados, SLAs de uptime, dashboards de monitoreo, y APIs enriquecidas que van más allá del JSON-RPC estándar.
Comparativa de proveedores RPC en 2026
| Proveedor | Redes soportadas | Plan gratuito | Precio inicial | Diferenciación | Ideal para |
|---|---|---|---|---|---|
| Alchemy | 30+ (EVM + Solana) | Sí (300M CU/mes) | $49/mes | Mejor tooling para devs (Notify, Transact) | DApps con tooling avanzado |
| Infura | 15+ (EVM) | Sí (100K req/día) | $50/mes | Integración nativa MetaMask | Proyectos Ethereum-first |
| QuickNode | 25+ (EVM + non-EVM) | Sí (limitado) | $49/mes | Máximo rendimiento (RPS) | Aplicaciones de alto tráfico |
| Google Cloud | Ethereum + EVM | Sí (limitado) | Pay-as-you-go | Enterprise, sin gestión de nodos | Empresas en Google Cloud |
| Chainstack | 30+ | Sí (3M req/mes) | $29/mes | Multi-chain, buen precio/prestaciones | Startups multi-chain |
| Ankr | 45+ | Sí (limitado) | Pay-per-request | Mayor cobertura de redes | Proyectos cross-chain |
Alchemy lidera en tooling para desarrolladores. Sus APIs enriquecidas (Alchemy Notify para webhooks de eventos, Transact para gestión de transacciones) van mucho más allá del JSON-RPC estándar. Es la elección preferida para desarrollo de DApps que necesitan monitoreo avanzado.
QuickNode lidera en rendimiento bruto. Su infraestructura globalmente distribuida ofrece las mayores tasas de requests por segundo, lo que lo hace ideal para aplicaciones de alto tráfico como DEXs, plataformas de trading o sistemas de tokenización con muchos usuarios concurrentes.
Infura sigue siendo el proveedor más confiable para proyectos centrados en Ethereum, con la ventaja de su integración nativa con MetaMask (ambos propiedad de Consensys).
WebSocket vs HTTP: ¿cuándo usar cada protocolo?
| Característica | HTTP | WebSocket |
|---|---|---|
| Modelo | Request-response | Bidireccional persistente |
| Uso principal | Consultas puntuales | Suscripciones en tiempo real |
| Latencia | Mayor (nueva conexión por petición) | Menor (conexión persistente) |
| Ejemplo |
eth_getBalance, eth_call
|
eth_subscribe (nuevos bloques, logs) |
| Ideal para | Backend, consultas batch | Dashboards en tiempo real, DEXs |
HTTP es suficiente para la mayoría de operaciones: consultar balances, enviar transacciones, leer estados de contratos. Cada petición abre una conexión, recibe la respuesta y cierra.
WebSocket es imprescindible cuando necesitas datos en tiempo real: nuevos bloques minados, eventos emitidos por contratos (transferencias de tokens, cambios de estado), actualizaciones de precio. La conexión se mantiene abierta y el nodo envía datos automáticamente cuando ocurren eventos — sin necesidad de hacer polling constante.
Para plataformas de tokenización, WebSocket es esencial para mostrar transacciones de tokens en tiempo real, notificar a los inversores cuando reciben distribuciones de rendimientos, y monitorear eventos de compliance en contratos ERC-3643.
RPC en la práctica: tokenización, DeFi y Smart Wallets
Cada caso de uso blockchain tiene patrones RPC específicos:
Tokenización con ERC-3643: Las plataformas de tokenización inmobiliaria usan eth_call para verificar la elegibilidad de inversores (consultar ONCHAINID), eth_sendRawTransaction para ejecutar transferencias de tokens con compliance automático, y eth_getLogs para monitorear eventos de distribución de rendimientos. Un proveedor RPC con baja latencia y alta disponibilidad es crítico — una llamada RPC fallida puede bloquear una transacción de inversión.
DeFi: Los protocolos de finanzas descentralizadas generan volúmenes masivos de llamadas RPC. Un swap en Uniswap implica múltiples eth_call (cotización, slippage, aprobación), seguidas de eth_sendRawTransaction y eth_getTransactionReceipt. Los arbitrajistas ejecutan cientos de peticiones por segundo.
Smart Wallets (ERC-4337): Las wallets con account abstraction usan patrones RPC especializados — incluyendo el envío de UserOperations a bundlers que las empaquetan en transacciones regulares. Esto añade una capa adicional de complejidad RPC que requiere endpoints compatibles con ERC-4337.
Librerías y herramientas: ethers.js, web3.js y viem
Los desarrolladores no suelen hacer llamadas JSON-RPC directamente — usan librerías que abstraen la complejidad:
ethers.js es la librería más popular en 2026. Ofrece una API limpia y tipada para interactuar con Ethereum:
const provider = new ethers.JsonRpcProvider("https://eth-mainnet.alchemyapi.io/v2/YOUR_KEY");
const balance = await provider.getBalance("0x742d35Cc...");
console.log(ethers.formatEther(balance)); // "1.5"
web3.js fue la primera librería Ethereum y sigue siendo ampliamente usada, especialmente en proyectos legacy. Su API es más verbosa pero muy documentada.
viem es la alternativa moderna, con enfoque en TypeScript, rendimiento y tree-shaking. Está ganando adopción rápidamente en nuevos proyectos por su diseño modular y tipo-seguro.
Las tres librerías construyen llamadas JSON-RPC internamente y las envían al endpoint configurado. La elección depende del stack tecnológico del proyecto y las preferencias del equipo.
Buenas prácticas y seguridad en endpoints RPC
En Beltsys aplicamos estas prácticas en todos nuestros proyectos de desarrollo Web3:
- Nunca expongas tu API key en el frontend: Usa un backend o proxy que añada la key en servidor. Una API key expuesta en el código del navegador puede ser explotada por cualquiera.
- Implementa fallback multi-proveedor: Configura al menos dos proveedores RPC. Si Alchemy falla, tu aplicación debe conmutar automáticamente a Infura o QuickNode.
-
Cachea respuestas frecuentes: Consultas como
eth_chainId,eth_blockNumbero balances de tokens cambian con poca frecuencia. Un caché de 5-15 segundos reduce drásticamente las llamadas RPC. - Usa rate limiting en tu backend: Protege tu endpoint RPC de abuso. Sin rate limiting, un bot puede agotar tu cuota en minutos.
- Monitorea latencia y errores: Configura alertas para detectar degradación del servicio RPC antes de que afecte a los usuarios.
- Separa endpoints por función: Usa un endpoint para lecturas (alto volumen, baja latencia) y otro para escrituras (alta fiabilidad, confirmación).
Si estás construyendo una DApp, plataforma de tokenización o sistema Web3 y necesitas asesoramiento sobre arquitectura de infraestructura RPC, nuestro equipo de consultoría blockchain puede ayudarte a diseñar una arquitectura robusta y escalable.
Sigue explorando
- Que es blockchain: guia completa
- Cuanto cuesta crear un smart contract
- Que es Web3: guia para empresas
Preguntas frecuentes sobre RPC en blockchain
¿Qué es RPC en blockchain?
RPC (Remote Procedure Call) es el protocolo de comunicación que conecta las aplicaciones (wallets, DApps, backends) con los nodos de la red blockchain. Cada consulta de balance, transacción o interacción con un smart contract pasa por una llamada RPC. En Ethereum y redes EVM se usa el estándar JSON-RPC, que envía peticiones y recibe respuestas en formato JSON.
¿Cuál es la diferencia entre un nodo RPC público y uno gestionado?
Un nodo público es gratuito pero con rate limiting, baja fiabilidad y sin privacidad — adecuado solo para desarrollo. Un proveedor gestionado (Alchemy, Infura, QuickNode) ofrece endpoints dedicados con SLA de disponibilidad, mayor rendimiento, dashboards de monitoreo y APIs enriquecidas. Es el estándar para aplicaciones en producción.
¿Qué proveedor RPC es mejor para mi proyecto en 2026?
Depende del caso de uso: Alchemy para DApps que necesitan tooling avanzado, QuickNode para alto rendimiento, Infura para proyectos Ethereum-first con integración MetaMask, Chainstack para startups multi-chain con presupuesto ajustado, y Google Cloud para empresas que ya usan infraestructura Google. La mejor práctica es configurar al menos dos proveedores como fallback.
¿Qué es JSON-RPC y por qué lo usa Ethereum?
JSON-RPC es un protocolo de llamada remota que usa JSON como formato de datos. Es ligero, sin estado e independiente del transporte. Ethereum lo adoptó como estándar de comunicación por su simplicidad y compatibilidad con cualquier lenguaje de programación. Todas las redes EVM (Polygon, Arbitrum, Optimism, Base) usan el mismo protocolo.
¿Cuándo debo usar WebSocket en lugar de HTTP para RPC?
Usa HTTP para consultas puntuales: balances, estados de contratos, envío de transacciones. Usa WebSocket cuando necesites datos en tiempo real: nuevos bloques, eventos de smart contracts, actualizaciones de precio. WebSocket mantiene una conexión persistente y el nodo envía datos automáticamente sin necesidad de polling.
¿Cómo se usa RPC en tokenización con ERC-3643?
Las plataformas de tokenización usan eth_call para verificar elegibilidad de inversores en ONCHAINID, eth_sendRawTransaction para ejecutar transferencias con compliance automático, y eth_getLogs para monitorear eventos de distribución de rendimientos. Un proveedor RPC fiable con baja latencia es crítico para la experiencia del inversor. Beltsys integra esta infraestructura en sus proyectos de tokenización.
Sobre el autor
Beltsys es una empresa española de desarrollo blockchain especializada en infraestructura Web3, smart contracts y tokenización para empresas y fintechs. Con experiencia en más de 300 proyectos desde 2016, Beltsys diseña e implementa arquitecturas blockchain de producción — desde la selección de infraestructura RPC hasta el despliegue de plataformas de tokenización con ERC-3643. Conoce más sobre Beltsys
Related: Desarrollo Web3
Related: Smart Contracts
Related: Tokenización inmobiliaria
Top comments (0)