Visión general del anchoring

CORE-M ancla cada punto de telemetría aceptado a la blockchain de BSV. La promesa es simple de enunciar y difícil de falsificar: cualquiera — incluido un auditor que no confíe en CORE-M — puede demostrar que un punto de datos concreto existió en un momento concreto y no ha sido alterado desde entonces. Esta página explica la garantía, el pipeline que la entrega, y la frontera criptográfica que mantiene la wallet separada de todo lo demás. Las páginas más detalladas cubren después cada etapa por completo.

Por qué anclar

Una plataforma de IoT tradicional almacena la telemetría en una base de datos. Si esa base de datos se edita — por un infiltrado, un atacante o un bug — no hay ninguna forma integrada de que una parte externa lo detecte. Los registros son tan fiables como el operador que los custodia, ni más ni menos.

CORE-M elimina ese requisito de confianza. Para cada punto aceptado calcula un hash SHA-256 canónico y compromete ese hash a la blockchain de BSV dentro de una salida OP_RETURN. Una vez que la transacción se mina, el commitment es inmutable. A partir de ese momento:

1. Evidencia de manipulación (tamper evidence) — cualquier cambio en los datos originales produce un hash distinto, que ya no coincide con el commitment on-chain.
2. Verificación independiente — cualquiera que disponga de los datos originales y la proof puede verificarla contra la blockchain pública, sin acceso a CORE-M.
3. Existencia en el tiempo — la posición del bloque en la cadena establece una cota inferior de cuándo existieron los datos.
4. Escala — un Merkle tree compromete miles de puntos con una sola transacción on-chain, de modo que el coste por punto se mantiene reducido.

Consejo

¿Nuevo en el vocabulario? Lee primero los Conceptos básicos y el Glosario — términos como anchor batch, Merkle proof y finality se usan a lo largo de toda esta sección.

Lo que haces tú, y lo que hace la plataforma

Tu parte es simple: defines una política de anchoring (el modo y el umbral de finality para un tenant o un perfil de dispositivo) y, cuando lo necesitas, verificas proofs. Nunca tocas una wallet, no financias nada ni gestionas tokens — CORE-M lo hace todo por ti.

Nota

La plataforma gestionada CORE-M financia y opera el anchoring en blockchain en tu nombre. Tú no gestionas wallets, tokens ni saldos de tesorería — defines la política de anchoring y verificas las proofs que CORE-M produce.

El pipeline de anchoring

Cada punto aceptado avanza por un ciclo de vida explícito, y CORE-M registra su estado en cada paso. El camino feliz va de accept → batch → anchor → confirm → final.

flowchart LR
  A([Telemetry point]) --> B[accepted\nhash + lifecycle record written]
  B --> C[validated\nwritten to telemetry stores]
  C --> D[pending_batch\nhash assigned to a batch]
  D --> E[anchored\nOP_RETURN tx broadcast, txid known]
  E --> F[confirmed\nblock inclusion observed]
  F --> G[final\nfinality depth reached]
  E -. retry .-> R[failed_retryable]
  R -.-> D
  R -. exhausted .-> T[failed_terminal]

En palabras:

• accepted — el punto pasó la autenticación y el parseo; existen su data_hash canónico y un registro durable del ciclo de vida de la proof. El punto no se reconoce al llamante hasta que ese registro está escrito.
• validated — la validación de dispositivo y perfil pasó y el punto se escribió en los almacenes de telemetría.
• pending_batch — el hash ha sido asignado a un batch de anchoring. Los batches se vacían al alcanzar un umbral de recuento (por defecto 1000 puntos) o una ventana de tiempo (por defecto 30s).
• anchored — la transacción de anchoring se difundió (broadcast) y su txid es conocido.
• confirmed — ARC o el SPV watcher observó la transacción en un bloque.
• final — la profundidad de confirmación alcanzó el umbral de finality configurado (por defecto 6). La proof es durable y exportable como un bundle portable.
• failed_retryable / failed_terminal — un fallo temporal programa un reintento; la plataforma los resuelve por ti. Un reorg que invalida una transacción confirmada devuelve los registros afectados a failed_retryable.

Hashing y Merkle trees El layout exacto en bytes del hash canónico, las reglas JCS y el payload del OP_RETURN.

Modos, SLA y finality Modos de anchoring, resolución de políticas, el ciclo de vida de la proof, finality y manejo de reorgs.

Para saber cómo un punto llega al servicio de anchoring en primer lugar, consulta Envío de telemetría.

A dónde ir después

Lee en orden

1. Hashing y Merkle trees — el commitment exacto.
   
2. Modos, SLA y finality — política y ciclo de vida.
   
3. Verificación — demuestra un punto de forma independiente.