开放科学（资源服务）标志码（OSID）：

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]得到混合权重，使得评价结果更全面且符合实际情况。设计静态与动态评价相结合的综合信任评价方案，使用TOPSIS方法^[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]，只有达成共识的服务信息才能入链被用户查询，这样可以使各个成员能够维持统一可信的数据信息。

为了提高存储效率并防止数据篡改，区块链存储服务信息的哈希值。当双方发生科技服务交易时，双方会调用预设的智能合约，满足预设条件将自动执行。在交易完成后，交易信息会经过共识广播给各个记账节点后入链。基于联盟链的科技服务交易信任管理模型如图 2所示，其中，虚线代表涉及到科技服务平台与底层区块链有所交互的部分，即将交易信息、服务信息与QoS信息记录在链上；实线代表在科技服务平台上进行的操作。可见，结合区块链技术与基于QoS的信任评价方法是可行的。

2 基于可信QoS的综合信任评价方案

本文提出的综合信任评价方案与文献[1]有所不同，不同之处在于本文利用区块链技术保证静态QoS数据可信并解决了冷启动问题。静态评价以及动态评价步骤相同，只是计算参考的数据不同，即静态QoS评价参考服务提供商提供的数据，动态QoS评价依据服务在调用之后监测到的数据。基于可信QoS的综合信任评价步骤具体如下：

步骤1     确保服务信息的可信性。服务提供商在发布服务时，考虑到部分QoS参数会由于网络波动而波动，造成较大的不确定性，同时为了保证参数的真实性，不采用简单平均的方法，而将QoS参数以区间数形式设置。联盟链中只有达成共识的服务才能上链，共识阶段主要验证服务的QoS参数是否合理等。考虑到区块链上的存储性能，本文将各个服务的静态QoS参数用一个数组表示，并将该数组进行哈希运算，同时在区块上存储该哈希值，这样既能防止信息被篡改，又能减轻区块上的存储压力。

步骤2    确定用户需求。平台通过用户功能需求粗选出候选服务，考虑到不同用户对相同服务的需求不同，平台允许用户对各类QoS参数的需求使用区间数进行设置，同时对于负向型参数额外设置最大容忍阈值。阈值的设置是考虑到服务被调用时的动态性，如果监测到当前动态QoS信息超出用户阈值，则会重新选择合适服务。

步骤3    通过区间数模型筛选出候选服务，并计算区间数的可能度，构造可能度矩阵。分别将用户需求与服务提供商所提供的各个QoS参数区间进行对比，筛选用户需求的区间数与服务发布的区间数有交集的服务。随后计算区间数的可能度^[24]，从而构造可能度矩阵。其中使用区间数是考虑到服务的动态变化性，而可能度的引用则是衡量当前服务与用户需求之间的贴合程度。

定义1(区间数可能度)    设任意两个区间数$ a=[{a}^{-}, {a}^{+}] $，$ b=[{b}^{-}, {b}^{+}] $，$ {l}_{a}={a}^{+}-{a}^{-} $，$ {l}_{b}={b}^{+}-{b}^{-} $。则a大于b的可能度如下：

$ p(a\ge b)=\mathrm{m}\mathrm{a}\mathrm{x}\left\{1-\mathrm{m}\mathrm{a}\mathrm{x}\left(\frac{{b}^{+}-{a}^{-}}{{l}_{a}+{l}_{b}}, 0\right), 0\right\} $

(1)

考虑到本文中吞吐量以及成功率为正向指标，而响应时间、成本以及延迟为负向指标，因此利用式(2)表示不同指标对应的取值：

$ {p}_{ij}=\left\{\begin{array}{l}p({c}_{ij}\ge {d}_{ij}), \mathrm{负}\mathrm{向}\mathrm{指}\mathrm{标}\\ p({d}_{ij} < {c}_{ij}), \mathrm{正}\mathrm{向}\mathrm{指}\mathrm{标}\end{array}\right. $

(2)

其中：$ {c}_{ij}(1\le i\le n, 1\le j\le m) $表示用户需求区间数的矩阵，即第i个服务的第j个指标；$ {d}_{ij}(1\le i\le n, 1\le j\le m) $表示QoS信息区间数的矩阵。

步骤4    权重设定。权重是评价多属性决策问题的重要参数，常用的权重确定方法中熵权法受样本数据影响大，可能造成与现实认知不相符的情况，层次分析法^[21]又过于依赖主观情感，基于本文科技服务交易这一应用场景，本文将这两种权重确定方法的优点结合，即考虑到科技服务要求用户有一定的背景知识，在设置主观权重方面，更多需要专家帮助进行主观权重的设置，所以本文首先使用层次分析法对5种因素进行主观权重的设定，然后使用熵权法^[20]确定客观权重，减少主观判断对权重的影响，最后综合两者获得混合权重。

专家对QoS参数采用1-9标度两两比较法建立层次分析判断矩阵$ {\boldsymbol{f}}_{ij} $，然后根据式(3)、式(4)验证矩阵的一致性，其中n为矩阵阶数，$ {\phi }_{\mathrm{m}\mathrm{a}\mathrm{x}} $为矩阵的最大特征值。R_RI对应的数值可查表得到，当$ {C}_{\mathrm{C}\mathrm{R}} < 0.1 $时，认为矩阵是有效的。在通过验证后，由式(5)计算主观权重。主观权重不会因QoS参数改变而变化，客观权重会根据静态QoS数据或动态QoS数据发生改变，首先根据步骤3中得到的可能度用式(6)计算第j个指标的熵，然后通过式(7)计算权重，其中$ \sum\limits_{j=1}^{m}{w}_{j}^{o}=1 $，最后利用式(8)计算混合权重。

$ {C}_{\mathrm{C}\mathrm{I}}=\frac{{\phi }_{\mathrm{m}\mathrm{a}\mathrm{x}}-n}{n-1} $

(3)

$ {C}_{\mathrm{C}\mathrm{R}}=\frac{{C}_{\mathrm{C}\mathrm{I}}}{{R}_{\mathrm{R}\mathrm{I}}} $

(4)

$ {w}_{j}^{s}=\frac{\sqrt[m]{{\boldsymbol{f}}_{i1}\times {\boldsymbol{f}}_{i2}\times \cdots \times {\boldsymbol{f}}_{im}}}{\sum\limits_{j=1}^{m}\sqrt[m]{{\boldsymbol{f}}_{i1}\times {\boldsymbol{f}}_{i2}\times \cdots \times {\boldsymbol{f}}_{im}}} $

(5)

$ {e}_{j}=\frac{1}{\mathrm{l}\mathrm{n}n}\sum\limits_{i=1}^{n}{p}_{ij}\mathrm{l}\mathrm{n}\frac{1}{{p}_{ij}} $

(6)

$ {w}_{j}^{o}=\frac{1-{e}_{j}}{\sum\limits_{j=1}^{m}1-{e}_{j}} $

(7)

$ {w}_{j}=\gamma {w}_{j}^{s}+(1-\gamma ){w}_{j}^{o}, p=\mathrm{1, 2}, \cdots , m $

(8)

步骤5    服务综合评价与排序。逼近理想解排序法^[16-17]是分别计算候选服务与最佳服务、最劣服务之间的距离，从而评价服务。

首先根据步骤3中区间数的可能度建立可能度评价矩阵$ \boldsymbol{P}=\left\{{p}_{ij}\right\} $，再根据步骤4中与之相对应的混合权重建立权重矩阵$ \boldsymbol{W}=\{{w}_{1}, {w}_{2}, \cdots , {w}_{m}\} $并改写为对角形式，则综合评价矩阵为$ \boldsymbol{Z}=\left\{{z}_{ij}\right\} $，其中$ {z}_{ij}={p}_{ij}\times {w}_{j} $。然后取各个指标中的最大值组成正理想解$ {z}_{j}^{+} $，各个指标中的最小值组成负理想解$ {z}_{j}^{-} $，通过式(9)~式(11)依次计算各个候选服务的贴合度。最后根据服务的贴合度进行综合评价与排序，即距离正理想解较近、距离负理想解远的服务为最优服务。

$ {V}_{i}^{+}=\sqrt{\sum\limits_{j=1}^{m}({z}_{ij}-{z}_{j}^{+}{)}^{2}} $

(9)

$ {V}_{i}^{-}=\sqrt{\sum\limits_{j=1}^{m}({z}_{ij}-{z}_{j}^{-}{)}^{2}} $

(10)

$ {C}_{i}=\frac{{V}_{i}^{-}}{{V}_{i}^{+}+{V}_{i}^{-}} $

(11)

考虑到冷启动问题，当服务没有被调用的历史时，就根据服务提供商提供的静态QoS信息进行评价，由于信息保存在区块链中，因此信任度相对较高。随着服务被调用的次数增多，静态权重会逐渐下降，服务的综合评价应偏重于当前服务的动态评价数据，因此服务的综合信任值计算如下：

$ Q=\frac{1}{\mu +1}{C}_{\mathrm{静}}+\frac{\mu }{\mu +1}{C}_{\mathrm{动}} $

(12)

其中：$ \mu $为该服务被调用的次数。

综合信任评价流程如图 3所示。

3 交易合约设计

通过开发、部署以及调试智能合约实现科技服务的交易过程，即利用智能合约将用户以及相关服务信息写入区块链中，在双方进行交易时，再使用API从区块链中调取信息，从而保证信息的真实可靠。本文主要基于Fabric环境开发交易合约，区块链中的智能合约必须使用Init与Invoke两个接口，其中Init接口负责初始化，Invoke接口负责业务逻辑的实现，并且接收来自客户端的函数及函数需要的参数。根据科技服务综合信任评价交易方案需求，设计如表 1所示的链码函数。

根据科技服务交易的业务逻辑，需要设计的函数以及函数中的参数主要包括：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所示。

区块链上静态数据的加密哈希具体如下：

1) 0482bdfa78f742778f154b404ff6b8e2fced27d001b67ac904931e0288acbac8。

2) de837b930336c88e292354fbeed011550747b86a10001cefa3ea8a3dcc45e723。

3) 7151c762ef1010ad01e8074d3255293cef0cd97e8eaed28b991299da07e2b974。

4) ab817821c89a43731f035fe5c8d971ad12fe479aa809e6a0ffca599e193429d8。

5) 58c78e874d8423d5d8dc51dacb31084aa7b2e60331907d00f795f5f00aaacdec。

6) 0c729260ed0f9ffa83ca08b25a3e04b54d40362179e201fafaa48531be1b2a88。

7) e8eebfc950318b12be29b8c0d32a61bcad36de793b2fb761f79fb1110ae5bb5f。

8) fdd11d6c064d17250b876509a0988ee0f8f4d32f39092a98ff88063f1f284378。

9) 49fe920f1db7afa0e88d1823c13f2097323023fb9571c70355ad603d5430c7eb。

10) 13b3c31de77a364e4c4c4d6af23b37bbd276b4ba9cc766da3567e0778bdb5409。

11) e09460e3bbe0f4c644d7748c8605a4da2f45fa9ca786cf3a45d4b5cee5592572。

12) d0dffd0634428ecd4961826803c55dc57143bc5442c00af1897064612f757db1。

13) 7e60a4beed9867bc25a75d24c11821b60a7589e89bd2356dd419b4211。

在每个服务第一次被调用时的动态QoS数据如表 4所示。考虑到QoS信息的动态变化性，将表 4中的实际QoS数据以自身的0.1倍为半径扩展成区间型数据。主观权重构建的层次分析矩阵如表 5所示，服务综合评价数据如表 6所示。

4.1.1 服务冷启动问题及动态信任评估对服务综合排名的影响

由于刚发布的服务没有运行时的数据，因此静态信任评估的权重为1，而每个服务调用1次之后，会根据调用时的数据，计算出动态QoS信息，最终计算得到综合信任值为后续用户选择提供参考。从图 4可以看出，随着服务被调用时的实时动态QoS信息的加入，服务的排名会略有波动，这是由于QoS信息不稳定性导致的，但是均反映了近期被调用的QoS的性能表现，最终将两者结合，使得评价结果可信且符合事实。可以看出，CSP7、CSP8、CSP11已经不参与排名，这是因为用户设置了阈值，最近一次调用的服务检测到这3个云服务提供商提供的服务的动态QoS参数超出最大容忍阈值，故不在推荐名单中。

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

将$ \gamma $分别取{0.0，0.1，…，1.0}，同时保证原始的静态QoS信息不发生改变，但静态的综合权重会发生改变，通过计算得到综合排名前5(CSP10、CSP1、CSP5、CSP13、CSP2)的服务排名变化情况，如图 5所示。从图 5可以看出，随着$ \gamma $的不断变化，服务的综合排名在不断变化，可见主观权重重要性系数会影响服务排名。

4.1.3 动态参数优劣化对服务综合排名的影响

通过排名第1的服务(CSP10)劣化QoS参数以及排名第5的服务(CSP2)优化QoS参数来判断本文方案是否及时正确反映了服务排名的变化，在实验过程中的静态QoS原始信息不发生改变且$ \gamma $=0.5。从图 6可以看出，当CSP10以及CSP2的QoS参数在不断变化时，服务的综合排名也在不断变化，通过不断的优化，CSP2从最劣服务转变为最佳服务，CSP10从最佳服务转变为最劣服务。由此可知，本文方案能够及时正确地反映服务排名的变化情况。

4.1.4 用户需求变化对服务综合排名的影响

实验根据用户需求变化观察服务排名情况。在$ \gamma $=0.5的前提下，CSP1、CSP2、CSP5、CSP10、CSP13的服务排名情况如图 7所示。从图 7可以看出，当用户需求不断变化时，静态QoS信息与动态QoS信息转化成的区间数均发生改变，排名将会发生改变，虽然前3组排名不变，但是其综合评价值在不断变化，因此用户需求的改变会对排名产生影响。

4.1.5 性能分析与对比

选用折损累计增益(Discounted Cumulative Gain，DCG)^[25]指标评估本文方案性能，并将其与其他方案进行性能对比。DCG主要对服务排序结果进行分析，具体计算公式如式(13)、式(14)所示：

$ {D}_{\mathrm{D}\mathrm{C}{\mathrm{G}}_{k}}=\sum\limits_{i=1}^{k}\frac{r{}_{\mathrm{r}\mathrm{e}{\mathrm{l}}_{i}}}{\mathrm{l}\mathrm{b}(i+1)} $

(13)

$ {r}_{\mathrm{r}\mathrm{e}{\mathrm{l}}_{i}}=\sum\limits_{j=1}^{m}{z}_{ij} $

(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方案，同时考虑到了静态信息，因此更为全面。

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所示。

2) 服务注册函数验证

云服务提供商CSP1注册验证检测服务，服务编号为001，通过本文方案计算后，其信任值为0.78，并将信息入链，如图 10所示。

3) 服务交易函数验证

通过计算将信任值排名第1的CSP1提供的服务1推送给用户User1，调用交易命令与验证如图 11所示。

4) 服务查询函数验证

在交易完成后，对服务进行查询，查看哪些用户在使用服务，服务查询命令与验证如图 12所示。

5) 服务交易历史函数验证

查看从服务注册开始的历史交易记录，这样可以做到溯源，具体命令如图 13(a)所示。验证结果如图 13(b)所示，其中第1个current_owner_id是01，记录本次交易的对象即为用户User1，第2个current_owner_id是1，代表注册服务时的服务商。

4.3 对比实验分析

将本文方案与文献[1]中的URDQ方案以及文献[26]中的Entropy-TOPSIS方案分别从服务评价的冷启动、数据可信、数据动态性、数据筛选以及细粒度5个方面进行对比，结果如表 9所示，其中，√表示该方案具备该特性，×表示该方案不具备该特性。

从表 9可以看出：1)从服务评价是否解决冷启动问题来看，Entropy-TOPSIS方案以及URDQ方案均只是考虑运行时的服务评价数据，对于如何评价刚发布的服务并没有涉及，而本文方案将动静态QoS结合，并且随着服务调用的次数增多，动态评价比重亦会增大；2)从数据可信、数据动态性以及数据筛选3个方面来看，Entropy-TOPSIS方案不考虑数据的可信性以及动态性，只以某一次运行的结果进行计算，而URDQ方案考虑到动态变化性，同时也对一些数据进行过滤，但却忽视了数据是否可信，默认所有数据均是可信的，本文方法对于不满足用户需求的数据进行过滤，并利用区块链技术获得可信的数据，基于可信的数据使用区间数模型对动态数据进行处理；3)从服务评价的数据细粒度方面来看，三者对于服务评价因素的选择相同，考虑的因素更为全面。因此，结合上文的DCG性能对比实验可以看出，本文方案更为准确。

5 结束语

为辅助用户选择既可信又能满足需求的科技服务，本文提出一种动态服务综合评价方案。针对交易信息的可信性，建立基于联盟链的交易信任模型。针对QoS信息的动态性，选择区间数模型分别对静态以及动态QoS信息进行描述，同时通过计算区间数可能度构造评价矩阵。将主观与客观权重结合设定混合权重，保证服务评价的全面性。考虑到冷启动问题，在服务刚发布时，利用服务提供商的静态QoS信息进行评价，随着调用次数的增多，逐步提高动态信任评价的权重，从而保证评价结果客观可靠。实验结果表明，该方案通过区块链技术保证了静态QoS参数以及服务信息可信，同时部署与调试交易合约证明了其可行性。下一步可将服务信任评价步骤转化为通用的智能合约，通过简化数据处理流程并采用区间数模型进行服务评价，使得本文方案能更适用于实际科技服务交易平台。