libp2p: la pila modular que salió de los ficheros distribuidos

Casi todo lo que hoy llamamos redes entre pares en producción desciende de un mismo gesto de ingeniería: alguien construyó un sistema de ficheros distribuido, descubrió que la parte difícil no era el almacenamiento sino conseguir que dos máquinas cualesquiera hablaran entre sí, y decidió sacar esa parte a una biblioteca aparte. Esa biblioteca es libp2p, y su documentación la define sin adornos como un sistema modular de protocolos, especificaciones y bibliotecas para desarrollar aplicaciones entre pares a escala global. La palabra decisiva de esa definición es modular, porque libp2p no te entrega una red: te entrega los ejes sobre los que se puede construir una, y la obligación de elegir un valor para cada eje. Esa elección es su mayor virtud cuando sabes lo que quieres y su mayor coste cuando no. Antes de comparar libp2p con nada, conviene entender qué ejes existen, cuándo se resuelven —casi todos durante el establecimiento de la conexión, no en tiempo de compilación— y qué factura llega después.

Una pila extraída, no diseñada desde cero

El detalle histórico importa más de lo que parece. libp2p no nació de una especificación previa a la implementación, sino de la necesidad concreta de un sistema de ficheros distribuido que tenía que funcionar sobre redes reales, con navegadores, móviles, servidores y toda la fauna de cortafuegos que hay entre ellos. Cuando la lógica de red se separó del resto, heredó una propiedad que ninguna pila diseñada en abstracto suele tener: cada pieza existe porque un despliegue concreto la necesitó. Eso explica su heterogeneidad, que a primera vista parece desorden.

La consecuencia práctica es que libp2p tiene hoy varias implementaciones de primera fila —en Go, Rust, JavaScript, Nim y Python— y que todas siguen las mismas especificaciones precisamente para poder hablar entre ellas. Esa disciplina de especificación compartida es lo que convierte a libp2p en algo más que una biblioteca: es un contrato entre lenguajes. Un nodo escrito en Rust y otro escrito en el navegador pueden abrir una conexión porque ambos implementan el mismo documento, no porque compartan código.

El objetivo declarado del proyecto es que tus aplicaciones de red funcionen con independencia del entorno de ejecución y de la ubicación de los nodos. Traducido a decisiones de diseño: nada en la pila puede asumir que existe una dirección estable, ni un puerto abierto, ni un sistema operativo concreto, ni siquiera un sistema operativo. De ahí sale casi todo lo demás.

Las capas intercambiables y el momento en que se eligen

La pila se organiza en ejes, y cada eje admite varios valores simultáneos. El eje del transporte mueve los bits: TCP, QUIC, WebSocket, WebRTC y WebTransport son las opciones documentadas, y ser agnóstico respecto al transporte figura como requisito fundacional del proyecto. Una aplicación puede habilitar varios a la vez; la elección real se hace al marcar, según lo que el otro extremo anuncie.

El eje del canal seguro cifra y autentica. Todas las conexiones van cifradas por defecto con Noise o con TLS 1.3, sin excepción y sin modo inseguro para producción. El eje del multiplexado permite abrir muchos flujos lógicos sobre una única conexión, con Yamux y mplex como implementaciones. Y por encima de todo eso vive el componente que la documentación llama switch —o swarm, según la implementación—, que guarda el estado de los pares conocidos y de las conexiones abiertas, y que ofrece una interfaz de marcado y escucha que abstrae qué multiplexor se acabó usando en cada conexión.

// La pila se declara eje a eje: cada campo es una lista de candidatos
import { createLibp2p } from "libp2p";
import { tcp } from "@libp2p/tcp";
import { webSockets } from "@libp2p/websockets";
import { noise } from "@chainsafe/libp2p-noise";
import { yamux } from "@chainsafe/libp2p-yamux";
import { identify } from "@libp2p/identify";

const nodo = await createLibp2p({
  transports: [tcp(), webSockets()],   // el marcado elige uno segun el par
  connectionEncrypters: [noise()],     // Noise o TLS 1.3, nunca nada
  streamMuxers: [yamux()],             // Yamux o mplex, negociado
  services: { identify: identify() },
});

Lo que hay que retener no es la lista de opciones sino cuándo se resuelve la elección. No es en tiempo de compilación: es durante el establecimiento de la conexión, mediante negociación de protocolo. Los pares acuerdan un multiplexor que ambos soporten y ese acuerdo promociona una conexión de transporte cruda a una conexión multiplexada capaz de abrir flujos nuevos. La documentación es explícita en un detalle que ahorra muchos dolores: si marcas a un par con el que el switch ya tiene una conexión abierta, el flujo nuevo se multiplexa automáticamente sobre la existente en lugar de abrir otra.

Descubrimiento y enrutado: encontrar a quien no tiene dirección estable

Un par en libp2p se identifica por su PeerId, derivado de su clave pública, y se alcanza mediante una multiaddr, una dirección compuesta que describe el camino completo capa por capa. La separación es deliberada: la identidad es criptográfica y permanente, la dirección es circunstancial y múltiple. Un mismo par puede anunciar varias direcciones a la vez y cambiarlas sin dejar de ser quien es, que es exactamente lo que la documentación llama itinerancia nativa.

Queda entonces el problema de averiguar qué direcciones tiene alguien. Aquí conviene separar dos preguntas que se confunden a menudo. El descubrimiento responde a qué pares existen: mDNS los encuentra en la red local por multidifusión, y el protocolo de encuentro los reúne alrededor de un punto conocido. El enrutado responde a cómo llego a este par concreto: la DHT de Kademlia mantiene una tabla distribuida donde consultar las direcciones asociadas a un identificador. Y hay un tercer protocolo, identify, que suele pasar desapercibido y es central: es el mecanismo por el que un nodo aprende qué direcciones suyas ve el mundo desde fuera.

flowchart TD
APP[tu aplicacion habla un protocolo con su identificador] --> SW[switch o swarm que guarda pares y conexiones]
SW --> MUX[multiplexado negociado yamux o mplex]
MUX --> SEC[canal seguro noise o TLS 1.3]
SEC --> TR[transporte TCP QUIC WebSocket WebRTC WebTransport]
SW --> DISC[descubrimiento mDNS y protocolo de encuentro]
SW --> RUT[enrutado DHT de Kademlia]
DISC --> SW
RUT --> SW
style APP fill:#a6e3a1,color:#11111b
style SEC fill:#f9e2af,color:#11111b
style TR fill:#89b4fa,color:#11111b
style DISC fill:#cba6f7,color:#11111b

Ese bucle del diagrama no es decorativo. El switch necesita direcciones para marcar, el descubrimiento y el enrutado se las suministran, y ambos necesitan conexiones abiertas para funcionar, que solo el switch puede darles. Arrancar un nodo desde cero exige romper la circularidad con pares semilla configurados de antemano, y esa dependencia inicial es el punto donde más redes entre pares se atascan en producción sin que nadie lo haya escrito en el diagrama de arquitectura.

El precio de la modularidad

La primera factura es de negociación. Cada eje que dejas abierto es una conversación más antes de poder enviar el primer byte útil, y esas conversaciones ocurren en el peor momento posible: cuando el usuario está esperando. La segunda es de interoperabilidad combinatoria: cinco transportes por dos canales seguros por dos multiplexores por cinco implementaciones de lenguaje no es una matriz que se pueda verificar a ojo. No es casualidad que el proyecto mantenga una batería de pruebas de interoperabilidad entre implementaciones y una página pública de estado; existen porque la modularidad las hace imprescindibles.

// En rust cada eje es un campo del tipo, y el compilador te obliga a decidir
#[derive(NetworkBehaviour)]
struct MiPila {
    identify: identify::Behaviour,
    kademlia: kad::Behaviour<kad::store::MemoryStore>,
    relay_cliente: relay::client::Behaviour,
    dcutr: dcutr::Behaviour,
}

La tercera factura, la más silenciosa, es de depuración. Cuando una conexión no se establece, la pregunta por qué tiene demasiadas respuestas posibles: no había transporte común, la negociación del canal seguro falló, el multiplexor no coincidió, el par anunciaba direcciones inalcanzables, la consulta a la tabla distribuida no devolvió nada, el cortafuegos descartó el paquete. Un sistema con una sola opción por eje no es más rápido, pero tiene un árbol de fallos que cabe en la cabeza de una persona.