NB01-F01: receiver node and authenticated bootstrap

NB01-F01 — contratos de nodo y bootstrap Amoy

Fecha: 2026-10-19. Implementación de desarrollo del nodo receiver previsto en N5; sin cierre G06-M/O ni bootstrap Amoy instalado. Los formatos/versiones son artefactos de proyecto; no son registros IANA ni una especificación IETF adoptada.

1. Frontera de confianza y alternativas

Recomendación: nodo Bor/Heimdall validador de ejecución/consenso, operado por el receiver. El quórum administrador del receiver admite nodo, red, software, configuración, checkpoints y canales. El issuer sigue autenticando su binding AN01; no elige ni acredita los endpoints del receiver. La política local prohíbe reutilizar los thumbprints issuer declarados para el rol receiver_node_admin.

Alternativas: socket Unix con identidad/provenance de proceso; gateway TLS local con certificado fijado; nodo remoto con admisión/canales equivalentes; cliente ligero que verifica consenso/pruebas portables. Esta revisión implementa el cliente para un gateway HTTPS numeric loopback con pin DER, por su uso desde Windows y Linux. No implementa el gateway ni instala los clientes. Dos RPC o un issuer que dice finalized=true no son bootstrap ni fallback de esta ruta.

La identidad del canal acredita el gateway admitido. Version strings, hashes de archivos y una firma administrativa no prueban por sí solos que el proceso en ejecución usa esos archivos ni que valida consenso. El operador debe comprobar y atestiguar esa vinculación, la topología Bor↔Heimdall, parent Sepolia, bootstrap de consenso y flags antes de admitir el servicio. Esa frontera operativa sigue abierta; el adaptador no es un light client CometBFT ni verifica firmas BFT.

2. Bootstrap autenticado

Siete schemas 2020-12 con IDs https://xcim.invalid/ietf/nb01/schemas/:

bootstrap_commitment = SHA-256(UTF8("XCIM-NB-01-BOOTSTRAP\0") || JCS(payload))
context_commitment   = SHA-256(UTF8("XCIM-NB-01-ANCHOR-CONTEXT\0") || JCS(context))
local_policy_hash    = SHA-256(UTF8("XCIM-NB-01-LOCAL-POLICY\0") || JCS(policy))

Hash transportado como base64url canónico sin padding. Pin/código/hash de bloque como hex lowercase 32 bytes; dirección hex lowercase 20 bytes. Firmas bootstrap: alg=Ed25519, typ=application/xcim-nb-bootstrap+jcs, kids exactos bajo pins receiver_node_admin, thumbprints distintos, umbral y vigencias de claves/política/ bootstrap/checkpoint. El hash debe coincidir con el pin previamente aceptado; no hay TOFU ni autoaceptación por una firma que se adjunta a sí misma.

La admisión compara hashes de archivos locales binary/config/genesis con el manifest. SHA-256 del archivo genesis no es el hash del bloque Bor 0: se fijan por separado. Checkpoints no se deducen del consenso del issuer ni del acuerdo de dos URLs. Receiver obtiene y contrasta sus anchors por un procedimiento aceptado, incluyendo trusted_until y assumptions de weak subjectivity/state sync. Cambiar pin/epoch/roots/endpoints/certificado requiere nueva admisión y migración de floors autorizada; esa migración no se automatiza en esta revisión.

Las versiones revisadas son Bor v2.10.3 (commit a16f123…) y Heimdall-v2 v0.12.2 (ced0710…). Provenance de la revisión fija archivos/SHAs. Son candidatos para comprobar compatibilidad, no una pareja de binarios ya instalada, auditada o admitida. No se descargaron ejecutables ni snapshots.

3. Transporte de sólo lectura

HTTPS directo, sólo 127.0.0.1 o ::1, puertos/path prefijos explícitos del bootstrap. SHA-256 de certificado DER comprobado después del handshake y antes de enviar HTTP. Es PKI por pin exacto: no fallback a CA, nombre DNS o nuevo certificado. Identidad/rotación se gobiernan por el bootstrap y su vigencia; esta política no usa la fecha/CA del certificado para sustituir esa admisión. No proxies de entorno, redirects, gzip, URLs externas ni credenciales en URLs.

Métodos Bor permitidos: eth_chainId, web3_clientVersion, eth_syncing, eth_getBlockByNumber/Hash, eth_getTransactionReceipt/ByHash, eth_getCode y eth_call. Comet: status/commit. REST: node_info y milestones/latest. No send/admin ni reintentos o proveedores alternativos. Respuestas JSON-RPC exigen ID exacto, versión 2.0/result sin error; JSON duplicado/floats/enteros inseguros se rechaza.

Presupuestos máximos de aceptación configurables a la baja: 2s por llamada, 10s totales de intento, 256 llamadas, 128 enlaces por recorrido, 1 MiB por respuesta/8 MiB acumulados, 120s por header y caché 30s; reloj acotado hasta 60s. Lecturas secuenciales en esta revisión. Error/límite/pruning/timeout/429 → sin positivo, sin latest/safe fallback. No se afirma que un nodo Amoy real cumpla estos presupuestos todavía. Los presupuestos rechazan resultados tardíos; no garantizan cancelación instantánea de un syscall o del scheduler. Un supervisor operativo sigue siendo necesario.

4. Corte Heimdall y finalidad Bor

La documentación Polygon describe milestones separados de checkpoints al parent y el tag Bor finalized. NB01 no convierte sus ejemplos basados en altura en una prueba de ancestry.

1. Verificar bootstrap/contexto/archivos antes de crear el transporte; abrir DB existente y rechazar cuarentena/cambio de política/bootstrap.
2. Comprobar chain ID, genesis Bor, client version y eth_syncing=false. Comet status debe tener red aceptada/catching_up=false y concordar con commit a H. node_info REST debe coincidir en versión app y red.
3. Consultar /milestones/latest con x-cosmos-block-height: H. Exigir que el servidor ecoe H mediante x-cosmos-block-height o grpc-metadata equivalente; ausencia o conflicto retira señal. El hash bytes del proto v2 usa base64 estándar con padding, no hex ni base64url. Es hash de Bor end_block, no root de un intervalo del perfil viejo.
4. Seleccionar F=milestone.end y comprobar número/hash del bloque recuperado; leer Q=tag Bor finalized. Exigir F≤Q y recorrer Q→F por parentHash. Si Bor avanzó respecto del corte H, no se mezclan sus headers con el estado de otro F.
5. Comprobar checkpoints y floors por hashes canónicos del nodo admitido y no regresión de H/F/Q. Para el evento recorrer F→B por parentHash, con la cota de 128 enlaces; una altura baja de otra rama no basta. Los checkpoints y el deployment históricos se confrontan con la vista canónica del nodo confiado, no con una proof portable desde genesis.
6. Receipt exitoso, tx/block/index/log exactos y removed=false, dirección/publisher, topics/data e ID N1 recalculados. Rechazar duplicidad/sustitución/encoding. Leer runtime y todos los getters mediante {blockHash:F,requireCanonical:true}: identidad/roles/halt/head/checkpoint exactos. Ninguna consulta a latest sustituye soporte EIP-1898.
7. Confrontar receipt de creación, dirección/bloque canónico, creation input y runtime esperados. Releer barreras Bor F por altura y commit Heimdall H; comprobar que el nuevo Q sigue descendiendo del Q inicial. Contradicción de bloques previamente finalizados → cuarentena persistida, no selección de rama.
8. Verificar deadline/budget/caché también después de escribir floors con CAS; devolver diagnóstico de consistencia, con consenso proof y PASS siempre false.

La API v2 y su semántica se revisaron en fuentes fijadas, incluyendo query.proto y milestone.proto. El eco de altura, formato, pruning y EIP-1898 deben comprobarse en el gateway y las versiones reales; la revisión de source no equivale a ejecutar los nodos.

5. Floors, resultados y reuso

SQLite mantiene hash de política, store/epoch, cortes Bor seleccionado/nodo y Heimdall, revisión CAS y cuarentena. Transacciones BEGIN IMMEDIATE + synchronous FULL; no decrementos ni hashes alternativos a igual altura. Inicialización es acción explícita del operador, sólo archivo nuevo. CLI no la hace. Ausencia, otra política o DB ilegible → sin positivo, sin reset. Cuarentena no se borra automáticamente; si falla persistirla se retira señal y se conserva latch en el objeto del proceso. Recuperación requiere intervención autenticada.

Esto no protege frente a rollback/borrado malicioso del disco, no acredita ACLs, proceso/gateway, clock ni snapshots y no es el store transaccional SMTP/MX. Un receiver real necesita protección/recuperación de esas dependencias.

NB01_NODE_CONSISTENCY_OK significa consistencia contra el servicio admitido. Siempre: consensus_proof_verified=false, can_assert_xcim_pass=false. El deadline de nodo intersecta headers Bor/Heimdall, bootstrap, checkpoint, admin y política; cache_remaining_ms usa reloj monotónico. El consumidor debe guardar su propia hora de adquisición y volver a comprobar todas las vigencias AS/AN/P1 al usarlo; un JSON exportado no conserva frescura ni reemplaza la identidad del canal.

No se transforma NodeView en la vista sintética AN01 ni se activa Proof P1. La integración con el verifier completo, binding/autoridad/permiso y commit SMTP es dependencia explícita. No se emitió una transacción Amoy, se aprovisionó una confianza real ni se contactó IETF/IANA.