在本章節，我們會利用實驗來說明在上一個章節所提到整體系統架構的數 據，實現整體快速稽核架構的程式語言為 Java，在此實驗會分為單一電腦測試 以及相同網路區段與相異網路區段的電腦分別扮演儲存供應商以及醫院，扮演 同網段儲存供應商的電腦作業系統為 Windows 10，處理器為 Intel（R） Core（
TM） i7-7700 CPU @3.60GHz，記憶體為 16GB DDR4；扮演異網段儲存供應商 的電腦為 acer Aspire VN7，作業系統為 Windows 10，處理器為 Intel（R） Core
（TM） i5-6300HQ CPU @2.30GHz，記憶體為 16GB DDR4；而醫院方的電腦為 acer Aspire V5，作業系統為 Windows 10，處理器為 Intel（R） Core（TM） i5-4200U CPU @ 1.6GHz，記憶體為 12GB DDR3。
而測試的檔案為 4KB 純文字檔以模擬感測器所產生的資料，假設每日產生 14 萬筆資料並以每周為一個週期，而這一周將產生 100 萬筆資料，比較一、方 法二與FBHTree 這三種方法之一日/一周/一月/三月/六月/一年累計資料量下各種 參數。
在 上 一 章 節 有 提 到 在 面 臨 極 大 量 的 資 料 下 ， 即 使 是 操 作 效 率 非 常 高 Aggregate hash，仍然有可能因為密碼學證據並不符合手上持有的，意即稽核時 發生錯誤而必須進行 POV，所以我們提出了一個結合 Aggregate hash 與 FBHTree 優點的作法，但由於這種作法仍會導致儲存服務商所需保存證據的空間增大，
所以首先先針對各種不同大小的 Aggregate hash 陣列找出空間與效率平衡間最佳 的選擇（表 1、表 2），再來必須為方法二選定適當的 FBHTree 大小，在一年的 假設下選擇使用 leaf node 數量為 128 的 8 層 FBHTree 之參數（表 3），在結合
處在平衡點（見圖 15），分析後主要原因為在過大的陣列上雖然碰撞率較低，
不過也因此消耗了大量的空間儲存此陣列，若以方法二儲存若干個陣列此種影 響也會隨之放大，另外一方面過小的陣列則將導致碰撞率大幅提高，稽核時必 須要大量的 hash pairs 傳送回醫院而傳送時間又因網路節點延遲影響，使得整體 集合時間大幅拉長，這也是我們決定以這個參數作為方法一與方法二 Aggregate hash 陣列大小的參照值。
表 1 各陣列大小稽核時間比較（ms）
𝟐𝟑 𝟐𝟕 𝟐 𝟐 𝟓 𝟐 𝟗
稽核 172.72 25.62 2.84 0.0057 0.0026 Hash pairs
傳送 1870 168 39.42 26.97 24.93
without internet（ms）
POV
with internet（ms）
16.2 128 0.12 19.41
0
130 132 134 136 138 140 142 144 146 148 150 152
CSP WITH HASH PAIRS TRANSATION
𝟐
保存陣列上所需要的空間。
而最後的表8 與表 9 則是呈現了三者在稽核與 POV 時所需的時間消耗，我 們可以發現 FBHTree 在這方面相當突出，因其稽核與 POV 時僅需要驗證一條 Slice 與 root hash，而方法一則是會因為一個陣列中塞入太多筆資料，導致於碰 撞過高且必須回傳的 hash pairs 過多，使得稽核與 POV 時間逐漸增長，方法二 將陣列大小利用固定周期作切割，使得不管是一般稽核或者是更消耗時間的 POV 都能穩定的維持在常數，不會因為資料筆數的增長而成長。
表 4 一日所需同步時間(s)
時間 [13] 3593 Method 1 19 Method 2 19
表 5 運算量比較
Hash 乘除法 模數運算
[13] 3,289,000 2,717,000 143,000 Method 1 572,000 286,000 429,000 Method 2 572,011 286,007 429,001
表 6 不同累計時間 CSP 消耗空間
一日 一周 一月 三月 六月 一年
[13] 52MB 190MB 950MB 2,850MB 5,700MB 11,400MB Method 1 18MB 132MB 663MB 1,978MB 3,958MB 6,859MB Method 2 18MB 132MB 664MB 1,980MB 3,960MB 6,864MB
表 7 不同累計時間醫院消耗空間
一日 一周 一月 三月 六月 一年
[13] 32Byte 32Byte 32Byte 32Byte 32Byte 32Byte Method 1 0.142MB 0.142MB 0.142MB 0.142MB 0.142MB 0.142MB Method 2 0.143MB 0.143MB 0.147MB 0.157MB 0.162MB 0.192MB
表 8 不同累計時間一般稽核時間
一日 一周 一月 三月 六月 一年
[13] 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms Method 1 8.47ms 43.2ms 131.8ms 286.1ms 457.7ms 793.1ms Method 2 27.88ms 61.67ms 61.67ms 61.67ms 61.67ms 61.67ms
表 9 不同累計時間 POV 時間
一日 一周 一月 三月 六月 一年
[13] 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms Method 1 27.81s 87.57s 266.3 596.5s 936.5s 1403s Method 2 27.81s 87.57s 87.57s 87.57s 87.57s 87.57s
最後我們在特別針對方法一與方法二在傳遞證據時的 overhead 做比較如圖 16，在此將不同累計時間周期的實際保存資料做比對如表 10，我們可以發現方 法一在存入資料筆數越多的狀態下，在 POV 時所需回傳的 hash pairs 也會增長
，但是整體的overhead 仍然是維持在 3.2%左右如表 11，而方法二得力於週期切 割使得不管資料累計筆數如何增長，皆能保持不增長且維持在常數狀態，這也 是讓方法二在資料筆數越多，整體overhead 反而呈現下降的主因。
表 10 實際資料與POV 時所需傳遞 hash pairs 比較(MB)
一日 一周 一月 三月 六月 一年
實際資料大小 585 4,100 20,500 61,501 123,003 213,790 Method 1 18 132 663 1,978 3,958 6,859 Method 2 18 132 132 132 132 132
表 11 實際資料與POV 時所需傳遞 hash pairs 比較(%)
一日 一周 一月 三月 六月 一年
Method 1 3.076 3.219 3.234 3.216 3.217 3.208 Method 2 3.076 3.219 0.643 0.214 0.107 0.061
0 200 400 600 800 1000 1200 1400 1600 1800 2000
一日 一周 一月 三月 六月 一年
POV時間(網路)
Method 1 Method 2
X 軸 : 累計資料時間 Y 軸 : POV 時間(s) 圖 16 POV 時間比較（網路）