基于區塊鏈的科技服務質量信任評價方案

張垿豪，馮文龍，黃夢醒，劉 偉

（海南大學 信息與通信工程學院，海口 570228）

0 概述

近年來，功能相似的服務增多使得服務質量（Quality of Service，QoS）成為評價服務優劣的重要依據?，F已提出的一些基于QoS 的服務選擇方法［1-3］均假定QoS 信息是真實的，但在實際環境下服務提供商提供的QoS 信息真假難以辨別，例如：文獻［1］提出利用歷史數據與用戶需求進行評價與匹配，但是未考慮數據的真實性；文獻［3］提出在多個QoS 指標的約束下對服務進行選擇組合，但是未考慮QoS 指標的來源以及可信性。另一些研究考慮了QoS 信息的真實性，但卻忽略了服務冷啟動以及QoS 信息動態變化的問題［4-6］，例如：文獻［4］基于歷史數據以及用戶評價的相似性對QoS 指標進行修正得到可信的QoS 數值，但對初始發布的服務評價未做具體介紹；文獻［5］通過改進K-means 算法過濾異常的QoS 數據，降低虛假信息干擾，但是基于運行一段時間后得到的相關數據，無法解決冷啟動問題；文獻［6］通過多次實驗找到合適的概率響應請求，從而采集運行數據對服務提供者的數據修正，同時計算反饋的相似度保證QoS 可信，但是仍未解決冷啟動問題。此外，多數基于QoS 的評價方法僅使用檢測到的實數進行評價［7-8］，例如文獻［7］是對監測到的某一時刻的QoS 具體數值使用層次分析法進行計算，隨后通過逼近理想解法排序，但是服務均在動態變化的網絡中，因此選擇某一時刻的數值計算是不準確的。目前，基于QoS 的評價方法主要面臨QoS信息可信性難以保證、對于動態變化的QoS 數據缺少處理、在服務冷啟動階段沒有歷史監測數據的情況下常用QoS 評價方法無法使用等問題。

為保證獲得可信的QoS 數據，區塊鏈［9-11］作為一個分布式共享賬本技術被認為是解決該問題的可行工具。利用區塊鏈技術可以保證交易前的訪問者身份信息可信、交易過程可信以及交易后的交易信息存儲可信并不被篡改。具體而言，基于區塊鏈的分散性可達到以下目標：將其應用在分布式網絡的科技服務交易中，通過密碼學原理來保證加入區塊鏈網絡的節點身份信息是可信的；將用戶信息以及服務信息記錄在區塊鏈中確保內容不被篡改；利用智能合約的強制性保證交易過程可信；通過分布式共識算法使得網絡中有權限的用戶共同維護賬本并決定入鏈內容，確保得到真實數據，實現存儲可信。

依據獲得的各類可信QoS 數據對服務進行綜合評價是服務排序與選擇的基礎，主要包括數據處理、權重確定以及多維決策綜合評價。對于QoS 數據采用隨機 變量處 理［12］、實數處 理［7-8］以及區 間數處理［13-14］。對于權重確定，現有確權方法［15］多數使用多種方法相結合的方式。對于多維決策綜合評價主要包括逼近理想解法［16-17］、模糊綜合評價法［18］以及灰色關聯分析法［19］等方法。逼近理想解法相比于其他兩種方法，對原始信息利用更為充分，并且考慮到同類服務數量逐漸增多，不僅適用于小樣本而且適合大樣本，相對較為靈活。同時，逼近理想解法能準確反映各個服務之間的差異，刻畫多個指標的綜合影響力度，可以得到良好的可比性評價結果。

本文利用區塊鏈的公開透明、可追溯、防篡改等特性，構建科技服務的交易與評價流程，保證交易信息可信及流程規范透明。通過區間數模型描述QoS信息并計算可能度，減少QoS 信息動態性對評估結果的影響。結合熵權法［20］與層次分析法［21］得到混合權重，使得評價結果更全面且符合實際情況。設計靜態與動態評價相結合的綜合信任評價方案，使用TΟPSIS 方法［16］進行科技服務排序以解決科技服務冷啟動問題，并且通過交易合約的設計與調試以驗證該方案的可行性。

1 基于聯盟鏈的科技服務交易信任模型

由于科技服務交易這一場景通常是在兩個企業之間或者校企之間展開，并且不是所有人能夠更改賬本信息，因此正好契合聯盟鏈只允許認證后的節點參與共識，交易信息局部開放的特點。聯盟鏈中的節點主要分為背書節點、驗證節點、排序節點三大類。背書節點模擬執行交易提案，驗證節點負責檢查交易，排序節點對收集到的交易打包區塊并進行共識，其中除排序節點外，另外兩個節點均有記賬功能。

為了保證QoS 信息可信，本文利用區塊鏈技術，將通過驗證的靜態QoS 信息上鏈，一定程度上避免了服務提供商提供虛假信息。此外，本文分析了將區塊鏈技術應用于科技服務交易這一場景的可行性并提出一種可信交易模型。模型中的用戶主要分為服務提供商、服務需求方、平臺管理方等3類。服務提供商通過Fabric提供的SDK 以及API 操作鏈碼，將經過認證的服務信息存入區塊鏈中；平臺管理方可以對服務提供方以及需求方進行管理，同時管理、更新合約，也可以廢除鏈上的合約；服務需求方可以通過遠程API 查看或選擇鏈上的某個服務。下面以科技服務注冊及交易為例，給出具體工作流程：

1）服務提供商與服務需求方向CA 機構請求身份驗證并登錄平臺進行身份注冊，只有通過認證且注冊的用戶才能發布服務或發起交易。

2）服務提供方登錄客戶端后，創建科技服務發布的提案，并將提案發送給各個背書節點。

3）背書節點模擬執行服務注冊鏈碼，并將模擬的提案結果返回給客戶端。

4）客戶端收集足夠多的背書結果后，將服務注冊的提案以及背書結果提交給排序節點。

5）排序節點將同一時間的提案打包封裝到區塊，然后將區塊發給各個驗證節點。

6）驗證節點對區塊進行檢驗，主要包括交易信息是否真實、簽名是否完整、讀寫集版本是否矛盾等。驗證通過則執行該提案，并將結果寫入賬本。

7）服務需求方登錄客戶端輸入服務需求。

8）平臺管理方調用查詢鏈碼查詢服務信息并結合需求進行信任評價，將信任評價結果返回給服務需求方。

9）服務需求方選擇服務并創建科技服務交易提案，重復步驟2～步驟6。

基于聯盟鏈的科技服務交易總體流程如圖1所示。由圖1 可以看出：為了保證交易雙方身份信息可信，聯盟鏈中運用密碼學技術產生數字證書作為通信依據；為了保證發布的靜態QoS 參數信息可信，聯盟鏈中依據PBFT 共識機制［22-23］，只有達成共識的服務信息才能入鏈被用戶查詢，這樣可以使各個成員能夠維持統一可信的數據信息。

圖1 基于聯盟鏈的科技服務交易總體流程Fig.1 Overall process of technology service transaction based on alliance chain

為了提高存儲效率并防止數據篡改，區塊鏈存儲服務信息的哈希值。當雙方發生科技服務交易時，雙方會調用預設的智能合約，滿足預設條件將自動執行。在交易完成后，交易信息會經過共識廣播給各個記賬節點后入鏈。基于聯盟鏈的科技服務交易信任管理模型如圖2 所示，其中，虛線代表涉及到科技服務平臺與底層區塊鏈有所交互的部分，即將交易信息、服務信息與QoS 信息記錄在鏈上；實線代表在科技服務平臺上進行的操作。可見，結合區塊鏈技術與基于QoS 的信任評價方法是可行的。

圖2 基于聯盟鏈的科技服務交易信任模型Fig.2 Trust model of technology service transaction based on alliance chain

2 基于可信QoS 的綜合信任評價方案

步驟1確保服務信息的可信性。服務提供商在發布服務時，考慮到部分QoS 參數會由于網絡波動而波動，造成較大的不確定性，同時為了保證參數的真實性，不采用簡單平均的方法，而將QoS 參數以區間數形式設置。聯盟鏈中只有達成共識的服務才能上鏈，共識階段主要驗證服務的QoS 參數是否合理等?？紤]到區塊鏈上的存儲性能，本文將各個服務的靜態QoS 參數用一個數組表示，并將該數組進行哈希運算，同時在區塊上存儲該哈希值，這樣既能防止信息被篡改，又能減輕區塊上的存儲壓力。

步驟2確定用戶需求。平臺通過用戶功能需求粗選出候選服務，考慮到不同用戶對相同服務的需求不同，平臺允許用戶對各類QoS 參數的需求使用區間數進行設置，同時對于負向型參數額外設置最大容忍閾值。閾值的設置是考慮到服務被調用時的動態性，如果監測到當前動態QoS 信息超出用戶閾值，則會重新選擇合適服務。

步驟3通過區間數模型篩選出候選服務，并計算區間數的可能度，構造可能度矩陣。分別將用戶需求與服務提供商所提供的各個QoS 參數區間進行對比，篩選用戶需求的區間數與服務發布的區間數有交集的服務。隨后計算區間數的可能度［24］，從而構造可能度矩陣。其中使用區間數是考慮到服務的動態變化性，而可能度的引用則是衡量當前服務與用戶需求之間的貼合程度。

定義1（區間數可能度）設任意兩個區間數a=[a-,a+]，b=[b-,b+]，la=a+-a-，lb=b+-b-。則a大 于b的可能度如下：

考慮到本文中吞吐量以及成功率為正向指標，而響應時間、成本以及延遲為負向指標，因此利用式（2）表示不同指標對應的取值：

其中：cij(1 ≤i≤n,1 ≤j≤m)表示用戶需求區間數的矩陣，即 第i個服 務的第j個指標；dij(1 ≤i≤n,1 ≤j≤m)表示QoS 信息區間數的矩陣。

步驟4權重設定。權重是評價多屬性決策問題的重要參數，常用的權重確定方法中熵權法受樣本數據影響大，可能造成與現實認知不相符的情況，層次分析法［21］又過于依賴主觀情感，基于本文科技服務交易這一應用場景，本文將這兩種權重確定方法的優點結合，即考慮到科技服務要求用戶有一定的背景知識，在設置主觀權重方面，更多需要專家幫助進行主觀權重的設置，所以本文首先使用層次分析法對5 種因素進行主觀權重的設定，然后使用熵權法［20］確定客觀權重，減少主觀判斷對權重的影響，最后綜合兩者獲得混合權重。

專家對QoS 參數采用1-9 標度兩兩比較法建立層次分析判斷矩陣fij，然后根據式（3）、式（4）驗證矩陣的一致性，其中n為矩陣階數，?max為矩陣的最大特征值。RRI對應的數值可查表得到，當CCR＜0.1 時，認為矩陣是有效的。在通過驗證后，由式（5）計算主觀權重。主觀權重不會因QoS 參數改變而變化，客觀權重會根據靜態QoS 數據或動態QoS 數據發生改變，首先根據步驟3 中得到的可能度用式（6）計算第j個指標的熵，然后通過式（7）計算權重，其中1，最后利用式（8）計算混合權重。

12) oasis [??'e?s?s] n. 綠洲13) limit ['l?m?t] n.限制14) wave [we?v] n.波浪

步驟5服務綜合評價與排序。逼近理想解排序法［16-17］是分別計算候選服務與最佳服務、最劣服務之間的距離，從而評價服務。

首先根據步驟3 中區間數的可能度建立可能度評價矩陣P={pij}，再根據步驟4 中與之相對應的混合權重建立權重矩陣W={w1,w2,…,wm}并改寫為對角形式，則綜合評價矩陣為Z={zij}，其中zij=pij×wj。然后取各個指標中的最大值組成正理想解，各個指標中的最小值組成負理想解通過式（9）～式（11）依次計算各個候選服務的貼合度。最后根據服務的貼合度進行綜合評價與排序，即距離正理想解較近、距離負理想解遠的服務為最優服務。

考慮到冷啟動問題，當服務沒有被調用的歷史時，就根據服務提供商提供的靜態QoS 信息進行評價，由于信息保存在區塊鏈中，因此信任度相對較高。隨著服務被調用的次數增多，靜態權重會逐漸下降，服務的綜合評價應偏重于當前服務的動態評價數據，因此服務的綜合信任值計算如下：

其中：μ為該服務被調用的次數。

綜合信任評價流程如圖3 所示。

圖3 綜合信任評價流程Fig.3 Comprehensive trust evaluation process

3 交易合約設計

通過開發、部署以及調試智能合約實現科技服務的交易過程，即利用智能合約將用戶以及相關服務信息寫入區塊鏈中，在雙方進行交易時，再使用API 從區塊鏈中調取信息，從而保證信息的真實可靠。本文主要基于Fabric 環境開發交易合約，區塊鏈中的智能合約必須使用Init 與Invoke 兩個接口，其中Init 接口負責初始化，Invoke 接口負責業務邏輯的實現，并且接收來自客戶端的函數及函數需要的參數。根據科技服務綜合信任評價交易方案需求，設計如表1 所示的鏈碼函數。

表1 鏈碼函數Table 1 Chaincode function

根據科技服務交易的業務邏輯，需要設計的函數以及函數中的參數主要包括：1）用戶注冊函數（userRegister），管理用戶信息登記，主要包括姓名以及id 2 個參數；2）服務注冊函數（serviceEnroll），管理服務的登記注冊，主要包括服務的名稱以及服務id、服務的信任評價值以及服務的擁有者id 4 個參數；3）服務交易函數（serviceTrade），管理交易雙方信息，包括服務提供者的id、服務id 以及該服務需求方id 3 個參數；4）用戶查詢函數（queryUser），驗證用戶是否存在，包含用戶id 1 個參數；5）服務查詢函數（queryService），查詢驗證服務是否存在以及服務的相關信息，包含服務id 1 個參數；6）服務歷史查詢函數（queryServiceHistory），查詢服務的交易歷史情況，包含服務id 1 個參數，返回服務的歷史交易情況。

此外，shim 包中有一個ChaincodeStubInterface接口，通過該接口提供的一組方法來直接操作Fabric中的賬本數據。科技服務交易合約的設計過程中所需要的API 具體如下：1）GetFunctionAndParameter，負責接收從客戶端傳遞過來的信息，包括調用的函數名稱以及所需的參數；2）GetState，負責從Fabric賬本中取出可信數據并交給chaincode 使用；3）PutState，負責將從客戶端傳遞過來的數據保存到Fabric 賬本中，即寫入賬本的操作；4）DelState，負責刪除某個key；5）CreateCompositeKey，負責創建一個組合鍵；6）GetHistoryForKey，負責查詢歷史記錄信息。

4 實驗與結果分析

4.1 信任評價實驗分析

為驗證本文提出的信任評價方案，實驗采用在2019 年底更新的QWS Dataset（2.0），該數據集包含了Internet 中2 507 個Web 服務調用時的真實QoS 性能指標值，選取其中13 個云服務提供商（Cloud Service Provider，CSP）提供的測試服務在同一域下被調用時所產生的QoS 性能指標值，具體為響應時間（RT）、吞吐量（TP）、成功率（SA）、價格（BP）和延遲（LC），其中響應時間、價格、延遲為負向指標，吞吐量和成功率為正向指標。為了模擬評價時不被篡改，將指標計算哈希存儲在區塊鏈中。設定用戶需求如表2 所示，云服務提供商設定的靜態QoS 數據如表3 所示。

表2 用戶需求Table 2 User requirements

表3 靜態QoS 數據Table 3 Static QoS data

區塊鏈上靜態數據的加密哈希具體如下：

在每個服務第一次被調用時的動態QoS 數據如表4 所示?？紤]到QoS 信息的動態變化性，將表4 中的實際QoS 數據以自身的0.1 倍為半徑擴展成區間型數據。主觀權重構建的層次分析矩陣如表5 所示，服務綜合評價數據如表6 所示。

表4 動態QoS 數據Table 4 Dynamic QoS data

表5 層次分析矩陣Table 5 Hierarchy analytic matrix

表6 服務綜合評價數據Table 6 Comprehensive service evaluation data

4.1.1 服務冷啟動問題及動態信任評估對服務綜合排名的影響

由于剛發布的服務沒有運行時的數據，因此靜態信任評估的權重為1，而每個服務調用1 次之后，會根據調用時的數據，計算出動態QoS 信息，最終計算得到綜合信任值為后續用戶選擇提供參考。從圖4 可以看出，隨著服務被調用時的實時動態QoS信息的加入，服務的排名會略有波動，這是由于QoS信息不穩定性導致的，但是均反映了近期被調用的QoS 的性能表現，最終將兩者結合，使得評價結果可信且符合事實?？梢钥闯觯珻SP7、CSP8、CSP11 已經不參與排名，這是因為用戶設置了閾值，最近一次調用的服務檢測到這3 個云服務提供商提供的服務的動態QoS 參數超出最大容忍閾值，故不在推薦名單中。

圖4 冷啟動時的靜態排名以及服務被調用后的綜合排名Fig.4 Static ranking during cold start and comprehensive ranking after service call

4.1.2 主觀權重重要性系數對服務綜合排名的影響

將γ分別?。?.0，0.1，…，1.0｝，同時保證原始的靜態QoS 信息不發生改變，但靜態的綜合權重會發生改變，通過計算得到綜合排名前5（CSP10、CSP1、CSP5、CSP13、CSP2）的服務排名變化情況，如圖5 所示。從圖5 可以看出，隨著γ的不斷變化，服務的綜合排名在不斷變化，可見主觀權重重要性系數會影響服務排名。

圖5 主觀權重重要性系數對服務綜合排名的影響Fig.5 Influence of subjective weight importance coefficient on comprehensive service ranking

4.1.3 動態參數優劣化對服務綜合排名的影響

通過排名第1 的服務（CSP10）劣化QoS 參數以及排名第5 的服務（CSP2）優化QoS 參數來判斷本文方案是否及時正確反映了服務排名的變化，在實驗過程中的靜態QoS 原始信息不發生改變且γ=0.5。從圖6 可以看出，當CSP10 以及CSP2 的QoS 參數在不斷變化時，服務的綜合排名也在不斷變化，通過不斷的優化，CSP2 從最劣服務轉變為最佳服務，CSP10從最佳服務轉變為最劣服務。由此可知，本文方案能夠及時正確地反映服務排名的變化情況。

圖6 變化動態QoS 值對服務綜合排名的影響Fig.6 Impact of changing dynamic QoS value on comprehensive service ranking

4.1.4 用戶需求變化對服務綜合排名的影響

實驗根據用戶需求變化觀察服務排名情況。在γ=0.5 的前提 下，CSP1、CSP2、CSP5、CSP10、CSP13的服務排名情況如圖7 所示。從圖7 可以看出，當用戶需求不斷變化時，靜態QoS 信息與動態QoS 信息轉化成的區間數均發生改變，排名將會發生改變，雖然前3 組排名不變，但是其綜合評價值在不斷變化，因此用戶需求的改變會對排名產生影響。

圖7 用戶需求變化對服務綜合排名的影響Fig.7 Impact of user demand change on comprehensive service ranking

4.1.5 性能分析與對比

選用折損累計增益（Discounted Cumulative Gain，DCG）［25］指標評估本文方案性能，并將其與其他方案進行性能對比。DCG 主要對服務排序結果進行分析，具體計算公式如式（13）、式（14）所示：

其中：k為排序后的服務排名，當k值相同時，得到評價的DCG 數值越大，說明方案性能越好。

首先利用文獻［1］中的URDQ 方案與本文方案對上述服務進行排序，設置γ=0.5，在進行一次服務調用后得到的服務排名如表7 所示，其中CSP7、CSP8 以及CSP11 由于在動態評價中超過了用戶閾值，因此不參與服務評價。然后利用文獻［1］中的URDQ 方案與本文方案對排序后Top-k（k=1，6，7，8，9，10）的服務DCG 值進行對比，如表8 所示。從表8可以看出，本文方案Top-k的服務DCG 值均大于URDQ 方案的DCG 值，這說明本文方案的準確性高于URDQ 方案，同時考慮到了靜態信息，因此更為全面。

表7 URDQ 方案與本文方案的服務排名Table 7 Ranking of services by URDQ scheme and the proposed scheme

表8 URDQ 方案與本文方案的Top-k 服務DCG 值對比Table 8 Comparison of Top-k service DCG values between URDQ scheme and the proposed scheme

4.2 交易合約驗證

本文交易合約在開發者模式下進行調試，測試環境配置選擇Ubuntu 16.04 運行環境，Docker 19.03.5，go 1.16，Docker-compose 1.18.0，node v12.16.1。在搭建好的Hyperledger Fabric 1.4 版本下進入鏈碼開發者模式，使用docker exec -it chaincode bash 命令進入chaincode 容器中編譯鏈碼，在cli 容器中先安裝并且初始化鏈碼，再對設計鏈碼進行操作和調試。

1）用戶注冊函數驗證

以云服務提供商CSP1 以及用戶User1 注冊為例，為了將兩者區分，id 分別采用“1”與“01”。命令與驗證結果分別如圖8、圖9 所示。

圖8 云服務提供商注冊Fig.8 Cloud service provider registration

圖9 用戶注冊Fig.9 User registration

2）服務注冊函數驗證

云服務提供商CSP1 注冊驗證檢測服務，服務編號為001，通過本文方案計算后，其信任值為0.78，并將信息入鏈，如圖10 所示。

圖10 服務注冊Fig.10 Service registration

3）服務交易函數驗證

通過計算將信任值排名第1 的CSP1 提供的服務1推送給用戶User1，調用交易命令與驗證如圖11所示。

圖11 服務交易Fig.11 Service transaction

4）服務查詢函數驗證

在交易完成后，對服務進行查詢，查看哪些用戶在使用服務，服務查詢命令與驗證如圖12 所示。

圖12 服務查詢Fig.12 Service query

5）服務交易歷史函數驗證

查看從服務注冊開始的歷史交易記錄，這樣可以做到溯源，具體命令如圖13（a）所示。驗證結果如圖13（b）所示，其中第1 個current_owner_id 是01，記錄本次交易的對象即為用戶User1，第2 個current_owner_id 是1，代表注冊服務時的服務商。

圖13 服務交易歷史Fig.13 Service transaction history

4.3 對比實驗分析

將本文方案與文獻［1］中的URDQ 方案以及文獻［26］中的Entropy-TΟPSIS 方案分別從服務評價的冷啟動、數據可信、數據動態性、數據篩選以及細粒度5 個方面進行對比，結果如表9 所示，其中，√表示該方案具備該特性，×表示該方案不具備該特性。

表9 3 種方案的對比結果Table 9 Comparison results of three schemes

從表9 可以看出：1）從服務評價是否解決冷啟動問題來看，Entropy-TΟPSIS 方案以及URDQ 方案均只是考慮運行時的服務評價數據，對于如何評價剛發布的服務并沒有涉及，而本文方案將動靜態QoS 結合，并且隨著服務調用的次數增多，動態評價比重亦會增大；2）從數據可信、數據動態性以及數據篩選3 個方面來看，Entropy-TΟPSIS 方案不考慮數據的可信性以及動態性，只以某一次運行的結果進行計算，而URDQ 方案考慮到動態變化性，同時也對一些數據進行過濾，但卻忽視了數據是否可信，默認所有數據均是可信的，本文方法對于不滿足用戶需求的數據進行過濾，并利用區塊鏈技術獲得可信的數據，基于可信的數據使用區間數模型對動態數據進行處理；3）從服務評價的數據細粒度方面來看，三者對于服務評價因素的選擇相同，考慮的因素更為全面。因此，結合上文的DCG 性能對比實驗可以看出，本文方案更為準確。

5 結束語

為輔助用戶選擇既可信又能滿足需求的科技服務，本文提出一種動態服務綜合評價方案。針對交易信息的可信性，建立基于聯盟鏈的交易信任模型。針對QoS 信息的動態性，選擇區間數模型分別對靜態以及動態QoS 信息進行描述，同時通過計算區間數可能度構造評價矩陣。將主觀與客觀權重結合設定混合權重，保證服務評價的全面性。考慮到冷啟動問題，在服務剛發布時，利用服務提供商的靜態QoS 信息進行評價，隨著調用次數的增多，逐步提高動態信任評價的權重，從而保證評價結果客觀可靠。實驗結果表明，該方案通過區塊鏈技術保證了靜態QoS 參數以及服務信息可信，同時部署與調試交易合約證明了其可行性。下一步可將服務信任評價步驟轉化為通用的智能合約，通過簡化數據處理流程并采用區間數模型進行服務評價，使得本文方案能更適用于實際科技服務交易平臺。