CN113570479B - 一种房产交易数据的区块链传输方法、系统及存储介质 - Google Patents

Abstract

本申请公开了一种房产交易数据的区块链传输方法、系统及存储介质，包括：获取房产交易业务系统产生的交易原始数据；将交易原始数据上传至第一区块链，通过第一中继服务节点和第二中继服务节点，将第一区块链上的交易原始数据跨链同步给第二区块链。应用本申请实施类方案，由于采用了区块链以及跨链技术，利用区块链可溯性以及不可篡改的特性，增加交易原始数据的安全性。

Description

一种房产交易数据的区块链传输方法、系统及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种房产交易数据的区块链传输方法、一种房产交易数据的区块链传输系统、一种及存储介质、一种电子设备和一种计算机程序产品。

背景技术

随着互联网的发展，各行各业可以通过网络平台进行交易，并由此带来极大的便利。在房产交易市场，买卖双方同样可以通过网络交易。但由于房产交易金额较大，交易环节比较多，需要一种更为可靠的方法保证房产交易各个环节所产生的数据的安全。

发明内容

针对上述现有技术，本申请实施例公开一种房产交易数据的区块链传输方法，可以克服数据不安全的缺陷，达到数据安全的目的。

鉴于此，本申请实施例提出一种房产交易数据的区块链传输方法，该方法包括：

获取房产交易业务系统产生的交易原始数据；

将所述交易原始数据上传至第一区块链，所述第一区块链为所述房产交易业务系统一侧的原区块链；

通过第一中继服务节点和第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链，所述第一中继服务节点为所述第一区块链一侧的中继服务节点，所述第二中继服务节点为所述第二区块链一侧的中继服务节点，所述第二区块链为远端目标区块链。

进一步地，

所述获取房产交易业务系统产生的交易原始数据的步骤包括：

监听所述房产交易业务系统中的业务完成通知消息，所述业务完成通知消息是所述房产交易业务系统在每个业务环节结束时产生的消息，所述每个业务环节在结束时还产生属于该环节的交易原始数据并保存于所述房产交易业务系统中的数据存储中心；

根据所述业务完成通知消息中的索引KEY值，从所述房产交易业务系统中的数据存储中心获取所述交易原始数据；

将获取的所述交易原始数据保存在分布式面向列的数据库中；

为所述交易原始数据设置对应的上链情况信息，将所述上链情况信息保存在关系型数据库中，所述上链情况信息是用于表示所述交易原始数据的上链情况的信息，包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。

进一步地，

所述将交易原始数据上传至第一区块链的步骤包括：

从所述关系型数据库中获取所述交易原始数据对应的上链情况信息，根据所述上链情况信息中的原始数据标识从所述分布式面向列的数据库中获取对应的交易原始数据；

对获取的交易原始数据进行结构化处理，使其符合所述第一区块链的智能合约支持的数据模式；

调用所述第一区块链的智能合约，将结构化处理后的交易原始数据上传到所述第一区块链，并在上链完成时获得区块ID、交易ID和上链时间；将上链完成获得的区块ID、交易ID和上链时间分别作为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间；

更新所述关系型数据库中的上链情况信息，将所述上链情况信息中的第一区块ID更新为所述获得的第一区块ID，将所述上链情况信息中的第一交易ID更新为所述获得的第一交易ID，将上链情况信息中的第一上链状态更新为已上链，将上链情况信息中的第一上链时间更新为所述获得的第一上链时间。

进一步地，

所述通过第一中继服务节点和第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链的步骤包括：

所述第一区块链向所述第一中继服务节点发送跨链请求，所述跨链请求携带有所述结构化处理后的交易原始数据、所述第一区块ID和所述第一交易ID；

所述第一中继服务节点解析所述跨链请求，将解析后获得的所述结构化处理后的交易原始数据、所述第一区块ID和所述第一交易ID发送给所述第二中继服务节点；

所述第二中继服务节点调用所述第一区块链的智能合约，验证接收到的所述结构化处理后的交易原始数据、所述第一区块ID、所述第一交易ID与所述第一区块链上所保存相应数据的一致性；

在验证通过后，所述第二中继服务节点调用所述第二区块链的智能合约，将接收到的所述结构化处理后的交易原始数据同步给所述第二区块链；

所述第二区块链在保存所述结构化处理后的交易原始数据后生成第二区块ID和第二交易ID，并将所述第二区块ID和所述第二交易ID返回给所述第一中继服务节点；

所述第一中继服务节点调用所述第二区块链的智能合约，验证所述结构化处理后的交易原始数据、所述第二区块ID、所述第二交易ID与所述第二区块链上所保存的相应数据的一致性，并在验证通过后完成跨链传输。

进一步地，

所述获取房产交易业务系统产生的交易原始数据的步骤之前，该方法进一步包括：

所述房产交易业务系统中的上下游签约系统执行自身各业务环节，并在自身各业务环节产生所述交易原始数据；所述上下游签约系统为签约前和签约后涉及的业务系统；

所述房产交易业务系统中的电子签平台系统执行电子合同签署，并在完成电子合同签署时产生所述交易原始数据。

进一步地，

所述房产交易业务系统包括SAAS能力模块、签约通用能力模块和基础功能模块；所述房产交易业务系统中的电子签平台系统执行电子合同签署的步骤包括：

所述签约通用能力模块调用基础功能模块，由基础功能模块执行实名认证过程；

所述签约通用能力模块生成待签署的房产交易合同文件，通过所述SAAS能力模块展示所述待签署的房产交易合同文件，以完成客户签名和意愿认证过程；

所述签约通用能力模块将所述房产交易合同文件发送给所述基础功能模块；

所述基础功能模块通过签署通道获得数字证书，并根据所述数字证书生成电子签署的房产交易合同文件；

所述基础功能模块将所述电子签署的房产交易合同文件返回给所述签约通用能力模块保存。

本申请实施例还提供一种房产交易数据的区块链传输系统，可以达到交易数据安全可靠的目的，该系统包括房产交易业务系统、交易证据保全系统、第一区块链、第二区块链、第一中继服务节点、第二中继服务节点；

所述房产交易业务系统，用于执行房产交易业务并产生交易原始数据；

所述交易证据保全系统，用于从所述房产交易业务系统获取所述交易原始数据；将所述交易原始数据上传至第一区块链，所述第一区块链为所述房产交易业务系统一侧的原区块链；

通过所述第一中继服务节点和所述第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链，所述第一中继服务节点为所述第一区块链一侧的中继服务节点，所述第二中继服务节点为所述第二区块链一侧的中继服务节点，所述第二区块链为远端目标区块链。

进一步地，

所述交易证据保全系统获取房产交易业务系统产生的交易原始数据的步骤，包括：监听所述房产交易业务系统中的业务完成通知消息，所述业务完成通知消息为所述房产交易业务系统在每个业务环节结束时产生的消息，所述每个业务环节在结束时还产生属于该环节的交易原始数据并保存于所述房产交易业务系统中的数据存储中心；根据所述业务完成通知消息中的索引KEY值，从所述数据存储中心获取对应的交易原始数据；将获取的所述交易原始数据保存在分布式面向列的数据库中；为所述交易原始数据设置对应的上链情况信息，将所述上链情况信息保存在关系型数据库中，所述上链情况信息为用于表示所述交易原始数据的上链情况的信息，包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。

进一步地，

所述交易证据保全系统将所述交易原始数据上传至第一区块链的步骤，包括：从所述关系型数据库中获取所述交易原始数据对应的上链情况信息，根据所述上链情况信息中的原始数据标识从所述分布式面向列的数据库中获取对应的交易原始数据；对获取的交易原始数据进行结构化处理，使其符合所述第一区块链的智能合约支持的数据模式；调用所述第一区块链的智能合约，将结构化处理后的交易原始数据上传到所述第一区块链，并在上链完成时获得区块ID、交易ID和上链时间；将上链完成获得的区块ID、交易ID和上链时间分别作为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间；更新所述关系型数据库中的上链情况信息，将所述上链情况信息中的第一区块ID更新为所述获得的第一区块ID，将所述上链情况信息中的第一交易ID更新为所述获得的第一交易ID，将所述上链情况信息中的第一上链状态更新为已上链，将所述上链情况信息中的第一上链时间更新为所述获得的第一上链时间。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现上述任一项所述的房产交易数据的区块链传输方法的步骤。

本申请实施例还提供一种电子设备，该电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述的房产交易数据的区块链传输方法。

本申请实施例还提供一种计算机程序产品，包括计算机指令，所述计算机指令在被处理器执行时实施如上述任一项所述的方法。

综上所述，本申请实施例将房产交易业务系统产生的交易原始数据上传给自身一侧的第一区块链，再跨链传输给第二区块链，利用区块链可溯性以及不可篡改的特性，增加交易原始数据的安全性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实现房产交易数据的区块链传输方法实施例一的流程图。

图2是本申请实现房产交易数据的区块链传输方法实施例二的流程图。

图3是本申请实施例三中电子签平台系统在完成电子合同签署时产生交易原始数据的方法流程图。

图4是本申请实施例三中以合同保存后产生的交易原始数据为例进行区块链传输的方法流程图。

图5是本申请实施例三中将原始交易数据从第一区块链跨链传输到联盟链的消息流示意图。

图6本申请实现房产交易数据的区块链传输系统结构示意图。

图7是本申请实施例中的电子设备示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

针对房产交易各个环节所产生的交易数据的安全性问题，本申请实施例将交易原始数据上传到区块链，并跨链传输到远端目标区块链上，利用区块链上的数据可回溯、不可篡改的特点，保证房产交易各个环节所产生数据的安全。

图1是本申请实现房产交易数据的区块链传输方法实施例一的流程图。如图1所示，该方法包括：

步骤101：获取房产交易业务系统产生的交易原始数据。

实际应用中，房产交易业务系统比较庞大，交易流程和环节很多。为了保证交易的安全，需要先获取房产业务系统中各个环节产生的数据。比如：房产交易业务系统包括签约上下游系统和电子签平台系统，其中签约上下游系统是签约前和签约后涉及到的业务系统，电子签平台系统是签约过程中涉及到的系统。比如签约上下游系统还可以进一步包括房源委托上架、客户带看过程、费用支付、交易备件材料上传等环节，电子签平台系统包括电子合同签署的环节。上述各个环节都会产生与交易相关的原始数据。不管是哪个环节产生的数据，也不管数据是哪种类型，本申请实施例中统一称为“交易原始数据”。

步骤102：将所述交易原始数据上传至第一区块链，所述第一区块链为所述房产交易业务系统一侧的原区块链。

本申请实施例在房产交易业务系统一侧设置了区块链，便于交易原始数据上链操作。为了与后续其他区块链区分，这里称为“第一区块链”。不管是第一区块链，还是后续的第二区块链，都属于区块链。区块链实际上是一种分布式、去中心化的网络数据库系统，所有的交易都由网络的全部节点参与确认和维护，通过共识机制来保证交易与信息的安全和有效性。

步骤103：通过第一中继服务节点和第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链，所述第一中继服务节点为所述第一区块链一侧的中继服务，所述第二中继服务节点为所述第二区块链一侧的中继服务，所述第二区块链为远端目标区块链。

在实际应用中，为了增加区块链数据的公信力，可以在公证处、法院等权威组织部署节点，采用Raft共识机制，将多个节点联盟组网，构成“联盟链”，即上述的第二区块链。如果将房产交易业务系统中产生的交易原始数据传输给联盟路，可以大大增加交易原始数据的可信度。为了区分房产交易业务系统一侧的区块链和联盟链，本申请实施例将房产交易业务系统一侧的区块链称为第一区块链，将远端的联盟链称为第二区块链，而交易原始数据则需要从第一区块链跨链传输给第二区块链。为了不影响第一区块链和第二区块链自身已有的功能实施，尽量少地对第一区块链和第二区块链的更改，本申请实施例在第一区块链和第二区块链之间设置第一中继服务节点和第二中继服务节点，由第一中继服务节点和第二中继服务节点负责数据的验证和转发，从而达到交易原始数据跨链传输的目的。

为了更好地描述本申请方案，下面再用其他较佳实施例进行详细描述。

在本申请方法实施例二中，假设房产交易业务系统中，各个业务环节完成时会产生业务完成通知消息，业务完成通知消息可以包括索引KEY值和上链标识等信息。本申请实施例还假设包括分布式面向列的数据库和关系型数据库，其中分布式面向列的数据库可以为Hbase数据库，关系型数据库可以为MYSQL数据库。

图2是本申请实现房产交易数据的区块链传输方法实施例二的流程图。如图2所示，该方法包括：

步骤201：监听房产交易业务系统中的业务完成通知消息，所述业务完成通知消息是房产交易业务系统在每个业务环节结束时产生的消息，每个业务环节在结束时还产生属于该环节的交易原始数据并保存于房产交易业务系统中的数据存储中心。

如上所述，房产交易业务系统会在某个交易环节结束时产生业务完成通知消息，并将该环节生成的交易原始数据保存在数据存储中心。此时，可以从房产交易业务系统中监听到该业务完成通知消息。比如，房产交易业务系统在完成房源委托上架的环节后，会产生针对房源委托环节的业务完成通知消息A，并将生成的例如城市名称、业务姓名、房源的楼盘、委托录入时间、房源实勘图和户型图等房源委托过程中产生的数据保存在数据存储中心，这些数据即为交易原始数据。再比如，房产交易业务系统在完成对客户的实名认证之后，会产生针对实名认证业务环节的业务完成通知消息B，并将生成的例如客户姓名、身份证号、手机号、银行卡号等实名认证过程中产生的数据保存在数据存储中心，这些数据也为交易原始数据。

这里所述的数据存储中心是用于存储交易原始数据的地方，可以根据实际情况设置一个或者若干个，在此不作限制。

步骤202：根据所述业务完成通知消息中的索引KEY值，从所述房产交易业务系统中的数据存储中心获取所述交易原始数据。

为了准确地获得交易原始数据，在数据存储中心可以利用索引KEY值进行标识。如果有若干个数据存储中心，也可以在业务完成通知消息中携带相应的标识，根据业务完成通知消息中的标识就可以确定到哪一个数据存储中心获取交易原始数据。另外，房产交易业务系统产生的业务完成通知消息还可能提供给其他业务系统利用，这些业务完成通知消息涉及到的数据并非是需要上链的交易原始数据，因此可以先进行过滤。如果是不需要上链的交易原始数据对应的业务完成通知消息，则直接丢弃。如果是需要上链的交易原始数据对应的业务完成通知消息，才继续执行后续步骤。为了达到过滤的目的，在实际应用中，可以在业务完成通知消息中设置上链标识，利用上链标识来识别涉及到的交易原始数据是否需要上链。

步骤203：将获取的交易原始数据保存在分布式面向列的数据库中。

为了便于上链操作，可以先将需要上链的交易原始数据从房产交易业务系统内的数据存储中心取出，保存在Hbase数据库中。Hbase数据库是一种分布式面向列的存储系统，适合实时读写、随机访问的超大规模数据集。本申请实施例中的交易原始数据的数据量很大，数据类型复杂，如果采用分布式面向列的存储系统，则可以从中快速获取，可以加快上链操作的速度。

步骤204：为交易原始数据设置对应的上链情况信息，将所述上链情况信息保存在关系型数据库中，所述上链情况信息是用于表示交易原始数据的上链情况的信息，包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。

上述步骤203已经将交易原始数据保存在Hbase这类分布式面向列的存储系统中了。在实际应用中，还需要对交易原始数据的上链情况进行管理。为了有效地管理，本申请实施例为交易原始数据设置了对应的上链情况信息，包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。在交易原始数据保存在Hbase数据库且还未上链时，可以对相应的上链情况信息进行初始化，其中，第一区域ID、第一交易ID和第一上链时间设置为“空”，原始数据标识根据实际情况设置，只要能够标识即可，第一上链状态设置为“未上链”。第一区块ID和第一交易ID是用于标识交易原始数据存储在第一区块链上的位置。由于还未上链，因此此处的第一区块ID、第一交易ID和第一上链时间均为“空”。由于上链情况信息比较简单，在本申请实施例中利用关系型数据库即可。本申请实施例将交易原始数据保存在Hbase数据库，而将上链情况信息保存在MYSQL数据库，实现分离保存管理，可以分别利用两种不同数据库的优势特点，提高系统的工作效率。另外，由于将交易原始数据保存在分布式面向列的数据库中，只能进行存储和查阅，不进行任何修改，也可以防止交易原始数据被修改或者删除的风险，更好保证数据的安全性。

上述步骤201～步骤204是本申请实施例获取房产业务系统产生的交易原始数据的过程。也就是说，通过监听业务完成通知消息，从房产交易业务系统中数据存储中心获取交易原始数据，并重新保存在分布式面向列的Hbase数据库中。实际应用中，步骤201～步骤204可以根据实际情况串行或并行多次循环执行。当需要上传区块链时才执行后续的步骤。

步骤205：从关系型数据库中获取交易原始数据对应的上链情况信息，根据上链情况信息中的原始数据标识从分布式面向列的数据库中获取对应的交易原始数据。

实际应用中，可以定时从关系型数据库MYSQL中获取上链情况信息。当然，这里获取的上链情况信息是还未上链的交易原始数据所对应的上链情况信息，并根据原始数据标识快速地从Hbase数据库中获取对应的交易原始数据，以准备上链操作。

步骤206：对获取的交易原始数据进行结构化处理，使其符合所述第一区块链的智能合约支持的数据模式。

步骤207：调用所述第一区块链的智能合约，将结构化处理后的交易原始数据上传到所述第一区块链，并在上链完成时获得区块ID、交易ID和上链时间；将上链完成获得的区块ID、交易ID和上链时间分别作为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间。

上述步骤206和步骤207是具体的上链操作。交易原始数据无法按照原有结构直接上链，需要进行结构化处理之后调用智能合约才能完成上链操作。智能合约是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。上链之后，智能合约会返回所保存交易原始数据的信息，比如区块ID、交易ID和上链时间等信息。为了与后续其他区块链的智能合约，这里的智能合约为第一区块链的智能合约。相应地，为了与后续其他区块ID、交易ID和上链时间区分，这里为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间。

另外，本步骤是在需要上传结构化处理后的交易原始数据时，调用了第一区块链的智能合约。实际应用中，如果需要执行其他的操作，比如后续涉及到的验证、同步等操作，也需要调用智能合约才能实现。

步骤208：更新关系型数据库中的上链情况信息，将所述上链情况信息中的第一区块ID更新为获得的第一区块ID，将所述上链情况信息中的第一交易ID更新为所述获得的第一交易ID，将上链情况信息中的第一上链状态更新为已上链，将所述上链情况信息中的第一上链时间更新为所述获得的第一上链时间。

上述步骤205～步骤208是本申请实施例将交易原始数据上传至第一区块链的过程。虽然交易原始数据已经上链，但仍然处于房产交易业务系统一侧的私有链中。为了增加数据的公信力，本申请实施例还利用后续步骤对其进行跨链传输，比如传输给远端的联盟链，即第二区块链。

步骤209：第一区块链向第一中继服务节点发送跨链请求，所述跨链请求携带有结构化处理后的交易原始数据、第一区块ID和第一交易ID。

步骤210：第一中继服务节点解析所述跨链请求，将解析后获得的结构化处理后的交易原始数据、第一区块ID和第一交易ID一并打包转发给第二中继服务节点。

步骤211：第二中继服务节点调用第一区块链的智能合约，验证接收到的结构化处理后的交易原始数据、第一区块ID、第一交易ID与第一区块链上所保存相应数据的一致性。

这里，第二中继服务节点已经获得结构化处理后的交易原始数据、第一区块ID和第一交易ID，为了保证传输的正确性，还需要与第一区块链上保存的相应数据进行对比，以验证其数据的一致性。另外，如前所述，本步骤在执行验证操作时，需要调用第一区块链的智能合约来实现的。

步骤212：在验证通过后，第二中继服务节点调用第二区块链的智能合约，将接收到的结构化处理后的交易原始数据同步给第二区块链。

实际应用中，如果验证未通过，第二中继服务节点可以向第一区块链返回验证失败的信息。这里的是智能合约是第二区块链的智能合约。与第一区块链的智能合约相同，这里的智能合约也是一种旨在以信息化方式传播、验证或执行合同的计算机协议，在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。如前所述，本步骤在执行同步操作时，需要调用第二区块链的智能合约来实现。

步骤213：第二区块链在保存结构化处理后的交易原始数据后生成第二区块ID和第二交易ID，并将第二区块ID和第二交易ID返回给第一中继服务节点。

步骤214：第一中继服务节点调用第二区块链智能合约，验证结构化处理后的交易原始数据、第二区块ID、第二交易ID与第二区块链上所保存的相应数据的一致性，并在验证通过后完成跨链传输。

一方面，第一中继服务节点在步骤209已经获得了结构化处理后的交易原始数据，另一方面，第一中继服务节点在验证时，可以通过第二区块ID和第二交易ID从第二区块链中获取保存的结构化处理后的交易原始数据，从而不但可以验证获得的第二区块ID、第二交易ID是否与第二区块链中的一致性，还可以验证结构化处理后的交易原始数据是否与第二区块链中的一致性。另外，如上所述，本步骤需要调用第二区块链的智能合约来执行验证操作。

上述步骤209～步骤214是本申请实施例将第一区块链上的交易原始数据跨链同步给第二区块链的过程。其中，第一中继服务节点的节点部署在第一区块链一侧，第二中继服务节点的节点部署在第二区块链一侧，第一中继服务节点和第二中继服务节点二者之间通过远距离传输。由于部署了第一中继服务节点和第二中继服务节点，即使第一区块链和第二区块链的处理方式或数据结构要求不同，也无需对自身进行大量改动，只需要利用第一中继服务节点和第二中继服务节点进行适配处理即可，从而更好地将房产交易业务系统一侧的区块链和远端的联盟链进行链接，不但增强交易原始数据的安全性、可靠性，也增强其公信力。

在方法实施例三中，假设房产交易业务系统中包括上下游签约系统和电子签平台系统。其中，上下游签约系统是签约前和签约后涉及的业务系统，可以包括房源系统、带看系统、支付系统和交易备件管理系统等，电子签平台系统包括基础功能模块、签约通用能力模块和SAAS(Software-as-a-Service，软件即服务)能力模块共三层。房源系统是对房源进行管理的系统，带看系统是带领客户参观房源的管理系统，支付系统是客户交易中支付费用的管理系统，交易备件管理系统是对交易所需材料文件的管理系统。电子签平台系统主要用于生成交易合同并完成电子签署的管理系统。其中，基础功能模块负责与有认证能力的对象连接，并提供底层的电子签署通道。签约通用能力模块负责为业务提供合同签署服务以及对合同进行管理。SAAS能力模块面向客户提供业务场景下的签署应用服务。另外，本申请实施例中还包括交易证据保全系统，主要负责监听业务完成通知消息，以及将产生的交易原始数据进行上链操作。

本申请实施例中，上下游签约系统在自身各个业务环节结束时可以产生交易原始数据，电子签平台系统在完成电子合同签署时也可以产生交易原始数据。各种交易原始数据如表一所示：

表一

本申请实施例中，假设房源系统中有N个房源信息，某业务员小A带领某客户小B实地看了M处房源，客户小B对某个房源L有交易意向。此时，假设房源系统的房源委托上架环节涉及的交易原始数据已经上链，带看系统中客户带看过程环节涉及的交易原始数据也已经上链。如果客户小B有交易意向，上下游签约系统会触发电子签平台系统进行电子合同的签署。

图3是本申请实施例三中电子签平台系统在完成电子合同签署时产生交易原始数据的方法流程图。如图3所示，该方法包括：

步骤301：签约通用能力模块调用基础功能模块，由基础功能模块执行实名认证过程。

如上所述，基础功能模块负责与有认证能力的对象连接，因此可以由基础功能模块执行实名认证。实名认证可以分别针对二元信息、三元信息或四元信息进行认证。二元信息包括客户姓名和身份证号，二元信息的依据可以来自公安部的数据源。三元信息包括客户姓名、身份证号和手机号，三元信息的依据可以来自运营商的数据源。四元信息包括客户姓名、身份证号、手机号和银行卡号，四元信息的依据可以来自银行系统的数据源。不管是二元信息、三元信息还是四元信息，本实施例中的基础功能模块都可以与权威认证机构连接，完成实名认证过程。在完成实名认证后，实名认证中的二元信息、三元信息或四元信息为交易原始数据

步骤302：签约通用能力模块生成待签署的房产交易合同文件，通过所述SAAS能力模块展示所述待签署的房产交易合同文件，以完成客户签名和意愿认证过程。

实际应用中，签约通用能力模块中可以事先设置合同模板，当录入与合同签署相关的数据参数比如客户姓名、房源地址、房价等等，就可以将录入的数据参数与合同模板合并生成一份实际的PDF合同文件。实际应用中，线下的纸质版的合同文件需要客户手写签名或签章才能生效。为了模拟该环节，本步骤生成的PDF合同文件可以通过SAAS能力模块展示给客户，完成客户签名。如上所述，SAAS能力模块是面向客户提供的签署应用服务，在实际应用中可以通过H5、WEB、SDK等多种形式提供给业务应用方，供业务应用方在业务场景下完成客户签名，并采用短信验证和活体确认等形式完成意愿认证过程。这里的客户签名可以是在客户授权的情况下对PDF合同文件自动签名或盖章，也可以是在客户阅读完PDF合同文件之后，通过回填发送到自己手机号上的短信验证码，或者扫脸确认后对合同完成手动签名。实际应用中，这里的客户签名可以针对单个文档的签署，也可以针对多个文档的签署，此处不作限制。意愿认证过程表示客户签名的有效性，以确保房产交易合同的法律效力。

步骤303：签约通用能力模块将房产交易合同文件发送给基础功能模块。

步骤304：基础功能模块通过签署通道获得数字证书，并根据所述数字证书生成电子签署的房产交易合同文件。

为了加强房产交易合同文件的安全性，本申请实施例还对房产交易合同文件进行电子签署。这里所述的电子签署与步骤302中所述客户签名不同。客户签名是通过SAAS能力模块提供的应用服务实现的，可以通过客户手写或自动生成。而本步骤所述的电子签署是指通过签署通道从认证中心获取数字证书，将数字证书加密到房产交易合同文件中的过程。

实际应用中，签署通道可以为CA(Certificate Authority，认证中心)签署通道或RA(Register Authority，注册中心)签署通道。CA签署通道是连接与具备CA资质的签署能力提供方之间的通道，比如与中国金融认证中心(CFCA)连接，与北京数字证书认证中心(BJCA)连接，与深圳市电子商务安全证书管理有限公司(SZCA)连接。RA签署通道是连接与具有RA资质的签署能力的第三方供应商之间的通道，比如与上上签、法大大或e签宝等连接。实际应用中，可以将其中一种签署作为主要通道另外一种作为备用通道。当主通道发生故障时，可以立即切换至备用通道，防止业务发生中断的现象。

步骤305：基础功能模块将所述电子签署的房产交易合同文件返回给所述签约通用能力模块保存。

至此，电子签平台系统已经对房产交易合同文件完成电子签署。在签署过程中，当步骤301完成实名认证过程，实名认证过程中的二元信息、三元信息或四元信息可以作为交易原始数据。当步骤302完成意愿认证，意愿认证过程中的短信、验证码、活体人脸图片等可以作为交易原始数据。当步骤302中客户完成合同签约时，签约方姓名、身份证/护照号、各签署方的签约盖章时间以及各签署方页面操作记录等可以作为交易原始数据。步骤305中房产交易合同文件经过电子签署进行合同保存时，合同PDF文件、合同文件保存路径、合同保存时间等可以作为交易原始数据。

同样，上述电子签平台系统产生交易原始数据时，也会产生业务完成通知消息。因此，在监听到业务完成通知消息时，可以利用实施例二的方法实现区块链传输，以保证这些交易原始数据的安全性。

需要说明的是，在利用以下步骤实现区块链传输时，并非在完成房产交易合同文件的电子签署之后才实施，只要电子签平台系统中某个业务环节产生了交易原始数据，就可以进行区块链的传输。

本实施例三以合同保存后产生的交易原始数据为例进行区块链传输。图4是该方法的详细描述，如图4所示，该方法包括：

步骤401：签约通用能力模块完成房产交易合同文件的保存后，生成合同PDF文件、合同文件保存路径、合同保存时间，并将其作为交易原始数据。

步骤402：签约通用能力模块产生业务完成通知消息。

步骤403：交易证据保全系统监听到业务完成通知消息，根据业务完成通知消息的索引KEY值，从电子签平台系统的签约通用能力模块中获取合同PDF文件、合同文件保存路径、合同保存时间。

步骤404：交易证据保全系统将获取的合同PDF文件、合同文件保存路径、合同保存时间存储于Hbase数据库中。

步骤405：交易证据保全系统为交易原始数据设置对应的上链情况信息，将设置的上链情况信息保存在MYSQL数据库中，并初始化该上链情况信息，所述上链情况信息包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。

步骤406：交易证据保全系统定时从MYSQL数据库中获取上链情况信息，根据上链情况信息中的原始数据标识从Hbase数据库中获取对应的交易原始数据，即合同PDF文件、合同文件保存路径、合同保存时间。

步骤407：交易证据保全系统将合同PDF文件、合同文件保存路径以及合同保存时间进行结构化处理，使其符合第一区块链的智能合约支持的数据模式。

这里所述的第一区块链就是房产交易业务系统一侧的原区块链。

步骤408：交易证据保全系统调用第一区块链的智能合约，将结构化处理后的交易原始数据上传到第一区块链，并在上链完成时获得区块ID、交易ID和上链时间，将上链完成获得的区块ID、交易ID和上链时间分别作为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间。

步骤409：更新MYSQL数据库中的上链情况信息，将上链情况信息中的第一区块ID更新为上链完成时获得的第一区块ID，将上链情况信息中的第一交易ID更新为上链完成时获得的第一交易ID，将上链情况信息中的第一上链状态更新为已上链，将上链情况信息中的第一上链时间更新为上链完成时获得第一上链时间。

至此，原始交易数据已经上传到第一区块链中。图5是本申请实施例三中将原始交易数据从第一区块链跨链传输到联盟链的消息流示意图，并按照如下的步骤410～步骤415实现。

步骤410：第一区块链向第一中继服务节点发送跨链请求，所述跨链请求携带有结构化处理后的交易原始数据、第一区块ID和第一交易ID。

步骤411：第一中继服务节点解析所述跨链请求，将解析后获得的结构化处理后的交易原始数据、第一区块ID和第一交易ID一并打包转发给第二中继服务节点。

步骤412：第二中继服务节点调用第一区块链的智能合约，验证接收到的结构化处理后的交易原始数据、第一区块ID、第一交易ID与第一区块链上所保存相应数据的一致性。

步骤413：在验证通过后，第二中继服务节点调用联盟链的智能合约，将接收到的结构化处理后的交易原始数据同步给联盟链。

步骤414：联盟链在保存结构化处理后的交易原始数据后生成联盟链区块ID和联盟链交易ID，并将联盟链区块ID和联盟链交易ID返回给第一中继服务节点。

步骤415：第一中继服务节点调用联盟链的智能合约，验证结构化处理后的交易原始数据、联盟链区块ID、联盟链交易ID与联盟链上所保存的相应数据的一致性，并在验证通过后完成跨链传输。

至此，本申请实施例将电子签平台系统产生的合同PDF文件、合同文件保存路径以及合同保存时间上传到第一区块链，并跨链传输给联盟链。由于区块链的可溯性和不可篡改性，联盟链的权威性，使得本实施例中的交易原始数据(合同PDF文件、合同文件保存路径、合同保存时间)更加安全。实际应用中，上链以后的交易原始数据可以采用隐私保护机制，只有签约能力提供方才能查阅交易原始数据的原文，而其他节点只能查看哈希值，无法查阅原文，从而杜绝交易原始数据泄露的风险。另外，本申请实施例是以合同为例描述方案，如果将整个房产交易过程各个环节产生的交易原始数据都上传到区块链并跨链传输给联盟链，那么房产交易的各个环节的交易原始数据将形成有力的证据链。

本申请还提供一种房产交易数据的区块链传输系统。如图6所示，该系统包括房产交易业务系统601、交易证据保全系统602、第一区块链603、第二区块链604、第一中继服务节点605、第二中继服务节点606。

其中，

房产交易业务系统601，用于执行房产交易业务并产生交易原始数据。

实际应用中，房产交易业务系统601可以进一步包括上下游签约系统和电子签平台系统。其中，上下游签约系统包括房源系统、带看系统、支付系统和交易备件管理系统。电子签平台系统包括基础功能模块、签约通用能力模块和SAAS能力模块。

交易证据保全系统602，用于从所述房产交易业务系统601获取所述交易原始数据；将所述交易原始数据上传至第一区块链603，所述第一区块链603为所述房产交易业务系统601一侧的原区块链。

也就是说，房产交易业务系统601执行房产交易业务并产生交易原始数据；交易证据保全系统602从所述房产交易业务系统601获取所述交易原始数据；将所述交易原始数据上传至第一区块链603；第一区块链603通过第一中继服务节点605和第二中继服务节点606，将交易原始数据跨链同步给第二区块链604，所述第一中继服务节点605为第一区块链603一侧的中继服务，所述第二中继服务节点606为第二区块链604一侧的中继服务，第二区块链604为远端目标区块链。

在实际应用中，交易证据保全系统602获取房产交易业务系统产生的交易原始数据时，可以采用本申请方法实施例二中的步骤201～步骤204的方法实现，即：监听房产交易业务系统601中的业务完成通知消息，所述业务完成通知消息为所述房产交易业务系统601在每个业务环节结束时产生的消息，所述每个业务环节在结束时还产生属于该环节的交易原始数据并保存于所述房产交易业务系统601中的数据存储中心；根据所述业务完成通知消息中的索引KEY值，从所述房产交易业务系统601中的数据存储中心获取对应的交易原始数据；将获取的所述交易原始数据保存在分布式面向列的数据库中；为所述交易原始数据设置对应的上链情况信息，将所述上链情况信息保存在关系型数据库中，所述上链情况信息是用于表示所述交易原始数据的上链情况的信息，包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。

交易证据保全系统602将交易原始数据上传至第一区块链时，可以采用本申请方法实施例二中的步骤205～步骤208的方法实现，即：从关系型数据库中获取交易原始数据对应的上链情况信息，根据上链情况信息中的原始数据标识从分布式面向列的数据库中获取对应的交易原始数据；对获取的交易原始数据进行结构化处理，使其符合所述第一区块链603的智能合约支持的数据模式；调用第一区块链603的智能合约，将结构化处理后的交易原始数据上传到第一区块链603，并在上链完成时获得区块ID、交易ID和上链时间；将上链完成获得的区块ID、交易ID和上链时间分别作为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间；更新关系型数据库中的上链情况信息，将所述上链情况信息中的第一区块ID更新为所述获得的第一区块ID，将所述上链情况信息中的第一交易ID更新为所述获得第一交易ID，将所述上链情况信息中的第一上链状态更新为已上链，将所述上链情况信息中的第一上链时间更新为所述获得第一上链时间。

第一区块链603通过第一中继服务节点605和第二中继服务节点606，将交易原始数据跨链同步给第二区块链604的具体的方法可以采用本申请方法实施例二中的步骤209～步骤214，包括：第一区块链603向第一中继服务节点605发送跨链请求，所述跨链请求携带有结构化处理后的交易原始数据、第一区块ID和第一交易ID；第一中继服务节点605解析所述跨链请求，将解析后获得的结构化处理后的交易原始数据、第一区块ID和第一交易ID一并打包转发给第二中继服务节点606；第二中继服务节点606调用第一区块链的智能合约，验证接收到的结构化处理后的交易原始数据、第一区块ID和第一交易ID与第一区块链上保存的一致性；在验证通过后，第二中继服务节点606调用第二区块链的智能合约，将接收到的结构化处理后的交易原始数据同步给第二区块链604；第二区块链604在保存结构化处理后的交易原始数据后生成第二区块ID和第二交易ID，并将第二区块ID和第二交易ID返回给第一中继服务节点605；第一中继服务节点605调用第二区块链604智能合约，验证结构化处理后的交易原始数据、第二区块ID和第二交易ID与第二区块链604上保存的一致性，并在验证通过后完成跨链传输。

另外，房产交易业务系统601中的电子签平台系统将电子签的功能进行了分层管理，包括基础功能模块、签约通用能力模块和SAAS能力模块三个层次。其中，基础功能模块负责与有认证能力的对象连接，并提供底层的电子签署通道。签约通用能力模块负责为业务提供合同签署服务以及对合同进行管理。SAAS能力模块面向客户提供业务场景下的签署应用服务。上述的分层管理可以更好地适应业务变化或者拓展需求。比如，电子签平台系统需要增加一种新的额签署通道，仅需要在基础功能模块中增加新的签署通道即可，不影响其他层次模块的改变，可扩展性强。

本申请实施例还提供一种计算机可读介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时可执行如上所述的房产交易数据的区块链传输方法中的步骤。实际应用中，所述的计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或多个程序被执行时，可以实现上述各实施例描述的房产交易数据的区块链传输方法。根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令在被处理器执行时实施如上述任一实施例所述的方法。

如图7所示，本发明实施例还提供一种电子设备，其中可以集成本申请实施例实现方法的装置。如图7所示，其示出了本发明实施例所涉及的电子设备的结构示意图，具体来讲：

该电子设备可以包括一个或一个以上处理核心的处理器701、一个或一个以上计算机可读存储介质的存储器702以及存储在存储器上并可在处理器上运行的计算机程序。在执行所述存储器702的程序时，可以实现上述房产交易数据的区块链传输方法。

具体的，实际应用中，该电子设备还可以包括电源703、输入单元704、以及输出单元705等部件。本领域技术人员可以理解，图7中示出的电子设备的结构并不构成对该电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器701是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器702内的软件程序和/或模块，以及调用存储在存储器702内的数据，执行服务器的各种功能和处理数据，从而对该电子设备进行整体监控。

存储器702可用于存储软件程序以及模块，即上述计算机可读存储介质。处理器701通过运行存储在存储器702的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器702可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器702可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器1202还可以包括存储器控制器，以提供处理器701对存储器702的访问。

该电子设备还包括给各个部件供电的电源703，可以通过电源管理系统与处理器701逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源703还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该电子设备还可包括输入单元704，该输入单元704可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

该电子设备还可以包括输出单元705，该输出单元705可以用于显示由用户输入的信息或提供给用户的信息以及各种图像用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (9)

1.一种房产交易数据的区块链传输方法，其特征在于，该方法包括：

获取房产交易业务系统产生的交易原始数据；

将所述交易原始数据上传至第一区块链，所述第一区块链为所述房产交易业务系统一侧的原区块链；以及

通过第一中继服务节点和第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链，所述第一中继服务节点为所述第一区块链一侧的中继服务节点，所述第二中继服务节点为所述第二区块链一侧的中继服务节点，所述第二区块链为远端目标区块链；

其中，获取房产交易业务系统产生的交易原始数据，包括：

监听所述房产交易业务系统中的业务完成通知消息，所述业务完成通知消息为所述房产交易业务系统在每个业务环节结束时产生的消息，所述每个业务环节在结束时还产生属于该环节的交易原始数据并保存于所述房产交易业务系统中的数据存储中心；

根据所述业务完成通知消息中的索引KEY值，从所述数据存储中心获取对应的交易原始数据；

将获取的所述交易原始数据保存在分布式面向列的数据库中；以及

为所述交易原始数据设置对应的上链情况信息，将所述上链情况信息保存在关系型数据库中，所述上链情况信息为用于表示所述交易原始数据的上链情况的信息；

其中，在业务完成通知消息中设置上链标识，以利用所述上链标识来识别涉及到的交易原始数据是否需要上链。

2.根据权利要求1所述的方法，其特征在于，所述上链情况信息包括原始数据标识、第一区块ID、第一交易ID、第一上链状态和第一上链时间。

3.根据权利要求2所述的方法，其特征在于，将交易原始数据上传至第一区块链的步骤包括：

从所述关系型数据库中获取所述交易原始数据对应的上链情况信息，根据所述上链情况信息中的原始数据标识从所述分布式面向列的数据库中获取对应的交易原始数据；

对获取的交易原始数据进行结构化处理，使其符合所述第一区块链的智能合约支持的数据模式；

调用所述第一区块链的智能合约，将结构化处理后的交易原始数据上传到所述第一区块链，并在上链完成时获得区块ID、交易ID和上链时间；将上链完成获得的区块ID、交易ID和上链时间分别作为获得的第一区块ID、获得的第一交易ID和获得的第一上链时间；

更新所述关系型数据库中的上链情况信息，将所述上链情况信息中的第一区块ID更新为所述获得的第一区块ID，将所述上链情况信息中的第一交易ID更新为所述获得的第一交易ID，将上链情况信息中的第一上链状态更新为已上链，将所述上链情况信息中的第一上链时间更新为所述获得的第一上链时间。

4.根据权利要求3所述的方法，其特征在于，所述通过第一中继服务节点和第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链的步骤包括：

所述第一区块链向所述第一中继服务节点发送跨链请求，所述跨链请求携带有所述结构化处理后的交易原始数据、所述第一区块ID和所述第一交易ID；

所述第一中继服务节点解析所述跨链请求，将解析后获得的所述结构化处理后的交易原始数据、所述第一区块ID和所述第一交易ID发送给所述第二中继服务节点；

所述第二中继服务节点调用所述第一区块链的智能合约，验证接收到的所述结构化处理后的交易原始数据、所述第一区块ID、所述第一交易ID与所述第一区块链上所保存相应数据的一致性；

在验证通过后，所述第二中继服务节点调用所述第二区块链的智能合约，将接收到的所述结构化处理后的交易原始数据同步给所述第二区块链；

所述第二区块链在保存所述结构化处理后的交易原始数据后生成第二区块ID和第二交易ID，并将所述第二区块ID和所述第二交易ID返回给所述第一中继服务节点；

所述第一中继服务节点调用所述第二区块链的智能合约，验证所述结构化处理后的交易原始数据、所述第二区块ID、所述第二交易ID与所述第二区块链上所保存的相应数据的一致性，并在验证通过后完成跨链传输。

5.根据权利要求1所述的方法，其特征在于，所述获取房产交易业务系统产生的交易原始数据的步骤之前，该方法进一步包括：

所述房产交易业务系统中的上下游签约系统执行自身各业务环节，并在自身各业务环节产生所述交易原始数据；所述上下游签约系统为签约前和签约后涉及的业务系统；

所述房产交易业务系统中的电子签平台系统执行电子合同签署，并在完成电子合同签署时产生所述交易原始数据。

6.根据权利要求5所述的方法，其特征在于，所述房产交易业务系统包括SAAS能力模块、签约通用能力模块和基础功能模块；所述房产交易业务系统中的电子签平台系统执行电子合同签署的步骤包括：

所述签约通用能力模块调用基础功能模块，由基础功能模块执行实名认证过程；

所述签约通用能力模块生成待签署的房产交易合同文件，通过所述SAAS能力模块展示所述待签署的房产交易合同文件，以完成客户签名和意愿认证过程；

所述签约通用能力模块将所述房产交易合同文件发送给所述基础功能模块；

所述基础功能模块通过签署通道获得数字证书，并根据所述数字证书生成电子签署的房产交易合同文件；

所述基础功能模块将所述电子签署的房产交易合同文件返回给所述签约通用能力模块保存。

7.一种房产交易数据的区块链传输系统，其特征在于，该系统包括房产交易业务系统、交易证据保全系统、第一区块链、第二区块链、第一中继服务节点、第二中继服务节点；

所述房产交易业务系统，用于执行房产交易业务并产生交易原始数据；

所述交易证据保全系统，用于从所述房产交易业务系统获取所述交易原始数据；将所述交易原始数据上传至第一区块链，所述第一区块链为所述房产交易业务系统一侧的原区块链；以及

通过所述第一中继服务节点和所述第二中继服务节点，将所述第一区块链上的所述交易原始数据跨链同步给第二区块链，所述第一中继服务节点为所述第一区块链一侧的中继服务节点，所述第二中继服务节点为所述第二区块链一侧的中继服务节点，所述第二区块链为远端目标区块链；

其中，基于以下步骤获取房产交易业务系统产生的交易原始数据：

监听所述房产交易业务系统中的业务完成通知消息，所述业务完成通知消息为所述房产交易业务系统在每个业务环节结束时产生的消息，所述每个业务环节在结束时还产生属于该环节的交易原始数据并保存于所述房产交易业务系统中的数据存储中心；

根据所述业务完成通知消息中的索引KEY值，从所述数据存储中心获取对应的交易原始数据；

将获取的所述交易原始数据保存在分布式面向列的数据库中；以及

为所述交易原始数据设置对应的上链情况信息，将所述上链情况信息保存在关系型数据库中，所述上链情况信息为用于表示所述交易原始数据的上链情况的信息；

其中，在业务完成通知消息中设置上链标识，以利用所述上链标识来识别涉及到的交易原始数据是否需要上链。

8.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时可实现权利要求1至6任一项所述的房产交易数据的区块链传输方法的步骤。

9.一种电子设备，其特征在于，该电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述权利要求1至6任一项所述的房产交易数据的区块链传输方法。