Open jollen opened 5 years ago
關於讀者詢問關於 Flowchain 的技術問題解釋。
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 的維護，有一定的更新頻率，因此「預測」是理論上幾乎不可能實現的。
如上述問題與說明，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），也就是並非所有存儲的數據都要「過帳」。
關於讀者詢問關於 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），也就是並非所有存儲的數據都要「過帳」。