基于区块链的科技服务质量信任评价方案

张垿豪，冯文龙，黄梦醒，刘 伟

（海南大学 信息与通信工程学院，海口 570228）

0 概述

近年来，功能相似的服务增多使得服务质量（Quality of Service，QoS）成为评价服务优劣的重要依据。现已提出的一些基于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 的性能表现，最终将两者结合，使得评价结果可信且符合事实。可以看出，CSP7、CSP8、CSP11 已经不参与排名，这是因为用户设置了阈值，最近一次调用的服务检测到这3 个云服务提供商提供的服务的动态QoS 参数超出最大容忍阈值，故不在推荐名单中。

图4 冷启动时的静态排名以及服务被调用后的综合排名Fig.4 Static ranking during cold start and comprehensive ranking after service call

4.1.2 主观权重重要性系数对服务综合排名的影响

将γ分别取｛0.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 参数以及服务信息可信，同时部署与调试交易合约证明了其可行性。下一步可将服务信任评价步骤转化为通用的智能合约，通过简化数据处理流程并采用区间数模型进行服务评价，使得本文方案能更适用于实际科技服务交易平台。