一种交易上链方法、装置、电子设备及存储介质

技术领域

本申请涉及区块链技术领域，尤其涉及一种交易上链方法、装置、电子设备及存储介质。

背景技术

智能合约是一段代码和数据的集合，智能合约部署是指将智能合约部署到以太坊区块链上运行的过程。智能合约在以太坊区块链上运行需要将智能合约代码转换为以太坊虚拟机可识别的字节码，而将智能合约成功部署到区块链上后，就会生成对应的合约地址。而基于部署好的智能合约的合约交易可以通过获取合约地址，输入所需参数然后调用合约的方法来完成整个交易过程。

目前，在Java工程中进行合约部署时，首先需要使用工具将智能合约编程语言Solidity的SOL文件编译成Java代码，然后再将Java代码引入到Java工程项目中。接着在进行合约交易的时候，需要调用合约交易对应的的Java方法来进行交易。具体的，首先调用交易接口来发送交易，在发送交易以后，获得本次交易对应的交易哈希值，然后轮询调用交易结果查询接口，利用哈希值来获取交易结果。

在上述Java工程进行合约部署的过程中，需要先将SOL文件编译转换为Java代码，然后需要把转换后的Java代码引入Java工程，交易时也需要调用对应的Java方法。这样，每部署一个智能合约都需要先将智能合约的SOL文件编译转换成Java代码，然后再将Java代码引入Java工程中。这样无法实现通用化的合约部署，合约部署以及交易上链的效率异常低下。并且现有的区块链系统中，交易均是通过调用对应的接口单笔发送上链的，并且交易结果的查询也是单笔查询的，因此交易上链和结果查询的效率也很低。因此如何提高智能合约部署、交易上链以及交易结果查询的效率成为亟需解决的问题。

发明内容

有鉴于此，本申请实施例第一方面提供了一种交易上链方法，该交易批量上链方法应用于上链交易平台。其中，上链交易平台通过交易上传接口与具有钱包系统的上层应用相连，且上链交易平台通过批量上链接口/批量查询接口与区块链相连。该交易批量上链方法包括：

通过交易上传接口接收上层应用输入的交易信息。

对上层应用输入的交易信息进行处理，生成待上链交易。

将待上链交易暂存至本地交易池中。

根据第一预设时间段轮询本地交易池，获取本地交易池中的多笔待上链交易。

通过批量上链接口将多笔待上链交易同时上传至区块链中。

通过批量查询接口同时查询多笔已上链交易的交易结果，多笔待上链交易与多笔已上链交易对应。

本申请实施例第二方面提供了一种交易上链的处理装置，该处理装置包括上链交易平台。上链交易平台通过交易上传接口与具有钱包系统的上层应用相连，且上链交易平台通过批量上链接口/批量查询接口与区块链相连。该处理装置包括：

接收单元，用于通过交易上传接口接收上层应用输入的交易信息。

处理单元，用于对上层应用输入的交易信息进行处理，生成待上链交易。

存储单元，用于将待上链交易暂存至本地交易池中。

获取单元，用于根据第一预设时间段轮询本地交易池，获取本地交易池中的多笔待上链交易。

处理单元，还用于通过批量上链接口将多笔待上链交易同时上传至区块链中。

查询单元，用于通过批量查询接口同时查询多笔已上链交易的交易结果，多笔待上链交易与多笔已上链交易对应。

本申请实施例第三方面提供了一种电子设备，包括：存储器和处理器，存储器和所述处理器耦合。

存储器用于存储一条或多条计算机指令。

处理器用于执行一条或多条计算机指令，以实现上述第一方面的交易上链方法。

本申请实施例第四方面还提供了一种计算机可读存储介质，其上存储有一条或多条计算机指令，其特征在于，该指令被处理器执行以实现上述任意一种技术方案所述的一种交易上链方法。

与现有技术相比，本申请实施例具有以下优点：

在本申请实施例中，上链交易平台提供了交易上传接口、批量上链接口和批量查询接口。其中，交易上传接口和上层应用相连，用于接收交易信息。该交易信息可以是合约部署信息，也可以是普通交易信息。在合约部署阶段，交易上传接口中的合约部署接口可以直接接收上层应用输入的原始合约代码编译后对应的合约二进制文件和应用二进制进口文件ABI，然后基于两者实现合约部署。这样，不需要将原始合约代码转换为Java代码，再调用对应的Java方法来部署合约。因此消除了原始合约代码编译转化为Java代码的流程，使得任意合约都可以直接调用交易上传接口进行合约部署，实现了合约的通用化部署。而在普通交易上链阶段，上链交易平台可以根据上层应用输入的交易信息生成待上链交易，并将待上链交易暂存在本地交易池中，然后根据预设时间轮询本地交易池，最后通过批量上链接口将多笔待上链交易同时上传至区块链中，同时还可以通过批量查询接口同时查询多笔待上链交易的交易结果。这样，就可以通过批量上链接口和批量查询接口同时对多笔待上链交易进行上链和交易结果查询，在实现合约的交易通用化以及合约的查询通用化的同时，提高了交易上链效率和交易结果查询效率。

附图说明

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

图1是本申请实施例提供的上链交易平台的结构示意图；

图2是本申请实施例提供的交易上链方法的流程示意图；

图3是本申请实施例提供的另一种交易上链方法的流程示意图；

图4是本申请实施例提供的交易上链的处理装置的结构示意图；

图5是本申请实施例提供的电子设备的结构示意图。

具体实施方式

本申请实施例提供了一种交易上链方法、装置、电子设备及存储介质。其中，上链交易平台提供了交易上传接口、批量上链接口、和批量查询接口。通过调用交易上传接口中的合约部署接口可以实现智能合约的通用化部署。通过批量上链接口可以将多笔待上链交易同时上传至区块链中，同时通过批量查询接口可以同时查询多笔交易的交易结果，从而提高了交易上链效率和交易结果查询效率。

为了使本领域的技术人员能够更好的理解本申请的技术方案，下面结合本申请实施例中的附图，对本申请进行清楚、完整地描述。但本申请能够以很多不同于上述描述的其他方式进行实施，因此，基于本申请提供的实施例，本领域普通技术人员在不经过创造性劳动的情况下，所获得的所有其他实施例，都应属于本申请保护的范围。

需要说明的是，本申请的权利要求书、说明书及附图中的术语“第一”、“第二”、“第三”等是用于区别类似的角色，并不用于描述特定的顺序或先后次序。这样使用的数据在适当情况下是可以互换的，以便于本文所描述的本申请的实施例，能够以除了在本文图示或描述的内容以外的顺序实施。此外，术语“包括”、“具有”以及他们的变形形式，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

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

智能合约可以自动化的执行一些预先定义好的规则和条款，是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约是一段代码和数据的集合，它允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。在以太坊中智能合约采用Solidity语言实现。而合约部署和交易是指将智能合约和交易在以太坊区块链上运行，智能合约在以太坊区块链上运行需要将智能合约代码转换为以太坊虚拟机可识别的字节码，而将智能合约成功部署到区块链上后，就会生成对应的合约地址。而基于部署好的智能合约的合约交易可以通过获取合约地址，输入所需参数然后调用合约的方法来完成整个交易过程。

目前，在Java工程中进行合约部署时，首先需要使用工具将智能合约编程语言Solidity的SOL文件编译转换成Java代码，然后再将转换后的Java代码引入到Java工程项目中。这样，在进行交易的时候，就可以调用合约的Java方法来完成相关交易。例如，调用Java代码合约对应的合约部署Java方法和合约交易的Java方法进行合约的部署和交易。具体的，其底层是通过ABI方法组装交易参数，然后通过调用WEB3J的交易接口“eth_sendTransaction”发送交易，在发送交易以后，获得交易哈希值，然后每隔500ms轮询调用交易结果查询接口“eth_getEthTransactionByHash”，可以通过哈希值查询交易结果。

在上述Java工程进行合约部署和交易的过程中，在将智能合约代码进行部署的时候，需要先将Solidity的源码SOL文件编译转换为Java代码，然后把转换后的Java代码引入Java工程，部署合约和交易的时候再调用对应的Java方法。这样，每部署一个合约都需要先将每个合约的源码SOL文件编译转换成Java代码，再把每个合约对应的Java代码引入到Java工程中，最后再根据不同合约的Java代码调用其对应的Java方法。由于每个合约都要被编译成Java代码，这会导致合约部署的效率很低，并且无法满足通用化的合约部署。而且，在现有的区块链系统中，交易是通过调用“eth_sendTransaction”接口单笔发送交易的，并且是通过调用“eth_getEthTransactionByHash”接口单笔查询结果。交易是单笔上链，交易结果也是单笔查询，导致交易上链和结果查询的效率较低。

针对上述问题，本申请提供了一种交易上链方法、装置、电子设备及存储介质。本申请的上链交易平台提供了交易上传接口、批量上链接口、批量查询接口以及数据查询接口。可以实现合约的通用化部署。并且可以在实现合约的交易通用化以及合约的查询通用化的同时，提高交易上链效率和交易结果查询效率。下面结合具体实施例及附图对本申请所述的上链交易平台、方法、装置、终端以及计算机可读存储介质做进一步详细说明。

图1为本申请实施例提供的一种上链交易平台的结构示意图。如图1所示，该上链交易平台包括交易上传接口101，交易查询接口102、交易打包模块103、交易异步处理模块104、批量上链接口105、批量查询接口106、合约链上数据查询接口107、本地交易池108以及数据库模块109。

其中，交易上传接口101和具有钱包系统的上层应用相连，用于接收上层应用输入的交易信息。具体的，交易上传接口101包括合约部署接口和交易输入接口。

当交易信息为合约部署交易信息时，合约部署接口接收上层应用输入的合约部署交易信息，该合约部署交易信息包括原始合约代码文件和第一应用请求编号。而当交易信息为合约交易信息的时候，则交易输入接口接收上层应用输入的合约交易信息，该合约交易信息包括第二应用交易请求编号、ABI文件调用信息和ABI文件输入参数。

其中，交易查询接口102与上层应用相连，交易查询接口102用于接收上层应用发送的交易结果查询请求，具体的，交易查询接口102可能接收上层应用发送的第一交易结果查询请求，该第一交易结果查询请求包括第一交易业务单号或第一应用交易请求编号，其与合约部署对应。当上链交易平台接收到第一交易结果查询请求后，就需要响应第一交易结果查询请求，然后查询该第一交易业务单号或第一应用交易请求编号对应的第一回执事件信息。具体的，若第一交易业务单号或第一应用交易请求编号对应的智能合约部署成功时，就向上层应用反馈合约地址信息以及该智能合约对应的ABI文件等。如果第一交易业务单号或第一应用交易请求编号对应的智能合约部署失败时，就向上层应用反馈上链失败信息。

交易查询接口102可能接收上层应用发送的第二交易结果查询请求，该第二交易结果查询请求包括第二交易业务单号或第二应用交易请求编号，其与普通交易相关。同理，当上链交易平台接收到第二交易结果查询请求后，就需要响应第二交易结果查询请求，然后查询该第二交易业务单号或第二应用交易请求编号对应的第二回执事件信息。具体的，若第二交易业务单号或第二应用交易请求编号对应的交易上链成功时，就向上层应用反馈该交易调用的智能合约对应的ABI文件、该笔交易的交易结果等。如果第二交易业务单号或第二应用交易请求编号对应的交易上链失败时，就向上层应用反馈上链失败提示。

交易打包模块103用于根据交易信息来进行交易打包，获得待上链交易。其中，待上链交易可以是待上链的合约部署交易，也可以是待上链的合约交易。示例性的，如果是合约部署过程，交易打包模块103可以对原始合约代码文件进行编译，得到原始合约代码文件对应的合约二进制文件和原始合约代码文件对应的应用二进制接口ABI文件。其中，ABI文件包括原始合约代码文件的构造函数文件、交易方法、查询方法以及事件等。然后，交易打包模块103会将合约二进制文件和构造函数文件进行打包处理，生成待签名合约部署交易。接着就会调用上层应用的钱包签名服务对待签名合约部署交易进行签名，将待签名交易和签名组合，得到待上链合约部署交易。同时还将计算待上链合约部署交易对应的第一交易哈希值。

而如果是合约交易，交易打包模块103将根据交易信息中的ABI文件调用信息确定数据库模块109中的待调用ABI文件，然后对待调用ABI文件对应的合约地址信息、待调用ABI文件对应的编号和ABI文件输入参数进行打包处理，生成待签名合约交易，然后交易打包模块103调用上层应用的钱包签名服务对待签名合约交易进行签名，将待签名交易和签名组合，得到待上链合约交易。同时还将计算计算待上链合约交易对应的第二交易哈希值。

同时，无论是合约部署过程，还是合约交易上链过程，交易打包模块103在得到待上链交易时，都需要在数据库模块109中存储待上链交易的对应关系。例如，在合约部署过程中，交易打包模块需要在数据库模块109中存储合约部署交易对应的ABI文件和合约二进制文件，并且在存储完之后，生成该合约部署交易对应的第一交易业务单号。然后建立第一应用交易请求编号、ABI文件、合约二进制文件、第一交易哈希值以及第一交易业务单号的第一对应关系，并在数据库模块109中存储第一对应关系。接着，上链交易平台需要将第一交易业务单号通过合约部署接口发送给上层应用，用于向上层应用反馈该合约部署交易接收成功。

例如，在合约交易上链过程中，交易打包模块103在数据库模块109中存储完第二应用交易请求编号和第二交易哈希值的对应关系之后，生成合约交易对应的第二交易业务单号。然后交易打包模块103建立第二应用交易请求编号、第二交易哈希值以及第二交易业务单号的第二对应关系，并在数据库模块中存储第二对应关系。最后上链交易平台将第二交易业务单号通过交易输入接口发送给上层应用，第二交易业务单号用于向上层应用反馈合约交易接收成功。

在得到待上链交易以后，交易打包模块103就将待上链交易放入本地交易池108中。此时，交易异步处理模块104根据第一预设时间轮询本地交易池108，获取本地交易池108中的多笔待上链交易，并通过批量上链接口105将多笔待上链交易同时上传至区块链中，以实现交易批量上链的目的。

同时，在批量上链接口105将多笔待上链交易同时上传至区块链以后，交易异步处理模块104就需要定时的批量查询区块链，通过批量查询接口106定时获取多笔已上链交易的交易结果。可以理解的，多笔已上链交易与之前的多笔待上链交易是对应的。在批量的获取到多笔已上链交易的交易结果之后，就需要解析多笔已上链交易的交易结果，根据每一笔已上链交易的交易哈希值在数据库109中存储这些已上链交易的交易结果。

接着，当上层应用需要获取某一个交易的交易结果时，就需要通过交易查询接口102向交易上链平台发送交易结果查询请求。此时，交易异步处理模块104可以响应交易结果查询请求，根据数据库中的第一对应关系确定第一交易业务单号或第一应用交易请求编号对应的第一交易哈希值，然后在数据库模块109中查询第一交易哈希值对应的交易结果，该交易结果包括第一回执事件信息、合约地址信息、上链失败信息或ABI文件的编号等。然后交易异步处理模块104再通过交易查询接口102将第一交易哈希值对应的第一回执事件信息、合约地址信息或者上链失败信息和ABI文件的编号发送给上层应用。或者，交易异步处理模块104还用于根据第二对应关系确定第二交易业务单号或第二应用交易请求编号对应的第二交易哈希值，在数据库模块109中确定第二交易哈希值对应的交易结果，例如第二回执事件信息和上链结果信息等。最后通过交易查询接口102将第二交易哈希值对应的第二回执事件结果和上链结果信息等发送给上层应用。

最后，交易异步处理模块104还需要监测各个上链交易的交易结果查询情况，如果确定在第二预设时间段内有一个已经发送上链目标待上链交易的交易结果一直没有查到，那么交易打包模块103就需要重新为该目标待上链交易计算交易哈希值，并且把该目标待上链交易重新放入本地交易池中，以再次上链。

其中，批量上链接口105和区块链相连，用于将多笔待上链交易同时上传至所述区块链中。

其中，批量查询接口106和区块链相连，用于同时查询多笔待上链交易的交易结果。

其中，本地交易池107用于存储待上链的合约部署交易和合约交易。

其中，数据库模块109用于存储第一应用交易请求编号、ABI文件、合约二进制文件、第一交易哈希值以及第一交易业务单号的第一对应关系。存储第二应用交易请求编号、第二交易哈希值以及第二交易业务单号的第二对应关系。数据库模块109还用于在交易异步处理模块104解析完多笔待上链交易的交易结果后，按照交易哈希值存储合约部署交易对应的第一回执事件信息和合约地址信息或上链失败信息，存储合约交易的第二回执事件结果和上链结果信息。

结合上述交易上链平台，下面对交易上链的过程进行详细的介绍。图2为本申请实施例提供的一种交易上链方法的流程示意图。需要说明的是，该流程示意图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，同时，在某些情况，可以以不同于该流程示意图中示出的逻辑顺序执行所释出的步骤。

如图2所示，该交易上链方法包括以下几个步骤：

201、通过交易上传接口接收上层应用输入的交易信息。

上链交易平台是通过交易上传接口来接收上层应用输入的交易信息的。其中，上层应用输入的交易信息可以是合约部署交易信息，也可以是普通的合约交易信息。而交易上传接口包括合约部署接口以及交易输入接口。若交易信息是合约部署交易信息时，就调用专门的合约部署接口来向上链交易平台发送合约部署交易信息。若交易信息是合约交易信息，则调用交易上传接口来向上链交易平台发送合约交易信息。

其中，合约部署交易信息对应合约部署交易。合约部署交易是指将智能合约代码发送到区块链上运行，用来确定交易的规则，其部署过程也是一种特殊的交易过程。而合约交易交易信息对应合约交易，是指调用已部署好的合约来实现的账号交易。其中，合约部署交易信息包括原始合约代码文件和第一应用请求编号，而合约交易信息包括第二应用交易请求编号、需要调用的合约(已存在的)的ABI文件调用信息以及ABI文件输入参数。

其中，第一应用请求编号和第二应用请求编号是可以用来唯一标识合约部署交易信息和合约交易信息的编号，每一个合约部署交易和每一个合约交易都对应唯一的应用请求编号。ABI调用信息用于指示合约交易需要调用的已经部署好的ABI文件的构造函数，ABI文件输入参数是指在调用目标ABI构造函数时需要输入的交易参数。

202、对上层应用输入的交易信息进行处理，生成待上链交易。

在接收到上层应用输入的交易信息后，就需要对交易信息进行打包处理，生成可以上传至区块链的待上链交易。打包处理的过程将在下面实施例中具体介绍，在此不做赘述。

203、将待上链交易暂存至本地交易池中。

上链交易平台在生成待上链交易之后，不会立即将待上链交易发送到区块链中，而是先将待上链的交易存储在本地交易池中。这样，本地交易池将不断接收到多笔需要发送到区块链上的合约部署交易或合约交易，即本地交易池用于暂存待上链交易。

204、根据第一预设时间段轮询本地交易池，获取本地交易池中的多笔待上链交易。

上链交易平台将根据预设的时间周期来轮询本地交易池，确定第一预设时间段内本地交易池接收并存储的多笔待上链交易。其中，第一预设时间可以根据待上链交易生成的数量和速度来提前预设，示例性的，可以确定第一预设时间段为500ms，即上链交易平台需要每隔500ms轮询本地交易池，获取本地交易池在该500ms内存储的多笔待上链交易。

205、通过批量上链接口将多笔待上链交易同时上传至区块链中。

上链交易平台在向区块链发送待上链交易时，不是单笔单笔发送的，而是通过批量上链接口一次性上传多笔待上链交易。具体的，上链交易平台根据预设时间周期来轮询本地交易池，获取第一预设时间段内暂存在本地交易池中的多笔待上链交易，然后通过批量上链接口，将多笔待上链交易同时上传到区块链中。待上传成功后，就清空本地交易池。

206、通过批量查询接口同时查询并存储多笔已上链交易对应的交易结果。

上链交易平台完成多笔待上链交易的上传步骤后，就需要及时查询多笔待上链交易的交易结果，以此来判断多笔待上链交易是否上传成功。在本实施例中，上链交易平台也不是单笔单笔查询交易结果的，而是通过批量查询接口成批的查询多笔已上链交易的交易结果的。具体的，上链交易平台将第一预设时间段内多笔待上链交易成批的上传至区块链，完成上传过程，然后通过批量查询接口及时查询该批已上链交易的交易结果，可以理解的，待上链交易与已上链交易是对应的。如果查询到某一笔已上链交易的交易结果，那么就在数据库中存储该笔交易对应的交易结果。如果未查询到某一笔已上链交易的交易结果，说明该笔交易上链失败，那么就在数据库中存储该笔交易的交易结果为交易失败，或者对该笔交易重新打包，再次尝试上链。

其中，每一笔交易在打包过程中均对应一个交易哈希值，交易哈希值用于寻找该笔交易对应的区块链区块。因此，在查询多笔已上链交易的交易结果时，需要根据每一笔已上链交易的交易哈希值来查询区块链上对应的区块。同时，在存储查询到的交易结果后，需要在数据库中存储交易、交易哈希值和交易结果的对应关系。

207、通过交易查询接口接收上层应用发送的交易结果查询请求。

上链交易平台批量上传完多笔交易后，会将上传成功的多笔交易的交易结果进行存储。然后，当上层应用需要查询某一笔交易的交易结果时，需要通过交易查询接口来发送的交易结果查询请求，可以理解的，交易结果查询请求包括有该笔交易的交易信息，示例性的，可以是应用交易请求编号，或交易业务单号等，这些交易信息可以唯一确定某一笔交易，即能通过交易结果查询请求中的交易信息唯一确定某一笔交易的交易哈希值。

208、响应交易结果查询请求，确定交易查询请求对应的目标交易哈希值。

上链交易平台在接收到交易结果查询请求后，就响应该交易结果查询请求，确定交易查询请求对应的目标交易哈希值。然后在数据库中查询目标交易哈希值对应的交易结果。

209、在存储的多笔待上链交易对应的交易结果中确定目标交易哈希值对应的交易结果。

210、通过交易查询接口将目标交易哈希值对应的交易结果发送给上层应用。

最后，交易上链平台通过交易查询接口将查询到的交易结果发送给上层应用，完成查询过程。可以理解的，上层应用可以调用交易查询接口查询任意一笔交易的交易结果，实现单笔交易查询的目的。

在本申请实施例中，上链交易平台提供了交易上传接口、批量上链接口和批量查询接口。其中，交易上传接口和上层应用相连，用于接收交易信息。该交易信息可以是合约部署信息，也可以是普通交易信息。在合约部署阶段，交易上传接口中的合约部署接口可以直接接收上层应用输入的原始合约代码编译后对应的合约二进制文件和应用二进制进口文件ABI，然后基于两者实现合约部署。这样，不需要将原始合约代码转换为Java代码，再调用对应的Java方法来部署合约。因此消除了原始合约代码编译转化为Java代码的流程，使得任意合约都可以直接调用交易上传接口进行合约部署，实现了合约的通用化部署。而在普通交易上链阶段，上链交易平台可以根据上层应用输入的交易信息生成待上链交易，并将待上链交易暂存在本地交易池中，然后根据预设时间轮询本地交易池，最后通过批量上链接口将多笔待上链交易同时上传至区块链中，同时还可以通过批量查询接口同时查询多笔待上链交易的交易结果。这样，就可以通过批量上链接口和批量查询接口同时对多笔待上链交易进行上链和交易结果查询，在实现合约的交易通用化以及合约的查询通用化的同时，提高了交易上链效率和交易结果查询效率。

下面对合约部署上链的过程进行详细的说明。图3为本申请实施例提供的一种合约部署交易的上链方法的结构示意图，如图3所示，该方法包括以下几个步骤。

301、上层应用通过合约部署接口向交易上链平台输入合约部署交易信息。

其中，合约部署交易信息可以包括solidity原始合约代码文件，合约名称，构造参数，第一应用交易请求编号，钱包编号等。其中，第一应用交易请求编号用于标记该笔合约部署交易。而上层应用是指需要进行合约部署的应用程序，例如，可以是NFT应用、存证应用等。Solidity则是一门面向合约的，为实现智能合约而创建的高级编程语言，Solidity语言是运行在以太坊虚拟机上的语言。Solidity原始合约代码文件通常以SOL作为扩展名。

下面以NFT应用(上层应用)为例对合约部署交易信息中的各项信息进行简单说明：

NFT的合约源文件可以是NFT.sol合约源文件代码。而合约名称是指NFT应用输入的合约源文件的名称，用户可以通过自定义合约名称来标识当前合约。第一应用交易请求编号则是指NFT应用发起的该笔合约部署交易的请求编号，用于唯一标识该笔合约部署交易。而钱包编号也可以称为钱包地址，是指发送交易的钱包账号。构造参数则是指部署合约的构造方法所需要输入的参数，可以用于合约的初始化。

302、上链交易平台对原始合约代码文件进行编译，得到原始合约代码文件对应的合约二进制文件和应用二进制接口ABI文件。

上层应用调用上链交易平台的合约部署接口，将合约部署交易信息发送至上链交易平台，然后上链交易平台对原始合约代码文件进行编译，得到原始合约代码文件对应的合约二进制文件和原始合约代码文件对应的应用二进制接口ABI文件。示例性的，可以使用Solidty编译工具“solc”对原始合约代码文件进行编译，得到原始合约代码文件对应的二进制文件和原始合约代码文件对应的应用二进制接口ABI文件。

其中，原始合约代码文件对应的ABI文件是可以运行在区块链上的字节码文件。一个合约要部署到区块链上，就需要编译成以太坊可以识别的字节码文件。原始合约代码文件对应的应用二进制接口ABI文件是程序间互动的接口，是供应用程序调用的文件，ABI文件包括了应用调用需要的构造函数、交易方法、查询方法和事件等。

下面对ABI文件的构造函数、交易方法、查询方法和事件进行解释说明。

1、构造函数是合约的构造方法，是指在合约部署的时候调用的方法。

示例性的，NFT合约的构造方法可以是：

2、交易方法是指合约交易时调用的方法。例如：NFT销毁接口的代码可以是functionburnNFT(uint256 tokenId)；，在需要销毁某个接口时，调用该代码，输入tokenId编号后即可销毁该编号对应的接口。

3、查询方法是指该合约对应的区块链上数据查询的方法，通常会返回查询结果的参数。例如，获取tokenId元信息查询接口：

queryNftByTokenId(uint256 tokenId)public view returns(string,string,string,address)

查询tokenId元信息时，就可以调用该方法，输入tokenId编号。这样，区块链就会返回tokenId元数据的名称、图片信息、描述信息、和持有者区块链地址信息等。

4、事件用于将数据记录成日志(log)保存到区块链上，用于在合约交易的时候，输出区块链上的log事件。通常在交易的回执数据中返回，用于查看结果数据。例如销毁NFT-tokenId成功后，则会产生转让事件：

event Transfer(address indexed from,address indexed to,uint256indexed tokenId)；

Transfer(owner,address(0),tokenId)；

上述事件描述了tokenId从token拥有者转让到0地址。

通过上述步骤，在进行合约部署交易的部署时，上链交易平台直接将合约原始代码文件编译成合约二进制文件和应用二进制接口ABI文件，然后通过直接输入合约二进制文件和应用二进制接口ABI文件来实现合约部署过程。这样，在进行合约部署的时候，不需要将每一个合约原始代码文件先转换成Java文件，然后再通过调用对应的Java合约部署方法和Java合约交易方法来部署合约。这样，就可以消除原始合约代码文件转换为Java文件的流程，简化了合约部署流程，使得任意合约都可直接通过合约二进制文件和ABI文件来进行部署部署，实现了通用化的合约部署流程。

303、上链交易平台记录ABI文件列表和交易请求编号的对应关系。

具体的，上链交易平台记录ABI列表，该ABI列表即为ABI的构造函数、交易方法、查询方法和事件、时间等的集合列表。在合约部署交易中，需要将编译得到的ABI文件进行存储，示例性的，可以以ABI列表的形式来存储一笔合约部署交易对应的多个ABI文件。同时，上链交易平台记录合约部署交易的ABI列表和第一交易请求编号的对应关系，用于对该笔合约部署交易进行标记。这样，可以方便后续交易和交易结果查询的时候，通过第一交易请求编号查询到合约的ABI列表。也方便对该合约的ABI列表的交易方法、查询方法等进行调用。

304、上链交易平台基于合约部署交易信息中的构造参数，进行数据格式转化。

在合约部署阶段，需要将合约部署交易中的数据的数据格式从java类型转化solidity的数据类型，再将solidity的数据类型转化为RLP格式。

递归长度前缀(Recursive Length Prefix，RLP)，提供了一种适用于任意二进制数据数组的编码，是以太坊中对对象进行序列化的主要编码方式，RLP是以太坊中最常使用的序列化格式方法。因此，如果交易要在以太坊区块链上运行，就需要把其他类型的数据格式转化为以太坊区块链序列化指定的格式。

在本步骤中，首先，根据合约的构造方法和构造参数的数据格式，将上层应用的Java类型的数据的格式转化为和合约的构造方法和构造参数的数据格式匹配的web3j.type类型，然后再将web3j.type类型转换为以太坊的序列化的RLP格式，从而使得合约可以在以太坊区块链上运行。

305、上链交易平台对合约二进制文件和ABI文件中的构造函数文件进行打包处理，生成待签名合约部署交易。

上链交易平台将合约二进制文件，构造函数文件、构造参数，区块链相关参数等数据进行打包，得到待签名交易。其中，区块链相关参数包括链的块高、nonce等数据。链的块高也就是区块高度，是区块链接在主链的个数，代表着区块的编号，而交易的随机数(nonce)代表交易次数，用来记录账户已执行的交易总数。

306、上链交易平台调用钱包服务，得到待签名合约部署交易对应的签名。

上链交易平台在打包好合约部署交易后，调用钱包服务，输入钱包编号和钱包区块链地址。得到合约部署交易对应的签名数据，以便后续利用该签名数据对待签名合约部署交易进行签名。

307、计算待上链合约部署交易对应的第一交易哈希值。

首先，在进行数字签名时，需要先对待签名合约部署交易，也就是打包好的RLP编码的交易序列化消息进行经过哈希计算，哈希计算是指利用哈希函数把任意长度的消息映射成为一个长度较短且长度固定的值，该值即为哈希值，哈希值可以作为一段数字内容唯一的标识。在本申请中，待签名合约部署交易数据经过哈希计算后，缩短为一段字符串，也就是交易哈希值，交易哈希值用来指示区块链上的地址。

308、上链交易平台利用签名对待签名合约部署交易进行签名，得到待上链合约部署交易。

示例性的，上链交易平台获取钱包私钥，利用钱包私钥对待签名合约部署交易进行签名，得到最终的待上链合约部署交易，也就是待发送给区块链的交易数据。

下面，对数字签名的过程进行简单介绍：

数字签名主要用来验证交易的发出方的合法性，防止交易过程中信息不被篡改，用于确认用户身份以及保障信息无法抵赖。可以理解的是，发送方用自己的私钥，对待签名的合约部署交易信息进行加密。

309、上链交易平台生成第一交易业务单号，建立并存储第一应用交易请求编号、ABI文件、合约二进制文件、第一交易哈希值、第一交易业务单号的对应关系。

上链交易平台在生成待上链合约部署交易后，就生成本次合约部署的第一交易业务请求单号，然后在数据库中存储该笔合约部署交易的交易时间，以及第一应用交易请求编号、ABI文件、合约二进制文件、交易哈希值、第一交易业务单号的对应关系。然后标记该笔合约部署交易的状态为上链中。其中，第一应用交易请求编号、第一交易业务单号以及交易哈希值一一对应，用于关联该笔合约部署交易的所有参数。而第一应用交易请求编号和第一交易业务单号以及交易哈希值都可以用来标识该笔交易，在后续的查询过程中也可以利用任意一个来查询合约部署交易的交易结果。

310、上链交易平台将待上链合约部署交易放入本地交易池中。

上链交易平台在将待上链合约部署交易放入到本地交易池以后，则可以向上层应用反馈该笔合约交易已经接收成功，然后对上层应用返回第一交易业务单号。其中，本地交易池可以暂存多笔待上链的交易，包括多笔合约部署交易和多笔合约交易。上链交易平台可以将一定的时间内接收到的多笔交易成批的上传至区块中。

311、上链交易平台通过批量上传接口将待上链合约部署交易发送到区块链上。

上链交易平台的交易池可以不断接收来自上层应用的合约部署交易和合约交易，并将这些交易存储到本地交易池，这样，上链交易平台就可以根据预设的时间，例如，预设时间是500ms，成批的进行交易上链。比如上链交易平台可以每隔500ms获取交易池中的多笔待上链的交易，然后通过批量上传接口，将这些待上链交易批量上传到区块链上。

上链交易平台通过批量上传接口，实现了本地交易池中的待上链的多笔交易批量上传到区块链上的目的，解决了现有的区块链系统中每次只能有一笔交易上链，大大提高了交易上链的效率。

312、上链交易平台使用批量查询接口查询待上链合约部署交易对应的交易结果，并解析交易结果。

批量查询接口支持上链交易平台一次性查询多笔待上链的交易的交易结果，并返回交易结果。

在本申请的一个实施例中，上链交易平台使用交易哈希值，通过批量查询接口不断轮询，同时查询多笔交易的交易结果，在获得某笔交易的交易结果时，就需要解析交易结果，并对该笔交易的交易结果进行存储。

示例性的，上链交易平台可以通过异常定时器，拉取长时间未成功上链交易的交易数据。具体的，上链交易平台可以查询区块链多次，如果在区块链中一直查询不到交易哈希对应的交易数据，或者根据交易数据库的更新信息，如果数据库中该笔交易信息超过10分钟，在数据库信息查询不到该笔交易在数据库中的交易信息的更新数据。那么就可以判断可能是因为网络等原因，该笔交易没有被区块链接收。此时，上链交易平台重新打包合约交易参数，得到待签名的新的交易，通过新的待签名的交易，得到新的哈希值和待发送的新的待上链交易，然后根据交易请求编号更新数据库中的该交易的哈希值，接着重新对该交易进行上链，直到交易上链并解析出交易结果。

示例性的，若合约部署交易交易成功，上链交易平台就可以通过交易结果解析出部署成功合约的合约地址。如果交易失败，则会返回交易失败的错误信息。

313、上链交易平台在数据库中存储待上链合约部署交易的交易结果。

在完成结果解析后，上链交易平台需要将合约地址，回执结果列表，ABI文件列表，交易哈希值、交易结果等存储到数据库中，并更新该笔交易的数据库，然后把该笔交易的交易状态记录为交易成功，此时，该笔交易结束。最终第一应用交易请求编号、第一交易业务单号以及交易哈希值都是一一对应的，可以唯一确定标识该笔合约部署交易。

314、上层应用通过第一应用交易请求编号或者第一交易业务单号查询交易结果。

上层应用通过第一交易请求编号或者第一交易业务单号从上链交易平台的数据库中查询该笔合约部署的结果，如果合约部署交易成功，则可以通过第一交易请求编号或者第一交易业务单号得到存储在数据库中的该笔合约部署交易的合约地址，ABI文件列表，回执结果列表、交易成功的结果等信息，如果合约部署交易失败，也可以从数据库中读取该笔交易交易失败的错误信息。

在上述本申请实施例所提供的技术方案，上链交易平台可以直接根据上层应用输入的合约源码文件编译后得到的合约二进制文件和应用二进制进口文件ABI进行合约部署。不需要将合约源码文件转换为Java代码，再调用对应的Java方法来部署合约，这样消除了合约源码文件编译转化为Java代码的流程，使得任意合约都可以直接通过交易上传接口进行合约部署，实现了合约的通用化部署。而上链交易平台可以将待上链的合约部署交易暂存在本地交易池中，然后根据预设时间轮询本地交易池，通过批量上链接口将多笔待上链的交易同时上传至所述区块链中，通过批量查询接口同时查询多笔已上链的交易的交易结果。通过批量上链接口和批量查询接口同时对多笔待上链交易进行上链和交易结果查询，提高了交易上链效率和交易结果查询效率。

结合上述实施例，下面对普通的合约交易的上链过程进行介绍，可以理解的，合约交易的上链过程与合约部署交易的上链过程类似，仅在某些部分，例如打包处理过程中存在差距，下面将着重介绍合约交易上链过程中与合约部署交易不同的地方，对类似的步骤不再进行赘述。

首先，上层应用需要调用交易输入接口向交易上链平台输入合约交易信息。由于合约交易是基于部署好的合约进行的交易，那么合约交易信息中包括第二应用交易请求编号，需要调用的合约的ABI编号、合约地址、和ABI参数，钱包编号等。其中，合约交易可以调用已经成功上链的合约部署交易的交易构造方法。合约交易信息中的ABI编号则是本次交易需要调用的合约的ABI文件的标识。ABI编号能够唯一确定一个已上链的合约，上链交易平台可以通过ABI编号来查找对应的ABI文件，进而找到ABI对应的构造方法。而ABI参数是指合约交易调用ABI文件中的构造方法时为该方法输入的参数值。

接着，上链交易平台在接收到合约交易信息后，会对合约地址，ABI编号、ABI参数、钱包编号等进行打包，得到待签名的合约交易。具体的，上链交易平台根据ABI编号查询数据库中该编号对应的ABI文件中的构造方法和构造参数，然后根据查询到的构造方法和数据类型与输入的调用的方法和参数进行匹配。例如，输入的ABI方法是否是对应的交易方法，ABI的对应参数的个数和数据格式是否和输入的参数的个数和数据格式一致等。如果ABI编号和参数以及方法匹配一致，则将合约地址，ABI编ABI编号、合约地址、ABI参数、钱包编号等数据打包组装成待签名合约交易。

接着，上链交易平台在打包好合约交易后，调用钱包服务，输入钱包编号和钱包区块链地址。得到合约交易对应的签名数据，然后利用签名数据对待签名合约交易进行签名。其中，在进行数字签名时，需要先对待签名合约交易进行哈希计算，得到该笔合约交易的交易哈希值，然后上链交易平台获取钱包私钥，利用钱包私钥对待签名合约交易进行签名，得到最终的待上链合约交易，也就是待发送给区块链的合约交易数据。

接着，上链交易平台会生成合约交易对应的第二交易业务单号，建立并存储第二应用交易请求编号、第二交易哈希值、第一交易业务单号的对应关系。并且标记该笔合约交易的状态为上链中。其中，第二应用交易请求编号、第二交易业务单号以及交易哈希值一一对应，用于关联该笔合约交易的所有参数。而第二应用交易请求编号和第二交易业务单号以及交易哈希值都可以用来标识该笔交易，在后续的查询过程中也可以利用任意一个来查询合约交易的交易结果。

最后，上链交易平台将打包好的待上链合约交易发送的本地交易池中进行暂存，然后通过批量上传接口同时上传本地交易池中的多笔待上链的交易。然后上链交易平台还需要通过批量查询接口同时查询多笔交易的交易结果。其中，如果是合约交易，则需要轮询合约的ABI事件列表，解析出ABI列表中匹配的交易事件，然后将事件的结果，回执结果列表，交易哈希等存储到数据库中，然后把该笔交易的交易状态记录为交易成功，此时，该笔交易结束。如果交易失败，则会返回交易失败的错误信息，将错误信息存储到数据库中，同时将该笔交易的交易状态记录为交易失败。

图4为本申请实施例提供的一种交易上链的处理装置的结构示意图，以下结合图4对本实施例提供的进行详细描述。以下描述所涉及的实施例用于解释本申请的技术方案，并不是实际使用的限定。如图4所示，处理装置包括上链交易平台，上链交易平台通过交易上传接口与具有钱包系统的上层应用相连，且上链交易平台通过批量上链接口/批量查询接口与区块链相连，该处理装置包括：

接收单元401，用于通过交易上传接口接收上层应用输入的交易信息。

处理单元402，用于对上层应用输入的交易信息进行处理，生成待上链交易。

存储单元403，用于将待上链交易暂存至本地交易池中。

获取单元404，用于根据第一预设时间段轮询本地交易池，获取本地交易池中的多笔待上链交易。

处理单元402，还用于通过批量上链接口将多笔待上链交易同时上传至区块链中。

查询单元405，用于通过批量查询接口同时查询多笔已上链交易的交易结果，多笔待上链交易与多笔已上链交易对应。

在一个可选的实施方式中，上链交易平台与上层应用相连的交易查询接口。该装置还包括发送单元406。查询单元405，具体用于确定多笔已上链交易对应的多个交易哈希值，根据多笔已上链交易对应的多个交易哈希值，同时查询区块链中多笔已上链交易中每一笔已上链交易对应的交易结果。

存储单元403，还用于存储每一笔已上链交易对应的交易结果。

接收单元401，还用于通过交易查询接口接收上层应用发送的交易结果查询请求。

处理单元402，还用于响应交易结果查询请求，确定交易结果查询请求对应的目标交易哈希值。

发送单元406，用于通过交易查询接口将目标交易哈希值对应的交易结果发送给上层应用。

在一个可选的实施方式中，交易上传接口包括合约部署接口，交易信息为合约部署交易信息。合约部署交易信息包括原始合约代码文件和第一应用交易请求编号，待上链交易包括待上链合约部署交易。

处理单元402，具体用于对原始合约代码文件进行编译，得到原始合约代码文件对应的合约二进制文件和原始合约代码文件对应的应用二进制接口ABI文件。其中，ABI文件包括构造函数文件。对合约二进制文件和构造函数文件进行打包处理，生成待签名合约部署交易。

获取单元404，还用于调用上层应用的钱包签名服务，获得上层应用对应的签名。

处理单元402，具体用于利用签名对待签名合约部署交易进行签名，得到待上链合约部署交易。

在一个可选的实施方式中，处理单元402，还用于在存储单元403存储待上链合约部署交易对应的ABI文件和合约二进制文件之后，生成待上链合约部署交易对应的第一交易业务单号。计算待上链合约部署交易对应的第一交易哈希值。建立第一应用交易请求编号、ABI文件、合约二进制文件、第一交易哈希值以及第一交易业务单号的第一对应关系。

存储单元403还用于存储第一对应关系。

发送单元406，还用于将第一交易业务单号通过合约部署接口发送给上层应用。第一交易业务单号用于向上层应用反馈合约部署交易信息接收成功。

在一个可选的实施方式中，上链交易平台还包括数据库模块，处理单元402，还用于解析多笔已上链交易的交易结果，确定多笔已上链交易中每一笔已上链交易对应的交易结果信息。在多笔已上链交易的交易结果信息中确定第一交易哈希值对应的第一交易结果信息，第一交易结果信息包括第一交易哈希值、第一回执事件信息以及合约地址信息/上链失败信息。

存储单元403，还用于在数据库模块中存储第一回执事件信息和合约地址信息/上链失败信息。

在一个可选的实施方式中，交易查询接口具体用于接收上层应用发送的第一交易结果查询请求。第一交易结果查询请求包括第一交易业务单号/所述第一应用交易请求编号。

处理单元402，还用于响应第一交易结果查询请求，根据第一对应关系确定第一交易业务单号/第一应用交易请求编号对应的第一交易哈希值。

查询单元405，还用于在数据库模块中查询第一交易哈希值对应的第一回执事件信息、合约地址信息/上链失败信息和ABI文件的编号。

发送单元406，还用于通过交易查询接口将第一交易哈希值对应的第一回执事件信息、合约地址信息/上链失败信息和ABI文件的编号发送给上层应用。

在一个可选的实施方式中，交易上传接口包括交易输入接口。交易信息为合约交易信息，合约交易信息包括第二应用交易请求编号、ABI文件调用信息和ABI文件输入参数。待上链交易包括待上链合约交易。

处理单元402，具体用于根据ABI文件调用信息确定数据库模块中的待调用ABI文件。对待调用ABI文件对应的合约地址信息、待调用ABI文件对应的编号和ABI文件输入参数进行打包处理，生成待签名合约交易。

获取单元404，还用于调用上层应用的钱包签名服务，获得上层应用对应的签名。

处理单元402，具体用于根据签名和根据待签名合约交易，得到待上链合约交易。

在一个可选的实施方式中，处理单元402，还用于存储单元403在数据库模块中存储完第二应用交易请求编号和第二交易哈希值的对应关系之后，生成合约交易对应的第二交易业务单号。计算待上链合约交易对应的第二交易哈希值。建立第二应用交易请求编号、第二交易哈希值以及第二交易业务单号的第二对应关系。

存储单元403，还用于在数据库模块中存储第二对应关系。

发送单元406，还用于将第二交易业务单号通过交易输入接口发送给上层应用，第二交易业务单号用于向上层应用反馈合约交易信息接收成功。

在一个可选的实施方式中，处理单元402，还用于在多笔已上链交易的交易结果信息中确定第二交易哈希值对应的第二交易结果信息。第二交易结果信息包括第二交易哈希值、第二回执事件结果以及上链结果信息。

存储单元403，还用于在数据库模块中存储第二交易哈希值对应的第二回执事件结果和上链结果信息。

在一个可选的实施方式中，交易查询接口，具体用于接收上层应用发送的第二交易结果查询请求。第二交易结果查询请求包括第二交易业务单号/第二应用交易请求编号。

处理单元402，还用于响应第二交易结果查询请求，根据第二对应关系确定第二交易业务单号/第二应用交易请求编号对应的第二交易哈希值。在数据库模块中确定第二交易哈希值对应的第二回执事件信息和上链结果信息。

发送单元406，还用于通过交易查询接口将第二交易哈希值对应的第二回执事件结果和上链结果信息发送给上层应用。

在一个可选的实施方式中，处理单元402，还用于确定第二预设时间段内多笔待上链交易中未查询到交易结果的目标待上链交易。将目标待上链交易重新放入本地交易池中。重新为目标待上链交易计算交易哈希值。

在本申请实施例中，上链交易平台提供了交易上传接口、批量上链接口和批量查询接口。其中，交易上传接口和上层应用相连，用于接收交易信息。该交易信息可以是合约部署信息，也可以是普通交易信息。在合约部署阶段，交易上传接口中的合约部署接口可以直接接收上层应用输入的原始合约代码编译后对应的合约二进制文件和应用二进制进口文件ABI，然后基于两者实现合约部署。这样，不需要将原始合约代码转换为Java代码，再调用对应的Java方法来部署合约。因此消除了原始合约代码编译转化为Java代码的流程，使得任意合约都可以直接调用交易上传接口进行合约部署，实现了合约的通用化部署。而在普通交易上链阶段，上链交易平台可以根据上层应用输入的交易信息生成待上链交易，并将待上链交易暂存在本地交易池中，然后根据预设时间轮询本地交易池，最后通过批量上链接口将多笔待上链交易同时上传至区块链中，同时还可以通过批量查询接口同时查询多笔待上链交易的交易结果。这样，就可以通过批量上链接口和批量查询接口同时对多笔待上链交易进行上链和交易结果查询，在实现合约的交易通用化以及合约的查询通用化的同时，提高了交易上链效率和交易结果查询效率。

需要说明的是，装置中各模块/单元之间的信息交互、执行过程等内容，与本申请中图1至图3对应的各个方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

接下来介绍本申请实施例提供的一种电子设备，请参阅图5，图5为本申请实施例提供的电子设备的一种结构示意图。其中，电子设备500上可以部署有图4对应实施例中所描述的交易上链的处理装置，用于实现图1至图4对应实施例中的功能。具体的，电子设备500包括：接收器501、发射器502、处理器503和存储器504(其中执行设备500中的处理器503的数量可以一个或多个，图5中以一个处理器为例)，其中，处理器503可以包括应用处理器5031和通信处理器5032。在本申请的一些实施例中，接收器501、发射器502、处理器503和存储器504可通过总线或其它方式连接。

存储器504可以包括只读存储器和随机存取存储器，并向处理器503提供指令和数据。存储器504的一部分还可以包括非易失性随机存取存储器(non-volatile randomaccess memory，NVRAM)。存储器504存储有处理器和操作指令、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，操作指令可包括各种操作指令，用于实现各种操作。

处理器503控制执行设备的操作。具体的应用中，执行设备的各个组件通过总线系统耦合在一起，其中总线系统除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都称为总线系统。

上述本申请实施例揭示的方法可以应用于处理器503中，或者由处理器503实现。处理器503可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器503中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器503可以是通用处理器、数字信号处理器(digital signal processing，DSP)、微处理器或微控制器，还可进一步包括专用集成电路(application specific integratedcircuit，ASIC)、现场可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。该处理器503可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器504，处理器503读取存储器504中的信息，结合其硬件完成上述方法的步骤。

接收器501可用于接收输入的数字或字符信息，以及产生与执行设备的相关设置以及功能控制有关的信号输入。发射器502可用于通过第一接口输出数字或字符信息；发射器502还可用于通过第一接口向磁盘组发送指令，以修改磁盘组中的数据；发射器502还可以包括显示屏等显示设备。

本申请实施例中，处理器503中的应用处理器5031，用于执行图1至图4施例中的交易上链平台及上链交易方法执行各个步骤的具体方式，与本申请中图1至图4应的各个方法实施例基于同一构思，其带来的技术效果与本申请中图1至图4应的各个方法实施例相同，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质包括计算机指令，计算机指令在被处理器执行时用于实现本申请实施例中任意一种交易上链方法的技术方案。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

其中，计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。