申訴

前面已經分析完所有錯誤情形，在這個章節將會詳細說明任何錯誤的詳細申 訴流程，包括Owner 要上傳甚麼證據、Contract 會如何判決。

第一段 憑證從樹上消失

定義：Owner 在稽核階段的第三個步驟，檢查憑證資料時，直接找不到憑證

訊息，意即key-value pair 移失。這有兩種可能，第一種是 CA 在申請的時候就未 放入Tree 中，另一種則是 CA 某日不小心刪除 key-value pair。

情境：

圖10 CA 未放入之情境

26

圖11 從樹上消失之情境

申訴依據：𝐴𝐶𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}、𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦}、List of key-value pairs。

申訴步驟：

第一步：Owner 將回條𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦}、Slice、list of key-value pairs 打入 Contract。

第二步：Contract 檢查回條上 CA 簽名是否正確。

第三步：Contract 確認 CO 與 Root hash 是否與本身記錄的一致。

第四步：Contract 計算 Slice、list of key-value pairs 是否正確。

第五步：Contract 檢查 list of key-value pairs 內是否有𝐴𝐶𝑀_{𝑟𝑒𝑝𝑙𝑦}記錄之憑證。

第六步：若List of key-value pairs 查無憑證，則判定 CA 弄丟憑證，Contract 將轉出一筆加密貨幣給 Owner，當作賠償金。

第二段 CA 狀態更新錯誤

定義：Owner 有向 CA 發送𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}，CA 同意請求也給了𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦}，但 Owner 在稽核階段的第三個步驟，檢查憑證資料時，發現 key-value pair 的憑證狀

態與𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦}記錄不同。

27

情境：

圖12 CA 狀態更新錯誤之情境

申訴依據：𝐶𝑆𝑀_{𝑟𝑒𝑞𝑢𝑒𝑡}、𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦}、List of key-value pairs。

申訴步驟：

第一步：Owner 將回條𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦}、Slice、list of key-value pairs 打入 Contract。

第二步：Contract 檢查回條上 CA 簽名是否正確。

第三步：Contract 確認 CO 與 Root hash 是否與本身記錄的一致。

第四步：Contract 計算 Slice、list of key-value pairs 是否正確。

第五步：Contract 比對 List of key-value pairs 內記錄的憑證狀態是否與 𝐶𝑆𝑀_{𝑟𝑒𝑝𝑙𝑦}記錄相同。

第六步：若比對結果不相同，判定CA 狀態更新錯誤，Contract 將轉出一筆 加密貨幣給 Owner，當作賠償金。

第三段 CA 撤銷憑證錯誤

定義：CA 撤銷憑證並未按照正常程序(先暫停，在撤銷)，導致 Owner 在稽

核階段，發現憑證狀態從Add 或 Renew，直接變為 Revoked。

28

情境：

圖13 CA 撤銷憑證錯誤之情境 申訴依據：CO 相連的兩條 Slice。

申訴步驟：

第一步：Owner 將兩條 Slice、list of key-value pairs 打入 Contract。

第二步：Contract 檢查兩個 Slice 的 CO 是否相連。

第三步：Contract 確認兩對 CO 與 Root hash 是否與本身記錄的一致。

第四步：Contract 計算兩條 Slice、list of key-value pairs 是否正確。

第五步：Contract 比對兩個 List of key-value pairs 內記錄的憑證狀態，是否分 別為 Pause、Revoked。

第六步：若比對結果不符合，判定CA 未照正常程序進行撤銷，Contract 將 轉出一筆加密貨幣給 Owner，當作賠償金。

第四段 𝑴

欄位資料錯誤

定義：Owner 收到的任何種類𝑀_{𝑟𝑒𝑝𝑙𝑦}，其result 為 Accept，但記錄的資料與

𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}不同

29

情境：

圖14 𝑴_{𝒓𝒆𝒑𝒍𝒚}欄位資料錯誤之情境

申訴依據：𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}、𝑀_{𝑟𝑒𝑝𝑙𝑦} 申訴步驟：

第一步：Owner 將𝑀_{𝑟𝑒𝑝𝑙𝑦}、Slice、list of key-value pairs 打入 Contract。

第二步：Contract 檢查回條上 CA 簽名是否正確。

第三步：Contract 確認𝑀_{𝑟𝑒𝑝𝑙𝑦}的result 是否為 Accept。

第四步：Contract 比對𝑀_{𝑟𝑒𝑝𝑙𝑦}與𝑀_{𝑟𝑒𝑞𝑢𝑒𝑠𝑡}的Status 是否一致。

第五步：若比對結果不符合，判定CA 回條有誤，Contract 將轉出一筆加密 貨幣給 Owner，當作賠償金。

𝑀_{𝑟𝑒𝑝𝑙𝑦}欄位錯誤除了Status 以外，還有 Hash(Certificate)也可能會發生錯誤，

但Hash(Certificate)錯誤會導致 Owner 在稽核時，查無憑證資訊，因此可接使用「憑 證不在樹上」的方式申訴即可

第五段 CA 上傳錯誤證據

定義：Owner 取得的 Slice，其 Root hash 與 Contract 上記錄的不一致。這有

兩種可能，第一種是CA 上傳錯誤的 Root hash 到 Contract 上，第二種則是 CA 發

30

給Owner 的 Slice 有錯誤。可以同時申訴兩種情況的理由是 Contract 只有 CA 能 上傳，而Slice 有 CA 簽名，兩者都只有 CA 可以操作，因此若資料發生不同步，

我們可以合理推斷一定是CA 自己操作失誤。

情境：

圖15 CA 上傳錯誤證據之情境 申訴依據：Slice

申訴步驟：

第一步：Owner 將 Slice、list of key-value pairs 打入 Contract。

第二步：Contract 檢查 Slice、list of key-value pairs 簽名是否正確。

第三步：Contract 確認 CO 與 Root hash 是否與本身記錄的一致。

第四步：若比對結果不符合，判定CA 上傳錯誤證據，Contract 將轉出一筆

加密貨幣給Owner，當作賠償金。

31