¿Conoces este escenario? Estás ejecutando un bot de trading. Cada milisegundo cuenta: cada llamada a RPC cuesta dinero.
Pagas una prima a un proveedor de RPC de alta velocidad para ejecutar transacciones al instante. Pero el problema es que: en tus llamadas RPC, el 90% es lectura, no escritura. Consultas precios, verificas saldos y escaneas el mempool, pero pagas el mismo precio alto por cada llamada.
¿Qué pasaría si mantuvieras completamente inalterada la ruta de escritura rápida, pero desviar todo el tráfico de lectura hacia un canal más barato y de un subconjunto pequeño?
Esto no es una suposición. Este patrón se llama separación lectura-escritura, y es una de las arquitecturas más efectivas para reducir costos para cualquier dApp seria, robot o indexador.
Dolores que todos sentimos
Hablemos claro: hoy en día, la mayoría de los proyectos usan RPC de esta manera.
while True:
price = web3.eth.call(price_feed_contract) # Lectura
balance = web3.eth.get_balance(user_wallet) # Lectura
# ... comprobar condiciones ...
tx_hash = web3.eth.send_raw_transaction(signed) # Escritura
En un ciclo de transacción típico, por cada transacción se hacen 10–50 lecturas. Sin embargo, la mayoría de los desarrolladores enrutan todas las solicitudes a un solo endpoint RPC—normalmente el optimizado para velocidad de envío de transacciones y, por lo tanto, más caro.
Si pagas $X por un RPC de aceleración de transacciones, pero el 95% de tus llamadas son de lectura, en realidad estás desperdiciando $0.95X en consultas de datos que podrían hacerse con un proveedor muchísimo más barato.
En realidad, no es un problema de precios, sino de arquitectura—y la solución es sorprendentemente simple. A continuación, te lo desgloso en detalle.👇
Nuestra solución: separación de lectura y escritura
La arquitectura es sencilla:
Consultas de lectura (eth_call, eth_getBalance……) ➡️ BlockPI (barato, estable, con soporte de archivo)
Transacciones de escritura (RPC de aceleración de transacciones) ➡️ Tu RPC de aceleración de transacciones (envío de baja latencia)
Solo mantén dos proveedores en tu código, enruta de forma inteligente las solicitudes y podrás ahorrar inmediatamente entre 60–80% en costes de RPC.
Cómo funciona en el código
Es extremadamente sencillo de implementar. Aquí tienes un patrón práctico de Python:
from web3 import Web3
from web3.middleware import geth_poa_middleware
import os
READ_RPC_URL = os.getenv("BLOCKPI_RPC_URL")
WRITE_RPC_URL = os.getenv("TRANSACTION_ACCELERATION_RPC_URL")
w3_read = Web3(Web3.HTTPProvider(READ_RPC_URL))
w3_write = Web3(Web3.HTTPProvider(WRITE_RPC_URL))
w3_read.middleware_onion.inject(geth_poa_middleware, layer=0)
w3_write.middleware_onion.inject(geth_poa_middleware, layer=0)
def get_eth_price():
price_feed = w3_read.eth.contract(
address="0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419",
abi=[{"inputs":[],"name":"latestAnswer","outputs":[{"internalType":"int256","name":"","type":"int256"}],"stateMutability":"view","type":"function"}]
)
return price_feed.functions.latestAnswer().call()
def execute_swap(signed_tx):
return w3_write.eth.send_raw_transaction(signed_tx)
def wait_for_receipt(tx_hash):
return w3_read.eth.wait_for_transaction_receipt(tx_hash)
O, de forma más limpia, usa un encapsulado de Web3 con enrutamiento automático:
class SmartWeb3:
"""Encapsulado Web3 para enrutar las solicitudes de lectura y escritura a diferentes proveedores."""
def __init__(self, read_rpc: str, write_rpc: str):
self._read = Web3(Web3.HTTPProvider(read_rpc))
self._write = Web3(Web3.HTTPProvider(write_rpc))
@property
def eth(self):
return self._routed_eth()
def _routed_eth(self):
class RoutedEth:
def __init__(self, read, write):
self._read = read.eth
self._write = write.eth
def get_balance(self, address, block=None):
return self._read.get_balance(address, block)
def call(self, transaction, block=None):
return self._read.call(transaction, block)
def get_logs(self, filter_params):
return self._read.get_logs(filter_params)
def send_raw_transaction(self, signed_tx):
return self._write.send_raw_transaction(signed_tx)
def estimate_gas(self, transaction):
return self._write.estimate_gas(transaction)
def get_transaction_count(self, address, block=None):
return self._write.get_transaction_count(address, block)
def block_number(self):
return self._read.block_number()
def wait_for_transaction_receipt(self, tx_hash, timeout=120):
return self._read.wait_for_transaction_receipt(tx_hash, timeout)
return RoutedEth(self._read, self._write)
w3 = SmartWeb3(
read_rpc=os.getenv("BLOCKPI_RPC_URL"),
write_rpc=os.getenv("TRANSACTION_ACCELERATION_RPC_URL")
)
balance = w3.eth.get_balance("0x...")
price = w3.eth.call(tx)
tx_hash = w3.eth.send_raw_transaction(signed_tx)
La lógica del negocio no necesita ningún cambio de comportamiento; la única diferencia es la factura.
Por qué BlockPI está diseñado para escenarios con muchas lecturas
Después de separar lecturas y escrituras, el proveedor de lecturas debe cumplir tres puntos:
Fiabilidad a gran escala
Tu robot o dApp no puede permitirse perder un bloque. La infraestructura de BlockPI está construida para cargas de trabajo de producción: nodos distribuidos, conmutación automática por fallos y un búfer de limitación de velocidad que realmente funciona.
Soporte de archivo — porque las lecturas a menudo necesitan datos históricos
Muchos patrones de lectura requieren datos históricos—obtener los logs de la semana pasada, comprobar posiciones antiguas de LP o reproducir eventos tras reiniciar. BlockPI soporta modo de archivo en Ethereum y Base (desde el bloque génesis), eth_getLogs admite rangos de 5,000 bloques y permite paginación para consultas a cualquier profundidad.
Eficiencia de costes que realmente marque la diferencia
La facturación basada en RU de BlockPI es competitiva, así que puedes enrutar lecturas de alto volumen sin tener que sopesar una y otra vez el coste por cada llamada. El coste por llamada es solo una fracción del cobrado por el proveedor premium orientado a ejecución.
Volumen de llamadas Lecturas mediante RPC de aceleración de transacciones Lecturas mediante BlockPI
1M llamadas/día $XX–$XXX 60–80% menos
10M llamadas/día $XXX–$XXXX La brecha se amplía
¿Para quién es adecuada la separación de lectura y escritura?
A continuación se muestra cómo configurar un robot típico de MEV o arbitraje en JavaScript:
const { Web3 } = require('web3');
const web3Read = new Web3('https://base.blockpi.network/v1/rpc/{YOUR_API_KEY}');
const web3Write = new Web3(process.env.TRANSACTION_ACCELERATION_RPC_URL);
async function tradingCycle() {
// Paso 1: escanear oportunidades (todas las lecturas van por BlockPI)
const currentPrice = await web3Read.eth.call({
to: '0x...',
priceFeed.encodeABI()
});
const poolReserves = await web3Read.eth.call({
to: poolAddress,
poolAbi.encodeReserves()
});
const profit = calculateProfit(currentPrice, poolReserves);
// Paso 2: si es rentable, ejecutar (escritura vía RPC rápido)
if (profit > threshold) {
const nonce = await web3Write.eth.getTransactionCount(wallet.address);
const gasPrice = await web3Write.eth.getGasPrice();
const tx = {
from: wallet.address,
to: routerAddress,
swapData,
gas: 300000,
gasPrice: gasPrice * 2,
nonce: nonce,
chainId: 8453
};
const signed = await wallet.signTransaction(tx);
const txHash = await web3Write.eth.sendRawTransaction(signed);
// Paso 3: esperar confirmación (lecturas por BlockPI)
const receipt = await web3Read.eth.getTransactionReceipt(txHash);
return receipt;
}
}
Cada bloque, el robot ejecuta cientos de lecturas para escanear oportunidades; pero cuando encuentra una, solo envía una o dos transacciones. Sin separación lectura-escritura, estos costes de escaneo se acumulan cada vez que haces un eth_call a la tarifa alta de un RPC caro.
BlockPI ofrece a los desarrolladores:
• Precios competitivos por RU — haciendo que las cargas de trabajo intensivas en lecturas sean realmente asequibles
• API de Beacon + blob_sidecars, para análisis de datos en L2
• Soporte multi-cadena — una sola consola, varias cadenas, facturación unificada
• Rango getLogs de 5,000 bloques — con paginación hasta cualquier profundidad
Esto significa para tu proyecto:
• Robot de trading — escanea el mempool y datos on-chain de bajo costo, y ejecuta transacciones mediante proveedores rápidos
• Rastreadores de cartera — ejecuta cientos de consultas de balances/llamadas en lotes, sin que la factura te sorprenda
• Indexador — reproduce datos históricos con profundidad de archivo y reenvía transacciones cuando sea necesario
• Panel DeFi — incluso con sondeos continuos de datos on-chain, sigue siendo sostenible financieramente
🛡️ No solo lectura: infraestructura de transacciones más flexible
Separar lectura y escritura no significa que BlockPI solo sirva para lecturas. Cuando tu aplicación también envía transacciones a través de BlockPI, puedes activar la protección MEV para ayudar a reducir el riesgo de ataques tipo sandwich y otras extracciones de mempool. Las transacciones sensibles pueden enrutarse por una ruta de envío protegida, sin quedar expuestas de forma predeterminada en el mempool público.
En la práctica, muchos equipos usan BlockPI como capa principal de lectura de alta capacidad para eth_call, balances, logs y receits, y eligen la ruta de escritura según la tarea: cuando la prioridad es una colocación en cadena con ultra baja latencia, se usa el RPC de aceleración de transacciones; cuando la calidad de ejecución más segura es más importante que la velocidad original, se usa BlockPI con protección MEV. Así, los desarrolladores obtienen una arquitectura flexible, en lugar de verse obligados a elegir entre proveedores.
🔒 Después de habilitar la protección MEV, BlockPI puede ayudar al equipo a conservar más valor del que normalmente esperaría obtener on-chain—especialmente útil para intercambios, liquidaciones y otras transacciones sensibles al precio—sin renunciar a infraestructura de lectura con excelente relación calidad-precio. También puede ayudarte a enviar transacciones sensibles sin que los arbitrajistas te las intercepten.
Empieza con la separación de lectura y escritura en minutos
La migración no requiere cambios importantes en el código:
1. Regístrate en https://dashboard.blockpi.io y obtén un endpoint
2. Configura en el código una instancia de solo lectura de Web3 apuntando a BlockPI
3. Enrútala para que maneje solicitudes de lectura—eth_call, eth_getBalance, eth_getLogs, eth_blockNumber, eth_getTransactionReceipt……
4. Conserva el proveedor de escritura existente, para el RPC de aceleración de transacciones. O usa nuestro servicio MEV
No necesitas reescribir el código ni rediseñar la arquitectura por completo; solo tienes que tomar decisiones de enrutamiento más inteligentes.
Comparación real de costes
Supongamos que tu proyecto realiza 100,000 llamadas al día:
• De esas 95,000, 95,000 son lecturas (eth_call, getBalance, getLogs, blockNumber)
• 5,000 son escrituras (RPC de aceleración de transacciones)
Modo Coste de lectura Coste de escritura Total
All through accelerated transaction RPC High x 95K High x 5K $$$$
Separación lectura-escritura con BlockPI Low x 95K High x 5K ~60–80% menos
El ahorro crece linealmente con la cantidad de lecturas. Para cargas de trabajo intensivas en lecturas—que es lo que ocurre en la mayoría de los proyectos—separar lectura y escritura no solo es una buena idea, sino una necesidad económica.
Elige la modalidad que mejor se adapte a su solución
Tu aplicación no necesita usar la misma ruta RPC para cada tipo de operación. La clave es hacer que cada categoría de carga de trabajo se ajuste a las características de infraestructura que realmente necesita:
Lecturas: capacidad, estabilidad, profundidad de archivo ➡️ BlockPI
Escritura: velocidad de transacción ➡️ tu RPC de aceleración de transacciones
No se trata de reemplazar tus RPC existentes, sino de evitar que pagues de más por lo que ya estás haciendo.
BlockPI ofrece la parte de lectura en esta ecuación: precios asequibles, soporte de archivo y una infraestructura a nivel producción, para que puedas escalar el volumen de lecturas sin aumentar los costes en la misma proporción.
Elige el modelo de compra que se adapte a tu carga de trabajo:
1️⃣ Paquete RU — Compra paquetes de recursos RPC predefinidos, adecuado para cargas de trabajo predecibles, con un presupuesto más claro y mejores unidades de economía en niveles de uso comprometidos.
2️⃣ Pago por uso (PAYG) — Empieza sin paquetes fijos, pagando según el uso real. Ideal para cargas de trabajo con cambios de tráfico, pruebas y necesidades de escalado flexible.
Experimenta la separación de lectura y escritura al instante ➡️ https://dashboard.blockpi.io
Concéntrate en BLOCKPI:
X oficial：https://x.com/RealBlockPI
YouTube：https://www.youtube.com/@BlockPINetwork
Telegram：@BlockPIdaily
Consola: https://dashboard.blockpi.io/