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
Preguntas e ideas sobre BCP
BCP se debate en el foro de participantes; las propuestas para cambiar el documento pasan por los RFC y GitHub.
Abrir la categoría BCP en el foro