Skip to main content
La clase LiopServer constituye la infraestructura receptora del protocolo Logic-Injection-on-Origin. Aloja conjuntos de datos confidenciales, aplica fronteras criptográficas, valida módulos de lógica entrantes en WebAssembly o JavaScript mediante Guardian AST y los ejecuta dentro de sandboxes aislados de V8 bajo estrictos límites de memoria e instrucciones de CPU. En lugar de exponer endpoints de alto riesgo basados en REST o consultas SQL directas a agentes remotos de inteligencia artificial, un LiopServer declara Capacidades (Herramientas) estrictamente tipadas. Los agentes envían programas compilados para computar los resultados in-situ; de este modo impiden que los registros crudos viajen por la red.

Creación y Configuración del Servidor

Inicialice un Nodo de Datos definiendo su identidad pública y sus parámetros de seguridad perimetral:

Opciones de Configuración del Servidor

object
requerido
Identidad canónica transmitida durante la negociación del protocolo.
ServerOptions
Configuración integral de seguridad, concurrencia en hilos y taxonomía de red.

Declaración de Capacidades (tool)

Las capacidades representan herramientas analíticas ejecutables expuestas hacia la red. Declárelas mediante esquemas tipados con Zod:

Flujo de Ejecución de Lógica In-Situ

Cuando un agente envía módulos de código dinámico (archivos .wasm o scripts de JavaScript aislados), el entorno aplica seis capas sucesivas de protección:
  1. Capa 1 (Guardian AST): Analiza el árbol de sintaxis abstracta antes de inicializar el módulo. Solo autoriza 14 funciones base de wasi_snapshot_preview1. Cualquier invocación a APIs del sistema anfitrión cancela la ejecución al instante.
  2. Capa 2 (Sandbox Aislado de V8): Procesa el código dentro de un contexto seguro donde 25 variables globales sensibles (process, require, eval, Function, setTimeout, fetch, WebSocket) quedan sustituidas por trampas que abortan la memoria ante cualquier acceso. Aplica Object.freeze sobre 11 prototipos nativos (Object, Array, Promise, etc.) para cumplir con las exigencias de PCI-DSS.
  3. Capa 3 (Analizador Taint): Rastrea el flujo de información para impedir la inferencia indirecta de datos confidenciales mediante canales laterales o conversiones de caracteres.
  4. Capa 4 (Escudo PII de Salida): Examina las respuestas contra patrones de tarjetas de pago, numeraciones IBAN, fórmulas de validación y modelos NER.
  5. Capa 5 (Política de Agregación): Exige que el resultado contenga métricas consolidadas. La presencia de listas de registros individuales detiene la entrega del paquete.
  6. Capa 6 (Generación de Recibo ZK): Emite un recibo criptográfico vinculado al resumen de la lógica procesada y al hash del dataset. Soporta compromisos HMAC-SHA256 (Modo 0, v1), pruebas de conocimiento cero Groth16 sobre la curva BN254 (Modo 2, v2) y recibos híbridos de doble capa con firma digital post-cuántica ML-DSA-65 (Modo 3, v2.1) según la configuración de la herramienta.

Políticas de Ejecución de Herramientas (LogicExecutionPolicy)

Los enclaves configuran parámetros detallados de Conocimiento Cero y criptografía post-cuántica de forma individual por cada herramienta proporcionando el objeto policy:

Recursos y Plantillas de Prompts

Además de herramientas ejecutables, LiopServer publica esquemas estáticos, referencias y plantillas estructuradas para coordinar a los agentes.

Publicación de Recursos

Registro de Prompts

Modo de Autonomía (enableZeroShotAutonomy)

Activa el prompt de sistema liop_blind_analyst y publica el diccionario de datos del nodo en la malla:

Ciclo de Vida y Apertura de Conexiones


Referencia de Métodos Públicos