💻 computer science

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

Dit artikel stelt een door MultiChain ondersteunde herkomstarchitectuur voor Kafka Streams voor die deterministische, controleerbare en reproduceerbare real-time verwerking van weergegevens waarborgt door cryptografische Merkle-wortels van venstergestuurde gegevens aan de blockchain te koppelen, terwijl de payloads off-chain blijven.

Oorspronkelijke auteurs: Niaz Mohammad Ramaki, Florian Schintke

Gepubliceerd 2026-01-27

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Niaz Mohammad Ramaki, Florian Schintke

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je naar een live nieuwsbericht kijkt met het weerbericht in Berlijn. Elke paar minuten kondigt de nieuwspresentator (het computersysteem) de gemiddelde temperatuur van het afgelopen uur aan.

Het Probleem: De "Tovertruc" van Live TV
Normaal gesproken is het verwerken van live gegevens een beetje als een tovertruc van een illusionist. De computer neemt duizenden temperatuurmetingen op, husselt ze door elkaar en geeft een gemiddelde weer. Maar omdat de computer zo snel is en het internet soms hapert, kan de volgorde waarin de gegevens binnenkomen veranderen.

Als je de computer zou vragen om exact dezelfde berekening twee keer uit te voeren, zou hij twee licht verschillende antwoorden kunnen geven.

Run 1: De computer ziet drie temperatuurmetingen en zegt: "Het gemiddelde is 21,0°C."
Run 2: Vanwege een kleine netwerkvertraging arriveert een vierde meting een fractie van een seconde later. De computer plaatst deze in een andere "bak" (tijdvenster) en zegt: "Het gemiddelde is 21,75°C."

Dit maakt het onmogelijk voor een auditor om te zeggen: "Ik weet zeker dat de computer dit correct heeft berekend," omdat het resultaat elke keer verandert als je de tape opnieuw afspeelt. Het is alsoal proberen een wiskundige som te verifiëren waarbij de getallen steeds opnieuw worden gerangschikt.

De Oplossing: Het "Verzegelde Envelop"-systeem
De auteurs van dit artikel hebben een systeem gebouwd om dit op te lossen met behulp van twee hoofdinstrumenten: Kafka Streams (de computer die de berekeningen uitvoert) en MultiChain (een speciale, onveranderlijke digitale grootboek, zoals een blockchain).

Zo werkt hun systeem, stap voor stap, met behulp van een eenvoudige analogie:

1. De "Vaste Tijdvakken" (Deterministisch Windowing)

In plaats van de computer te laten beslissen wanneer hij stopt met tellen en begint met een nieuw gemiddelde op basis van wanneer hij de gegevens toevallig ontvangt, gebruikt het systeem vaste tijdvakken.

Analogie: Stel je een lopende band in een fabriek voor die precies elke 2 uur stopt, ongeacht wat er gebeurt.
Hoe het werkt: Of de gegevens nu om 13:59 uur of om 14:01 uur binnenkomen, het systeem dwingt ze in het vak "13:00 tot 15:00 uur". Dit zorgt ervoor dat elke keer dat je de berekening uitvoert, exact dezelfde set gegevens in exact hetzelfde vak terechtkomt.

2. Het "Gestandaardiseerde Recept" (Canonical JSON)

Zelfs als de gegevens in hetzelfde vak zitten, kunnen computers zaken soms anders opschrijven (bijv. "10:00:00" versus "10:00").

Analogie: Stel je een chef-kok voor die erop staat dat elk ingrediënt in exact hetzelfde handschrift en in dezelfde volgorde wordt opgeschreven voordat het in de pan gaat.
Hoe het werkt: Het systeem neemt elk temperatuurrecord en herschrijft dit naar een strikt, standaard formaat. Dit garandeert dat de gegevens er elke keer identiek uitzien tijdens de verwerking.

3. De "Digitale Lakzegel" (Merkle Trees)

Nu de gegevens in een vast vak zitten en in een standaardformaat zijn geschreven, moet het systeem bewijzen dat de gegevens niet zijn gemanipuleerd.

Analogie: Stel je voor dat je een stapel bonnetjes hebt. In plaats van de hele stapel in een kluis te vergrendelen, maak je een hash (je verandert ze in een unieke digitale vingerafdruk) en rangschikt ze in een piramide. Vervolgens neem je het bovenste getal van de piramide — de Merkle Root — en verzegelt je deze in een envelop met lak.
Hoe het werkt: Het systeem maakt een "Merkle Root" voor alle temperaturen in dat 2-uurlijkse vak. Deze root is een enkele, kleine code die de gehele groep gegevens vertegenwoordigt. Als zelfs maar één temperatuur verandert, verandert de code volledig.

4. Het "Onveranderlijke Logboek" (Blockchain Anchoring)

Dit is waar de magie gebeurt. Het systeem plaatst de zware, rommelige temperatuurgegevens niet op de blockchain (dat zou te traag en te duur zijn).

Analogie: Je bewaart de zware bonnetjes in een lade (off-chain opslag), maar je schrijft het Zegelnummer (de Merkle Root) en het Paginanummer in een openbaar, onveranderlijk dagboek (de blockchain).
Hoe het werkt: Het systeem schrijft de Merkle Root en de "paginanummers" (Kafka offsets) naar de MultiChain blockchain. De blockchain fungeert als een permanente, onveranderlijke getuige.

5. De "Controle van de Auditor" (Verification)

Stel je nu voor dat een auditor wil controlen of het weerbericht correct was.

Ze kijken in het Dagboek (Blockchain) om te zien wat het "Zegelnummer" voor die tijdsperiode had moeten zijn.
Ze gaan naar de Laat (Off-chain opslag) en halen de werkelijke bonnetjes (de temperatuurgegevens) eruit.
Ze voeren het "Gestandaardiseerde Recept" en de "Piramide-zegel" berekening opnieuw uit.
Het Resultaat: Als het nieuwe Zegelnummer overeenkomt met het nummer in het Dagboek, is bewezen dat de gegevens 100% authentiek en volledig zijn. Als het niet overeenkomt, heeft iemand met de bonnetjes geknoeid.

De Resultaten
De auteurs hebben dit getest met echte weerstations in Berlijn. Ze ontdekten:

Reproduceerbaarheid: Ze konden de berekening op twee verschillende computers uitvoeren, en het produceerde elke keer exact hetzelfde resultaat.
Snelheid: Het controleren van de wiskunde (verificatie) ging erg snel, zelfs met veel gegevens.
Efficiëntie: De blockchain raakte niet verstopt omdat deze alleen de kleine "Zegelnummers" opsloeg, en niet de zware gegevens zelf.

Samenvattend
Dit artikel presenteert een manier om live datastromen "betrouwbaar" te maken. Door de gegevens vast te leggen in vaste tijdvakken, het formaat te standaardiseren en de resultaten te verzegelen in een digitale envelop die op een blockchain is vastgelegd, maken ze het voor iedereen mogelijk om onafhankelijk te verifiëren dat een live berekening (zoals een gemiddelde temperatuur) wiskundig correct is en niet is vervalst of gewijzigd.

Technische Samenvatting: Multichain Blockchain Data Provenance voor Deterministische Stream Processing met Kafka Streams

1. Probleemstelling

Real-time datastroomverwerkingspijplijnen, zoals die gebouwd op Kafka Streams of Apache Flink, worden geconfronteerd met kritieke uitdagingen met betrekking tot auditbaarheid en reproduceerbaarheid. Deze systemen zijn inherent niet-deterministisch vanwege afhankelijkheden van runtime-scheduling, window-triggers, netwerkjitter en de volgorde van aankomst van records. Bijgevolg kunnen identieke inputstromen die op verschillende tijdstippen of op verschillende nodes worden verwerkt, verschillende outputs opleveren.

Huidige blockchain-gebaseerde provenance-oplossingen vertrouwen vaak op hash-ketens om vingerafdrukken van gegevens op te slaan. De auteurs identificeren echter twee belangrijke nadelen van deze aanpak voor stream processing:

Opslagoverhead: Naarmate de keten groeit, nemen de opslagvereisten aanzienlijk toe.
Berekeningskosten: Verificatie vereist herhaaldelijke hashing van lange ketens, wat inefficiënt is voor grote datasets.
Bovendien koppelen hash-ketens provenance aan de volgorde van ingestie, wat ze ongeschikt maakt voor deterministische replay onder re-keyed of tijdgebaseerde windows waarbij de lidmaatschap van records verandert door externe factoren (bijv. rebalancing).

2. Methodologie

Het artikel stelt een blockchain-ondersteunde provenance-architectuur voor die zware dataloads ontkoppelt van de blockchain door alleen cryptografische ankers en metadata op te slaan. Het systeem is geïmplementeerd met behulp van Kafka Streams voor verwerking en MultiChain (een permissioned blockchain) voor het verankeren.

Kerncomponenten en Workflow

Ingestie & Verwerking:
- Real-time weergegevens van twee stations (Berlin-Brandenburg en Berlin-Tempelhof) worden via Kafka geïnjecteerd.
- Het systeem gebruikt epoch-aligned tumbling windows. In tegenstelling tot processing-time windows zijn dit vaste absolute intervallen (bijv. 2-uur blokken beginnend op specifieke epoch-tijden) om globale determinisme te garanderen, ongeacht de vertragingen in de ingestie.
- Binnen elk window worden records geaggregeerd (min, max, gemiddelde temperaturen).
Deterministische Canonicalisering:
- Om niet-determinisme veroorzaakt door de volgorde van records te elimineren, past het systeem Canonical JSON toe op alle records binnen een window.
- Dit proces omvat het verwijderen van inconsistente velden, het normaliseren van timestamps naar UTC (ISO-8601), en het lexicografisch sorteren van objectsleutels.
- Records worden vervolgens gededupliceerd.
Merkle Tree Constructie:
- In plaats van een lineaire hash-keten construeert het systeem een Merkle Tree van de gecanoniseerde records.
- Leaf nodes zijn SHA-256 hashes van de gecanoniseerde records.
- Interne nodes zijn hashes van geconcateneerde child nodes.
- De uiteindelijke Merkle Root dient als een compacte, cryptografische commitment tot de volledige payload van het window.
Blockchain Anchoring (Checkpoints):
- De volledige payload blijft off-chain (opgeslagen in een gedistribueerd bestandssysteem als NDJSON).
- Een checkpoint die de Merkle Root, Kafka offset grenzen (offsetStart, offsetEnd), record aantal, payload pad en payload hash bevat, wordt gepubliceerd naar een MultiChain stream.
- MultiChain is gekozen vanwege de append-only, key-value stream functies en de permissioned aard, waarbij de complexiteit van smart contracts wordt vermeden ten gunste van externe applicatielogica.
Verificatie:
- Een onafhankelijke auditor kan de integriteit van een window verifiëren door:
  1. De checkpoint metadata (Merkle Root $R$ en record aantal $N$ ) van de blockchain te halen.
  2. De off-chain payload te laden.
  3. De records opnieuw te canonicaliseren en de Merkle Root ( $\hat{R}$ ) en record aantal ( $\hat{N}$ ) opnieuw te berekenen.
  4. $\hat{R}$ met $R$ en $\hat{N}$ met $N$ te vergelijken. Verificatie slaagt alleen als beide overeenkomen.

3. Belangrijkste Bijdragen

Deterministische Window Provenance: De introductie van een methode om reproduceerbare stream windows te creëren met behulp van epoch-aligned grenzen en canonical serialisatie, wat het inherente niet-determinisme van standaard stream processing oplost.
Merkle Tree boven Hash Chains: Een verschuiving van lineaire hash-ketens naar Merkle trees voor window provenance, wat de verificatiecomplexiteit vermindert van lineair naar logaritmisch ten opzichte van het aantal records.
Off-Chain/On-Chain Split: Een schaalbare architectuur waarbij grote, mutabele payloads off-chain worden opgeslagen, terwijl immutabele cryptografische ankers (Merkle roots) en metadata on-chain worden opgeslagen, wat blockchain-bloat voorkomt.
Onafhankelijke Auditbaarheid: Een framework waarmee derde partijen de volledigheid en correctheid van afgeleide analytics (bijv. gemiddelde temperaturen) kunnen verifiëren zonder toegang te hoeven hebben tot de interne status van de streaming engine.

4. Evaluatie en Resultaten

Het systeem werd geëvalueerd met behulp van real-time weergegevens uit Berlijn.

Reproduceerbaarheid: Onafhankelijke runs op verschillende hardware (MacOS M2 en M4) met Java 21 produceerden byte-identieke resultaten voor de canonical JSON, payload SHA-256 en Merkle roots, wat bevestigt dat de door de omgeving veroorzaakte niet-determinisme is geëlimineerd.
Verificatiekosten:
- De end-to-end verificatietijd ( $T(n)$ ) schaalt lineair met het aantal records ( $n$ ), volgens het model $T(n) = \alpha n + \beta$ .
- Het systeem demonstreerde een hoge throughput (records per seconde) tijdens verificatie, zonder prestatieverlies naarmate de window-groottes toenamen.
- De kosten voor canonicalisering en hashing toonden lineaire schaling, en de constructie van de Merkle tree bleef bijna lineair.
Blockchain Prestaties:
- Real-world checkpointing resulteerde in een lage Transactions Per Second (TPS) (0–0,015 items/s) vanwege de zeldzame aard van het sluiten van windows vergeleken met de ruwe event rates.
- Benchmarking met parallelle publishers toonde aan dat MultiChain hogere TPS kan verwerken (tot ~2,1 tx/s voor kleine payloads), maar een verzadigingspunt bereikt (rond 8 workers) door zijn round-robin consensus algoritme.

5. Betekenis en Claims

Het artikel claimt dat het ontwerp de mogelijkheid biedt voor onafhankelijke auditors om drie kritieke aspecten van stream processing te verifiëren:

De volledigheid van window payloads (garanderen dat er geen records zijn gedropt of toegevoegd).
De canonical serialisatie van data (garanderen van deterministische verwerking).
De correctheid van afgeleide analytics (bijv. het verifiëren dat een gerapporteerd gemiddelde temperatuur wiskundig consistent is met de onderliggende records).

De auteurs positioneren dit werk als een oplossing voor de "auditability gap" in moderne stream processing. Door deterministische windowing te combineren met cryptografische verankering, biedt het systeem een reproduceerbare herverwerking van datastromen, een capaciteit die momenteel ontbreekt in standaard streaming platforms. Het artikel merkt bescheiden op dat hoewel het integriteit en auditbaarheid oplost, het nog niet de semantische betekenis van de data aanpakt (wat toekomstig werk met RDF vereist) of privacyzorgen (wat wijst op zero-knowledge proofs als een toekomstige richting). Het concludeert dat blockchain succesvol kan worden geïntegreerd met streaming platforms om een betrouwbare, onveranderlijke referentielaag voor data provenance te bieden.