电子证书的信用评估方法以及设备与流程

[0001]
本申请涉及区块链技术领域，尤其涉及一种电子证书的信用评估方法以及设备。


背景技术：

[0002]
电子证书，也称作数字证书，对网络用户在计算机网络交流中的信息和数据等以加密或解密的形式保证了信息和数据的完整性和安全性。通常，用户需要通过浏览器验证电子证书，来确认证书提供方的身份，而所验证的电子证书需要是有效电子证书，才能用于验证提供方的身份。
[0003]
目前，有效电子证书为通过证书认证机构，例如证书颁发机构(certificate authority，ca)，认证的、具有较高信用度的电子证书。电子证书的需求方向ca提出申请，由ca对需求方进行审核，在审核通过后进行证书签发。
[0004]
然而，由于电子证书的信用度依赖于证书认证机构的认证，不可避免的存在中心化的问题，在证书认证机构恶意签发证书、或者证书认证机构受到恶意攻击时，都会导致所签发的电子证书不可靠，为网络通信安全带来风险。


技术实现要素：

[0005]
本申请提供一种电子证书的信用评估方法以及设备，能够以去中心化的方式对电子证书的信用进行评估，以保证网络通信安全。
[0006]
第一方面，本申请实施例提供一种电子证书的信用评估方法，应用于认证参与节点，所述认证参与节点为区块链中登录有第一账户的节点，所述第一账户为任一参与电子证书认证的账户，包括：
[0007]
获取电子证书的信用评分；所述电子证书为经过签名的电子证书，所述信用评分包括第一信用评分，所述第一信用评分为通过浏览器使用所述电子证书得到的；
[0008]
根据所述信用评分，确定所述电子证书的信用值，所述电子证书的信用值用于确定所述电子证书是否可信。
[0009]
第二方面，本申请实施例提供一种电子证书的信用评估方法，应用于认证需求节点，所述认证需求节点为区块链中登录有第二账户的节点，所述第二账户为电子证书的认证需求方的账户，所述方法包括：
[0010]
生成电子证书的认证交易请求，所述电子证书为经过签名的电子证书，所述认证交易请求用于请求至少一个参与电子证书认证的账户对所述电子证书进行认证；
[0011]
在所述区块链中同步所述认证交易请求；
[0012]
在所述至少一个参与电子证书认证的账户对所述电子证书进行认证后，根据每个参与电子证书认证的账户的信用值，向所述参与电子证书认证的账户发送对应的通证。
[0013]
第三方面，本申请实施例提供一种区块链节点，包括：存储器和处理器；
[0014]
所述存储器存储计算机执行指令；
[0015]
所述处理器执行所述存储器存储的计算机执行指令，使得所述处理器执行第一方
面所述的电子证书的信用评估方法。
[0016]
第四方面，本申请实施例提供一种区块链节点，包括：存储器和处理器；
[0017]
所述存储器存储计算机执行指令；
[0018]
所述处理器执行所述存储器存储的计算机执行指令，使得所述处理器执行第二方面所述的电子证书的信用评估方法。
[0019]
第五方面，本申请实施例提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序用于实现第一方面或第二方面所述的方法。
[0020]
本申请实施例，通过认证参与节点获取电子证书的信用评分，并根据信用评分，确定该电子证书的信用值，该信用值用于确定电子证书是否有效，即网络用户通过电子证书的信用值即可分辨该电子证书是否可信，避免了网络用户基于对认证机构所认证的电子证书的可信度的依赖，实现了通过去中心化的方式对电子证书的信用进行评估，保证网络通信的安全。
附图说明
[0021]
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0022]
图1为本申请实施例提供的一种电子证书签名以及使用的流程示意图；
[0023]
图2为本申请实施例提供的一种应用场景示意图；
[0024]
图3a或图3b为本申请实施例提供的一种电子证书的信用评估方法300的流程示意图；
[0025]
图4为本申请实施例提供的一种电子证书的信用评估方法400的流程示意图；
[0026]
图5a或图5b为本申请实施例提供的一种电子证书的信用评估方法500的流程示意图；
[0027]
图6为本申请实施例提供的一种电子证书的信用评估方法600的流程示意图；
[0028]
图7为本申请实施例提供的一种区块链节点700的结构示意图；
[0029]
图8为本申请实施例提供的一种区块链节点800的结构示意图；
[0030]
图9为本申请一实施例提供的区块链的节点900的硬件结构示意图。
具体实施方式
[0031]
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0032]
为了使网络通信更加安全，网络用户在访问某个网站时，首先需要通过浏览器对网站提供的电子证书进行验证，来识别该网站是否安全可信。而电子证书本身应具备有效性或者说具备较高的可信度。结合图1所示，通常，电子证书的需求方向证书认证机构提交申请信息，证书认证机构对电子证书的需求方提交的申请信息进行审核，在审核通过后，证
书认证机构基于非对称加密算法，生成非对称加密秘钥对，包括公钥和私钥，再将公钥和私钥发送给电子证书的需求方，此时，电子证书的需求方也称作证书持有用户。
[0033]
进一步地，证书持有用户通过公钥和私钥生成电子证书，再向网络用户提供电子证书，使网络用户通过运行浏览器对电子证书进行验证，以供网络用户确认证书持有用户的身份以及确认电子证书的状态是否正常。
[0034]
示例性的，证书持有用户通过公钥和私钥生成电子证书，通常包括：对明文信息进行哈希hash运算，得到摘要a，其中明文信息包括证书持有用户的机构名称、证书的有效时间、序列号等；并通过私钥对摘要a进行加密，得到签名a；再将签名a、明文信息以及公钥作为电子证书。
[0035]
示例性的，网络用户通过浏览器访问该电子证书对应的网站时，下载该电子证书，通过相同的hash算法，对明文信息进行hash运算，得到摘要a’，并通过公钥对签名a进行解密，得到摘要b，进而对比摘要a’和摘要b是否一致，若一致则电子证书验证通过，若不一致则电子证书验证不通过，在验证不通过时，可提升网络用户电子证书异常，建议用户停止继续访问网站。
[0036]
在上述过程中，证书认证机构提供的非对称加密秘钥对时验证电子证书是否正常的核心，而证书认证机构向电子证书的需求方提供非对称加密秘钥对是基于对需求方提供的申请信息的审核结果，那么假设证书认证机构对申请信息的审核结果有误，或者证书认证机构受到恶意攻击或恶意向不符合要求的需求方提供的非对称加密秘钥对，则难以保证网络用户的信息安全，甚至资产安全。
[0037]
基于上述应用场景，为了提高网络通信的安全，本申请实施例基于去中心化的区块链技术，对电子证书的信用进行评估，并对电子证书进行去中心化的管理。
[0038]
图2为本申请实施例提供的一种应用场景示意图，如图2所示，区块链200可以为任一平台的区块链，区块链200中包括多个节点和智能合约。
[0039]
其中，区块链200的多个节点包括至少一个认证参与节点和至少一个认证需求节点，可选的，区块链200中除认证需求节点外的其他节点可以全部或者部分为认证参与节点。应理解，认证参与节点为登录有第一账户的节点，该第一账户为任一参与电子证书认证的账户(也称作认证参与方的账户)，即登录第一账户的用户选择参与了电子证书的认证；认证需求节点为登录有第二账户的节点，该第二账户为电子证书的认证需求方的账户，一般来说，认证需求方为证书的持有者。
[0040]
智能合约(smart contract)是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。
[0041]
在本申请的一些实施例中，为了实现去中心化的电子证书的信用评估，在区块链200中部署的智能合约包括证书生成合约，用于根据认证需求方的证书信息生成电子证书，并将电子证书在区块链200中进行同步，使认证参与方对电子证书的信用进行评估。
[0042]
下面通过几个实施例进行具体说明。
[0043]
为了实现对电子证书的去中心化的信用评估，本申请实施例通过多个认证参与节点获取每个认证参与用户对电子证书的信用评分，并根据信用评分，确定该电子证书的信用值，该信用值用于指示电子证书是否有效。
[0044]
图3a或图3b为本申请实施例提供的一种电子证书的信用评估方法300的流程示意图。示例性的，如图3a所示，该方法可应用于图2所示实施例中的认证参与节点，包括：
[0045]
s301：获取针对电子证书的信用评分。
[0046]
应理解，该电子证书为经过签名的电子证书，可选的，签名方式包括自签名或认证机构签名。信用评分包括第一信用评分，第一信用评分为通过浏览器使用电子证书得到的。
[0047]
首先，认证参与方可从区块链或者认证需求方的服务端获取电子证书，进而通过认证参与节点中部署的浏览器使用该电子证书，例如在访问认证需求方的网络平台时使用该电子证书。与前述实施例类似的，电子证书中包括明文信息、签名a以及公钥，明文信息至少包括机构名称、有效时间、序列号中的任一一种或者多种；与前述实施例类似的，浏览器使用电子证书的过程包括：通过预设的hash算法，对明文信息进行hash运算，得到摘要a’，并通过公钥对签名a进行解密，得到摘要b，进而对比摘要a’和摘要b是否一致，若一致则电子证书验证通过，若不一致则电子证书验证不通过，预设的hash算法应与生成电子证书时使用的hash算法相同。
[0048]
进一步地，根据电子证书是否验证通过，得到该电子证书的信用评分。示例性的，若验证通过，则向登录有认证需求方账户的认证需求节点发送1个通证，若验证不通过，则获取登录有认证需求方账户的认证需求节点发送的1个通证，并在该电子证书对应的信用值存证链中记录通证的变化，将认证参与节点向认证需求节点发送的通证记录为正向通证，将认证需求节点向认证参与节点发送的通证记录为负向通证。示例性的，结合图3b所示，甲为认证需求方，乙为认证参与方，乙通过使用电子证书，确定电子证书验证通过，则向甲发送1个通证，并在信用值存证链中记录为+1。可选的，乙向甲发送的交易可通过具有背书资质的丙和丁对交易进行背书认证，乙向甲发送的交易经过背书认证后才能完成，否则交易失败。
[0049]
在本步骤中，认证参与节点可通过浏览器使用电子证书后得到信用评分，或者获取其他终端设备通过有线或者无线的方式发送的该电子证书的信用评分。
[0050]
s302：根据信用评分，确定电子证书的信用值。
[0051]
若该信用评分为针对该电子证书的第一个信用评分，则电子证书的信用值等于该信用评分，例如，获取的信用评分为+1，则电子证书的信用值为1。
[0052]
若在认证参与节点接收到该信用评分之前，已经记录有其他信用评分(也称作历史信用评分)，则需要根据该信用评分和历史信用值，确定该电子证书的信用值。历史信用值为根据电子证书的初始信用评分和/或至少一个历史信用评分得到的，例如历史信用值可以是初始信用评分，或者是对至少两个历史信用评分进行求和运算得到的历史信用值，或者可以是初始信用值和至少一个历史信用评分通过求和运算得到的。
[0053]
可选的，初始信用评分为根据电子证书的签名方式确定的，其中，签名方式包括自签名或认证机构签名。示例性的，自签名的电子证书的初始信用评分较低，认证机构签名的初始信用评分较高。
[0054]
示例性的，可以对信用评分和历史信用值进行求和运算，以确定电子证书的信用值。
[0055]
作为一种示例，结合3b所示，该电子证书的信用值为+1、+1、-1、-2、+10、+10的和，即19。
[0056]
应理解，电子证书的信用值用于指示电子证书是否可信。示例性的，网络用户在获取到电子证书后，首先通过电子证书的信用值对电子证书是否可信进行判断，例如在电子证书的信用值大于预设阈值时，确定电子证书可信，小于等于预设阈值时，确定电子证书不可信。网络用户在电子证书可信时再进一步通过验证电子证书，来识别网络平台的身份。
[0057]
本申请实施例中，通过认证参与节点获取电子证书的信用评分，并根据信用评分，确定该电子证书的信用值，该信用值用于确定电子证书是否可信，即网络用户通过电子证书的信用值即可分辨该电子证书是否可信，避免了网络用户基于对认证机构所认证的电子证书的可信度的依赖，实现了通过去中心化的方式对电子证书的信用进行评估，保证网络通信的安全。
[0058]
在一种具体的实现方式中，信用评分还包括第二信用评分，第二信用评分为根据接收到的对电子证书的投诉信息得到的。示例性的，在通过浏览器使用电子证书后，认证参与方可根据使用情况，向认证参与节点输入投诉信息，认证参与节点根据接收到的投诉信息，得到第二信用评分，再将第二信用评分在区块链中进行同步，例如，认证参与方发现电子证书或者电子证书的持有者存在异常时，可向认证参与节点发送投诉信息。一般来说第二信用评分为负值，若认证参与方因满意电子证书的可信度向认证参与节点输入的为认可信息，第二信用评分为正值。
[0059]
为了获得更多的信用评分，使得对电子证书的信用评估更准确，需要更多的认证参与方参与信用评估，那么，除了上述实施例中提到的被动接收愿意参与认证的认证参与方提供的信用评分外，本申请实施例通过认证需求节点主动发送认证交易请求，请求认证参与节点对其电子证书进行信用评估。
[0060]
图4为本申请实施例提供的一种电子证书的信用评估方法400的流程示意图。示例性的，如图4所示，在本实施例中，步骤s301获取电子证书的信用评分，包括：
[0061]
s401：认证需求节点生成电子证书的认证交易请求。
[0062]
示例性的，认证需求节点可根据认证需求方输入的指令，生成电子证书的认证交易请求。
[0063]
其中，电子证书为经过签名的电子证书；认证交易请求用于请求至少一个参与电子证书认证的账户对电子证书进行认证。
[0064]
s402：认证需求节点同步认证交易请求。
[0065]
认证需求节点将认证交易请求在区块链中进行同步，使区块链中的每个节点均接收到该认证交易请求。应理解，该认证交易请求中携带有通证信息，该通证信息用于指示在认证参与节点发送信用评分后，向参与电子证书认证的账户发送对应数量的通证。
[0066]
s403：认证参与节点响应于认证交易请求，获取电子证书的信用评分。
[0067]
认证参与节点接收到认证交易请求后，可以选择是否对电子证书进行信用评估。一般来说，认证参与节点对电子证书的信用评估由认证参与方的指令触发。示例性的，认证参与方在认证参与节点接收到认证交易请求后，可向认证参与节点发送信用评估指令，认证参与节点接收到信用评估指令后，获取电子证书的信用评分，包括同时获取第一信用评分和第二信用评分，或者获取第一信用评分或第二信用评分，例如通过浏览器使用电子证书以获取该电子证书的第一信用评分，或者，根据接收到的电子证书的投诉信息，确定第二信用评分。
[0068]
在步骤s403之后，执行步骤s302：根据信用评分，确定电子证书的信用值，具体实现方式与上述实施例中类似，此处不再赘述。
[0069]
本实施例提供的方法还可以包括将信用评分在区块链中进行同步，可以在步骤s302之前或者之后执行该同步的过程，本实施例对此不做限制。
[0070]
示例性的，在步骤s302之后，执行步骤s404：认证需求节点根据每个参与电子证书认证的账户的信用值，向参与电子证书认证的账户发送对应的通证。相应的认证参与节点接收认证需求节点发送的通证。
[0071]
示例性的，参与电子证书认证的账户的信用值越高，对应的通证越多。参与电子证书认证的账户的信用值可根据该账户建立的时间长短、账户行为和账户状态等信息确定。
[0072]
结合图3b所示，甲为认证需求方、丙为响应于认证交易请求的认证参与方，乙对电子证书的信用评分为10，则在信用值存证链中记录+10，甲在丙完成对电子证书的信用评估后，向乙的账户发送10个通证。
[0073]
本实施例中，通过认证需求节点发送认证交易请求来请求更多的认证参与方参与电子证书的信用评估，并向每个参与了电子证书信用评估的账户发送对应的通证，提高了信用评估的准确性。
[0074]
在上述任一实施例的基础上，图5a或图5b为本申请实施例提供的一种电子证书的信用评估方法500的流程示意图。示例性的，如图5a所示，在步骤s301：获取电子证书的信用评分之前，该方法还包括：
[0075]
s501：认证需求节点获取电子证书。
[0076]
在本步骤中，认证需求节点可接收认证需求方以有线或者无线的方式发送的电子证书，该电子证书应为经过签名的电子证书。
[0077]
作为一种示例，结合图5b所示，认证需求节点获取电子证书可以是接收证书生成合约发送的电子证书，即步骤s501-1。应理解，证书生成合约可根据任一终端设备通过调用接口信息提供的证书信息生成电子证书，并将电子证书在区块链200中进行同步，使认证参与方对电子证书的信用进行评估。
[0078]
s502：认证需求节点根据电子证书的签名方式，确定电子证书的初始信用评分。
[0079]
示例性的，自签名的电子证书的初始信用评分较低，认证机构签名的初始信用评分较高。
[0080]
s503：认证需求节点在区块链中同步电子证书。
[0081]
认证需求节点通过在区块链中同步电子证书，使包括认证参与节点在内的节点能够接收到电子证书，以便于后续对电子证书的信用进行评估。
[0082]
可选的，上述步骤s501至步骤s503也可图4所示的实施例中的步骤s401之前执行。
[0083]
为了实现对电子证书的管理，便于及时停止电子证书的使用，本申请实施例对于电子证书的吊销提供一下两种可能的实现方式：
[0084]
方式一、由认证需求方，此处可理解为证书持有者，主动发起电子证书的吊销请求，认证需求节点根据获取电子证书的吊销交易请求，并根据吊销交易请求，将电子证书设置为吊销状态。结合图6所示，具体包括：
[0085]
s601：获取针对电子证书的吊销交易请求。
[0086]
示例性的，认证需求节点根据证书持有者输入的吊销指令，生成吊销交易请求，或
者认证需求节点接收证书持有者通过任一终端设备发送的吊销交易请求。
[0087]
s602：根据吊销交易请求，将电子证书的证书状态设置为吊销状态。
[0088]
示例性的，认证需求节点将该吊销交易请求在区块链中进行同步，各个区块链的节点均将电子证书的证书状态设置为吊销状态。可选的，在将证书状态设置为吊销状态之前，需通过背书认证确定吊销交易完成。
[0089]
方式二、在电子证书的信用值低于预设值时，网络用户的客户端不再信任该电子证书，即达到吊销电子证书的效果。
[0090]
为了约束认证参与方的评估行为，提高认证参与方对电子证书的信用评估的客观性，本申请实施例对每个参与电子证书认证的账户的信用值进行动态的反馈。示例性的，对于每个参与电子证书认证的账户，随着电子证书的信用值的变化，每个账户对应的信用值也将根据该账户对该电子证书的信用评价发生动态的变化。例如对电子证书给出信用评价+10的账户的信用值在电子证书的信用值上升至100时，账户的信用值增加10，而对电子证书给出信用评价+1的账户的信用值在电子证书的信用值上升至100时，账户的信用值增加1；相应的，对电子证书给出信用评价+10的账户的信用值在电子证书的信用值下降至0时，账户的信用值下降20，而对电子证书给出信用评价+1的账户的信用值在电子证书的信用值下降至0时，账户的信用值下降2。进一步地，参与电子证书认证的账户的信用值将用于在下一次由认证需求方发起的主动认证过程中，确定能够被分配得到的通证的数量。
[0091]
图7为本申请实施例提供的一种区块链节点700的结构示意图，如图7所示，该节点700包括：
[0092]
获取单元701，用于获取电子证书的信用评分；所述电子证书为经过签名的电子证书，所述信用评分包括第一信用评分，所述第一信用评分为通过浏览器使用所述电子证书得到的；
[0093]
处理单元702，用于根据所述信用评分，确定所述电子证书的信用值，所述电子证书的信用值用于确定所述电子证书是否可信。
[0094]
本实施例提供的一种区块链节点700包括获取单元701和处理单元702，通过认证参与节点获取电子证书的信用评分，并根据信用评分，确定该电子证书的信用值，该信用值用于确定电子证书是否有效，即网络用户通过电子证书的信用值即可分辨该电子证书是否可信，避免了网络用户基于对认证机构所认证的电子证书的可信度的依赖，实现了通过去中心化的方式对电子证书的信用进行评估，保证网络通信的安全。
[0095]
在一种可能的设计中，处理单元702具体用于：
[0096]
根据所述信用评分和历史信用值，确定所述电子证书的信用值；所述历史信用值为根据所述电子证书的初始信用评分和/或至少一个历史信用评分得到的；所述历史信用评分为在获取所述信用评分之前，获取的对电子证书的信用评分。
[0097]
在一种可能的设计中，信用评分还包括第二信用评分；所述第二信用评分为根据接收到的对所述电子证书的投诉信息得到的。
[0098]
在一种可能的设计中，获取单元701具体用于：
[0099]
接收认证需求节点发送的所述电子证书的认证交易请求，所述认证交易请求用于请求至少一个参与电子证书认证的账户对所述电子证书进行认证；
[0100]
响应于所述认证交易请求，获取针对电子证书的信用评分。
[0101]
在一种可能的设计中，获取单元701还用于：
[0102]
接收所述认证需求节点发送的通证。
[0103]
本实施例提供的一种区块链节点可用于实现上述任一实施例中认证参与节点侧的方法，其实现效果与方法实施例类似，此处不再赘述。
[0104]
图8为本申请实施例提供的一种区块链节点800的结构示意图，如图8所示，该节点800包括：
[0105]
获取单元801，用于生成电子证书的认证交易请求，所述电子证书为经过签名的电子证书，所述认证交易请求用于请求至少一个参与电子证书认证的账户对所述电子证书进行认证；
[0106]
处理单元802，用于在所述区块链中同步所述认证交易请求；
[0107]
所述处理单元802还用于：在所述至少一个参与电子证书认证的账户对所述电子证书进行认证后，根据每个参与电子证书认证的账户的信用值，向所述参与电子证书认证的账户发送对应的通证。
[0108]
在一种可能的设计中，获取单元801还用于：
[0109]
获取所述电子证书；
[0110]
根据所述电子证书的签名方式，确定所述电子证书的初始信用评分，所述签名方式包括自签名或认证机构签名；
[0111]
在所述区块链中同步所述电子证书。
[0112]
在一种可能的设计中，获取单元801还用于：获取针对所述电子证书的吊销交易请求；
[0113]
处理单元802还用于根据所述吊销交易请求，将所述电子证书的证书状态设置为吊销状态。
[0114]
本实施例提供的一种区块链节点可用于实现上述任一实施例中认证需求节点侧的方法，其实现效果与方法实施例类似，此处不再赘述。
[0115]
图9为本申请一实施例提供的区块链的节点900的硬件结构示意图。如图9所示，通常，区块链节点900包括有：处理器901和存储器902。
[0116]
处理器901可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器901可以采用dsp(digital signal processing，数字信号处理)、fpga(field－programmable gate array，现场可编程门阵列)、pla(programmable logic array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器901也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(central processing unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器901可以在集成有gpu(graphics processing unit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器901还可以包括ai(artificial intelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。
[0117]
存储器902可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器902还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器902中的非暂态的计算机可
读存储介质用于存储至少一个指令，该至少一个指令用于被处理器901所执行以实现本申请中方法实施例提供的电子证书的信用评估方法。
[0118]
可选地，如图9所示，区块链节点900还可以包括收发器903，处理器901可以控制该收发器903与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。
[0119]
其中，收发器903可以包括发射机和接收机。收发器903还可以进一步包括天线，天线的数量可以为一个或多个。
[0120]
可选地，该区块链节点900可以实现本申请实施例的各个方法中的相应流程，为了简洁，在此不再赘述。
[0121]
本领域技术人员可以理解，图9中示出的结构并不构成对区块链节点900的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。
[0122]
本申请实施例还提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由区块链的节点的处理器执行时，使得区块链节点能够执行上述实施例提供的电子证书的信用评估方法。
[0123]
本实施例中的计算机可读存储介质可以是计算机能够存取的任何可用介质，或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备，可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如ssd)等。
[0124]
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0125]
本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例提供的电子证书的信用评估方法。
[0126]
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
[0127]
以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。