💻 computer science

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

本文提出了一种面向 Kafka Streams 的多链支持溯源架构，通过将窗口化数据的加密默克尔根锚定至区块链，同时将有效载荷保留在链下，从而确保实时天气数据处理具有确定性、可审计性和可重现性。

原作者： Niaz Mohammad Ramaki, Florian Schintke

发布于 2026-01-27

📖 1 分钟阅读☕ 轻松阅读

原作者： Niaz Mohammad Ramaki, Florian Schintke

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在观看一场柏林天气状况的实时新闻直播。每隔几分钟，新闻主播（计算机系统）就会公布过去一小时的平均气温。

问题所在：“电视直播”的魔术诡计
通常，实时数据处理有点像一个魔术师的戏法。计算机接收成千上万个温度读数，将它们重新排列，然后吐出一个平均值。但因为计算机运行极快，且互联网有时会出现网络抖动，数据的到达顺序可能会发生变化。

如果你要求计算机进行两次完全相同的计算，它可能会给出两个略有不同的答案。

运行 1： 计算机看到了三个温度读数，并说：“平均值是 21.0°C。”
运行 2： 由于微小的网络延迟，第四个读数在稍后一瞬间到达。计算机将其放入了另一个“桶”（时间窗口）中，并说：“平均值是 21.75°C。”

这使得审计人员无法断言：“我确信计算机计算得完全正确，”因为每次重播录像时，结果都会发生变化。这就像是在尝试验证一道数学题，而题目中的数字却一直在不断重排。

解决方案：“密封信封”系统
本文作者构建了一个系统来解决这个问题，主要使用了两个工具：Kafka Streams（执行计算的计算机）和 MultiChain（一种特殊的、不可更改的数字账本，类似于区块链）。

以下是该系统的运作方式，通过一个简单的类比来逐步说明：

1. “固定时间桶”（确定性窗口化）

系统不再根据数据“实际到达”的时间来决定何时停止计数并开始新的平均值计算，而是使用固定时间桶。

类比： 想象一条工厂传送带，无论发生什么，它都会每隔整整 2 小时停一次。
运作方式： 无论数据是在下午 1:59 到达还是在 2:01 到达，系统都会强制将其归入“下午 1:00 至下午 3:00”这个桶中。这确保了每次运行计算时，都会有完全相同的数据进入完全相同的桶中。

2. “标准化食谱”（规范化 JSON）

即使数据在同一个桶里，计算机在记录方式上也可能存在差异（例如，“10:00:00”与“10:00”）。

类比： 想象一位厨师坚持要求每一件食材在放入锅中之前，必须以完全相同的笔迹和顺序被记录下来。
运作方式： 系统将每条温度记录重新改写为一种严格的标准格式。这保证了数据在每次处理时看起来都是完全一致的。

3. “数字封蜡”（默克尔树/Merkle Trees）

现在，数据已经处于固定的时间桶中，并且以标准化的格式记录好了，系统需要证明这些数据未被篡改。

类比： 想象你有一堆收据。你不是把整堆收据锁进保险箱，而是将它们进行哈希处理（转化为唯一的数字指纹），并将它们排列成一个金字塔形。然后，你取出金字塔最顶端的那个数字——默克尔根（Merkle Root）——并将其封入一个蜡封信封中。
运作方式： 系统为该 2 小时时间桶内的所有温度数据创建一个“默克尔根”。这个根是一个单一的、微小的代码，代表了整个数据集。如果其中哪怕只有一个温度数值发生变化，这个代码就会发生彻底改变。

4. “不可更改的日志簿”（区块链锚定）

这正是奇迹发生的地方。系统并不会将沉重、杂乱的温度数据直接放在区块链上（那样太慢也太昂贵了）。

类比： 你将沉重的收据保存在抽屉里（链下存储），但你会将封印编号（默克尔根）和页码记录在一个公开、不可更改的日记本中（区块链）。
运作方式： 系统将默克尔根和“页码”（Kafka 偏移量）写入 MultiChain 区块链。区块链充当了一个永久、不可篡改的见证者。

5. “审计检查”（验证）

现在，假设一名审计人员想要检查天气报告是否正确。

他们查看日记（区块链），确认该时间段对应的“封印编号”应该是多少。
他们去**抽屉（链下存储）**中取出实际的收据（温度数据）。
他们重新运行“标准化食谱”和“金字塔封印”计算。
结果： 如果新的封印编号与日记中的编号相匹配，则证明数据是 100% 真实且完整的。如果不匹配，则说明有人篡改了收据。

研究结果
作者使用柏林真实的气象站对该系统进行了测试。他们发现：

可重现性： 他们可以在两台不同的计算机上运行计算，并且每次都会产生完全相同的结果。
速度： 进行数学校验（验证）的速度非常快，即使处理大量数据也是如此。
效率： 区块链并没有被堵塞，因为它只存储了微小的“封印编号”，而不是沉重的数据本身。

总结
本文提出了一种让实时数据流变得“值得信赖”的方法。通过将数据锁定在固定时间桶中、标准化格式，并将结果封存在记录在区块链上的数字信封中，他们使得任何人都能独立验证一项实时计算（如天气平均值）在数学上是正确的，且未被伪造或篡改。

技术摘要：用于 Kafka Streams 确定性流处理的多链区块链数据溯源

1. 问题陈述

实时数据流处理流水线（例如基于 Kafka Streams 或 Apache Flink 构建的系统）面临着关于可审计性和可复现性的关键挑战。这些系统本质上是非确定性的，因为它们依赖于运行时调度、窗口触发器、网络抖动以及记录到达顺序。因此，在不同时间或在不同节点上处理相同的输入流，可能会产生不同的输出。

目前的基于区块链的溯源方案通常依赖哈希链来存储数据指纹。然而，作者指出这种方法在流处理中存在两个主要缺陷：

存储开销： 随着链的增长，存储需求显著增加。
计算成本： 验证过程需要对长链进行重复哈希，这对于大规模数据集而言效率低下。
此外，哈希链将溯源与摄取顺序绑定在一起，这使得它们不适用于在因外部因素（如重平衡）导致记录成员发生变化的重键（re-keyed）或基于时间的窗口下的确定性重放。

2. 方法论

本文提出了一种区块链支持的溯源架构，该架构将沉重的数据负载与区块链解耦，仅在区块链上存储加密锚点和元数据。该系统使用 Kafka Streams 进行处理，并使用 MultiChain（一种许可链）进行锚定。

核心组件与工作流

摄取与处理：
- 来自两个站点（柏林-勃兰登堡和柏林-滕佩尔霍夫）的实时天气数据通过 Kafka 进行摄取。
- 系统使用基于 Epoch 对齐的翻转窗口（epoch-aligned tumbling windows）。与处理时间窗口不同，这些是固定的绝对间隔（例如，从特定 Epoch 时间开始的 2 小时块），以确保无论摄取延迟如何都能实现全局确定性。
- 在每个窗口内，记录被聚合（计算最高温、最低温、平均温度）。
确定性规范化（Deterministic Canonicalization）：
- 为了消除由记录顺序引起的不确定性，系统对每个窗口内的所有记录应用 Canonical JSON。
- 此过程包括移除不一致的字段、将时间戳标准化为 UTC（ISO-8601），并按字典顺序对对象键进行排序。
- 随后对记录进行去重。
Merkle 树构建：
- 系统没有使用线性哈希链，而是从规范化后的记录中构建 Merkle 树。
- 叶节点是规范化记录的 SHA-256 哈希值。
- 内部节点是连接子节点的哈希值。
- 最终的 Merkle 根（Merkle Root） 作为整个窗口有效载荷的紧凑型加密承诺。
区块链锚定（检查点）：
- 完整的有效载荷保持在链下（存储在分布式文件系统中，格式为 NDJSON）。
- 包含 Merkle 根、Kafka 偏移量边界（offsetStart、offsetEnd）、记录计数、有效载荷路径和有效载荷哈希值的**检查点（checkpoint）**被发布到 MultiChain 流中。
- 选择 MultiChain 是因为它具有追加式、键值对流的特性以及许可性质，避免了使用智能合约的复杂性，转而使用外部应用程序逻辑。
验证：
- 独立的审计员可以通过以下步骤验证窗口的完整性：
  1. 从区块链获取检查点元数据（Merkle 根 $R$ 和记录数 $N$ ）。
  2. 加载链下有效载荷。
  3. 重新进行规范化处理，并重新计算 Merkle 根 ( $\hat{R}$ ) 和记录数 ( $\hat{N}$ )。
  4. 将 $\hat{R}$ 与 $R$ 以及 $\hat{N}$ 与 $N$ 进行比较。只有当两者都匹配时，验证才通过。

3. 核心贡献

确定性窗口溯源： 引入了一种通过 epoch 对齐边界和规范化序列化来创建可复现流窗口的方法，解决了标准流处理中固有的非确定性问题。
以 Merkle 树取代哈希链： 从线性哈希链转向用于窗口溯源的 Merle 树，将验证复杂度从相对于记录数量的线性降低到对数级。
链上/链下分离： 一种可扩展的架构，其中大型、可变的有效载荷存储在链下，而不可变的加密锚点（Merkle 根）和元数据存储在链上，从而防止区块链膨胀。
独立可审计性： 一个允许第三方审计员在无需访问流引擎内部状态的情况下，验证派生分析结果（例如温度平均值）的完整性和正确性的框架。

4. 评估与结果

系统使用来自柏林实时天气数据进行了评估。

可复现性： 在使用 Java 21 的不同硬件（MacOS M2 和 M4）上进行的独立运行产生了字节一致的 Canonical JSON、有效载荷 SHA-256 和 Merkle 根，证实了环境诱导非确定性的消除。
验证成本：
- 端到端验证时间 ( $T(n)$ ) 随记录数 ( $n$ ) 呈线性缩放，遵循模型 $T(n) = \alpha n + \beta$ 。
- 系统在验证过程中表现出高吞吐量（每秒记录数），且随着窗口大小的增加，性能并未出现崩溃。
- 规范化和哈希成本显示出线性缩放，且 Merkle 树构建保持在接近线性的水平。
区块链性能：
- 由于窗口关闭的频率远低于原始事件速率，实际情况下的检查点发布呈现低 TPS（0–0.015 items/s）。
- 通过并行发布者的基准测试表明，MultiChain 可以处理更高的 TPS（对于小负载可达 ~2.1 tx/s），但由于其轮询共识算法，会在约 8 个工作者处达到饱和点。

5. 意义与主张

论文声称其设计使独立审计员能够验证流处理的三个关键方面：

窗口有效载荷的完整性（确保没有丢失或增加记录）。
规范化序列化（确保数据处理的确定性）。
派生分析的正确性（例如，验证报告的平均温度与底层记录在数学上是否一致）。

作者将这项工作定位为解决现代流处理中“可审计性缺口”的方案。通过结合确定性窗口化与加密锚定，该系统允许对数据流进行可复现的重处理，这是目前标准流平台所缺乏的能力。论文谦虚地指出，虽然它解决了完整性和可审计性问题，但尚未解决数据的语义含义（需要未来结合 RDF 的研究），也未涉及隐私问题（建议将零知识证明作为未来的研究方向）。结论认为，区块链可以成功集成到流平台中，为数据溯源提供一个值得信赖且不可篡改的参考层。