一种权限管理方法、装置、存储介质及电子设备与流程

本发明涉及区块链技术领域，具体而言，涉及一种权限管理方法、装置、存储介质及电子设备。

背景技术：

目前在金融证券等行业都有一些对应用户权限的系统，分别用于实现购买权限、分发权限、资金对账、权限过期处理等功能。在现有的架构中，各个系统提供各自的服务接口，通过系统之间的相互调用来实现预期的功能，系统之间的耦合程度极高，容错性较差。

技术实现要素：

本申请实施例的目的在于提供一种权限管理方法、装置、存储介质及电子设备，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种权限管理方法，包括：支付系统在用户购买权限后生成权限购买记录，并向区块链集群中部署的区块链写入所述权限购买记录；区块链集群在监听到向所述区块链写入所述权限购买记录的行为时，执行部署在所述区块链上的第一智能合约；其中，所述第一智能合约被配置为：在执行时向权限系统发送第一通知消息，以使所述权限系统生成所述用户购买的权限，并由所述区块链集群向所述区块链中写入所述权限与所述用户的绑定关系。

在上述方法中，首先，支付系统和权限系统并不直接交互，而是通过区块链上部署的第一智能合约产生联系，即通过区块链实现了去中心化的解耦，有利于改善系统的容错性。其次，相关数据（比如，权限购买记录、权限与用户的绑定关系）或代码（第一智能合约）都记录在区块链上，从而对区块链的各参与方公开透明，不会产生数据黑盒效应。另外，基于区块链的用户权限下放（从权限系统生成权限开始，到权限与用户绑定的过程）过程完全智能化、流程化，数据难以伪造。

在第一方面的一种实现方式中，在所述权限系统生成所述用户购买的权限之前，所述方法还包括：所述权限系统响应所述第一通知消息，通过查询所述区块链中写入的所述权限购买记录确定权限购买行为的合法性。

在第一方面的一种实现方式中，所述第一智能合约还被配置为：在执行时向财务系统发送第二通知消息；所述方法还包括：所述财务系统响应所述第二通知消息，通过查询所述区块链中写入的所述权限购买记录确定权限购买行为的合法性。

对于以上两种实现方式，权限系统和财务系统，都可以利用区块链的防篡改机制进行校验和对账，确保权限购买行为合法，并且，由于只需利用区块链进行对账，对账过程简单高效，对账成本较低。在现有技术中，通常的做法是支付系统、权限系统以及财务系统三者之间相互进行校验和对账，对账过程复杂，对账成本较高。并且，在现有技术中一般是批量对账，即每隔一段时间进行一次对账，而利用区块链则可以支持实时对账，即每发生一次权限购买行为立即进行对账。

在第一方面的一种实现方式中，所述方法还包括：业务系统通过查询所述区块链中写入的所述绑定关系确定所述用户已经购买了所述权限。

当用户要使用业务系统提供的服务时，可以提供表征其身份的信息，例如用户id，业务系统根据该身份信息可以从区块链上查询用户具有的权限，从而为用户提供相应的服务。

在第一方面的一种实现方式中，所述方法还包括：区块链集群在监听到向所述区块链写入所述绑定关系的行为时，执行部署在所述区块链上的第二智能合约；其中，所述第二智能合约被配置为：在执行时向业务系统发送所述绑定关系；所述业务系统在本地保存接收到的所述绑定关系，并通过查询本地保存的所述绑定关系确定所述用户已经购买了所述权限。

在上述实现方式中，权限与用户的绑定关系除了在区块链上存储以外，还可以发送给业务系统存储，这样业务系统无需每次从区块链上查询用户的权限，只需在业务系统本地进行查询，从而可以提高查询效率。上述第二智能合约也可以和第一智能合约实现为同一个合约。

在第一方面的一种实现方式中，在所述区块链集群执行部署在所述区块链上的第一智能合约之前，所述方法还包括：所述区块链集群接收业务系统、所述权限系统、所述支付系统以及财务系统中任意一方提交的所述第一智能合约，并在满足预设条件时确定所述第一智能合约生效;其中，所述预设条件包括：除合约提交方以外的各方已经通过私钥签名确认所述第一智能合约的代码无误。

在上述实现方式中，第一智能合约经多方私钥签名确认后才能生效，确保了合约内容得到了区块链各参与方的共同认可，合约内容真实可信。

在第一方面的一种实现方式中，所述区块链采用联盟链。

本申请方案中涉及的支付系统、权限系统、业务系统、财务系统等均为联盟链的参与方，每个系统在实现上可以是一个集群，联盟链的节点可以部署在各个系统集群内部，相互之间通过专线交互，即使某个系统集群发生了故障，剩余系统集群中的节点仍然可以提供服务，即具有可降级灾备的特性。

第二方面，本申请实施例提供一种权限管理装置，包括：记录写入模块，用于支付系统在用户购买权限后生成权限购买记录，并向区块链集群中部署的区块链写入所述权限购买记录；合约执行模块，用于区块链集群在监听到向所述区块链写入所述权限购买记录的行为时，执行部署在所述区块链上的第一智能合约；其中，所述第一智能合约被配置为：在执行时向权限系统发送第一通知消息，以使所述权限系统生成所述用户购买的权限，并由所述区块链集群向所述区块链中写入所述权限与所述用户的绑定关系。

第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法的步骤。

第四方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种权限管理系统的结构图；

图2示出了本申请实施例提供的一种权限管理方法的流程图；

图3示出了本申请实施例提供的一种权限管理装置的模块图；

图4示出了本申请实施例提供的一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

图1示出了本申请实施例提供的一种权限管理系统的结构图。参照图1，权限管理系统100包括区块链集群110、支付系统120、权限系统130、财务系统140以及业务系统150。当然，在一些实现方式中，权限管理系统100也可以只包含4个系统中的一部分：例如，只包含支付系统120和权限系统130；又例如，只包含支付系统120、权限系统130和财务系统140，等等。

其中，区块链集群110是由多个区块链节点构成区块链系统，集群中部署有区块链数据库（简称区块链），区块链的分布式账本由各个区块链节点保存。

支付系统120、权限系统130、财务系统140以及业务系统150均可以实现为一个具有特定功能的集群（后文有时也称系统集群），其中包含多个节点。各系统具有的功能简介如下，可以理解的，下面仅仅是各系统的主要功能，并不代表各系统只具有这些功能。

支付系统120：接入微信、支付宝、apple支付等相关通道，让用户可以通过支付对应的金额来购买相应的服务，如权限。比如，一款能够查看股票行情的app，用户安装后可以免费查看一些基础的信息，但如果用户希望查看更多的指标，或者希望看到更快的盘口变化，则需要付费购买高级权限。

权限系统130：为用户生成权限，所谓权限就是一种表征用户所具有的权益的凭证，例如，权限可以实现为一个令牌，一个标识等。

财务系统140：在业务流程中进行金额核对并生成报表，例如，用户通过支付系统120支付的金额可以由财务系统140进行核对。

业务系统150：直接与用户交互，从而为用户提供服务，若某些服务需要用户具有相应的权限，则业务系统150应当对用户是否具有该权限进行验证。

继续参照图1，上述4个系统均可以和区块链集群进行通信，至于4个系统相互之间能否相互通信本申请不作限定。在后文中，若提到区块链集群110执行某个步骤，应理解为区块链集群中的一个或多个节点来执行该步骤；类似地，若提到某个系统（指上述4个系统之一）执行某个步骤，应理解为该系统集群中的一个或多个节点来执行该步骤。

另外，还需要指出，区块链节点和系统集群中的节点并没有严格的界限，既有可能是同一个物理节点也有可能是不同的物理节点。

下面介绍权限管理系统100中采用的一些典型配置：

（1）传输机制：这里所谓的传输，既可以包括区块链集群110中各区块链节点之间的数据传输，又可以包括区块链节点和各系统集群中节点之间的数据传输。权限管理系统100中采用tcp/ip协议中p2p的交互模型，底层使用netty等进行连接，保证了数据传递的快捷高效性，以及通过定期的心跳校验和重试连接，保证其关联的稳定性。

例如，在区块链集群110部署后，区块链节点间通过p2p点对点交互确认进行节点身份校验后，建立tcp通信连接，连接期间则通过心跳检测进行关联性验证，一旦心跳失败或者异常断开，节点之间会自动发起重连。

（2）区块链类型：采用联盟链，所谓联盟链是指一种只针对某个特定群体的成员和有限的第三方开放的区块链，在本申请的方案中，所谓特定群体就是指支付系统120、权限系统130、财务系统140以及业务系统150。联盟链的节点可以部署在各个系统集群内部，相互之间通过专线交互而不是直接互通，即使某个系统集群发生了故障，剩余系统集群中的节点仍然可以正常提供服务，即具有可降级灾备的特性。

（3）共识算法：采用股权授权证明（delegatedproofofstake，简称dpos），dpos机制通过股权的多少来分配哪个节点参加记账，最后由多个股权节点来选举出哪个股权节点进行区块记录。由于使用联盟链，所以采用dpos机制可以减少产生区块时的额外损耗，产生速度快，而且dpos机制可以有效的控制产生区块的节点，使得外部很难伪造或者攻击集群。

（4）签名及加密机制：区块链中的区块生成使用sha-256算法实施签名，签名算法使用base58进行处理字符串处理，使得数据可输入，可读、可处理，公私钥加密算法使用ecc（椭圆加密算法）。

可以理解的，以上配置是适合本申请方案的较好配置，但并不是说权限管理系统100只能采用上述配置，也不是说上述配置是权限管理系统100的最优配置。

发明人研究发现，现有技术中，虽然也有一些功能与支付系统120、权限系统130、财务系统140以及业务系统150类似的系统，但存在如下缺陷：

（1）开发这些系统需要业务部门、支付部门、财务部门等多个部门相互协调，开发成本高。

（2）各个系统之间的耦合度极高，导致系统容错性很低，任何系统出现问题，业务流程都不能继续进行下去。

（3）财务审核时对业务不了解，需要深入学习后才能正确处理相关报表，学习成本较高。

（4）需要多个系统之间相互对账，对账过程复杂，对账成本高，并且很多对账数据是重复性质的，造成极大的资源浪费。并且，对账一般采用定时对账，即每隔一段时间针对一批交易进行对账，实时性较差。

（5）各系统间的信息不互联互通，数据产生黑盒，无法保障数据的准确性，只能通过延迟的对账处理或者人工干预才可以达到数据准确。

为解决上述技术问题，本申请实施例提供一种权限管理方法，图2示出了其可能的执行流程。参照图2，该方法包括：

步骤s200：支付系统生成权限购买记录。

用户通过支付系统接入的相关通道购买权限后，支付系统上会生成用户的购买记录，例如，其中可以包含用户的身份信息（如用户id）、购买花费的金额、权限的描述信息等。

步骤s210：支付系统向区块链集群中部署的区块链写入权限购买记录。

区块链集群可以提供服务接口供支付系统调用，支付系统调用其中用于写入数据的接口即可以将步骤s200中生成的权限购买记录写入到区块链中。至于区块链节点如何记账，属于现有技术，此处不进行详细阐述。

步骤s220：区块链集群在监听到向区块链写入权限购买记录的行为时，执行部署在区块链上的第一智能合约。

第一智能合约的主要功能是实现用户购买权限后的权限下放（即生成权限并将权限分配给用户）。在一种实现方式中，第一智能合约可由业务系统、权限系统、支付系统以及业务系统中的任意一方向区块链集群提交，提交后的智能合约将保存在区块链上。其中，上述每一方都持有自己专属的公私钥对，一方提交合约后，其余各方均可以查看合约代码（查看代码可由人工利用各系统查看），例如查看代码是否存在错误，是否包含恶意代码等。若某一方确认代码无误，则可用自己持有的私钥对特定信息（例如，第一智能合约的哈希值）进行签名，表明认可第一智能合约的内容，当除合约提交方以外的各方均通过私钥签名确认了第一智能合约的内容无误后，区块链集群将会使第一智能合约生效。由于合约生效过程得到了区块链参与各方的共同认可，所以合约内容真实可信。

智能合约具有触发条件并且可以监听触发条件是否满足，在满足触发条件时，智能合约将被区块链节点执行。对于第一智能合约而言，其触发条件是存在向区块链写入权限购买记录的行为，从而当步骤s210执行后，第一智能合约将被触发并执行合约代码。

第一智能合约的代码逻辑可以包括步骤s221至步骤s226，当然，由于第一智能合约在区块链节点上执行，因此严格来说，在步骤s221至步骤s226中，只有那些在区块链节点上执行的步骤才属于第一智能合约的代码逻辑，不过由于这些步骤之间关系密切，所以为简单起见，在图2中将这些步骤都放到步骤s220之下。

步骤s221：区块链集群向权限系统发送第一通知消息。

第一通知消息用于告知权限系统用户购买了权限，权限系统在接收到第一通知消息后，作为响应可以执行步骤s222以及步骤s223。

步骤s222：权限系统通过查询区块链中写入的权限购买记录确定权限购买行为的合法性。

权限系统可以利用区块链的防篡改机制进行校验和对账，确保权限购买行为合法。其中，校验可以指验证权限购买行为的真实性，比如区块链上是否有记录该行为，对账则可以指验证权限购买行为的金额是否与区块链上记录的一致。若权限购买行为合法则可以继续执行步骤s223，否则可以终止方法流程。在一些实现方式中，若不需要权限系统验证权限购买行为的合法性，也可以直接跳过步骤s222。

步骤s223：权限系统生成用户购买的权限，并向区块链集群发送生成的权限。

第一通知消息中可以携带权限的描述信息，从而权限系统根据该描述信息可以为用户生成其所购买的权限（指表征权限的凭证）。在一些实现方式中，权限系统可以提供服务接口供区块链集群调用，区块链集群调用其中用于生成权限的接口即可以获取用户购买的权限。

步骤s224：区块链集群向区块链中写入权限与用户的绑定关系。

区块链集群从权限系统获得权限后，将其与购买该权限的用户（可以指用户的身份信息）绑定起来，并将这一绑定关系记录在区块链中。此时，由于用户已经和自己购买的权限绑定，所以可以认为用户已经获得了其购买的权限。当然，该权限要被业务系统认可后，才会真正发挥其效用。

步骤s225：区块链集群向财务系统发送第二通知消息。

第二通知消息用于告知财务系统用户购买了权限，财务系统在接收到第二通知消息后，作为响应可以执行步骤s226。在一些实现方式中，若权限管理系统不包括财务系统，也可以直接跳过步骤s225和步骤s226。

步骤s226：财务系统通过查询区块链中写入的权限购买记录确定权限购买行为的合法性。

步骤s226和步骤s222类似，不再重复。若财务系统判断权限购买行为合法则可以继续执行后续操作，例如产生报表等，否则可以终止方法流程。在一些实现方式中，若不需要财务系统验证权限购买行为的合法性，也可以直接跳过步骤s226。

步骤s230：业务系统通过查询区块链中写入的权限与用户的绑定关系确定用户已经购买了权限。

用户访问业务系统时（例如，登陆账号），可以提供其身份信息，从而业务系统可以根据该身份信息查询该用户是否具有某项权限，如果查询到用户已经购买了某项权限，则可以为其提供对应的服务，否则不能为其提供该项权限对应的服务。至于如何查询用户是否具有某项权限，有不同的实现方式，本申请列举了两种：第一种是步骤s230，通过查询之前在步骤s224中向区块链中写入的权限与用户的绑定关系确定用户的权限情况；第二种是步骤s240至步骤s250，简单概括就是查询在业务系统本地保存的权限与用户的绑定关系确定用户的权限情况。在实施时，这两种方式择一实现即可。

步骤s240：区块链集群在监听到向区块链写入权限与用户的绑定关系的行为时，执行部署在区块链上的第二智能合约。

对于第二智能合约而言，其触发条件是存在向区块链写入权限与用户的绑定关系的行为，从而当步骤s224执行后，第二智能合约将被触发并执行合约代码。第二智能合约主要供业务系统使用，因此可以由，但不限于由业务系统提交，至于第二智能合约的生效过程与第一智能合约类似，不再重复阐述。

第二智能合约的代码逻辑可以包括步骤s241至步骤s242，当然，由于第二智能合约在区块链节点上执行，因此严格来说，只有步骤s241才属于第二智能合约的代码逻辑，不过由于这两个步骤之间关系密切，所以为简单起见，在图2中将这两个步骤都放到步骤s240之下。

步骤s241：区块链集群向业务系统发送权限与用户的绑定关系。

步骤s242：业务系统在本地保存接收到的权限与用户的绑定关系。

以上两个步骤合并在一起进行阐述，在步骤s224中，区块链集群一方面将权限与用户的绑定关系写入区块链，另一方面触发第二智能合约，将权限与用户的绑定关系发送至业务系统进行存储。也不排除在一些实现方式中，并不执行步骤s224将权限与用户的绑定关系写入区块链，而是直接将该绑定关系发送至业务系统进行存储（当然此时第二智能合约的触发条件也需要随之调整），但考虑到区块链中的数据具有防篡改、便于他人进行验证的特性，先将权限与用户的绑定落地到区块链中保存是一种安全的做法。

步骤s250：业务系统通过查询本地保存的权限与用户的绑定关系确定用户已经购买了所述权限。

由于在步骤s240中业务系统将权限与用户的绑定关系保存在本地，因此，当用户访问业务系统时，业务系统只需从本地查询用户的权限情况，没有必要再从区块链上进行查询，这样可以提高查询效率。当然，区块链上可以继续保存权限与用户的绑定关系，除了出于安全因素考虑，区块链上的数据也可以作为备份，若业务系统中的数据出现异常，还可以根据区块链上记录的数据进行恢复，而区块链分布式存储的特点使得这样的数据恢复变得容易。

进一步的，在一些实现方式中，第二智能合约也可以和第一智能合约实现为同一个合约，比如，将步骤s241的逻辑放到第一智能合约中执行也是可以的。另外，第二智能合约的功能也不限于向业务系统发送权限与用户的绑定关系，还可以在合约中定义其他功能。

综上所述，在本申请实施例提供权限管理方法中，首先，各系统（支付系统、权限系统、财务系统、业务系统）不直接进行交互，而是通过区块链或者智能合约产生联系，即借助于区块链实现了去中心化的系统解耦，从而有利于改善系统的容错性。并且，由于实现了各系统解耦，使得各部门在开发相应的系统时，无需过多关注其他系统的开发进度，开发成本大大降低。

其次，权限系统和财务系统都只需利用区块链进行校验和对账，对账过程简单高效，对账成本较低。在现有技术中，通常的做法是支付系统、权限系统以及财务系统三者之间相互进行校验和对账，对账过程复杂，对账成本较高。并且，利用区块链则可以支持实时对账，即每发生一次权限购买行为立即查询区块链就可以完成校验和对账，执行效率较高。另外，由于财务系统和业务系统并不直接进行对账，使得财务无需过多了解业务逻辑，从而有利于降低相关人员的学习成本。

再者，与权限相关的数据（比如，权限购买记录、权限与用户的绑定关系）或代码（第一智能合约）都记录在区块链上，从而对区块链的各参与方公开透明，不会产生数据黑盒效应。

最后，基于区块链的用户权限下放过程完全智能化、流程化，数据难以伪造，使得对用户权限的管理安全高效。

图3示出了本申请实施例提供的权限管理装置300的功能模块图。参照图3，权限管理装置300包括：

记录写入模块310，用于支付系统在用户购买权限后生成权限购买记录，并向区块链集群中部署的区块链写入所述权限购买记录；

合约执行模块320，用于区块链集群在监听到向所述区块链写入所述权限购买记录的行为时，执行部署在所述区块链上的第一智能合约；其中，所述第一智能合约被配置为：在执行时向权限系统发送第一通知消息，以使所述权限系统生成所述用户购买的权限，并由所述区块链集群向所述区块链中写入所述权限与所述用户的绑定关系。

在权限管理装置300的一种实现方式中，所述装置还包括：第一验证模块，用于所述权限系统在生成所述用户购买的权限之前，响应所述第一通知消息，通过查询所述区块链中写入的所述权限购买记录确定权限购买行为的合法性。

在权限管理装置300的一种实现方式中，所述第一智能合约还被配置为：在执行时向财务系统发送第二通知消息；所述装置还包括：第二验证模块，用于所述财务系统响应所述第二通知消息，通过查询所述区块链中写入的所述权限购买记录确定权限购买行为的合法性。

在权限管理装置300的一种实现方式中，所述装置还包括：第一权限查询模块，用于业务系统通过查询所述区块链中写入的所述绑定关系确定所述用户已经购买了所述权限。

在权限管理装置300的一种实现方式中，合约执行模块320还用于区块链集群在监听到向所述区块链写入所述绑定关系的行为时，执行部署在所述区块链上的第二智能合约；其中，所述第二智能合约被配置为：在执行时向业务系统发送所述绑定关系；所述装置还包括：第二权限查询模块，用于所述业务系统在本地保存接收到的所述绑定关系，并通过查询本地保存的所述绑定关系确定所述用户已经购买了所述权限。

在权限管理装置300的一种实现方式中，所述装置还包括：合约生效模块，用于所述区块链集群在所述区块链集群执行部署在所述区块链上的第一智能合约之前，接收业务系统、所述权限系统、所述支付系统以及财务系统中任意一方提交的所述第一智能合约，并在满足预设条件时确定所述第一智能合约生效；其中，所述预设条件包括：除合约提交方以外的各方已经通过私钥签名确认所述第一智能合约的代码无误。

在权限管理装置300的一种实现方式中，所述区块链采用联盟链。

本申请实施例提供的权限管理装置300，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

图4示出了本申请实施例提供的电子设备400的一种可能的结构。参照图4，电子设备400包括：处理器410、存储器420以及通信接口430，这些组件通过通信总线440和/或其他形式的连接机构（未示出）互连并相互通讯。

其中，存储器420包括一个或多个（图中仅示出一个），其可以是，但不限于，随机存取存储器（randomaccessmemory，简称ram），只读存储器（readonlymemory，简称rom），可编程只读存储器（programmableread-onlymemory，简称prom），可擦除只读存储器（erasableprogrammableread-onlymemory，简称eprom），电可擦除只读存储器（electricerasableprogrammableread-onlymemory，简称eeprom）等。处理器410以及其他可能的组件可对存储器420进行访问，读和/或写其中的数据。

处理器410包括一个或多个（图中仅示出一个），其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器410可以是通用处理器，包括中央处理器（centralprocessingunit，简称cpu）、微控制单元（microcontrollerunit，简称mcu）、网络处理器(networkprocessor，简称np）或者其他常规处理器；还可以是专用处理器，包括数字信号处理器（digitalsignalprocessor,简称dsp)、专用集成电路（applicationspecificintegratedcircuits，简称asic）、现场可编程门阵列（fieldprogrammablegatearray，简称fpga）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口430包括一个或多个（图中仅示出一个），可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口430可以包括进行有线和/或无线通信的接口。

在存储器420中可以存储一个或多个计算机程序指令，处理器410可以读取并运行这些计算机程序指令，以实现本申请实施例提供的权限管理方法以及其他期望的功能。

可以理解，图4所示的结构仅为示意，电子设备400还可以包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。电子设备400可能是实体设备，例如pc机、笔记本电脑、平板电脑、手机、服务器、嵌入式设备等，也可能是虚拟设备，例如虚拟机、虚拟化容器等。并且，电子设备400也不限于单台设备，也可以是多台设备的组合或者大量设备构成的一个或多个集群。例如，在本申请实施例中，区块链集群、支付系统、权限系统、财务系统、作业系统中的节点均可采用电子设备400的结构，并且这些集群或系统从整体上也可以视为采用了采用电子设备400的结构。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的权限管理方法。例如，计算机可读存储介质可以实现为图4中电子设备400中的存储器420。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。