数据传输方法、装置、计算机设备以及存储介质

数据传输方法、装置、计算机设备以及存储介质

　　技术领域

　　本申请涉及计算机技术领域，尤其涉及一种数据传输方法、装置、计算机设备以及存储介质。

　　背景技术

　　区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。简单的讲，区块链就是去中心化的分布式账本。

　　目前，区块链节点和客户端之间的交互过程为：客户端向区块链节点发送用于提交至区块链的交易数据后，客户端会向区块链节点发送用于查询提交结果的http请求。交易数据被成功存储到区块链上且接收到查询提交结果的http请求时，区块链节点才会向客户端反馈提交结果。

　　可见，客户端只有发送了请求后，才能获知到交易数据的提交结果，造成获取交易数据的提交结果的延迟较高，降低交易的实时性。

　　发明内容

　　本申请实施例提供一种数据传输方法、装置、计算机设备以及存储介质，可以降低获取的交易数据的交易状态的延迟，增强交易的实时性。

　　本申请实施例一方面提供了一种数据传输方法，包括：

　　通过长连接传输通道接收客户端发送的交易数据；

　　将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　每当所述交易数据的交易状态发生变更时，将变更后的交易状态通过所述长连接传输通道发送至所述客户端。

　　本申请实施例一方面提供了一种数据传输方法，包括：

　　通过长连接传输通道向区块链节点发送交易数据，以使所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　每当所述交易数据的交易状态发生变更时，通过所述长连接传输通道接收所述区块链节点发送的变更后的交易状态，显示变更后的交易状态对应的通知消息。

　　本申请实施例一方面提供了一种数据传输系统，包括客户端和区块链节点；

　　所述客户端通过长连接传输通道向所述区块链节点发送交易数据；

　　所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　每当所述交易数据的交易状态发生变更时，所述区块链节点将变更后的交易状态通过所述长连接传输通道发送至所述客户端，所述客户端显示变更后的交易状态对应的通知消息。

　　本申请实施例一方面提供了一种数据传输装置，包括：

　　第一接收模块，用于通过长连接传输通道接收客户端发送的交易数据；

　　提交模块，用于将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　第一发送模块，用于每当所述交易数据的交易状态发生变更时，将变更后的交易状态通过所述长连接传输通道发送至所述客户端。

　　本申请实施例一方面提供了一种数据传输装置，包括：

　　第二发送模块，用于通过长连接传输通道向区块链节点发送交易数据，以使所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　第三接收模块，用于每当所述交易数据的交易状态发生变更时，通过所述长连接传输通道接收所述区块链节点发送的变更后的交易状态，显示变更后的交易状态对应的通知消息。

　　本申请实施例一方面提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述各实施例中的方法。

　　本申请实施例一方面提供了一种计算机存储介质，计算机存储介质存储有计算机程序，计算机程序包括程序指令，程序指令当被处理器执行时，执行上述各实施例中的方法。

　　本申请实施例一方面提供了一种计算机程序产品或计算机程序，计算机程序产品或计算机程序包括计算机指令，计算机指令存储在计算机可读存储介质中，计算机指令被计算机设备的处理器执行时，执行上述各实施例中的方法。

　　在交易数据提交过程中，每当交易数据的交易状态发生变化时，区块链节点通过复用同一个长连接，将变化后的交易状态主动发送至客户端，可以降低客户端获取交易数据的交易状态的延迟，提升交易的实时性；再有，由区块链节点主动发送交易状态，避免由于客户端发送请求所导致的网络流量消耗问题，可以降低网络流量的耗费，节约流量资源；进一步地，区块链节点不仅实时向客户端反馈最后的交易状态，提交过程的中间状态也会实时反馈至客户端，进一步提升交易的实时性。

　　附图说明

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

　　图1是本申请实施例提供的一种区块链网络的示意图；

　　图2a-图2f是本申请实施例提供的一种数据传输的场景示意图；

　　图3是本申请实施例提供的一种多个交易状态的变更示意图；

　　图4是本申请实施例提供的一种数据传输系统的交互示意图；

　　图5a-图5b是本申请实施例提供的一种传输协议对比示意图；

　　图6是本申请实施例提供的一种数据传输方法的流程示意图；

　　图7是本申请实施例提供的一种数据传输方法的流程示意图；

　　图8是本申请实施例提供的一种数据传输方法的流程示意图；

　　图9是本申请实施例提供的一种数据传输装置的结构示意图；

　　图10是本申请实施例提供的一种数据传输装置的结构示意图；

　　图11是本申请实施例提供的一种计算机设备的结构示意图；

　　图12是本申请实施例提供的一种计算机设备的结构示意图。

　　具体实施方式

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

　　区块链(Block chain)是分布式数据存储、点对点传输(P2P，Peer To Peer)、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一个或多个交易信息，用于验证其信息的有效性(防伪)和生成下一个区块。

　　请参见图1，其是本申请实施例提供的一种区块链网络的示意图，节点1、节点2、节点3以及节点4可以组合为区块链网络，每个节点都可以存储一条相同的区块链，上述4个节点也可以称为区块链节点，每个节点都可以包括硬件层、中间层、操作系统层和应用层。可以理解的是，节点可以包括计算机设备。

　　上述节点可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。节点还可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。各节点之间可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

　　云技术(Cloud technology)是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。目前，技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

　　目前，云技术主要分为云基础技术类以及云应用类；云基础技术类可以进一步细分为：云计算、云储存、数据库以及大数据等；云应用类可以进一步细分为：医疗云、云物联、云安全、云呼叫、私有云、公有云、混合云、云游戏、云教育、云会议、云社交以及人工智能云服务等。

　　本申请的数据传输方法可以涉及云技术下属的云计算和云储存：

　　云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

　　在本申请中，区块链节点可以通过云计算技术获取足够算力和存储空间，进而执行本申请中所涉及的将交易数据提交至区块链。

　　云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

　　在本申请中，区块链可以由区块链节点通过云存储技术存储在“云”上，当需要从区块链上读取区块或需要向区块链上写入区块时，可以从云存储设备中拉取区块或者向云存储设备发送区块，以降低节点的本地存储压力。

　　本申请所涉及的数据传输方法的应用场景为：当客户端需要在区块链上进行交易时，客户端和区块链节点之间建立一个长连接传输通道，客户端通过该长传输通道向区块链节点发送交易数据，区块链节点将交易数据提交至区块链。在交易数据提交过程中，交易数据会经历多个不同的交易状态，每当交易状态发生变更时，区块链节点通过复用长连接传输通道，将变更后的交易状态发送至客户端。以实现细粒度的交易状态实时通知机制。

　　请参见图2a-图2f，其是本申请实施例提供的一种数据传输的场景示意图。图2a展示了1个区块链网络，该区块链网络包括3个节点，3个节点分别是：节点1、节点2以及节点3。这3个节点的本地都会存储区块链20a，从图2a可以看出此时区块链20a中包括3个区块。

　　客户端和节点3通过多次交互建立数据传输通道20b，数据传输通道20b也可以称为客户端和节点3之间的连接。客户端获取交易数据，交易数据的具体内容可以为：(账户1,账户2,20)，账户1表示资源转出账户，账户2表示资源转入账户，20表示待转移的资源量。通俗理解该交易数据的含义即是将数量为20的资源数据从区块链20a上的账户1转移至区块链20a上的账户2。

　　如图2b所示，客户端通过该数据传输通道20b将获取到的交易数据发送至节点3，节点3将交易数据存储至交易队列，并在存储至交易队列后将交易数据的状态由起始状态调整为未知状态(unknown-state)。

　　如图2c所示，由于交易数据的状态发生了变化，节点3可以通过复用该数据传输通道20b将交易数据当前的状态(交易数据当前的状态为未知状态unknown-state)发送至客户端，客户端在界面上显示未知状态对应的通知消息，以提示用户当前交易数据处于未知状态。

　　如图2b所示，节点3可以判断账户1的剩余资源量是否不小于20，验证交易数据携带的账户1的签名是否正确等等。若判断出账户1的剩余资源量不小于20，且验证出交易数据携带的账户1的签名正确，节点3将交易数据存储至交易池，并将交易数据的状态从未知状态(unknown-state)调整为待处理状态(pending-state)。

　　如图2d所示，由于交易数据的状态发生了变化，节点3可以通过再次复用该数据传输通道20b，将交易数据当前的状态(交易数据当前的状态为待处理状态pending-state)发送至客户端，客户端在界面上显示待处理状态对应的通知消息，以提示用户当前交易数据处于待处理状态。

　　如图2b所示，节点3可以将交易数据广播至节点1和节点2，基于区块链20a的共识机制从节点1、节点2和节点3中选择中记账节点，记账节点将交易数据打包为区块20c，并将新生成的区块20c在区块链网络中进行广播。节点3获取到包含交易数据的区块20c后，将交易数据的状态从待处理状态(pending-state)调整为入块状态(in_block-state)。

　　如图2e所示，由于交易数据的状态发生了变化，节点3可以通过再次复用该数据传输通道20b，将交易数据当前的状态(交易数据当前的状态为入块状态in_block-state)发送至客户端，客户端在界面上显示入块状态对应的通知消息，以提示用户当前交易数据处于入块状态。

　　如图2b所示，节点1、节点2和节点3对包含交易数据的区块20c达成共识后，节点3将区块20c存储至节点3本地维护的区块链20a中，当然对节点1和节点2来说，同样将区块20c存储至节点1(或者节点2)本地维护的区块链20a中。至此就完成了交易数据的提交过程(或者称为交易数据的上链过程)。如图2f所示，当前区块链20a中包括4个区块，且最后一个区块是新生成的包含交易数据的区块20c。

　　在将区块20c存储至区块链20a后，节点3将交易数据的状态从入块状态(in_block-state)调整为已确认状态(confirmed-state)。

　　如图2f所示，由于交易数据的状态发生了变化，节点3可以通过再次复用该数据传输通道20b，将交易数据当前的状态(交易数据当前的状态为已确认状态confirmed-state)发送至客户端，客户端在界面上显示已确认状态对应的通知消息，以提示用户当前交易数据处于已确认状态。

　　总结上述过程，在节点3将交易数据提交至区块链20a的过程中，交易数据会经历多个状态，且这多个状态的变更过程为：起始状态→未知状态→待处理状态→入块状态→已确认状态。每当交易数据的状态发生改变时，节点3会将改变后的状态主动发送至客户端，即节点3会将未知状态、待处理状态、入块状态以及已确认状态实时发送至客户端。将多个细粒度的状态发送至客户端可以增强区块链上交易的实时性，用户可以清楚的知道交易数据在任一时刻所处的状态，且节点3通过复用同一个数据传输通道主动向客户端发送交易数据所处的状态，可以降低网络流量的消耗。

　　其中，通过长连接传输通道(如上述实施例中的数据传输通道20b)接收客户端发送的交易数据，将交易数据提交至区块链(如上述实施例中的区块链20a)，以及将变更后的多个交易状态(如上述实施例中的未知状态、待处理状态、入块状态以及已确认状态)通过长连接传输通道发送至客户端的具体过程可以参见下述图3-图8对应的实施例。

　　在详细描述本申请方案前，先介绍交易数据在提交至区块链过程中，所要经历的多个交易状态以及这多个交易状态之间的变更方式。请参见图3，图3是本申请实施例提供的一种多个交易状态的变更示意图。

　　首先说明多个交易状态的定义：

　　1、未知状态(UNKNOWN，可以对应本申请中的第一状态)：未被网络检测到且位于交易队列的交易数据被定义为处于UNKONW状态；

　　2、待处理状态(PENDING，可以对应本申请中的第二状态)：等待共识节点打包处理且位于交易池中的交易数据被定义为处于PENDING状态。

　　3、入块状态(IN_BLOCK，可以对应本申请中的第三状态)：被打包进区块的交易数据被定义为处于IN_BLOCK状态。

　　4、已确认状态(CONFIRMED，可以对应本申请中的第四状态)：被确认且被写入账本的交易数据被定义为处于CONFIRMED状态。

　　5、被替换状态(REPLACED，可以对应本申请中的第五状态)：在以下两种情况下，交易状态可以从PENDING状态变为REPLACED状态。

　　(a)另一笔交易来自同一发送者且有相同编号的交易进入了IN_BLOCK状态；

　　(b)另一笔来自同一发送者且有相同编号且给的小费更高进入了PENDING状态。

　　多个交易状态之间的转换如下：

　　1、加入交易池(POOLED)：处于UNKOWN状态的交易数据进入交易池，被称为POOLED并进入PENDING状态。处于REPLACED状态的交易数据，如果上述条件(a)和条件(b)不再成立，则会被加入交易池并进入PENDING状态。

　　2、被打包(MINED)：交易数据可以被共识节点打包为区块，交易数据一旦被打包，交易数据就处于IN_BLOCK状态。

　　3、被替换(REPLACED)：从PENDING状态进入到REPLACED状态的交易被称为REPLACED。

　　4、被分叉(FORKED)：当交易数据处于被撤销的区块中时，该交易数据就是被分叉的交易数据，被撤销的区块中的所有交易数据从IN_BLOCK状态回到PENDING状态。

　　5、CONFIRMED(已确认)：处于IN_BLOCK状态的交易数据被确认并写入账本后，交易数据处于CONFIRMED状态。

　　从图3可以知道，两个不同交易状态之间的转换可以有多种途径，例如从未知状态可以直接到入块状态；也可以先从未知状态到待处理状态再到入块状态。

　　请参见图4，是本申请实施例提供的一种数据传输系统的交互示意图，数据传输系统涉及客户端和区块链节点，客户端和区块链节点的交互过程包括如下步骤：

　　步骤S101，所述客户端通过长连接传输通道向所述区块链节点发送交易数据。

　　具体的，客户端和区块链节点之间构建一个长连接传输通道(如上述图2a-图2f对应实施例中的数据传输通道20b)，长连接传输通道相比短连接传输通道的优势在于可以被复用，也就是说，长连接传输通道可以多次传输数据。长连接传输通道也可以被称为长连接。

　　客户端通过构建好的长连接传输通道向区块链节点发送交易数据，也可以说客户端基于一个已经构建好的长连接，向区块链节点发送交易数据。

　　通过长连接传输通道向区块链节点发送交易数据，从技术实现层面来来说，即是客户端在将交易数据打包为数据帧序列时，在数据帧序列的起始位置填充交互信息，其中交互信息是构建长连接传输通道过程中，区块链节点和客户端之间交换的信息。区块链节点接收到数据帧序列后，验证该交互信息，进而可以确定与客户端之间是否建立了长连接传输通道。

　　下面对如何构建长连接传输通道进行具体的说明：

　　客户端向区块链节点发送第一握手请求，区块链节点响应该第一握手请求向客户端反馈响应消息，客户端基于该响应消息再向区块链节点发送第二握手请求，至此，就建立了客户端和区块链节点之间的握手通道，该握手通道也可以称为tcp(传输控制协议，Transmission Control Protocol)连接。上述过程也可以被称为区块链节点和客户端之间的“三次握手”。

　　其中，握手通道是http/tcp协议对应的连接通道。

　　客户端通过握手通道，可以向区块链节点发送协议调整请求，可以知道该协议调整请求是http(超文本传输协议，HyperText Transfer Protocol)请求，协议调整请求中包含目标传输协议的协议标识，例如，协议请求中包括upgrade的字段。本申请中，目标传输协议可以具体是Websocket协议，协议调整请求的目的是将客户端和区块链节点之间的传输协议由http协议调整为Websocket协议。

　　区块链节点根据协议调整请求，通过握手通道向客户端反馈确认消息，客户端接收到确认消息后，客户端和区块链节点之间就构建了一个基于Websocket协议的长连接传输通道，此处的长连接传输通道可以具体是Websocket长连接。

　　正是由于长连接传输通道是基于Websocket协议的连接通道，因此区块链节点才可以主动向客户端下发数据。

　　反之，基于握手通道，区块链节点就不可以主动向客户端下发数据，只有客户端请求数据，区块链节点才可以为了响应请求向客户端下发数据。

　　请参见图5a-图5b，是本申请实施例提供的一种传输协议对比示意图，图5a描述的是HTTP协议的示意图，图5b描述的是Websocket协议的示意图。从图5a和图5b可以看出，WebSocket与传统的HTPP每次请求-响应都需要客户端与服务端建立TCP短连接的模式不同，WebSocket是类似Socket的TCP长连接的通讯模式，一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。其中，建立TCP短连接(或者TCP长连接)是通过“三次握手”连接的。

　　在客户端断开WebSocket连接或者服务器断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发和客户端与服务端交互负载流量大的情况下，极大节省了网络带宽资源的消耗，有明显的性能优势，同时客户端发送和接收消息是在同一个持久连接上发起，服务端也可以主动向客户端发送数据，实时性优势明显。

　　建立WebSocket连接(WebSocket连接可以对应本申请中的长连接传输通道)的具体过程是：客户端和服务器之间建立tcp连接(tcp长连接或者tcp短连接均可)，客户端通过tcp连接首先发送一个HTTP请求到服务端，请求的特殊之处在于请求里面带了一个upgrade的字段，告诉服务器，客户端想将当前的传输协议更改为WebSocket的协议。服务器收到请求后，返回给客户端一个握手确认，握手确认中包含一个ACK，意思允许客户端将传输协议更改为WebSocket协议，完成这个协商后，客户端和服务器之间就建立了一个WebSocket连接，且在协商过程中，客户端与服务端之间的底层TCP连接是没有中断的。接下来，客户端可以主动向服务端发起基于WebSocket协议的消息，服务端也可以主动向客户端基于WebSocket协议的消息。

　　步骤S102，所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同。

　　具体的，区块链节点通过长连接传输通道获取到交易数据后，将交易数据提交至区块链(如上述图2a-图2e对应实施例中的区块链20a)。

　　其中，区块链节点在将交易数据提交至区块链的过程中，交易数据会经历多个交易状态，多个交易状态互不相同。

　　多个交易状态可以包括：起始状态、第一状态(如上述图2a-图2e对应实施例中的未知状态)、第二状态(如上述图2a-图2e对应实施例中的待处理状态)、第三状态(如上述图2a-图2e对应实施例中的入块状态)和第四状态。

　　多个交易状态的变更过程可以为：起始状态→第一状态→第二状态→第三状态→第四状态。

　　下面对区块链节点如何将交易数据提交至区块链进行详细说明：

　　区块链节点通过长连接传输通道获取到交易数据后，将交易数据缓存至交易队列，缓存至交易队列后，区块链节点将交易数据的交易状态由起始状态变更为第一状态，其中处于第一状态的交易数据表示未被网络检测到且位于交易队列的交易数据。

　　区块链节点验证交易数据是否为合法交易数据，其中可以验证交易数据携带的签名是否正确，交易数据的格式是否正确的等。当然，若签名正确且交易数据的格式也正确，区块链节点可以确定交易数据是合法交易数据；反之，若签名不正确，或者交易数据的格式不正确，区块链节点可以确定交易数据是非法交易数据。若区块链节点验证到交易数据是合法交易数据，区块链节点将交易数据缓存至交易池，缓存至交易池后，区块链节点将交易数据的交易状态由第一状态变更为第二状态，其中，处于第二状态的交易数据表示等待共识节点打包处理且位于交易池中的交易数据。

　　可选的，将交易数据缓存至交易池后，区块链节点可以将交易队列中的交易数据进行删除。

　　需要说明的是，区块链节点接收到交易数据一直到交易数据被成功提交到区块链这个过程的任意时刻，交易数据会处于且只处于一种交易状态。例如，在交易数据的交易状态未被变更为第一状态之前，交易数据一直处于初始状态，在交易数据的交易状态未被变更为第二状态之前，交易数据一直处于第一状态。

　　区块链节点提取交易池中的交易数据以及N个待打包交易数据，N个待打包交易数据是交易池中除通过长连接传输通道接收到的交易数据以外的其余交易数据。区块链节点计算每个待打包交易数据和交易数据之间的数据相似度(称为交易数据相似度)，其中，若交易数据和待打包交易数据来源于同一个用户，则交易数据和该待打包交易数据之间的交易数据相似度大；若交易数据和待打包交易数据来携带相同的交易编号，则交易数据和该待打包交易数据之间的交易数据相似度大。

　　若N个交易数据相似度都小于相似度阈值，则区块链节点将交易数据以及N个待打包交易数据打包为区块(如上述图2a-图2e对应实施例中的区块20c)。打包为区块后，区块链节点将交易数据的交易状态由第二状态变更为第三状态，其中，处于第三状态的交易数据是被打包进区块的交易数据。

　　区块链节点将新生成的区块在区块链网络中进行广播，区块链网络中的所有节点对该区块进行共识。当区块共识完成时，区块链节点将区块存储至区块链。区块被存储至区块链后，区块链节点将交易数据的交易状态由第三状态变更为第四状态，其中，处于第四状态的交易数据是被确认且被写入账本的交易数据。

　　至此，就完成了将交易数据提交至区块链的全部过程，总结上述过程，交易数据的交易状态发生了如下变更：从起始状态变更为第一状态，从第一状态变更为第二状态，从第二状态变更为第三状态，从第三状态变更为第四状态。

　　可选的，在区块被添加至区块链后，删除存储在交易池中的交易数据和N个待打包交易数据。

　　需要说明的是，上面描述在交易数据提交过程中，交易数据要经历5种交易状态，也可以对这5种交易状态进行合并，使得在交易数据提交过程中，交易数据只经历4种(或者3种，或者2种)交易状态，交易状态的合并可以参见上述图3。

　　例如，若交区块链节点检测到交易数据是合法交易数据，此时区块链节点可以将交易数据的交易状态从起始状态调整为第二状态，后续过程不变，这个时候，交易数据就会经历起始状态，第二状态，第三状态和第四状态这4个交易状态。或者，在提交过程中交易数据经历起始状态，第三状态和第四状态这3个交易状态。按照这种思想，具有多种组合方式，可以根据不同的业务需求，作出相应的调整。

　　可选的，前面描述了若N个交易数据相似度都小于相似度阈值的情况，若N个交易数据相似度中存在至少一个大于相似度阈值的交易数据相似度，则将大于相似度阈值的待打包交易数据作为目标待打包交易数据。检测目标待打包交易数据的交易状态是否为第三状态，以及检测目标待打包交易数据对应的奖励资源量是否大于交易数据对应的奖励资源量，若区块链节点检测到目标待打包交易数据的交易状态为第三状态，或者检测到目标待打包交易数据对应的奖励资源量大于交易数据对应的奖励资源量，则将交易数据的交易状态从第二状态变更为第五状态，且处于第五状态的交易数据不会被打包为区块，会一直缓存在交易池中，只有当交易状态变更为第二状态时，该交易数据才可以被打包为区块。可以知道，一旦目标待打包交易数据被写入账本后，交易池中的目标待打包交易数据就会被删除，在这种情况下，一旦区块链节点检测中交易池中不存在目标待打包交易数据时，区块链节点可以将交易数据的交易状态再从第五状态调整回第二状态。此时，区块链节点再检测交易数据和当前交易池中的新的待打包交易数据之间的交易数据相似度，后续流程和前述一致，此处不再赘述。

　　总结上述过程，在交易数据被提交至区块链过程中，交易数据经历了：起始状态，第一状态，第二状态，第五状态，第三状态和第四状态这6个交易状态，且交易数据的交易状态发生了如下变更：从起始状态变更为第一状态，从第一状态变更为第二状态，从第二状态变更为第五状态，从第五状态变成为第二状态，从第二状态变更为第三状态，从第三状态变更为第四状态。

　　换句话说，在交易数据提交过程中，同一个交易状态可以经历多次，如上述的第二状态，交易状态的变更可以参见上述图3。

　　可选的，若区块链节点检测到目标待打包交易数据的交易状态不是第三状态，且检测到目标待打包交易数据对应的奖励资源量不大于交易数据对应的奖励资源量，区块链节点将交易数据和N个待打包交易数据打包为区块，并将交易数据的交易状态从第二状态变更第三状态，后续流程和前述一致，此处不再赘述。

　　步骤S103，每当所述交易数据的交易状态发生变更时，所述区块链节点将变更后的交易状态通过所述长连接传输通道发送至所述客户端。

　　具体的，每当交易数据的交易状态发生变更时，区块链节点获取变更后的交易状态，并通过复用长连接传输通道将变更后的交易状态发送至客户端。

　　从前述可知，交易数据在被存储至区块链的过程中，交易状态发生变更可以包括以下4种情况分别是：从起始状态变更为第一状态，从第一状态变更为第二状态，从第二状态变更为第三状态，从第三状态变更为第四状态。当交易数据从起始状态变更为第一状态时，区块链节点通过复用长连接传输通道将第一状态发送至客户端；当交易数据从第一状态变更为第二状态时，区块链节点通过复用长连接传输通道将第二状态发送至客户端；当交易数据从第二状态变更为第三状态时，区块链节点通过复用长连接传输通道将第三状态发送至客户端；当交易数据从第三状态变更为第四状态时，区块链节点通过复用长连接传输通道将第四状态发送至客户端。

　　交易数据在被存储至区块链的过程中，交易状态发生变更可以包括以下6种情况分别是：从起始状态变更为第一状态，从第一状态变更为第二状态，从第二状态变更为第五状态，从第五状态变更为第二状态，从第二状态变更为第三状态，从第三状态变更为第四状态。当交易数据从起始状态变更为第一状态时，区块链节点通过复用长连接传输通道将第一状态发送至客户端；当交易数据从第一状态变更为第二状态时，区块链节点通过复用长连接传输通道将第二状态发送至客户端；当交易数据从第二状态变更为第五状态时，区块链节点通过复用长连接传输通道将第五状态发送至客户端；当交易数据从第五状态变更为第二状态时，区块链节点通过复用长连接传输通道将第二状态发送至客户端；当交易数据从第二状态变更为第三状态时，区块链节点通过复用长连接传输通道将第三状态发送至客户端；当交易数据从第三状态变更为第四状态时，区块链节点通过复用长连接传输通道将第四状态发送至客户端。

　　步骤S104，所述客户端显示变更后的交易状态对应的通知消息。

　　具体的，客户端一旦接收到变更后的交易状态，可以显示变更后的交易状态对应的通知消息。

　　例如，一旦客户端接收到第一状态，在客户端中显示提示通知消息：“您提交的交易数据已经处于第一状态啦”。

　　用户通过阅览客户端，即可知道交易数据当前所处交易状态，而不仅仅是只知道最后的提交结果(或者说最后的交易状态)，区块链节点向客户端反馈的信息更为丰富，实现细粒度的交易状态实时通知机制。再有，由区块链节点主动发送交易状态，避免由于客户端发送请求所导致的网络流量消耗问题，可以降低网络流量的耗费，节约流量资源。

　　请参见图6，是本申请实施例提供的一种数据传输方法的流程示意图，数据传输方法涉及客户端和区块链节点，本实施例从区块链节点侧进行描述，数据传输方法包括如下步骤：

　　步骤S201，通过长连接传输通道接收客户端发送的交易数据。

　　具体的，区块链节点和客户端之间建立一个长连接传输通道，其中该长连接传输通道是Websocket协议对应的传输通道，基于Websocket协议的长连接传输通道区块链节点可以主动向客户端下发数据。

　　区块链节点通过长连接传输通道接收客户端发送的交易数据。

　　其中，构建长连接传输通道的具体过程可以参见上述图4对应实施例中的步骤S101。

　　步骤S202，将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同。

　　具体的，区块链节点将交易数据提交至区块链，其中在提交过程中，交易数据可以经历5个交易状态，这个5个交易状态分别为：初始状态，第一状态，第二状态，第三状态和第四状态，且这5个交易状态的变更过程为：初始状态→第一状态→第二状态→第三状态→第四状态。

　　可选的，在提交过程中，交易数据可以经历6个交易状态，这个6个交易状态分别为：初始状态，第一状态，第二状态，第三状态，第四状态和第五状态，且这6个交易状态的变更过程为：初始状态→第一状态→第二状态→第五状态→第二状态→第三状态→第四状态。

　　其中，区块链节点向区块链提交交易数据的具体过程可以参见上述图4对应实施例中的步骤S102。

　　步骤S203，每当所述交易数据的交易状态发生变更时，将变更后的交易状态通过所述长连接传输通道发送至所述客户端，以使所述客户端显示变更后的交易状态。

　　具体的，当交易数据的交易状态从初始状态变更为第一状态时，区块链节点通过长连接传输通道主动向客户端发送第一状态；当交易数据的交易状态从第一状态变更为第二状态时，区块链节点通过长连接传输通道主动向客户端发送第二状态；当交易数据的交易状态从第二状态变更为第三状态时，区块链节点通过长连接传输通道主动向客户端发送第三状态；当交易数据的交易状态从第三状态变更为第四状态时，区块链节点通过长连接传输通道主动向客户端发送第四状态。

　　当交易数据的交易状态从初始状态变更为第一状态时，区块链节点通过长连接传输通道主动向客户端发送第一状态；当交易数据的交易状态从第一状态变更为第二状态时，区块链节点通过长连接传输通道主动向客户端发送第二状态；当交易数据的交易状态从第二状态变更为第五状态时，区块链节点通过长连接传输通道主动向客户端发送第五状态；当交易数据的交易状态从第五状态变更为第二状态时，区块链节点通过长连接传输通道主动向客户端发送第二状态；当交易数据的交易状态从第二状态变更为第三状态时，区块链节点通过长连接传输通道主动向客户端发送第三状态；当交易数据的交易状态从第三状态变更为第四状态时，区块链节点通过长连接传输通道主动向客户端发送第四状态。

　　下面以变更后的交易状态是第一状态为例说明如何发送第一状态，其余的交易状态都可以采用相同的方式向客户端发送：

　　由于客户端和区块链节点之间的传输协议是Websocket协议，数据都以帧序列的形式进行传输。区块链节点查询第一状态对应的状态码，将获取的状态码、客户端标识、服务器标识等封装为传输消息，将传输消息划分为多个数据帧，在数据帧的头部添加交互信息，使得多个数据帧可以通过长连接传输通道发送至客户端，区块链节点向客户端发送多个数据帧。其中，交互信息是构建长连接传输通道过程中，区块链节点和客户端之间交换的信息。

　　请参见图7，是本申请实施例提供的一种数据传输方法的流程示意图，数据传输方法涉及客户端和区块链节点，本实施例从客户端侧进行描述，数据传输方法包括如下步骤：

　　步骤S301，通过长连接传输通道向区块链节点发送交易数据，以使所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同。

　　具体的，区块链节点和客户端之间建立一个长连接传输通道，其中该长连接传输通道是Websocket协议对应的传输通道，基于Websocket协议的长连接传输通道区块链节点可以主动向客户端下发数据。

　　客户端通过长连接传输通道向区块链节点发送交易数据，以使区块链节点将交易数据提交至区块链，其中在提交过程中，交易数据可以经历5个交易状态，这个5个交易状态分别为：初始状态，第一状态，第二状态，第三状态和第四状态，且这5个交易状态的变更过程为：初始状态→第一状态→第二状态→第三状态→第四状态。

　　可选的，在提交过程中，交易数据可以经历6个交易状态，这个6个交易状态分别为：初始状态，第一状态，第二状态，第三状态，第四状态和第五状态，且这6个交易状态的变更过程为：初始状态→第一状态→第二状态→第五状态→第二状态→第三状态→第四状态。

　　其中，构建长连接传输通道的具体过程可以参见上述图4对应实施例中的步骤S101，区块链节点向区块链提交交易数据的具体过程可以参见上述图4对应实施例中的步骤S102。

　　步骤S302，每当所述交易数据的交易状态发生变更时，通过所述长连接传输通道接收所述区块链节点发送的变更后的交易状态，显示变更后的交易状态对应的通知消息。

　　具体的，当交易数据的交易状态从初始状态变更为第一状态时，客户端通过长连接传输通道接收区块链节点发送的第一状态，显示第一状态对应的通知消息；当交易数据的交易状态从第一状态变更为第二状态时，客户端通过长连接传输通道接收区块链节点发送的第二状态，显示第二状态对应的通知消息；当交易数据的交易状态从第二状态变更为第三状态时，客户端通过长连接传输通道接收区块链节点发送的第三状态，显示第三状态对应的通知消息；当交易数据的交易状态从第三状态变更为第四状态时，客户端通过长连接传输通道接收区块链节点发送的第四状态，显示第四状态对应的通知消息。

　　当交易数据的交易状态从初始状态变更为第一状态时，客户端通过长连接传输通道接收区块链节点发送的第一状态，显示第一状态对应的通知消息；当交易数据的交易状态从第一状态变更为第二状态时，客户端通过长连接传输通道接收区块链节点发送的第二状态，显示第二状态对应的通知消息；当交易数据的交易状态从第二状态变更为第五状态时，客户端通过长连接传输通道接收区块链节点发送的第五状态，显示第五状态对应的通知消息；当交易数据的交易状态从第五状态变更为第二状态时，客户端通过长连接传输通道接收区块链节点发送的第二状态，显示第二状态对应的通知消息；当交易数据的交易状态从第二状态变更为第三状态时，客户端通过长连接传输通道接收区块链节点发送的第三状态，显示第三状态对应的通知消息；当交易数据的交易状态从第三状态变更为第四状态时，客户端通过长连接传输通道接收区块链节点发送的第四状态，显示第四状态对应的通知消息。

　　下面以变更后的交易状态是第一状态为例说明如何接收第一状态，客户端可以按照相同的方式接收其余的交易状态：

　　客户端通过长连接传输通道接收区块链节点发送的多个数据帧，将多个数据帧按照顺序组合为传输消息，从传输消息中读取状态码，查询该状态码对应的交易状态，查询到的交易状态即是区块链节点发送的变更后的交易状态。

　　可选的，客户端显示选择界面，选择界面还包含状态订阅选项。若用户触发状态订阅选项，客户端生成状态订阅消息，客户端通过长连接传输通道向区块链节点发送状态订阅消息，该状态订阅消息是用于通知区块链节点每当交易数据的交易状态发生变更时，区块链节点就要向客户端发送变更后的交易状态。

　　图8是本申请实施例提供的一种数据传输方法的流程示意图，数据传输过程包括如下步骤：

　　步骤S401，客户端与区块链节点建立WebSocket连接后，客户端向区块链节点发送交易数据。

　　步骤S402，全双工通信协议模块接收交易数据，并将交易数据缓存至交易队列，同时将交易状态设置为UNKOWN状态，并通过全双工通信协议模块告知客户端当前的交易状态为UNKOWN。接着通知虚拟机执行验证交易数据，例如验证数字签名、验证余额是否足够，验证交易是否重放等。

　　步骤S403，验证通过后，全双工通信协议模块将交易数据放入交易池，同时将交易数据从交易队列中删除。

　　步骤S404，交易池缓存交易数据后，将交易状态设置为PENDING状态，生成一条交易状态变更事件通过日志管理模块发布。全双工通信协议模块通过日志管理模块发现有新的交易状态变更事件，全双工通信协议模块告知客户端当前的交易状态为PENDING。

　　步骤S405，交易池将交易数据通过P2P网络广播给其他区块链节点。

　　步骤S406，共识组件从交易池中拉取交易数据打包成区块，打包后将交易状态设置为IN_BLOCK，生成一条交易状态变更事件通过日志管理模块发布。全双工通信协议模块通过日志管理模块发现有新的交易状态变更事件，全双工通信协议模块告知客户端当前的交易状态为IN_BLOCK。

　　步骤S407，共识组件运行共识协议，将打包的区块通过P2P网络广播。

　　步骤S408，在共识协议运行过程中，共识组件将区块传递给执行组件。

　　步骤S409，执行组件通知虚拟机调用智能合约执行区块中的交易数据并缓存执行结果。

　　步骤S410，执行组件将执行结果返回共识组件。

　　步骤S411，共识组件通过交换执行结果尝试达成共识。

　　步骤S412，共识达成后，执行组件通知持久化存储模块将区块以及执行结果持久化存储，将持久化存储后交易数据的交易状态设置为CONFIRMED，生成一条交易状态变更事件通过日志管理模块发布；全双工通信协议模块通过日志管理模块发现有新的交易状态变更事件，全双工通信协议模块告知客户端当前的交易状态为CONFIRMED，通知缓存在交易池中的交易数据删除。

　　进一步的，请参见图9，其是本申请实施例提供的一种数据传输装置的结构示意图。如图9所示，数据传输装置1可以应用于上述图4-图8对应实施例中的区块链节点，具体的，数据传输装置1可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如该数据传输装置1为一个应用软件；该数据传输装置1可以用于执行本申请实施例提供的方法中的相应步骤。

　　数据传输装置1可以包括：第一接收模块11、提交模块12以及第一发送模块13。

　　第一接收模块11，用于通过长连接传输通道接收客户端发送的交易数据；

　　提交模块12，用于将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　第一发送模块13，用于每当所述交易数据的交易状态发生变更时，将变更后的交易状态通过所述长连接传输通道发送至所述客户端。

　　第一发送模块13，具体用于获取变更后的交易状态对应的状态码，将所述状态码封装为传输消息，将所述传输消息划分为多个数据帧，将所述多个数据帧通过所述长连接传输通道发送至所述客户端。

　　长连接传输通道是目标传输协议对应的传输通道；

　　数据传输装置1可以包括：第一接收模块11、提交模块12以及第一发送模块13；还可以包括：第二接收模块14和调整模块15。

　　第二接收模块14，用于接收客户端发送的协议调整请求，所述协议调整请求包括所述目标传输协议的协议标识；

　　调整模块15，用于向所述客户端发送针对所述协议调整请求的确认消息，以建立与所述客户端之间的所述长连接传输通道。

　　第二接收模块14，具体用于接收客户端发送的握手请求，向所述客户端发送针对所述握手请求的响应消息，以建立与所述客户端的握手通道，通过所述握手通道接收所述客户端发送的所述协议调整请求。

　　其中，第一接收模块11、提交模块12以及第一发送模块13、第二接收模块14和调整模块15的具体功能实现方式可以参见上述图4对应实施例中的步骤S101-步骤S104。

　　提交模块12可以包括：第一缓存单元121和打包单元122。

　　第一缓存单元121，用于将所述交易数据缓存至交易队列，将所述交易数据的交易状态从起始状态变更为第一状态，若所述交易队列中的所述交易数据是合法交易数据，则将所述交易数据缓存至交易池，将所述交易数据的交易状态从所述第一状态变更为第二状态；

　　打包单元122，用于将所述交易池中的所述交易数据打包为区块；

　　所述第一缓存单元121，还用于将所述交易数据的交易状态从所述第二状态变更为第三状态，对所述区块进行共识，当所述区块共识完成时，将所述区块存储至所述区块链，并将所述交易数据的交易状态从所述第三状态变更为第四状态。

　　在一个实施例中，所述交易池包括N个待打包交易数据和所述交易数据，所述N是大于0的整数；

　　所述打包单元122，具体用于确定每个待打包交易数据和所述交易数据之间的交易数据相似度，若N个交易数据相似度都小于相似度阈值，则将所述交易数据以及所述N个待打包交易数据打包为所述区块；

　　提交模块可以包括：第一缓存单元121和打包单元122，还包括：删除单元123。

　　删除单元123，用于删除所述交易池中的所述交易数据以及所述N个待打包交易数据。

　　其中，第一缓存单元121、打包单元122和删除单元123的具体功能实现方式可以参见上述图4对应实施例中的步骤S102。

　　在一个实施例中，交易状态发生变更包括以下任一种：从所述起始状态变更为所述第一状态，从所述第一状态变更为所述第二状态、从所述第二状态变更为所述第三状态，从所述第三状态变更为所述第四状态。

　　进一步的，请参见图10，其是本申请实施例提供的一种数据传输装置的结构示意图。如图10所示，数据传输装置2可以应用于上述图4-图8对应实施例中的客户端，具体的，数据传输装置2可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如该数据传输装置2为一个应用软件；该数据传输装置2可以用于执行本申请实施例提供的方法中的相应步骤。

　　数据传输装置2可以包括：第二发送模块21以及第三接收模块22。

　　第二发送模块21，用于通过长连接传输通道向区块链节点发送交易数据，以使所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　第三接收模块22，用于每当所述交易数据的交易状态发生变更时，通过所述长连接传输通道接收所述区块链节点发送的变更后的交易状态，显示变更后的交易状态对应的通知消息。

　　其中，第二发送模块21以及第三接收模块22的具体功能实现方式可以参见上述图4对应实施例中的步骤S101-步骤S104。

　　在一个实施例中，所述长连接传输通道是目标传输协议对应的传输通道；

　　数据传输装置2可以包括：第二发送模块21以及第三接收模块22；还可以包括：第三发送模块23。

　　第三发送模块23，用于向所述区块链节点发送握手请求，接收所述区块链节点针对所述握手请求的响应消息，以建立与所述区块链节点的握手通道，通过所述握手通道向所述区块链节点发送协议调整请求，所述协议调整请求包括所述目标传输协议的协议标识，通过所述握手通道接收所述区块链节点针对所述协议调整请求发送的确认消息，以建立与所述区块链节点的所述长连接传输通道。

　　在一个实施例中，数据传输装置2可以包括：第二发送模块21以及第三接收模块22；还可以包括：显示模块24。

　　显示模块24，用于显示选择界面，所述选择界面包括状态订阅选项，响应对所述状态订阅选项的触发操作，生成状态订阅消息，通过所述长连接传输通过将所述状态订阅消息发送至所述区块链节点，所述状态订阅消息用于通知所述区块链节点每当所述交易数据的交易状态发生变更时，向所述客户端发送变更后的交易状态。

　　其中，第三发送模块23的具体功能实现方式可以参见上述图4对应实施例中的步骤S101，显示模块24的具体功能实现方式可以参见上述图7对应实施例中的步骤S302。

　　进一步地，请参见图11，是本申请实施例提供的一种计算机设备的结构示意图。上述图4-图8对应实施例中的区块链节点。如图11所示，计算机设备1000可以包括：用户接口1002、处理器1004、编码器1006以及存储器1008。信号接收器1016用于经由蜂窝接口1010、WIFI接口1012、...、或NFC接口1014接收或者发送数据。编码器1006将接收到的数据编码为计算机处理的数据格式。存储器1008中存储有计算机程序，处理器1004被设置为通过计算机程序执行上述任一项方法实施例中的步骤。存储器1008可包括易失性存储器(例如，动态随机存取存储器DRAM)，还可以包括非易失性存储器(例如，一次性可编程只读存储器OTPROM)。在一些实例中，存储器1008可进一步包括相对于处理器1004远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备1000。用户接口1002可以包括：键盘1018和显示器1020。

　　在图11所示的计算机设备1000中，处理器1004可以用于调用存储器1008中存储计算机程序，以实现：

　　通过长连接传输通道接收客户端发送的交易数据；

　　将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　每当所述交易数据的交易状态发生变更时，将变更后的交易状态通过所述长连接传输通道发送至所述客户端。

　　应当理解，本申请实施例中所描述的计算机设备1000可执行前文图4-图8所对应实施例中对数据传输方法的描述，也可执行前文图9所对应实施例中对数据传输装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

　　此外，这里需要指出的是：本申请实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的数据传输装置1所执行的计算机程序，且计算机程序包括程序指令，当处理器执行程序指令时，能够执行前文图4-图8所对应实施例中对数据传输方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可以被部署在一个计算机设备上执行，或者在位于一个地点的多个计算机设备上执行，又或者，分布在多个地点且通过通信网络互联的多个计算机设备上执行，分布在多个地点且通过通信网络互联的多个计算机设备可以组合为区块链网络。

　　进一步地，请参见图12，是本申请实施例提供的一种计算机设备的结构示意图。上述图4-图8对应实施例中的客户端所在的终端设备可以为计算机设备2000。如图12所示，计算机设备2000可以包括：用户接口2002、处理器2004、编码器2006以及存储器2008。信号接收器2016用于经由蜂窝接口2020、WIFI接口2012、...、或NFC接口2014接收或者发送数据。编码器2006将接收到的数据编码为计算机处理的数据格式。存储器2008中存储有计算机程序，处理器2004被设置为通过计算机程序执行上述任一项方法实施例中的步骤。存储器2008可包括易失性存储器(例如，动态随机存取存储器DRAM)，还可以包括非易失性存储器(例如，一次性可编程只读存储器OTPROM)。在一些实例中，存储器2008可进一步包括相对于处理器2004远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备2000。用户接口2002可以包括：键盘2018和显示器2020。

　　在图12所示的计算机设备2000中，处理器2004可以用于调用存储器2008中存储计算机程序，以实现：

　　通过长连接传输通道向区块链节点发送交易数据，以使所述区块链节点将所述交易数据提交至区块链；其中，所述交易数据在提交过程中会经历多个交易状态，所述多个交易状态互不相同；

　　每当所述交易数据的交易状态发生变更时，通过所述长连接传输通道接收所述区块链节点发送的变更后的交易状态，显示变更后的交易状态对应的通知消息。

　　应当理解，本申请实施例中所描述的计算机设备2000可执行前文图4-图8所对应实施例中对数据传输方法的描述，也可执行前文图10所对应实施例中对数据传输装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

　　此外，这里需要指出的是：本申请实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的数据传输装置2所执行的计算机程序，且计算机程序包括程序指令，当处理器执行程序指令时，能够执行前文图4-图8所对应实施例中对数据传输方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可以被部署在一个计算机设备上执行，或者在位于一个地点的多个计算机设备上执行，又或者，分布在多个地点且通过通信网络互联的多个计算机设备上执行，分布在多个地点且通过通信网络互联的多个计算机设备可以组合为区块链网络。

　　本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

　　以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。