Conceptos clave

Estos son los conceptos que encontrarás por todas partes en CORE-M. Cada uno se apoya en el anterior, así que leer de arriba abajo es la forma más rápida de entrar en materia. Cuando un concepto tiene una sección propia, sigue el enlace para ver el tratamiento completo.

Tenant

Un tenant es una cuenta de cliente aislada. Cada registro en CORE-M — dispositivos, telemetry, reglas, proofs — está acotado a un tenant_id, y el aislamiento se aplica en cada capa, desde el servicio de autenticación hasta las claves de almacenamiento. Un único despliegue de CORE-M atiende a muchos tenants sin que sus datos se mezclen nunca. Consulta Autenticación y multitenancy.

Dispositivo

Un dispositivo es una pieza de hardware registrada (o un agente de software) que envía telemetry. El device-registry guarda su registro — nombre, estado, versión de firmware, grupos, etiquetas y configuración — y un dispositivo se autentica con una clave de API, una PSK o un certificado X.509. Consulta Conectar dispositivos.

device_id frente a hardware_id

Estos son deliberadamente distintos.

• device_id es el identificador propio de CORE-M para un dispositivo — la clave que usas en la API, en la telemetry y en los proofs. Es estable durante toda la vida del dispositivo en la plataforma.
• hardware_id es la identidad física del dispositivo (un número de serie, MAC o IMEI) registrada como metadato.

Mantenerlos separados significa que puedes reemplazar o reprovisionar hardware sin romper el registro histórico ligado a un device_id, y puedes buscar un dispositivo por su identidad de plataforma o por la física. Consulta Identidad del dispositivo.

Telemetry point y métrica

Un telemetry point es una lectura de un dispositivo en un instante. Lleva el device_id, el tenant_id, una marca de tiempo y un conjunto de valores con nombre — numéricos o de cadena. Cada valor con nombre es una métrica (por ejemplo temperature o status). Un único point puede por tanto reportar varias métricas medidas en el mismo instante.

Precaución

Cuando un point se convierte en hash para el anchoring, su marca de tiempo se trunca a segundos enteros. Los nanosegundos se descartan para que un verificador externo — que quizá solo tenga precisión de segundos — pueda reproducir exactamente el mismo hash. Ten esto en cuenta siempre que calcules un hash para verificar.

Consulta Enviar telemetry.

Anchor batch

Anclar un point por transacción de blockchain sería lento y costoso, así que CORE-M los agrupa. Un anchor batch es una colección de hashes de telemetry-point acumulados durante una ventana corta. El batch entero se compromete a la cadena en una sola transacción, amortizando el coste entre todos los points que contiene. Consulta Anchoring.

Merkle proof

Los hashes de un batch se organizan en un Merkle tree, cuyo único root hash resume el batch completo. Solo ese root de 32 bytes va on-chain. Un Merkle proof (o Merkle path) es la breve lista de hashes hermanos que permite a cualquiera recalcular el root a partir de un único dato — demostrando que este point exacto formaba parte de aquel batch anclado, sin necesitar los demás points. Consulta Merkle proofs.

Finality

Una transacción de anchoring difundida no es permanente al instante. La finality es el punto en el que una transacción confirmada se considera irreversible — por defecto tras 6 confirmaciones de bloque, configurable por tenant o por perfil de dispositivo. Antes de la finality un point está anclado pero todavía es provisional; el servicio chain-anchor rastrea las confirmaciones y gestiona el raro caso de un reorg de cadena que invalidaría una transacción aún no final. Consulta Finality y reorgs.

Ciclo de vida del proof

Cada telemetry point aceptado recorre un ciclo de vida del proof explícito, y la plataforma registra su estado en cada paso:

1. Pending — aceptado y convertido en hash, a la espera de ser agrupado y difundido.
2. Anchored — incluido en un batch cuya transacción ha sido difundida a la red BSV.
3. Confirmed — la transacción ha sido minada en un bloque.
4. Final — la transacción ha alcanzado el umbral de finality; el proof se archiva en PostgreSQL y puede exportarse como un paquete portátil.

Este ciclo de vida es la columna vertebral de la garantía de integridad: un point solo se considera plenamente demostrable una vez que es final. Consulta Ciclo de vida del proof y Verificación.