基于区块链的鉴权方法、装置、介质及设备

技术领域

本公开涉及区块链技术领域，具体而言，涉及一种基于区块链的鉴权方法、装置、介质及设备。

背景技术

为了防止恶意请求接入占用网络资源，后台服务器通常会在客户端请求接入时对其进行相关参数（如，应用包名、渠道ID、GUID、设备MAC地址）的鉴权，以证实客户端接入的有效性。各客户端在向服务端请求数据之前均需要通过后台服务器的鉴权，通过鉴权之后才能够获取到服务端反馈的数据。这种方式下，对于后台服务器的依赖性较强，如果后台服务器出现宕机等问题，则容易导致无法及时鉴权或无法正确鉴权的问题。此外，中心化的后台服务器对于每次的鉴权请求进行响应也存在效率较低的问题，因此，如何在保证安全性的前提下降低鉴权次数避免计算资源的浪费也成为了当前需要解决的问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种基于区块链的鉴权方法、基于区块链的鉴权装置、计算机可读存储介质及电子设备，实施本公开实施例能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，在接收到鉴权请求之后，对其进行验证、共识、写入，一方面确保鉴权请求的合法性和隐私性，另一方面利用区块链分布式存储的优势，解决现有技术中后台服务器宕机后无法及时鉴权的问题，再一方面可以通过对于鉴权请求进行时效监控，使得当前用户在个性化的鉴权有效时长内具备合法性，从而在保证安全性的前提下降低鉴权次数避免计算资源的浪费。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一方面，提供一种基于区块链的鉴权方法，包括：

当接收到鉴权请求时，对鉴权请求进行合法性验证；

若验证出鉴权请求存在合法性，对鉴权请求进行共识并将鉴权请求写入区块链账本；

根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应；

根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控；

在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。

根据本公开的一方面，提供一种基于区块链的鉴权装置，包括：

请求验证单元，用于当接收到鉴权请求时，对鉴权请求进行合法性验证；

请求共识单元，用于在验证出鉴权请求存在合法性时，对鉴权请求进行共识并将鉴权请求写入区块链账本；

请求响应单元，用于根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应；

时效监控单元，用于根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控；

失效信息上链单元，用于在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。

在本公开的一种示例性实施例中，时效监控单元根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，包括：

从鉴权请求提取当前用户对应的用户标识；

确定区块链账本中用于记录各个用户等级的目标区块；

从目标区块的默克尔树中读取用户标识对应的鉴权等级。

在本公开的一种示例性实施例中，时效监控单元调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控之后，以及在失效信息上链单元检测到鉴权有效时长到期之前，还包括：

检测单元，用于当接收到当前用户对应的二次鉴权请求时，检测区块链账本中是否存在与二次鉴权请求对应的区块；

请求响应单元，还用于在检测单元检测到区块链账本中存在与二次鉴权请求对应的区块之后，向服务端请求二次响应数据并将二次响应数据反馈至二次鉴权请求的客户端。

在本公开的一种示例性实施例中，时效监控单元调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控，包括：

由响应鉴权请求后开始对鉴权请求进行时效监控；

若鉴权等级对应的鉴权有效时长未到期，且检测到用于接收响应数据的客户端停止接收数据时，确定数据传输时长；

调用智能合约针对数据传输时长计算目标费用并从当前用户的账户中扣除目标费用。

在本公开的一种示例性实施例中，请求共识单元对鉴权请求进行共识，包括：

查询区块链账本的默克尔树中是否存在与鉴权请求对应的分支节点，如果不存在，则对鉴权请求进行共识。

在本公开的一种示例性实施例中，还包括：

节点确定单元，用于在请求共识单元将鉴权请求写入区块链账本之后，从默克尔树中确定与鉴权请求对应的分支节点；

节点反馈单元，用于向发送鉴权请求的客户端反馈分支节点。

在本公开的一种示例性实施例中，节点反馈单元向发送鉴权请求的客户端反馈分支节点之后，客户端根据分支节点中的鉴权摘要生成新鉴权请求，并向后台服务器发送新鉴权请求。

在本公开的一种示例性实施例中，请求响应单元根据写入结果向服务端请求响应数据，包括：

根据写入结果判定鉴权请求鉴权通过，并向服务端发送多媒体文件请求，以使得服务端根据鉴权请求对应的请求内容反馈相对应的多媒体文件作为响应数据。

在本公开的一种示例性实施例中，请求响应单元根据响应数据对鉴权请求进行响应，包括：

向发送鉴权请求的客户端反馈多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。

在本公开的一种示例性实施例中，请求共识单元对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：

通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本；其中，共识节点的数量与区块链中节点总数量之间的占比属于预设范围内。

在本公开的一种示例性实施例中，请求共识单元通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：

广播鉴权请求以使得各个共识节点计算鉴权请求所属的区块的鉴权摘要：

根据每个共识节点计算出的鉴权摘要的一致性确定共识结果；

若共识结果符合预设结果，则将区块写入区块链账本。

在本公开的一种示例性实施例中，根据从鉴权请求提取到的用户标识确定当前用户对应的鉴权等级之前，还包括：

获取当前用户对应的充值记录，根据充值记录确定当前用户对应的鉴权等级；

其中，当前用户对应的鉴权等级随当前用户对应的充值记录的变更而变更，当前用户对应的鉴权等级与当前用户对应的鉴权有效时长呈正相关。

根据本申请的一方面，提供一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一项的方法。

根据本申请的一方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一项的方法。

根据本申请的一方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的各种可选实现方式中提供的方法。

本申请示例性实施例可以具有以下部分或全部有益效果：

在本申请的一示例实施方式所提供的基于区块链的鉴权方法中，可以当接收到鉴权请求时，对鉴权请求进行合法性验证；若验证出鉴权请求存在合法性，对鉴权请求进行共识并将鉴权请求写入区块链账本；根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应；根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控；在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。依据上述方案描述，本申请一方面，能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，在接收到鉴权请求之后，对其进行验证、共识、写入，从而确保鉴权请求的合法性和隐私性，避免恶意鉴权请求攻击后台服务器。本申请又一方面，能够利用区块链分布式存储的优势，解决现有技术中后台服务器宕机后无法及时鉴权的问题，提升鉴权过程的稳定性。本申请再一方面可以通过对于鉴权请求进行时效监控，使得当前用户在个性化的鉴权有效时长内具备合法性，从而在保证安全性的前提下降低鉴权次数避免计算资源的浪费。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了可以应用本申请实施例的一种基于区块链的鉴权方法及基于区块链的鉴权装置的示例性系统架构的示意图。

图2示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

图3示意性示出了根据本申请的一个实施例应用于区块链系统的一个可选的结构示意图。

图4示意性示出了根据本申请的一个实施例的区块结构（Block Structure）的示意图。

图5示意性示出了根据本申请的一个实施例的现有鉴权序列图。

图6示意性示出了根据本申请的另一个实施例的现有鉴权序列图。

图7示意性示出了根据本申请的一个实施例的基于区块链的鉴权方法的流程图。

图8示意性示出了根据本申请的一个实施例的用户界面示意图。

图9示意性示出了根据本申请的一个实施例的区块结构示意图。

图10示意性示出了根据本申请的一个实施例的基于区块链的鉴权方法的序列图。

图11示意性示出了根据本申请的一个实施例的基于区块链的鉴权方法的流程图。

图12示意性示出了根据本申请的一个实施例中的基于区块链的鉴权装置的结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本申请的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本申请的各方面变得模糊。

此外，附图仅为本申请的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1示出了可以应用本申请实施例的一种基于区块链的鉴权方法及基于区块链的鉴权装置的示例性应用环境的系统架构的示意图。

如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等等。应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

本申请实施例所提供的基于区块链的鉴权方法一般由服务器105执行，相应地，基于区块链的鉴权装置一般设置于服务器105中。但本领域技术人员容易理解的是，本申请实施例所提供的基于区块链的鉴权方法也可以由终端设备101、102或103执行，相应的，基于区块链的鉴权装置也可以设置于终端设备101、102或103中，本示例性实施例中对此不做特殊限定。举例而言，在一种示例性实施例中，服务器105可以当接收到鉴权请求时，对鉴权请求进行合法性验证；若验证出鉴权请求存在合法性，对鉴权请求进行共识并将鉴权请求写入区块链账本；根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应；根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控；在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。

图2示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图2所示，计算机系统200包括中央处理单元（CPU）201，其可以根据存储在只读存储器（ROM）202中的程序或者从储存部分208加载到随机访问存储器（RAM）203中的程序而执行各种适当的动作和处理。在RAM 203中，还存储有系统操作所需的各种程序和数据。CPU201、ROM 202以及RAM 203通过总线204彼此相连。输入/输出（I/O）接口205也连接至总线204。

以下部件连接至I/O接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管（CRT）、液晶显示器（LCD）等以及扬声器等的输出部分207；包括硬盘等的储存部分208；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入储存部分208。

特别地，根据本申请的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元（CPU）201执行时，执行本申请的方法和装置中限定的各种功能。

本发明实施例涉及云计算(cloud computing)，本申请中的后台服务器可以为云服务器，云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。按照逻辑功能划分，在IaaS（Infrastructure as aService，基础设施即服务）层上可以部署PaaS(Platform as a Service，平台即服务)层，PaaS层之上再部署SaaS (Software as a Service，软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

本发明实施例涉及的系统可以是由客户端、服务端、多个节点（接入网络中的任意形式的计算设备，如服务器、用户终端）通过网络通信的形式连接形成的分布式系统。

以分布式系统为区块链系统为例，参见图3，图3是本发明实施例提供的基于区块链的鉴权装置300应用于区块链系统的一个可选的结构示意图，由多个节点301（接入网络中的任意形式的计算设备，如服务器、用户终端）、后台服务器302、客户端303和服务端304形成，当接收到客户端303发送的鉴权请求时，可以通过多个节点301中任意节点对鉴权请求进行合法性验证；进而，若验证出鉴权请求存在合法性，则可以通过多个节点301中的共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本；进而，可以后台服务器302根据写入结果向服务端304请求响应数据，并根据响应数据对鉴权请求进行响应。其中，节点之间形成组成的点对点（P2P，Peer To Peer）网络，P2P 协议是一个运行在传输控制协议（TCP，Transmission Control Protocol ）协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。

参见图3示出的区块链系统中各节点的功能，涉及的功能包括：

1）路由，节点具有的基本功能，用于支持节点之间的通信。

节点除具有路由功能外，还可以具有以下功能：

2）应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。

例如，应用实现的业务包括：

2.1）钱包，用于提供进行电子货币的交易的功能，包括发起交易（即，将当前交易的交易记录发送给区块链系统中的其他节点，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币。

2.2）共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认。

2.3）智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移到商户的地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。

3）区块链，包括一系列按照产生的先后时间顺序相互接续的区块（Block），新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。

参见图4，图4是本发明实施例提供的区块结构（Block Structure）一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值（本区块的哈希值）、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链（Blockchain），本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性（防伪）和生成下一个区块。

随着云游戏的不断发展，云游戏逐渐成为了OTT端提供的主要服务之一。其中，OTT端用于通过互联网向用户提供各种应用服务，OTT端可以为互联网电视一体机或（OTT盒子+电视机）。一般来说，客户端云游戏需要通过后台服务器先执行鉴权，在鉴权成功之后，后台服务器可以向服务端请求云游戏数据并反馈至客户端。针对这一过程，有现有的两种解决方案，通过图5和图6对其进行序列化表示。

请参阅图5，图5示意性示出了根据本申请的一个实施例的现有鉴权序列图。如图5所示，现有鉴权序列图包括：步骤S510~步骤S580。S510：启动云游戏。具体地，用户可以通过客户端（如，OTT端）启动云游戏。S520：获取待鉴权参数。具体地，客户端可以获取当前设备对应的待鉴权参数，如，GUID、MAC地址、预置在应用程序内的包括云游戏ID、云游戏渠道ID、encrypted_key等。S530：发送鉴权请求。具体地，客户端可以向后台服务器发送包含待鉴权参数的鉴权请求。S540：处理鉴权请求。具体地，后台服务器可以对待鉴权参数的合法性进行检验。S550：反馈鉴权结果。具体地，后台服务器在待鉴权参数存在合法性时，向后台服务器反馈鉴权结果，鉴权结果用于表示鉴权成功或鉴权失败。S560：发送多媒体文件请求。具体地，后台服务器可以在鉴权结果表示鉴权成功时向服务端发送多媒体文件请求。S570：反馈多媒体文件。具体地，服务端响应于多媒体文件请求反馈多媒体文件。S580：发送多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。具体地，服务端可以将多媒体文件反馈至客户端，以使得客户端根据多媒体文件渲染待展示内容并将待展示内容通过用户界面展示给用户。可见，上述方案主要是依靠待鉴权参数进行鉴权，待鉴权参数中的设备信息可以通过刷机或修改系统软件的方式篡改，云游戏渠道ID、encrypted_key等也可以通过反编译客户端软件或者抓取鉴权请求的网络包报文进行获取。故，这种方式下的鉴权结果可靠性、可信度较低。

请参阅图6，图6示意性示出了根据本申请的另一个实施例的现有鉴权序列图。如图6所示，该现有鉴权序列图包括：步骤S600~步骤S690。

S600：启动云游戏。具体地，用户可以通过客户端（如，OTT端）启动云游戏。S610：获取待鉴权参数。具体地，客户端可以获取当前设备对应的待鉴权参数，如，GUID、MAC地址、预置在应用程序内的包括云游戏ID、云游戏渠道ID、encrypted_key等。S620：请求skey。具体地，客户端可以将待鉴权参数发送至第三方后台。S630：反馈skey和skey有效期。具体地，第三方后台根据待鉴权参数进行哈希计算，得到当前设备对应的skey，进而为skey分配有效期（即，skey的使用时限），向客户端反馈skey和skey有效期，skey可以作为当前设备的表征。S640：发送鉴权请求。具体地，客户端可以向后台服务器发送包含通过待鉴权参数、skey和skey有效期的鉴权请求。S650：委托鉴权。具体地，后台服务器可以将该鉴权请求发送至第三方后台，以委托第三方后台执行鉴权操作。S660：反馈鉴权结果。具体地，第三方后台在鉴权结束后可以向后台服务器反馈鉴权结果，鉴权结果用于表示鉴权成功或鉴权失败。S670：发送多媒体文件请求。具体地，后台服务器可以在鉴权结果表示鉴权成功时向服务端发送多媒体文件请求。S680：反馈多媒体文件。具体地，服务端响应于多媒体文件请求反馈多媒体文件。S690：发送多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。具体地，服务端可以将多媒体文件反馈至客户端，以使得客户端根据多媒体文件渲染待展示内容并将待展示内容通过用户界面展示给用户。可见，上述方案主要是通过委托第三方分配标识码以及鉴权，这种方式对于后台服务器的依赖性较强，如果后台服务器的鉴权逻辑出错，或者受到攻击，则容易导致鉴权结果出错等问题。

可见，基于图5和图6所示的现有鉴权序列图可知，上述两种鉴权方式均需要依赖中心化的后台服务器，当后台服务器出现宕机等问题时，容易导致无法及时鉴权或无法正确鉴权的问题。

本示例实施方式提供了一种基于区块链的鉴权方法。该基于区块链的鉴权方法可以应用于上述服务器105，也可以应用于上述终端设备101、102、103中的一个或多个，本示例性实施例中对此不做特殊限定。参考图7所示，该基于区块链的鉴权方法可以包括以下步骤S710至步骤S750。

步骤S710：当接收到鉴权请求时，对鉴权请求进行合法性验证。

步骤S720：若验证出鉴权请求存在合法性，对鉴权请求进行共识并将鉴权请求写入区块链账本。

步骤S730：根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应。

步骤S740：根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控。

步骤S750：在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。

其中，步骤S710至步骤S750可以由后台服务器执行，当本申请应用于云游戏领域时，该后台服务器可以为云游戏后台服务器；其中，云游戏，是以云计算为基础的游戏方式，在云游戏的运行模式下，所有游戏都在服务端运行，服务端渲染完毕后的游戏画面压缩后，可以通过网络传送至客户端，进而，运行客户端的游戏设备可以解压视频功能，从而获得游戏画面。另外，云游戏后台服务器内部维护了一个基于联盟链的区块链；其中，联盟链建立于一定数目的预选认证节点上。区块链的共识算法由这些预选节点（即，共识节点）执行，可以减少对于网络资源的占用。本申请的预选节点为云游戏后台群组节点，云游戏后台群组节点可以为多个节点服务器。

实施图7所示的方法，能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，在接收到鉴权请求之后，对其进行验证、共识、写入，从而确保鉴权请求的合法性和隐私性，避免恶意鉴权请求攻击后台服务器。此外，能够利用区块链分布式存储的优势，解决现有技术中后台服务器宕机后无法及时鉴权的问题，提升鉴权过程的稳定性。此外，能够通过对于鉴权请求进行时效监控，使得当前用户在个性化的鉴权有效时长内具备合法性，从而在保证安全性的前提下降低鉴权次数避免计算资源的浪费。

下面，对于本示例实施方式的上述步骤进行更加详细的说明。

在步骤S710中，当接收到鉴权请求时，对鉴权请求进行合法性验证。

具体地，鉴权请求的请求内容可以包括：待鉴权参数和请求获得的数据（如，视频数据、实时游戏画面等）。待鉴权参数可以包括：云游戏ID、云游戏渠道ID、全局唯一标识符（Globally Unique Identifier，GUID）和消息认证码（MAC）等；其中，MAC是一种包含密钥的Hash函数，MAC是基于密钥和消息摘要所获得的值，可用于数据源发认证和完整性校验，其安全性依赖于Hash函数；GUID是一种由算法生成的二进制长度为128位的数字标识符，可以用于在拥有多个节点、多台计算机的网络或系统中，一般来说，任何计算机和计算机集群都不会生成两个相同的GUID。

作为一种可选的实施例，对鉴权请求进行合法性验证之前，还包括：接收由客户端发送的加密的鉴权请求，并对鉴权请求进行解密。

具体地，对鉴权请求进行解密，包括：通过客户端公钥对鉴权请求进行解密。进而，对鉴权请求进行合法性验证，包括：验证鉴权请求中的GUID和MAC是否合法。

可见，实施该可选的实施例，能够通过对于鉴权请求的加解密，提升请求传输过程中的数据安全性。

作为一种可选的实施例，接收由客户端发送的加密的鉴权请求之前，还包括：客户端对待鉴权参数进行加密并根据加密后的待鉴权参数生成加密的鉴权请求发送至后台服务器。

具体地，客户端可以为OTT端。客户端对待鉴权参数进行加密，包括：客户端通过客户端私钥对待鉴权参数进行加密。

另外，客户端对待鉴权参数进行加密之前，上述方法还可以包括：当客户端检测到接入操作时接入云游戏。其中，接入操作可以为登录操作，用户可以通过账号密码登录客户端（如，OTT端），进而通过该客户端获取云游戏资源。

请参阅图8，图8示意性示出了根据本申请的一个实施例的用户界面示意图。图8的用户界面展示的是运行在OTT端的游戏大厅中的多个云游戏，该用户界面中展示的云游戏属于“推荐”功能下的游戏，用户可以通过对“遥控器游戏”功能以及“手柄游戏”功能的选择，触发OTT端展示对应功能下的游戏。具体地，用户可以对图8所示用户界面中的多个游戏进行选择，当用户触发多个游戏中任一游戏启动时，OTT端（即，客户端）可以确定出与触发操作对应的待鉴权参数，并对待鉴权参数进行加密并根据加密后的待鉴权参数生成加密的鉴权请求发送至后台服务器。

可见，实施该可选的实施例，能够通过客户端对待鉴权参数进行加密，提升待鉴权参数的安全性，降低鉴权请求中待鉴权参数被盗取的概率。

作为一种可选的实施例，客户端对待鉴权参数进行加密，包括：客户端通过对称加密算法或非对称加密算法对待鉴权参数进行加密。

其中，对称加密算法是指加密和解密使用相同密钥的加密算法，对称加密算法可以为DES算法、3DES算法、TDEA算法、Blowfish算法、RC5算法或IDEA算法等；非对称加密算法是指加密和解密使用不同密钥的加密算法，非对称加密算法可以为RSA算法、Elgamal算法、背包算法、Rabin算法、D-H算法或椭圆曲线加密算法（ECC）等，本申请实施例不作限定。

具体地，客户端通过对称加密算法对待鉴权参数进行加密的方式可以为：客户端通过预设密钥对待鉴权参数进行加密，以使得后台服务器接收到鉴权请求时也可以通过该预设密钥进行解密。客户端通过非对称加密算法对待鉴权参数进行加密的方式可以为：客户端通过用户私钥对待鉴权参数进行加密，以使得后台服务器接收到鉴权请求时可以通过用户公钥进行解密。

可见，实施该可选的实施例，能够通过对待鉴权参数的加密，提升其在传输过程中的安全性。

在步骤S720中，若验证出鉴权请求存在合法性，对鉴权请求进行共识并将鉴权请求写入区块链账本。

可选的，对鉴权请求进行共识，包括：通过工作量证明（Proof of Work，PoW）机制对鉴权请求进行共识；具体包括：在验证出鉴权请求存在合法性之后，将鉴权请求广播至区块链网络中并将鉴权请求作为交易信息写入交易池；进而，区块链网络中的共识节点可以在满足预设打包条件的情况下打包交易池中的交易信息，并计算打包所得的区块的随机数（Nonce），若共识节点中的目标节点计算出一随机数且该随机数满足于生成该区块的难度目标，则将该区块写入区块链。其中，预设打包条件可以为交易池中的交易信息数量满足预设数量，或者，预设打包条件可以为满足单位时间（如，20ms）。

进一步地，计算打包所得的区块的随机数，包括：各共识节点计算满足于表达式H(n||h) ≤ t中的n（随机数），并将最先计算出n的共识节点确定为目标节点；其中，H(n||h)为SHA256算法的哈希函数，t为难度目标，h为区块头的数据。SHA256算法用于对于任意长度的消息产生一个256位的哈希值（即，消息摘要），该消息摘要等于长度为32个字节的数组，可以通过长度为64的十六进制字符进行表示。

作为一种可选的实施例，对鉴权请求进行共识，包括：查询区块链账本的默克尔树中是否存在与鉴权请求对应的分支节点，如果不存在，则对鉴权请求进行共识。

具体地，默克尔树是一种二叉树，由一组叶节点（如，交易信息1、交易信息2、……、交易信息n，n为正整数）、一组中间节点（如，Hash1、 Hash 2、……、Hash n、Hash12、Hash23、Hash34、Hash1234等）和一个根节点（Merkel根）构成，每个区块包含一个默克尔树。另外，查询区块链账本的默克尔树中是否存在与鉴权请求对应的分支节点的时间复杂度是O(log

基于此，查询区块链账本的默克尔树中是否存在与鉴权请求对应的分支节点，包括：获取鉴权请求中的分链信息，根据分链信息中的根节点确定鉴权请求对应的区块，定位到该区块并根据分链信息中的中间节点计算叶节点；若叶节点与默克尔树中的一个叶节点一致，则判定默克尔树中存在与鉴权请求对应的分支节点；若叶节点与默克尔树中的一个叶节点不一致，则判定默克尔树中不存在与鉴权请求对应的分支节点。

基于此，如果默克尔树中存在与鉴权请求对应的分支节点，还可以包括：判定鉴权请求鉴权通过，并向服务端发送多媒体文件请求，以使得服务端根据鉴权请求对应的请求内容反馈相对应的多媒体文件作为响应数据。

可见，实施该可选的实施例，能够为首次数据请求的客户端上链鉴权请求，并在该客户端再次请求数据时，通过节点核查的方式确定是否存在与该客户端相对应的上链信息，如果存在，则可以直接判定请求合法，不仅提升了鉴权过程的安全性、鉴权结果的不可篡改性，还能够提升对于再次请求的响应效率。

作为一种可选的实施例，将鉴权请求写入区块链账本之后，还包括：从默克尔树中确定与鉴权请求对应的分支节点；向发送鉴权请求的客户端反馈分支节点。

具体地，分支节点的数量可以为一个或多个，多个分支节点可以构成分链信息，如，默克尔根-Hash12-Hash2-Tx2，包含该鉴权请求的交易信息对应于节点Tx2。

另外，向发送鉴权请求的客户端反馈分支节点之后，上述方法还可以包括：客户端根据分支节点更新待鉴权参数，更新后的待鉴权参数包括用于描述分支节点的信息。

可见，实施该可选的实施例，能够通过对于分支节点的反馈，使得客户端可以在下一次请求多媒体数据时直接发送包含分支节点的请求，后台服务器可以通过对于分支节点的成功核验，为客户端请求所需的多媒体数据，其中利用了区块链网络的不可篡改性和唯一性，当成功核验分支节点确实存在与默克尔树中之后，即可证明客户端的合法性。这样可以提升数据请求过程的安全性，相较于现有技术的通过中心化的后台服务器进行鉴权，本申请的鉴权方式更具可靠性，一定程度上避免中心化的后台服务器被攻击之后无法执行正常鉴权操作的问题。

作为一种可选的实施例，向发送鉴权请求的客户端反馈分支节点之后，还包括：客户端根据分支节点中的鉴权摘要生成新鉴权请求，并向后台服务器发送新鉴权请求。

具体地，新鉴权请求中可以包括分支节点中的鉴权摘要。

可见，实施该可选的实施例，能够通过对于首次请求的上链，提升后续请求的响应效率。

作为一种可选的实施例，对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本；其中，共识节点的数量与区块链中节点总数量之间的占比属于预设范围（如，0~20%）内。

举例来说，当区块链中节点总数量为5000时，共识节点的数量可以为1010，1010/5000=20%。另外，通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：共识节点根据拜占庭容错技术（Practical Byzantine Fault Tolerance，PBFT）对鉴权请求进行共识并将鉴权请求写入区块链账本。

可见，实施该可选的实施例，能够使云游戏鉴权的验证由中心化的后台系统转变为去中心化的区块链系统，提升了鉴权结果的可靠性、唯一性和不可篡改性。

作为一种可选的实施例，通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：广播鉴权请求以使得各个共识节点计算鉴权请求所属的区块的鉴权摘要：根据每个共识节点计算出的鉴权摘要的一致性确定共识结果；若共识结果符合预设结果，则将区块写入区块链账本。

具体地，区块链账本中的区块呈链式结构，每个区块均包括区块头和区块体。区块体用于存储自前一区块之后发生的多次下载记录。区块头中的字段包括版本、前一区块哈希（PreBlockHash）、默克尔根（Merkle Root）、时间戳、预设条件、目标随机数（Nonce）以及鉴权摘要，区块头可以表示为下表。

其中，第一列为区块头中包含的字段，第二列是对第一列中字段的描述解释，第三列是第一列中各字段占用字节的大小。

相应地，区块头对应的数据结构如下：

struct MyBlockHeader

{

string blockVersion; //版本

string previousBlockHash; //前一区块哈希

string MerkleRootNode; //默克尔根节点

string timestamp; //时间戳

int difficult; //预设条件

int nonce; //随机数

string data; //包含鉴权摘要的校验数据

}。

请参阅图9，图9示意性示出了根据本申请的一个实施例的区块结构示意图。如图9所示，示意性展示了区块链中的区块910、区块920和区块930，在区块910之前还可以包括多个区块（未图示），在区块930之后也可以包括多个区块（未图示）。具体地，区块910、区块920和区块930均可以包括区块头和区块体，区块头中均包括前一区块哈希（PreviousBlockHash）、随机数（Nonce）和默克尔根（MerkleRoot）。对于区块920的区块体进行了详细展示，对于区块910和区块930的区块体省略未展示。区块920的区块体中可以包括各默克尔节点：Tx1、Tx2、Tx3、Tx4，Tx1对应的哈希值Hash1、Tx2对应的哈希值Hash2、Tx3对应的哈希值Hash3、Tx4对应的哈希值Hash4、哈希值Hash1和哈希值Hash2对应的哈希值12、哈希值Hash3和哈希值Hash4对应的哈希值34。根据哈希值12和哈希值34可以计算出区块头中的默克尔根（Merkle Root）。

另外，广播鉴权请求以使得各个共识节点计算鉴权请求所属的区块的鉴权摘要之前，上述方法还可以包括：从所有共识节点中选取主节点，主节点不参与鉴权摘要的计算，主节点用于记录交易信息以及写入区块。其中，从所有共识节点中选取主节点，包括：根据分配给各共识节点的随机倒计时时长从所有共识节点中选取主节点，所选取的主节点对应的随机倒计时时长最先结束。另外，上述方法还可以包括：若主节点崩溃，可以通过分配给各共识节点的随机倒计时时长从剩下所有的共识节点中选取新的主节点。

基于此，广播鉴权请求，包括：主节点广播鉴权请求；或者，主节点确定与该鉴权请求处于同一接收时段的其他请求，根据接收时间排序并广播排序结果。进而，若主节点根据接收时间排序并广播排序结果，各个共识节点计算鉴权请求所属的区块的鉴权摘要，包括：各个共识节点计算排序结果对应的鉴权摘要。

基于此，根据每个共识节点计算出的鉴权摘要的一致性确定共识结果，并将区块写入区块链账本，包括：主节点接收各共识节点计算出的鉴权摘要，并确定各共识节点计算出的鉴权摘要是否满足（共识节点总数>3n+1）；若满足（共识节点总数>3n+1），则判定每个共识节点计算出的鉴权摘要之间存在一致性，确定用于表示共识成功的共识结果；进而，主节点将区块写入区块链账本；若不满足（共识节点总数>3n+1），则判定每个共识节点计算出的鉴权摘要之间不存在一致性，确定用于表示共识失败的共识结果；其中，n为有可能崩溃/出错的节点的最大个数。

可见，实施该可选的实施例，能够通过对鉴权请求进行上链，从而保证鉴权请求的合法性和正确性，保障服务器对正常用户请求的正常响应，避免服务器被伪造正常用户请求的恶意访问攻击。

在步骤S730中，根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应。

具体地，写入结果可以用于表示写入区块链成功或用于表示写入区块链失败。此外，响应数据可以为多媒体数据，当本申请应用于云游戏领域时，向服务端请求的可以是实时/非实时游戏画面。

作为一种可选的实施例，根据写入结果向服务端请求响应数据，包括：根据写入结果判定鉴权请求鉴权通过，并向服务端发送多媒体文件请求，以使得服务端根据鉴权请求对应的请求内容反馈相对应的多媒体文件作为响应数据。

具体地，多媒体文件请求中可以包括鉴权通过的设备信息（如，设备ID）和游戏信息（如，云游戏ID）等。

可见，实施该可选的实施例，能够利用分布式存储对请求进行鉴权共识记账，从而保证存储的鉴权请求中的参数的正确性、不可篡改性。

作为一种可选的实施例，根据响应数据对鉴权请求进行响应，包括：向发送鉴权请求的客户端反馈多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。

具体地，客户端根据多媒体文件渲染待展示内容之后，还可以包括：将渲染后的待展示内容展示与用户界面中，待展示内容可以为游戏画面。

可见，实施该可选的实施例，能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，提升鉴权过程的安全性和稳定性。

在步骤S740中，根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控。

具体地，用户标识可以表示为字符串，鉴权有效时长（如，2小时）用于表征当前用户存在合法性的时长，鉴权等级为至少两个。

另外，需要说明的是，智能合约是一种用算法和程序编制的合同条款，部署在区块链上，是可以按照规则自动执行的数字化协议。区块链的去中心化使得智能合约在没有中心管理者参与的情况下，可同时运行在全网所有节点。在本申请中，智能合约未直接运行在区块链节点上，以避免合约中包含恶意代码或漏洞时对区块链节点的安全造成威胁。本申请中的智能合约基于开源区块链分布式账本（Hyperledger Fabric）运行于沙箱环境中，其中，部署后的智能合约可以打包为 Docker 镜像，每个节点可以基于该镜像启动一个新的Docker 容器并执行合约中算法规则。

作为一种可选的实施例，根据从鉴权请求提取到的用户标识确定当前用户对应的鉴权等级之前，还包括：获取当前用户对应的充值记录，根据充值记录确定当前用户对应的鉴权等级；其中，当前用户对应的鉴权等级随当前用户对应的充值记录的变更而变更，当前用户对应的鉴权等级与当前用户对应的鉴权有效时长呈正相关。

具体地，获取当前用户对应的充值记录，包括：获取单位时间内的当前用户对应的至少一次充值记录，根据充值记录确定当前用户对应的鉴权等级。举例来说，单位时间为1周，充值总金额处于>100的用户的鉴权等级为A，A对应的鉴权有效时长为1小时；充值总金额处于100~500的用户的鉴权等级为B，B对应的鉴权有效时长为5小时；充值总金额处于500~1000的用户的鉴权等级为C，C对应的鉴权有效时长为100小时；充值总金额处于<1000的用户的鉴权等级为D，D对应的鉴权有效时长为280小时。

可见，实施该可选的实施例，能够基于用户的充值记录个性化确定出适合用户的鉴权等级，以在保证鉴权准确性的前提下提升鉴权效率，并且提升了鉴权的个性化程度。

作为一种可选的实施例，根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，包括：从鉴权请求提取当前用户对应的用户标识；确定区块链账本中用于记录各个用户等级的目标区块；从目标区块的默克尔树中读取用户标识对应的鉴权等级。

具体地，目标区块用于记录最新的用户等级，用户等级的更新时间晚于用户充值的时间。基于此，从鉴权请求提取当前用户对应的用户标识之前，还包括：以预设时长（如，1小时）为时间间隔对存在充值行为的用户所对应的用户等级进行更新。

可见，实施该可选的实施例，能够根据对于区块的回溯确定出最新的鉴权等级，以便确定出针对当前用户的个性化的鉴权有效时长，以提升鉴权效率，从而有利于优化对于计算机资源的分配。

作为一种可选的实施例，调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控之后，以及在检测到鉴权有效时长到期之前，还包括：当接收到当前用户对应的二次鉴权请求时，检测区块链账本中是否存在与二次鉴权请求对应的区块；如果是，则向服务端请求二次响应数据并将二次响应数据反馈至二次鉴权请求的客户端。

具体地，智能合约不仅能够监控时效还能够进行费用结算，二次鉴权请求为鉴权有效时长内的请求，故，无需执行合法性验证步骤，只需验证区块对于第一次的鉴权请求的检测结果存在，即可证明二次鉴权请求存在合法性。

可见，实施该可选的实施例，能够在当前用户对应的个性化的鉴权有效时长内，无需反复鉴权，以提升客户端请求数据时向其反馈数据的效率。

在步骤S750中，在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。

具体地，失效凭证可以通过包含多个字段的数据表构成。

作为一种可选的实施例，调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控，包括：由响应鉴权请求后开始对鉴权请求进行时效监控；若鉴权等级对应的鉴权有效时长未到期，且检测到用于接收响应数据的客户端停止接收数据时，确定数据传输时长；调用智能合约针对数据传输时长计算目标费用并从当前用户的账户中扣除目标费用。

具体地，确定数据传输时长，包括：以接收到响应鉴权请求为起始时间，以客户端停止接收数据的时刻为终止时间，确定连续的数据传输时长；其中，数据传输时长可以为游戏时长。

可见，实施该可选的实施例，能够通过对于智能合约的调用，使其不仅可以实现对于时效的监控，还能够实现对于费用的实时计算，可以使用户感受到不同充值环境下的服务体验。

请参阅图10，图10示意性示出了根据本申请的一个实施例的基于区块链的鉴权方法的序列图。如图10所示，该序列图可以包括：步骤S1010~步骤S1080。

S1010：启动云游戏。具体地，用户可以通过客户端（如，OTT端）启动云游戏。

S1020：发送鉴权请求。具体地，客户端可以获取当前设备对应的待鉴权参数，如，GUID、MAC地址、预置在应用程序内的包括云游戏ID、云游戏渠道ID、encrypted_key等，进而向后台服务器发送包含鉴权参数的鉴权请求。

S1030：校验鉴权请求的合法性。具体地，后台服务器内部维护的区块链对待鉴权参数的合法性进行检验。

S1040：对合法的鉴权请求进行共识记账。具体地，后台服务器内部维护的区块链的共识节点可以对合法的鉴权请求进行共识记账，具体包括：广播鉴权请求以使得各个共识节点计算鉴权请求所属的区块的鉴权摘要，根据每个共识节点计算出的鉴权摘要的一致性确定共识结果，若共识结果符合预设结果，则将区块写入区块链账本。

S1050：反馈鉴权请求对应的默克尔树分支节点。具体地，后台服务器可以向客户端反馈鉴权请求对应的默克尔树分支节点，便于客户端可以在下一次请求多媒体数据时直接发送包含分支节点的请求，从而免于共识记账过程。

S1060：发送多媒体文件请求。具体地，后台服务器可以在鉴权结果表示鉴权成功时向服务端发送多媒体文件请求。

S1070：反馈多媒体文件。具体地，服务端响应于多媒体文件请求反馈多媒体文件。

S1080：发送多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。具体地，服务端可以将多媒体文件反馈至客户端，以使得客户端根据多媒体文件渲染待展示内容并将待展示内容通过用户界面展示给用户。

请参阅图11，图11示意性示出了根据本申请的一个实施例的基于区块链的鉴权方法的流程图。如图11所示，该基于区块链的鉴权方法可以包括：步骤S1100~步骤S1170。

步骤S1100：客户端对待鉴权参数进行加密并根据加密后的待鉴权参数生成加密的鉴权请求发送至后台服务器。

步骤S1110：后台服务器接收由客户端发送的加密的鉴权请求，并对鉴权请求进行解密。

步骤S1120：当接收到鉴权请求时，后台服务器对鉴权请求进行合法性验证。若验证出鉴权请求存在合法性，则执行步骤S1130。若验证出鉴权请求不存在合法性，则结束流程。

步骤S1130：后台服务器查询区块链账本的默克尔树中是否存在与鉴权请求对应的分支节点。如果存在，则执行步骤S1170。如果不存在，则执行步骤S1140。

步骤S1140：后台服务器通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本；其中，共识节点的数量与区块链中节点总数量之间的占比属于预设范围内。

步骤S1150：后台服务器从默克尔树中确定与鉴权请求对应的分支节点，并向发送鉴权请求的客户端反馈分支节点。

步骤S1160：后台服务器根据写入结果判定鉴权请求鉴权通过，并向服务端发送多媒体文件请求，以使得服务端根据鉴权请求对应的请求内容反馈相对应的多媒体文件作为响应数据。

步骤S1170：后台服务器向发送鉴权请求的客户端反馈多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。

需要说明的是，步骤S1100~步骤S1170与图7所示的各步骤及其实施例相对应，针对步骤S1100~步骤S1170的具体实施方式，请参阅图7所示的各步骤及其实施例，此处不再赘述。

可见，实施图11所示的方法，能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，在接收到鉴权请求之后，对其进行验证、共识、写入，从而确保鉴权请求的合法性和隐私性，避免恶意鉴权请求攻击后台服务器。此外，能够利用区块链分布式存储的优势，解决现有技术中后台服务器宕机后无法及时鉴权的问题，提升鉴权过程的稳定性。此外，能够通过对于鉴权请求进行时效监控，使得当前用户在个性化的鉴权有效时长内具备合法性，从而在保证安全性的前提下降低鉴权次数避免计算资源的浪费。

进一步的，本示例实施方式中，还提供了一种基于区块链的鉴权装置。参考图12所示，该基于区块链的鉴权装置1200可以包括：

请求验证单元1201，用于当接收到鉴权请求时，对鉴权请求进行合法性验证；

请求共识单元1202，用于在验证出鉴权请求存在合法性时，对鉴权请求进行共识并将鉴权请求写入区块链账本；

请求响应单元1203，用于根据写入结果向服务端请求响应数据，并根据响应数据对鉴权请求进行响应；

时效监控单元1204，用于根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，并调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控；

失效信息上链单元1205，用于在检测到鉴权有效时长到期时，生成用于表征鉴权请求失效的失效凭证，并将失效凭证写入区块链账本；其中，失效后的鉴权请求无法证明当前用户的合法性。

可见，实施图12所示的装置，能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，在接收到鉴权请求之后，对其进行验证、共识、写入，从而确保鉴权请求的合法性和隐私性，避免恶意鉴权请求攻击后台服务器。此外，能够利用区块链分布式存储的优势，解决现有技术中后台服务器宕机后无法及时鉴权的问题，提升鉴权过程的稳定性。此外，能够通过对于鉴权请求进行时效监控，使得当前用户在个性化的鉴权有效时长内具备合法性，从而在保证安全性的前提下降低鉴权次数避免计算资源的浪费。

在本公开的一种示例性实施例中，时效监控单元1204根据从鉴权请求中提取到的用户标识确定当前用户对应的鉴权等级，包括：

从鉴权请求提取当前用户对应的用户标识；

确定区块链账本中用于记录各个用户等级的目标区块；

从目标区块的默克尔树中读取用户标识对应的鉴权等级。

可见，实施该可选的实施例，能够根据对于区块的回溯确定出最新的鉴权等级，以便确定出针对当前用户的个性化的鉴权有效时长，以提升鉴权效率，从而有利于优化对于计算机资源的分配。

在本公开的一种示例性实施例中，时效监控单元1204调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控之后，以及在失效信息上链单元1205检测到鉴权有效时长到期之前，还包括：

检测单元（未图示），用于当接收到当前用户对应的二次鉴权请求时，检测区块链账本中是否存在与二次鉴权请求对应的区块；

请求响应单元1203，还用于在检测单元检测到区块链账本中存在与二次鉴权请求对应的区块之后，向服务端请求二次响应数据并将二次响应数据反馈至二次鉴权请求的客户端。

可见，实施该可选的实施例，能够在当前用户对应的个性化的鉴权有效时长内，无需反复鉴权，以提升客户端请求数据时向其反馈数据的效率。

在本公开的一种示例性实施例中，时效监控单元1204调用智能合约，以使得智能合约根据鉴权等级对应的鉴权有效时长对鉴权请求进行时效监控，包括：

由响应鉴权请求后开始对鉴权请求进行时效监控；

若鉴权等级对应的鉴权有效时长未到期，且检测到用于接收响应数据的客户端停止接收数据时，确定数据传输时长；

调用智能合约针对数据传输时长计算目标费用并从当前用户的账户中扣除目标费用。

可见，实施该可选的实施例，能够通过对于智能合约的调用，使其不仅可以实现对于时效的监控，还能够实现对于费用的实时计算，可以使用户感受到不同充值环境下的服务体验。

在本公开的一种示例性实施例中，还包括：

鉴权等级确定单元（未图示），用于在时效监控单元1204根据从鉴权请求提取到的用户标识确定当前用户对应的鉴权等级之前，获取当前用户对应的充值记录，根据充值记录确定当前用户对应的鉴权等级；

其中，当前用户对应的鉴权等级随当前用户对应的充值记录的变更而变更，当前用户对应的鉴权等级与当前用户对应的鉴权有效时长呈正相关。

可见，实施该可选的实施例，能够基于用户的充值记录个性化确定出适合用户的鉴权等级，以在保证鉴权准确性的前提下提升鉴权效率，并且提升了鉴权的个性化程度。

在本公开的一种示例性实施例中，还包括：

请求接收单元（未图示），用于在请求验证单元1201对鉴权请求进行合法性验证之前，接收由客户端发送的加密的鉴权请求，并对鉴权请求进行解密。

可见，实施该可选的实施例，能够通过对于鉴权请求的加解密，提升请求传输过程中的数据安全性。

在本公开的一种示例性实施例中，请求接收单元接收由客户端发送的加密的鉴权请求之前，客户端对待鉴权参数进行加密并根据加密后的待鉴权参数生成加密的鉴权请求发送至后台服务器。

可见，实施该可选的实施例，能够通过客户端对待鉴权参数进行加密，提升待鉴权参数的安全性，降低鉴权请求中待鉴权参数被盗取的概率。

在本公开的一种示例性实施例中，客户端对待鉴权参数进行加密，包括：

客户端通过对称加密算法或非对称加密算法对待鉴权参数进行加密。

可见，实施该可选的实施例，能够通过对待鉴权参数的加密，提升其在传输过程中的安全性。

在本公开的一种示例性实施例中，请求共识单元1202对鉴权请求进行共识，包括：

查询区块链账本的默克尔树中是否存在与鉴权请求对应的分支节点，如果不存在，则对鉴权请求进行共识。

可见，实施该可选的实施例，能够为首次数据请求的客户端上链鉴权请求，并在该客户端再次请求数据时，通过节点核查的方式确定是否存在与该客户端相对应的上链信息，如果存在，则可以直接判定请求合法，不仅提升了鉴权过程的安全性、鉴权结果的不可篡改性，还能够提升对于再次请求的响应效率。

在本公开的一种示例性实施例中，还包括：

节点确定单元（未图示），用于在请求共识单元1202将鉴权请求写入区块链账本之后，从默克尔树中确定与鉴权请求对应的分支节点；

节点反馈单元（未图示），用于向发送鉴权请求的客户端反馈分支节点。

可见，实施该可选的实施例，能够通过对于分支节点的反馈，使得客户端可以在下一次请求多媒体数据时直接发送包含分支节点的请求，后台服务器可以通过对于分支节点的成功核验，为客户端请求所需的多媒体数据，其中利用了区块链网络的不可篡改性和唯一性，当成功核验分支节点确实存在与默克尔树中之后，即可证明客户端的合法性。这样可以提升数据请求过程的安全性，相较于现有技术的通过中心化的后台服务器进行鉴权，本申请的鉴权方式更具可靠性，一定程度上避免中心化的后台服务器被攻击之后无法执行正常鉴权操作的问题。

在本公开的一种示例性实施例中，节点反馈单元向发送鉴权请求的客户端反馈分支节点之后，客户端根据分支节点中的鉴权摘要生成新鉴权请求，并向后台服务器发送新鉴权请求。

可见，实施该可选的实施例，能够通过对于首次请求的上链，提升后续请求的响应效率。

在本公开的一种示例性实施例中，请求响应单元1203根据写入结果向服务端请求响应数据，包括：

根据写入结果判定鉴权请求鉴权通过，并向服务端发送多媒体文件请求，以使得服务端根据鉴权请求对应的请求内容反馈相对应的多媒体文件作为响应数据。

可见，实施该可选的实施例，能够利用分布式存储对请求进行鉴权共识记账，从而保证存储的鉴权请求中的参数的正确性、不可篡改性。

在本公开的一种示例性实施例中，请求响应单元1203根据响应数据对鉴权请求进行响应，包括：

向发送鉴权请求的客户端反馈多媒体文件，以使得客户端根据多媒体文件渲染待展示内容。

可见，实施该可选的实施例，能够利用去中心化的区块链网络的唯一性、不可篡改性和可靠性，提升鉴权过程的安全性和稳定性。

在本公开的一种示例性实施例中，请求共识单元1202对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：

通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本；其中，共识节点的数量与区块链中节点总数量之间的占比属于预设范围内。

可见，实施该可选的实施例，能够使云游戏鉴权的验证由中心化的后台系统转变为去中心化的区块链系统，提升了鉴权结果的可靠性、唯一性和不可篡改性。

在本公开的一种示例性实施例中，请求共识单元1202通过共识节点对鉴权请求进行共识并将鉴权请求写入区块链账本，包括：

广播鉴权请求以使得各个共识节点计算鉴权请求所属的区块的鉴权摘要：

根据每个共识节点计算出的鉴权摘要的一致性确定共识结果；

若共识结果符合预设结果，则将区块写入区块链账本。

其中，区块至少包括：版本、前一区块哈希、默克尔根、时间戳、预设条件、目标随机数以及鉴权摘要。

可见，实施该可选的实施例，能够通过对鉴权请求进行上链，从而保证鉴权请求的合法性和正确性，保障服务器对正常用户请求的正常响应，避免服务器被伪造正常用户请求的恶意访问攻击。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

由于本申请的示例实施例的基于区块链的鉴权装置的各个功能模块与上述基于区块链的鉴权方法的示例实施例的步骤对应，因此对于本申请装置实施例中未披露的细节，请参照本申请上述的基于区块链的鉴权方法的实施例。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。