基于区块链的订单通证化、赔付、查询的方法、装置及存储
介质
技术领域
本公开的实施例总体上涉及区块链的技术领域,并且更具体地,涉及基于区块链的订单通证化、赔付、查询的方法、装置及存储介质。
背景技术
保险系统是保险公司用于开展电子化保险产品销售和管理而开发的技术系统,其提供了保险产品配置、销售(投保)、核保、理赔申请、核赔、理算、赔付、对账、审计等功能,用于满足保险公司和保险用户的业务需求及保险监管机构的监管审计需求。
就现有保险系统而言,由于保险产品条款、责任、因子等因素的差异,保险条款的组成不同,不同保险公司在其系统设计过程中使用的方式不同等因素,使得保险系统的设计非常复杂。
首先,在保险产品的保单、批改、理赔、账单的设计方面需要进行极大的冗余以兼容所有的产品。保险产品根据产品条款、费率与投保人关系不同,存在同质产品与非同质产品的差异。例如对于一些高温险、互助保险等产品,所出售的不同保单与购买人无直接关系,同一产品下销售的多份产品都是一致的,用户只根据购买的份数缴纳不同的保费和享受不同的保额,即为同质产品;而对于例如健康险、车险等产品,销售的每一份保单在与投、被保人关联后都会在保额保费、理赔等方面出现不同,每一份保单都处于不同的状态,不可替代,为非同质产品。
其次,保险产品配置结构及其复杂。通常每个产品都至少包含6至10个配置层级,涉及营销渠道配置、产品组合配置、条款配置、保险责任配置、产品因子与理赔因子配置等多类具有层级关系的元素,而结构化的系统导致无论是多复杂或者多简单的产品,都需要放弃灵活性和扩展性,根据上述结构实现。
再次,随着互联网技术发展和电商、O2O等场景出现,保险产品逐渐变得高频、海量和碎片化,保险系统需要非常复杂的底层结构支持,通过分库分表、消息中间件、流计算等技术确保系统的高可用。
最后,保险产品无法从信息技术层面提供统一的用户视图。每个保险公司都有自己的保险结构与业务接口设计,使得无论是面向保险的用户、其它保险公司和保险经纪公司、业务渠道合作方、还是保险监管机构都无法提供统一的视图和对接方式。
区块链是一种将交易按发生的时间戳进行排序并首尾相连的链式数据结构,其不是一种单一构成的技术,而是由分布式账本、密码学、共识机制和智能合约等技术共同组成的。区块链通过点对点网络和共识算法,以去信任的方式集体维护一个可靠的分布式数据库,提供了去中心化、不可篡改等特性。
智能合约是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。
发明内容
根据以上内容,现有的保险系统存在以下问题。
1、对用户端而言无法提供统一的保险资产存管服务。这是因为不同保险公司的保险系统具有不同的产品结构、业务接口设计与接入要求,难以提供一个统一的应用将用户在各个保险公司购买的产品进行聚合提供统一的服务。
2、现有的保险系统对用户理赔透明度低,业务过程对用户是一个封闭的黑盒,用户无法了解具体的理赔过程和一系列问题出现的原因,而保险条款又极其复杂与难以理解,使得用户普遍对保险公司缺乏信任感。
3、无法提供细粒度的隐私保护功能和数据流转。用户数据以结构化方式存储于关系型数据库的数据表中,无法提供细粒度隐私保护与数据流转功能,全靠业务代码和人工措施进行。
4、保险产品代码结构复杂并大量冗余,需要复杂的架构体系支撑,配置和维护成本高。一方面,为了保证保险产品在代码结构上的一致性与完整性和整体架构设计的通用性,必须将保险产品结构设计得大而全,并且具备复杂的层级结构。造成新产品在开发的时候必须安全全量的结构进行设计与配置;另一方面,为了系统能支撑每天百万计的业务请求,需要通过一系列中间件技术确保业务系统的高可用。上述两方面都需要花费巨大的研发投入、人员成本和时间成本。
5、无法从信息技术层面提升监管效果:在现有技术框架下,保险监管主要通过收集上报数据,清洗过滤并进行分析的方式进行业务监管。由于采取的是事后监管的方式,因此过程中会导致保险业务数据的完整性和真实性无法得到保障,业务违规问题无法及时发现。
本公开的实施例提供了一种基于区块链的订单通证化、赔付、查询的方法、装置及存储介质。
本公开的第一实施例提出了一种基于区块链的订单通证化的方法,包括:在所述区块链的第一节点处,接收订单生成请求,所述订单生成请求包括订单分类标识数据,其中,所述区块链中存储有与所述订单分类标识数据相对应的智能合约;在所述第一节点处,基于所述订单生成请求生成订单数据;以及由所述第一节点向所述区块链的多个第二节点发送所述订单数据的至少部分,以在所述区块链中基于所述对应的智能合约创建通证,所述通证包括所述订单的概况信息。
在该实施例中,可以将各种类型的产品提前以智能合约的形式部署在区块链中,订单的生成可以由代码自动执行,提升了透明度和可信任度。并且,将所生成的订单在区块链中通证化,从而能够在同业或上下游企业合作过程中以安全、可信的方式基于通证进行数据的授权、流通、开放计算,以此提升风控能力、自动化能力。而通证作为用户权益和资产的载体,使得用户能够对与加入区块链的节点相关的所有订单进行统一管理,获得统一的服务,加强用户体验。另外,基于区块链的系统降低了系统单点故障等问题引发的不可用风险。此外,还能够使得监管机构对订单的生成进行实时监控,使得面向结果的监管转变成面向过程,提升监管范围和力度和数据信任度。
本公开的第二实施例提出了一种基于区块链的订单赔付方法,包括:在所述区块链的第一节点处,获得订单赔付请求,所述订单赔付请求包括与待赔付订单相对应的通证;在所述第一节点处,基于所述订单赔付请求生成赔付数据;以及由所述第一节点向所述多个第二节点发送所述赔付数据的至少部分,以获得赔付结果,所述赔付结果用于更新存储在所述区块链中的所述对应的通证的状态。
在该实施例中,在订单通证化的基础上,通过在区块链中进行订单的赔付和/或记录赔付结果,能够提升整个订单赔付过程的透明度和可信任度。
本公开的第三实施例提出了一种基于区块链的订单查询方法,包括:在所述区块链的第一节点处,获得订单查询请求;在所述第一节点处,基于所述订单查询请求中的查询条件获得与待查询订单相对应的智能合约在所述区块链中的地址;以及在所述第一节点处,根据所述智能合约的地址获得所述待查询订单的订单数据的至少部分。
在该实施例中,在订单通证化的基础上,能够在同业或上下游企业合作过程中以安全、可信的方式基于通证进行数据的授权、流通、开放计算,以此提升风控能力、自动化能力。
本公开的第四实施例提出了一种基于区块链的订单通证化的装置,所述装置包括:处理器;以及存储器,其用于存储指令,当所述指令被执行时使得所述处理器执行以下操作:在所述区块链的第一节点处,接收订单生成请求,所述订单生成请求包括订单分类标识数据,其中,所述区块链中存储有与所述订单分类标识数据相对应的智能合约;在所述第一节点处,基于所述订单生成请求生成订单数据;以及由所述第一节点向所述区块链的多个第二节点发送所述订单数据的至少部分,以在所述区块链中基于所述对应的智能合约创建通证,所述通证包括所述订单的概况信息。
本公开的第五实施例提出了一种基于区块链的订单赔付装置,所述装置包括:处理器;以及存储器,其用于存储指令,当所述指令被执行时使得所述处理器执行以下操作:在所述区块链的第一节点处,获得订单赔付请求,所述订单赔付请求包括与待赔付订单相对应的通证;在所述第一节点处,基于所述订单赔付请求生成赔付数据;以及由所述第一节点向所述多个第二节点发送所述赔付数据的至少部分,以获得赔付结果,所述赔付结果用于更新存储在所述区块链中的所述对应的通证的状态。
本公开的第六实施例提出了一种基于区块链的订单查询装置,包括:处理器;以及存储器,其用于存储指令,当所述指令被执行时使得所述处理器执行以下操作:在所述区块链的第一节点处,获得订单查询请求;在所述第一节点处,基于所述订单查询请求中的查询条件获得与待查询订单相对应的智能合约在所述区块链中的地址;以及在所述第一节点处,根据所述智能合约的地址获得所述待查询订单的订单数据的至少部分。
本公开的第七实施例提出了一种计算机可读存储介质,其具有存储在其上的计算机可读程序指令,所述计算机可读程序指令用于执行根据第一实施例的基于区块链的订单通证化的方法。
本公开的第八实施例提出了一种计算机可读存储介质,其具有存储在其上的计算机可读程序指令,所述计算机可读程序指令用于执行根据第二实施例的基于区块链的订单赔付方法。
本公开的第九实施例提出了一种计算机可读存储介质,其具有存储在其上的计算机可读程序指令,所述计算机可读程序指令用于执行根据第三实施例的基于区块链的订单查询方法。
附图说明
结合附图并参考以下详细说明,本公开的各实施例的特征、优点及其它方面将变得更加明显,在此以示例性而非限制性的方式示出了本公开的若干实施例,在附图中:
图1示出了根据本公开的一个实施例的基于区块链的保险系统的架构示意图;
图2示出了根据本公开的一个实施例的基于区块链的订单通证化的方法的流程图;
图3示出了根据本公开的一个实施例的基于区块链的订单赔付方法的流程图;
图4示出了根据本公开的一个实施例的基于区块链的订单查询方法的流程图;以及
图5示出了根据本公开的一个实施例的基于区块链的订单通证化的装置的示意图。
具体实施方式
以下参考附图详细描述本公开的各个示例性实施例。虽然以下所描述的示例性方法、装置包括在其它组件当中的硬件上执行的软件和/或固件,但是应当注意,这些示例仅仅是说明性的,而不应看作是限制性的。例如,考虑在硬件中独占地、在软件中独占地、或在硬件和软件的任何组合中可以实施任何或所有硬件、软件和固件组件。因此,虽然以下已经描述了示例性的方法和装置,但是本领域的技术人员应容易理解,所提供的示例并不用于限制用于实现这些方法和装置的方式。
此外,附图中的流程图和框图示出了根据本公开的各个实施例的方法和系统的可能实现的体系架构、功能和操作。应当注意,方框中所标注的功能也可以按照不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,或者它们有时也可以按照相反的顺序执行,这取决于所涉及的功能。同样应当注意的是,流程图和/或框图中的每个方框、以及流程图和/或框图中的方框的组合,可以使用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以使用专用硬件与计算机指令的组合来实现。
本文所使用的术语“包括”、“包含”及类似术语是开放性的术语,即“包括/包含但不限于”,表示还可以包括其它内容。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”;术语“另一实施例”表示“至少一个另外的实施例”等等。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论,但在适当情况下,所述技术、方法和设备应当视为说明书的一部分。对于附图中的各单元之间的连线,仅仅是为了便于说明,其表示至少连线两端的单元是相互通信的,并非旨在限制未连线的单元之间无法通信。
为了便于描述,下面对本公开中出现的一些术语进行说明,应当理解,本公开所使用的术语应解释为具有与其在本公开的说明书的上下文及有关领域中的意义一致的意义。
本公开中的术语“多个”是指两个或两个以上。
本公开中的术语“订单”是指由至少两方对于购买或交换某项服务或物品而达成的一个或多个约定。
本公开中的术语“通证”是指在区块链中以数字形式存在的权益证明。
下面以根据本公开的一个实施例的保险系统为例进行详细描述。图1示出了根据本公开的一个实施例的基于区块链的保险系统100的架构示意图。在图1所示出的实施例中,保险系统100包括经由网络通信连接的节点101、102、103、104、105、106、107和108,其中,网络可以是互联网、局域网、广域网等任何形式的网络,连接可以是无线连接、有线连接等任何形式的连接方式。在图1的实施例中,仅示出了8个节点101、102、103、104、105、106、107和108,然而这仅仅是示例性的。在一些实施例中,该保险系统100可以包括任意数量的节点。
在图1的实施例中,节点101、102、103、104、105、106、107和108构成一个基于区块链协议的系统。在一个实施例中,节点可以包括保险公司、保险公司的上下游企业、保险经纪公司、业务渠道合作企业、保险监管机构等。
如图1中可以看到的,安装有服务器端软件的节点101(例如,保险公司A)经由网络与安装有客户端软件的用户设备110和111通信连接,其中,网络可以是互联网、局域网、广域网等任何形式的网络,连接可以是无线连接、有线连接等任何形式的连接方式。为了简洁起见,图1中仅示出了节点101与两个用户设备110和111通信连接,但是在另一些实施例中,节点101可以与任意数量的用户设备通信连接。类似地,尽管图1中未示出与节点102通信连接的用户设备,但是节点102也可以与任意数量的用户设备通信连接。在图1的实施例中,用户经由用户设备110和111向节点101请求生成保险订单、向节点101申请订单理赔、并向节点101请求查询保险订单。
在图1所示的保险系统100中,保险产品合约IPC(Insurance-Product Contract)是一个智能合约,其除了提供了完善的生命周期管理和状态跟踪等功能的实现,还包含了保险产品对应的一些必要业务逻辑。每一个保险产品合约实例即对应了一款由保险公司研发的保险产品。也就是说,在图1的实施例中,将传统的保险产品合约通过区块链中的智能合约的方式来体现。
如上文中提及的,保险产品的条款与组成有较大不同,例如,保险产品存在同质与非同质的区别,并且包含多层配置。在一些实施例中,定义了一系列保险资产通证化标准协议IATS(Insurance-Asset Token Standard)。它是对于保险系统100中的保险产品通证的一组标准化接口,该协议允许保险公司以智能合约的形式实现一个标准的保险产品通证的应用程序编程接口API(Application Programming Interface),其提供了对保险产品的从投保到协议终止的全生命周期管理和状态追踪等基础功能。定义保险资产通证化标准协议能够避免保险产品相应的代码化的智能合约的逻辑复杂、扩展性差,并且降低了部署和交易成本,而且,使用统一的合约结构和接口规范,使得更易于对整个保险系统100中的保险资产进行管理。然而,在一些实施例中,也可以不定义这样的系列标准协议,每个保险公司都可以自己定义与保险产品相对应的智能合约,并部署在区块链中。
具体来说,在一些实施例中,所定义的保险资产通证化标准协议具有四大类的协议,包括:1)非同质保险产品通证标准,其适用于表示每份保单都是独一无二的产品,或根据营销渠道具有不同渠道佣金等因子的情况的产品;2)同质保险产品通证标准,其适用于产品属性一致,与投、被保人差异无关的产品;3)组合保险产品通证标准,其包括一个同质保险产品通证与一到多个同质保险产品通证的组合、一个非同质保险产品通证与一到多个非同质保险产品通证的组合、一个同质保险产品通证或非同质保险产品通证与一到多个同质保险产品通证与非同质保险产品通证的组合这几种类型。其适用于较为复杂和大额的保险产品;4)混合保险产品通证标准,其适用于更为复杂的组合(例如,组合不同的渠道、不同的投保人、被保人等)保险产品。
下面以节点101为保险公司A、节点102为保险公司B、节点103为保险监管机构为例,参照图1详细说明在保险系统中创建表示保险订单的通证、针对某一保险订单申请赔付、查询保险订单的详细流程。
当节点101(即保险公司A)和节点102(保险公司B)加入区块链中后,首先,节点101和102分别在区块链中部署与保险产品相对应的智能合约。部署智能合约的过程需要区块链中的各节点进行共识,并且在通过共识后,存储在区块链中的每一节点处。在该区块链中,可以使用任何适当的共识机制来进行共识。在图1的实施例中,可以在共识机制中规定某个或某些节点对共识结果具有比其它节点更高的影响因子。例如,作为监管机构的节点103可以具有“一票否决”的权利,当待部署的智能合约被广播到节点103时,其可以根据预先设定的监管规则,对智能合约中的条款进行监控,当发现违规的智能合约时,可以阻止共识通过,从而该智能合约不能被部署在区块链中,即,其可以阻止违规保险产品的发布。
在图1的实施例中,智能合约在区块链中所定义的保险资产通证化标准协议的基础上实现。每次节点101或102成功部署一个新的智能合约,区块链就相应地为该智能合约分配一个地址。例如,为保险公司A的保险产品a1分配的地址为Addr1,为保险公司A的保险产品a2分配的地址为Addr2,为保险公司B的保险产品b1分配的地址为Addr3……,等等。可以根据任意的规则来实现地址的分配,只要每个智能合约的地址都是唯一的即可。同时,每个智能合约还被设置一个状态标记(例如,有效或无效)。在部署智能合约后,将该智能合约的状态标记设为有效。如果该智能合约对应的保险产品目前正在销售,则保持该状态标记为有效;反之,如果该智能合约对应的保险产品停止销售,那么就将该智能合约的状态标记更改为无效。这样能够便于对智能合约进行统一管理,并且方便查询某一智能合约或查看其状态。
在图1的实施例中,在区块链的每个节点的本地存储器中还建立两个相同的索引表:保险公司-智能合约索引表,以及保险产品分类-智能合约索引表,以便于将来的查询操作。保险公司-智能合约索引表例如包括一系列一一对应的数据:0x14be-0x21fe,0x14be-0x12ba,0x2ebb-0x7cef,……,其中,0x14be和0x2ebb分别表示保险公司的标识信息(例如,保险公司的ID),0x21fe、0x12ba和0x7cef分别表示智能合约在区块链中的地址。保险产品分类-智能合约索引表例如包括一系列一一对应的数据:航延险-0x21fe,航延险-0x7cef,健康险-0x12ba,……,其中,航延险和健康险表示保险产品的分类,0x21fe、0x7cef和0x12ba分别表示智能合约在区块链中的地址。这两个索引表包括区块链中所有智能合约的地址。每当一个新的智能合约被部署在区块链中时,这两个索引表都会进行更新,以将新的智能合约的信息包括在其中。此外,在区块链的每个节点的本地存储器中还建立节点保险产品分类-智能合约索引表,其仅包括每个节点自己发布的智能合约的地址。例如,每次节点101成功部署一个新的智能合约,用户设备110和111的客户端和节点101的服务器端就更新与智能合约相对应的保险产品,并且更新节点保险产品分类-智能合约索引表。
在图1的实施例中,节点101上的服务器端与用户设备110和111上的客户端进行交互。用户可以在客户端上进行注册,以获得账户(例如,用户ID)。接下来参照图1详细说明用户经由用户设备110的投保过程。首先,用户在用户设备110的客户端上选择保险产品并输入所选择的保险产品所需的相关信息,例如,投保人和被保人的个人身份信息、航班信息(例如选择航空延误险)、车辆信息(例如选择车险)等等。在一些实施例中,用户可以通过人机对话机器人来进行这样的选择和信息输入。人机对话机器人作为客户端的载体,用户通过与机器人对话来请求购买保险产品。机器人通过自然语言处理技术,根据用户的语音输入来解析要购买的保险产品。在另一些实施例中,还可以通过其它外部系统调用机器人的API,来使得机器人获得用户的投保请求。或者,在另一些实施例中,用户还可以手动选择保险产品并输入信息。
在客户端获得需要购买的保险产品及相关信息之后,其向节点101发送订单生成请求。在图1的实施例中,订单生成请求包括用户标识信息(例如,用户ID)、指示待生成的保险订单所属的保险产品的订单分类标识数据、以及该保险产品需要的相关信息。节点101接收订单生成请求,并确认该保险产品的状态。具体来说,节点101通过节点保险产品分类-智能合约索引表获得与所请求的保险产品对应的智能合约地址,并查看存储在区块链中的该智能合约的状态。如果该智能合约的状态为无效,表示所请求的保险产品已经停售,则向客户端返回无法生成保险订单的消息。在图1的实施例中,节点101查看存储在其处的该智能合约的状态,然而在另一些实施例中,也可以经由区块链中的任一个节点来进行这样的查看操作,并向节点101返回智能合约的状态。
在图1的实施例中,在确认与所请求的保险产品对应的智能合约为有效的状态下,判断订单生成请求是否满足预定的订单生成条件,也就是说,对订单生成请求进行初步核保。例如,在所请求的保险产品为健康险的情况下,可以初步判断订单生成请求中的投保人的年龄性别等身份信息和既往病史是否符合预定的投保要求。这是因为如果核保的操作全部在区块链中进行,则区块链中的每个节点处的智能合约都需要执行完整的核保操作,这样会加重整个区块链网络的负担。而将大部分核保操作提前在节点101处本地执行可以有效地减少智能合约中的运行逻辑。然而,在另一些实施例中,也可以省略这样的步骤,即,可以将核保的操作全部在区块链中的智能合约中执行。或者,在另一些实施例中,也可以将所有核保的操作都在节点101处执行。
接下来,在节点101处,基于订单生成请求生成订单数据。如果在节点101处未通过初步核保,则向客户端返回未通过核保的消息,并将订单生成请求和核保结果作为订单数据存储在本地存储器中。否则,接下来,在节点101处,生成初始订单,并基于预定的存储规则生成订单数据,所述订单数据包括第一数据集合和第二数据集合。在图1的实施例中,第一数据集合包括订单的全部业务数据,第二数据集合包括用户标识信息(例如,用户ID等)和订单的至少部分业务数据。将第一数据集合的至少部分基于预定的加解密规则进行加密之后存储在节点101的本地存储器中,而将第二数据集合的至少部分基于预定的加解密规则进行加密之后连同表示第一数据集合在节点101的本地存储器中的地址的地址标识信息发送给区块链中的其它节点,以在区块链中执行另外一部分核保操作,并将用户标识信息和表示第一数据集合在节点101的本地存储器中的地址的地址标识信息存储在区块链中,这样能够有效地减少区块链中数据的存储量。存储在区块链和节点101的本地存储器中的具体内容将在下文中详细说明。
然而,在另一些实施例中,预定的存储规则可以是任意设定的规则,并不限于以上实施例中所提出的存储规则,因此,第一数据集合和第二数据集合可以包括与订单有关的任何其它数据。此外,在另一些实施例中,还可以基于保险公司和保险产品的不同而设置不同的存储规则。此外,在核保操作全部在区块链中执行的实施例中,将订单生成请求作为订单数据,并且在本地存储器中不存储任何订单数据,而是将所有订单数据都发送给区块链中的其它节点,以在区块链中执行核保操作。
当区块链中的其它节点接收到来自节点101的第二数据集合和表示第一数据集合在节点101的本地存储器中的地址的地址标识信息之后,在每个节点处,根据与所请求的保险产品对应的智能合约和接收到的第二数据集合,判断是否能够生成保险订单,即,通过智能合约进行另一部分的核保。核保的过程也经过区块链中的各节点的共识。区块链的某个或某些节点对于共识的结果具有比其它节点更高的影响因子。例如,作为监管机构的节点103可以具有“一票否决”的权利,当发现订单数据中的业务数据违规时,其可以根据预先设定的监管规则实时发出告警,并阻止该订单交易信息被打包到区块中,从而可以在订单生成过程中进行实时监管。
在一些实施例中,核保的过程可以包括由区块链的各节点调用中间件(例如,预言机)向外部系统发送核查信息的请求并接收外部系统的核查结果。例如,在所请求的保险产品为航空延误险的情况下,可以通过预言机向外部应用(例如,航空公司应用)发送核查机票的请求,而外部应用在进行核查后,向区块链的各节点发送核查结果,即,机票确认的结果。
如果未通过在区块链中的核保,则由节点101向用户设备110的客户端返回保险订单未生成的消息。否则,由区块链的各节点基于智能合约和第二数据集合生成相对应的通证,并为该通证分配唯一标识信息(例如,通证ID)。所生成的通证可以包括保险订单的概况信息,例如,保险公司、保险产品、投保人、被保人、保费、保额等。可以使用任何规则来生成通证的标识信息,只要使得对于同一节点和同一智能合约,所创建的通证都具有彼此不同的标识信息即可。
在创建通证之后,由区块链的各节点在相应的智能合约的地址处,存储与该通证对应的用户标识信息(例如,用户ID)、通证标识信息(例如,通证ID)、通证创建时间、通证状态、以及表示第一数据集合(包括通证所表示的订单的全部业务数据)在节点101的本地存储器中的地址的地址标识信息。通证状态表示当前通证的最新状态,状态例如包括:赔后终止(totalLoss)、核保通过(issued)、期满终止(uneffective)等等。对于新创建的通证,状态为核保通过(issued)。例如,在众安-航延Addr:0x7CEF这一智能合约地址处,存储这样的一组数据:通证:0xbe1f,用户:0x8211,日期:20180816,状态:issued,地址标识信息:0x61。
此外,在区块链的每个节点处,还更新与用户标识信息(例如,用户ID)对应的通证列表,该通证列表表示每个用户所拥有的所有通证,每个节点都将新创建的通证及该通证对应的智能合约地址加入对应用户的通证列表中。之后,由节点101向用户设备110返回所创建的通证,当用户设备110接收到通证之后,更新当前用户所持有的通证信息。
如上面提及的,在另一些实施例中,也可以将所有核保的操作都在节点101处完成,在这样的实施例中,只需要在区块链中根据第二数据集合创建通证,而不再需要核保。
在另一些实施例中,可以将核保的操作全部在区块链中的智能合约中进行。在这样的实施例中,不需要在节点101处生成订单,并且将订单生成请求作为订单数据,并发送给区块链中的其它节点,从而在区块链中完成全部核保操作并生成订单,将订单的全部业务数据存储在区块链中。因而,在节点101的本地存储器中不保存业务数据。
在另一些实施例中,可以在预定的存储规则中预先设定使第一数据集合和第二数据集合分别包括订单的业务数据的一部分,并将第一数据集合存储在本地存储器中,将第二数据集合存储在区块链中。
以上内容详细描述了用户经由用户设备110向节点101投保某一保险产品的过程。类似地,另一用户也可以经由用户设备111向节点101投保特定的保险产品。在区块链中的每个智能合约处,针对每个通证分别存储通证相关信息,包括但不限于用户标识信息(例如,用户ID)、通证标识信息(例如,通证ID)、通证生成时间、通证状态、以及表示第一数据集合在节点101的本地存储器中的地址的地址标识信息。
在图1的实施例中,将用户在保险系统100中所购买的保险产品转换为一串基于保险资产通证化标准的可编程的代码,因而,保险产品的投保、保险订单的理赔等一系列状态的转变都可以通过提前制定规则,由代码自动执行,提升了产品的透明度和可信任度。此外,保险资产通证化标准和区块链技术使得可以通过与密码学技术、预言机的结合,在同业或者上下游企业合作过程中以安全、可信的方式基于保险资产通证进行数据的授权、流通、开放计算,以此提升风控能力,自动化能力。如同业的累积风险保额,跨行业的商保直赔等。
而且,所有保险产品都基于一致的保险资产通证化协议,因而具备统一的结构和接口规范,使得可以进行保险资产的统一存管。保险上下游企业能够基于通证的数据流通对接来提升保险投保、理赔的自动化程度,加强用户体验。利用区块链构建保险系统也降低了系统单点故障等问题引发的不可用风险。
再者,监管机构可以实时地对保险业务进行实时的监控。通过对监管机构权限和保险产品的智能合约的设定,监管机构可以非常容易地实现对业务的实时自动告警设定和叫停机制,从面向结果转变成面向过程,提升监管范围和力度。而通过区块链实现保险核心业务,使得监管机构无需担心数据的真实性,也大大降低了信任成本。
下面将参照图1描述用户经由用户设备110向节点101发起赔付请求的过程。首先,用户在用户设备110的客户端上向节点101发起赔付请求。在一些实施例中,使用人机对话机器人作为客户端的载体,因此,可以由用户通过与机器人对话来选择某一通证发起赔付请。或者,在另一些实施例中,机器人还可以主动学习通证信息,并调用中间件(例如预言机),从而当符合赔付条件的事件发生时自动发起赔付请求。此外,在另一些实施例中,还可以由用户在客户端上手动地选择某一通证来发起赔付请求。替代地,在另一些实施例中,还可以由节点110自动针对某一通证发起赔付请求。
接下来,在节点101处获得订单赔付请求。在图1的实施例中,订单赔付请求包括赔付所针对的通证、用户标识信息(例如,用户ID)以及赔付所需的相关信息。然后,在节点101处,判断订单赔付请求是否满足预定的订单赔付条件,也就是说,对订单赔付请求进行初步核赔。例如,在所请求赔付的保险产品为健康险的情况下,可以初步判断订单赔付请求中的投保人的年龄性别等身份信息和赔付所需的就医信息是否符合预定的订单赔付条件。与投保过程类似,可以将大部分核赔的操作在节点101处本地执行,从而能够减少区块链的智能合约中的运行逻辑。在另一些实施例中,也可以省略这样的步骤,即,可以将核赔和/或计算赔付金额的操作全部在区块链中的智能合约中执行。或者,在另一些实施例中,也可以将所有核赔和/或计算赔付金额的操作都在节点101处执行。
如果未通过初步核赔,则向客户端返回未通过核赔的消息,并将订单赔付请求和赔付结果作为赔付数据存储在本地存储器中。否则,接下来,在节点101处,基于预定的存储规则生成赔付数据,其包括第三数据集合和第四数据集合。在图1的实施例中,第三数据集合包括赔付数据中的详细赔付信息,第四数据集合包括用户标识信息(例如,用户ID等)、通证标识信息(例如,通证ID等)和赔付数据中的至少部分详细赔付信息。节点101将第三数据集合存储在本地存储器中,而将第四数据集合发送给区块链中的其它节点,以在区块链中基于第四数据集合执行另外一部分核赔的操作,并根据核赔结果来更新对应通证的通证状态。
在另一些实施例中,预定的存储规则可以是任意设定的规则,第三数据集合和第四数据集合可以包括与核赔数据有关的任何其它数据。此外,在另一些实施例中,还可以基于保险公司和保险产品的不同而设置不同的存储规则。在核赔操作全部在区块链中执行的实施例中,将订单核赔请求作为核赔数据,并且在本地存储器中不存储任何核赔数据,而是将所有核赔数据都发送给区块链中的其它节点,以在区块链中执行核赔操作。
在图1的实施例中,节点103作为监管节点可以不参与核赔的过程。当区块链中的其它节点接收到来自节点101的第四数据集合之后,在除了节点103之外的每个节点处,根据与所请求的保险产品对应的智能合约和接收到的第四数据集合,判断是否能够通过核赔,即,通过智能合约执行另一部分的核赔操作。核赔的过程也经过区块链的各节点的共识。
与核保的过程类似,在一些实施例中,核赔的过程也可以包括由区块链的各节点调用中间件(例如,预言机)向外部系统发送核查信息的请求,并接收外部系统的核查结果。例如,在所请求核赔的保险产品为航空延误险的情况下,可以通过预言机向外部应用(例如,航空公司应用)发送核查航班延误的请求,而外部应用在进行核查后,向区块链的各节点发送核查结果,即,航班延误确认的结果。
接下来,根据核赔结果来更新对应通证的通证状态。如果未通过在区块链中的核赔,则由节点101向用户设备110的客户端返回订单核赔未通过的消息。否则,接下来,由区块链中除监管节点103以外的各节点基于智能合约来计算赔付金额并由节点101将赔付结果和赔付金额返回给用户设备110,以便在用户设备110处进行通证状态的更新。
如上面提及的,在另一些实施例中,也可以将所有核赔和/或计算赔付金额的操作都在节点101处完成,在这样的实施例中,第四数据集合包括核赔结果,因此在区块链的各节点处只需要更新对应的通证状态。或者,在一些实施例中,可以将核赔的操作全部在区块链中的智能合约中进行。在这样的实施例中,将订单核赔请求作为核赔数据,并发送给区块链中的其它节点,从而在区块链中完成全部核赔和/或计算赔付金额的操作并更新对应的通证状态。因而,在节点101的本地存储器中不保存核赔数据。
因此,在图1的实施例中,作为监管机构的节点103除了在生成保险订单、保险订单发生赔付等业务过程期间根据预定的监管规则进行实时监控之外,节点103还可以实时获得增量数据,并添加到报表中,从而可以实时查看业务状态变更。
下面将参照图1描述用户经由用户设备110查询订单的过程。用户在用户设备110的客户端上从通证列表中选择特定通证。通证列表可以由用户设备110向节点101请求而获得。在一些实施例中,用户可以通过人机对话机器人来进行这样的选择。人机对话机器人作为客户端的载体,用户通过与机器人对话来请求通证列表并选择特定通证。机器人通过自然语言处理技术,根据用户的语音输入来解析所选择的通证。在另一些实施例中,还可以通过其它外部系统调用机器人的API,来使得机器人获得用户的选择。或者,在另一些实施例中,用户还可以手动选择特定通证。
当用户设备110接收到所选择的通证之后,向节点101发送订单查询请求。在图1的实施例中,订单查询请求包括通证标识信息(例如,通证ID)以及与该通证对应的智能合约地址。节点101接收订单查询请求,并在区块链中搜索该智能合约地址和通证标识信息,以获得存储在该智能合约地址处的、与该通证对应的表示订单数据的第一数据集合在节点101的本地存储器中的地址的地址标识信息。接下来,节点101根据该地址标识信息,从本地存储器中获得第一数据集合,即订单数据中的全部业务数据。然后,节点101基于预定的加解密规则,将第一数据集合进行解密,并发送给用户设备110。
在另一些实施例中,订单数据被拆分为第一数据集合和第二数据集合,分别存储在本地存储器中和区块链中。因此,在节点101查询订单时,首先从区块链中读取第二数据集合并获得与通证对应的、存储在节点的本地存储器中的第一数据集合的地址标识信息,然后相应地从本地存储器中读取或者向其它节点请求第一数据集合,并基于预定的加解密规则和组合规则对第一数据集合和第二数据集合进行解密和合并后,发送给用户设备110。
在另一些实施例中,用户还可以批量查询订单,例如,选择多个通证。在这样的实施例中,订单查询请求可以包括多组通证标识信息(例如,通证ID)以及与该通证对应的智能合约地址,节点101按照与上述类似的方式获得存储在区块链中的第二数据集合和/或与多个通证分别对应的、存储在节点的本地存储器中的第一数据集合的地址标识信息,再分别从自身的本地存储器中读取或者向其它节点请求第一数据集合,经解密和合并后返回给用户设备110。
在另一些实施例中,用户还可以按保险公司为查询条件查询在若干个保险公司投保的保险订单。在这样的实施例中,订单查询请求可以包括保险公司标识信息(例如,节点ID)和用户标识信息(例如,用户ID),节点101根据保险公司-智能合约索引表,获得一系列智能合约地址。然后,节点101根据智能合约地址及用户标识信息获得存储在区块链中的第二数据集合和/或存储在节点的本地存储器中的第一数据集合的地址标识信息,再分别从自身的本地存储器中读取或者向其它节点请求第一数据集合,经解密和合并后返回给用户设备110。
在另一些实施例中,用户还可以按保险产品分类(例如,航延险、健康险、车险等等)为查询条件查询在若干个保险公司针对该类保险产品投保的所有保险订单。在这样的实施例中,订单查询请求可以包括保险产品分类、保险公司标识信息(例如,节点ID)和用户标识信息(例如,用户ID),节点101根据保险产品分类-智能合约索引表,获得一系列智能合约地址。然后,节点101根据智能合约地址及用户标识信息获得存储在区块链中的第二数据集合和/或存储在节点的本地存储器中的第一数据集合的地址标识信息,再分别从自身的本地存储器中读取或者向其它节点请求第一数据集合,经解密和合并后返回给用户设备110。
以上仅例示了查询条件的部分示例,在其它实施例中,查询条件可以是以上查询条件的任意组合。
在另一些实施例中,用户可以查询其它用户的订单。在这样的实施例中,节点101接收到订单查询请求后,根据被查询用户的用户标识信息,向被查询用户发送授权请求,在经过被查询用户授权的情况下,才能进行下一步的查询动作。
在另一些实施例中,核保的过程完全在区块链中进行,因此订单数据并未存储在节点的本地存储器中。在这样的实施例中,节点101接收到订单查询请求后,直接根据订单查询请求中所包括的智能合约地址和/或通证标识信息等来获得相应的订单数据。
在另一些实施例中,区块链的节点(例如,节点102或103)也可以根据查询条件来查询订单。查询条件可以是上面所提及的查询条件,例如,一组或多组通证标识信息(例如,通证ID)以及与该通证对应的智能合约地址、保险公司标识信息、保险产品分类,或者它们的任意组合。与上述的查询过程类似,在查询条件并非直接包括智能合约地址的情况下,首先根据保险公司-智能合约索引表和保险产品分类-智能合约索引表来获得智能合约地址。当需要获取存储在节点的本地存储器中的数据时,需要首先从区块链中的智能合约的地址处获取对应的地址标识信息。在待查询的订单较多的情况下,还可以使用数据同步机制将本地存储存储器和区块链中所存储的数据同步到缓存或搜索组件中,从而提升查询效率。在获得本地存储器中的数据之后,基于预定的加解密规则和组合规则对数据进行解密和合并。
在另一些实施例中,还可以根据查询节点的属性来设置查询权限。例如,作为监管节点的节点103不需要获得被查询订单所属用户的授权,而作为保险公司的节点102在查询其它保险公司的用户的保险订单时,需要获得被查询订单所属用户的授权。
上文以保险系统100为例详细描述了保险订单通证化、保险订单赔付以及保险订单查询的方法。然而,这仅仅是一个示例,本公开的实施例不限于保险系统。在其它示例中,也可以使用本公开的订单通证化、订单赔付以及订单查询的方法。
图2示出了根据本公开的一个实施例的基于区块链的订单通证化的方法的流程图。如图2中看到的,该基于区块链的订单通证化的方法200包括以下步骤:
首先,在步骤201中,在区块链的第一节点处,接收订单生成请求,订单生成请求包括订单分类标识数据,其中,区块链中存储有与订单分类标识数据相对应的智能合约。在一些实施例中,订单生成请求由与该第一节点通信连接的用户设备发送,订单生成请求包括用户标识信息、订单分类标识数据以及生成订单所需要的相关信息。在第一节点加入区块链网络时,将每种订单类型作为智能合约经由区块链中每个节点的共识而部署在区块链网络中,并且,每个智能合约都被分配一个地址。在第一节点的本地存储器中,存储订单分类标识数据与相应智能合约地址的索引表。因此,通过订单分类标识数据可以获得与其对应的智能合约的地址。如上文提及的,订单生成请求可以在用户设备处通过用户的手动输入、人机对话机器人等方式来生成。
接着,在步骤202中,在第一节点处,基于订单生成请求生成订单数据。在一些实施例中,该步骤进一步包括:判断订单生成请求是否满足预定的订单生成条件;以及在确定订单生成请求满足预定的订单生成条件的情况下,基于预定的存储规则生成订单数据,订单数据包括第一数据集合和第二数据集合。预定的存储规则可以是第一数据集合包括订单的全部业务数据,第二数据集合包括用户标识信息(例如,用户ID等)和订单的至少部分业务数据。在另一些实施例中,如果不在第一节点处判断订单生成请求是否满足预定的订单生成条件,即,判断是否满足预定的订单生成条件的操作全部在区块链中进行,则订单数据可以包括订单生成请求。在另一些实施例中,可以根据需要设定其它的存储规则,例如,第一数据集合和第二数据集合分别包括订单的一部分业务数据。
接下来,在步骤203中,由第一节点向区块链的多个第二节点发送订单数据的至少部分,以在区块链中基于对应的智能合约创建通证,通证包括订单的概况信息。通证由区块链中的多个第二节点通过共识,并基于智能合约和第二数据集合而生成,并且被分配有唯一标识信息。在生成通证之后,其由第一节点向发送订单生成请求的请求方返回通证。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):由第一节点将第一数据集合的至少部分存储在本地存储器中;以及由第一节点向多个第二节点发送表示第一数据集合的至少部分在本地存储器中的地址的地址标识信息,该地址标识信息与通证的标识信息一起存储在对应的智能合约在区块链中的地址处。
在一些实施例中,由第一节点向区块链的多个第二节点发送订单数据的至少部分的步骤进一步包括:由第一节点向多个第二节点发送第二数据集合,并且,第二数据集合的至少部分被存储在区块链中。在这样的实施例中,除了将第二数据集合发送给区块链中的其它节点以外,还将表示第一数据集合的至少部分在本地存储器中的地址的地址标识信息发送给区块链中的其它节点。在一些实施例中,在基于对应的智能合约和第二数据集合创建通证之后,在区块链中的多个第二节点处,都存储通证的唯一标识信息、对应的第二数据集合中的用户标识信息、通证生成日期、通证状态、以及表示第一数据集合的至少部分在第一节点的本地存储器中的地址的地址标识信息。这样,在区块链中仅存储了一些标识信息,而在第一节点的本地存储器中存储了关于订单的订单数据中的详细业务数据,从而可以在查询过程中通过地址标识信息而从本地存储器中查询相应的详细业务数据,减少了区块链中数据的存储量。在另一些实施例中,也可以使得订单数据中的部分业务数据包括在第二数据集合中,并存储在区块链中。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):基于预定的加解密规则,对第一数据集合和第二数据集合的至少部分进行加密。在第一数据集合和第二数据集合被存储或者发送之前,使用预定的加解密规则来对它们的至少部分进行加密,能够进一步提高数据的安全性和隐私性。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):在第一节点处,判断区块链中存储的对应的智能合约是否有效,并且其中,在确定对应的智能合约有效的情况下,基于订单生成请求生成订单数据。因为订单类型与智能合约地址一一对应,因此可以由第一节点首先在区块链中搜索与订单分类标识数据对应的智能合约,基于智能合约的状态判断与订单分类标识数据对应的智能合约是否有效。在确认有效的情况下,才基于订单生成请求生成订单数据。这样能够预先判断所请求的订单类型是否存在,从而能够提高将订单通证化的效率。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):在第一节点处,获得订单赔付请求,订单赔付请求包括与待赔付订单相对应的通证;在第一节点处,基于订单赔付请求生成赔付数据;以及由第一节点向多个第二节点发送赔付数据的至少部分,以获得赔付结果,赔付结果用于更新存储在区块链中的对应的通证的状态。
在一些实施例中,基于订单赔付请求生成赔付数据包括:判断订单赔付请求是否满足预定的订单赔付条件;以及在确定订单赔付请求满足预定的订单赔付条件的情况下,基于预定的存储规则生成赔付数据,赔付数据包括第三数据集合和第四数据集合。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):由第一节点将第三数据集合的至少部分存储在本地存储器中;并且其中由第一节点向区块链的多个第二节点发送赔付数据的至少部分包括:由第一节点向多个第二节点发送第四数据集合,并且,第四数据集合的至少部分被存储在所述区块链中。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):在第一节点处,获得订单查询请求;在第一节点处,基于订单查询请求中的查询条件获得与待查询订单相对应的智能合约在所述区块链中的地址;以及在第一节点处,根据智能合约的地址获得待查询订单的订单数据的至少部分。
在一些实施例中,根据智能合约的地址获得待查询订单的订单数据的至少部分包括:根据智能合约的地址,从区块链中获得订单数据的第二数据集合的至少部分以及表示订单数据的第一数据集合的至少部分在区块链的节点的本地存储器中的地址的地址标识信息;基于地址标识信息从本地存储器中获得第一数据集合的至少部分;以及基于预定的合并规则对第一数据集合的至少部分和第二数据集合的至少部分进行合并,以获得订单数据的至少部分。
在一些实施例中,基于区块链的订单通证化的方法200还包括以下步骤(在图2中未示出):在对第一数据集合的至少部分和第二数据集合的至少部分进行合并之前,基于预定的加解密规则,对第一数据集合的至少部分和所述第二数据集合的至少部分进行解密。
图3示出了根据本公开的一个实施例的基于区块链的订单赔付方法的流程图。从图3中可以看出,该基于区块链的订单赔付方法300包括以下步骤:
首先,在步骤301中,在区块链的第一节点处,获得订单赔付请求,订单赔付请求包括与待赔付订单相对应的通证。订单赔付请求可以由第一节点从用户设备处接收,也可以由第一节点自身发起。
接下来,在步骤302中,在第一节点处,基于订单赔付请求生成赔付数据。在一些实施例中,基于订单赔付请求生成赔付数据包括:判断订单赔付请求是否满足预定的订单赔付条件;以及在确定订单赔付请求满足预定的订单赔付条件的情况下,基于预定的存储规则生成所赔付数据,赔付数据包括第三数据集合和第四数据集合。
在一些实施例中,可以在第一节点处初步判断订单赔付请求是否满足预定的订单赔付条件,第三数据集合可以包括详细赔付信息,第四数据集合可以包括详细赔付信息的一部分和通证标识信息,以发送给区块链中的多个第二节点,并在区块链中完成另一部分的订单赔付条件的判断。
在另一些实施例中,判断订单赔付请求是否满足预定的订单赔付条件可以全部在第一节点处完成,因而第四数据集合可以包括赔付结果和通证标识信息,以改变存储在区块链中的对应通证的状态。在另一些实施例中,判断订单赔付请求是否满足预定的订单赔付条件也可以全部在区块链中完成。在这样的实施例中,赔付数据可以包括订单赔付请求,并被发送给区块链中的多个第二节点。
之后,在步骤303中,由第一节点向多个第二节点发送赔付数据的至少部分,以获得赔付结果,赔付结果用于更新存储在区块链中的对应的通证的状态。在该步骤中,第一节点向区块链中的多个第二节点发送赔付数据的至少部分,并且区块链中的各节点能够基于赔付结果而改变对应通证的状态。
在一些实施例中,用于获得区块链中的数据的方法300还包括以下步骤(在图3中未示出):由第一节点将第三数据集合的至少部分存储在本地存储器中;并且其中,由第一节点向区块链的多个第二节点发送赔付数据的至少部分包括:由第一节点向多个第二节点发送第四数据集合,并且,第四数据集合的至少部分被存储在区块链中。在该步骤中,第三数据集合的至少部分被存储在本地存储器中,第四数据集合被发送给区块链中的多个第二节点,并且其至少部分被存储在区块链中。通过将详细赔付信息的部分/或全部存储在本地存储器中,能够有效地减少区块链中数据的存储量。
图4示出了根据本公开的一个实施例的基于区块链的订单查询方法的流程图。从图4中可以看出,该基于区块链的订单查询方法400包括以下步骤:
首先,在步骤401中,在区块链的第一节点处,获得订单查询请求。订单查询请求可以来自用户设备或区块链的任一节点或者其它与区块链的节点通信连接的设备。
接下来,在步骤402中,在第一节点处,基于订单查询请求中的查询条件获得与待查询订单相对应的智能合约在区块链中的地址。如上面提及的,通证相关信息存储在区块链中对应的智能合约的地址处,因此,为了查询到相应订单,需要首先获得与待查询订单相对应的智能合约在区块链中的地址。
之后,在步骤403中,在第一节点处,根据智能合约的地址获得待查询订单的订单数据的至少部分。在一些实施例中,该步骤进一步包括:根据智能合约的地址,从区块链中获得订单数据的第二数据集合的至少部分以及表示订单数据的第一数据集合的至少部分在区块链的节点的本地存储器中的地址的地址标识信息;基于地址标识信息从本地存储器中获得第一数据集合的至少部分;以及基于预定的合并规则对第一数据集合的至少部分和第二数据集合的至少部分进行合并,以获得订单数据的至少部分。由于订单数据的第一数据集合的至少部分被存储在节点的本地存储器中,因此,首先从区块链中获得第二数据集合的至少部分并根据与待查询订单相对应的智能合约地址来查询第一数据集合的至少部分在区块链的节点的本地存储器中的地址的地址标识信息,然后再基于地址标识信息从节点的本地存储器中获得第一数据集合的至少部分,并基于预定的合并规则将它们进行合并。
在一些实施例中,在对第一数据集合的至少部分和第二数据集合的至少部分进行合并之前,基于预定的加解密规则,对第一数据集合的至少部分和第二数据集合的至少部分进行解密。
在一些实施例中,查询条件包括以下各项中的一项或多项:与待查询订单相对应的通证以及与待查询订单相对应的智能合约在区块链中的地址、待查询订单所属节点的标识信息、以及待查询订单所属的订单类型。
此外,替代地,上述方法能够通过计算机程序产品,即计算机可读存储介质来实现。计算机程序产品可以包括计算机可读存储介质,其上载有用于执行本公开的各个实施例的计算机可读程序指令。计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是但不限于电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身,诸如无线电波或者其它自由传播的电磁波、通过波导或其它传输媒介传播的电磁波(例如,通过光纤电缆的光脉冲)、或者通过电线传输的电信号。
一般而言,本公开的各种示例实施例可以在硬件或专用电路、软件、固件、逻辑,或其任何组合中实施。某些实施例可以在硬件中实施,而一些实施例可以在可以由控制器、微处理器或其它计算设备执行的固件或软件中实施。当本公开的各实施例被图示或描述为框图、流程图或使用某些其它图形表示时,将理解此处描述的方框、装置、系统、技术或方法可以作为非限制性的示例在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其它计算设备,或其某些组合中实施。
图5示出了根据本公开的一个实施例所提出的基于区块链的订单通证化的装置500的方框图。从图5中可以看出,基于区块链的订单通证化的装置500包括处理器501和与处理器501耦接的存储器502。
存储器502存储有指令。指令在由处理器501执行时使得处理器501执行以下动作:在区块链的第一节点处,接收订单生成请求,订单生成请求包括订单分类标识数据,其中,区块链中存储有与订单分类标识数据相对应的智能合约;在第一节点处,基于订单生成请求生成订单数据;以及由第一节点向区块链的多个第二节点发送订单数据的至少部分,以在区块链中基于对应的智能合约创建通证,通证包括订单的概况信息。
在一些实施例中,基于订单生成请求生成订单数据包括:判断订单生成请求是否满足预定的订单生成条件;以及在确定订单生成请求满足预定的订单生成条件的情况下,基于预定的存储规则生成订单数据,所述订单数据包括第一数据集合和第二数据集合。
在一些实施例中,指令在由处理器501执行时使得处理器501执行以下动作:由第一节点将第一数据集合的至少部分存储在本地存储器中;由第一节点向多个第二节点发送表示第一数据集合的至少部分在本地存储器中的地址的地址标识信息,地址标识信息与通证的标识信息一起存储在对应的智能合约在区块链中的地址处;并且其中,由第一节点向区块链的多个第二节点发送订单数据的至少部分包括:由第一节点向多个第二节点发送第二数据集合,并且,第二数据集合的至少部分被存储在区块链中。
在一些实施例中,指令在由处理器501执行时使得处理器501执行以下动作:在第一节点处,判断区块链中存储的对应的智能合约是否有效,并且其中,在确定对应的智能合约有效的情况下,基于订单生成请求生成订单数据。
本公开的实施例还提供了一种基于区块链的订单赔付装置,装置包括:处理器;以及存储器,其用于存储指令,当指令被执行时使得处理器执行以下操作:在区块链的第一节点处,获得订单赔付请求,订单赔付请求包括与待赔付订单相对应的通证;在第一节点处,基于订单赔付请求生成赔付数据;以及由第一节点向多个第二节点发送赔付数据的至少部分,以获得赔付结果,赔付结果用于更新存储在区块链中的对应的通证的状态。
在一些实施例中,基于所述订单赔付请求生成赔付数据包括:判断订单赔付请求是否满足预定的订单赔付条件;以及在确定订单赔付请求满足预定的订单赔付条件的情况下,基于预定的存储规则生成赔付数据,赔付数据包括第三数据集合和第四数据集合。
在一些实施例中,当指令被执行时还使得处理器执行以下操作:由第一节点将第三数据集合的至少部分存储在本地存储器中;并且其中,由第一节点向区块链的多个第二节点发送赔付数据的至少部分包括:由第一节点向多个第二节点发送第四数据集合,并且,第四数据集合的至少部分被存储在区块链中。
本公开的实施例还提供了一种基于区块链的订单查询装置,包括:处理器;以及存储器,其用于存储指令,当指令被执行时使得处理器执行以下操作:在区块链的第一节点处,获得订单查询请求;在第一节点处,基于订单查询请求中的查询条件获得与待查询订单相对应的智能合约在区块链中的地址;以及在第一节点处,根据智能合约的地址获得待查询订单的订单数据的至少部分。
在一些实施例中,根据智能合约的地址获得待查询订单的订单数据的至少部分包括:根据智能合约的地址,从区块链中获得订单数据的第二数据集合的至少部分以及表示订单数据的第一数据集合的至少部分在区块链的节点的本地存储器中的地址的地址标识信息;基于地址标识信息从本地存储器中获得第一数据集合的至少所述部分;以及基于预定的合并规则对第一数据集合的至少部分和第二数据集合的至少部分进行合并,以获得订单数据的至少部分。
在一些实施例中,在对第一数据集合的至少部分和第二数据集合的至少部分进行合并之前,基于预定的加解密规则,对第一数据集合的至少部分和第二数据集合的至少部分进行解密。
在一些实施例中,查询条件包括以下各项中的一项或多项:与待查询订单相对应的通证以及与待查询订单相对应的智能合约在区块链中的地址、待查询订单所属节点的标识信息、以及待查询订单所属的订单类型。
虽然上面描述了本公开的各种示例实施例可以在硬件或专用电路中实现,但是上述用于区块链的数据处理设备既可以以硬件的形式来实现,也可以通过软件的形式来实现,这是因为:在20世纪90年代,一个技术改进能够很容易地对该改进属于硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是属于软件上的改进(例如对于方法流程的改进)。然而,随着技术的持续发展,如今的很多方法流程的改进几乎都能够通过将改进的方法流程编程到硬件电路中来实现,换句话说,通过对于硬件电路编程不同的程序从而得到相应的硬件电路结构,即实现了硬件电路结构的改变,故这样的方法流程的改进也可以被视为硬件电路结构的直接改进。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device:PLD)(例如现场可编程门阵列(Field Programmable Gate Array:FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片可编程逻辑器件上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compi1er)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language:HDL),而HDL也并非仅有—种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell UniversityProgramming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等,目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
用于执行本公开的各个实施例的计算机可读程序指令或者计算机程序产品也能够存储在云端,在需要调用时,用户能够通过移动互联网、固网或者其它网络访问存储在云端上的用于执行本公开的一个实施例的计算机可读程序指令,从而实施依据本公开的各个实施例所公开的技术方案。
以上所述仅为本公开的实施例可选实施例,并不用于限制本公开的实施例,对于本领域的技术人员来说,本公开的实施例可以有各种更改和变化。凡在本公开的实施例的精神和原则之内,所作的任何修改、等效替换、改进等,均应包含在本公开的实施例的保护范围之内。
虽然已经参考若干具体实施例描述了本公开的实施例,但是应当理解,本公开的实施例并不限于所公开的具体实施例。本公开的实施例旨在涵盖在所附权利要求的精神和范围内所包括的各种修改和等同布置。权利要求的范围符合最宽泛的解释,从而包含所有这样的修改及等同结构和功能。