# 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/`:

| Contrato | Contenido y autorización |
|---|---|
| ReceiverNodePolicy | receiver/node/policy epoch, store ID, pins admin Ed25519/umbral, issuer thumbprints prohibidos, hash exacto del bootstrap y contexto AN01, expiración y floor de bootstrap epoch. Provisionado localmente, nunca desde email/discovery. |
| NodeBootstrap | Scope y epoch, chain ID Bor 80002, genesis block hash, chain ID Heimdall, parent 11155111, releases/commits/hashes binary/config/genesis, versiones RPC esperadas, enlaces entre procesos, endpoints/pins, checkpoints Bor/Heimdall/trusted_until, vigencia y límites. |
| SignedBootstrap | Envelope de quórum con payload JCS y protected JCS; payload decodificado debe cumplir NodeBootstrap. |
| AnchorContext | Dirección, G/T/I, publisher/guardian, runtime hash y ubicación/creation-input del despliegue. Derivado de AN01 previamente aceptado y fijado por política local. No autentica por sí mismo el binding del issuer. |
| AnchorReadRequest | Tx/log index y secuencia/C/previous_C. Son coordenadas no confiables, nunca endpoints ni autoridad. La comprobación AS/P1 completa sigue siendo requisito separado. |
| NodeView | Bloques/cortes, anchor_id, estado bajo hash, budgets/deadline/floor revision y resultado de consistencia. No transporta una proof portable de consenso ni habilita PASS. |
| common | Hashes/enteros/IDs y refs explícitas a envelopes/pins AS01. |

```text
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](https://xcim.org/standardization/nb01/upstream-sources.json) 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](https://docs.polygon.technology/pos/concepts/finality/finality/)
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](https://github.com/0xPolygon/heimdall-v2/blob/ced0710a3f6e269b8d5e996eb7d2b740fd9f80c5/proto/heimdallv2/milestone/query.proto)
y [milestone.proto](https://github.com/0xPolygon/heimdall-v2/blob/ced0710a3f6e269b8d5e996eb7d2b740fd9f80c5/proto/heimdallv2/milestone/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](https://xcim.org/standardization/nb01/DEPENDENCIES.md). No se emitió una transacción Amoy,
se aprovisionó una confianza real ni se contactó IETF/IANA.