基于区块链的交通事故处理方法及装置、电子设备
技术领域
本说明书一个或多个实施例涉及区块链技术领域,尤其涉及一种基于区块链的交通事故处理方法及装置、电子设备。
背景技术
区块链技术,也被称之为分布式账本技术,是一种由若干台计算设备共同参与“记账”,共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性,使得区块链技术已在众多的领域中广泛的进行应用。
发明内容
本说明书提出一种基于区块链的交通事故处理方法,应用于客户端;其中,所述区块链存储了车辆身份信息和车辆投保详情数据的对应关系;所述方法包括:
响应于事故参与方用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,并查询所述区块链中存储的与所述车辆身份信息对应的车辆投保详情数据;
将所述车辆身份信息和所述车辆投保详情数据通过界面向事故参与方用户进行输出显示;
响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,将获取到的事故数据发布至所述区块链进行存证;其中,所述事故数据用于交通事故理赔;所述事故数据包括与所述事故相关的事故参与方用户的车辆身份信息以及与事故现场相关的取证数据的对应关系。
可选的,所述响应于事故参与方用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,包括:
响应于事故参与方用户的图像扫描操作,针对与事故相关的其他事故参与方用户的客户端上输出的基于所述车辆身份信息生成的图形编码进行编码识别,以获取其他事故参与方用户的车辆身份信息。
可选的,所述图形编码包括二维码。
可选的,所述区块链中部署了用于进行事故管理的智能合约;
所述响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,将获取到的事故数据发布至所述区块链进行存证,包括:
响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,构建用于发起事故上报的第一交易;其中,所述第一交易包括所述与事故现场相关的事故数据;
将所述第一交易发布至所述区块链,以使所述区块链中的节点设备响应于所述第一交易,调用所述智能合约中的校验逻辑,针对所述事故数据进行合法性校验;
如果针对所述事故数据合法性校验通过,进一步调用所述智能合约中的事件生成逻辑,生成与所述事故数据对应的事故事件,并将所述事故事件和所述事故数据关联存储至所述区块链的分布式账本。
可选的,还包括:
监听所述智能合约生成的事故事件;
响应于监听到的所述事故事件,向所述事故参与方用户输出与所述事故事件对应的提示信息,以提示所述事故参与方用户对所述事故事件发起理赔处理。
可选的,所述区块链中部署了用于进行事故理赔的智能合约;
所述方法还包括:
响应于事故参与方用户发起的针对所述事故事件的事故理赔操作,构建用于发起事故理赔的第二交易;
将所述第二交易发布至所述区块链,以使所述区块链中的节点设备响应于所述第二交易,调用所述智能合约中的验证逻辑,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,以及由所述第一事故数据中的其他事故参与方用户发布的第二事故数据,并验证所述第一事故数据与所述第二事故数据是否匹配;
如果是,进一步调用所述智能合约中的车祸理赔逻辑,对所述事故参与方用户进行车祸理赔处理。
可选的,所述与事故现场相关的取证数据,包括以下示出的一个或者多个的组合:
事故发生的时刻、事故发生的地点、与事故现场相关的图像数据。
本说明书还提出一种基于区块链的交通事故处理方法,应用于服务设备;其中,所述区块链存储了由事故参与方用户发布的事故数据;所述事故数据包括与事故相关的事故参与方用户的车辆身份信息和与事故现场相关的取证数据的对应关系;所述方法包括:
响应于针对事故参与方用户的事故理赔,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据;
基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据;
验证所述第一事故数据与所述第二事故数据是否匹配;如果是,对所述事故参与方用户进行车祸理赔处理。
可选的,所述服务设备为所述区块链中的节点设备;所述区块链中部署了用于进行事故管理的智能合约;
所述方法还包括:
接收客户端发送的用于发起事故上报的第一交易;所述第一交易包括所述与事故现场相关的事故数据;
响应于所述第一交易,调用所述智能合约中的校验逻辑,针对所述事故数据进行合法性校验;
如果针对所述事故数据合法性校验通过,进一步调用所述智能合约中的事件生成逻辑,创建与所述事故数据对应的事故事件,并将所述事故对象和所述事故数据关联存储至所述区块链的分布式账本。
可选的,所述方法还包括:
监听所述智能合约生成的事故事件;
响应于监听到的所述事故事件,向理赔机构发送与所述事故事件对应的提示信息,以提示理赔机构对所述事故事件进行理赔处理。
可选的,所述区块链中部署了用于进行事故理赔的智能合约;
所述响应于针对事故参与方用户的事故理赔,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据,验证所述第一事故数据与所述第二事故数据是否匹配,包括:
接收所述事故参与方用户通过客户端发送的用于发起事故理赔的第二交易;
响应于所述第二交易,调用所述智能合约中的验证逻辑,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据,验证所述第一事故数据与所述第二事故数据是否匹配;
所述如果是,对所述事故参与方用户进行车祸理赔处理,包括:
如果是,进一步调用所述智能合约中的车祸理赔逻辑,对所述事故参与方用户进行车祸理赔处理。可选的,还包括:
在对所述事故参与方用户进行车祸理赔处理完成后,将针对所述事故参与方用户的车祸理赔记录发布至所述区块链进行存证。
本说明书还提出一种基于区块链的交通事故处理装置,应用于客户端;其中,所述区块链存储了车辆身份信息和车辆投保详情数据的对应关系;所述方法包括:
第一获取模块,响应于事故参与方用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,并查询所述区块链中存储的与所述车辆身份信息对应的车辆投保详情数据;
输出模块,将所述车辆身份信息和所述车辆投保详情数据通过界面向事故参与方用户进行输出显示;
存证模块,响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,将获取到的事故数据发布至所述区块链进行存证;其中,所述事故数据用于交通事故理赔;所述事故数据包括与所述事故相关的事故参与方用户的车辆身份信息以及与事故现场相关的取证数据的对应关系。
可选的,所述第一获取模块:
响应于事故参与方用户的图像扫描操作,针对与事故相关的其他事故参与方用户的客户端上输出的基于所述车辆身份信息生成的图形编码进行编码识别,以获取其他事故参与方用户的车辆身份信息。
可选的,所述图形编码包括二维码。
可选的,所述区块链中部署了用于进行事故管理的智能合约;
所述存证模块:
响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,构建用于发起事故上报的第一交易;其中,所述第一交易包括所述与事故现场相关的事故数据;
将所述第一交易发布至所述区块链,以使所述区块链中的节点设备响应于所述第一交易,调用所述智能合约中的校验逻辑,针对所述事故数据进行合法性校验;
如果针对所述事故数据合法性校验通过,进一步调用所述智能合约中的事件生成逻辑,生成与所述事故数据对应的事故事件,并将所述事故事件和所述事故数据关联存储至所述区块链的分布式账本。
可选的,还包括:
第一监听模块,监听所述智能合约生成的事故事件;响应于监听到的所述事故事件,向所述事故参与方用户输出与所述事故事件对应的提示信息,以提示所述事故参与方用户对所述事故事件发起理赔处理。
可选的,所述区块链中部署了用于进行事故理赔的智能合约;
所述装置还包括:
第一理赔模块,响应于事故参与方用户发起的针对所述事故事件的事故理赔操作,构建用于发起事故理赔的第二交易;将所述第二交易发布至所述区块链,以使所述区块链中的节点设备响应于所述第二交易,调用所述智能合约中的验证逻辑,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,以及由所述第一事故数据中的其他事故参与方用户发布的第二事故数据,并验证所述第一事故数据与所述第二事故数据是否匹配;如果是,进一步调用所述智能合约中的车祸理赔逻辑,对所述事故参与方用户进行车祸理赔处理。
本说明书还提出一种基于区块链的交通事故处理装置,应用于服务设备;其中,所述区块链存储了由事故参与方用户发布的事故数据;所述事故数据包括与事故相关的事故参与方用户的车辆身份信息和与事故现场相关的取证数据的对应关系;所述方法包括:
第二获取模块,响应于针对事故参与方用户的事故理赔,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据;基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据;
验证模块,验证所述第一事故数据与所述第二事故数据是否匹配;
第二理赔模块,如果是,对所述事故参与方用户进行车祸理赔处理。
可选的,所述服务设备为所述区块链中的节点设备;所述区块链中部署了用于进行事故管理的智能合约;
所述装置还包括:
生成模块,接收客户端发送的用于发起事故上报的第一交易;所述第一交易包括所述与事故现场相关的事故数据;响应于所述第一交易,调用所述智能合约中的校验逻辑,针对所述事故数据进行合法性校验;如果针对所述事故数据合法性校验通过,进一步调用所述智能合约中的事件生成逻辑,创建与所述事故数据对应的事故事件,并将所述事故对象和所述事故数据关联存储至所述区块链的分布式账本。
可选的,所述装置还包括:
第二监听模块,监听所述智能合约生成的事故事件;响应于监听到的所述事故事件,向理赔机构发送与所述事故事件对应的提示信息,以提示理赔机构对所述事故事件进行理赔处理。
可选的,所述区块链中部署了用于进行事故理赔的智能合约;
所述验证模块:
接收所述事故参与方用户通过客户端发送的用于发起事故理赔的第二交易;
响应于所述第二交易,调用所述智能合约中的验证逻辑,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据,验证所述第一事故数据与所述第二事故数据是否匹配;
所述第二理赔模块:
如果是,进一步调用所述智能合约中的车祸理赔逻辑,对所述事故参与方用户进行车祸理赔处理。
可选的,所述第二理赔模块进一步:
在对所述事故参与方用户进行车祸理赔处理完成后,将针对所述事故参与方用户的车祸理赔记录发布至所述区块链进行存证。
以上技术方案中,一方面,由于用户可以通过客户端访问在区块链中存储的数据,快捷的与其他事故参与方用户交换各自的车辆投保详情数据,对其他事故参与方用户的车辆身份数据和车辆投保详情数据进行相互验证确认,并在对其他事故参与方用户的车辆身份数据和车辆投保详情数据进行确认后,可以通过客户端将事故参与方用户的车辆身份信息和与事故现场相关的取证数据作为用于交通事故理赔的事故数据自主的上报到区块链进行存证,而不再需要交通管理部门的工作人员进行事故处理,因此可以降低交通管理部门的工作负担,提高事故上报理赔的处理效率;
另一方面,由于理赔机构在针对事故参与方用户进行事故理赔时,可以将区块链中存储的由该用户和其他事故参与方用户发布的事故数据进行匹配,来对本次的事故进行真实性验证,从而可以避免用户单方面向区块链发布虚假事故数据来骗取理赔的行为,提升事故理赔的安全性。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图;
图2是一示例性实施例提供的调用智能合约的示意图;
图3是一示例性实施例提供的创建智能合约和调用智能合约的示意图;
图4是一示例性实施例提供的一种基于区块链的事故处理方法的流程图;
图5是一示例性实施例提供的一种电子设备的结构示意图;
图6是一示例性实施例提供的一种基于区块链的交通事故处理装置的框图;
图7是一示例性实施例提供的另一种基于区块链的交通事故处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型:公有链(Public Blockchain),私有链(PrivateBlockchain)和联盟链(Consortium Blockchain)。此外,还可以有上述多种类型的结合,比如私有链+联盟链、联盟链+公有链等。
其中,去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者(也可称为区块链中的节点)可以读取链上的数据记录、参与交易、以及竞争新区块的记账权等。而且,各节点可自由加入或者退出网络,并进行相关操作。
私有链则相反,该网络的写入权限由某个组织或者机构控制,数据读取权限受组织规定。简单来说,私有链可以为一个弱中心化系统,其对节点具有严格限制且节点数量较少。这种类型的区块链更适合于特定机构内部使用。
联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织;节点通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
基于区块链的基本特性,区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳,所有的区块严格按照区块中记录的时间戳,构成一条在时间上有序的数据链条。
对于物理世界产生的真实数据,可以将其构建成区块链所支持的标准的交易(transaction)格式,然后发布至区块链,由区块链中的节点设备对收到的交易进行共识处理,并在达成共识后,由区块链中作为记账节点的节点设备,将这笔交易打包进区块,在区块链中进行持久化存证。
其中,区块链中支持的共识算法可以包括:
第一类共识算法,即节点设备需要争夺每一轮的记账周期的记账权的共识算法;例如,工作量证明(Proof of Work,POW)、股权证明(Proof of Stake,POS)、委任权益证明(Delegated Proof of Stake,DPOS)等共识算法;
第二类共识算法,即预先为每一轮记账周期选举记账节点(不需要争夺记账权)的共识算法;例如,实用拜占庭容错(Practical Byzantine Fault Tolerance,PBFT)等共识算法。
在采用第一类共识算法的区块链网络中,争夺记账权的节点设备,都可以在接收到交易后执行该笔交易。争夺记账权的节点设备中可能有一个节点设备在本轮争夺记账权的过程中胜出,成为记账节点。记账节点可以将收到的交易与其它交易一起打包以生成最新区块,并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识。
在采用第二类共识算法的区块链网络中,具有记账权的节点设备在本轮记账前已经商定好。因此,节点设备在接收到交易后,如果自身不是本轮的记账节点,则可以将该交易发送至记账节点。对于本轮的记账节点,在将该交易与其它交易一起打包以生成最新区块的过程中或者之前,可以执行该交易。记账节点在生成最新区块后,可以将该最新区块或者该最新区块的区块头发送至其它节点设备进行共识。
如上所述,无论区块链采用以上示出的哪种共识算法,本轮的记账节点都可以将接收到的交易打包以生成最新区块,并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到最新区块或者该最新区块的区块头后,经验证没有问题,可以将该最新区块追加到原有的区块链末尾,从而完成区块链的记账过程。其它节点验证记账节点发来的新的区块或区块头的过程中,也可以执行该区块中的包含的交易。
在区块链领域,有一个重要的概念就是账户(Account);以以太坊为例,以太坊通常将账户划分为外部账户和合约账户两类;外部账户就是由用户直接控制的账户,也称之为用户账户;而合约账户则是由用户通过外部账户创建的,包含合约代码的账户(即智能合约)。
当然,对于一些基于以太坊的架构而衍生出的区块链模型(比如蚂蚁区块链),还可以对区块链支持的账户类型,进行进一步的扩展,在本说明书中不进行特别限定。
对于区块链中的账户而言,通常会通过一个结构体,来维护账户的账户状态。当区块中的交易被执行后,区块链中与该交易相关的账户的状态通常也会发生变化。
以以太坊为例,账户的结构体通常包括Balance,Nonce,Code和Storage等字段。其中:
Balance字段,用于维护账户目前的账户余额;
Nonce字段,用于维护该账户的交易次数;它是用于保障每笔交易能且只能被处理一次的计数器,有效避免重放攻击;
Code字段,用于维护该账户的合约代码;在实际应用中,Code字段中通常仅维护合约代码的hash值;因而,Code字段通常也称之为Codehash字段。
Storage字段,用于维护该账户的存储内容(默认字段值为空);对于合约账户而言,通常会分配一个独立的存储空间,用以存储该合约账户的存储内容;该独立的存储空间通常称之为该合约账户的账户存储。合约账户的存储内容通常会构建成MPT(MerklePatricia Trie)树的数据结构存储在上述独立的存储空间之中;其中,基于合约账户的存储内容构建成的MPT树,通常也称之为Storage树。而Storage字段通常仅维护该Storage树的根节点;因此,Storage字段通常也称之为StorageRoot字段。
其中,对于外部账户而言,以上示出的Code字段和Storage字段的字段值均为空值。
对于大多数区块链模型,通常都会使用Merkle树;或者,基于Merkle树的数据结构,来存储和维护数据。以以太坊为例,以太坊使用了MPT树,作为数据组织形式,用来组织和管理账户状态、交易信息等重要数据。其中,MPT树是一种融合了Trie字典树的树形结构的Merkle树变种。
以太坊针对区块链中需要存储和维护的数据,设计了三棵MPT树,分别是MPT状态树、MPT交易树和MPT收据树。其中,除了以上三棵MPT树以外,实际上还存在一棵基于合约账户的存储内容构建的Storage树。
MPT状态树,是由区块链中所有账户的账户状态(state)数据组织成的MPT树;MPT交易树,是由区块链中的交易(transaction)数据组织成的MPT树;MPT收据树,是区块中的交易在执行完毕后生成的与每笔交易对应的交易(receipt)收据组织成的MPT树。以上示出的MPT状态树、MPT交易树和MPT收据树的根节点的hash值,最终都会被添加至对应区块的区块头中。
其中,MPT交易树和MPT收据树均与区块相对应,即每一个区块都有自己的MPT交易树和MPT收据树。而MPT状态树是一个全局的MPT树,并不与某一个特定的区块相对应,而是涵盖了区块链中所有账户的账户状态数据。
需要说明的是,区块链每产生一个最新区块,则在该最新区块中的交易被执行之后,区块链中这些被执行交易的相关账户(可以是外部账户也可以是合约账户)的账户状态,通常也会随之发生变化;
例如,当区块中的一笔“转账交易”执行完毕后,与该“转账交易”相关的转出方账户和转入方账户的余额(即这些账户的Balance字段的字段值),通常也会随之发生变化。
而节点设备在区块链产生的最新区块中的交易执行完毕后,由于当前区块链中的账户状态发生了变化,因此节点设备需要根据区块链中所有账户当前的账户状态数据,来构建MPT状态树,用于维护区块链中所有账户的最新状态。
也即,每当区块链中产生一个最新区块,并且该最新区块中的交易执行完毕后,导致区块链中的账户状态发生了变化,节点设备都需要基于区块链中所有账户最新的账户状态数据,重新构建一棵MPT状态树。
换句话说,区块链中每一个区块,都有一个与之对应的MPT状态树;该MPT状态树,维护了在该区块中的交易在执行完毕后,区块链中所有账户最新的账户状态。
在实际应用中,不论是公有链、私有链还是联盟链,都可能提供智能合约(Smartcontract)的功能。区块链上的智能合约是在区块链上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑。以太坊作为一个可编程区块链,其核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,通过它可以实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,EVM直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”),所以部署在区块链上的智能合约可以是字节码。
如图1所示,Bob将一笔包含创建智能合约信息的交易(Transaction)发送到以太坊网络后,各节点均可以在EVM中执行这笔交易。其中,图中1中交易的From字段用于记录发起创建智能合约的账户的地址,交易的Data字段的字段值保存的合约代码可以是字节码,交易的To字段的字段值为一个null(空)的账户。当节点间通过共识机制达成一致后,这个智能合约成功创建,后续用户可以调用这个智能合约。
智能合约创建后,区块链上出现一个与该智能合约对应的合约账户,并拥有一个特定的地址;比如,图1中各节点中的“0x68e12cf284…”就代表了创建的这个合约账户的地址;合约代码(Code)和账户存储(Storage)将保存在该合约账户的账户存储中。智能合约的行为由合约代码控制,而智能合约的账户存储则保存了合约的状态。换句话说,智能合约使得区块链上产生包含合约代码和账户存储的虚拟账户。
前述提到,包含创建智能合约的交易的Data字段保存的可以是该智能合约的字节码。字节码由一连串的字节组成,每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑,开发者可以不直接书写字节码,而是选择一门高级语言编写智能合约代码。例如,高级语言可以采用诸如Solidity、Serpent、LLL语言等。对于采用高级语言编写的智能合约代码,可以经过编译器编译,生成可以部署到区块链上的字节码。
以Solidity语言为例,用其编写的合约代码与面向对象编程语言中的类(Class)很相似,在一个合约中可以声明多种成员,包括状态变量、函数、函数修改器、事件等。状态变量是永久存储在智能合约的账户存储(Storage)字段中的值,用于保存合约的状态。
如图2所示,仍以以太坊为例,Bob将一笔包含调用智能合约信息的交易发送到以太坊网络后,各节点均可以在EVM中执行这笔交易。其中,图2中交易的From字段用于记录发起调用智能合约的账户的地址,To字段用于记录被调用的智能合约的地址,交易的Data字段用于记录调用智能合约的方法和参数。调用智能合约后,合约账户的账户状态可能改变。后续,某个客户端可以通过接入的区块链节点(例如图2中的节点1)查看合约账户的账户状态。
智能合约可以以规定的方式在区块链网络中每个节点独立的执行,所有执行记录和数据都保存在区块链上,所以当这样的交易执行完毕后,区块链上就保存了无法篡改、不会丢失的交易凭证。
创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约,需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约,是发起一笔指向智能合约地址的交易,各个节点的EVM可以分别执行该交易,将智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
在实际应用中,当用户在发生交通事故后,通常需要交通管理部门的工作人员到达现场,对事故进行处理,并上报事故数据。而当用户需要对事故进行理赔时,则需要向理赔机构(比如保险公司)进行理赔申报,由理赔机构对用户申报的需要理赔的事故进行核实后,对该用户进行理赔处理。
不难理解,在以上描述的整个事故上报和理赔流程中,仍然需要交通管理部门甚至理赔机构进行人工处理,因此会造成人力成本较高,和事故申报理赔的效率低下的问题。
而本说明书旨在提出一种事故参与方通过访问区块链中存储的数据,快捷的与其他事故参与方用户交换各自的车辆身份数据和车辆投保详情数据进行相互验证,进而在验证后自主的将事故数据上报至区块链进行存储并完成理赔的技术方案。
在实现时,用户可以将自己名下的车辆的车辆身份信息和车辆投保详情数据的对应关系上传至区块链进行存储。当用户在发生交通事故后,客户端可以响应用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,并查询所述区块链中存储的与所述车辆身份信息对应的车辆投保详情数据;
在查询到其他事故参与方用户的车辆投保详情数据之后,可以将所述车辆身份数据和所述车辆投保详情数据通过界面向事故参与方用户进行输出显示,由用户进行查看验证;当用户对输出显示的数据进行确认后,客户端可以响应用户的确认操作,将客户端获取到的事故数据发布至区块链进行存证;其中,该事故数据可以用于交通事故理赔;该事故数据包括与本次事故相关的事故参与方用户的车辆身份信息,和客户端获取到的与事故现场相关的取证数据的对应关系。
而对于其他事故参与方用户来说,也可以通过客户端执行以上描述的相同的操作,也将客户端获取到的事故数据发布至区块链进行存证。
当事故的事故参与方用户均通过客户端,分别将获取到的上述事故数据发布至区块链进行存证之后,理赔机构在对本次事故的事故参与方进行理赔时,可以获取区块链中存储的由该事故参与方用户发布的第一事故数据,并基于该第一事故数据的数据内容来确定与本次事故相关的其他事故参与方用户,然后再获取由该其他事故参与方用户发布至区块链的第二事故数据。
进一步的,理赔机构可以验证该第一事故数据与该第二事故数据是否匹配,来确认本次事故的真实性;如果二者匹配,证明本次事故为真实的事故,可以进一步对该事故参与方用户进行车祸理赔处理。
在以上技术方案中,一方面,由于用户可以通过客户端访问在区块链中存储的数据,快捷的与其他事故参与方用户交换各自的车辆投保详情数据,对其他事故参与方用户的车辆身份数据和车辆投保详情数据进行相互验证确认,并在对其他事故参与方用户的车辆身份数据和车辆投保详情数据进行确认后,可以通过客户端将所有事故参与方用户的车辆身份信息和与事故现场相关的取证数据作为用于交通事故理赔的事故数据自主的上报到区块链进行存证,而不再需要交通管理部门的工作人员进行事故处理,因此可以降低交通管理部门的工作负担,提高事故上报理赔的处理效率;
另一方面,由于理赔机构在针对事故参与方用户进行事故理赔时,可以将区块链中存储的由该用户和其他事故参与方用户发布的事故数据进行匹配,来对本次的事故进行真实性验证,从而可以避免用户单方面向区块链发布虚假事故数据来骗取理赔的行为,提升事故理赔的安全性。
以下将结合具体的实施例对本说明书披露的技术方案进行详细描述。
请参见图4,图4是一示例性实施例提供的一种基于区块链的交通事故处理方法的流程图。其中,所述区块链存储了车辆身份信息和车辆投保详情数据的对应关系;所述方法包括以下步骤:
步骤402,客户端响应于事故参与方用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,并查询所述区块链中存储的与所述车辆身份信息对应的车辆投保详情数据;
步骤404,客户端将所述车辆身份信息和车辆投保详情数据通过界面向事故参与方用户进行输出显示。
步骤406,客户端响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,将获取到的事故数据发布至所述区块链进行存证;其中,所述事故数据用于交通事故理赔;所述事故数据包括与所述事故相关的事故参与方用户的车辆身份信息和与事故现场相关的取证数据的对应关系;
步骤408,服务设备响应于针对所述事故的事故理赔,获取区块链中存储的由事故参与方用户发布的第一事故数据,基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据;
步骤410,验证所述第一事故数据与所述第二事故数据是否匹配;如果是,对所述事故参与方用户进行车祸理赔处理。
上述客户端,具体可以包括面向驾驶者提供各种与车辆相关的增值服务的客户端软件;
例如,在一个例子中,上述客户端具体可以是一款面向驾驶者提供服务的名为“驾驶员钱包”APP;该APP面向驾驶者提供的服务具体可以包括:停车费、罚单、行驶费缴纳、事故申报、事故理赔等在线服务。
上述服务设备,具体可以与理赔机构(比如保险公司)对应,可以包括理赔机构面向用户提供服务的服务器、服务器集群、或者基于服务器集群搭建的服务平台,等等。其中,需要说明的是,上述服务设备可以是与理赔机构对应的中心化服务设备,也可以作为节点设备加入区块链。
在本说明书中,用户可以预先将自己名下的车辆的车辆身份信息和车辆投保详情数据的对应关系上传至区块链进行存储。
其中,上述车辆身份信息,具体可以包括车辆信息和与车辆信息绑定的用户身份信息;
例如,在实际应用中,上述车辆信息具体可以包括车辆的车牌号、发动机号、车辆外观数据(比如车辆外观图片),等等可以唯一标识车辆的各种信息。上述用户身份信息,具体可以包括用户的身份证号、驾驶证号等能够唯一标识用户的信息。
当用户在发生交通事故后,可以通过操作客户端访问区块链中存储的数据,与其他的事故参与方交换各自的车辆身份信息和投保详情数据进行互相验证。
而客户端可以响应用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,并将获取到的其他事故参与方用户的车辆身份信息作为查询索引,来查询区块链中存储的与该车辆身份信息对应的车辆投保详情数据。
其中,需要说明的是,用户通过客户端获取与事故相关的其他事故参与方用户的车辆身份信息的具体方式,在本说明书中不进行特别的限定;
在示出的一种实施方式,用户可以通过使用客户端与其他事故参与方用户进行扫码的方式,来获取其他事故参与方用户的车辆身份信息;在这种情况下,在客户端中可以面向用户提供一个由用户的车辆身份信息生成的图形编码的访问入口;用户在遭遇车祸后,所有的车祸参与方用户都可以通过操作客户端提供的该访问入口,触发将该图形编码在客户端的用户界面进行输出展示。
事故参与方用户可以通过客户端对其他事故参与方用户的客户端上输出的图形编码进行图像扫描操作,来获取对方的车辆身份信息。而客户端可以响应用户发起的图像扫描操作,针对其他事故参与方用户的客户端上输出的图形编码进行编码识别,解析出图形编码中携带的编码信息,来获取其他事故参与方用户的车辆身份信息。
其中,需要说明的是,上述图形编码的具体形式,在本说明书中不再进行特别的限定;例如,可以是通用的二维码,也可以是诸如二维码以外的条形码,或者其它形式的图形编码。
在本说明书中,当用户的客户端查询到区块链中存储的与上述其他事故参与方用户的车辆身份信息对应的车辆投保详情数据之后,可以将获取到的上述其他事故参与方用户的车辆身份信息和对应的车辆投保详情数据通过界面向该用户输出,由该用户对本次事故的其他事故参与方用户的车辆身份信息和车辆投保详情数据进行验证确认。相应的,对于其他事故参与方用户而言,也可以通过相同的方式,使用客户端来扫描该用户的客户端输出的图像编码,获取该用户的车辆身份信息以及车辆投保详情数据,在界面中进行输出显示,然后再进行验证确认,具体的过程不再赘述。
可以理解的是,对于事故的任意参与一方,都可以通过以上描述的扫码过程,通过区块链与其他事故参与方用户进行车辆身份数据和车辆投保详情数据的数据交换,来相互进行验证。
其中,需要说明的是,上述车辆投保详情数据具体可以包括保险公司的基本信息、车辆保险信息、车辆保险有效期等信息;而用户在相互验证事故对方的以上信息时,可以验证车辆身份信息是否与事故车辆匹配,车辆保险详情中规定的理赔事故类型是否涵盖本次事故类型,车辆保险有效期是否到期,等等。
当用户对客户端输出的其他事故参与方用户的车辆身份信息和车辆投保详情数据进行验证无误后,可以在客户端的界面中对客户端展示的这些信息执行确认操作;
例如,在实现时,客户端在通过界面输出以上信息时,还可以提供一个对应的确认按钮;用户在验证以上信息无误后,可以通过诸如点击等方式,触发该确认按钮,对已经验证通过的以上信息进行确认。
当用户在客户端上执行了对上述其他事故参与方用户的车辆身份信息和车辆投保详情数据的确认操作之后,客户端可以响应该确认操作,将获取到的与本次事故相关事故数据发布至区块链进行存证,以完成本次事故的上报;
当然,在实际应用中,出于数据隐私保护的目的,也可以仅将与本次事故相关事故数据的数据摘要(比如hash值),发布至区块链进行存证,而将事故数据的原始内容在客户端本地,或者由客户端进一步提交给理赔机构进行存储。也即,在本说明书中,客户端发布至区块链的事故数据,可以是事故数据的原始内容,也可以是事故数据的摘要数据,在本说明书中不进行特别限定。
其中,上述事故数据具体用于交通事故理赔;上述事故数据可以包括与上述事故相关的事故参与方用户的车辆身份信息和与事故现场相关的取证数据的对应关系。
需要说明的是,上述事故数据中包括的车辆身份信息,可以包括所有事故参与方用户的车辆身份信息,也可以仅包括所有事故参与方用户中的至少多个事故参与方的车辆身份信息,在本说明书中不进行特别限定。
例如,假设用户A、B和C发生了第三方事故,则对于A发布至区块链的事故数据中,可以包括用户A、B和C三方的车辆身份信息,也可以仅包括用户A的车辆身份信息,以及B或者C中的其中一个事故参与方用户的车辆身份信息。
上述与事故现场相关的取证数据,具体可以包括事故发生的时刻、事故发生的地点、与事故现场相关的图像数据等数据中的一个或者多个的组合。其中,上述图像数据具体可以包括与事故现场相关的图片、视频或者其它形式的能够还原出事故现场状况的图像数据。
在示出的一种实施方式中,上述取证数据,可以是客户端在响应用户的上述确认操作时,由用户实时获取到的数据。
例如,以上述取证数据,为与事故现场相关的图片为例;在这种情况下,当用户在客户端上执行了对上述其他事故参与方用户的车辆身份信息和车辆投保详情数据的确认操作之后,客户端可以响应该确认操作,通过界面向用户输出一条“是否跳转至拍摄界面拍摄事故现场”的提示消息,用户进行确认后跳转至拍摄界面对事故现场进行拍摄取证;或者,也可以直接跳转至拍摄界面对事故现场进行拍摄取证。
当然,在实现时,上述取证数据,也可以是用户使用客户端提前获取到的数据;
例如,仍以上述取证数据,为与事故现场相关的图片为例;在这种情况下,当用户在客户端上执行了对上述其他事故参与方用户的车辆身份信息和车辆投保详情数据的确认操作之后,客户端可以响应该确认操作,通过界面向用户输出一上传入口;用户可以通过触发该上传入口,从相册目录中选择已经拍摄的事故现场图片进行上传。
相应的,对于其他事故参与方用户而言,也可以通过相同的方式,向区块链上传与本次事故相关的事故数据,不再赘述。在本说明书中,上述区块链上还可以预先部署了用于进行事故管理的智能合约;其中,智能合约的部署过程,请参照图1描述的具体过程,不再赘述。
在该智能合约中声明的合约代码对应的代码执行逻辑,可以包括用于对事故数据进行合法性校验的校验逻辑,和事故事件生成逻辑;用户在发生事故后,可以通过客户端调用该智能合约,将本次事故相关的事故数据上报至区块链进行存储。
具体地,当用户在客户端上执行了对上述其他事故参与方用户的车辆身份信息和车辆投保详情数据的确认操作之后,客户端可以响应该确认操作,构建一笔用于发起事故上报的第一交易;其中,该第一交易具体可以是一笔用于调用智能合约的交易,在该交易中具体可以包括与事故现场相关的上述事故数据;
然后,客户端可以将该第一交易发布至区块链。而区块链中的节点设备在收到该第一交易后,可以响应该第一交易,调用上述智能合约中的校验逻辑,针对上述事故数据进行合法性校验;
其中,合法性校验的具体校验过程,在本说明书中不进行特别限定;例如,在一个例子中,上述事故数据可以携带数字签名,对上述事故数据进行合法性校验,则可以包括对上述事故数据的数字签名进行校验;如果数字签名校验通过,可以确定该事故数据是合法的数据。
如果针对上述事故数据合法性校验通过,可以进一步调用上述智能合约中的事件生成逻辑,生成与上述事故数据对应的事故事件,并将上述事故事件和上述事故数据关联存储至上述区块链的分布式账本。
其中,需要说明的是,上述事故事件具体可以是通过调用智能合约在区块链上创建的新的对象;在一个例子中,上述事故事件,具体可以是通过调用智能合约创建出的新的账户对象;
例如,在实现时,可以对区块链支持的账户类型,进行进一步的扩展,在外部账户和合约账户的基础上,扩展出一种与事故事件对应的账户类型。在这种情况下,上述事故事件和上述事故数据具体可以关联存储至上述智能合约对应的Storage树中;比如,上述事故事件可以作为key(可以是作为账户地址的字符串),上述事故数据可以作为与key对应的Value,以Key-Value对的形式,存储至Storage树中。
当用户通过客户端将与事故相关的事故数据发布至区块链进行存储后,客户端可以监听上述智能合约在区块链上生成的事故事件;例如,可以开发监听程序监听智能合约的Storage树中新创建的与事故事件对应的账户对象;
当监听到上述智能合约在区块链上生成的事故事件之后,可以响应于该事故事件,向事故参与方用户输出与该事故事件对应的提示信息,以提示该对该事故参与方用户对该事故事件发起理赔处理;
例如,在实现时,该提示消息可以是一条“您已成功上报了事故事件,是否发起理赔”的提示消息。该事故参与方用户可以在该提示消息的提示下,来决定是否发起针对该事故事件进行理赔处理。
当该事故参与方用户在上述提示消息的提示下,决定对该事故事件进行理赔时,可以通过客户端向理赔机构发起针对该事故事件进行理赔处理;而客户端可以响应于该事故参与方用户发起的针对该事故事件的事故理赔操作,来发起理赔处理;
例如,在一种方式中,该客户端可以响应上述事故理赔操作,向理赔机构的服务端发送一个理赔请求,来发起理赔;也可以在区块链上部署了由理赔机构发布的用于事故理赔的智能合约的情况下,向区块链的节点设备发送一笔调用智能合约的交易来发起理赔。
在本说明书中,当事故相关的事故参与方用户通过客户端,分别将获取到的上述事故数据发布至区块链进行存证之后,理赔机构可以基于区块链上最新发布的事故数据,来对事故参与方用户进行理赔处理。
其中,理赔机构对事故参与方用户进行的理赔处理,可以是由理赔机构通过服务设备监听区块链上最新发布的事故数据主动发起的,也可以是由用户通过客户端来主动发起的,在本说明书不进行特别限定;
在示出的一种实施方式中,如前所述,上述区块链上可以预先部署了用于进行事故管理的智能合约,用户可以通过调用该智能合约,来触发在区块链上生成事故事件,并将生成的事故事件与上述事故数据关联存储至区块链的分布式账本。
在这种情况下,理赔机构的服务设备可以监听上述智能合约在区块链上生成的事故事件;例如,可以开发监听程序监听智能合约的Storage树中新创建的与事故事件对应的账户对象;
当监听到上述智能合约在区块链上生成的事故事件之后,可以响应于该事故事件,向理赔机构发送与该事故事件对应的提示信息,以提示理赔机构对该事故事件进行理赔处理;
例如,在实现时,该提示消息可以是一条“收到XX用户上报的事故事件,是否发起理赔”的提示消息。理赔机构可以在该提示消息的提示下,来决定是否发起针对该事故事件的事故参与方用户进行理赔处理。
当理赔机构在上述提示消息的提示下,决定对本次事故的某个事故参与方进行理赔时,可以获取区块链中存储的由该事故参与方用户发布的第一事故数据;例如,上述提示消息中可以携带该事故事件的key,理赔机构可以基于该key,在智能合约的Storage树查询与该事故事件对应的事故数据;
在获取到由该事故参与方用户发布的第一事故数据之后,可以基于该第一事故数据的数据内容,来确定本次事故的其他事故参与方用户;例如,可以基于事故数据中携带的其他事故参与方的车辆身份信息中的用户身份信息,来明确其他事故参与方用户的身份。然后,可以获取区块链中存储的由该其他事故参与方用户发布的第二事故数据;
进一步的,在获取到区块链中存储的事故参与方用户发布的事故数据之后,可以继续验证上述第一事故数据和上述第二事故数据是否匹配;
例如,可以验证上述第一事故数据和上述第二事故数据中分别包含的事故参与方用户是否匹配、验证上述第一事故数据和上述第二事故数据中分别包含的上述取证数据中的事故发生的时刻、事故发生的地点、与事故现场相关的图像数据是否匹配,等等。
当经过验证确认上述第一事故数据和上述第二事故数据完全匹配,此时可以证明本次事故为真实的事故,可以进一步对该事故参与方用户进行车祸理赔处理。
其中,对该事故参与方用户进行车祸理赔处理的具体步骤,在本说明书中不再进行详述;
例如,以上述客户端是一款面向驾驶者提供服务的名为“驾驶员钱包”APP为例,理赔机构可以基于事故参与方用户的车辆投保金额,向事故参与方用户的“钱包账户”进行理赔转账处理即可。
在示出的一种实施方式中,当理赔机构在对事故参与方用户进行车祸理赔处理完成后,还可以生成与该事故参与方用户对应的车祸理赔记录,然后将该车祸理赔记录发布至区块链进行存证,以在区块链上形成该用户的车祸理赔记录,从而使得所有接入区块链的理赔机构,都可以获取到该用户的车祸理赔记录,对该用户定制理赔策略。
在示出的一种实施方式中,理赔机构也可以将事故参与方用户的理赔处理逻辑开发成用于进行事故理赔的智能合约,然后将该智能合约部署到区块链上。
其中,该该用于进行事故理赔的智能合约中声明的合约代码对应的代码执行逻辑,与以上描述的由理赔机构进行理赔处理的过程对应,可以包括用于对所有事故参与方用户发布的事故数据进行验证的验证逻辑,和事故理赔逻辑;用户在发生事故后,可以通过客户端调用该智能合约,来自主的完成理赔处理,而不需要理赔机构进行干预。
在这种情况下,客户端可以响应事故参与方用户发起的针对所述事故事件的事故理赔操作,构建一笔用于发起事故理赔的第二交易,并将该第二交易发布至所述区块链;
例如,在实现时,可以在客户端的界面中可以面向用户提供发起事故理赔的操作入口(比如按钮),使得该用户可以通过触发该操作入口,快捷的发起事故理赔;而客户端可以响应于用户针对该操作入口的触发操作,来触发构建上述第二交易,并将该第二交易发布至区块链。
而区块链中的节点设备在收到该第二交易后,可以响应该第二交易,获取区块链中存储的由该事故参与方用户发布的第一事故数据,基于该第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据,再验证该第一事故数据与所述第二事故数据是否匹配;当二者匹配时,可以进一步调用上述智能合约中的车祸理赔逻辑,对该事故参与方用户进行车祸理赔处理,具体的过程不再赘述。
上述智能合约在完成对该事故参与方用户的车祸理赔处理后,可以将车祸理赔处理结果,存储至区块链的分布式账本;而对于理赔机构来说,则可以通过监听上述智能合约的执行结果,来获取对上述事故参与方用户的理赔结果。
例如,在实现时,智能合约的执行结果通常是以交易执行日志(Log)的形式,存储到MPT收据树中;或者,也可以以Key-Value对的形式存储到智能合约的Storage树中。因此,理赔机构可以通过监听到MPT收据树或者智能合约的Storage树,来获取上述事故参与方用户的理赔结果。
在本说明中,对于上述智能合约生成的上述事故事件,还可以由智能合约维护一个对应的状态机,来标明其状态。例如,在实现时,对于上述智能合约生成的上述事故事件,在初始状态下,可以由智能合约将其标记为未理赔状态;当用户通过客户端调用智能合约,完成了针对该事故事件的理赔处理后,可以将其更新为已理赔状态。在这种情况下,无论是用户的客户端还是理赔机构的服务器,都可以通过监听的方式,及时了解到事故事件的最新状态,进而可以依据该事故事件的最新状态,向用户或者理赔机构的工作人员,发送相应的状态提示消息。
在以上技术方案中,一方面,由于用户可以通过客户端访问在区块链中存储的数据,快捷的与其他事故参与方用户交换各自的车辆投保详情数据,对其他事故参与方用户的车辆身份数据和车辆投保详情数据进行相互验证确认,并在对其他事故参与方用户的车辆身份数据和车辆投保详情数据进行确认后,可以通过客户端将所有事故参与方用户的车辆身份信息和与事故现场相关的取证数据作为用于交通事故理赔的事故数据自主的上报到区块链进行存证,而不再需要交通管理部门的工作人员进行事故处理,因此可以降低交通管理部门的工作负担,提高事故上报理赔的处理效率;
另一方面,由于理赔机构在针对事故参与方用户进行事故理赔时,可以将区块链中存储的由该用户和其他事故参与方用户发布的事故数据进行匹配,来对本次的事故进行真实性验证,从而可以避免用户单方面向区块链发布虚假事故数据来骗取理赔的行为,提升事故理赔的安全性。
与上述方法实施例相对应,本申请还提供了装置的实施例。
与上述方法实施例相对应,本说明书还提供了一种基于区块链的交通事故处理装置的实施例。
本说明书的基于区块链的交通事故处理装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,如图5所示,为本说明书的基于区块链的交通事故处理装置所在电子设备的一种硬件结构图,除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的电子设备通常根据该电子设备的实际功能,还可以包括其他硬件,对此不再赘述。
图6是本说明书一示例性实施例示出的一种基于区块链的交通事故处理装置的框图。
请参考图6,所述基于区块链的交通事故处理装置60可以应用在前述图5所示的电子设备中,其中所述区块链存储了车辆身份信息和车辆投保详情数据的对应关系;所述装置60包括:
第一获取模块601,响应于事故参与方用户的操作,获取与事故相关的其他事故参与方用户的车辆身份信息,并查询所述区块链中存储的与所述车辆身份信息对应的车辆投保详情数据;
输出模块602,将所述车辆身份信息和所述车辆投保详情数据通过界面向事故参与方用户进行输出显示;
存证模块603,响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,将获取到的事故数据发布至所述区块链进行存证;其中,所述事故数据用于交通事故理赔;所述事故数据包括与所述事故相关的事故参与方用户的车辆身份信息以及与事故现场相关的取证数据的对应关系。
在本说明书中,所述第一获取模块601:
响应于事故参与方用户的图像扫描操作,针对与事故相关的其他事故参与方用户的客户端上输出的基于所述车辆身份信息生成的图形编码进行编码识别,以获取其他事故参与方用户的车辆身份信息。
在本说明书中,所述图形编码包括二维码。
在本说明书中,所述区块链中部署了用于进行事故管理的智能合约;
所述存证模块603:
响应于所述事故参与方用户对所述车辆身份信息和所述车辆投保详情数据的确认操作,构建用于发起事故上报的第一交易;其中,所述第一交易包括所述与事故现场相关的事故数据;
将所述第一交易发布至所述区块链,以使所述区块链中的节点设备响应于所述第一交易,调用所述智能合约中的校验逻辑,针对所述事故数据进行合法性校验;
如果针对所述事故数据合法性校验通过,进一步调用所述智能合约中的事件生成逻辑,生成与所述事故数据对应的事故事件,并将所述事故事件和所述事故数据关联存储至所述区块链的分布式账本。
在本说明书中,还包括:
第一监听模块604(图6中未示出),监听所述智能合约生成的事故事件;响应于监听到的所述事故事件,向所述事故参与方用户输出与所述事故事件对应的提示信息,以提示所述事故参与方用户对所述事故事件发起理赔处理。
在本说明书中,所述区块链中部署了用于进行事故理赔的智能合约;
所述装置60还包括:
第一理赔模块605(图6中未示出),响应于事故参与方用户发起的针对所述事故事件的事故理赔操作,构建用于发起事故理赔的第二交易;将所述第二交易发布至所述区块链,以使所述区块链中的节点设备响应于所述第二交易,调用所述智能合约中的验证逻辑,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,以及由所述第一事故数据中的其他事故参与方用户发布的第二事故数据,并验证所述第一事故数据与所述第二事故数据是否匹配;如果是,进一步调用所述智能合约中的车祸理赔逻辑,对所述事故参与方用户进行车祸理赔处理。
图7是本说明书一示例性实施例示出的一种基于区块链的交通事故处理装置的框图。
请参考图7,所述基于区块链的交通事故处理装置70可以应用在前述图5所示的电子设备中,其中,所述区块链存储了由事故参与方用户发布的事故数据;所述事故数据包括与事故相关的事故参与方用户的车辆身份信息和与事故现场相关的取证数据的对应关系;所述装置70包括:
第二获取模块701,响应于针对事故参与方用户的事故理赔,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据;基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据;
验证模块702,验证所述第一事故数据与所述第二事故数据是否匹配;
第二理赔模块703,如果是,对所述事故参与方用户进行车祸理赔处理。
在本说明书中,所述服务设备为所述区块链中的节点设备;所述区块链中部署了用于进行事故管理的智能合约;
所述装置70还包括:
生成模块704(图7中未示出),接收客户端发送的用于发起事故上报的第一交易;所述第一交易包括所述与事故现场相关的事故数据;响应于所述第一交易,调用所述智能合约中的校验逻辑,针对所述事故数据进行合法性校验;如果针对所述事故数据合法性校验通过,进一步调用所述智能合约中的事件生成逻辑,创建与所述事故数据对应的事故事件,并将所述事故对象和所述事故数据关联存储至所述区块链的分布式账本。
在本说明书中,所述装置70还包括:
第二监听模块705(图7中未示出),监听所述智能合约生成的事故事件;响应于监听到的所述事故事件,向理赔机构发送与所述事故事件对应的提示信息,以提示理赔机构对所述事故事件进行理赔处理。
在本说明书中,所述区块链中部署了用于进行事故理赔的智能合约;
所述验证模块702:
接收所述事故参与方用户通过客户端发送的用于发起事故理赔的第二交易;
响应于所述第二交易,调用所述智能合约中的验证逻辑,获取所述区块链中存储的由所述事故参与方用户发布的第一事故数据,基于所述第一事故数据确定其他事故参与方用户,并获取所述区块链中存储的由所述其他事故参与方用户发布的第二事故数据,验证所述第一事故数据与所述第二事故数据是否匹配;
所述第二理赔模块703:
如果是,进一步调用所述智能合约中的车祸理赔逻辑,对所述事故参与方用户进行车祸理赔处理。
在本说明书中,所述第二理赔模块703进一步:
在对所述事故参与方用户进行车祸理赔处理完成后,将针对所述事故参与方用户的车祸理赔记录发布至所述区块链进行存证。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。