B+ Tree

在[12]當中提到一個對於資料庫稽核的方法，其資料結構使用 B+Tree[13]與 Full Binary Hash Tree，B+Tree 是一種樹資料結構，使用(index, value)的格式儲存

資料，特點是儲存的資料是用index 排序過的，將這個特性運用在資料庫稽核上 可以在範圍查找(Range Select)中獲得很好的效率。

其稽核的方式是將資料庫中取一個欄位作為index，將每個 row 用 SHA-256 計算雜湊值，將雜湊值作為 value，用這個方式將整個資料庫中的所有資料存到 B+Tree 中，如圖 1，之後將 B+Tree 中每個葉節點(LeafNode)計算出一個雜湊值，

按照順序放到一個Full Binary Hash Tree，如圖 2，從葉節點將資料一層一層計算

雜湊值，直到運算出樹頂端的雜湊值稱之為Root Hash。因為密碼學加密函數的 特性，倘若有修改過其中一個節點的值，那麼就會得出不同的 Root Hash，所以 我們可以用 Root Hash 來驗證整個資料庫的完整性。這個 Root Hash 要經過用戶

與伺服器交互簽章，讓雙方不能否認這個證據以支援POV。

圖 1 範例 B+ Tree

圖 2 範例 Full Binary Hash Tree

稽核資料庫時，假設要稽核id=40 的資料，要先向伺服器提出稽核，伺服器 先從B+Tree 中找到資料所在的葉節點，接著定位葉節點的編號，到 Merkle Hash Tree 中取得第 4 個葉節點的 slice，如圖 2 圈起來的部分，將要稽核的該筆資料

與slice 回傳給用戶，用戶即可利用回傳的資料計算雜湊值，與自己保留的 Root

Hash 進行比對，如果相等則稽核完成。如果要稽核的資料比較靠右側，則會造

成定位的時間拉長，這個是B+Tree 架構的第一個問題。

若要進行範圍查詢時，假設我們向資料庫查詢 10<id<34 的資料時，服務提 供者除了回傳資料結果外，會透過B+Tree 取出 E2、E3，另外將 Merkle Hash Tree 中包括E2、E3 的 Partial Merkle Tree 回傳給用戶端進行做稽核，所以稽核速度會 非常快。

新增刪除資料時，與稽核的步驟類似，先將資料欲插入的B+Tree 葉節點與 對應的 slice 回傳給使用者稽核，將資料插入後，用戶與伺服器同時做更新 slice 的動作，取出的Root Hash 雙方進行比對，若無誤則進行交互簽章，以支援 POV。

但是B+Tree 有自動平衡的特性，有時候在插入資料會造成節點分裂或合併的情 況，如圖3，假設 B+Tree 的 Max degree = 5，如果插入 id = 82 時會造成 E7 這個 葉節點分裂，對應到Merkle Hash Tree 上時，E7 右邊的所有葉節點都要往右移一 格，如圖4，要更新的 Partial Merkle Tree 會比未分裂的狀況多很多，這個是 B+Tree 架構的第二個問題。

64 90

H1|2 H3|4 H5|6 H7|8 H9|10

H9|10

H1|2 H3|4 H5|6 H7|8 H8|9

H89|10

H1|2 H3|4 H5|6 H7|8 H9|10

H9|10

H9|10 H1~8

Right shift

圖 4 B+ Tree 分裂問題示意圖(分裂後)

為了解決這兩個問題，作者使用限制B+Tree 高度的作法，先規定 B+Tree 成 長到指定高度時就停止分裂，當葉節點中內容數量超過 Max degree 時，以建立 子樹的方式取代分裂，如圖5，B+Tree 的子樹也對應產生一個 Merkle Hash Tree，

用相同的方式去建立。新增、刪除與稽核的方式與原先的方式相同。

圖 5 B+ Tree 建立子樹示意圖

圖 6 B+ Tree 子樹資料過度集中示意圖

雖然解決了定位與分裂的問題，卻產生了新的問題，若資料過度集中於某一

個特定範圍，可能會造成如圖6 的狀況，但是這種狀況不易產生，詳細的數據將

在第四章呈現。