技術要約：決定論的ストリーム処理のためのMultiChainを用いたマルチチェーン・ブロックチェーン・データプロベナンス

1. 問題提起

Kafka StreamsやApache Flinkなどの上で構築されるリアルタイム・データストリーム処理パイプラインは、**監査可能性（auditability）と再現性（reproducibility）**に関する重大な課題に直面している。これらのシステムは、ランタイムのスケジューリング、ウィンドウのトリガー、ネットワークのジッター、およびレコード到着順序への依存関係により、本質的に非決定論的である。その結果、同一の入力ストリームであっても、異なるタイミングや異なるノードで処理された場合、出力が異なる可能性がある。

現在のブロックチェーンを用いたプロベナンス（由来）ソリューションの多くは、データの指紋を保存するためにハッシュチェーンに依存している。しかし、著者らはこのアプローチにおけるストリーム処理への適用において、主に2つの欠点を指摘している。

1. ストレージのオーバーヘッド： チェーンが成長するにつれ、ストレージ要件が大幅に増加する。
2. 計算コスト： 検証には長いチェーンの反復的なハッシュ計算が必要であり、これは大規模なデータセットに対して非効率である。
   さらに、ハッシュチェーンはプロベナンスをインジェクション（取り込み）順序に拘束するため、リキーイングや時間ベースのウィンドウにおいて、外部要因（例：リバランシング）によってレコードのメンバーシップが変化する場合の決定論的なリプレイには適していない。

2. メソドロジー

本論文では、重いデータペイロードをブロックチェーンから切り離し、暗号的なアンカーとメタデータのみを格納するブロックチェーン・バック・プロベナンス・アーキテクチャを提案している。システムは、処理にKafka Streamsを、アンカリングにMultiChain（許可型ブロックチェーン）を使用して実装されている。

コアコンポーネントとワークフロー

1. インジェクションと処理：

   • 2つのステーション（ベルリン・ブランデンブルクおよびベルリン・テンペルホーフ）からのリアルタイムの気象データがKafka経由で取り込まれる。
   • システムは**エポック整列済みタンブリングウィンドウ（epoch-aligned tumbling windows）**を使用する。これらは、処理時間のウィンドウとは異なり、特定のエポック時刻から始まる固定された絶対間隔（例：2時間のブロック）であり、インジェクションの遅延に関わらずグローバルな決定論性を確保する。
   • 各ウィンドウ内では、レコードが集計される（最小値、最大値、平均温度）。

2. 決定論的なカノニカリゼーション（正規化）：

   • レコードの順序に起因する非決定性を排除するため、システムは各ウィンドウ内のすべてのレコードに対してCanonical JSONを適用する。
   • このプロセスには、一貫性のないフィールドの削除、UTC（ISO-8601）へのタイムスタンプの正規化、およびオブジェクトキーの辞書順ソートが含まれる。
   • その後、レコードの重複排除が行われる。

3. Merkle Tree（メルクル木）の構築：

   • 線形なハッシュチェーンの代わりに、システムはレコードからMerkle Treeを構築する。
   • リーフノードは、カノニカル化されたレコードのSHA-256ハッシュである。
   • 内部ノードは、連結された子ノードのハッシュである。
   • 最終的な**Merkle Root（メルクルルート）**は、ウィンドウ全体のペイロードに対するコンパクトな暗号学的コミットメントとして機能する。

4. ブロックチェーン・アンカリング（チェックポイント）：

   • フルペイロードはオフチェーンに留まる（NDJSONとして分散ファイルシステムに保存される）。
   • Merkle Root、Kafkaオフセット境界（offsetStart、offsetEnd）、レコード数、ペイロードパス、およびペイロードハッシュを含むチェックポイントが、MultiChainストリームに公開される。
   • MultiChainは、その追記型のキー・バリュー・ストリーム機能と許可型という性質から選定されており、スマートコントラクトの複雑さを避け、外部アプリケーションロジックを活用している。

5. 検証：

   • 独立した監査者は、以下の手順でウィンドウの完全性を検証できる。
     1. ブロックチェーンからチェックポイントのメタデータ（Merkle Root $R$ およびレコード数 $N$）を取得する。
     2. オフチェーンのペイロードをロードする。
     3. レコードを再カノニカル化し、Merkle Root ($\hat{R}$) とレコード数 ($\hat{N}$) を再計算する。
     4. $\hat{R}$ と $R$、および $\hat{N}$ と $N$ を比較する。両方が一致する場合のみ、検証は成功する。

3. 主な貢献

• 決定論的ウィンドウ・プロベナンス： エポック整列済みの境界とカノニカル・シリアライゼーションを用いた再現可能なストリームウィンドウを作成する手法を導入し、標準的なストリーム処理に固有の非決定性を解決した。
• ハッシュチェーンに対するMerkle Tree： ウィンドウのプロベナンスにおいて線形ハッシュチェーンからMerkle Treeへと移行し、検証の複雑さをレコード数に対して線形から対数へと低減させた。
• オフチェーン/オンチェーンの分離： 大きく可変的なペイロードはオフチェーンに保存し、不変の暗号的アンカー（Merkleルート）とメタデータのみをオンチェーンに保存することで、ブロックチェーンの肥大化を防ぐスケーラブルなアーキテクチャを実現した。
• 独立した監査可能性： サードパーティの監査者が、ストリーミングエンジンの内部状態にアクセスすることなく、派生した分析（例：温度平均）の完全性と正確性を検証できるフレームワークを提供した。

4. 評価と結果

システムは、ベルリンのリアルタイム気象データを用いて評価された。

• 再現性： Java 21を用いた異なるハードウェア（MacOS M2およびM4）上での独立した実行において、Canonical JSON、ペイロードのSHA-256、およびMerkleルートがバイト単位で同一の結果を示し、環境に起因する非決定性が排除されていることが確認された。
• 検証コスト：
  • エンドツーエンドの検証時間 $T(n)$ は、レコード数 $n$ に対して $T(n) = \alpha n + \beta$ というモデルに従い、線形にスケールする。
  • システムは検証中に高いスループット（レコード/秒）を示し、ウィンドウサイズが増加してもパフォーマンスの崩壊は見られなかった。
  • カノニカリゼーションとハッシングのコストは線形のスケーリングを示し、Merkle木の構築はほぼ線形に近い状態を維持した。
• ブロックチェーンの性能：
  • 実際のチェックポイント作成によるTPS（Transactions Per Second）は、生のイベントレートと比較して、ウィンドウのクローズが稀に発生することから、非常に低い値（0–0.015 items/s）となった。
  • 並列パブリッシャーを用いたベンチマークでは、MultiChainはより高いTPS（小さなペイロードに対して最大 ~2.1 tx/s）を処理できるが、そのラウンドロビン方式のコンセンサスアルゴリズムにより、約8個のワーカーで飽和点に達することが示された。

5. 意義と主張

本論文は、その設計がストリーム処理の以下の3つの重要な側面について、独立した監査者による検証を可能にすると主張している。

1. ウィンドウ・ペイロードの完全性（レコードがドロップされたり追加されたりしていないことの保証）。
2. カノニカル・シリアライゼーション（データの決定論的な処理の保証）。
3. 派生した分析の正確性（例：報告された平均気温が基礎となるレコードと数学的に整合していることの検証）。

著者らは、本研究を、現代のストリーム処理における「監査可能性のギャップ」に対する解決策として位置づけている。決定論的なウィンドウ処理と暗号的アンカリングを組み合わせることで、本システムはデータ・プロベナンスの信頼できる不変のリファレンス層を提供できる。論文では、本手法は完全性と監査可能性を解決するものの、データの意味論的（セマンティック）な内容にはまだ対処しておらず（RDFを用いた将来の研究が必要）、プライバシーの問題についても（ゼロ知識証明を将来の方向性として）示唆していることを謙虚に述べている。結論として、ブロックチェーンはストリーム処理プラットフォームと統合することで、データのプロベナンスに対して信頼できる不変のリファレンス層を効果的に提供できると結論付けている。