💻 computer science

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

Dieses Paper schlägt eine MultiChain-gestützte Provenienz-Architektur für Kafka Streams vor, die durch das Verankern kryptografischer Merkle-Roots von fensterbasierten Daten in der Blockchain bei gleichzeitiger Off-Chain-Speicherung der Nutzlasten eine deterministische, auditierbare und reproduzierbare Echtzeitverarbeitung von Wetterdaten gewährleistet.

Ursprüngliche Autoren: Niaz Mohammad Ramaki, Florian Schintke

Veröffentlicht 2026-01-27

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Niaz Mohammad Ramaki, Florian Schintke

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie schauen eine Live-Nachrichtensendung über das Wetter in Berlin. Alle paar Minuten verkündet der Nachrichtensprecher (das Computersystem) die Durchschnittstemperatur der letzten Stunde.

Das Problem: Der „Zaubertrick“ des Live-Fernsehens
Normalerweise ist die Verarbeitung von Live-Daten ein wenig wie ein Zaubertrick eines Magiers. Der Computer nimmt tausende Temperaturmessungen auf, ordnet sie um und gibt dann einen Durchschnitt aus. Aber weil der Computer so schnell ist und das Internet manchmal ruckelt, kann sich die Reihenfolge, in der die Daten eintreffen, ändern.

Wenn Sie den Computer bitten würden, exakt dieselbe Berechnung zweimal durchzuführen, könnte er zwei leicht unterschiedliche Antworten liefern.

Durchlauf 1: Der Computer sieht drei Temperaturmessungen und sagt: „Der Durchschnitt liegt bei 21,0 °C.“
Durchlauf 2: Aufgrund einer winzigen Netzwerkverzögerung trifft eine vierte Messung einen Bruchteil einer Sekunde später ein. Der Computer sortiert sie in ein anderes „Behälter“ (Zeitfenster) ein und sagt: „Der Durchschnitt liegt bei 21,75 °C.“

Dies macht es für einen Auditor unmöglich zu sagen: „Ich weiß mit Sicherheit, dass der Computer dies korrekt berechnet hat“, weil sich das Ergebnis jedes Mal ändert, wenn man das Band abspielt. Es ist, als würde man versuchen, ein mathematisches Problem zu verifizieren, bei dem sich die Zahlen ständig neu anordnen.

Die Lösung: Das „Versiegelte-Umschlag-System“
Die Autoren dieser Arbeit haben ein System entwickelt, um dies mit zwei Hauptwerkzeugen zu lösen: Kafka Streams (der Computer, der die Berechnungen durchführt) und MultiChain (ein spezielles, unveränderliches digitales Register, ähnlich einer Blockchain).

So funktioniert ihr System Schritt für Schritt, unter Verwendung einer einfachen Analogie:

1. Die „Festen Zeitbehälter“ (Deterministisches Windowing)

Anstatt den Computer entscheiden zu lassen, wann er mit dem Zählen aufhört und mit einem neuen Durchschnitt beginnt – basierend darauf, wann er die Daten zufällig erhält – verwendet das System feste Zeitbehälter.

Analogie: Stellen Sie sich ein Fließband in einer Fabrik vor, das alle exakt 2 Stunden stoppt, egal was passiert.
Funktionsweise: Ob die Daten um 13:59 Uhr oder um 14:01 Uhr eintreffen, das System erzwingt die Einordnung in den Behälter „13:00 bis 15:00 Uhr“. Dies stellt sicher, dass bei jedem Durchlauf der Berechnung exakt derselbe Datensatz in denselben Behälter gelangt.

2. Das „Standardisierte Rezept“ (Kanonisches JSON)

Selbst wenn die Daten im selben Behälter sind, können Computer Dinge manchmal unterschiedlich schreiben (z. B. „10:00:00“ vs. „10:00“).

Analogie: Stellen Sie sich einen Koch vor, der darauf besteht, dass jede Zutat vor dem Hinzufügen in den Topf in der exakt gleichen Handschrift und in der gleichen Reihenfolge aufgeschrieben werden muss.
Funktionsweise: Das System nimmt jeden Temperaturdatensatz und schreibt ihn in ein striktes, standardisiertes Format um. Dies garantiert, dass die Daten bei jeder Verarbeitung identisch aussehen.

3. Das „Digitale Siegelwachs“ (Merkle-Bäume)

Nun, da die Daten in einem festen Behälter liegen und in einem standardisierten Format geschrieben wurden, muss das System sicherstellen, dass die Daten nicht manipuliert wurden.

Analogie: Stellen Sie sich vor, Sie haben einen Stapel Quittungen. Anstatt den ganzen Stapel in einen Tresor zu sperren, „hashen“ Sie diese (wandeln sie in einen einzigartigen digitalen Fingerabdruck um) und ordnen sie in einer Pyramide an. Sie nehmen dann die oberste Zahl der Pyramide – die Merkle-Root – und versiegeln sie in einem Wachs-Umschlag.
Funktionsweise: Das System erstellt eine „Merkle-Root“ für alle Temperaturen in diesem 2-Stunden-Behälter. Diese Root ist ein einziger, winziger Code, der den gesamten Datensatz repräsentiert. Wenn sich auch nur eine einzige Temperatur ändert, ändert sich der Code vollständig.

4. Das „Unveränderliche Logbuch“ (Blockchain-Verankerung)

Hier geschieht die Magie. Das System legt die schweren, unordentlichen Temperaturdaten nicht auf die Blockchain (das wäre zu langsam und zu teuer).

Analogie: Sie bewahren die schweren Quittungen in einer Schublade auf (Off-Chain-Speicherung), aber Sie schreiben die Siegelnummer (die Merkle-Root) und die Seitenzahl in ein öffentliches, unveränderliches Tagebuch (die Blockchain).
Funktionsweise: Das System schreibt die Merkle-Root und die „Seitenzahlen“ (Kafka-Offsets) in die MultiChain-Blockchain. Die Blockchain fungt als permanenter, unveränderlicher Zeuge.

5. Die „Prüfung durch den Auditor“ (Verifizierung)

Stellen Sie sich nun vor, ein Auditor möchte überprüfen, ob der Wetterbericht korrekt war.

Er schaut in das Tagebuch (Blockchain), um zu sehen, welche „Siegelnummer“ für diesen Zeitslot vorgesehen war.
Er geht zur Schublade (Off-Chain-Speicher) und holt die eigentlichen Quittungen (die Temperaturdaten) heraus.
Er führt das „Standardisierte Rezept“ und die „Pyramiden-Siegel“-Berechnung erneut durch.
Das Ergebnis: Wenn die neue Siegelnummer mit der im Tagebuch eingetragenen übereinstimmt, ist bewiesen, dass die Daten zu 100 % authentisch und vollständig sind. Wenn sie nicht übereinstimmen, hat jemand die Quittungen manipuliert.

Die Ergebnisse
Die Autoren testeten dies mit echten Wetterstationen in Berlin. Sie fanden heraus:

Reproduzierbarkeit: Sie konnten die Berechnung auf zwei verschiedenen Computern durchführen, und sie lieferte jedes Mal exakt das gleiche Ergebnis.
Geschwindigkeit: Die mathematische Prüfung (Verifizierung) war sehr schnell, selbst bei großen Datenmengen.
Effizienz: Die Blockchain wurde nicht überlastet, da sie nur die winzigen „Siegelnummern“ speicherte und nicht die schweren Daten selbst.

Zusammenfassend
Diese Arbeit präsentiert einen Weg, Live-Datenströme „vertrauenswürdig“ zu machen. Indem sie die Daten in feste Zeitbehälter sperren, das Format standardisieren und die Ergebnisse in einem digitalen Umschlag auf einer Blockchain registrieren, ermöglichen sie es jedem, unabhängig zu verifizieren, dass eine Live-Berechnung (wie ein Wetterdurchschnitt) mathematisch korrekt ist und nicht gefälscht oder verändert wurde.

Technisches Resümee: Multichain-Blockchain-Datenprovenienz für deterministische Stream-Verarbeitung mit Kafka Streams

1. Problemstellung

Echtzeit-Datenstromverarbeitungspipelines, wie sie beispielsweise mit Kafka Streams oder Apache Flink aufgebaut werden, stehen vor kritischen Herausforderungen hinsichtlich der Auditierbarkeit und Reproduzierbarkeit. Diese Systeme sind aufgrund von Abhängigkeiten von Laufzeit-Scheduling, Window-Triggern, Netzwerk-Jitter und der Ankunftsreihenfolge von Datensätzen inhärent nicht-deterministisch. Folglich können identische Eingabeströme, die zu unterschiedlichen Zeiten oder auf unterschiedlichen Knoten verarbeitet werden, unterschiedliche Ausgaben liefern.

Gängige Blockchain-basierte Provenienzlösungen basieren oft auf Hash-Ketten zur Speicherung von Daten-Fingerabdrücken. Die Autoren identifizieren jedoch zwei wesentliche Nachteile dieses Ansatzes für die Stream-Verarbeitung:

Speicher-Overhead: Mit wachsender Kette steigen die Speicheranforderungen signifikant an.
Rechenkosten: Die Verifizierung erfordert wiederholtes Hashen langer Ketten, was bei großen Datensätzen ineffizient ist.
Darüber hinaus binden Hash-Ketten die Provenienz an die Ingestions-Reihenfolge, was sie für eine deterministische Replay-Verarbeitung unter Re-Keying oder zeitbasierten Fenstern ungeeignet macht, bei denen sich die Mitgliederschaft der Datensätze aufgrund externer Faktoren (z. B. Rebalancing) ändert.

2. Methodik

Das Paper schlägt eine Blockchain-gestützte Provenienz-Architektur vor, die schwere Daten-Payloads von der Blockchain entkoppelt, indem sie nur kryptografische Anker und Metadaten speichert. Das System wird unter Verwendung von Kafka Streams für die Verarbeitung und MultiChain (einer Permissioned Blockchain) für das Anchoring implementiert.

Kernkomponenten und Workflow

Ingestion & Verarbeitung:
- Echtzeit-Wetterdaten von zwei Stationen (Berlin-Brandenburg und Berlin-Tempelhof) werden via Kafka aufgenommen.
- Das System verwendet Epoch-aligned Tumbling Windows. Im Gegensatz zu Processing-Time-Windows handelt es sich hierbei um feste absolute Intervalle (z. B. 2-Stunden-Blöcke beginnend bei spezifischen Epoch-Zeiten), um globale Deterministik unabhängig von Ingestions-Verzögerungen zu gewährleisten.
- Innerhalb jedes Fensters werden die Datensätze aggregiert (Min, Max, Durchschnittstemperatur).
Deterministische Kanonisierung:
- Um Nicht-Determinismus durch die Reihenfolge der Datensätze zu eliminieren, wendet das System Canonical JSON auf alle Datensätze innerhalb eines Fensters an.
- Dieser Prozess beinhaltet das Entfernen inkonsistenter Felder, die Normalisierung von Zeitstempeln auf UTC (ISO-8601) und das lexikografische Sortieren von Objekt-Keys.
- Die Datensätze werden anschließend dedupliziert.
Merkle-Baum-Konstruktion:
- Anstatt einer linearen Hash-Kette konstruiert das System einen Merkle-Baum aus den kanonisierten Datensätzen.
- Die Blattknoten sind SHA-256-Hashes der kanonisierten Datensätze.
- Interne Knoten sind Hashes der konkatenierten Kindknoten.
- Der finale Merkle-Root dient als kompakter, kryptografischer Commitment für die gesamte Payload des Fensters.
Blockchain-Anchoring (Checkpoints):
- Die vollständige Payload verbleibt off-chain (gespeichert in einem verteilten Dateisystem als NDJSON).
- Ein Checkpoint, der den Merkle-Root, die Kafka-Offset-Grenzen (offsetStart, offsetEnd), die Anzahl der Datensätze, den Payload-Pfad und den Payload-Hash enthält, wird in einen MultiChain-Stream veröffentlicht.
- MultiChain wurde aufgrund seiner Append-only Key-Value-Stream-Eigenschaften und seines Permissioned-Charakters gewählt, um die Komplexität von Smart Contracts zugunsten externer Applikationslogik zu vermeiden.
Verifizierung:
- Ein unabhängiger Auditor kann die Integrität eines Fensters verifizieren, indem er:
  1. Die Checkpoint-Metadaten (Merkle-Root $R$ und Datensatzanzahl $N$ ) aus der Blockchain abruft.
  2. Die Off-Chain-Payload lädt.
  3. Die Datensätze erneut kanonisiert und den Merkle-Root ( $\hat{R}$ ) sowie die Anzahl der Datensätze ( $\hat{N}$ ) neu berechnet.
  4. $\hat{R}$ mit $R$ und $\hat{N}$ mit $N$ vergleicht. Die Verifizierung ist nur erfolgreich, wenn beide Werte übereinstimmen.

3. Zentrale Beiträge

Deterministische Window-Provenienz: Die Einführung einer Methode zur Erstellung reproduzierbarer Stream-Fenster mittels Epoch-aligned Boundaries und kanonischer Serialisierung, welche den in Standard-Stream-Verarbeitungsprozessen inhärenten Nicht-Determinismus löst.
Merkle-Baum statt Hash-Ketten: Ein Wechsel von linearen Hash-Ketten zu Merkle-Bäumen für die Fenster-Provenienz, was die Komplexität der Verifizierung von linear auf logarithmisch relativ zur Anzahl der Datensätze reduziert.
Off-Chain/On-Chain-Split: Eine skalierbare Architektur, bei der große, mutierbare Payloads off-chain gespeichert werden, während unveränderliche kryptografische Anker (Merkle-Roots) und Metadaten on-chain liegen, um das Aufblähen der Blockchain zu verhindern.
Unabhängige Auditierbarkeit: Ein Framework, das es Drittprüfern ermöglicht, die Vollständigkeit und Korrektheit abgeleiteter Analysen (z. B. Durchschnittstemperaturen) zu verifizieren, ohne Zugriff auf den internen Zustand der Streaming-Engine zu benötigen.

4. Evaluierung und Ergebnisse

Das System wurde unter Verwendung von Echtzeit-Wetterdaten aus Berlin evaluiert.

Reproduzierbarkeit: Unabhängige Durchläufe auf unterschiedlicher Hardware (MacOS M2 und M4) mit Java 21 erzeugten byte-identische Ergebnisse für das Canonical JSON, den Payload-SHA-256 und die Merkle-Roots, was die Eliminierung umgebungsbedingter Nicht-Determinismen bestätigt.
Verifizierungskosten:
- Die End-to-End-Verifizierungszeit ( $T(n)$ ) skaliert linear mit der Anzahl der Datensätze ( $n$ ) gemäß dem Modell $T(n) = \alpha n + \beta$ .
- Das System zeigte einen hohen Durchsatz (Datensätze pro Sekunde) während der Verifizierung, wobei die Performance auch bei steigenden Fenstergrößen nicht einbrach.
- Die Kosten für Kanonisierung und Hashing zeigten eine lineare Skalierung, und die Konstruktion des Merkle-Baums blieb nahezu linear.
Blockchain-Performance:
- Das reale Checkpointing resultierte in einem niedrigen Durchsatz von Transaktionen pro Sekunde (TPS) (0–0,015 Items/s), bedingt durch die seltene Natur von Fenster-Abschlüssen im Vergleich zu den rohen Ereignisraten.
- Benchmarks mit parallelen Publishern zeigten, dass MultiChain höhere TPS (bis zu ~2,1 tx/s für kleine Payloads) bewältigen kann, aber einen Sättigungspunkt (bei etwa 8 Workern) aufgrund seines Round-Robin-Konsens-Algorithmus erreicht.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass sein Design es unabhängigen Auditoren ermöglicht, drei kritische Aspekte der Stream-Verarbeitung zu verifizieren:

Die Vollständigkeit der Fenster-Payloads (Sicherstellung, dass keine Datensätze verloren gingen oder hinzugefügt wurden).
Die kanonische Serialisierung der Daten (Sicherstellung deterministischer Verarbeitung).
Die Korrektheit der abgeleiteten Analysen (z. B. Verifizierung, dass eine gemeldete Durchschnittstemperatur mathematisch konsistent mit den zugrunde liegenden Datensätzen ist).

Die Autoren positionieren diese Arbeit als Lösung für die „Auditierbarkeitslücke“ in der modernen Stream-Verarbeitung. Durch die Kombination von deterministischem Windowing mit kryptografischem Anchoring ermöglicht das System eine reproduzierbare Neuverarbeitung (Reprocessing) von Datenströmen – eine Fähigkeit, die in Standard-Streaming-Plattformen derzeit fehlt. Das Paper merkt bescheiden an, dass es zwar die Integrität und Auditierbarkeit löst, aber noch nicht die semantische Bedeutung der Daten adressiert (was zukünftige Arbeit mit RDF erfordert) und auch keine Datenschutzbedenken behandelt (was auf Zero-Knowledge-Proofs als zukünftige Richtung hindeutet). Es kommt zu dem Schluss, dass Blockchain erfolgreich in Streaming-Plattformen integriert werden kann, um eine vertrauenswürdige, unveränderliche Referenzschicht für die Datenprovenienz bereitzustellen.