💻 computer science

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

Ce document propose une architecture de provenance reposant sur MultiChain pour Kafka Streams qui garantit un traitement déterministe, auditable et reproductible des données météorologiques en temps réel en ancrant les racines de Merkle cryptographiques de données fenêtrées à la blockchain tout en conservant les charges utiles hors chaîne.

Auteurs originaux : Niaz Mohammad Ramaki, Florian Schintke

Publié 2026-01-27

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Niaz Mohammad Ramaki, Florian Schintke

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous regardiez un journal télévisé en direct présentant la météo à Berlin. Toutes les quelques minutes, le présentateur (le système informatique) annonce la température moyenne de la dernière heure.

Le Problème : Le « tour de magie » de la télévision en direct
Habituellement, le traitement des données en direct ressemble un peu à un tour de magie. L'ordinateur reçoit des milliers de relevés de température, les mélange, et en extrait une moyenne. Mais parce que l'ordinateur est très rapide et que l'internet est parfois instable, l'ordre dans lequel les données arrivent peut changer.

Si vous demandiez à l'ordinateur d'effectuer exactement le même calcul deux fois, il pourrait donner deux réponses légèrement différentes.

Exécution 1 : L'ordinateur voit trois relevés de température et dit : « La moyenne est de 21,0 °C. »
Exécution 2 : En raison d'un léger délai réseau, un quatrième relevé arrive une fraction de seconde plus tard. L'ordinateur le place dans un autre « seau » (fenêtre temporelle) et dit : « La moyenne est de 21,75 °C. »

Cela rend impossible pour un auditeur de dire : « Je sais avec certitude que l'ordinateur a calculé cela correctement », car le résultat change à chaque fois que l'on rejoue la cassette. C'est comme essayer de vérifier un problème mathématique où les chiffres ne cessent de se réorganiser.

La Solution : Le système de l'« enveloppe scellée »
Les auteurs de cet article ont construit un système pour corriger cela en utilisant deux outils principaux : Kafka Streams (l'ordinateur qui fait les calculs) et MultiChain (un registre numérique immuable, semblable à une blockchain).

Voici comment leur système fonctionne, étape par étape, en utilisant une analogie simple :

1. Les « Seaux de temps fixes » (Fenêtrage déterministe)

Au lieu de laisser l'ordinateur décider quand arrêter de compter et commencer un nouveau calcul en fonction du moment où il reçoit les données, le système utilise des seaux de temps fixes.

Analogie : Imaginez un tapis roulant d'usine qui s'arrête exactement toutes les 2 heures, peu importe ce qui arrive.
Fonctionnement : Que la donnée arrive à 13h59 ou à 14h01, le système la force à entrer dans le seau « de 13h00 à 15h00 ». Cela garantit que chaque fois que vous lancez le calcul, le même ensemble de données entre dans le même seau.

2. La « Recette standardisée » (JSON canonique)

Même si les données sont dans le même seau, les ordinateurs peuvent parfois écrire les choses différemment (par exemple, « 10:00:00 » contre « 10:00 »).

Analogie : Imaginez un chef qui insiste pour que chaque ingrédient soit écrit exactement avec la même écriture et dans le même ordre avant d'être mis dans la marmite.
Fonctionnement : Le système prend chaque relevé de température et le réécrit dans un format strict et standard. Cela garantit que les données paraissent identiques à chaque fois qu'elles sont traitées.

3. Le « Sceau de cire numérique » (Arbres de Merkle)

Maintenant que les données sont dans un seau fixe et écrites dans un format standard, le système doit prouver que les données n'ont pas été altérées.

Analogie : Imaginez que vous avez une pile de reçus. Au lieu de verrouiller toute la pile dans un coffre-fort, vous les hachez (les transformez en une empreinte numérique unique) et les disposez en pyramide. Vous prenez ensuite le nombre tout en haut de la pyramide — la Racine de Merkle — et vous la scellez dans une enveloppe de cire.
Fonctionnement : Le système crée une « Racine de Merkle » pour tous les relevés de température de ce seau de 2 heures. Cette racine est un code unique et minuscule qui représente l'intégralité du groupe de données. Si une seule température change, le code change complètement.

4. Le « Registre immuable » (Ancrage sur la Blockchain)

C'est ici que la magie opère. Le système ne met pas les données de température lourdes et désordonnées sur la blockchain (cela serait trop lent et coûteux).

Analogie : Vous gardez les reçus lourds dans un tiroir (stockage hors chaîne/off-chain), mais vous écrivez le Numéro de Sceau (la Racine de Merkle) et le Numéro de Page dans un journal public et immuable (la blockchain).
Fonctionnement : Le système écrit la Racine de Merkle et les « numéros de page » (offsets Kafka) sur la blockchain MultiChain. La blockchain agit comme un témoin permanent et inaltérable.

5. La « Vérification de l'auditeur » (Vérification)

Maintenant, imaginez qu'un auditeur veuille vérifier si le rapport météorologique était correct.

Il consulte le Journal (Blockchain) pour voir quel était le « Numéro de Sceau » prévu pour ce créneau horaire.
Il va chercher dans le Tiroir (Stockage hors chaîne) les reçus réels (les données de température).
Il relance la « Recette Standardisée » et le calcul du « Sceau de la Pyramide ».
Le Résultat : Si le nouveau Numéro de Sceau correspond à celui inscrit dans le Journal, les données sont prouvées être 100 % authentiques et complètes. Si cela ne correspond pas, quelqu'un a falsifié les reçus.

Les Résultats
Les auteurs ont testé cela avec de vraies stations météo à Berlin. Ils ont constaté :

Reproductibilité : Ils pouvaient exécuter le calcul sur deux ordinateurs différents, et cela produisait exactement le même résultat à chaque fois.
Vitesse : Vérifier le calcul (la vérification) était très rapide, même avec beaucoup de données.
Efficacité : La blockchain n'était pas encombrée car elle ne stockait que les petits « Numéros de Sceau », et non les données lourdes elles-mêmes.

En résumé
Cet article présente un moyen de rendre les flux de données en direct « dignes de confiance ». En verrouillant les données dans des seaux de temps fixes, en standardisant le format et en scellant les résultats dans une enveloppe numérique enregistrée sur une blockchain, ils permettent à n'importe qui de vérifier indépendamment qu'un calcul en direct (comme une moyenne de température) est mathématiquement correct et n'a pas été falsifié ou modifié.

Résumé Technique : Provenance des données blockchain multichaîne pour le traitement de flux déterministes avec Kafka Streams

1. Énoncé du problème

Les pipelines de traitement de flux de données en temps réel, tels que ceux construits sur Kafka Streams ou Apache Flink, sont confrontés à des défis critiques concernant l'auditabilité et la reproductibilité. Ces systèmes sont intrinsèquement non déterministes en raison des dépendances liées à l'ordonnancement d'exécution, aux déclenchements de fenêtres (windows), aux gères de réseau et à l'ordre d'arrivée des enregistrements. Par conséquent, des flux d'entrée identiques traités à des moments différents ou sur des nœuds différents peuvent produire des sorties différentes.

Les solutions actuelles de provenance basées sur la blockchain reposent souvent sur des chaînes de hachage pour stocker les empreintes de données. Cependant, les auteurs identent deux inconvénients majeurs de cette approche pour le traitement de flux :

Surcharge de stockage : À mesure que la chaîne croît, les exigences de stockage augmentent considérablement.
Coût de calcul : La vérification nécessite un hachage répété de longues chaînes, ce qui est inefficace pour de grands ensembles de données.
De plus, les chaînes de hachage lient la provenance à l'ordre d'ingestion, ceما les rend inadaptées pour un rejeu déterministe sous des fenêtres basées sur le temps ou le re-clésage où la composition des enregistrements change en raison de facteurs externes (ex. : rééquilibrage).

2. Méthodologie

Le papier propose une architecture de provenance soutenue par la blockchain qui découple les charges utiles de données lourdes de la blockchain, en ne stockant que des ancres cryptographiques et des métadonnées. Le système est implémenté en utilisant Kafka Streams pour le traitement et MultiChain (une blockchain avec permission) pour l'ancrage.

Composants principaux et flux de travail

Ingestion et Traitement :
- Des données météorologiques en temps réel provenant de deux stations (Berlin-Brandenburg et Berlin-Tempelhof) sont ingérées via Kafka.
- Le système utilise des fenêtres à bascule alignées sur l'époque (epoch-aligned tumbling windows). Contrairement aux fenêtres basées sur le temps de traitement, celles-ci sont des intervalles absolques fixes (ex. : blocs de 2 heures commençant à des moments d'époque spécifiques) pour garantir un déterminisme global quel que soit les délais d'ingestion.
- Au sein de chaque fenêtre, les enregistrements sont agrégés (min, max, moyenne des températures).
Canonicalisation Déterministe :
- Pour éliminer le non-déterminisme causé par l'ordre des enregistrements, le système applique un JSON Canonique à tous les enregistrements au sein d'une fenêtre.
- Ce processus implique la suppression des champs inconsistants, la normalisation des horodatages en UTC (ISO-8601) et le tri lexicographique des clés d'objets.
- Les enregistrements sont ensuite dédoublonnés.
Construction de l'Arbre de Merkle :
- Au lieu d'une chaîne de hachage linéaire, le système construit un Arbre de Merkle à partir des enregistrements canonicalisés.
- Les nœuds feuilles sont des hachages SHA-256 des enregistrements canoniques.
- Les nœuds internes sont des hachages de la concaténation des nœuds enfants.
- La Racine de Merkle finale sert de compromis (commitment) cryptographique compact pour l'ensemble de la charge utile de la fenêtre.
Ancrage sur la Blockchain (Points de contrôle) :
- La charge utile complète reste hors chaîne (off-chain) (stockée dans un système de fichiers distribué en tant que NDJSON).
- Un point de contrôle (checkpoint) contenant la Racine de Merkle, les limites d'offset Kafka (offsetStart, offsetEnd), le nombre d'enregistrements, le chemin de la charge utile et le hachage de la charge utile est publié sur un flux MultiChain.
- MultiChain est choisi pour ses fonctionnalités de flux clé-valeur append-only et sa nature avec permission, évitant la complexité des contrats intelligents au profit d'une logique d'application externe.
Vérification :
- Un auditeur indépendant peut vérifier l'intégrité d'une fenêtre en :
  1. Récupérant les métadonnées du point de contrôle (Racine de Merkle $R$ et nombre d'enregistrements $N$ ) depuis la blockchain.
  2. Chargant la charge utile hors chaîne.
  3. Re-canonicalisant les enregistrements et en re-calculant la Racine de Merkle ( $\hat{R}$ ) et le nombre d'enregistrements ( $\hat{N}$ ).
  4. Comparant $\hat{R}$ avec $R$ et $\hat{N}$ avec $N$ . La vérification réussit uniquement si les deux correspondent.

3. Contributions Clés

Provenance de Fenêtre Déterministe : L'introduction d'une méthode pour créer des fenêtres de flux reproductibles en utilisant des limites alignées sur l'époque et une sérialisation canonique, résolvant le non-déterminisme inhérent au traitement de flux standard.
Arbre de Merkle plutôt que Chaînes de Hachage : Un passage des chaînes de hachage linéaires aux arbres de Merkle pour la provenance des fenêtres, réduisant la complexité de vérification de linéaire à logarithmique par rapport au nombre d'enregistrements.
Séparation Hors-Chaîne/Sur-Chaîne : Une architecture évolutive où les charges utiles larges et mutables sont stockées hors chaîne, tandis que les ancres cryptographiques immuables (racines de Merkle) et les métadonnées sont stockées sur la chaîne, évitant l'encombrement de la blockchain.
Auditabilité Indépendante : Un cadre permettant à des auditeurs tiers de vérifier l'intégrité et la correction des analyses dérivées (ex. : les moyennes de température) sans avoir besoin d'accéder à l'état interne du moteur de streaming.

4. Évaluation et Résultats

Le système a été évalué en utilisant des données météorologiques en temps réel de Berlin.

Reproductibilité : Des exécutions indépendantes sur différents matériels (MacOS M2 et M4) avec Java 21 ont produit des résultats strictement identiques pour le JSON canonique, le SHA-256 de la charge utile et les racines de Merkle, confirmant l'élimination du non-déterminisme induit par l'environnement.
Coût de Vérification :
- Le temps de vérification de bout en bout ( $T(n)$ ) évolue linéairement avec le nombre d'enregistrements ( $n$ ), suivant le modèle $T(n) = \alpha n + \beta$ .
- Le système a démontré un haut débit (enregistrements par seconde) lors de la vérification, sans effondrement des performances à mesure que la taille des fenêtres augmentait.
- Les coûts de canonicalisation et de hachage ont montré une mise à l'échelle linéaire, et la construction de l'arbre de Merkle est restée proche du linéaire.
Performance de la Blockchain :
- L'ancrage des points de contrôle en conditions réelles a résulté en un faible nombre de transactions par seconde (TPS) (0–0,015 éléments/s) en raison de la nature peu fréquente de la fermeture des fenêtres par rapport aux taux d'événements bruts.
- Le benchmarking avec des éditeurs parallèles a montré que MultiChain peut gérer des TPS plus élevées (jusqu'à ~2,1 tx/s pour de petites charges utiles) mais atteint un point de saturation (autour de 8 travailleurs) dû à son algorithme de consensus round-robin.

5. Signification et Revendications

Le papier affirme que sa conception permet à des auditeurs indépendants de vérifier trois aspects critiques du traitement de flux :

La complétude des charges utiles des fenêtres (garantissant qu'aucun enregistrement n'a été supprimé ou ajouté).
La sérialisation canonique des données (garantissant un traitement déterministe).
La correction des analyses dérivées (ex. : vérifier qu'une température moyenne rapportée est mathématiquement cohérente avec les enregistrements sous-jacents).

Les auteurs positionnent ce travail comme une solution au "fossé d'auditabilité" dans le traitement de flux moderne. En combinant le fenêtrage déterministe avec l'ancrage cryptographique, le système permet un re-traitement reproductible des flux de données, une capacité actuellement absente des plateformes de streaming standards. Le papier note modestement que, bien qu'il résolve l'intégrité et l'auditabilité, il ne traite pas encore de la signification sémantique des données (nécessitant des travaux futurs avec RDF) ni des préoccupations de confidentialité (suggérant les preuves à divulgation nulle de connaissance comme direction future). Il conclut que la blockchain peut être intégrée avec succès aux plateformes de streaming pour fournir une couche de référence fiable et immuable pour la provenance des données.