稽核

本文採用時代性證明違約協定，服務提供者於一個時代(epoch)開始時會模 擬資料庫系統的結構為每個資料庫建立一棵 Merkle Tree 如圖 四-3，並推導出樹 的根雜湊值代表一個時代開始時資料庫的狀態，交給所有能存取該資料庫的客 戶保存，稽核時服務提供者會將欲稽核資料庫的 Merkle Tree 交給稽核者，稽核 者也會跟該帳戶下能存取這資料庫的客戶收集最後一個證據，首會先比對服務 提供者與客戶這時代的根雜湊值是否一樣，再來根據每個證據中的更新該棵

Merkle Tree，最後推導出樹的根雜湊值與服務提供者依據目前資料庫資料推導而 得的根雜湊值做比對，如果根雜湊值一樣則稽核成功，就能將服務提供者此時 代的所有證據都清除並進入下一個時代，稽核總共有 15 個步驟以下將詳述所有 步驟：

Service Provider

ClientA

ClientB

ClientC

3.1 return latest ack

& root hash

Auditor

1. audit request 2. start audit

7. receive Merkle Tree

& all ack 4. send Merkle Tree & all ack 5. derive root hash

8. check ack signature

& compare latest ack of client to ack of service provider 9. Import Merkle Tree

& redo operation 10. derive root hash

6. send root hash

11. receive service provider root hash

12. send audit result 13. receive audit result 15. Broadcast next epoch

root hash to client 3. collect latest ack

14. clean all attestation

& entry next epoch

圖 四-3 雲端資料庫使用 Four-Step-DH 架構流程圖 Step 1: 稽核者向服務提供者提出稽核請求。

Step 2: 服務提供者收到稽核請求。

Step 3: 稽核者向該使用者帳戶下的所有客戶收集最後一個證據，也就是該客

戶的最後一個操作承認訊息(acknowledgment message)。

Step 3.1: 使用者帳戶下的客戶將自己的最後一個操作承認訊息與這個時代

Step 7: 稽核者接收服務提供者傳來目前這時代開始時的 Merkle Tree 和這時代

所有的操作承認訊息。

Step 8: 稽核者首先驗證從服務提供者得到的承認訊息電子簽章，接著再比對

從客戶得到的最後一個承認訊息與服務提供者提供的承認訊息是否相同，

如果都相同即證明所有承認訊息沒有被竄改。

Step 9: 稽核者將 Merkle Tree 匯入本地資料庫中，並執行每一個承認訊息中此

次 OPi的 SQL 指令。

Step 10: 稽核者完成這時代所有的動作後算出本地資料庫的根雜湊值。

Step 11: 稽核者接收服務提供者傳來目前雲端資料庫系統最新的根雜湊值。

Step 12: 稽核者比較本地資料庫的根雜湊值與從服務提供者得來的根雜湊值，

如果相同即證明雲端資料庫經過這時代所有的操作後的狀態是正確的，並 回傳稽核成功告知服務提供者。

Step 13: 服務提供者等待稽核者傳送稽核結果。

Step 14: 如果稽核成功服務提供者就將該使用者帳戶下目前這時代的證據都清

除並進入下一個時代，將新算出的根雜湊值作為新時代開始時雲端資料庫 系統的狀態。

Step 15: 稽核者將新的根雜湊值廣播給使用者帳戶底下的所有客戶，告知目前 這時代結束已進入下一個時代。

26