一种基于区块链的APPID申请管理方法和系统与流程

一种基于区块链的appid申请管理方法和系统
技术领域
1.本公开涉及物联网设备管理领域，具体涉及一种基于区块链的appid管理方法和系统。


背景技术：

2.物联网设备的管理通常在后台服务器中实现，如消防应急设备的管理通常在消防大数据应用平台中实现，现有技术中需要社会平台数据对接负责人登录消防大数据应用平台，注册并完善对接申请信息，其中对接申请信息包含申请对接设备类型列表集、监测服务机构相关信息、软件平台厂商信息、项目中标方信息以及三方合作合同证明。 填写好的信息会再政务平台中流转到相关的政务运营平台对接负责人去审核相关信息，审核提交的对接信息是否通过，审核不通过则联系申请人继续完善相关申请信息，资料完善并审核通过后，进行发放电子数字证书；其中电子数字证书中包含appid、appkey、用户名、密码；数字证书通过邮件的方式发送给社会平台数据对接负责人，社会平台数据对接负责人通过电子证书将消防物联网设备的静态信息（设备厂商、设备社会运营中心等信息）、动态信息（设备故障、设备点位、设备安装位置等信息）数据进行同步。社会平台数据对接负责人将信息同步后，数据即上传至政务平台上。政务平台管理员需要对同步过来的静态、动态信息进行校验，校验通过的信息即可直接保存。
3.然而，社会平台对接负责人向“政务运营平台”提交申请信息，由于申请信息不全例如不涵盖中标合同信息，导致最终很难追踪到责任主体。政务运营平台向社会平台对接负责人发放appid，由于appid没有一个明确严格的发放条件，导致appid泛滥。社会平台对接负责人通过appid将静态、动态数据上传至政务平台，由于appid泛滥以及申请信息不全，导致数据不实同时无效数据过多的情况。


技术实现要素：

4.本公开提供一种appid管理方法和系统，能够解决背景技术中提到的问题。为解决上述技术问题，本公开提供如下技术方案：作为本公开实施例的一个方面，提供一种基于区块链的appid申请管理方法，包括如下步骤：获取appid申请信息；主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员；所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员，如果所述确认消息包个数符合要求，则执行所述appid的分配。
5.可选地，主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员具体包括如下步骤：主节点将所述appid申请信息和由区块链网络分配的appid封装为一个请求，并为
所述请求分配一个请求编号；将所述请求和请求编号封装成消息广播给所有成员。
6.可选地，所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员具体包括如下步骤：所有成员接收到所述广播后的消息；通过检查主节点的签名字段检查所述消息是否来源于主节点，在确认无误后，将成员节点的签名信息与请求编号封装成确认消息包；将所述确认消息包广播给所述区块链网络中的其他成员节点以表示所述成员节点对所述消息中的请求进行了确认。
7.可选地，在执行所述appid的分配后，还包括如下步骤：将所述申请信息和确认消息包上传到区块链网络。
8.作为本公开实施例的另一个方面，提供一种基于区块链的appid申请管理系统，包括：申请信息上传模块，获取appid申请信息；区块链网络模块，主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员；所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员，如果所述确认消息包个数符合要求，则执行所述appid的分配。
9.可选地，所述区块链网络还用于：主节点将所述appid申请信息和由区块链网络分配的appid封装为一个请求，并为所述请求分配一个请求编号；将所述请求和请求编号封装成消息广播给所有成员。
10.可选地，所述区块链网络还用于：所有成员接收到所述广播后的消息；通过检查主节点的签名字段检查所述消息是否来源于主节点，在确认无误后，将成员节点的签名信息与请求编号封装成确认消息包；将所述确认消息包广播给所述区块链网络中的其他成员节点以表示所述成员节点对所述消息中的请求进行了确认。
11.可选地，在执行所述appid的分配后，将所述申请信息和确认消息包上传到区块链网络。
12.本公开的有益效果是：通过社会平台上传的申请信息，利用区块链网络的共识机制或共识算法，区块链网络中大部分节点对申请信息进行签名确认，以appid为导向，追溯故障设备、“僵尸”设备的全链条信息数据，压实责任主体。借助区块链的去中心化，例如将上述方法、系统应用到消防应急平台的appid申请管理上，以消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络，大规模的消防设备数据经过三方共识，保证数据的监管、真实、有效、完整属性。同时，还能借助区块链的链式存储结构，将历史数据以及历史修改数据进行存储，保证数据的不可窜改以及数据的前后关联。
附图说明
13.图1为根据本公开实施例1中的appid申请管理方法的流程图。
14.图2为根据本公开实施例1中的利用区块链网络的区块链共识机制来管理appid申
请的示意流程图。
15.图3为根据本公开实施例2中的appid申请管理系统示意框图。
具体实施方式
16.以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。
17.在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。
18.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括a、b、c中的至少一种，可以表示包括从a、b和c构成的集合中选择的任意一个或多个元素。
19.另外，为了更好地说明本公开，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本公开的主旨。
20.可以理解，本公开提及的上述各个方法实施例，在不违背原理逻辑的情况下，均可以彼此相互结合形成结合后的实施例，限于篇幅，本公开不再赘述。
21.此外，本公开还提供了一种基于区块链的appid申请管理方法和系统，上述均可用来实现本公开提供的任一种appid申请管理方法，相应技术方案和描述和参见方法部分的相应记载，不再赘述。
22.一种基于区块链的appid申请管理方法中的区块链网络各个节点的执行主体可以是计算机或者其他能够实现appid申请管理方法的装置，例如，方法可以由终端设备或服务器或其它处理设备作为区块链网络中的节点来执行，其中，终端设备可以为用户设备（user equipment，ue）、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理（personal digital assistant，pda）、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该appid申请管理方法可以通过区块链网络各个节点中的处理器调用存储器中存储的计算机可读指令的方式来实现。
23.实施例1本实施例一种基于区块链的appid申请管理方法，如图1所示，包括如下步骤：s10、获取appid申请信息；s20、主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员；s30、所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员，如果所述确认消息包个数符合要求，则执行所述appid的分配。
24.在上述实施例中，所述主节点可为消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络中的任意一个节点。比如可以将消防主管部门的节点作为主节点。
25.基于上述配置本公开实施例通过社会平台上传的申请信息，利用区块链网络的共
识机制或共识算法，区块链网络中大部分节点对申请信息进行签名确认，以appid为导向，追溯故障设备、“僵尸”设备的全链条信息数据，压实责任主体。借助区块链的去中心化，例如将上述方法、系统应用到消防应急平台的appid申请管理上，以消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络，大规模的消防设备数据经过三方共识，保证数据的监管、真实、有效、完整属性。同时，还能借助区块链的链式存储结构，将历史数据以及历史修改数据进行存储，保证数据的不可窜改以及数据的前后关联。
26.下面以消防物联网设备的管理为例分别对本公开实施例的各步骤进行详细说明。如图2所示，为利用区块链网络的区块链共识机制来管理appid申请的示意流程图。
27.s10、获取appid申请信息；其中，获取appid申请信息的主体为区块链网络，通过社会平台如消防大数据应用平台，由社会平台数据对接负责人注册、完善对接appid申请信息，将上述信息上传到社会平台，然后在社会平台数据对接负责人确认好申请信息后，社会平台数据对接负责人的签名信息和appid申请信息被上传到区块链网络，也即被区块链网络所获取。所述appid申请信息包括不限于如下信息：1.申请对接设备类型集合；2.监测服务机构（营业执照、单位法人姓名、身份证号码、身份证正反面等信息）；3.软件平台厂商（营业执照、单位法人姓名、身份证号码、身份证正反面等信息）；4.项目中标方（营业执照、单位法人姓名、身份证号码、身份证正反面等信息）；5.三方合作合同证明等。
28.s20、主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员；其中，主节点把上传的appid申请信息加上由区块链网络分配的appid封装成一个请求，并分配一个请求编号，再将请求和请求编号封装成消息广播给所有成员。
29.其中，所述区块链网络为baas平台区块链网络。
30.s30、所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员，如果所述确认消息包个数符合要求，则执行所述appid的分配。
31.其中，所有成员节点收到广播后的消息，通过主节点的签名字段检查消息是否来源于主节点，确认无误后，将本成员节点的签名信息与请求编号封装成确认消息包，广播给其他所有成员节点，表示自己已对请求进行了确认；在一些实施例中，所有成员节点根据收到的确认消息包，进行签名检查，如果收到的确认消息包符合要求如超过全部节点数量的三分之二，则认为整个区块链网络认可该请求，则将该请求进行全网广播，最近开启请求的业务。
32.在一些实施例中，在分配过appid后还对appid进行可信化操作，然后社会平台对接负责人获取appid。
33.在一些实施例中，社会平台对接负责人还将获取的appid的静态、动态信息发送至社会平台进行政务数据有效性校验，在校验通过后再将appid的静态、动态信息反馈至区块链网络节点。
34.在一些实施例中，在获取appid后，消防物联网设备例如智能烟感、nb烟感、智能水箱、智能水泵等，将消防设备数据是指消防物联网设备的警报信息、维护信息、静态厂商以
及设备参数信息、故障信息上传至区块链网络。这样，借助区块链的去中心化，以消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络，大规模的消防设备数据经过三方共识，保证数据的监管、真实、有效、完整属性。同时，也借助区块链的链式存储结构，将历史数据以及历史修改数据进行存储，保证数据的不可窜改以及数据的前后关联；所述历史数据为消防物联网设备从生产到安装直至目前位置，设备的警报信息、维修信息、故障信息，包含报警位置、维修人、时间戳、故障详情等数据；历史修改数据指的是从社会平台上报过来的数据可能存在问题，需要修改后再次上传，这些修改数据的痕迹，包含什么时间修改了什么数据的对应关系。
35.在一些实施例中，还利用区块链网络中的智能合约建立基于appid的信用体系，根据消防物联网设备的上链数据情况更新信用体系数据，将信用体系数据上传到区块链网络中，进一步实现对appid的管理。
36.实施例2本实施例提供一种基于区块链的appid申请管理系统100，如图3所示，包括：申请信息上传模块1，获取appid申请信息；区块链网络模块2，主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员；所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员，如果所述确认消息包个数符合要求，则执行所述appid的分配。
37.在上述实施例中，所述区块链网络可为消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络；所述主节点为区块链网络中的任意一个节点。比如可以将消防主管部门的节点作为主节点。
38.基于上述配置本公开实施例通过社会平台上传的申请信息，利用区块链网络的共识机制或共识算法，区块链网络中大部分节点对申请信息进行签名确认，以appid为导向，追溯故障设备、“僵尸”设备的全链条信息数据，压实责任主体。借助区块链的去中心化，例如将上述方法、系统应用到消防应急平台的appid申请管理上，以消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络，大规模的消防设备数据经过三方共识，保证数据的监管、真实、有效、完整属性。同时，还能借助区块链的链式存储结构，将历史数据以及历史修改数据进行存储，保证数据的不可窜改以及数据的前后关联。
39.下面分别对本公开实施例的各个模块进行详细说明。
40.申请信息上传模块1，用于获取appid申请信息；其中，获取appid申请信息的主体为区块链网络，通过社会平台如消防大数据应用平台，由社会平台数据对接负责人注册、完善对接appid申请信息，将上述信息上传到社会平台，然后在社会平台数据对接负责人确认好申请信息后，社会平台数据对接负责人的签名信息和appid申请信息被上传到区块链网络，也即被区块链网络所获取。所述appid申请信息包括不限于如下信息：1.申请对接设备类型集合；2.监测服务机构（营业执照、单位法人姓名、身份证号码、身份证正反面等信息）；3.软件平台厂商（营业执照、单位法人姓名、身份证号码、身份证正反面等信息）；4.项目中标方（营业执照、单位法人姓名、身份证号码、身份证正反面等信息）；
5.三方合作合同证明等。
41.区块链网络模块2，主节点将所述appid申请信息和由区块链网络分配的appid封装为消息广播给区块链网络的所有成员；其中，主节点把上传的appid申请信息加上由区块链网络分配的appid封装成一个请求，并分配一个请求编号，再将请求和请求编号封装成消息广播给所有成员。
42.其中，所述区块链网络为baas平台区块链网络。
43.本实施例中，所有成员依次检查并确认了所述消息后形成的确认消息包被广播给所有成员，如果所述确认消息包个数符合要求，则执行所述appid的分配。
44.其中，所有成员节点收到广播后的消息，通过主节点的签名字段检查消息是否来源于主节点，确认无误后，将本成员节点的签名信息与请求编号封装成确认消息包，广播给其他所有成员节点，表示自己已对请求进行了确认；在一些实施例中，所有成员节点根据收到的确认消息包，进行签名检查，如果收到的确认消息包符合要求如超过全部节点数量的三分之二，则认为整个区块链网络认可该请求，则将该请求进行全网广播，最近开启请求的业务。
45.在一些实施例中，在分配过appid后还对appid进行可信化操作，然后社会平台对接负责人获取appid。
46.在一些实施例中，社会平台对接负责人还将获取的appid的静态、动态信息发送至社会平台进行政务数据有效性校验，在校验通过后再将appid的静态、动态信息反馈至区块链网络节点。
47.在一些实施例中，在获取appid后，消防物联网设备例如智能烟感、nb烟感、智能水箱、智能水泵等，将消防设备数据是指消防物联网设备的警报信息、维护信息、静态厂商以及设备参数信息、故障信息上传至区块链网络。这样，借助区块链的去中心化，以消防主管部门、消防业务部门、消防监管部门三方多节点建立区块链分布式协同网络，大规模的消防设备数据经过三方共识，保证数据的监管、真实、有效、完整属性。同时，也借助区块链的链式存储结构，将历史数据以及历史修改数据进行存储，保证数据的不可窜改以及数据的前后关联；所述历史数据为消防物联网设备从生产到安装直至目前位置，设备的警报信息、维修信息、故障信息，包含报警位置、维修人、时间戳、故障详情等数据；历史修改数据指的是从社会平台上报过来的数据可能存在问题，需要修改后再次上传，这些修改数据的痕迹，包含什么时间修改了什么数据的对应关系。
48.在一些实施例中，还利用区块链网络中的智能合约建立基于appid的信用体系，根据消防物联网设备的上链数据情况更新信用体系数据，将信用体系数据上传到区块链网络中，进一步实现对appid的管理。
49.尽管已经示出和描述了本公开的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本公开的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本公开的范围由所附权利要求及其等同物限定。