IPC nodo blockchain: go-ipc conecta bots sin TCP/HTTP

En pocas palabras: Se conecta con IPC: go-ipc, la librería en Go de seiji0411 (6 de octubre de 2026), une un servidor del nodo con varios bots mediante named pipes en Windows y sockets Unix en Linux y macOS. Cada bot usa canales de suscripción y envío, sin TCP ni HTTP.

Si buscás IPC nodo blockchain para varios bots, go-ipc es una librería en Go que conecta un servidor del nodo con bots de trading, como procesos separados de la misma máquina y sin TCP ni HTTP. Su autor, seiji0411, la presentó el 6 de octubre de 2026.

go-ipc es una librería de comunicación bidireccional entre procesos escrita en Go, pensada para transmitir eventos de blockchain a bots de trading. Conecta un servidor IPC del lado del nodo con cualquier cantidad de bots clientes que corren como procesos separados en la misma máquina. Cada bot tiene dos canales dedicados: uno de suscripción (nodo a bot) para bloques, logs y transacciones pendientes, y otro de envío (bot a nodo) para transacciones firmadas.

¿Qué es go-ipc y para qué sirve?

go-ipc sirve para que un proceso del lado del nodo reparta eventos a varios bots y reciba de vuelta transacciones firmadas, todo por pipes locales del sistema operativo. El transporte no lo escribió el autor: según el README del repositorio, lo resuelve james-barrow/golang-ipc, y los tipos de transacción y log vienen de go-ethereum.

El post donde seiji0411 lo presenta, publicado el 6 de octubre de 2026, es del propio autor, no una evaluación externa. Ni el post ni el README traen datos de adopción o de rendimiento.

Ojo con una confusión fácil: go-ipc no es el socket geth.ipc de Geth. Ese archivo es el endpoint JSON-RPC del nodo, y go-ipc define su propio protocolo de mensajes encima de golang-ipc.

¿Cómo funciona el registro, la suscripción y el heartbeat entre el nodo y los bots?

Cada bot se registra en el pipe bot_main_ipc, levanta su propio pipe de suscripción, le informa el nombre al nodo y recibe el nombre de un tercer pipe para enviar transacciones. Según el README, un bot termina usando tres pipes en su vida útil (registro, suscripción y envío), y el de registro se cierra tras el handshake.

1. Registro: el bot se conecta a bot_main_ipc, arranca su servidor en un pipe único (nombre del tipo bot<ts>_<rand>) y manda un mensaje MsgTypeNewClient con ese nombre.
2. Conexión del nodo: el nodo se conecta al pipe del bot (los roles se invierten: el bot hospeda el servidor y el nodo actúa como cliente) y crea su propio servidor con el sufijo _submit.
3. Canal de envío: el nodo manda MsgTypeCreateSubmit con el nombre del pipe de envío y el bot se conecta.
4. Cierre del registro: dos segundos después de registrarse, el bot cierra la conexión con bot_main_ipc.

Los eventos salen con BroadcastLog, que lanza una goroutine por bot. Cada frame lleva un sobre JSON (IPCMessage) cuyo tipo interno indica si es inicio de bloque (5), log (6), fin de bloque (7) o transacción pendiente (8).

Sobre el heartbeat, el README fija un ping del bot cada 3 segundos, una revisión del nodo cada 5 y la expulsión tras más de 10 segundos sin ping. Una inferencia nuestra, que el README no dice: como la revisión es cada 5 segundos, un bot caído debería desaparecer entre 10 y 15 segundos después de su último ping. Tema relacionado: cómo evaluar la infraestructura de nodos web3.

Los fragmentos del README, condensados. Nodo, difundir un bloque:

go nodeipc.Shared().Run()

block, _ := json.Marshal(message.IPCBlock{BlockNumber: 123, BlockTimestamp: 1700000000})
envelope, _ := json.Marshal(message.IPCMessage{
 MessageType: message.MsgTypeBlockStart,
 MessageData: block,
})
nodeipc.Shared().BroadcastLog(envelope)

Bot, consumir eventos y enviar transacciones:

events := make(chan message.IPCMessage)
if err := nodeipc.Shared().Run(events); err != nil {
 panic(err)
}
for ev := range events {
 switch ev.MessageType {
 case message.MsgTypeBlockStart: /* ... */
 case message.MsgTypeLog: /* ... */
 case message.MsgTypePendingTx: /* ... */
 }
}
// con el pipe de envío ya creado:
// nodeipc.Shared().SubmitTxn(rawSignedTx)

¿En qué se diferencia el IPC de un nodo blockchain del HTTP y el WebSocket?

En Geth, IPC es un pipe del sistema de archivos local, habilitado por defecto y con acceso a todos los namespaces JSON-RPC. HTTP y WebSocket hay que activarlos con flags (–http y –ws) y sí aceptan conexiones remotas, según la documentación de Geth.

Transporte	Suscripción a eventos	Conexión remota	Overhead por mensaje	Activación y ubicación
HTTP	No	Sí	Alto	–http, puerto 8545
WebSocket	Sí	Sí	Bajo	–ws, puerto 8546
IPC	Sí	No	Bajo	Por defecto, ~/.ethereum/geth.ipc o \\.\pipe\geth.ipc en Windows

La ruta se cambia con –ipcpath y el IPC se apaga con –ipcdisable. La documentación aclara que cualquier proceso de la misma máquina puede usar el archivo geth.ipc. Sobre cómo conectarte desde Python o Node.js, las fuentes no traen ejemplos y no vamos a inventarlos.

Sobre seguridad, Geth dice (traducción nuestra) que IPC es el más seguro porque se limita a interacciones en la máquina local y no puede exponerse a tráfico externo. Lo del “sin overhead de TCP/HTTP” que repite el README de go-ipc es una decisión de diseño, no una medición. Tomalo con pinzas.

¿Alguien midió la latencia contra WebSocket? En estas fuentes, no.

¿Qué limitaciones tiene go-ipc hoy?

Según el README, go-ipc es una demo con cuentas pendientes, no una pieza lista para integrar sin revisar.

• Una sola máquina: nodo y bots tienen que compartir host.
• Pausas fijas de 2 segundos: el handshake las usa entre pasos. En el log de ejemplo, entre recibir al bot y mandar CreateSubmit pasan 2 segundos.
• Demo con texto plano: el servidor demo difunde “Hello Client” y el bot, que espera JSON, registra JSON parse Error en esos frames (sí, en serio).
• Envío sin terminar: en el camino de envío, el README deja un TODO para reenviar la transacción al tx pool del nodo.
• Licencia: el README no la menciona. Revisá el repositorio antes de usarlo en un proyecto comercial.

Qué está confirmado y qué no

Confirmado en las fuentes:

• La arquitectura de tres pipes y los tiempos de ping, revisión y expulsión (README).
• El transporte con named pipes y sockets Unix (README y documentación de Geth).
• Que Geth trae IPC habilitado por defecto y sin conexión remota (documentación de Geth).

Sin confirmar:

• Latencia o throughput frente a HTTP y WebSocket.
• Funcionamiento con un nodo real conectado a una red.
• Que SubmitTxn llegue al tx pool.
• Adopción y estabilidad en producción.

Con esto podés decidir si vale la pena prototipar. No alcanza para elegirlo sobre WebSocket por rendimiento.

¿Cuándo conviene usar IPC local y cuándo no?

Conviene cuando nodo y bots viven en el mismo host, y no sirve cuando algún bot corre en otro servidor, porque ahí hace falta red. Lo que sigue es criterio editorial, no sale de las fuentes. Para más detalles técnicos, mirá el costo de las llamadas HTTP en n8n.

Ponele un caso hipotético: un nodo y tres bots en una misma máquina, cada uno suscripto a su pipe. Ahí el esquema de go-ipc encaja. Ahora imaginá que levantás el nodo, arrancás los tres bots, todo anda bárbaro en la demo, lo llevás a servidores separados para escalar y de golpe los pipes locales no alcanzan, porque el bot ya no comparte máquina con el nodo y hay que rediseñar el transporte con WebSocket o HTTP, con todo lo que eso implica en seguridad.

Si evaluás dónde alojar ese host único, en donweb.com hay VPS y cloud en Argentina. El requisito técnico es que ambos procesos compartan máquina.

Un bot que firma y envía transacciones merece cuidado con los permisos del pipe o socket (que no es poco). Geth aclara que su IPC accede a todos los namespaces, así que revisá quién puede abrir ese archivo.

Propuesta de verificación (editorial, no la probamos nosotros): corré server.go y dos client.go en terminales separadas, y chequeá que el log del servidor muestre los dos bots registrados y un BroadcastLog con 2 clientes. Matá uno de los bots y comprobá que el servidor lo da de baja a los 10 a 15 segundos. Por último, mandá una transacción de prueba y confirmá que llegue al tx pool, porque ese paso hoy es un TODO.

Errores comunes

• Compilar con go run . o go build ./…: server.go, client.go y wsClient.go declaran cada uno su propio main. Corrélos archivo por archivo, como indica el README.
• Confundir go-ipc con geth.ipc: son cosas distintas. Si querés llamar a eth_call desde un bot, apuntá a geth.ipc.
• Difundir texto plano: el bot espera un IPCMessage en JSON. Envolvé cada evento como en el snippet de BroadcastLog.
• Dar por hecho que SubmitTxn llega a la red: el reenvío al tx pool está pendiente. Verificalo antes de apostar plata.
• Abrir HTTP para evitar IPC: Geth advierte que exponer APIs como debug por HTTP aumenta la superficie de ataque, y que hay bots escaneando nodos con HTTP habilitado.

Preguntas Frecuentes

¿Qué es go-ipc y para qué sirve?

go-ipc es una librería en Go para comunicación bidireccional entre procesos, pensada para enviar eventos de blockchain a bots de trading. Conecta un servidor del lado del nodo con varios bots en la misma máquina y usa golang-ipc como transporte.

¿Cómo conecto varios bots a un nodo blockchain en la misma máquina?

Cada bot se registra en el pipe bot_main_ipc, crea su pipe de suscripción y recibe un pipe de envío, mientras el nodo difunde eventos a todos con BroadcastLog. Para probarlo, el README indica correr go run client.go en terminales separadas, una por bot. Complementá con orquestar los bots como contenedores con Kubernetes.

¿Qué diferencia hay entre IPC y HTTP en un nodo Ethereum?

En Geth, IPC es un pipe local, viene habilitado por defecto y permite suscribirse a eventos, mientras que HTTP cierra la conexión tras cada respuesta y no ofrece suscripción. La documentación de Geth marca el overhead por mensaje como alto en HTTP y bajo en IPC.

¿IPC funciona en Windows, Linux y macOS?

Sí, en los tres. go-ipc usa named pipes en Windows y sockets de dominio Unix en Linux y macOS, y Geth hace lo mismo: su ruta por defecto es \\.\pipe\geth.ipc en Windows y ~/.ethereum/geth.ipc en Linux y macOS.

¿Se puede usar IPC si el bot corre en otro servidor?

No. La tabla de Geth marca la conexión remota como no disponible para IPC, y el README de go-ipc limita todo a una misma máquina. Con el bot en otro servidor necesitás WebSocket o HTTP, y proteger esos puertos.

Conclusión

go-ipc es una propuesta concreta y bien documentada para repartir eventos de un nodo entre varios bots por IPC local, con registro, heartbeat y expulsión automática. También es un proyecto personal con un TODO en el envío de transacciones, sin mediciones y sin licencia declarada en el README.

Si tu nodo y tus bots comparten máquina, clonalo, corré la demo y aplicá la verificación propuesta antes de comparar con WebSocket. Si tus bots están en otro servidor, ni lo mires, andá directo a WebSocket y protegé el puerto.

Fuentes

• GitHub, seiji0411/go-ipc – repositorio y README del proyecto
• DEV Community – post del autor sobre go-ipc, 6 de octubre de 2026
• go-ethereum – documentación del servidor JSON-RPC y transportes