BackPlane: middleware de mensajería notarizada

BackPlane es un middleware de mensajería notarizada desarrollado en 2022 íntegramente por Gonzalo Varalla. La idea central: usar una blockchain privada permisionada como infraestructura de almacenamiento y replicación de mensajes entre sistemas de información diversos dentro de ecosistemas de múltiples participantes. Era el segundo intento —el primero, sobre Hyperledger Fabric, ya había ido a producción.

El problema que resuelve

Los ecosistemas complejos —cadenas de suministro, redes de organizaciones, procesos de gobierno— tienen tres flujos: el logístico (bienes y servicios), el financiero (dinero) y el administrativo (información). El flujo de información es el más difícil de auditar: los mensajes entre sistemas son efímeros, dispersos y de visibilidad local. BackPlane apunta exactamente a ese problema: garantizar que cada mensaje quede registrado de forma inmutable, replicada y verificable, con visibilidad controlada por rol.

La topología de la red

La red tiene tres tipos de nodos en topología concéntrica. En el núcleo están los validators: seis nodos que ejecutan el consenso IBFT 2.0 con Besu. El período de bloque es de dos segundos; el epoch, de 30.000 bloques. Los validators no exponen servicios a las aplicaciones: su único trabajo es acordar el estado de la cadena.

En la capa intermedia están los bootnodes: tres nodos que facilitan el descubrimiento de pares dentro de la red. En la capa exterior están los writers: uno por despliegue, es el único punto de contacto entre las aplicaciones y la red. El writer firma las transacciones vía EthSigner y las inyecta en la cadena.

En producción, los seis validators y los tres bootnodes se distribuyen en tres corenodes —dos validators y un bootnode por corenode—. En laboratorio, todo el núcleo corre en un solo corenode: cuatro validators y dos bootnodes.

El stack

Los nodos tienen dos perfiles de stack. Los corenodes —bootnodes y validators— corren Linux 64 bits con Java y Besu como única aplicación: no hay Node.js, no hay middleware de aplicación.

El writer tiene un stack completo: Linux 64 bits, Java, Besu, EthSigner, Node.js y nginx. EthSigner corre en el puerto 8501 como servicio independiente y gestiona las claves privadas fuera del cliente Besu. El middleware Node.js corre en el puerto 8888 con Express como framework HTTP. nginx opera como reverse proxy en el 8080 y es el punto de acceso externo para las aplicaciones.

Todo el aprovisionamiento se hace con scripts Bash estructurados por componente —base, corenode, writer, backplane—; los servicios de aplicación corren como unidades systemd.

Los módulos y los roles

El contrato Solidity desplegado en la red organiza tres módulos: governance, accounting y messaging.

Governance gestiona el ciclo de vida de los miembros y define tres roles. El service provider es el administrador del ecosistema: puede registrar y desactivar cualquier tipo de miembro, modificar límites y tiene visibilidad completa sobre todos los mensajes. El rector tiene permisos similares pero con alcance acotado. El standard es el participante ordinario: solo puede enviar y recibir mensajes, y solo ve los que le conciernen.

Accounting lleva los contadores de mensajes por miembro y aplica throttling: cada miembro tiene un límite configurable de mensajes por período; solo un service provider puede resetear el contador. Messaging maneja el envío y la recepción.

Los tipos de mensaje

BackPlane define cuatro tipos de envío. Las trazas son mensajes utilizados para dejar constancia de un dato o evento —registro puro, sin destinatario específico—. Las notificaciones comunican un dato o evento a otros participantes.

El broadcast es un envío público en texto plano a todos los miembros activos de la red; el hash del contenido queda registrado en el contrato. El unicast —y su variante multicast— es un envío cifrado de extremo a extremo: el emisor firma el mensaje con su clave privada Ethereum mediante ECDSA y lo cifra con la clave pública del receptor usando criptografía de curva elíptica; solo el destinatario puede descifrarlo con su clave privada. Los service providers pueden leer cualquier mensaje en texto plano, lo que les habilita un rol de auditoría.

El registro inmutable

Cada acción genera registros inmutables en la cadena. El catálogo de miembros registra código de cuatro bytes, dirección Ethereum, nombre, clave pública, rol y estado. Cada mensaje registra emisor, receptor, hash del contenido y el contenido propiamente dicho —en texto plano para broadcast, cifrado para unicast y multicast—.

Una bitácora global actúa como registro de auditoría: cada operación produce una entrada que referencia al registro que la originó. Los contadores y límites por miembro completan el modelo de gobierno. Todo cambio de estado emite el evento notifyNews, indexado por código de miembro y tipo de registro, que el listener externo puede consumir en tiempo real.

La API REST y el listener

El middleware Node.js expone una API REST completa sobre todos los métodos del contrato; todos los endpoints son POST con cuerpo JSON. La API cubre consulta de registros, gestión de miembros, envío y lectura de mensajes, y consulta de estado —límites, contadores, disponibilidad de códigos y direcciones—. nginx actúa como reverse proxy entre los clientes externos y el middleware.

Un listener independiente —también Node.js, corriendo como servicio systemd— mantiene una conexión WebSocket con Besu y suscribe al evento notifyNews. Al recibir un evento, lo propaga vía HTTP POST a un endpoint externo configurable, permitiendo que los participantes reaccionen en tiempo real sin polling.

Apuntes generales

BackPlane aborda un problema genuino: los ecosistemas de múltiples organizaciones necesitan un canal de comunicación auditable sin depender de que ningún participante sea el custodio de la verdad. La blockchain privada cumple ese rol —es el registro compartido que todos pueden leer según su rol y que nadie puede modificar—.

La decisión de usar Besu en lugar de Hyperledger Fabric fue deliberada: Besu es un cliente Ethereum estándar, compatible con EVM y con redes como Quorum y LACchain, y permite ofrecer un producto instalable con menor fricción operativa que Fabric. El proyecto quedó en estado de laboratorio funcional: la red arranca, procesa mensajes, aplica throttling y emite eventos. Lo que faltó fue un cliente que lo llevara a producción en su segunda generación.