Skip to main content
En el Logic-Injection-on-Origin Protocol, un “Cliente” es un Nodo Agente (Agent Node) o un orquestador de Inteligencia. Mientras el Servidor garantiza una ejecución segura, el Cliente es responsable de descubrir datos, definir intenciones y despachar la lógica de ejecución a través de la red. Los Nodos Agentes operan la Malla a través de tres mecanismos: Descubrimiento (DHT), Handshakes de Elicitación e Inyección de Lógica.

​
1. Descubrimiento de Red (Kademlia DHT)

A diferencia de las arquitecturas tradicionales donde el Cliente debe conocer la IP o el DNS del servidor, los Nodos Agentes en LIOP operan en una topología descentralizada:
Enrutamiento por Tabla de Hash DistribuidaEnrutamiento por Tabla de Hash Distribuida
  • Peer IDs: Cada nodo genera una identidad Ed25519 al iniciar.
  • Kademlia DHT: Los nodos forman una Tabla de Hash Distribuida.
  • Consulta por Capacidad: Para acceder a un recurso (ej., SQL_Database), el Agente pregunta a la red: “¿Quién posee esta capacidad?”.
  • Ruta Optimizada: El algoritmo DHT calcula la ruta más eficiente, resolviendo IPs dinámicas detrás de NATs y firewalls sin registros centrales.

​
2. Handshakes de Elicitación y Confianza

La confianza no depende de autoridades de certificación centralizadas. LIOP emplea un handshake Zero-Trust antes de ejecutar lógica:
  • Noise Protocol: Las conexiones QUIC se cifran usando claves derivadas de la identidad del Agente.
  • PQC (Kyber): Las Elicitaciones encapsulan intenciones con ML-KEM-768, protegiendo la comunicación contra futuras amenazas cuánticas (Harvest Now, Decrypt Later).
Si se requiere intervención humana o tokens de autorización, el Nodo de Datos solicita los alcances de OAuth al Agente de forma nativa.

​
3. Inyección de Lógica (El Payload)

Tras establecer el canal seguro, el Cliente inyecta el binario de ejecución:
  1. Compilación: El SDK traduce la lógica de alto nivel (JS/Python) en un módulo binario WebAssembly.
  2. GuardianTS: Inspección estática del .wasm para verificar que no incluya llamadas al sistema no autorizadas fuera del sandbox.
  3. Sellado (Crypto): El payload se cifra con ML-KEM-768 y AES-256-GCM.
  4. Streaming (MeshNode): El binario se transmite vía Yamux y Noise a la malla de destino.
  5. Verificación ZK: El Agente valida el ZK-Receipt recibido, garantizando la integridad computacional del resultado.

​
4. Arquitectura de Ejecución en Node.js

El SDK está diseñado para gestionar límites de seguridad y cifrado intensivo sin bloquear el Event Loop principal de Node.js.
Flujo de Runtime Animado SDKFlujo de Runtime Animado SDK
Componentes clave dentro de @nekzus/liop:

​
1. Agent App

El punto de origen que define la intención analítica y genera la lógica que se enviará a la red.

​
2. GuardianTS

Primera línea de defensa. Analiza el binario generado mediante una compilación estática previa para verificar que no solicite importaciones fuera de wasi_snapshot_preview1.

​
3. Worker Pool (Piscina)

Para evitar saturar el hilo principal con operaciones criptográficas, LIOP delega el cifrado y descifrado a un pool de hilos de trabajo (piscina).
  • Outbound: Los hilos cifran el .wasm con ML-KEM-768 y AES-256-GCM en paralelo.
  • Inbound: Los resultados y recibos ZK se verifican de forma concurrente, evitando bloqueos en el bucle de eventos de Node.js.

​
4. MeshNode

La interfaz hacia la red descentralizada. Gestiona la puerta de enlace libp2p, el túnel Noise y la multiplexación Yamux, permitiendo múltiples inyecciones simultáneas sobre una sola conexión QUIC/TLS con mínima sobrecarga de tramas.