💻 computer science

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

Questo articolo propone un'architettura di provenienza supportata da MultiChain per Kafka Streams che garantisce un'elaborazione dei dati meteorologici in tempo reale deterministica, verificabile e riproducibile, ancorando le radici crittografiche di Merkle dei dati a finestra alla blockchain mantenendo i payload off-chain.

Autori originali: Niaz Mohammad Ramaki, Florian Schintke

Pubblicato 2026-01-27

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Niaz Mohammad Ramaki, Florian Schintke

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di guardare un telegiornale in diretta con le previsioni del tempo di Berlino. Ogni pochi minuti, l'annunciatore del telegiornale (il sistema informatico) annuncia la temperatura media dell'ultima ora.

Il Probleo: Il "Trucco Magico" della TV in Diretta
Di solito, l'elaborazione dei dati in tempo reale è un po' come un trucco di un mago. Il computer riceve migliaoli di letture di temperatura, le rimescola e restituisce una media. Ma poiché il computer è velocissimo e la connessione internet è talvolta instabile, l'ordine con cui i dati arrivano può cambiare.

Se chiedessi al computer di eseguire esattamente lo stesso calcolo due volte, potrebbe fornire due risposte leggermente diverse.

Esecuzione 1: Il computer vede tre letture di temperatura e dice: "La media è 21,0°C".
Esecuzione 2: A causa di un minimo ritardo di rete, una quarta lettura arriva un istante dopo. Il computer la inserisce in un "secchiello" (time window) diverso e dice: "La media è 21,75°C".

Questo rende impossibile per un auditor dire: "So con certezza che il computer ha calcolato correttamente", perché il risultato cambia ogni volta che si rigira la pellicola. È come cercare di verificare un problema matematico dove i numeri continuano a riorganizzarsi da soli.

La Soluzione: Il Sistema della "Busta Sigillata"
Gli autori di questo articolo hanno costruito un sistema per risolvere il problema utilizzando due strumenti principali: Kafka Streams (il computer che esegue i calcoli) e MultiChain (un registro digitale immutabile, simile a una blockchain).

Ecco come funziona il loro sistema, passo dopo passo, usando una semplice analogia:

1. I "Secchielli Temporali Fissi" (Windowing Deterministico)

Invece di lasciare che il computer decida quando smettere di contare e iniziare una nuova media in base a quando accade di ricevere i dati, il sistema utilizza dei secchielli temporali fissi.

Analogia: Immagina un nastro trasportatore di una fabbrica che si ferma esattamente ogni 2 ore, indipendentemente da tutto.
Come funziona: Che il dato arrivi alle 13:59 o alle 14:01, il sistema lo forza nel secchiello "dalle 13:00 alle 15:00". Questo assicura che ogni volta che esegui il calcolo, l'esatto stesso set di dati entri nello stesso identico secchiello.

2. La "Ricetta Standardizzata" (JSON Canonico)

Anche se i dati sono nello stesso secchiello, i computer possono talvolta scrivere le cose in modo diverso (ad esempio, "10:00:00" rispetto a "10:00").

Analogia: Immagina uno chef che insiste affinché ogni ingrediente venga annotato con la stessa identica grafia e nello stesso ordine prima di essere messo in pentola.
Come funziona: Il sistema prende ogni record di temperatura e lo riscrive in un formato rigoroso e standard. Ciò garantisce che i dati appaiano identici ogni volta che vengono elaborati.

3. Il "Sigillo di Cera Digitale" (Alberi di Merkle)

Ora che i dati sono in un secchiello fisso e scritti in un formato standard, il sistema deve dimostrare che non siano stati manomessi.

Analogia: Immagina di avere una pila di ricevute. Inveve di chiudere l'intera pila in una cassaforte, ne crei un hash (trasformandole in un'impronta digitale unica) e le disponi a forma di piramide. Poi prendi il numero in cima alla piramide — la Root di Merkle — e la sigilli in una busta di cera.
Come funziona: Il sistema crea una "Root di Merkle" per tutte le temperature in quel secchiello di 2 ore. Questa root è un singolo, minuscolo codice che rappresenta l'intero gruppo di dati. Se anche una sola temperatura cambia, il codice cambia completamente.

4. Il "Registro Immutabile" (Ancoraggio su Blockchain)

È qui che avviene la magia. Il sistema non inserisce i pesanti e disordinati dati della temperatura sulla blockchain (sarebbe troppo lento e costoso).

Analogia: Conservi le pesanti ricevute in un cassetto (archiviazione off-chain), ma scrivi il Numero del Sigillo (la Root di Merkle) e il Numero di Pagina in un diario pubblico e immutabile (la blockchain).
Come funziona: Il sistema scrive la Root di Merkle e i "numeri di pagina" (offset di Kafka) su blockchain MultiChain. La blockchain funge da testimone permanente e inalterabile.

5. Il "Controllo dell'Auditor" (Verifica)

Ora, immagina che un auditor voglia controllare se il rapporto meteorologico era corretto.

Consulta il Diario (Blockchain) per vedere quale era il "Numero del Sigillo" previsto per quella fascia oraria.
Va nel Cassetto (archiviazione off-chain) e tira fuori le ricevute effettive (i dati della temperatura).
Esegue nuovamente la "Ricetta Standardizzata" e il calcolo del "Sigillo a Piramide".
Il Risultato: Se il nuovo Numero del Sigillo corrisponde a quello presente nel Diario, i dati sono provati essere al 100% autentici e completi. Se non corrisponde, qualcuno ha manomesso le ricevute.

I Risultati
Gli autori hanno testato questo sistema con stazioni meteorologiche reali a Berlino. Hanno scoperto che:

Riproducibilità: Potevano eseguire il calcolo su due computer diversi, e questo produceva lo stesso identico risultato ogni volta.
Velocità: Controllare i calcoli (verifica) era molto veloce, anche con grandi quantità di dati.
Efficienza: La blockchain non si è intasata perché memorizzava solo i piccoli "Numeri del Sigillo", non i dati pesanti.

In Sintesi
Questo articolo presenta un modo per rendere affidabili i flussi di dati in tempo reale. Bloccando i dati in secchielli temporali fissi, standardizzando il formato e sigillando i risultati in una busta digitale registrata su una blockchain, essi permettono a chiunque di verificare in modo indipendente che un calcolo in tempo reale (come una media della temperatura) sia matematicamente corretto e non sia stato falsificato o alterato.

Sintesi Tecnica: Provenance dei Dati Blockchain Multichain per l'Elaborazione di Stream Deterministici con Kafka Streams

1. Definizione del Problema

Le pipeline di elaborazione di flussi di dati in tempo reale, come quelle costruite su Kafka Streams o Apache Flink, affrontano sfide critiche riguardanti l'auditabilità e la riproducibilità. Questi sistemi sono intrinsecamente non deterministici a causa delle dipendenze dalla pianificazione dell'esecuzione (runtime scheduling), dai trigger delle finestre temporali (window triggers), dai jitter di rete e dall'ordine di arrivo dei record. Di conseguenza, stream di input identici elaborati in momenti diversi o su nodi diversi possono produrre output differenti.

Le attuali soluzioni di provenienza basate su blockchain spesso si affidano a catene di hash per memorizzare le impronte digitali dei dati. Tuttavia, gli autori identificano due principali svantaggi in questo approccio per l'elaborazione di stream:

Overhead di Archiviazione: Man mano che la catena cresce, i requisiti di archiviazione aumentano significativamente.
Costo Computazionale: La verifica richiede la ripetuta operazione di hashing di lunghe catene, il che è inefficiente per dataset di grandi dimensioni.
Inoltre, le catene di hash vincolano la provenienza all'ordine di ingestione, rendendole inadatte per il replay deterministico sotto finestre basate su chiavi o sul tempo in cui l'appartenenza dei record cambia a causa di fattori esterni (ad esempio, il rebalancing).

2. Metodologia

Il documento propone un'architettura di provenienza supportata da blockchain che disaccoppia i carichi utili (payload) pesanti dalla blockchain, memorizzando solo gli ancoraggi crittografici e i metadati. Il sistema è implementato utilizzando Kafka Streams per l'elaborazione e MultiChain (una blockchain permissioned) per l'ancoraggio.

Componenti Core e Workflow

Ingestione ed Elaborazione:
- Dati meteorologici in tempo reale provenienti da due stazioni (Berlin-Brandenburg e Berlin-Tempelhof) vengono ingeriti tramite Kafka.
- Il sistema utilizza finestre a scatti allineate agli epoch (epoch-aligned tumbling windows). A differenza delle finestre basate sul tempo di elaborazione (processing-time), queste sono intervalli assoluti fissi (ad esempio, blocchi di 2 ore che iniziano in specifici istanti epoch) per garantire il determinismo globale indipendentemente dai ritardi di ingestione.
- All'interno di ogni finestra, i record vengono aggregati (min, max, media delle temperature).
Canonicalizzazione Deterministica:
- Per eliminare il non determinismo causato dall'ordine dei record, il sistema applica il JSON Canonico (Canonical JSON) a tutti i record all'interno di una finestra.
- Questo processo prevede la rimozione di campi inconsistenti, la normalizzazione dei timestamp in UTC (ISO-8601) e l'ordinamento lessicografico delle chiavi degli oggetti.
- I record vengono quindi deduplicati.
Costruzione dell'Albero di Merkle:
- Invece di una catena di hash lineare, il sistema costruisce un Albero di Merkle dai record canonicalizzati.
- I nodi foglia sono hash SHA-256 dei record canonici.
- I nodi interni sono hash di nodi figli concatenati.
- La Root di Merkle (Merkle Root) finale funge da impegno crittografico compatto per l'intero payload della finestra.
Ancoraggio su Blockchain (Checkpoint):
- Il payload completo rimane off-chain (memorizzato in un file system distribuito come NDJSON).
- Un checkpoint contenente la Merkle Root, i confini degli offset di Kafka (offsetStart, offsetEnd), il conteggio dei record, il percorso del payload e l'hash del payload viene pubblicato su uno stream MultiChain.
- MultiChain è stato scelto per le sue caratteristiche di stream append-only, basate su chiavi e valori, e per la sua natura permissioned, evitando la complessità degli smart contract a favore della logica applicativa esterna.
Verifica:
- Un auditor indipendente può verificare l'integrità di una finestra:
  1. Recuperando i metadati del checkpoint (Merkle Root $R$ e numero di record $N$ ) dalla blockchain.
  2. Caricando il payload off-chain.
  3. Ri-canonicalizzando i record e ricalcolando la Merkle Root ( $\hat{R}$ ) e il numero di record ( $\hat{N}$ ).
  4. Confrontando $\hat{R}$ con $R$ e $\hat{N}$ con $N$ . La verifica passa solo se entrambi corrispondono.

3. Contributi Chiave

Provenance delle Finestre Deterministiche: L'introduzione di un metodo per creare finestre di stream riproducibili utilizzando confini allineati agli epoch e serializzazione canonica, risolvendo il non determinismo inerente allo standard di stream processing.
Albero di Merkle rispetto alle Catene di Hash: Un passaggio dalle catene di hash lineari agli alberi di Merkle per la provenienza delle finestre, riducendo la complessità di verifica da lineare a logaritmica rispetto al numero di record.
Divisione Off-Chain/On-Chain: Un'architettura scalabile in cui i grandi payload mutabili sono memorizzati off-chain, mentre gli ancoraggi crittografici immutabili (merkle root) e i metadati sono memorizzati on-chain, prevenendo l'ingrossamento (bloat) della blockchain.
Auditabilità Indipendente: Un framework che consente ad auditor terzi di verificare l'integrità e la correttezza delle analisi derivate (ad esempio, le medie delle temperature) senza dover accedere allo stato interno del motore di streaming.

4. Valutazione e Risultati

Il sistema è stato valutato utilizzando dati meteorologici in tempo reale da Berlino.

Riproducibilità: Esecuzioni indipendenti su hardware differenti (MacOS M2 e M4) con Java 21 hanno prodotto risultati byte-identici per il JSON canonico, l'hash SHA-256 del payload e le merkle root, confermando l'eliminazione del non determinismo indotto dall'ambiente.
Costo di Verifica:
- Il tempo di verifica end-to-end ( $T(n)$ ) scala linearmente con il numero di record ( $n$ ), seguendo il modello $T(n) = \alpha n + \beta$ .
- Il sistema ha dimostrato un alto throughput (record al secondo) durante la verifica, senza un crollo delle prestazioni all'aumentare delle dimensioni delle finestre.
- I costi di canonicalizzazione e hashing hanno mostrato una scalabilità lineare, e la costruzione dell'albero di Merkle è rimasta quasi lineare.
Performance della Blockchain:
- Il checkpointing nel mondo reale ha comportato un basso numero di Transazioni Per Secondo (TPS) (0–0.015 item/s) a causa della natura infrequente della chiusura delle finestre rispetto ai tassi di eventi grezzi.
- Il benchmarking con publisher paralleli ha mostrato che MultiChain può gestire TPS più elevati (fino a ~2.1 tx/s per piccoli payload) ma raggiunge un punto di saturazione (intorno a 8 worker) a causa del suo algoritmo di consenso round-robin.

5. Significato e Rivendicazioni

Il documento afferma che il suo design consente ad auditor indipendenti di verificare tre aspetti critici dell'elaborazione di stream:

La completezza dei payload delle finestre (assicurando che non siano stati persi o aggiunti record).
La serializzazione canonica dei dati (garantendo un processing deterministico).
La correttezza delle analisi derivate (ad esempio, verificando che una temperatura media riportata sia matematicamente coerente con i record sottostanti).

Gli autori posizionano questo lavoro come una soluzione al "gap di auditabilità" nei moderni sistemi di stream processing. Combinando il windowing deterministico con l'ancoraggio crittografico, il sistema permette il reprocessing riproducibile degli stream di dati, una capacità attualmente carente nelle piattaforme di streaming standard. Il documento nota modestamente che, sebbene risolva l'integrità e l'auditabilità, non affronta ancora il significato semantico dei dati (richiedendo lavori futuri con RDF) né le preoccupazioni sulla privacy (suggerendo le zero-knowledge proofs come direzione futura). Conclude che la blockchain può essere integrata con successo nelle piattaforme di streaming per fornire uno strato di riferimento affidabile e immutabile per la provenienza dei dati.