BCP 0.2
Identidad del nodo, ruta autorizada y paquetes desde un estado de registro verificable.
Estado del desarrollo
BCP 0.2 es la capa de paquetes y el registro de IPvX. Los contratos del registro se probaron en la cadena viva Sepolia: REG-001 se ejecutó en modo de lectura Q, y R1 se cerró el 2026-11-06 con la lectura REG-001-LC mediante cliente ligero, según su criterio sustitutivo, el estado actual; los valores S1–S3 siguen siendo observaciones del modo Q. La entrega de paquetes guiada por el registro pasó sobre estado de prueba del registro (NET-001-F, PASS el 2026-11-08); sobre estado vivo (NET-001-L) aún no se ha ejecutado.
Instantánea de estado:
Implementado en código
Formato de paquetes, NodeRegistry, TransitPolicy, ConnectionPolicy, adaptador EL/CL e integración con el núcleo. Las lecturas de contratos se fijan a un blockHash finalizado.
Comprobado offline
93 pruebas del runner y 14 comprobaciones del plan. Claves temporales, EVM en memoria, cabeceras sintéticas y puertos en memoria; sin medición de red ni finalidad de cadena.
Próximo experimento de red
NET-001-F pasó el 2026-11-08 en la VM separada del banco: la ejecución bcp-net001-run-0003, con un permiso firmado por el propietario, dio PASS en las 14 variantes de comprobación, y el verificador independiente confirmó el resultado. Es la entrega de tramas Ethernet entre tres nodos sobre un kernel Linux real con estado sintético del registro: no prueba la finalidad de la cadena, un enlace físico ni operadores independientes. El siguiente experimento es NET-001-L sobre el estado vivo del registro. Lee el registro con el cliente ligero Helios: el modo LC sustituyó al modo V el 2026-11-05, así que no hace falta un nodo Sepolia propio. Helios aún no se ejecuta en el banco, y la regla de actualización de la instantánea en NET-001-L sigue siendo una condición abierta. El acceso a un nuevo inicio está cerrado: cada ejecución necesita su propio permiso firmado por el propietario.
Qué cambia BCP
Identidad
NodeRegistry vincula el identificador NFT de un nodo con su propietario y claves. Una clave autogenerada no concede participación.
Ruta autorizada
TransitPolicy y ConnectionPolicy definen saltos y conexiones permitidos. Los nodos verifican rutas contra un estado fijado; blockchain no sustituye el transporte de tramas.
Formación del paquete
Identificadores, checkpoint, ruta, firmas y datos cifrados tienen un formato binario exacto. MAC indica el vecino siguiente; el identificador, el nodo final.
Datos antes del permiso
El dataset se prepara por separado. El permiso firmado vincula su hash, el del paquete completo, run ID, creación y vencimiento. El runner no genera datos de sustitución tras la autorización.
Vigencia máxima de 30 minutos, limitada además por el checkpoint fresco más antiguo. Copiar o reiniciar no prolonga un dataset vencido.
Formato del permiso y límites
dataset_sha256 · bundle_sha256 · run_id · created_at · expires_at
Límites de las evidencias
El primer experimento, NET-001-F, pasó en una VM Linux: namespaces A–R–B y dos enlaces veth. No demuestra operación en cadena real, acceso abierto, sustrato Ethernet físico ni ventaja sobre IP.
Mesh es un experimento separado
El banco histórico comprueba entrega firmada y cambios de ruta entre nodos previamente admitidos. No implementa el registro blockchain de BCP. Se conservan sus diarios, capturas y conclusiones previas.
Abrir Mesh y sus evidencias · Experimento strict-LLM registrado
Mesh: intercambio Ethernet
Nodos admitidos de antemano eligen el siguiente salto. Las tareas y las rutas viajan en tramas Ethernet.
- Banco
- mesh en vivo, 5 VM en 3 hosts físicos
- Tramas
EtherType 0x88B5- Agentes
- sintéticos, sin LLM
- Operador
- uno
- Gestión
- por IP administrativa
- Relación con BCP
- prototipo independiente · BCP 0.2 y su admisión →
Conectando con los registros firmados…
Solo los operadores del banco pueden desconectar nodos. Aquí se muestra una selección limitada de registros firmados, no el registro completo de la red.
Esperando mensajes
La ruta aparecerá tras cotejar los registros del emisor, del destinatario y de los intermediarios.
Cronología de la red
La cronología se reúne en esta pestaña; el historial local se guarda 15 minutos como máximo.
Cada punto es un mensaje cotejado con los registros firmados de todos los nodos de la ruta. La hora procede de los registros de los propios nodos. El observador entrega las últimas 24 entregas. La pestaña conserva los registros vistos 15 minutos como máximo; el gráfico muestra los últimos 3 minutos. Al cerrar la pestaña se pierde este historial local. Las firmas verifican los saltos mostrados, pero no que el registro esté completo. Pulsa un punto para examinar el mensaje.
Qué causó qué
Cadena de la última desconexión según los registros firmados. Pulsa un paso para abrir el registro o el mensaje. El tiempo se cuenta desde el registro de la desconexión, según los relojes de los propios nodos.
Mensajes entregados
Quién elige la ruta
Cada fila es una decisión del propio nodo, tomada de su registro firmado. No hay un despachador central.
Cómo la red superó el fallo
Qué se verificó en máquinas reales
¿En qué se diferencia este experimento del internet habitual?
se deriva de la clave pública. No lo asigna ningún registrador; el destinatario sigue siendo el mismo en toda la ruta.
Los vecinos intercambian anuncios firmados: es un . Cada nodo elige la ruta disponible más corta; la información antigua sobre un vecino desaparecido caduca.
Las tramas propias con tipo 0x88B5 viajan por Ethernet. En los datos y en los anuncios de rutas no hay IPv4, IPv6, TCP, UDP ni DNS. solo indica el siguiente vecino.
Los SO de estas VM conservan una IP administrativa. SSH y la página de observación usan IP. Los necesita el operador; los agentes siguen intercambiando datos con el panel desconectado.
Son cinco VM admitidas de antemano en tres hosts físicos, con un solo operador y en un solo centro de datos. En los invitados se observan tramas Ethernet; la configuración de la red subyacente entre hipervisores no se ha confirmado por separado. El registro blockchain y las políticas BCP no están implementados en este Mesh. Es un modo aparte: el experimento strict-LLM registrado usa tres invitados en tres hosts, dos modelos locales y núcleos invitados sin INET/IPv6. Aquí funcionan agentes sintéticos sin LLM. La versión del banco en vivo figura en el pie de página; la fecha de la aceptación guardada, en la sección «Qué se verificó en máquinas reales». Verificamos la entrega y el enrutamiento propios, pero aún no una red global, la admisión automática de nodos desconocidos ni la resistencia a la sobrecarga.
A y B conservan las claves de la etapa anterior. R1 desconecta el enlace de transmisión real durante 60 segundos; la gestión de servicio sigue disponible y después el enlace se reactiva automáticamente. Las reglas de las máquinas invitadas prohíben la ruta directa A↔B.
Tareas en una red grande
Qué se ha entregado ya con tramas reales y dónde la arquitectura actual choca con la escala.
- Documentos
- reales
- Agentes
- programas, sin modelo de lenguaje
- Operador
- uno
- Dónde se midió
- experimento aparte en una VM del proyecto Relcom
- Medición y cálculo
- se muestran por separado
- Datos
- resultados guardados · las cinco máquinas en funcionamiento están en el banco en vivo
Cargando los informes de las pruebas realizadas…
16 agentes ejecutan tu tarea Medido
Cada círculo es un proceso independiente con su propia clave y su tabla de rutas. Los 16 procesos funcionan en una sola máquina física, en una red aislada sin IP. La línea resaltada es la ruta confirmada de la tarea. Las etiquetas iguales H… o V… en bordes opuestos indican un único salto entre los vecinos extremos, sin pasar por los nodos intermedios.
Cuánto esperaron las tareas
Fuente del gráfico: ejecución medida en una VM de Relcom; procesamiento de dos artículos públicos. Cada punto es el número de resultados correctos recibidos.
Se introdujeron un retardo de 4 ± 1 ms, una pérdida del 0,02% de las tramas y la desconexión del enlace real N05 durante unos 10 segundos. La primera ejecución reveló una dirección IPv6 automática en el puente y no pasó la verificación. Se guarda por separado. El segundo experimento detectó tráfico de servicio del puente y dos fallos por un error en el plazo de la tarea. Tras las correcciones se hizo una nueva ejecución; ambos resultados anteriores se conservan.
Hasta 2 048 agentes: cálculo de una red posible Simulación
Es una simulación, no 2 048 agentes en ejecución. Detrás de cada enrutador simulado hay ocho agentes lógicos. La carga, las pérdidas, el ancho de banda y las colas se fijan explícitamente; los resultados no prometen la misma velocidad en una red real.
Los 36 cálculos
Proporción de tareas completadas a lo largo del tiempo: fila = condiciones, columna = tamaño de la red, tres líneas = tres . La línea discontinua es el límite de 60 segundos. Pulsa una celda para abrir el cálculo más abajo. Ahora el protocolo funciona como máximo con 16 nodos y 7 saltos, así que 64 y 256 son un cálculo para una versión que aún no existe.
Cada nodo toma la siguiente decisión según su propia tabla. Las tablas se obtienen del intercambio entre vecinos; no se usa ningún servicio central de rutas. La ruta resaltada procede de un cálculo terminado. Las etiquetas iguales H… o V… en bordes opuestos son un único salto entre los vecinos extremos.
La conclusión más importante: ampliar sin más la lista de ID clave no hace global el protocolo. Hacen falta anuncios de rutas compactos, un descubrimiento de servicios aparte, control de congestión y pruebas en redes independientes. La simulación muestra el coste de estas limitaciones, no las elimina.
¿Y los demás agentes ya se han pasado? Revisión de fuentes
Operadores externos consultados: 0. Se recibieron dos dictámenes independientes de agentes Codex aislados en el mismo servicio. No ven el transporte en el que se ejecutan y no pueden confirmar el paso a IPvX. No se encontró ningún nodo externo accesible con telemetría verificable.
Abajo, documentos primarios verificados a 27 de octubre de 2026. Es una revisión de protocolos, no una estadística de implantaciones. Esta revisión no contiene confirmaciones de un paso masivo de la IA a una red native sin IP.
Pruebas firmadas
Cada etapa es un bundle. Los bundles están firmados con la clave del laboratorio y anotados en un registro de Merkle.
- Bundle
- archivos de informes con SHA-256, commit de la release y assets de GitHub
- Firma
- clave del laboratorio
- Registro
- árbol de Merkle
- Quién verifica
- tu navegador, no el servidor
Cargando el registro y verificando las firmas…
Qué prueba esto y qué no
Prueba la integridad y el orden: un bundle no se puede modificar, quitar ni reordenar sin romper la firma o la prueba de consistencia. Quien haya guardado una cabeza anterior del registro verá cualquier historia reescrita.
No prueba una hora independiente ni un testigo independiente: la clave y el registro están en manos de un solo laboratorio, y las fechas son su propia declaración. El siguiente paso es anclar las cabezas donde el laboratorio no controla nada; esto mismo es la comparación del registro con la blockchain para H11.
Verificar los archivos por tu cuenta
El navegador no descarga los informes. Un comando en un clon del repositorio verifica las firmas, el árbol y el SHA-256 de cada archivo:
python -m ipvx_agent_lab.evidence verify
Dos agentes. Intercambio directo.
Cada agente vive en su propia máquina y envía él mismo los mensajes a su interlocutor. El ID se mantiene al cambiar de IP.
- Etapa
- 2 · cerrada: en estas máquinas funciona la etapa siguiente · abrir la red sin IP
- Red
- TCP/IP real · red interna del banco
- Nombres
- DNS desactivado en los agentes
- Datos
- sintéticos
- Agentes
- programas, sin modelo de lenguaje
- Máquinas
- dos VM en hosts físicos distintos · un operador
Agentes y entrega
Esperando la confirmación de entregaConexión TCP directa · red interna del banco · tramo conmutado
El observador, en un tercer host físico, lee los registros firmados de ambas VM. Los mensajes entre agentes no pasan por él.
Mensajes entregados
Se muestran los mensajes con registros coincidentes de ambos lados. Elige una fila para verificar la ruta.
Direcciones y eventos
Verificaciones en dos máquinas
¿Quién traza la ruta cuando hay muchos agentes?
El ID responde a «quién»; la IP, a «dónde»
En este experimento A conoce de antemano el ID público y la primera dirección de B. Cuando B cambia de dirección, firma un nuevo registro y se lo envía él mismo a A. A verifica la firma y la versión, guarda la nueva dirección y abre una conexión directa.
A gran escala, la búsqueda inicial puede repartirse entre muchos nodos. Guardan partes del directorio ID → direcciones, con copias y cachés. La búsqueda hace falta antes de conectar o tras perder una dirección, no para cada mensaje. Ese sistema de búsqueda aún no está implementado en este piloto directo.
Los paquetes los entrega la red IP existente. Sus enrutadores trabajan con prefijos de red; no necesitan un registro aparte para cada agente. Las colas, los límites de solicitudes y las réplicas de agentes resuelven otro problema: la sobrecarga de cálculo.
Renunciar a IP significaría desarrollar una red de enrutamiento propia. Ahora verificamos un ID independiente y el intercambio directo sobre TCP/IP. Si ambos agentes pierden a la vez todas las direcciones conocidas del otro, esta etapa no prevé la recuperación.
Límites del experimento
Dos VM en hosts físicos distintos · un operador y un centro de datos. La mudanza cambia la IP de escucha dentro de una misma VM; la gestión se queda en la dirección anterior. El botón solo inicia el cambio de dirección; el aviso al interlocutor lo hace el propio agente.
Internet para agentes
Un agente encuentra datos, recibe permisos limitados y pasa la tarea a un analista. Observa el avance de la tarea y los motivos de las decisiones.
- Etapa
- 1 · en el archivo de etapas · trabajo actual: BCP 0.2
- Datos
- sintéticos
- Operador
- uno
- Agentes
- programas, sin modelo de lenguaje
- Ejecución
- solo los operadores del banco · se muestra la última guardada
Ruta de la tarea
Eventos de la ejecución real
Propietario de la tarea
Agente personal
Tres resolvedores
Fuente de datos · MCP
Analista · A2A
Nuevo punto de conexión
El ID responde a «¿quién?». El resolvedor, a «¿dónde está ahora?». El permiso, a «¿qué puede hacer?».
Registro de eventos
0 eventosLos eventos aparecerán tras la ejecución. Cada fila abre la explicación y los datos observados.
Qué verificamos
Conservación del ID al mudarse, verificación de firmas, límites de los permisos y comportamiento ante fallos.
Hipótesis y pruebas
El veredicto se refiere a una ejecución concreta. Un resultado parcial deja preguntas abiertas.
- Etapa
- 1 · en el archivo de etapas · trabajo actual: BCP 0.2
- Fuente
- última ejecución guardada del banco /1
- Dirección de la hipótesis
#hypotheses/H5
Resultado de la ejecución
Todas las hipótesis
Conectar tu agente
La biblioteca cliente de Python resuelve un ID firmado mediante tres resolvedores, verifica el registro y guarda la versión conocida. El acceso a los datos requiere un permiso aparte del propietario.
- Etapa
- 1 · en el archivo de etapas · trabajo actual: BCP 0.2
- Idioma
- Python
- Confianza
- la fija el operador, no la biblioteca
Ejecución local
git clone https://github.com/relcom-technologies/ipvx-agent-lab cd ipvx-agent-lab python3 -m venv .venv source .venv/bin/activate pip install -e '.[test]' ipvx-lab local
Abre http://127.0.0.1:8080. El comando levanta siete procesos independientes. La instalación desde el repositorio cerrado requiere acceso a GitHub.
Llamada desde Python
from ipvx_agent_lab import AgentClient, invocation
with AgentClient(
resolver_urls, # tres direcciones de resolvedores
checkpoints={agent_id: (2, 3)},
state_file=".state/known-versions.json",
allowed_origins={"https://your-agent.example"},
) as client:
profile = client.resolve(agent_id)
result = client.invoke(
profile,
invocation(permission_chain, subject_key, "read"),
)Las direcciones de los resolvedores, la versión inicial de confianza, los nodos permitidos y la cadena de permisos los fija el operador. La biblioteca no decide por el propietario en quién confiar.
Verificar automáticamente
ipvx-lab run --scenario full --output reports/full.json pytest -q
Protocolo experimental
Versión 1 · aprobada por el propietario del proyecto el 26 de octubre de 2026.
- Etapa
- 1 · en el archivo de etapas · trabajo actual: BCP 0.2
- Base de IPvX
218bf93
Qué funciona en el banco
Generación local del ID, perfil firmado, búsqueda por capacidad, de dos de tres resolvedores, permisos estrechos y protección contra la ejecución repetida. La mudanza cambia el punto de conexión y conserva la identidad.
Qué cuenta como prueba
Los escenarios envían solicitudes HTTP a procesos independientes. Cada verificación guarda la condición, el resultado observado y la hora. Los registros SQLite y los informes exportados se conservan tras un reinicio.
Límites del experimento
- Un host físico y un operador. Los procesos independientes no prueban la independencia de los operadores.
- Los agentes aplican reglas fijadas sobre datos sintéticos. No hay ningún modelo de lenguaje conectado.
- MCP 2025-06-18 y A2A 0.3.0: se verifican adaptadores limitados. La compatibilidad con implementaciones externas aún no está certificada.
- El primer contacto requiere un punto de confianza reciente. La firma por sí sola no garantiza la frescura ni la calidad del resultado.
- Si la fuente de revocación no está disponible, se permite una ventana de caché de hasta 3 segundos; después, rechazo. El cambio de reloj es un fallo lógico introducido explícitamente.
- La blockchain y la implantación por equipos externos aún no se han verificado.
Base de IPvX fijada
218bf93acb842604167c93144e5bc967b70ecb6aLa regla de quórum procede de esta versión. Los perfiles de agentes y los permisos son un protocolo experimental nuevo.
Leer el protocolo completo ↗