第三章 技術改良與系統架構
第二節 解法與步驟
本架構的方法是將四步驟雙重鏈結雜湊應用於點對點之有責性改良至可以 應用於不同 Service Relaying Chains 間的有責性；又不希望使用者端負起保留全部
證據的責任，於是將證據打散儲存於各個有參與該次交易的雲端服務提供者上；
最後在原先四步驟雙重鏈結雜湊方法中彼此交換訊息的內容加上特定的請求訊
息或是承認訊息之雜湊值，以確保當不同的 Service Relaying Chains 涉及至同一雲
端服務時，各服務之間的正確執行順序。
接下來先描述所使用的協定內的符號意義，[O]pri(x)表示使用者 x 簽署在資料
物件（Data Object）上的電子簽章，此簽章是由使用者 x 本身的私有鑰匙（Private
Key）所簽署，而在中括弧內，多個資料物件會以逗號隔開，表示多個資料物件被 使用者 x 簽署，如[O1 , O2 , O3]pri(x)表示資料物件 O1、O2、O3被使用者 x 的私有鑰
匙所簽署。
接下來介紹將使用者與雲端服務提供商彼此交換訊息時的步驟說明與訊息
內的詳細內容：
Step 1: 當一個使用者 U 所持的客戶端裝置（Client）想要對一個服務提供者
（Service Provider）提出服務請求時，使用者會傳送一個請求訊息
（Request Message）Qi給服務端，而 Qi = ( OPi , ClientID , hash( QPreCaller ) ,
[ OPi , ClientID , hash( QPreCallee ) ] pri(U) )，其中 OPi會包含對此次操作所要 求的動作，ClientID 則用來識別使用者的身分，PreCaller 表示對此 Caller
而言，上一個呼叫它的雲端服務，而加入 hash( QPriCaller )至請求訊息的目
的是日後在做稽核時，可以用來檢查呼叫的順序是否與證據上所記錄的
結果一致。如圖 2 所示，若從顧客端發送請求到購物網站服務端（D）
（即 1.1 的過程），由於顧客為服務請求之發起者，沒有上一個呼叫他的
人存在，則不需在 Qi中加上 hash( QPriCaller )的內容；而由購物網站發送
請求至公司帳戶服務端（E）與訂單處理服務端（A）時（即 1.2 與 1.3 的
過程），由於需要先支付下單的費用至公司帳戶，而公司帳戶回報給購物
網站確定顧客有執行支付費用的動作後，才接著處理訂單與接下來的服
務。這樣的順序關係必須確保，所以在公司帳戶端完成此次操作後的承
認訊息（Acknowledgment Message）中加上該承認訊息之 ID 以供驗證時
辨識該承認訊息之證據儲存的位置，回傳給購物網站後，購物網站再將
剛剛自公司帳戶端收到的承認訊息的雜湊值加入原本送至訂單處理服
務端的 Request 中，所以訂單處理服務端可以確保顧客的確已經經過公
司帳戶的付款程序，便可以繼續接著將請求的內容依照步驟執行完畢。
Step 2: 當服務提供者收到來自使用者的請求 Qi，首先會驗證此請求內的電子簽 章[ OPi , ClientID , hash( QPreCaller ) ] pri(U)是否有效，如果電子簽章確認有
效後，再將上一筆的操作回應訊息（Response Message）Ri-1取雜湊後放
入此次操作 R，並回傳回應訊息 Ri i給使用者端裝置，Ri = ( Qi , hash(ACKj) ,
hash(Ri-1) , [Qi , hash(ACKj) , hash(Ri-1)]pri(Provider) )，其中 ACKj為使用者在 此服務端的上一個操作的承認訊息。
Step 3: 當使用者裝置收到由服務端所傳送的回應訊息 Ri後，先驗證 Ri內的電 子簽章是否有效，再比較 Ri內使用者裝置上一個操作的承認訊息的雜湊
值是否與使用者裝置目前保留的最後一個操作之承認訊息的雜湊相同，
其中，ACKj之 j < i 且 j 可能不等於 i-1。當檢查完畢後，使用者裝置傳
送回覆回應訊息（Reply-Response Message）RRi給服務端，其中 RRi =
( Ri , [Ri]pri(U) )。
Step 4: 服務端收到回覆回應訊息 RRi後便開始執行 Qi內所要求的操作指令，待 執行完成後，服務端傳送承認訊息 ACKi給使用者，ACKi = ( Li , RRi ,
hash(ACKCallee_ID) , ACK_ID , [Li , RRi , hash(ACKCallee_ID) ,
ACK_ID]pri(Provider) )，其中 Li為執行結果，hash(ACKCallee_ID)為被呼叫者
該次操作之證據的雜湊值，ACK_ID 為該次操作留下的證據之識別名稱。
最後，圖 2 所示之情境可以根據上述四步驟的交握協定配合雙重鏈結雜湊之
技術依序建立起如圖 6 所示之證據，可透過鏈結雜湊的方式檢視同服務端內的服
務執行順序，也可表示不同服務端之間各服務端呼叫的先後關係，圖中有框起來
的部分皆為雜湊值，箭頭指向雜湊值的來源，IH（Initial Hash）表示初始的雜湊
值。最後可對此證據儲存結果進行稽核，檢查每一筆不同的 Service Relaying Chains
之間的操作順序。
稽核的部分分成以下幾個步驟：
Step 1: 由服務請求發起者（即公司或顧客）留下的承認訊息可以得知該次交 易是由服務請求發起者向某雲端服務提供商發起請求開始，並可藉由
其識別名稱與比對證據的雜湊值可確認該雲端服務與該次交易相關的
證據。若該服務提供者與該次相關之證據內沒有包含其他的承認訊息
之雜湊值與其識別名稱，表示該雲端服務並無再繼續呼叫其他服務來
參與此次操作；
Step 2: 若有，則將此雜湊值與該雲端服務內之證據中找到由其呼叫之服務端所 送回的承認訊息的雜湊值比對，相同則再繼續重複 Step 1 直到某一服務
端所留下之證據內沒有存有其它承認訊息之雜湊值與其證據的識別名
稱為止，則代表該服務端為此次操作的尾端，即沒有再繼續呼叫其他服
務。
Step 3: 經過 Step 1 及 Step2 後，可以建立起不同條 Service Relaying Chains 的呼 叫情況，若有發生多筆交易涉及至同一雲端服務時，可藉由判斷該雲端
服務的證據串接順序（承認訊息之 ID 值）來決定各服務發起請求之先
後。