CN117454433B - 交易处理方法及装置 - Google Patents

Abstract

本申请提供了一种交易处理方法及装置，涉及区块链领域。该交易处理方法包括：接收买方端针对目标订单转账的保证金，并生成目标订单的交易标识；将交易标识发送至买方端；接收买方端输入的第一计算结果和第一证明文件，并基于交易标识和第一计算结果，对第一证明文件进行验证；在第一证明文件通过验证的情况下，接收买方端针对目标订单转账的交易金额；接收卖方端输入的目标订单对应的商品验证码和电子签名，并对商品验证码进行合法性验证，对电子签名进行有效性验证；若商品验证码通过合法性验证，并且，电子签名通过有效性验证，则将交易金额转账至卖方端。本申请能够保证交易的安全性，同时，保证卖方在交易过程中的权益。

Description

交易处理方法及装置

技术领域

本申请涉及区块链领域，具体涉及一种交易处理方法及装置。

背景技术

区块链在互联网经济中可以作为虚拟商品交易平台的底层，将交易数据记录在区块中来记账，然而，用于现货交易的区块链存在分叉攻击的风险，具体而言，从区块被广播直至区块达成交易最终性，这个过程需要一定的时间，这为通过分叉攻击取消已广播交易的合法性提供了可能性。

在实际应用场景下，恶意用户首先发起广播，实体商家在看到广播后选择发货，恶意用户一旦看到商品已经完成发货，便可利用被腐蚀者进行分叉攻击，进而将包含该交易的区块独立出去。最终结果是恶意用户获得了相应的现货，却没有完成链上支付。

发明内容

有鉴于此，本申请实施例提供了一种交易处理方法及装置。

第一方面，本申请一实施例提供了一种交易处理方法，包括：响应于买方端的第一交易请求，接收买方端针对目标订单转账的保证金，并生成目标订单的交易标识；将交易标识发送至买方端，以便买方端将交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件；响应于买方端的验证请求，接收买方端输入的第一计算结果和第一证明文件，并基于交易标识和第一计算结果，对第一证明文件进行验证；在第一证明文件通过验证的情况下，响应于买方端的第二交易请求，接收买方端针对目标订单转账的交易金额；响应于卖方端的第一验证请求，接收卖方端输入的目标订单对应的商品验证码和电子签名，并对商品验证码进行合法性验证，对电子签名进行有效性验证；若商品验证码通过合法性验证，并且，电子签名通过有效性验证，则将交易金额转账至卖方端，以及将保证金转账至买方端。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：在第一证明文件通过验证的情况下，若目标时段内未接收到买方端的第二交易请求，则获取卖方端发送的第二计算结果和第二证明文件，第二计算结果和第二证明文件是将第一计算结果输入可验证延迟函数得到的；接收卖方端发送的对第二证明文件的电子签名；响应于卖方端的交易失败指令的执行请求，对第二证明文件的电子签名进行有效性验证，并在第二证明文件的电子签名通过有效性验证时，将保证金提取指令的当前状态修改为暂停执行状态。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：若商品验证码未通过合法性验证，则响应于买方端的保证金冻结终止指令的执行请求，将保证金转账至买方端，并且，将交易失败指令和保证金提取指令的当前状态均修改为暂停执行状态。

结合第一方面，在第一方面的某些实现方式中，将保证金转账至买方端，包括：将电子签名作为输入，以生成保证金提取指令的执行请求；响应于保证金提取指令的执行请求，对电子签名进行有效性验证；若电子签名通过有效性验证，则将保证金转账至买方端，并且，将交易失败指令的当前状态修改为暂停执行状态。

结合第一方面，在第一方面的某些实现方式中，电子签名包括第一电子签名和第二电子签名，其中，第一电子签名是对交易标识和商品验证码执行签名算法得到的，第二电子签名是对第一证明文件执行签名算法得到的。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：确定买方端的身份验证数据和卖方端的身份验证数据；在生成目标订单的交易标识后，将第一交易信息记录在信息验证列表，第一交易信息包括保证金、交易标识、买方端的身份验证数据和卖方端的身份验证数据，以便对买方端和卖方端执行目标订单的交易过程进行验证。

结合第一方面，在第一方面的某些实现方式中，在基于交易标识和第一计算结果，对第一证明文件进行验证之前，还包括：基于交易标识，验证信息验证列表中记录有与交易标识匹配的第一交易信息；在第一证明文件通过验证的情况下，该方法还包括：在信息验证列表中，将第一交易信息修改为第二交易信息，并记录第二交易信息的交易状态为待交易，第二交易信息包括交易标识、保证金、第一计算结果、第一证明文件、以及可验证延迟函数的第一时间参数；在将保证金转账至买方端之后，该方法还包括：将第二交易信息的交易状态修改为已交易。

结合第一方面，在第一方面的某些实现方式中，交易金额与保证金存在指定的比例关系，在接收买方端针对目标订单转账的交易金额之后，还包括：若基于交易金额以及指定的比例关系，确定信息验证列表中记录有与交易金额相关的第二交易信息，则记录买方端的第二交易请求，以便卖方端基于第二交易请求，计算目标订单对应的商品验证码和电子签名，并生成卖方端的第一验证请求。

第二方面，本申请一实施例提供了一种交易处理装置，包括：第一接收模块，用于响应于买方端的第一交易请求，接收买方端针对目标订单转账的保证金，并生成目标订单的交易标识；发送模块，用于将交易标识发送至买方端，以便买方端将交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件；第一验证模块，用于响应于买方端的验证请求，接收买方端输入的第一计算结果和第一证明文件，并基于交易标识和第一计算结果，对第一证明文件进行验证；第二接收模块，用于在第一证明文件通过验证的情况下，响应于买方端的第二交易请求，接收买方端针对目标订单转账的交易金额；第二验证模块，用于响应于卖方端的第一验证请求，接收卖方端输入的目标订单对应的商品验证码和电子签名，并对商品验证码进行合法性验证，对电子签名进行有效性验证；转账模块，用于若商品验证码通过合法性验证，并且，电子签名通过有效性验证，则将交易金额转账至卖方端，以及将保证金转账至买方端。

第三方面，本申请一实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序用于执行第一方面所述的交易处理方法。

第四方面，本申请一实施例提供了一种电子设备，该电子设备包括：处理器；用于存储处理器可执行指令的存储器；该处理器用于执行第一方面所述的交易处理方法。

在本实施例中，通过交易标识可以对一些复杂的交易过程进行追踪，以及管理整个交易过程，包括确认交易状态以及该交易是否存在等问题。此外，利用交易标识生成第一计算结果和证明文件，提高了交易的安全性，避免了潜在的争议或欺诈行为。智能合约接收外部输入（包括买方端的输入和卖方端的输入），并执行对应操作前，均对其进行验证，保证了信息的准确性。可验证延迟函数在接收到交易标识这个输入后，需要较长的时间才能计算出相应的结果，也就是说，在对商品验证码和电子签名验证通过前，保证金是处于冻结状态的，买方端若想取回保证金，也必须经过较长的一段时间。在这段时间内，交易已经取得了最终性，因此，通过本实施例中的方法，买方端无法随意撤回保证金，又因为交易达成了最终性，买方端也不能通过分叉攻击自身的交易流程获取免费的商品，这个过程中，保护了卖方端的权益。

附图说明

通过结合附图对本申请实施例进行更详细地描述，本申请的上述以及其他目的、特征和优势将变得更加明显。附图用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与本申请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1所示为本申请一实施提供的交易处理方法的应用场景示意图。

图2所示为本申请一实施例提供的交易处理方法的流程示意图。

图3所示为本申请另一实施例提供的交易处理方法的流程示意图。

图4所示为本申请一实施例提供的交易处理装置的结构示意图。

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

具体实施方式

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

区块链在互联网经济中凸显了重要价值，最常见的情形是其作为虚拟商品的交易平台的底层，通过将透明的交易数据记录在区块中来记账。区块链作为交易平台的底层功能也可以自然地过渡到实体经济当中，但是区块链用于现货交易的记账存在一些问题，这些问题与区块链去中心化的本质以及共识机制相关。

具体而言，用于现货交易的区块链放大了分叉攻击的风险，这在众多的基于分叉的Race攻击、Finney攻击或Vector76攻击案例中有所体现。由于区块被广播直至区块达成交易最终性（即全体节点已经不可篡改地认同了已经发生的交易并更新了本地状态）需要一定的时间，这为通过分叉攻击取消已广播交易合法性提供了可能。例如，恶意用户首先发起交易广播，实体商家在看到广播后（此时，交易仍未达到最终性）立即选择发货。恶意用户一旦看到商家已经完成发货，便利用被腐蚀者进行分叉攻击，从而将包含此前交易的区块独立出去。最终的结果是恶意用户获得了相应现货，却没有完成链上支付。

在中心化的交易平台中，交易平台本身具有交易担保功能，充当了第三方交易员的角色。用户首先向平台支付货款，这笔钱在交易完成前会一直在平台临时冻结，直至交易顺利达成后由平台向商家转移这笔货款，这样的类似功能也可以在去中心化的交易平台中实现。

图1所示为本申请一实施提供的交易处理方法的应用场景示意图。如图1所示，该应用场景包括买方端10、区块链20和卖方端30。区块链20中部署有智能合约，用于执行本申请中的交易处理方法。

具体地，智能合约可以理解为运行区块链上预置规则、具有状态、条件响应的，可封装、验证、执行分布式节点复杂行为，完成信息交换、价值转移和资产管理的计算机程序。基于区块链的分布式架构、共识算法等，智能合约允许相互不信任的对象在不需要任何第三方可信中介或权威的情况下完成交易，同时，数字形式的智能合约可灵活嵌入各种有形或无形的资产、交易和数据中，实现主动或被动的资产、信息管理与控制，逐步构建可编程的智能资产、系统等。

区块链20中的节点均可以称为计算机设备，该计算机设备可以为终端设备，或者可以为服务器，或者为终端设备和服务器组成的系统，本申请实施例对此不做限定。终端设备可以包括但不限于：个人计算机、智能手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备（mobileinternetdevice，MID）、可穿戴设备（例如智能手表、智能手环等）、智能语音交互设备、智能家电（例如智能电视等）、车载设备、飞行器等电子设备，本申请对终端设备的类型不做限定。

服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（ContentDeliveryNetwork，CDN）、以及大数据和人工智能平台等基础云计算服务的云服务器。

基于上述，买方端10生成第一交易请求之后，可以调用区块链20中的智能合约，进而可以在虚拟机中执行相应的合约代码。合约代码自动判断当前所处的场景是否满足合约触发条件，并严格执行合约响应规则。

具体地，智能合约响应于第一交易请求，接收买方端10支付的保证金，将保证金存储在合约账户中，并生成交易标识。买方端10将交易标识输入可验证延迟函数，得到第一计算结果和第一证明文件。智能合约响应于买方端10的验证请求，对第一计算结果和第一证明文件进行验证。并在第一证明文件通过验证的情况下，响应于买方端10的第二交易请求，接收买方端10支付的交易金额。卖方端30监听到智能合约的执行记录后，计算商品验证码和电子签名。同时，智能合约响应于卖方端30的第一验证请求，对商品验证码进行合法性验证，对电子签名进行有效性验证，并在二者均通过验证的情况下，将保证金转账至买方端10的账户中，将交易金额转账至卖方端30的账户中。

图2所示为本申请一实施例提供的交易处理方法的流程示意图。如图2所示，该交易处理方法涉及买方端、智能合约和卖方端。具体地，本实施例提供的交易处理方法包括如下步骤。

步骤S210，发送第一交易请求。具体地，买方端发送第一交易请求至智能合约。

步骤S220，响应于买方端的第一交易请求，接收买方端针对目标订单转账的保证金，并生成目标订单的交易标识。具体地，智能合约响应于买方端的第一交易请求，接收买方端针对目标订单转账的保证金，并生成目标订单的交易标识。

示例性地，买方端向智能合约发送第一交易请求，第一交易请求包括详细的交易信息，如交易对象、交易价格、交易数量等等。智能合约对买方端的第一交易请求进行验证，包括检查交易信息的准确性和合法性。若第一交易请求通过验证，智能合约向买方端发送请求，要求买方端提供目标订单的保证金。

进一步地，买方端通过智能合约提供的接口，将保证金转账至指定的账户或地址。智能合约在确认接收到保证金之后，更新相关的交易记录和状态，并生成目标订单的交易标识r，该交易标识r被存储在智能合约中，并且，可以通过智能合约提供的接口进行查询。更具体地，该交易标识可用于追踪和验证目标订单的交易执行状态。示例性地，该交易标识为交易序列号。

步骤S230，将交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件。具体地，买方端将交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件。

买方端可以通过智能合约提供的接口，请求交易标识。智能合约根据买方端的身份验证和授权，将交易标识发送至买方端。

需要说明的是，交易标识的生成和发送过程是自动完成的，同时，为了保证交易标识的唯一性和可信度，智能合约可采用加密算法和数字签名等技术来确定交易标识的真实性和安全性。

买方端在接收到交易标识后，将交易标识输入到可验证延迟函数中。其中，可验证延迟函数是一种数据函数，在基于可验证延迟函数对交易标识进行计算前，需要设定第一延迟时间参数T。它接收到交易标识这个输入后，根据第一延迟时间参数T进行计算，返回相应的第一计算结果和第一证明文件，但是因为可验证延迟函数需要处理和计算大量的数据，因此，这个计算过程需要一定的时间来完成。在本实施例中，第一计算结果是对目标订单这个交易的评估和确认，第一证明文件是用于验证第一计算结果的证据。

步骤S240，发送验证请求、第一计算结果和第一证明文件。具体地，买方端发送验证请求、第一计算结果和第一证明文件至智能合约。

步骤S250，响应于买方端的验证请求，接收买方端输入的第一计算结果和第一证明文件，并基于交易标识和第一计算结果，对第一证明文件进行验证。具体地，智能合约响应于买方端的验证请求，接收买方端输入的第一计算结果和第一证明文件，并基于交易标识和第一计算结果，对第一证明文件进行验证。

示例性地，将交易标识和第一计算结果输入第一证明文件，若第一证明文件能够运行成功，则表明第一计算结果和第一证明文件是正确的。

步骤S260，在第一证明文件通过验证的情况下，发送第二交易请求。具体地，买方端在第一证明文件通过验证的情况下，发送第二交易请求至智能合约。

步骤S270，响应于买方端的第二交易请求，接收买方端针对目标订单转账的交易金额。具体地，智能合约响应于买方端的第二交易请求，接收买方端针对目标订单转账的交易金额。

步骤S280，计算目标订单对应的商品验证码和电子签名。具体地，卖方端计算目标订单对应的商品验证码和电子签名。

本实施例中的商品验证码具有唯一性，可用于追踪和验证目标订单对应的商品的唯一性。本实施例中的电子签名可利用数字签名技术来生成，用于确定卖方端的身份和交易的有效性。生成的商品验证码和电子签名进行确认后，被存在卖方端的系统中，以便后续的交易追踪和验证。

在本申请一实施例中，电子签名包括第一电子签名和第二电子签名，其中，第一电子签名是对交易标识和商品验证码执行签名算法得到的，第二电子签名是对第一证明文件执行签名算法得到的。

示例性地，将第一电子签名记为，将第二电子签名记为/>。其中，/>表示商品验证码，/>表示交易标识，/>表示利用卖方端的私钥对商品验证码和交易标识执行签名算法，/>表示第一证明文件，/>表示利用卖方端的私钥对第一证明文件执行签名算法。

在本实施例中，通过签名，卖方端可以确认商品验证码和交易标识的生成过程是合法、合规且真实的，从而确保交易的真实性和完整性，有助于避免欺诈和伪造。此外，签名过程可以提供额外的安全层，确保交易信息的机密性和安全性。

步骤S290，发送第一验证请求、商品验证码和电子签名。具体地，买方端发送第一验证请求、商品验证码和电子签名至智能合约。

步骤S2100，响应于卖方端的第一验证请求，接收卖方端输入的目标订单对应的商品验证码和电子签名，并对商品验证码进行合法性验证，对电子签名进行有效性验证。具体地，智能合约响应于卖方端的第一验证请求，接收卖方端输入的目标订单对应的商品验证码和电子签名，并对商品验证码进行合法性验证，对电子签名进行有效性验证。

具体地，智能合约可以通过与卖方端进行通信，将接收到的商品验证码与存储在卖方端系统中的预定义规则或算法进行比较，若商品验证码匹配，则表示该商品验证码是合法的。

示例性地，智能合约可以将买方端的公钥输入电子签名，以验证买方端的电子签名的有效性。或者，智能合约通过与数字证书认证机构进行通信，以验证卖方端的电子签名的合法性和有效性。

步骤S2110，若商品验证码通过合法性验证，并且，电子签名通过有效性验证，则将交易金额转账至卖方端，以及将保证金转账至买方端。

上面，通过图2所示的步骤，详细阐述了智能合约在整个交易过程中的具体执行过程。下面结合图2实施例，简单介绍智能合约包含的合同条款。

买方端A调用Con1，Con1/>包括：接收来自买方端A的保证金为/>的转账，设置转账目标为卖方端/>，更新状态后返回一个随机数作为交易指标/>。

买方端A在本地计算，其中，/>表示可验证延迟函数，T表示可验证延迟函数的第一延迟时间参数，/>表示第一计算结果，/>表示第一证明文件。

买方端A调用Con0，Con0/>是指可验证延迟函数的验证算法，具体包括：验证/>。

买方端A调用Con2，Con2/>包括：接收来自买方端/>的交易金额为/>的转账。

卖方端B计算商品验证码，并基于商品验证码生成电子签名。

卖方端调用Con2，Con2/>包括：接收来自卖方端的商品验证码/>，交易指标/>以及对应的电子签名，验证/>的合法性。如果合法，就修改Con2/>的状态为on。需要说明的是，Con2/>默认的状态均为off。其中，on表示可以执行，off表示暂停执行。

卖方端调用Con2，Con2/>包括：状态为/>时，验证中的电子签名/>，如果验证通过，向/>传递/>。

买方端A调用：状态为/>时，验证电子签名，发起保证金t到买方端/>的转账。

若电子签名具体分为第一电子签名和第二电子签名，则可以进一步表示为第一电子签名/>，以及第二电子签名/>。

在本实施例中，通过交易标识可以对一些复杂的交易过程进行追踪，以及管理整个交易过程，包括确认交易状态以及该交易是否存在等问题，此外，利用交易标识生成第一计算结果和证明文件，提高了交易的安全性，避免了潜在的争议或欺诈行为。智能合约接收外部输入（包括买方端输入和卖方端输入），并执行对应操作前，均需要对其进行验证，保证了信息的准确性。可验证延迟函数在接收到交易标识这个输入后，需要较长的时间才能计算出相应的结果，也就是说，在对商品验证码和电子签名验证通过前，保证金是处于冻结状态的，买方端若想取回保证金，也必须经过较长的一段时间。在这段时间内，交易已经取得了最终性，因此，通过本实施例中的方法，买方端无法随意撤回保证金，又因为交易达成了最终性，买方端也不能通过分叉攻击自身的交易流程获取免费的商品，这个过程中，保护了卖方端的权益。

结合图2所示实施例，本申请的交易处理方法还包括如下：确定买方端的身份验证数据和卖方端的身份验证数据；在生成目标订单的交易标识后，将第一交易信息记录在信息验证列表。

第一交易信息包括保证金、交易标识、买方端的身份验证数据和卖方端的身份验证数据，以便对买方端和卖方端执行目标订单的交易过程进行验证。

在一个示例中，对于买方端，可以将其邮箱地址、平台账户的注册信息等作为身份验证数据。对于卖方端，可以将其身份证明文件或者平台账户的注册信息作为身份验证数据。

在另一个示例中，将买方端的公钥作为其身份验证数据，将卖方端的公钥/>作为其身份验证数据。如此设置，买卖双方无需公开自己的个人信息，从而保护了个人隐私。并且，在区块链交易中，使用公钥对买卖双方进行身份验证，还可以简化交易流程，缩短交易时间。此外，公钥本身就代表了对应的私钥，使用公钥作为身份验证数据，可以在一定程度上增强交易的安全性。

以和/>作为其身份验证数据为例，信息验证列表DL记录的第一交易信息为（）。结合前述对智能合约的描述，也即买方端A调用Con1/>，Con1/>在得到交易指标r后，会把（/>）记录在DL中。

本实施例中的延迟验证信息列表是一个包含交易信息的数据结构，它需要一段时间来被验证和确认。该列表有助于管理区块链上的交易过程，提高交易效率，同时也可以确保交易的安全性，减少欺诈风险，降低交易纠纷。

下面，结合两个实施例来阐述延迟验证信息列表在交易过程中的具体用途。

实施例一：

在基于交易标识和第一计算结果，对第一证明文件进行验证之前，该交易处理方法还包括：基于交易标识，验证信息验证列表中记录有与交易标识匹配的第一交易信息。沿用前述示例，也即，买方端A调用Con0，Con0/>收买方端输入的/>，并验证/>是/>中的一行。如此操作，可以确认此次交易的合法性和真实性，避免交易欺诈行为。通过验证交易标识，还可以确保每次交易都是独立的、有效的。

在第一证明文件通过验证的情况下，该交易方法还包括：在信息验证列表中，将第一交易信息修改为第二交易信息，并记录第二交易信息的交易状态为待交易，第二交易信息包括交易标识、保证金、第一计算结果、第一证明文件、以及可验证延迟函数的第一时间参数。也即，买方端A调用Con0，并在/>后，在/>中将修改为/>，其中，0表示第二交易信息的交易状态为待交易。结合Con0/>的包含的条款，那么，买方端在调用Con2/>时，Con2/>在接收到交易金额/>的转账后，进一步更新状态/>，并修改/>方法的状态为/>。结合该状态的更新，那么，卖方端在调用Con2/>时，Con2/>对电子签名验证通过后，需要进一步验证是否存在状态/>，若存在，则将交易金额/>转账到卖方端B。并在转账成功后，删除状态/>。需要说明的是，/>方法即为下述实施例所述的交易失败指令，其默认状态为on。

将第一交易信息修改为第二交易信息，可以视为一个交易过程的新节点，通过将第二交易信息记录在信息验证列表中，可以确保交易的详细信息得到妥善保存，以便后续查阅或核对。将第二交易信息的交易状态标记为待交易，表示该交易尚未完成后续的交易步骤，这为后续的交易处理提供了明确的状态标记，避免交易出现错误。

在将保证金转账至买方端之后，该交易方法还包括：将第二交易信息的交易状态修改为已交易。沿用前述示例，也即，买方端A调用时，验证/>中是否包含/>，若包含，将/>中的/>修改为/>。通过该操作，简化了交易流程，使得买卖双方能够更快速、准确地识别到与第二交易信息相关的目标订单已经完成了交易，防止重复交易，避免出现错误转账或重复转账的情况。

实施例二：

交易金额与保证金存在指定的比例关系，在接收所述买方端针对目标订单转账的交易金额之后，还包括：若基于交易金额以及指定的比例关系，确定信息验证列表中记录有与交易金额相关的第二交易信息，则记录买方端的第二交易请求，以便卖方端基于第二交易请求，计算目标订单对应的商品验证码和电子签名，并生成卖方端的第一验证请求。沿用前述示例，也即，买方端A调用时，/>得到交易金额为/>的转账后，检查/>中是否包含/>，若包含，则记录这次调用，即记录买方端的第二交易请求。

示例性地，保证金为t，交易金额为k*t，k为正数。需要说明的是，为了确保保证金能够约束买方端的一些交易欺诈行为，保证金不能远低于交易金额，具体地，可根据实际交易请求设置。例如，在本实施例中，k=1，也即保证金等于交易金额。

在本实施例中，信息验证列表中记录有与交易金额相关的第二交易信息，表明买方端针对目标订单已经支付了保证金，因此，可进行下一步操作，即记录买方端的第二交易请求。这可以确保交易的合法性和有效性，避免可能的冲突和不合法的情况下，同时，简化了交易流程，提高了交易效率。

下述实施例涉及交易失败指令、保证金冻结指令和保证金提取指令各自的状态转换。因此，首先对这三类指令进行简单介绍。示例性地，交易失败指令记为，保证金冻结指令记为/>，保证金提取指令记为/>。交易失败指令的默认状态为on，表示正常流程下可执行；保证金冻结指令/>的默认状态为off，表示正常流程下暂停执行；保证金提取指令/>的默认状态为off，表示正常流程下暂停执行。

进一步地，用于交易完成后，将保证金返还给买方端；保证金冻结指令/>用于在卖方端提供的商品验证码不合法时，通过修改/>的状态为off，将保证金返还给买方端，结合图2所示实施例，卖方端调用Con2/>时，如果商品验证码/>不合法，则会同步将/>的状态修改为/>；/>用于买方端迟迟不支付交易金额时，卖方端通过调用该方法，强制冻结买方端的保证金。

图3所示为本申请另一实施例提供的交易处理方法的流程示意图。在图2所示实施例的基础上延伸出图3所示实施例，下面着重叙述图3所示实施例与图2所示实施例的不同之处。

如图3所示，在本实施例中，该交易处理方法还包括如下步骤。

步骤S310，在第一证明文件通过验证的情况下，若目标时段内未接收到买方端的第二交易请求，则获取卖方端发送的第二计算结果和第二证明文件。

第二计算结果和第二证明文件是将第一计算结果输入可验证延迟函数得到的。本实施例中的可验证延迟函数对应第二延迟时间参数，目标时段可根据实际情况设置。沿用前述示例，第二计算结果和第二证明文件记为/>。

步骤S320，接收卖方端发送的对第二证明文件的电子签名。

卖方端对第二证明文件进行签名，得到对应的电子签名，记为。该电子签名可以证明第二证明文件确实是由卖方端提交的，并且，具有真实性和可靠性，以便在产生交易争议时提供相关证据。此外，第二证明文件可用于确认交易的真实性和有效性，电子签名可以确保第二证明文件的合法性和可靠性。

步骤S330，响应于卖方端的交易失败指令的执行请求，对第二证明文件的电子签名进行有效性验证，并在第二证明文件的电子签名通过有效性验证时，将保证金提取指令的当前状态修改为暂停执行状态。

图3所示的步骤详细阐述了智能合约在买方端发生交易拖延时的具体执行过程。下面结合验证信息列表中记录的信息，对图3所示实施例中的执行过程进行补充说明。

举例来说，卖方端B在得到第二计算结果和第二证明文件之后、接收卖方端发送的第二证明文件的电子签名之前，卖方端还可以调用，包括：接受卖方端/>的输入/>，验证/>中是否包含；如果验证通过则在/>中添加/>为新的一行。

进一步地，卖方端调用Con0，/>即可验证延迟函数的验证算法，/>具体包括接受调用卖方端/>的输入/>，验证/>是/>中的一行，验证/>，如果验证通过则在/>中将对应记录的行修改为/>。

卖方端计算/>并调用Con1/>，Con1包括：状态为/>时，验证/>的签名，验证/>中是否包含；如果验证通过则将/>中对应行修改为/>，并修改的状态为/>，以便强制冻结买方端的保证金。

本实施例中，当买方端长时间不支付商品的全款时，通过将保证金提取指令暂停执行，强制冻结买方端的保证金，保护了卖方端的利益。也就是说，买方端不仅需要合法发起交易，还必须在指定时间内合法发起交易。

在本申请一些实施例中，结合图2所示实施例，若商品验证码未通过合法性验证，则响应于买方端的保证金冻结终止指令的执行请求，将保证金转账至所述买方端，并且，将交易失败指令和保证金提取指令的当前状态均修改为暂停执行状态。

具体地，对应到智能合约包含的具体合同条款为，买方端A调用，Con1/>包括：状态为/>时，发起保证金t到买方端的转账。同时，修改/>和/>的状态为/>。

在本申请一些实施例中，结合图2所示实施例，将保证金转账至买方端，包括：将电子签名作为输入，以生成保证金提取指令的执行请求；响应于保证金提取指令的执行请求，对电子签名进行有效性验证；若电子签名通过有效性验证，则将保证金转账至买方端，并且，将交易失败指令的当前状态修改为暂停执行状态。

具体地，对应到智能合约的具体合同条款，该过程可以表示为：：状态为/>时，验证/>的签名，验证/>中是否包含。如果验证通过则将/>中对应行修改为/>，并发起保证金t到买方端的转账，修/>的状态为/>。

上文结合图2和图3，详细描述了本申请的交易处理方法实施例，下面结合图4，详细描述本申请的交易处理装置实施例。应理解，交易处理方法实施例的描述与交易处理装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图4所示为本申请一示例性实施例提供的交易处理装置的结构示意图。如图4所示，本申请实施例提供的交易处理装置40包括：

第一接收模块410，用于响应于买方端的第一交易请求，接收买方端针对目标订单转账的保证金，并生成目标订单的交易标识；

发送模块420，用于将交易标识发送至买方端，以便买方端将交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件；

第一验证模块430，用于响应于买方端的验证请求，接收买方端输入的第一计算结果和第一证明文件，并基于交易标识和第一计算结果，对第一证明文件进行验证；

第二接收模块440，用于在第一证明文件通过验证的情况下，响应于买方端的第二交易请求，接收买方端针对目标订单转账的交易金额；

第二验证模块450，用于响应于卖方端的第一验证请求，接收卖方端输入的目标订单对应的商品验证码和电子签名，并对商品验证码进行合法性验证，对电子签名进行有效性验证；

转账模块460，用于若商品验证码通过合法性验证，并且，电子签名通过有效性验证，则将交易金额转账至卖方端，以及将保证金转账至买方端。

在本申请一实施例中，第二验证模块450还用于，在第一证明文件通过验证的情况下，若目标时段内未接收到买方端的第二交易请求，则获取卖方端发送的第二计算结果和第二证明文件，第二计算结果和第二证明文件是将第一计算结果输入可验证延迟函数得到的；接收卖方端发送的对第二证明文件的电子签名；响应于卖方端的交易失败指令的执行请求，对第二证明文件的电子签名进行有效性验证，并在第二证明文件的电子签名通过有效性验证时，将保证金提取指令的当前状态修改为暂停执行状态。

在本申请一实施例中，转账模块460还用于，若商品验证码未通过合法性验证，则响应于买方端的保证金冻结终止指令的执行请求，将保证金转账至买方端，并且，将交易失败指令和保证金提取指令的当前状态均修改为暂停执行状态。

在本申请一实施例中，转账模块460还用于，将电子签名作为输入，以生成保证金提取指令的执行请求；响应于保证金提取指令的执行请求，对电子签名进行有效性验证；若电子签名通过有效性验证，则将保证金转账至买方端，并且，将交易失败指令的当前状态修改为暂停执行状态。

在本申请一实施例中，电子签名包括第一电子签名和第二电子签名，其中，第一电子签名是对交易标识和商品验证码执行签名算法得到的，第二电子签名是对第一证明文件执行签名算法得到的。

在本申请一实施例中，还包括记录模块，用于确定买方端的身份验证数据和卖方端的身份验证数据；在生成目标订单的交易标识后，将第一交易信息记录在信息验证列表，第一交易信息包括保证金、交易标识、买方端的身份验证数据和卖方端的身份验证数据，以便对买方端和卖方端执行目标订单的交易过程进行验证。

在本申请一实施例中，第一验证模块430还用于，基于交易标识，验证信息验证列表中记录有与交易标识匹配的第一交易信息；在第一证明文件通过验证的情况下，在信息验证列表中，将第一交易信息修改为第二交易信息，并记录第二交易信息的交易状态为待交易，第二交易信息包括交易标识、保证金、第一计算结果、第一证明文件、以及可验证延迟函数的第一时间参数；在将保证金转账至买方端之后，将第二交易信息的交易状态修改为已交易。

在本申请一实施例中，第二验证模块450还用于，若基于交易金额以及指定的比例关系，确定信息验证列表中记录有与交易金额相关的第二交易信息，则记录买方端的第二交易请求，以便卖方端基于第二交易请求，计算目标订单对应的商品验证码和电子签名，并生成卖方端的第一验证请求。

下面，参考图5来描述根据本申请实施例的电子设备。图5所示为本申请一示例性实施例提供的电子设备的结构示意图。

如图5所示，电子设备50包括一个或多个处理器501和存储器502。

处理器501可以是中央处理单元（CPU）或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备50中的其他组件以执行期望的功能。

存储器502可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器（RAM）和/或高速缓冲存储器（cache）等。所述非易失性存储器例如可以包括只读存储器（ROM）、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器501可以运行所述程序指令，以实现上文所述的本申请的各个实施例的交易处理方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如包括保证金、交易金额、交易标识、第一计算结果、第一证明文件、商品验证码和电子签名等各种内容。

在一个示例中，电子设备50还可以包括：输入装置503和输出装置504，这些组件通过总线系统和/或其他形式的连接机构（未示出）互连。

该输入装置503可以包括例如键盘、鼠标等等。

该输出装置504可以向外部输出各种信息，包括保证金、交易金额、交易标识、第一计算结果、第一证明文件、商品验证码和电子签名等。该输出装置504可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图5中仅示出了该电子设备50中与本申请有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备50还可以包括任何其他适当的组件。

除了上述方法和设备以外，本申请的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述描述的根据本申请各种实施例的交易处理方法中的步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本申请的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述描述的根据本申请各种实施例的交易处理方法中的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。

以上结合具体实施例描述了本申请的基本原理，但是，需要指出的是，在本申请中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本申请的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本申请为必须采用上述具体的细节来实现。

本申请中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。

还需要指出的是，在本申请的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本申请的等效方案。

提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本申请。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本申请的范围。因此，本申请不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。

Claims (10)

1.一种交易处理方法，其特征在于，应用于区块链中的智能合约，所述方法包括：

响应于买方端的第一交易请求，接收所述买方端针对目标订单转账的保证金，并生成所述目标订单的交易标识；

将所述交易标识发送至所述买方端，以便所述买方端将所述交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件；

响应于所述买方端的验证请求，接收所述买方端输入的所述第一计算结果和所述第一证明文件，并基于所述交易标识和所述第一计算结果，对所述第一证明文件进行验证；

在所述第一证明文件通过验证的情况下，响应于所述买方端的第二交易请求，接收所述买方端针对所述目标订单转账的交易金额；

响应于卖方端的第一验证请求，接收所述卖方端输入的所述目标订单对应的商品验证码和电子签名，并对所述商品验证码进行合法性验证，对所述电子签名进行有效性验证，其中，所述电子签名包括对所述交易标识和所述商品验证码执行签名算法得到的第一电子签名；

若所述商品验证码通过合法性验证，并且，所述电子签名通过有效性验证，则将所述交易金额转账至所述卖方端，以及将所述保证金转账至所述买方端。

2.根据权利要求1所述的方法，其特征在于，还包括：

在所述第一证明文件通过验证的情况下，若目标时段内未接收到所述买方端的第二交易请求，则获取所述卖方端发送的第二计算结果和第二证明文件，所述第二计算结果和所述第二证明文件是将所述第一计算结果输入所述可验证延迟函数得到的；

接收所述卖方端发送的对所述第二证明文件的电子签名；

响应于所述卖方端的交易失败指令的执行请求，对所述第二证明文件的电子签名进行有效性验证，并在所述第二证明文件的电子签名通过有效性验证时，将保证金提取指令的当前状态修改为暂停执行状态。

3.根据权利要求1所述的方法，其特征在于，还包括：

若所述商品验证码未通过合法性验证，则响应于所述买方端的保证金冻结终止指令的执行请求，将所述保证金转账至所述买方端，并且，将交易失败指令和保证金提取指令的当前状态均修改为暂停执行状态。

4.根据权利要求1所述的方法，其特征在于，所述将所述保证金转账至所述买方端，包括：

将所述电子签名作为输入，以生成保证金提取指令的执行请求；

响应于所述保证金提取指令的执行请求，对所述电子签名进行有效性验证；

若所述电子签名通过有效性验证，则将所述保证金转账至所述买方端，并且，将交易失败指令的当前状态修改为暂停执行状态。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述电子签名还包括第二电子签名，其中，所述第二电子签名是对所述第一证明文件执行签名算法得到的。

6.根据权利要求1至4任一项所述的方法，其特征在于，还包括：

确定所述买方端的身份验证数据和所述卖方端的身份验证数据；

在生成所述目标订单的交易标识后，将第一交易信息记录在信息验证列表，所述第一交易信息包括所述保证金、所述交易标识、所述买方端的身份验证数据和所述卖方端的身份验证数据，以便对所述买方端和所述卖方端执行所述目标订单的交易过程进行验证。

7.根据权利要求6所述的方法，其特征在于，在所述基于所述交易标识和所述第一计算结果，对所述第一证明文件进行验证之前，还包括：

基于所述交易标识，验证所述信息验证列表中记录有与所述交易标识匹配的第一交易信息；

在所述第一证明文件通过验证的情况下，所述方法还包括：

在所述信息验证列表中，将所述第一交易信息修改为第二交易信息，并记录所述第二交易信息的交易状态为待交易，所述第二交易信息包括所述交易标识、所述保证金、所述第一计算结果、所述第一证明文件、以及所述可验证延迟函数的第一时间参数；

在所述将所述保证金转账至所述买方端之后，所述方法还包括：

将所述第二交易信息的交易状态修改为已交易。

8.根据权利要求7所述的方法，其特征在于，所述交易金额与所述保证金存在指定的比例关系，在所述接收所述买方端针对所述目标订单转账的交易金额之后，还包括：

若基于所述交易金额以及所述指定的比例关系，确定所述信息验证列表中记录有与所述交易金额相关的第二交易信息，则记录所述买方端的第二交易请求，以便所述卖方端基于所述第二交易请求，计算所述目标订单对应的商品验证码和所述电子签名，并生成所述卖方端的第一验证请求。

9.一种交易处理装置，其特征在于，应用于区块链中的智能合约，所述装置包括：

第一接收模块，用于响应于买方端的第一交易请求，接收所述买方端针对目标订单转账的保证金，并生成所述目标订单的交易标识；

发送模块，用于将所述交易标识发送至所述买方端，以便所述买方端将所述交易标识输入可验证延迟函数，得到对应的第一计算结果和第一证明文件；

第一验证模块，用于响应于所述买方端的验证请求，接收所述买方端输入的所述第一计算结果和所述第一证明文件，并基于所述交易标识和所述第一计算结果，对所述第一证明文件进行验证；

第二接收模块，用于在所述第一证明文件通过验证的情况下，响应于所述买方端的第二交易请求，接收所述买方端针对所述目标订单转账的交易金额；

第二验证模块，用于响应于卖方端的第一验证请求，接收所述卖方端输入的所述目标订单对应的商品验证码和电子签名，并对所述商品验证码进行合法性验证，对所述电子签名进行有效性验证，其中，所述电子签名包括对所述交易标识和所述商品验证码执行签名算法得到的第一电子签名；

转账模块，用于若所述商品验证码通过合法性验证，并且，所述电子签名通过有效性验证，则将所述交易金额转账至所述卖方端，以及将所述保证金转账至所述买方端。

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

处理器；

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

所述处理器，用于执行所述指令程序，以实现上述权利要求1至8任一项所述的方法。