基于智能合约的养老金处理方法、装置、设备和存储介质

本申请涉及养老保障技术领域，尤其涉及一种基于智能合约的养老金处理方法、装置、设备和存储介质。

目前，养老金运行模式为养老金三支柱运行模式。三支柱包括：第一支柱、第二支柱和第三支柱；第一支柱是基本养老保险，第二支柱是企业年金和职业年金，第三支柱包括个人储蓄性养老保险和商业养老保险。不同支柱账户管理情况不同，第一支柱的养老金账户由社保机构直接管理，第二支柱中职业年金账号由社保机构作为账户管理人管理，企业年金账户则由具有账户管理人资格的管理机构管理，第三支柱的养老金账户目前由经办机构管理。

现有技术中，当用户需要在第二支柱间进行账户关系转移时，需要由用户或者企业提出申请，管理机构之间通过邮件或者socket+sftp交互等方式，才能实现账户关系转移。

然而，上述账户关系转移的方法，存在过程繁琐，耗时长，用户体验较差等缺陷。

本申请提供一种基于智能合约的养老金处理方法、装置、设备和存储介质，用以解决现有账户关系转移的方法存在的过程繁琐，耗时长，用户体验较差等缺陷。

一方面，本申请提供一种基于智能合约的养老金处理方法，包括：

背书节点接收普通节点发送的开户申请，所述开户申请包括账管机构的信息、用户的信息；

所述背书节点基于第一智能合约对所述用户的信息进行信息校验，在校验通过后，根据所述账管机构的信息获取养老金账户类型；

所述背书节点根据第二智能合约对所述养老金账户类型进行开通账户校验，并在校验通过后，开通新的养老金账户，并保存所述用户、所述账管机构与所述新的养老金账户的关联关系。

可选的，所述背书节点根据第二智能合约对所述养老金账户类型进行开通账户校验，包括：

所述背书节点判断所述养老金账户类型为第三支柱养老金时，根据养老金账户数据库获取所述用户的第三支柱养老金的账户数量；

若所述账户数量小于预设数量，则所述背书节点确定开通账户校验通过。

可选的，所述背书节点根据第二智能合约对所述养老金账户类型进行开通账户校验，包括：

所述背书节点判断所述养老金账户类型非第三支柱养老金时，根据养老金账户数据库判断所述用户是否存在目标养老金账户，所述目标养老金账户为第一支柱养老金账户或第二支柱养老金账户；

若不存在目标养老金账户，则所述背书节点确定开通账户校验通过。

可选的，若存在第一支柱养老金账户，则所述背书节点确定开通账户校验不通过；

若存在第二支柱养老金账户，且所述第二支柱养老金账户的状态为当前不可用，则所述背书节点确定开通账户校验通过。

可选的，所述开通新的养老金账户之后，所述方法还包括：

所述背书节点接收普通节点发送的养老金账户的状态修改请求，所述状态修改请求包括目标状态和用户账户信息；

所述背书节点根据第三智能合约对所述用户账户信息进行账户校验，在校验通过后，修改所述养老金账户的状态至目标状态。

可选的，所述开通新的养老金账户之后，所述方法还包括：

所述背书节点接收普通节点发送的养老金账户的第一查询请求，所述第一查询请求包括用户账户信息；

所述背书节点根据养老金账户数据库获取缴费信息；

所述背书节点向所述普通节点发送所述第一查询响应，所述第一查询响应包括所述缴费信息。

可选的，所述开通新的养老金账户之后，所述方法还包括：

所述背书节点接收普通节点发送的养老金账户的第二查询请求，所述第二查询请求包括账管机构的信息；

所述背书节点根据养老金账户数据库获取账管机构所关联的用户的养老金账户；

所述背书节点向所述普通节点发送所述第二查询响应，所述第二查询响应包括所述账管机构所关联的用户的养老金账户。

第二方面，本申请提供一种基于智能合约的养老金处理装置，包括：

接收模块，用于接收普通节点发送的开户申请，所述开户申请包括账管机构的信息、用户的信息；

校验模块，用于基于第一智能合约对所述用户的信息进行信息校验；

获取模块，用于在信息校验通过后，根据所述账管机构的信息获取养老金账户类型；

所述校验模块，还用于根据第二智能合约对所述养老金账户类型进行开通账户校验；

处理模块，用于在开通账户校验通过后，开通新的养老金账户，并保存所述用户、所述账管机构与所述新的养老金账户的关联关系。

可选的，所述校验模块，具体用于判断所述养老金账户类型为第三支柱养老金时，根据养老金账户数据库获取所述用户的第三支柱养老金的账户数量；

若所述账户数量小于预设数量，则确定开通账户校验通过。

可选的，所述校验模块，具体还用于在判断所述养老金账户类型非第三支柱养老金时，根据养老金账户数据库判断所述用户是否存在目标养老金账户，所述目标养老金账户为第一支柱养老金账户或第二支柱养老金账户；

若不存在目标养老金账户，则确定开通账户校验通过。

可选的，所述校验模块，具体还用于若存在第一支柱养老金账户，则确定开通账户校验不通过；

若存在第二支柱养老金账户，且所述第二支柱养老金账户的状态为当前不可用，则确定开通账户校验通过。

可选的，所述接收模块，还用于接收普通节点发送的养老金账户的状态修改请求，所述状态修改请求包括目标状态和用户账户信息；

所述校验模块，还用于根据第三智能合约对所述用户账户信息进行账户校验；

所述处理模块，还用于在账户校验通过后，修改所述养老金账户的状态至目标状态。

可选的，所述基于智能合约的养老金处理装置还包括：发送模块；

所述接收模块，还用于接收普通节点发送的养老金账户的第一查询请求，所述第一查询请求包括用户账户信息；

所述获取模块，还用于根据养老金账户数据库获取缴费信息；

所述发送模块，用于向所述普通节点发送所述第一查询响应，所述第一查询响应包括所述缴费信息。

可选的，所述接收模块，还用于接收普通节点发送的养老金账户的第二查询请求，所述第二查询请求包括账管机构的信息；

所述获取模块，还用于根据养老金账户数据库获取账管机构所关联的用户的养老金账户；

所述发送模块，还用于向所述普通节点发送所述第二查询响应，所述第二查询响应包括所述账管机构所关联的用户的养老金账户。

第三方面，本申请提供一种基于智能合约的养老金处理设备，包括：

存储器；

处理器；

其中，所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如上述第一方面及第一方面各种可能的实现方式所述的基于智能合约的养老金处理方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现如上述第一方面及第一方面各种可能的实现方式所述的基于智能合约的养老金处理方法。

本申请提供的基于智能合约的养老金处理方法，通过背书节点接收普通节点发送的开户申请；背书节点基于第一智能合约对用户的信息进行信息校验，在校验通过后，根据账管机构的信息获取养老金账户类型；背书节点根据第二智能合约对养老金账户类型进行开通账户校验，并在校验通过后，开通新的养老金账户，并保存用户、账管机构与新的养老金账户的关联关系；使得用户无需再进行账户关系转移，只需要重新开通新的养老金账号即可；同时，由于开通新的养老金账户是由背书节点来执行的，使得背书节点存储有该用户所有的养老金账户信息，从而实现了养老金的统一管理。

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请提供的基于智能合约的养老金处理方法的流程图一；

图2为本申请提供的基于智能合约的养老金处理方法的流程图二；

图3为本申请提供的基于智能合约的养老金处理方法的流程图三；

图4为本申请提供的基于智能合约的养老金处理装置的结构示意图；

图5为本申请提供的基于智能合约的养老金处理设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。

本申请实施例中，“示例性的”或者“例如”等词用于表示例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请的技术方案中所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

首先，针对本申请涉及的名词进行解释说明。

智能合约：一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。

账管人：又称账户管理人；是指受受托人委托，并根据受托人提供的计划规划规则为企业和职工建立账户、记录缴费与投资运营收益、计算待遇支付和提供信息查询等服务的专业机构。

账户关系转移：指把在原工作地交的养老保险转到新工作地。一般工作地跨省(例如上一份工作是在北京，后续换工作到了上海等情况)，或者跨制度流动(例如之前交的是城乡居民养老保险，后面交的是城镇职工养老保险等情况)，需要办理账户关系转移。

目前，养老金运行模式为养老金三支柱运行模式。三支柱包括：第一支柱、第二支柱和第三支柱。

第一支柱是公共养老金。其养老金账户由社保机构直接进行管理。也即社保机构作为账管人来直接管理第一支柱的养老金账户。

第二支柱是企业个人共同缴费的职业养老金，包括企业年金和职业年金。职业年金账号由社保机构作为账户管理人管理，企业年金账户则由具有账管人资格的管理机构进行管理。

第三支柱包括个人储蓄性养老保险和商业养老保险。例如用户自愿从养老机构购买商业养老保险等。第三支柱以个人主导，是基于个人意愿和完全积累制的个人养老储蓄计划，由个人自愿缴费。第三支柱没有尚未设置统一的账管人，目前暂时由经办机构进行管理。

账管人对受托人的养老金进行建立账户、缴费、投资收益、待遇支付以及信息查询等服务。例如：用户在公司1工作，用户的第二支柱养老金由公司1委托的账管人A进行管理。

现有技术中，当用户需要在第二支柱间进行账户关系转移，则需要由用户或者企业提出账户关系转移申请，然后由对应的账管人通过邮件或者socket+sftp交互等方式，来实现账户关系转移。

例如：当用户从北京的公司1离职，进入了上海的公司2工作时，需要进行账户关系转移。此时，用户提出账户关系转移申请，由公司2委托的账管人B通过邮件等方式与公司1委托的账管人进行沟通处理，从而实现用户的账户关系转移。

然而，上述账户关系转移的方法，存在过程繁琐，耗时长，用户体验较差等缺陷。

针对上述问题，本申请提供一种基于智能合约的养老金处理方法，通过将用户的养老金账户在区块链上管理，并通过智能合约来开通新的养老金账户，同时在背书节点对应的社保机构处保存用户、账管机构与新的养老金账户的关联关系，从而避免了现有技术中第二支柱账户关系转移的方法存在的过程繁琐，耗时长，用户体验较差等缺陷；同时，由于背书节点中存储有用户、账管机构与新的养老金账户的关联关系，从而避免了目前养老金三支柱账户管理的繁杂情况，实现了账户统一管理。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1为本申请实施例提供的基于智能合约的养老金处理方法的流程图一。如图1所示，本实施例示出的基于智能合约的养老金处理方法，包括：

S101：背书节点接收普通节点发送的开户申请，所述开户申请包括账管机构的信息和用户的信息。

其中，背书节点例如可以是社保机构在区块链上的节点，普通节点例如可以是账管机构、企事业单位等在区块链上的节点。账管机构的信息例如可以是账管机构的机构代码，用户的信息例如可以包括证件类型以及用户对应的该证件类型的证件号码。例如：证件类型为身份证，则证件号码为该用户的身份证号码。

在该步骤中，普通节点向背书节点发送开户申请，该开户申请中包括有想要开户的用户的信息，该用户对应的账管机构的信息以及想要开通的养老金账户的类型。

表1为本实施例提供的开户申请的示意表：

表1

例如：用户在公司1工作，需要开通新的养老金账户，则公司1委托的账管机构A向社保机构发送该用户的开户申请，开户申请包括该用户的基本信息、需要开通的养老金账号以及公司1委托的账管机构A的信息(机构代码)。社保机构接收该账管机构A发送的该用户的开户申请。

S102：所述背书节点基于第一智能合约对所述用户的信息进行信息校验，在校验通过后，根据所述账管机构的信息获取养老金账户类型。

其中，第一智能合约用于对用户的信息进行信息校验，其目的主要是为了确定该用户的信息是否正确。第一智能合约例如可以包括：背书节点将所述用户的信息和数据库中该用户的信息进行比对，在所述用户的信息与数据库中该用户的信息相同时，确定信息校验通过。

养老金账户类型包括：第一支柱养老金、第二支柱养老金和第三支柱养老金。在确定用户的信息正确后，可以根据账管机构的信息获取到用户需要开通的养老金账户的账户类型。

表2为本实施例提供的账管机构的信息与养老金账户类型的关系表

表2

如表2所示，每一个账管机构的信息与类型之间存在关联关系，可以根据账管机构的信息获取到对应的类型。例如：当账管机构为社保机构时，养老金账户类型为第一支柱；当账管机构为具有账管人资格的管理机构时，养老金账户类型为第二支柱；当账管机构为经办机构时，养老金账户类型为第三支柱。

再例如：根据账管机构的机构代码来确定养老金账户对应的类型。

S103：所述背书节点根据第二智能合约对所述养老金账户类型进行开通账户校验，并在校验通过后，开通新的养老金账户，并保存所述用户、所述账管机构与所述新的养老金账户的关联关系。

其中，第二智能合约用于对养老金账户类型进行验证，其主要目的是确定用户是否可以开通该养老金账户类型的账户。

可以理解的，每个用户的第一支柱养老金账户只有一个，且直接由社保机构管理；每个用户的第二支柱养老金账户可以有多个，但是用户在每一个账管机构下最多只能存在一个对应的第二支柱养老金账户，也即：用户可以拥有多个第二支柱养老金账户，但是多个第二支柱养老金账户需要由多个账管机构管理，且每个账管机构只能管理一个账户；每个用户可以开通预设数量个第三支柱养老金账户。

第二智能合约例如可以包括：若养老金账户类型为第一支柱，则背书节点确定用户当前是否具备第一支柱养老金账户；若具备，则表明用户之前开通过第一支柱养老金账户，开通账户校验不通过；若不具备，则表明用户是第一次开通第一支柱养老金账户，开通账户校验通过。

第二智能合约例如还可以包括：若养老金账户类型为第二支柱，则背书节点确定该账管机构当前是否管理有该用户的第二支柱养老金账户，若否，则表明用户在该账管机构名下不存在第二支柱养老金账户，开通账户校验通过；若是，则表明用户在该账管机构名下存在第二支柱养老金账户，开通账户校验不通过。本申请对第二智能合约的具体实现方式不做特殊限制。

当校验通过，则可以为该用户开通新的养老金账户；同时，将用户、账管机构与该新的养老金账户的关联关系保存在背书节点对应的社保机构中，以便后续开通新的养老金账户时使用。可以理解的，此处的关联关系是链下保存。也即：链上开户，链下保存，这样做的目的是为了保证用户的隐私不会泄露。

可以理解的，现有技术中，当用户更换的工作地跨省时，用户需要在第二支柱间进行账户关系转移，才能继续缴纳养老金。而采用本实施例的方法，只需要用户在新的工作单位委托的账管机构中申请一个新的第二支柱养老金即可，无需再进行账户关系转移，从而避免了对应的账管机构通过邮件或者socket+sftp交互等方式，来实现账户关系转移，解决了现有技术中存在的过程繁琐，耗时长，用户体验较差等缺陷。

可选的，在开通了新的养老金账户之后，背书节点可以在区块链中将该养老金账户的信息广播给其他节点进行记录。

本实施例提供的基于智能合约的养老金处理方法，通过背书节点接收普通节点发送的开户申请，开户申请包括账管机构的信息和用户的信息；背书节点基于第一智能合约对用户的信息进行信息校验，在校验通过后，根据账管机构的信息获取养老金账户类型；背书节点根据第二智能合约对养老金账户类型进行开通账户校验，并在校验通过后，开通新的养老金账户，并保存用户、账管机构与新的养老金账户的关联关系；使得用户无需再进行账户关系转移，只需要重新开通新的养老金账号即可；同时，由于开通新的养老金账户是由背书节点来执行的，使得背书节点存储有该用户所有的养老金账户信息，从而实现了养老金的统一管理。

图2为本申请实施例提供的基于智能合约的养老金处理方法的流程图二。如图2所示，本实施例示出的基于智能合约的养老金处理方法，包括：

S201：背书节点接收普通节点发送的开户申请，所述开户申请包括账管机构的信息和用户的信息。

S202：所述背书节点基于第一智能合约对所述用户的信息进行信息校验，在校验通过后，根据所述账管机构的信息获取养老金账户类型。

步骤S201-步骤S202与上述步骤S101-步骤S102类似，在此不再赘述。

S203：所述背书节点判断所述养老金账户类型是否为第三支柱养老金；若是，则执行步骤S204，若否，则执行步骤S205。

其中，步骤S203-步骤S209是对第二智能合约进行详细说明。在获取到养老金账户类型之后，需要判断该养老金账户类型是否为第三支柱养老金；若是，则需要确定该用户当前第三支柱养老金的账户数量，若否，则需要判断该用户是否存在第一支柱养老金账户或者第二支柱养老金账户。

S204：根据养老金账户数据库获取所述用户的第三支柱养老金的账户数量。

其中，背书节点中设置有养老金账户数据库。养老金账户数据库用于存储所有用户的养老金账户。可以理解的，由于是由背书节点来为用户开通新的养老金账户，因此背书节点在开通了新的养老金账户之后，会将用户、账管机构以及新的养老金账户的关联关系进行保存，以生成养老金账户数据库。

在养老金账户类型为第三支柱养老金时，背书节点从养老金账户数据库中查该用户当前第三支柱养老金的账户数量，然后执行步骤S206。

S205：根据养老金账户数据库判断所述用户是否存在目标养老金账户，所述目标养老金账户为第一支柱养老金账户或第二支柱养老金账户。

其中，当养老金账户类型不是第三支柱养老金时，则需要判断该用户是否存在目标养老金账户类型。

可以理解的，当养老金账户类型为第一支柱时，目标养老金账户类型也为第一支柱；当养老金账户类型为第二支柱时，目标养老金账户类型也为第二支柱。

该步骤判断是否存在目标养老金账户的目的是为了确定当前是否可以为用户开通新的养老金账户。

S206：若所述账户数量小于预设数量，则所述背书节点确定开通账户校验通过。

其中，预设数量例如可以是用户设置的，也可以是根据相关规定设置的。在背书节点从养老金账户数据库中查到该用户当前第三支柱养老金的账户数量后，确定当前账户数量是否小于预设数量，若小于，则表明用户当前还存在开通第三支柱养老金账户的名额，因此背书节点确定开通账户验证通过。

S207：若不存在目标养老金账户，则所述背书节点确定开通账户校验通过。

其中，当不存在目标养老金账户时，则表明用户还没有开通第一支柱养老金账户，或者用户还没有在该账管机构名下开通对应的第二支柱养老金账户。此时背书节点确定开通账户校验通过，用户可以开通新的养老金账户。

S208：若存在第一支柱养老金账户，则所述背书节点确定开通账户校验不通过。

其中，该步骤的前提是：养老金账户类型为第一支柱养老金。在用户想要申请的是第一支柱养老金账户时，才会去判断当前是否已经存在第一支柱养老金账户。

当存在第一支柱养老金账户，则表明用户已经开通过第一支柱养老金账户，不能开通第二个第一支柱养老金账户。因此背书节点确定开通账户校验不通过。

S209：若存在第二支柱养老金账户，且所述第二支柱养老金账户的状态为当前不可用，则所述背书节点确定开通账户校验通过。

其中，该步骤的前提是：养老金账户类型为第二支柱养老金。在用户想要申请的是第二支柱养老金账户时，才会去判断当前是否已经存在第二支柱养老金账户。

当存在第二支柱养老金账户时，此时不能直接确定校验不通过。此时还需要确定该存在的养老金账户的状态是否为当前不可用，若是，则表明用户当前不存在可以使用的第二支柱养老金账户，则背书节点确定开通账户校验通过。

养老金账户的状态包括：当前不可用和当前可用。当前不可用状态包括：保留、注销等，当前可用状态包括：正常、支付等。

可以理解的，当存在当前不可用状态的养老金账户，则表明用户从上一个单位辞职或者由于特殊原因导致养老金账户不可用。此时可以为用户新开通一个养老金账户，而无需账管机构与之前的账管机构通过邮箱沟通。

例如：用户从北京的公司1离职，进入了上海的公司2工作。此时，公司1委托的账管机构A会将用户的第二支柱养老金账户1的状态修改为保留，也即不再进行管理；公司2委托的账管机构B会向背书节点发送该用户的开户申请，为该用户开通一个新的第二支柱养老金账户2，以由账管机构B管理。

在这种情况下，背书节点查询到存在第二支柱养老金账户1，但是该第二支柱养老金账户1的状态为保留。因此背书节点确定开通账户校验通过

S210：开通新的养老金账户，并保存所述用户、所述账管机构与所述新的养老金账户的关联关系。

步骤S210与上述步骤S103类似，在此不再赘述。

本实施例提供的基于智能合约的养老金处理方法，在根据第二智能合约对养老金账户类型进行开通账户校验时，通过确定该养老金账户的类型，并分别针对不同类型采用对应的校验方法；使得用户无需再进行账户关系转移，只需要重新开通新的养老金账号即可；同时，由于开通新的养老金账户是由背书节点来执行的，使得背书节点存储有该用户所有的养老金账户信息，从而实现了养老金的统一管理。

图3为本申请实施例提供的基于智能合约的养老金处理方法的流程图三。如图3所示，本实施例是在图1实施例和图2实施例的基础上，对修改养老金账户的状态进行详细说明，本实施例示出的基于智能合约的养老金处理方法，包括

S301：背书节点接收普通节点发送的养老金账户的状态修改请求，所述状态修改请求包括目标状态和用户账户信息；

其中，养老金账户的状态包括：正常，保留，支付，注销。保留表示对应的账管机构后续不再进行管理(例如缴费等)，支付表示用户已经进入领取养老保险的阶段，由该养老金账户来支付养老金，注销表示用户已经死亡，养老金账户已经注销。

当需要对养老金账户的状态进行修改时，普通节点会向背书节点发送状态修改请求，该请求包括：用户的账户信息和目标状态。目标状态是指修改后的养老金账户的状态，用户的账户信息包括：养老金账号、类型、养老金账户对应的账管机构的信息以及养老金账户的当前状态。

表3为本实施例给出的用户账户信息的示意表

表3

S302：所述背书节点根据第三智能合约对所述用户账户信息进行账户校验，在校验通过后，修改所述养老金账户的状态至目标状态。

其中，第三智能合约用于对用户的账户进行校验，其目的是确定用户账户信息是否是否正确。第三智能合约例如可以包括：背书节点将所述用户账户信息和数据库中该用户账户信息进行比对，在所述用户账户信息与数据库中该用户账户信息相同时，确定子账户校验通过。

在校验通过后，背书节点将该养老金账户的状态修改为目标状态。

可选的，背书节点还可以在区块链中广播该养老金账户修改后的状态。

可选的，在上述图1实施例和图2实施例的基础上，在开通新的养老金账户之后，用户还可以查询自身养老金的缴纳情况，所述基于智能合约的养老金处理方法还可以包括：

背书节点接收普通节点发送的养老金账户的第一查询请求，所述第一查询请求包括用户账户信息；

所述背书节点根据养老金账户数据库获取缴费信息；

所述背书节点向所述普通节点发送所述第一查询响应，所述第一查询响应包括所述缴费信息。

其中，背书节点对应的社保机构存储有所有养老金账户的账户详细信息。

表4为本实施例提供的账户详细信息

表4

如表3所示，背书节点对应的社保机构中存储有每一个养老金账户对应的每一次缴费的情况。通过将所有养老金账户的缴费记录存储在社保机构中，可以实现对养老金账户的统一管理。

当用户想查询自己的缴费记录时，用户可以向对应的账管机构请求查询缴费记录，账管机构在区块链中，通过自身的普通节点将该用户的用户账户信息发送给背书节点。

背书节点根据养老金账户数据库可以获取到该用户对应的缴费信息，例如缴费的养老金账户、缴费时间、缴费企业以及缴费的金额等，并将该缴费信息发送给普通节点，以使用户可以方便快捷的查询到与自身关联的所有养老金账户的缴费记录。

可选的，在上述图1实施例和图2实施例的基础上，在开通新的养老金账户之后，机构还可以查询与自己关联的用户的养老金的养老金账户情况，所述基于智能合约的养老金处理方法还可以包括：

背书节点接收普通节点发送的养老金账户的第二查询请求，所述第二查询请求包括账管机构的信息；

所述背书节点根据养老金账户数据库获取账管机构所关联的用户的养老金账户；

所述背书节点向所述普通节点发送所述第二查询响应，所述第二查询响应包括所述账管机构所关联的用户的养老金账户。

其中，账管机构也可以查询与自身关联的所有用户的养老金账户，以及每个养老金账户的缴费情况。

当账管机构想要查询与自身关联的所有用户的养老金账户时，其可以在区块链上通过普通节点向背书节点发送包括有账管机构的信息的第二查询请求。

背书节点根据养老金账户数据库可以获取到与该账管机构关联的用户的养老金账户，并将该养老金账户发送给普通节点，以使账管机构可以方便快捷的查询到与自身关联的所有养老金账户。

可以理解的，用户、账管机构与新的养老金账户的关联关系只由背书节点对应的社保机构以及该账管机构在区块链下保存，不同的账管机构无法获取到同一用户在其他账管机构处的养老金账户信息。由于所有的用户、账管机构与新的养老金账户的关联关系以及所有用户的缴费信息均保存在背书节点对应的社保机构处，因此可以实现养老金账户的统一管理。同时，用户和账管机构均可以通过区块链，快速的查询到与自身关联的养老金账户，方便了用户使用，提高了查询效率。

图4为本申请提供的基于智能合约的养老金处理装置的结构示意图。

如图4所示，该基于智能合约的养老金处理装置300包括：

接收模块301，用于接收普通节点发送的开户申请，所述开户申请包括账管机构的信息、用户的信息；

校验模块302，用于基于第一智能合约对所述用户的信息进行信息校验；

获取模块303，用于在信息校验通过后，根据所述账管机构的信息获取养老金账户类型；

所述校验模块302，还用于根据第二智能合约对所述养老金账户类型进行开通账户校验；

处理模块304，用于在开通账户校验通过后，开通新的养老金账户，并保存所述用户、所述账管机构与所述新的养老金账户的关联关系。

可选的，所述校验模块302，具体用于判断所述养老金账户类型为第三支柱养老金时，根据养老金账户数据库获取所述用户的第三支柱养老金的账户数量；

若所述账户数量小于预设数量，则确定开通账户校验通过。

可选的，所述校验模块302，具体还用于在判断所述养老金账户类型非第三支柱养老金时，根据养老金账户数据库判断所述用户是否存在目标养老金账户，所述目标养老金账户为第一支柱养老金账户或第二支柱养老金账户；

若不存在目标养老金账户，则确定开通账户校验通过。

可选的，所述校验模块302，具体还用于若存在第一支柱养老金账户，则确定开通账户校验不通过；

若存在第二支柱养老金账户，且所述第二支柱养老金账户的状态为当前不可用，则确定开通账户校验通过。

可选的，所述接收模块301，还用于接收普通节点发送的养老金账户的状态修改请求，所述状态修改请求包括目标状态和用户账户信息；

所述校验模块302，还用于根据第三智能合约对所述用户账户信息进行账户校验；

所述处理模块304，还用于在账户校验通过后，修改所述养老金账户的状态至目标状态。

可选的，所述基于智能合约的养老金处理装置还包括：发送模块305；

所述接收模块301，还用于接收普通节点发送的养老金账户的第一查询请求，所述第一查询请求包括用户账户信息；

所述获取模块303，还用于根据养老金账户数据库获取缴费信息；

所述发送模块305，用于向所述普通节点发送所述第一查询响应，所述第一查询响应包括所述缴费信息。

可选的，所述接收模块301，还用于接收普通节点发送的养老金账户的第二查询请求，所述第二查询请求包括账管机构的信息；

所述获取模块303，还用于根据养老金账户数据库获取账管机构所关联的用户的养老金账户；

所述发送模块305，还用于向所述普通节点发送所述第二查询响应，所述第二查询响应包括所述账管机构所关联的用户的养老金账户。

图5为本申请提供的基于智能合约的养老金处理设备的结构示意图。如图5所示，本申请提供一种基于智能合约的养老金处理设备，该基于智能合约的养老金处理设备400包括：接收器401、发送器402、处理器403以及存储器404。

接收器401，用于接收指令和数据；

发送器402，用于发送指令和数据；

存储器404，用于存储计算机执行指令；

处理器403，用于执行存储器404存储的计算机执行指令，以实现上述实施例中基于智能合约的养老金处理方法所执行的各个步骤。具体可以参见前述基于智能合约的养老金处理方法实施例中的相关描述。

可选地，上述存储器404既可以是独立的，也可以跟处理器403集成在一起。

当存储器404独立设置时，该电子设备还包括总线，用于连接存储器404和处理器403。

本申请还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上述基于智能合约的养老金处理设备所执行的基于智能合约的养老金处理方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

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