Flowchain 技術筆記 #1, 關於 Chunk 切片的技術問題

[jollen]

關於讀者詢問關於 Flowchain 的技術問題解釋。

Q1: txID 是多次 hash 生成，所以攻擊者無法預測 chunked data 是由哪個節點打包嗎？

A: Flowchain 在設計之初，就是考慮如何實現一個安全的分佈式帳本（Distributed Ledger），因此有二個關鍵的技術問題：(1) 如何實現分佈式的網路拓璞（Topology）、(2) 每一個數據切片（chunk data）該如何對應到處理節點。有了以上二個問題做為前提，才有了 P2P 的架構設計，以及 Chord 演算法的實現。

Chord 算法對於 P2P 的拓璞維護，採取了一個稱之為金手指（Finger Table）的觀念。簡而言之，finger table 運用前節點（precedentor）以及後節點（sucessor）的觀念，將 P2P 抽像化為 Ring 的結構；因此，不同的 Chunk Data 就會在這裡 Ring 裡「流動」，直到 Chunk Data 的 hash 值（即 TxID）落在某二個節點的 Node ID（亦為 hash 值）之間。當 Chunk Data 落在這二個節點之間時，就由其中一個節點來打包這筆數據切包（Chunked Data）。

因此，要計算 Chunk Data 最終由哪一個節點打包，是極為困難的技術問題；要實現這項技術，必須搜尋出P2P 上的「所有節點」，並且能取得所有節點的「Finger table」，才能計算出負責打包 Chunk Data 的節點。此外，這個 P2P 網路必須相當「穩定」，也就是這段計算（預測）該打包節點的時間內，不會有節點退出或加入（這個現象稱為 Churn），也不會有任何節點更新 Finger Table。由於 Finger Table 的維護，有一定的更新頻率，因此「預測」是理論上幾乎不可能實現的。

Q2: 關於 LC3 2018 演講 PPT 的 Page. 48：Step 9 和 Step 10，似乎找到 txID 的 Block 就可以設置 verified。

如上述問題與說明，txID 理論上是非常難以攻擊的（預測打包節點）。關於 Step 9 與 Step 10（應該是上述 PPT 的 P.56）：Step 7 到 Step 12 是 Auditing 過程，也就是在完成 Chunk Data 打包後，再次行驗證的過程，其實就是一種「共識」算法。Step 7 通知任何一個節點，根據 Chunk Data 與 txID 在 P2P 中「Lookup」，如果能找到匹配的 txID，表示這筆 Chunk Data 確實紀錄在帳本中了。

後記

Flowchain 在設計之初（最早開始於 2015 年），就希望能做出一個非常安全，又「極為簡潔」的 DLT 系統；在 IPFS 出世前，其實「存儲」一直是 Flowchain 在完成 DLT 後的一個大問題。不過，隨著 IPFS 的成熟，目前 Flowchain x IPFS 已經達到大約是 Beta 階段了。

觀點

分佈式帳本的設計，應該與分佈式存儲分離設計（Decoupled），也就是並非所有存儲的數據都要「過帳」。