方法二

在上述的作法中，我們利用了 Aggregate Hash 實現了以往[13]所使用的 FBHTree 中相同的功能，卻用更簡潔快速的做法來實現快速稽核，但是在此我 們有了新的疑慮，在源源不斷的感測器監測資料流入的狀態之下，累積起來的 資料筆數數以百萬甚至千萬計，若醫院稽核時發現與儲存服務商所保存的陣列 證據不一致而必須進行 POV 時，醫院方勢必只能要求儲存服務商將有疑慮的陣 列位置下所有 Hash pairs 回傳自行驗算。

在[13]的實驗中我們觀察到 FBHTree 結構若塞入極大量的資料，將會有兩 種解決方法，第一種我們可以讓他自動加大層數以容納更多筆資料的同時其 PB-pairs 碰撞不會隨之升高，但這做法的有個明顯的缺點，其稽核時間將會大幅 提升，而儲存服務商所保存的結構大小也會隨之暴漲，而第二種作法則是固定 leaf node 數量不會隨著資料筆數而作變動，但很明顯的 leaf node 下的 PB-pairs 碰 撞也會大幅提升，這也導致處理 PB-pairs 碰撞時間與整體稽核時間大幅拉長。

預見此種場景下，使用類似處理 Hash pair 作法的 Aggregate Hash 必須將所 有的 Hash pairs 回傳回來，其 POV 時間最大關聯就是在回傳 Hash pairs，所以在 此我們將此快速稽核架構針對這點融合了 Aggregate Hash 與 FBHTree 各自的優 勢，創造出圖 14 方法二的做法來解決本節開頭所提之極大量資料即時 POV 問 題。

首先我們將原始沒有限制資料筆數的 Aggregate Hash 陣列，轉變成以固定 天數間隔內之資料量的多個 Aggregate Hash 陣列，例如：一個陣列只保存一周 七天間隔的資料，下個間隔的資料保存在下個陣列以此類推，這間接限制每個 陣列插入筆數的大小，避免方法一插入太多筆資料導致大量 Hash pairs 的碰撞的 傳遞與計算問題。

…

…

: Aggregate hash array : FBHTree leaf node : FBHTree root node

圖 14 方法二架構圖

其中 leaf node 存每個間隔醫院與儲存服務商雙方簽章過的𝐴𝐻與𝐴𝐻的最新

𝐴𝐻 , 𝐴𝐻 , 𝐴𝐻₃, 𝐴𝐻₄,…），將最終運算的 root hash 與更新的版本號再由醫院與儲

存服務商雙方簽章（ 𝑡 ℎ𝑎 ℎ, 𝑛），此做法與最初的方法比較，儲存服務商 必須保存每個間隔的陣列與每個陣列位置下的 hash pairs 及（𝐴𝐻_𝑖, 𝑛）外，還要 額外存 FBHTree 結構的一維陣列及（ 𝑡 ℎ𝑎 ℎ, 𝑛），但是醫院從原本需要保

存陣列變成僅需要保存 （ 𝑡 ℎ𝑎 ℎ, 𝑛）與 （𝐴𝐻_𝑖, 𝑛）即可，減少所需的儲 存空間。

在 POV時，首先利用（ 𝑡 ℎ𝑎 ℎ, 𝑛）確認版本號後，醫院推算出欲 POV

的（𝑡𝑖𝑚𝑒, 𝐼𝐷）所對應的周期間隔，使用自己保存該週期的（𝐴𝐻_𝑖, 𝑛） POV 上 層的 FBHTree，由儲存服務商傳遞 Slice 由兩方各自推算 root hash 是否相等後完 成第一階段 POV，第二階段進入該週期間格的 Aggregate Hash 陣列 POV，醫院 方將所有自雲端服務商接收到的所有 hash pairs 並做運算重建陣列，最後對照醫 院方自已所持有的陣列內容。。

融合了 FBHTree 醫院方僅需保存少量資料與 Aggregate Hash 資料插入刪除 與 POV 速度的優點，這使我們可以利用此方法完美的解決掉極大量資料下兩者 所遇到 POV 效能上的瓶頸。