基于区块链的资产状态处理方法与装置
技术领域
本发明涉及信息处理技术,尤其涉及一种基于区块链的资产状态处理方法与装置。
背景技术
区块链,可理解为一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。
现有的相关技术中,在利用区块链实现资产的处理时,区块链中的节点完成任一处理时,会将该处理对应的存证信息写入区块链的账本中,从而使得区块链的所有节点都认可该处理的完成。其中,区块链上所有发生的数据变更交易,都是按照时间来定序并打包加入区块的,也就是说,所有共享存证信息的变更的依赖关系,体现在时间序列上。
然而,若节点的处理不恰当,例如不符合资产处理的业务流程,或发生错误的处理,则可能会导致资产被错误处理。
发明内容
本发明提供了一种基于区块链的资产状态处理方法与装置,以解决资产被错误处理的问题。
根据本发明的第一方面,提供了一种基于区块链的资产状态处理方法,应用于节点,包括:
确定区块链的账本中资产的待变更状态;所述待变更状态用于表征所述区块链中所述资产所需变更的状态;
根据状态变迁信息,确定所述待变更状态的前序状态;所述状态变迁信息用于表征所述资产的不同状态,以及不同状态之间的序列关系;
验证所述区块链中所述资产的当前状态与所述前序状态相同;
将所述资产的当前状态变更为所述待变更状态。
可选的,所述根据状态变迁信息,确定所述待变更状态的前序状态,包括:
获取所述区块链中预设的合约信息,所述合约信息中包括所述状态变迁信息;
从所述预设的合约信息中获取所述状态变迁信息;
根据所述状态变迁信息和所述待变更状态,确定所述前序状态。
可选的,所述合约信息中的状态变迁信息包括多个子资产业务流程中每个子资产业务流程的第一状态变迁信息,所述第一状态变迁信息用于表征所述子资产业务流程中所述资产的不同状态,以及不同状态之间的序列关系;
所述根据所述状态变迁信息和所述待变更状态,确定所述前序状态,包括:
在多个子资产业务流程中,确定所述待变更状态对应的目标子资产业务流程;
若所述待变更状态非所述目标子资产业务流程的首个状态,则根据所述第一状态变迁信息和所述待变更状态,确定所述前序状态;
若所述待变更状态非所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的当前状态。
可选的,所述状态变迁信息还包括第二状态变迁信息,所述第二状态变迁信息用于表征子资产业务流程的首个状态与上一个子资产业务流程的预设状态的序列关系;
所述在多个子资产业务流程中,确定所述待变更状态对应的目标子资产业务流程之后,还包括:
若所述待变更状态为所述目标子资产业务流程的首个状态,则根据所述第二状态变迁信息和所述待变更状态,确定所述前序状态;
若所述待变更状态为所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的上一个子资产业务流程的当前状态。
可选的,所述多个子资产业务流程包括如下的至少两个业务流程:
贷款申请、质押文件上传、差额划拨、本息还款、非本息还款、回购。
可选的,所述资产状态的变化为业务从资产方向资金方流转产生的;或者,业务从资金方向资产方流转产生的。
可选的,所述验证所述区块链中所述资产的当前状态与所述前序状态相同之前,还包括:
确定区块链的账本中所述资产待写入的存证信息;
所述验证所述区块链中所述资产的当前状态与所述前序状态相同之后,还包括:
将所述存证信息写入所述账本中。
根据本发明的第二方面,提供了一种基于区块链的资产状态处理装置,包括:
待变更状态确定模块,用于确定区块链的账本中资产的待变更状态;所述待变更状态用于表征所述区块链中所述资产所需变更的状态;
前序状态确定模块,用于根据状态变迁信息,确定所述待变更状态的前序状态;所述状态变迁信息用于表征所述资产的不同状态,以及不同状态之间的序列关系;
验证模块,用于验证所述区块链中所述资产的当前状态与所述前序状态相同;
变更模块,用于将所述资产的当前状态变更为所述待变更状态。
可选的,所述前序状态确定模块,包括:
合约获取子模块,用于获取所述区块链中预设的合约信息,所述合约信息中包括所述状态变迁信息;
变迁信息获取子模块,用于从所述预设的合约信息中获取所述状态变迁信息;
前序状态确定子模块,用于根据所述状态变迁信息和所述待变更状态,确定所述前序状态。
可选的,所述合约信息中的状态变迁信息包括多个子资产业务流程中每个子资产业务流程的第一状态变迁信息,所述第一状态变迁信息用于表征所述子资产业务流程中所述资产的不同状态,以及不同状态之间的序列关系;
所述前序状态确定子模块,包括:
目标流程确定单元,用于在多个子资产业务流程中,确定所述待变更状态对应的目标子资产业务流程;
第一前序状态确定单元,用于若所述待变更状态非所述目标子资产业务流程的首个状态,则根据所述第一状态变迁信息和所述待变更状态,确定所述前序状态;
若所述待变更状态非所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的当前状态。
可选的,所述状态变迁信息还包括第二状态变迁信息,所述第二状态变迁信息用于表征子资产业务流程的首个状态与上一个子资产业务流程的预设状态的序列关系;
所述前序状态确定子模块,还包括:
第二前序状态确定单元,用于若所述待变更状态为所述目标子资产业务流程的首个状态,则根据所述第二状态变迁信息和所述待变更状态,确定所述前序状态;
若所述待变更状态为所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的上一个子资产业务流程的当前状态。
可选的,所述多个子资产业务流程包括如下的至少两个业务流程:
贷款申请、质押文件上传、差额划拨、本息还款、非本息还款、回购。
可选的,所述资产状态的变化为业务从资产方向资金方流转产生的;或者,业务从资金方向资产方流转产生的。
可选的,所述的装置,还包括:
存证信息确定模块,用于确定区块链的账本中所述资产待写入的存证信息;
写入模块,用于将所述存证信息写入所述账本中。
根据本发明的第三方面,提供了一种电子设备,包括:
处理器;以及,
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行第一方面及其可选方案涉及的基于区块链的资产状态处理方法。
根据本发明的第四方面,提供了一种存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现第一方面及其可选方案涉及的基于区块链的资产状态处理方法。
本发明提供的基于区块链的资产状态处理方法、装置,通过确定区块链的账本中资产的待变更状态,实现了利用状态对区块链中的资产处理的变化进行表征,同时,本发明通过根据状态变迁信息,确定所述待变更状态的前序状态,以及验证所述区块链中所述资产的当前状态与所述前序状态相同;实现了状态的验证,通过当前状态与前序状态的验证,可及时获悉区块链中的资产处理的变化是当前状态下所允许发生的,由于不当变化通常由节点的不当处理产生,故而,本发明可避免不当处理产生影响,保障业务处理的有序进行。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是本发明一实施例中应用场景的示意图;
图2是本发明一实施例中基于区块链的资产状态处理方法的流程示意图;
图3是本发明另一实施例中基于区块链的资产状态处理方法的流程示意图;
图4是本发明一实施例中步骤S23的流程示意图;
图5是本发明一实施例中步骤S233的流程示意图;
图6是本发明一实施例中各子资产业务流程的关系示意图;
图7是本发明一实施例中贷款申请流程中的状态流转示意图;
图8是本发明一实施例中质押文件上传流程中的状态流转示意图;
图9是本发明一实施例中差额划拨流程中的状态流转示意图;
图10是本发明一实施例中本息还款流程与非本息还款流程中的状态流转示意图一;
图11是本发明一实施例中本息还款流程与非本息还款流程中的状态流转示意图二;
图12是本发明一实施例中回购流程中的状态流转示意图;
图13是本发明一实施例中基于区块链的资产状态处理装置的结构示意图;
图14是本发明另一实施例中基于区块链的资产状态处理装置的结构示意图;
图15是本发明一实施例中前序状态确定模块的结构示意图一;
图16是本发明一实施例中前序状态确定模块的结构示意图二;
图17是本发明一实施例中电子设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例不再赘述。
图1是本发明一实施例中应用场景的示意图。
请参考图1,本发明实施例所涉及的基于区块链的资产状态处理方法与装置可应用于图1所示的区块链的网络,其中可具有节点101,其中的节点101可以为资金方的,也可以为资产方的,其可以为任意设备或设备的集合。
本发明实施例中的资产,可以为特定的借贷,例如特定额度的贷款。针对于该贷款,所对应的处理可以包含:
贷款申请流程中各节点所需实施的各个处理;
质押文件上传流程中各节点所需实施的各个处理;
本息还款流程中各节点所需实施的各个处理;
此外,还可包含:
非本息还款流程中各节点所需实施的各个处理;
差额划拨流程中各节点所需实施的各个处理;
回购流程中各节点所需实施的各个处理。
此外,实施以上处理的节点可以为借贷中的资金方与资产方。
图2是本发明一实施例中基于区块链的资产状态处理方法的流程示意图。
请参考图2,基于区块链的资产状态处理方法,可以包括:
S11:确定区块链的账本中资产的待变更状态。
待变更状态,可以理解为用于表征所述区块链中所述资产所需变更的状态;节点实施了针对资产的处理后,可使得区块链中该资产在该流程下的状态发生变化,不同的处理可对应于产生不同的变化,进而具有不同的待变更状态。
其也可理解为区块链中在子资产业务流程下最新需写入还未写入的状态,或者需实施还未实施的子资产业务流程的第一个状态。同时,子资产业务流程之间也具有序列关系。
故而,若所述待变更状态非所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的当前状态;若所述待变更状态为所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的上一个子资产业务流程的当前状态。其中,目标子资产业务流程可理解为待变更状态对应的子资产业务流程。
为了对状态进行记录,资产在该流程下的状态变更需要一个唯一的标识来进行辨识,例如资产ID;进而,所述账本中记录有资产的标识,其可理解为:通过标识的不同,可对所需变更状态的和/或所需写入信息的资产进行确定,进而,通过标识,可获悉所确定的待变更状态为该资产的待变更状态。
标识的生成可以是简单依靠随机序列而生成,也可锚定资产的相关特性,并提供一定的证明机制。例如:若标识为资产ID,其可表征为assetUid,可以包括以下几个组成部分:原始权益方签名,其可表征为signOrgcode,具备公信力的资产编号,其可表征为assetNo,资产初始状态的详细数据摘要,其可表征为assetHash。进而,标识的生成逻辑可参照以下所描述的公式来理解:
assetUid=signOrgcode+assetNo+assetHash。
其中:
权益方签名,即signOrgcode,可以理解为是对资产的发行机构,也就是原始权益机构的约定机构编码进行签名,比如:JDJR是京东金融的机构编码,对JDJR使用京东金融的私钥进行签名,以此证明JDJR的身份。
资产编号,即assetNo,可以理解为对应具备公信力的机构颁发的编号,比如京东金融的白条资产,需要对应白条的借贷合同编号,借贷合同由监管机构审计,具备一定的公信力,目的是消除资产编号的随意性。
资产初始状态的详细数据摘要,既assetHash,可以理解为使用哈希hash算法对处于原始状态的资产信息进行摘抄处理而得到的。
本实施例锚定资产原始状态数据,在源头控制资产数据的不可篡改特性。
此外,还可配置有针对不同子资产业务流程的不同流程标识。
S12:根据状态变迁信息,确定所述待变更状态的前序状态。
状态变迁信息,可理解为用于表征所述资产的不同状态,以及不同状态之间的序列关系;该序列关系,可表征状态间的先后顺序,也可同时表征状态间的依赖关系,该依赖关系可理解为状态间的条件关系或因果关系。同时,不同资产可对应于不同的状态变迁信息,也可对应于相同的状态变迁信息。
相较而言,现有技术中,区块链上所有发生的数据变更交易,都是按照时间来定序并打包加入区块的,也就是说,所有状态,以及存证信息的变更的依赖关系,仅仅体现在时间上,然而,在实际的业务处理流程中,该依赖关系是由业务流程决定的,并非由数据上链时间决定。
例如:原始权益机构将资产原始数据共享上链,之后,计划管理机构查看资产数据并将相应资产指令上链,之后,托管行查看资产指令并将资金划拨指令上链。如果上述业务流程的顺序发生变更,将不足以契合资产证券化的整体业务流程,使得区块链应用于资产证券化业务失去意义。
故而,本实施例不仅体现在时间上,还体现在了状态变迁信息中。使得区块链中记录的信息不仅体现时间,也能同时体现业务流程。
S13:验证所述区块链中所述资产的当前状态与所述前序状态相同。
其中,可利用以上所涉及的标识查询确定区块链中所述资产的当前状态,进而将步骤S12所确定的前序状态将其进行比较,若其相同,则可认为验证通过,反之,则可认为验证不通过。
若验证不通过,其后果可例如:不利用待变更状态变更当前状态,即不实施步骤S14,进而,区块链中所述资产在该流程下的状态还是原状态,区块链中的节点均可知资产的当前状态未变化,节点则不会实施后续处理。
S14:将所述资产的当前状态变更为所述待变更状态。
本实施例提供的基于区块链的资产状态处理方法,通过确定区块链的账本中资产的待变更状态,实现了利用状态对区块链中的资产处理的变化进行表征,同时,本发明通过根据状态变迁信息,确定所述待变更状态的前序状态,以及验证所述区块链中所述资产的当前状态与所述前序状态相同;实现了状态的验证,通过当前状态与前序状态的验证,可及时获悉区块链中的资产处理的变化是当前状态下所允许发生的,由于不当变化通常由节点的不当处理产生,故而,本实施例可避免不当处理产生影响。
图3是本发明另一实施例中基于区块链的资产状态处理方法的流程示意图。
请参考图3,基于区块链的资产状态处理方法,
S21:确定区块链的账本中所述资产待写入的存证信息;
存证信息,可参照区块链中存证数据、存证信息、共享存证数据、共享存证信息理解,其可对针对资产的处理和/或处理结果进行表征和记录,并同步至全区块链。
S22:确定区块链的账本中资产的待变更状态。
S23:根据状态变迁信息,确定所述待变更状态的前序状态。
步骤S22、S23的技术名词、技术特征、可选实施方式,以及技术效果,均可参照步骤S11、S12理解,对于重复的内容,在此不再累述。
图4是本发明一实施例中步骤S23的流程示意图。
请参考图4,步骤S23可以包括:
S231:获取所述区块链中预设的合约信息。
S232:从所述预设的合约信息中获取所述状态变迁信息。
合约信息,可以理解为区块链的智能合约,加入区块链的节点可依据其中的信息工作,所述合约信息中可包括所述状态变迁信息。
可见,本实施例将区块链之外的资产证券化业务的流程根据一定原则抽象成若干状态,将状态利用状态变迁信息存储在区块链的合约信息中。所有的资产相关存证交易可映射成资产在该流程下的状态变迁。
S233:根据所述状态变迁信息和所述待变更状态,确定所述前序状态。
由于状态变迁信息描述了状态之间的序列关系,待变更状态可在其中确定一个状态,根据以上序列关系,可确定所述前序状态。
图5是本发明一实施例中步骤S233的流程示意图。
所述合约信息中的状态变迁信息包括多个子资产业务流程中每个子资产业务流程的第一状态变迁信息,所述第一状态变迁信息用于表征所述子资产业务流程中所述资产的不同状态,以及不同状态之间的序列关系。
请参考图5,步骤S233可以包括:
S2331:在多个子资产业务流程中,确定所述待变更状态对应的目标子资产业务流程。
S2332:所述待变更状态是否为所述目标子资产业务流程的首个状态。
若是,则可实施步骤S2333:根据所述第一状态变迁信息和所述待变更状态,确定所述前序状态。
所述状态变迁信息还可包括第二状态变迁信息,所述第二状态变迁信息用于表征子资产业务流程的首个状态与上一个子资产业务流程的预设状态的序列关系。
故而,步骤S2332判断为否,则可实施步骤S2334:根据所述第二状态变迁信息和所述待变更状态,确定所述前序状态。
其中,在区块链中,例如可记录有贷款申请流程与质押文件上传流程的状态,对于本息还款流程,由于其与质押文件上传流程均为贷款申请流程的上一个子资产业务流程,所以,在对本息还款流程中的第一个状态确定前序状态时,其无需考虑质押文件上传流程的状态,只需考虑其上一个子资产业务流程的状态,同样的在确定对应的当前状态时,只需考虑其上一个子资产业务流程的当前状态,即贷款申请流程的当前状态,而无需考虑质押文件上传流程的状态。
故而,若待变更状态为子资产业务流程的第一个状态,则其前序状态为根据第二状态变迁信息所记载的上一个子资产业务流程的预设状态;而对应的当前状态,指的也是该上一个子资产业务流程的当前状态。
可见,本实施例针对于资产处理的各个过程,将其区分为不同的流程进行处理,从而使得流程便于管理。
S24:验证所述区块链中所述资产的当前状态与所述前序状态相同。
S25:将所述资产的当前状态变更为所述待变更状态。
步骤S24、S25的技术名词、技术特征、可选实施方式,以及技术效果,均可参照步骤S13、S14理解,对于重复的内容,在此不再累述。
S26:将所述存证信息写入所述账本中。
可见,本实施例中,对状态的验证,可以为存证信息写入的前提条件,若验证不通过,则不将存证信息写入,进而,该存证信息对应的处理与处理结果则不被同步到整个区块链。即:本实施例的存证信息不仅仅能体现出时间信息,还可体现出流程的依赖性。
其中一种实施方式中,所述多个子资产业务流程包括如下的至少两个业务流程:贷款申请、质押文件上传、差额划拨、本息还款、非本息还款、回购。通常的,贷款申请流程、质押文件上传流程,以及本息还款流程为必要流程,其他流程为可选流程。
图6是本发明一实施例中各子资产业务流程的关系示意图。
根据图6所示,在贷款申请流程之后,可分别进入本息还款流程、质押文件上传流程,以及差额划拨流程,其三者可理解为在贷款申请流程之后可并行实施的流程。本息还款流程之后,若发生例如存在罚息的情况,可实施非本息还款流程;在质押文件上传流程之后,若发生文件未被确认的情况,额可进入回购流程;在贷款申请流程之后,若发生未上传文件或未提供还款计划等情况,也可进入回购流程。
进而,贷款申请流程为质押文件上传流程、差额划拨流程,以及本息还款流程的上一个流程,本息还款流程是非本息还款流程的上一个流程,贷款申请流程、质押文件上传流程,以及本息还款流程均可作为回购流程的前序流程。
基于图6所示,图7至图12所示实施方式可对各流程中状态的流转进行具体的描述。
图7是本发明一实施例中贷款申请流程中的状态流转示意图。
以下描述中,可利用A表征资产方,B表征资金方。
请参考图7,A发出贷款申请交易后,该资产在该流程下的状态可进入贷款申请状态st11,其可表征为(LOAN_APPLY)状态。
B针对贷款申请进行贷款审核后,若审核通过,该资产在该流程下的状态可进入贷款申请通过状态st12,其可表征为(LOAN_APPROVE)状态。
若审核不通过,则该资产在该流程下的状态可进入贷款审核拒绝状态st13,其可表征为(LOAN_REJECT)状态,进而针对此贷款的状态转移结束。
审核通过后,A调用资金方申请放款,发送放款结果通知交易,该资产在该流程下的状态可进入放款结果通知状态s14,其可表征为(LOAN_RESULT_NOTIFY)状态。
最后,B判断是否确认了发送的放款结果。
若已确认并发送放款结果确认交易,该资产在该流程下的状态可进入放款结果确认状态st16,其可表征为(LOAN_RESULT_COFIRM)状态。
若未确认,则该资产在该流程下的状态可进入放款结果拒绝状态st15,其可表征为(LOAN_RESULT_REJECT)状态,需A再次发送放款结果通知交易。
可见,状态st11是状态st12与状态st13的前序状态;状态st13是状态st14的前序状态,状态st14是状态st15与状态st16的前序状态。
图8是本发明一实施例中质押文件上传流程中的状态流转示意图。
以下描述中,可利用A表征资产方,B表征资金方。
请参考图8,B确认放款结果后,A需在指定期限内上传贷款质押文件。A首先发送质押文件上传交易后,该资产在该流程下的状态可进入质押文件上传状态st21,其可表征为(MORTGAGE_DOC_UPLOAD)状态。
B判断是否确认此质押文件。若确认,资产在该流程下的状态可进入质押文件确认状态st23,其可表征为(MORTGAGE_DOC_CONFIRM)状态。若不确认,资产在该流程下的状态可进入质押文件拒绝状态,其可表征为(MORTGAGE_DOC_REJECT)状态,需A再次上传质押文件。
可见,状态st16是状态st21的前序状态,状态st21是状态st22与转台st23的前序状态。
图9是本发明一实施例中差额划拨流程中的状态流转示意图。
以下描述中,可利用A表征资产方,B表征资金方。
对于确认放款结果后的贷款,A定期对其中符合条件的贷款进行差额划拨。A发送差额划拨结果通知交易后,资产在该流程下的状态可进入差额划拨结果通知状态st31,其可表征为(DIFF_RESULT_NOTIFY)状态。而后,A判断是否确认。
若确认,则资产在该流程下的状态可进入差额划拨结果确认状态st33,其可表征为(DIFF_RESULT_CONFIRM)状态。
若未确认,则资产在该流程下的状态可进入差额划拨结果拒绝状态st32,其可表征为(DIFF_RESULT_REJECT)状态,需B再次上传差额划拨结果。
其中,状态s16为状态st31的前序状态,状态st31为状态st32与状态st33的前序状态。
图10是本发明一实施例中本息还款流程与非本息还款流程中的状态流转示意图一;图11是本发明一实施例中本息还款流程与非本息还款流程中的状态流转示意图二。
以下描述中,可利用A表征资产方,B表征资金方。
请参考图10和图11,B确认放款结果后,A需上传还款计划。A发送还款计划上传交易后,资产在该流程下的状态可进入还款计划上传状态st41,其可表征为(REPAY_PLAN_UPLOAD)状态。
之后,若B确认还款计划,资产在该流程下的状态可进入还款计划确认状态st43,其可表征为(REPAY_PLAN_CONFIRM)状态;若未确认,则可进入还款计划拒绝状态s44,其可表征为(REPAY_PLAN_REJECT)状态。
还款计划确认之后,可转入具体分期还款相关状态。
以图10所示的第一期分期还款,以及图11所示的第t期分期还款为例分别描述如下:
若当前为第一期还款,则:
A针对于第一期还款,在线上或者线下还款成功后发送第一期本息扣款结果通知交易,资产在该流程下的状态进入第一期本息扣款结果通知状态st44,其可表征为(REPAY_RESULT_NOTIFY:1)状态。其中,因第一期本息扣款结果可能分多次上传,从业务上规定,若第一期扣款结果全部上传完毕(本息还清),B可发送本息扣款结果确认交易,资产在该流程下的状态可进入第一期本息扣款结果确认状态,其可表征为
(REPAY_RESULT_CONFIRM:1)状态;否则进入第一期本息扣款结果不确认状态,其可表征为(REPAY_RESULT_UNCONFIRM:1),需A继续上传第一期本息扣款结果。本息扣款结果确认后,若本期有罚息等非本息需要还款,则进入非本息还款子流程。当且仅当第一期本息扣款结果被确认后,业务才可以开始第二期的还款流程。
若进入非本息还款子流程,则资产在该流程下的状态进入第一期非本息扣款结果通知状态st51,其可表征为(ADD_REPAY_RESULT_NOTIFY:1)状态。
若B确认此结果,资产在该流程下的状态可进入第一期非本息扣款结果确认状态st53,其可表征为(ADD_REPAY_RESULT_CONFIRM:1)状态;
若B不确认,则可进入第一期非本息还款结果拒绝状态st52,其可表征为(ADD_REPAY_RESULT_UNCONFIRM:1)状态,需A继续上传第一期非本息扣款结果。第一期非本息还款子流程只需在第一期本息还款确认之后进行,与第二期及其之后的本息还款状态、其他期非本息还款状态无顺序关系。例如,第一期非本息还款通知可在第三期本息还款确认之后进行,即其可理解为每一期非本息还款流程的前一个流程为该期本息还款流程。
若当前为第t期还款,则:
A针对于第t期还款,在线上或者线下还款成功后发送第一期本息扣款结果通知交易,资产在该流程下的状态进入第t期本息扣款结果通知状态st47,其可表征为(REPAY_RESULT_NOTIFY:t)状态。
其中,因第t期本息扣款结果可能分多次上传,从业务上规定,若第一期扣款结果全部上传完毕(本息还清),B可发送本息扣款结果确认交易,资产在该流程下的状态可进入第t期本息扣款结果确认状态,其可表征为(REPAY_RESULT_CONFIRM:t)状态;否则,进入第t期本息扣款结果不确认状态,其可表征为(REPAY_RESULT_UNCONFIRM:t),需A继续上传第t期本息扣款结果。本息扣款结果确认后,若本期有罚息等非本息需要还款,则进入非本息还款子流程。当且仅当第t期本息扣款结果被确认后,业务才可以开始第t+1期的还款流程。
若进入非本息还款子流程,则资产在该流程下的状态进入第t期非本息扣款结果通知状态st54,其可表征为(ADD_REPAY_RESULT_NOTIFY:t)状态。
若B确认此结果,资产在该流程下的状态可进入第t期非本息扣款结果确认状态st55,其可表征为(ADD_REPAY_RESULT_CONFIRM:t)状态;
若B不确认,则可进入第一期非本息还款结果拒绝状态st52,其可表征为(ADD_REPAY_RESULT_UNCONFIRM:1)状态,需A继续上传第t期非本息扣款结果。第他、期非本息还款子流程只需在第t期本息还款确认之后进行,与第t+1期及其之后的本息还款状态、其他期非本息还款状态无顺序关系。例如,第t期非本息还款通知可在第t+2期本息还款确认之后进行,即其可理解为每一期非本息还款流程的前一个流程为该期本息还款流程。
可见,状态st16为状态st41的前序状态,状态st41为状态st42与状态st43的前序状态,状态st43为状态st44的前序状态,状态st44为状态st45与状态st46的前序状态,状态st46为状态st51的前序状态,状态st51为状态st52与状态st53的前序状态,状态st47为状态st48和状态st49的前序状态,状态st49为状态st54的前序状态,状态st54为状态st55与状态st56的前序状态。
图12是本发明一实施例中回购流程中的状态流转示意图。
以下描述中,可利用A表征资产方,B表征资金方。
若A未在规定期限内上传质押文件,或代偿、逾期达到一定条件,B会发送回购申请交易,业务转向回购相关状态,即进入回购流程,进而进入回购流程中的回购申请状态st61,其可表征为(BUYBACK_APPLY)状态。
根据回购原因不同,其承接的前序状态也较为复杂,其也可理解为回购流程的上一个子资产业务流程较多,其对应的上一个子资产业务流程的特定状态也就有较多可能性。其中,上一个即状态st61的前序状态可以为:
回购申请拒绝状态st62,其可表征为(BUYBACK_REJECT)状态,其可适用的情况可例如:因回购申请被拒绝需要重新上传回购申请;
放款结果确认状态st16;
质押文件上传状态st21,其可适用的情况可例如:因质押文件未被确认;
质押文件拒绝状态st22,其可适用的情况可例如:因上传的质押文件最终被拒绝;
还款计划上传状态st41,其可适用的情况可例如:因上传的还款计划未被确认;
还款计划确认状态st43,其可适用的情况可例如:因上传还款计划后未还款;
还款计划拒绝状态st42,其可适用的情况可例如:因上传还款计划被拒绝后未修订还款计划;
第一期本息还款结果通知状态st41,其可适用的情况可例如:因第一期本息还款结果未被确认;
第一期本息还款结果确认状态st43,其可适用的情况可例如:因第一期本息还款结果确认之后未继续完成二期的还款;
第一期本息还款结果不确认状态st42,其可适用的情况可例如:因第一期本息还款结果不确认后未采取任何后续行动;
第t期本息还款结果通知状态st47,其可适用的情况可例如:因第t期本息还款结果未被确认;
第t期本息还款结果确认状态st49,其可适用的情况可例如:因第t期本息还款结果确认之后未继续完成t+1期的还款;
第t期本息还款结果不确认状态st48,其可适用的情况可例如:因第t期本息还款结果不确认后未采取任何后续行动。
回购申请后,若A确认回购申请,资产的该流程进入回购申请确认状态st63,其可表征为(BUYBACK_COMFIRM)状态;否则进入回购申请拒绝状态st62,其可表征为(BUYBACK_REJECT)状态。
若申请被确认,B发起回购扣款后,资产的该流程进入回购结果通知状态st64,其可表征为(BUYBACK_RESULT_NOTIFY)状态。若回购结果被确认,资产的该流程进入回购结果确认状态st66,其可表征为(BUYBACK_RESULT_CONFIRM)状态;否则进入回购结果拒绝状态st65,其可表征为(BUYBACK_RESULT_REJECT),需B再次上传回购结果。
本实施例提供的基于区块链的资产状态处理方法,通过确定区块链的账本中资产的待变更状态,实现了利用状态对区块链中的资产处理的变化进行表征,同时,本发明通过根据状态变迁信息,确定所述待变更状态的前序状态,以及验证所述区块链中所述资产的当前状态与所述前序状态相同;实现了状态的验证,通过当前状态与前序状态的验证,可及时获悉区块链中的资产处理的变化是当前状态下所允许发生的,由于不当变化通常由节点的不当处理产生,故而,本实施例可避免不当处理产生影响。
图13是本发明一实施例中基于区块链的资产状态处理装置的结构示意图。
请参考图13,基于区块链的资产状态处理装置3,包括:
待变更状态确定模块31,用于确定区块链的账本中资产的待变更状态;所述待变更状态用于表征所述区块链中所述资产所需变更的状态;
前序状态确定模块32,用于根据状态变迁信息,确定所述待变更状态的前序状态;所述状态变迁信息用于表征所述资产的不同状态,以及不同状态之间的序列关系;
验证模块33,用于验证所述区块链中所述资产的当前状态与所述前序状态相同;
变更模块34,用于将所述资产的当前状态变更为所述待变更状态。
本实施例提供的基于区块链的资产状态处理装置,通过确定区块链的账本中资产的待变更状态,实现了利用状态对区块链中的资产处理的变化进行表征,同时,本发明通过根据状态变迁信息,确定所述待变更状态的前序状态,以及验证所述区块链中所述资产的当前状态与所述前序状态相同;实现了状态的验证,通过当前状态与前序状态的验证,可及时获悉区块链中的资产处理的变化是当前状态下所允许发生的,由于不当变化通常由节点的不当处理产生,故而,本实施例可避免不当处理产生影响。
图14是本发明另一实施例中基于区块链的资产状态处理装置的结构示意图。
请参考图14,基于区块链的资产状态处理装置4,包括:
待变更状态确定模块42,用于确定区块链的账本中资产的待变更状态;所述待变更状态用于表征所述区块链中所述资产所需变更的状态;
前序状态确定模块43,用于根据状态变迁信息,确定所述待变更状态的前序状态;所述状态变迁信息用于表征所述资产的不同状态,以及不同状态之间的序列关系;
验证模块44,用于验证所述区块链中所述资产的当前状态与所述前序状态相同;
变更模块45,用于将所述资产的当前状态变更为所述待变更状态。
图15是本发明一实施例中前序状态确定模块的结构示意图一;图16是本发明一实施例中前序状态确定模块的结构示意图二。
请参考图15和图16,所述前序状态确定模块43,包括:
合约获取子模块431,用于获取所述区块链中预设的合约信息,所述合约信息中包括所述状态变迁信息;
变迁信息获取子模块432,用于从所述预设的合约信息中获取所述状态变迁信息;
前序状态确定子模块433,用于根据所述状态变迁信息和所述待变更状态,确定所述前序状态。
可选的,请参考图15,所述合约信息中的状态变迁信息包括多个子资产业务流程中每个子资产业务流程的第一状态变迁信息,所述第一状态变迁信息用于表征所述子资产业务流程中所述资产的不同状态,以及不同状态之间的序列关系;
所述前序状态确定子模,433,包括:
目标流程确定单元4331,用于在多个子资产业务流程中,确定所述待变更状态对应的目标子资产业务流程;
第一前序状态确定单元4332,用于若所述待变更状态非所述目标子资产业务流程的首个状态,则根据所述第一状态变迁信息和所述待变更状态,确定所述前序状态;
若所述待变更状态非所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的当前状态。
可选的,请参考图16,所述状态变迁信息还包括第二状态变迁信息,所述第二状态变迁信息用于表征子资产业务流程的首个状态与上一个子资产业务流程的预设状态的序列关系;
所述前序状态确定子模块433,还包括:
第二前序状态确定单元4332,用于若所述待变更状态为所述目标子资产业务流程的首个状态,则根据所述第二状态变迁信息和所述待变更状态,确定所述前序状态;
若所述待变更状态为所述目标子资产业务流程的首个状态,则所述当前状态为所述目标子资产业务流程的上一个子资产业务流程的当前状态。
可选的,所述多个子资产业务流程包括如下的至少两个业务流程:
贷款申请、质押文件上传、差额划拨、本息还款、非本息还款、回购。
可选的,所述资产状态的变化为业务从资产方向资金方流转产生的;或者,业务从资金方向资产方流转产生的。
可选的,所述的装置,还包括:
存证信息确定模块41,用于确定区块链的账本中所述资产待写入的存证信息;
写入模块46,用于将所述存证信息写入所述账本中。
本实施例提供的基于区块链的资产状态处理装置,通过确定区块链的账本中资产的待变更状态,实现了利用状态对区块链中的资产处理的变化进行表征,同时,本发明通过根据状态变迁信息,确定所述待变更状态的前序状态,以及验证所述区块链中所述资产的当前状态与所述前序状态相同;实现了状态的验证,通过当前状态与前序状态的验证,可及时获悉区块链中的资产处理的变化是当前状态下所允许发生的,由于不当变化通常由节点的不当处理产生,故而,本实施例可避免不当处理产生影响。
图17是本发明一实施例中电子设备的结构示意图。
请参考图17,本实施例还提供了一种电子设备50包括:处理器51以及存储器52;其中:
存储器52,用于存储计算机程序,该存储器还可以是flash(闪存)。
处理器51,用于执行存储器存储的执行指令,以实现上述方法中的各个步骤。具体可以参见前面方法实施例中的相关描述。
可选地,存储器52既可以是独立的,也可以跟处理器51集成在一起。
当所述存储器52是独立于处理器51之外的器件时,所述电子设备50还可以包括:
总线53,用于连接所述存储器52和处理器51。
本实施例还提供一种可读存储介质,可读存储介质中存储有计算机程序,当电子设备的至少一个处理器执行该计算机程序时,电子执行执行上述的各种实施方式提供的方法。
本实施例还提供一种程序产品,该程序产品包括计算机程序,该计算机程序存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该计算机程序,至少一个处理器执行该计算机程序使得电子设备实施上述的各种实施方式提供的方法。
本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。