💻 computer science

MultiChain Blockchain Data Provenance for Deterministic Stream Processing with Kafka Streams: A Weather Data Case Study

Este artículo propone una arquitectura de procedencia respaldada por MultiChain para Kafka Streams que garantiza un procesamiento de datos meteorológicos en tiempo real determinista, auditable y reproducible al anclar raíces de Merkle criptográficas de datos en ventanas a la cadena de bloques mientras se mantienen las cargas útiles fuera de la cadena.

Autores originales: Niaz Mohammad Ramaki, Florian Schintke

Publicado 2026-01-27

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Niaz Mohammad Ramaki, Florian Schintke

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás viendo una transmisión de noticias en vivo sobre el clima en Berlín. Cada pocos minutos, el presentador de noticias (el sistema informático) anuncia la temperatura promedio de la última hora.

El Problema: El "Truco de Magia" de la TV en Vivo
Normalmente, el procesamiento de datos en vivo es un poco como un truco de magia. La computadora recibe miles de lecturas de temperatura, las mezcla y lanza un promedio. Pero debido a que la computadora es muy rápida y el internet a veces es inestable, el orden en que llegan los datos puede cambiar.

Si le pidieras a la computadora que hiciera exactamente el mismo cálculo dos veces, podría darte dos respuestas ligeramente diferentes.

Ejecución 1: La computadora ve tres lecturas de temperatura y dice: "El promedio es 21.0 °C".
Ejecución 2: Debido a un pequeño retraso en la red, una cuarta lectura llega una fracción de segundo después. La computadora la pone en un "cubo" (ventana de tiempo) diferente y dice: "El promedio es 21.75 °C".

Esto hace que sea imposible para un auditor decir: "Sé con certeza que la computadora calculó esto correctamente", porque el resultado cambia cada vez que reproduces la cinta. Es como intentar verificar un problema matemático donde los números se reordenan constantemente.

La Solución: El Sistema del "Sobre Sellado"
Los autores de este artículo construyeron un sistema para solucionar esto utilizando dos herramientas principales: Kafka Streams (la computadora que hace las matemáticas) y MultiChain (un libro de contabilidad digital especial e inalterable, como una cadena de bloques o blockchain).

Así es como funciona su sistema, paso a paso, usando una analogía simple:

1. Los "Cubos de Tiempo Fijos" (Ventaneo Determinista)

En lugar de dejar que la computadora decida cuándo dejar de contar y comenzar un nuevo promedio basándose en cuándo recibe los datos, el sistema utiliza cubos de tiempo fijos.

Analogía: Imagina una cinta transportadora de una fábrica que se detiene exactamente cada 2 horas, sin importar qué.
Cómo funciona: Ya sea que los datos lleguen a la 1:59 PM o a las 2:01 PM, el sistema los fuerza a entrar en el cubo de "1:00 PM a 3:00 PM". Esto asegura que cada vez que ejecutes el cálculo, el mismo conjunto de datos entre en el mismo cubo exacto.

2. La "Receta Estandarizada" (JSON Canónico)

Incluso si los datos están en el mismo cubo, las computadoras a veces pueden escribir las cosas de manera diferente (por ejemplo, "10:00:00" frente a "10:00").

Analogía: Imagina a un chef que insiste en que cada ingrediente debe ser anotado con la misma caligrafía y en el mismo orden antes de ser puesto en la olla.
Cómo funciona: El sistema toma cada registro de temperatura y lo reescribe en un formato estricto y estandarizado. Esto garantiza que los datos luzcan idénticos cada vez que se procesan.

3. El "Sello de Cera Digital" (Árboles de Merkle)

Ahora que los datos están en un cubo fijo y escritos en un formato estandarizado, el sistema necesita demostrar que los datos no han sido manipulados.

Analogía: Imagina que tienes una pila de recibos. En lugar de guardar toda la pila en una caja fuerte, los conviertes en un "hash" (los transformas en una huella digital única) y los organizas en una pirámide. Luego, tomas el número de la parte superior de la pirámide —la Raíz de Merkle— y la sellas en un sobre de cera.
Cómo funciona: El sistema crea una "Raíz de Merkle" para todas las temperaturas en ese cubo de 2 horas. Esta raíz es un código único y diminuto que representa a todo el grupo de datos. Si incluso una temperatura cambia, el código cambia por completo.

4. El "Libro de Registro Inalterable" (Anclaje en Blockchain)

Aquí es donde ocurre la magia. El sistema no pone los datos pesados y desordenados de la temperatura en la blockchain (eso sería demasiado lento y costoso).

Analogía: Guardas los recibos pesados en un cajón (almacenamiento fuera de la cadena o off-chain), pero escribes el Número de Sello (la Raíz de Merkle) y el Número de Página en un diario público e inalterable (la blockchain).
Cómo funciona: El sistema escribe la Raíz de Merkle y los "números de página" (offsets de Kafka) en la blockchain de MultiChain. La blockchain actúa como un testigo permanente e inalterable.

5. La "Verificación del Auditor" (Verificación)

Ahora, imagina que un auditor quiere comprobar si el informe meteorológico era correcto.

Consulta el Diario (Blockchain) para ver cuál era el "Número de Sello" para ese intervalo de tiempo.
Va al Cajón (Almacenamiento fuera de la cadena) y saca los recibos reales (los datos de temperatura).
Vuelve a ejecutar la "Receta Estandarizada" y el cálculo del "Sello de la Pirámide".
El Resultado: Si el nuevo Número de Sello coincide con el que está en el Diario, se demuestra que los datos son 100% auténticos y completos. Si no coincide, alguien manipuló los recibos.

Los Resultados
Los autores probaron esto con estaciones meteorológicas reales en Berlín. Encontraron que:

Reproducibilidad: Podían ejecutar el cálculo en dos computadoras diferentes y producía exactamente el mismo resultado cada vez.
Velocidad: Comprobar las matemáticas (verificación) era muy rápido, incluso con muchos datos.
Eficiencia: La blockchain no se saturó porque solo almacenaba los diminutos "Números de Sello", no los datos pesados.

En Resumen
Este artículo presenta una forma de hacer que los flujos de datos en vivo sean "confiables". Al bloquear los datos en cubos de tiempo fijos, estandarizar el formato y sellar los resultados en un sobre digital registrado en una blockchain, permiten que cualquiera pueda verificar de forma independiente que un cálculo en vivo (como un promedio del clima) es matemáticamente correcto y no ha sido falsificado o alterado.

Resumen Técnico: Procedencia de Datos Multicadena en Blockchain para el Procesamiento de Flujos Deterministas con Kafka Streams

1. Planteamiento del Problema

Los canales de procesamiento de flujos de datos en tiempo real, como los construidos sobre Kafka Streams o Apache Flink, enfrentan desafíos críticos relacionados con la auditabilidad y la reproducibilidad. Estos sistemas son inherentemente no deterministas debido a dependencias en la programación de ejecución (scheduling), disparadores de ventanas (window triggers), la latencia de red y el orden de llegada de los registros. En consecuencia, flujos de entrada idénticos procesados en diferentes momentos o en diferentes nodos pueden generar salidas distintas.

Las soluciones actuales de procedencia basadas en blockchain suelen depender de cadenas de hashes para almacenar huellas digitales de los datos. Sin embargo, los autores identifican dos desventajas principales en este enfoque para el procesamiento de flujos:

Sobrecarga de Almacenamiento: A medida que la cadena crece, los requisitos de almacenamiento aumentan significamente.
Costo Computacional: La verificación requiere el hashing repetido de cadenas largas, lo cual es ineficiente para grandes conjuntos de datos.
Además, las cadenas de hashes vinculan la procedencia al orden de ingestión, lo que las hace inadecuadas para la reproducción determinista bajo ventanas basadas en tiempo o re-clave (re-keyed) donde la membresía de los registros cambia debido a factores externos (por ejemplo, el rebalanceo).

2. Metodología

El artículo propone una arquitectura de procedencia respaldada por blockchain que desacopla las cargas útiles de datos pesadas del blockchain, almacenando únicamente anclajes criptográficos y metadatos. El sistema se implementa utilizando Kafka Streams para el procesamiento y MultiChain (un blockchain con permisos) para el anclaje.

Componentes Centrales y Flujo de Trabajo

Ingestión y Procesamiento:
- Datos meteorológicos en tiempo real de dos estaciones (Berlin-Brandenburg y Berlin-Tempelhof) se ingieren vía Kafka.
- El sistema utiliza ventanas de tipo tumbling alineadas con épocas (epoch-aligned tumbling windows). A diferencia de las ventanas de tiempo de procesamiento, estas son intervalos absolutos fijos (por ejemplo, bloques de 2 horas que comienzan en tiempos de época específicos) para garantizar un determinismo global independientemente de los retrasos de ingestión.
- Dentro de cada ventana, los registros se agregan (mínimo, máximo, promedio de temperaturas).
Canonicidad Determinista:
- Para eliminar la no determinación causada por el orden de los registros, el sistema aplica JSON Canónico (Canonical JSON) a todos los registros dentro de una ventana.
- Este proceso implica la eliminación de campos inconsistentes, la normalización de marcas de tiempo a UTC (ISO-8601) y el ordenamiento lexicográfico de las claves de los objetos.
- Posteriormente, los registros se deduplican.
Construcción del Árbol de Merkle:
- En lugar de una cadena de hash lineal, el sistema construye un Árbol de Merkle a partir de los registros canonicalizados.
- Los nodos hoja son hashes SHA-256 de los registros canónicos.
- Los nodos internos son hashes de la concatenación de los nodos hijos.
- La Raíz de Merkle (Merkle Root) final sirve como un compromiso criptográfico compacto de toda la carga útil de la ventana.
Anclaje en Blockchain (Checkpoints):
- La carga útil completa permanece fuera de la cadena (off-chain) (almacenada en un sistema de archivos distribuido como NDJSON).
- Se publica un checkpoint que contiene la Raíz de Merkle, los límites de desplazamiento de Kafka (offsetStart, offsetEnd), el recuento de registros, la ruta de la carga útil y el hash de la carga útil en un stream de MultiChain.
- Se eligió MultiChain por sus características de stream de clave-valor de solo adición (append-only) y su naturaleza con permisos, evitando la complejidad de los contratos inteligentes en favor de la lógica de aplicación externa.
Verificación:
- Un auditor independiente puede verificar la integridad de una ventana mediante:
  1. Recuperar los metadatos del checkpoint (Raíz de Merkle $R$ y recuento de registros $N$ ) desde el blockchain.
  2. Cargar la carga útil fuera de la cadena (off-chain).
  3. Re-canonicalizar los registros y recomputar la Raíz de Merkle ( $\hat{R}$ ) y el recuento de registros ( $\hat{N}$ ).
  4. Comparar $\hat{R}$ con $R$ y $\hat{N}$ con $N$ . La verificación es exitosa solo si ambos coinciden.

3. Contribuciones Clave

Procedencia de Ventanas Deterministas: La introducción de un método para crear ventanas de flujo reproducibles utilizando límites alineados con la época y serialización canónica, resolviendo la no determinación inherente al procesamiento de flujos estándar.
Árbol de Merkle sobre Cadenas de Hash: Un cambio de cadenas de hash lineales a árboles de Merkle para la procedencia de ventanas, reduciendo la complejidad de verificación de lineal a logarítmica respecto al número de registros.
División On-Chain/Off-Chain: Una arquitectura escalable donde las cargas útiles grandes y mutables se almacenan fuera de la cadena (off-chain), mientras que los anclajes criptográficos inmutables (raíces de Merkle) y los metadatos se almacenan en la cadena (on-chain), evitando la saturación del blockchain.
Auditabilidad Independiente: Un marco que permite a terceros auditores verificar la integridad y corrección de analíticas derivadas (por ejemplo, promedios de temperatura) sin necesidad de acceder al estado interno del motor de streaming.

4. Evaluación y Resultados

El sistema fue evaluado utilizando datos meteorológicos en tiempo real de Berlín.

Reproducibilidad: Ejecuciones independientes en diferentes hardware (MacOS M2 y M4) con Java 21 produjeron resultados de bytes idénticos para el JSON canónico, el hash SHA-256 de la carga útil y las raíces de Merkle, confirmando la eliminación de la no determinación inducida por el entorno.
Costo de Verificación:
- El tiempo de verificación de extremo a extremo ( $T(n)$ ) escala linealmente con el número de registros ( $n$ ), siguiendo el modelo $T(n) = \alpha n + \beta$ .
- El sistema demostró un alto rendimiento (registros por segundo) durante la verificación, sin colapso en el rendimiento a medida que aumentaban los tamaños de las ventanas.
- Los costos de canonicalización y hashing mostraron un escalamiento lineal, y la construcción del árbol de Merkle se mantuvo cerca de lo lineal.
Rendimiento de Blockchain:
- El checkpointing en el mundo real resultó en un bajo TPS (Transacciones Por Segundo) (0–0.015 ítems/s) debido a la naturaleza infrecuente del cierre de ventanas en comparación con las tasas de eventos brutos.
- Las pruebas de rendimiento con publicadores paralelos mostraron que MultiChain puede manejar un TPS más alto (hasta ~2.1 tx/s para cargas pequeñas), pero alcanza un punto de saturación (alrededor de 8 trabajadores) debido a su algoritmo de consenso round-robin.

5. Significado y Reivindicaciones

El artículo afirma que su diseño permite a auditores independientes verificar tres aspectos críticos del procesamiento de flujos:

La completitud de las cargas útiles de las ventanas (asegurando que no se hayan perdido ni añadido registros).
La serialización canónica de los datos (asegurando un procesamiento determinista).
La corrección de las analíticas derivadas (por ejemplo, verificando que un promedio de temperatura reportado es matemáticamente consistente con los registros subyacentes).

Los autores posicionan este trabajo como una solución a la "brecha de auditabilidad" en el procesamiento de flujos moderno. Al combinar el particionamiento de ventanas determinista con el anclaje criptográfico, el sistema permite la re-procesación reproducible de flujos de datos, una capacidad que actualmente falta en las plataformas de streaming estándar. El artículo señala modestamente que, aunque resuelve la integridad y la auditabilidad, aún no aborda el significado semántico de los datos (requiriendo trabajo futuro con RDF) ni las preocupaciones de privacidad (sugiriendo pruebas de conocimiento cero como una dirección futura). Concluye que el blockchain puede integrarse con éxito con las plataformas de streaming para proporcionar una capa de referencia confiable e inmutable para la procedencia de los datos.