CN113962676A - 交易验证的方法、装置 - Google Patents

交易验证的方法、装置 Download PDF

Info

Publication number
CN113962676A
CN113962676A CN202010698620.2A CN202010698620A CN113962676A CN 113962676 A CN113962676 A CN 113962676A CN 202010698620 A CN202010698620 A CN 202010698620A CN 113962676 A CN113962676 A CN 113962676A
Authority
CN
China
Prior art keywords
transaction
sub
chain
verification
string
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010698620.2A
Other languages
English (en)
Inventor
程烁
张衡
聂光耀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Digital Currency Institute of the Peoples Bank of China
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010698620.2A priority Critical patent/CN113962676A/zh
Priority to EP21847389.0A priority patent/EP4184406A4/en
Priority to PCT/CN2021/080336 priority patent/WO2022016886A1/zh
Publication of CN113962676A publication Critical patent/CN113962676A/zh
Priority to US18/156,786 priority patent/US20230177505A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请提供一种交易验证的方法及装置，用于计算机技术领域。其中，该方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的电子设备，包括在交易验证过程中，将业务逻辑的执行和数据存储从SE侧转移到TEE侧实现，SE侧保留交易合法性验证，在保证安全性的前提下，克服了电子设备SE存储空间与计算性能受限的问题，显著提升了用户体验。所述方法也应用于服务器侧，包括对来自电子设备的数据凭证进行增量验证，验证所述历史数据凭证没有记录的所述数据凭证中的数据的合法性。通过本申请，减少了服务器侧的冗余的验证计算，从而达到高并发场景下在服务器侧快速验证数据凭证、节省资源的效果。

Description

交易验证的方法、装置
技术领域
本申请实施例涉及计算机技术领域，尤其是涉及交易验证的方法。
背景技术
随着电子商务与移动支付的快速发展，传统的金融体系和技术正不断受到挑战。基于区块链技术的比特币也将数字货币这一概念带入大众视野，世界各主要经济体都在着手研究和推广数字货币相关技术。
数字货币一般由国家央行发行，为了实现高性能、高可用、高性能的数字货币，业界普遍采用区块链与分布式账本技术或者基于既有银行系统的中心化金融账户体系来实现。然而区块链与分布式账本技术虽然有很多优点，比如数据天然不可篡改和分布式一致性，但仍存在很多不足：区块链技术依旧处于发展阶段，当前的性能可能不足以支撑数字货币大规模应用后带来的交易压力。因此，基于既有的中心化银行系统架构方案反而是优先选择的实现方案，但这种方案在交易验证中依旧存在性能瓶颈。
为了解决这个问题，业界已经存在一种实现可控匿名的数字货币的技术，即在既有中心化银行系统中模拟了类似现金交易的模型来实现数字货币的离线、在线交易。数字货币的币串凭证由原始币串与若干交易子链组成。在该现有技术中，以原始币串为基础，随着数字货币的流通，会不断在币串凭证末尾追加新的交易子链，并在每次交易后针对币串凭证的整体数据生成数字签名、验证数字签名的有效性。现有技术能够有效实现数字货币在线、离线交易的功能，解决币串凭证的合法性和安全性问题，然而仍然存在验证过程中存在一定的冗余计算以及受限于性能用户体验较差的不足。
因此，如何提升数字货币的验证性能，提升用户体验成为亟待解决的问题。
发明内容
本申请实施例提供一种交易验证的方法和装置，应用于计算机技术领域，解决如下问题：
如何提升数字货币在交易过程中的验证性能，以提升用户体验。
为方便理解本申请的实施例，下面先对本申请中出现的部分技术概念做介绍。应理解的是，这些技术概念应用在本申请下文将要介绍的实施例中，但这些实施例仅是本发明提供的方案的部分实施例中，所以这些技术概念并非一定要应用在本申请所有实施例中。
软钱包：在电子设备上实现的客户端钱包应用程序，执行在富执行环境REE。
硬钱包：在电子设备上结合安全硬件特性在TEE和SE上实现的钱包业务逻辑和安全模块。
Applet：使用Java Card框架在SE中开发使用的应用程序。
发行机构：数字货币发行机构的后台服务，负责数字货币的验证、同步、审计等。
原始币串：用来表示数字货币价值的一种不可变的数据结构，有冠字号作为唯一标识，携带有货币发行机构和金额等信息。
机构签名：用来证明原始币串的合法性，由数字货币发行机构的私钥对原始币串进行数字签名生成。
交易子链：在两个用户进行交易时追加在原来的币串凭证上，用来记录一次付款行为的价值传递，包含交易金额等信息。
币串凭证：由原始币串和若干交易子链相连组成的，并由迭代的数字签名保证合法性。
前序交易：同一币串凭证上某一交易子链追加之前的币串凭证数据。
数字签名：在币串凭证的末尾追加的交易签名，用来证明交易子链及前序交易的合法性，由付款方私钥生成。
双离线交易：使用数字货币交易的双方均为离线状态下，仅通过终端设备传递币串凭证产生的交易，该交易会在原币串凭证结尾追加新的交易子链标记本次交易金额，末尾交易子链的金额表示了新币串凭证的价值。
冠字号：作为原始币串的唯一标识，与纸币的冠字号概念一致。
币串同步：随着用户使用数字货币的过程，用户硬钱包中会逐渐累积大量小额币串，此时硬钱包的性能会受到影响，因此需要用户与发行机构进行同步操作，将钱包中的小额币串整合为整额币串重新下发到钱包，或者存入自己的银行账户。
下面将从多个方面介绍本申请，容易理解的是，该以下多个方面可以单独实施，也可以选择其中任意两个或更多联合实施。该以下多个方面的实现和有益效果可互相参考。
在本申请的描述中，末尾交易子链和最后一个交易子链具有相同的含义。
第一方面，本申请实施例提供一种交易验证的方法，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第一电子设备，所述方法包括：所述REE向所述TEE发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型；所述TEE根据所述交易类型执行第一业务逻辑以获得第一验证指令，所述第一验证指令包括待验证的数字签名；所述TEE向所述SE发送所述第一验证指令；所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果，并将所述第一验证结果发送给所述TEE；所述TEE发送第一交易响应消息给所述REE，所述第一交易响应消息包含所述第一验证结果；所述REE在所述第一验证结果指示验证成功时，根据所述交易的接收方标识向第二电子设备发送第二交易请求消息，所述接收方标识用于指示所述第二电子设备。
示例性的，以用户在REE软钱包发起付款请求为例。用户在协商到收款方地址后，在REE侧软钱包发起付款操作，向TEE发起付款请求消息，在这个例子中，上述第一交易请求消息为付款请求。TEE收到付款请求消息后，执行第一业务逻辑即付款业务逻辑，如交易次数、交易限额等基本验证，并向SE发送第一验证指令，SE根据数字签名验证付款交易的合法性后将验证结果返回给TEE保存。而现有技术中，用户在协商到收款方地址后，在REE侧软钱包发起付款操作，并生成与SE交互的支付指令，由SE执行付款业务逻辑和保存币串凭证。
由于电子设备中SE为硬件隔离的独立运行环境，存储空间与计算性能受限，本申请相比现有技术，将第一业务逻辑和数据存储转移到TEE侧实现，SE侧保留交易合法性验证，在保证安全性的前提下，充分利用端侧性能，显著提升用户体验。
在一种可能的实现方式中，该方法还包括所述TEE保存了至少一个候选的数据凭证。
在一种可能的实现方式中，所述TEE根据所述交易类型执行第一业务逻辑包括所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑。
在一种可能的实现方式中，该方法还包括所述数据凭证为币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述数字签名为在所述币串凭证末尾追加的交易签名，用于指示所述交易子链的合法性，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
具体的，随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的子链数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。而现有技术中，每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，即每次生成数字签名都需要对所有前序交易数据进行整体签名。用链式签名方案替代整体签名方案，在对币串凭证生成数字签名和验证数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成和验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
在一种可能的实现方式中，所述第一交易请求消息还包括交易的交易金额。
在一种可能的实现方式中，所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行第一业务逻辑所述TEE根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证；所述TEE对所述待验证的币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；所述TEE提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额。
具体的，所述TEE根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证，具体的，所述TEE可以在TEE保存的所有币串凭证中，从大额度的币串凭证开始选择至少一个币串凭证；也可以根据交易金额在TEE保存的币串凭证中选择一个余额和交易金额最接近的币串凭证；也可以在TEE保存的币串凭证中筛选出余额大于等于交易金额的币串凭证，然后根据一定的算法选择至少一个币串凭证；还可以限定选择某一发行机构、优先选择满足交易金额要求的单个最小余额的币串凭证或者优先选择整合多个小余额币串以满足交易金额要求；还可以根据其他规则对币串凭证进行选择，本申请实施例不做特别限制。
具体的，所述TEE对所述待验证的币串凭证进行基本验证可以包括验证交易金额、钱包限额、交易次数、交易限额等是否合法。验证交易金额可以包括验证币串凭证的余额是否满足交易金额的要求。币串凭证的余额可以保存到TEE中。钱包限额、交易次数、交易限额等可以通过预设到TEE上，由TEE进行验证；或者钱包限额、交易次数、交易限额等也可以预设到SE上，然后从SE读取到TEE，再在TEE上进行验证。以交易次数为例，可以通过判断交易子链个数或者币串凭证长度判断交易次数是否在预设的限额内。可以理解的是，前述基本验证仅是示例，本申请不对基本验证进行限制。
在一种可能的实现方式中，所述TEE提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额，所述TEE将第一验证指令发送给SE。
可以理解的是，在一些流程中，TEE不需要发送第一验证指令给SE。示例性的，当TEE在不需要由SE生成新的交易子链时，比如读取当前钱包的总余额等操作；或者首次收到新的币串凭证需要验证的情况下，不需要发送第一验证指令给SE。
在一种可能的实现方式中，所述通过所述基本验证的币串凭证包括冠字号，所述冠字号为所述通过所述基本验证的币串凭证的唯一标识；所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果包括：所述SE根据所述第一验证指令中的所述交易金额生成交易信息；所述SE根据所述冠字号将本地存储的参考数字签名与所述第一验证指令中的所述最后一个交易子链的子链数字签名进行对比，当所述本地存储的参考数字签名与所述第一验证指令中的最后一个交易子链的子链数字签名一致时，所述SE根据所述交易信息、所述最后一个交易子链的子链数字签名和所述SE本地保存的私钥生成与所述交易对应的数字签名；所述SE根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链，所述与所述交易对应的交易子链中的子链数字签名为所述与所述交易对应的数字签名；所述SE生成包括所述与所述交易对应的交易子链的第一验证结果。可以理解的是，所述SE可以将与交易对应的数字签名保存在本地。
可以理解的是，如果TEE选择的待验证币串凭证包含至少一个币串凭证，则第一验证指令中将包含所述至少一个币串凭证中每个币串凭证的最后一个交易子链的数字签名；SE收到第一验证指令后，将根据冠字号分别对第一验证指令中的每个最后一个交易子链的子链数字签名与SE本地存储的参考数字签名一一进行对比；当SE本地存储的参考数字签名与最后一个交易子链的子链数字签名一致时，所述SE根据所述交易信息、所述最后一个交易子链的子链数字签名和所述SE本地保存的私钥生成与所述交易对应的数字签名。可以理解的是，每次签名对比一致，将生成一个与交易对应的数字签名，SE将根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链。
示例性的，比如，交易发起方发起5块钱转账交易，若TEE在本地选择了5个1块钱的币串凭证，则TEE将把这5个1块钱的币串凭证的最后一个交易子链的子链数字签名发送给SE，SE收到后，将来自TEE的这5个1块钱的币串凭证的最后一个交易子链的子链数字签名根据冠字号分别与保存在本地的签名信息进行对比，每次对比一致时，生成一个与交易对应的数字签名和一个与交易对应的交易子链。若5个币串凭证的最后一个交易子链的子链数字签名都对比一致，则SE将生成5个与交易对应的数字签名和5个与交易对应的交易子链。第一验证结果中将包括这5个与交易对应的交易子链。
在一种可能的实现方式中，所述SE根据所述交易金额、收款方身份唯一标识、交易唯一标识、生成新交易子链中的交易信息部分。
在一种可能的实现方式中，所述TEE保存所述第一验证结果；所述TEE根据冠字号将所述与交易对应的交易子链更新到所述通过所述基本验证的币串凭证上。
在一种可能的实现方式中，所述方法还包括所述第一电子设备将所述更新后的所述通过所述基本验证的币串凭证同步到服务器。具体的，所述币串凭证同步的时机可以是用户手动触发同步，或者是交易次数达到上限时自动触发同步等，本申请不做限制。需要说明的是，所述第一电子设备在同步币串凭证到服务器时，也可以同步上传跟币串凭证相关的其他信息，如币串余额、交易流水等。
在一种可能的实现方式中，所述方法还包括所述第一电子设备接收第二电子设备的确认消息以完成交易。第一电子设备接收到确认消息后，判断在币串凭证的金额使用完的情况下，对所述币串凭证标记删除标识。在币串凭证同步到服务器后，若币串凭证标记有删除标识则由服务器对所述币串凭证进行删除。
第二方面，一种交易验证的方法，其特征在于，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第二电子设备，所述方法包括：所述REE接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述TEE，所述第二交易请求消息包含至少一个数据凭证；所述TEE根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，所述第二验证指令包括待验证的数字签名；所述TEE向所述SE发送所述第二验证指令；所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述TEE，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；所述TEE接收来自所述SE的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述REE，所述第二交易响应消息用于指示交易是否成功；所述REE发送第二交易响应消息给第一电子设备。
由于电子设备中，SE为硬件隔离的独立运行环境，存储空间与计算性能受限，通过本申请的方法，将第二业务逻辑和数据存储转移到TEE侧实现，SE侧保留数据凭证合法性验证，在保证安全性的前提下，充分利用端侧性能，显著提升用户体验。
在一种可能的实现方式中，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
具体的，随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的子链数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。而现有技术中，每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，即每次生成数字签名都需要对所有前序交易数据进行整体签名。用链式签名方案替代整体签名方案，在对币串凭证生成数字签名和验证数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成和验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
在一种可能的实现方式中，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识。
在一种可能的实现方式中，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。具体的，可以在TEE中执行大部分的币串验证逻辑，包括原始币串的机构签名验证以及除最后一个交易子链以外的其他交易子链的子链数字签名验证。TEE还可以进行金额验证，该金额验证包括验证至少一个币串凭证中的每个币串凭证的最后一个交易子链的金额总和交易金额是否相等。当验证到最后一个交易子链的数字签名时，TEE获取验证最后一个交易子链的子链数字签名所必要的信息，这些信息可以包括倒数第二个交易子链的子链数字签名、最后一个交易子链的信息、最后一个交易子链的子链数字签名。
在一种可能的实现方式中，所述TEE向所述SE发送第二验证指令，其中，所述第二验证指令可以包括倒数第二个交易子链的子链数字签名、最后一个交易子链的信息、最后一个交易子链的子链数字签名。可以理解的是，所述第二验证指令还可以包括其他能够验证所述数据凭证合法性的信息，本申请不做特别限制。
需要说明的是，在现有技术中，由于每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，因此在生成数字签名的过程中，需要将整个币串凭证的内容完整地从TEE传入SE，由于SE的传输能力限制，SE并不适合传入传出较大的数据，因此这种方案会对端侧双离线交易场景的性能和体验产生影响。而在本申请中，由于每一个交易子链中的子链数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，每次生成数字签名所需要的信息是少量的，从而能够打破SE的性能和存储瓶颈，提升端侧交易性能。
在一种可能的实现方式中，所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果包括验证所述至少一个币串凭证中的每个币串凭证的最后一个交易子链的合法性。
在一种可能的实现方式中，所述最后一个交易子链的合法性验证通过后，所述SE保存所述最后一个交易子链的子链数字签名，所述最后一个交易子链的子链数字签名用于后续交易时作为对比验证的参考值。示例性的，所述最后一个交易子链的合法性验证可以通过验证该交易子链的子链数字签名来实现。
在一种可能的实现方式中，所述SE验证所述数据凭证的合法性后，将第二验证结果发送给所述TEE，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过。
在一种可能的实现方式中，所述TEE接收来自所述SE的第二验证结果，所述TEE保存所述验证通过的数据凭证，发送第二交易响应消息给所述REE，所述第二交易响应消息用于指示交易是否成功。可以理解的是，当所述至少一个数据凭证的合法性验证失败时，所述TEE接收来自所述SE的所述第二验证结果后，不保存所述验证失败的数据凭证。
在一种可能的实现方式中，所述REE收到第二交易响应消息后，将第二交易响应消息发送给第一电子设备。第二交易响应消息用于向第一电子设备的交易发起方指示本次交易完成，第二交易响应消息可以包括指示本次交易成功或失败的标识，还可以包括随机数，该随机数可以作为标识本次交易的唯一标识，该随机数是在传递币串凭证前交易发起方和交易接收方协商的。在实施例中，将以确认消息为示例来说明第二交易响应消息。
由于币串凭证的链式签名结构，最后一个交易子链的子链数字签名可以验证币串凭证整体信息的完整性和合法性。因此只要在端侧交互操作中，将最后一个交易子链的子链数字签名在SE中生成和验证，即可以达到和所有验证计算和数据都放在SE中一样的安全性效果。
本申请中仅将最后一个交易子链的子链数字签名和用户密钥存储在SE中，SE侧保留生成签名和验证签名的功能，其他的业务逻辑在TEE侧实现，在保证等效安全性的前提下，打破SE的性能和存储瓶颈，提升端侧交易性能。
在一种可能的实现方式中，所述方法还包括第二电子设备将合法性验证通过的数据凭证同步到服务器。数据凭证同步的时机可以是用户手动触发同步，或者是交易次数达到上限时自动触发同步等，本申请不做限制。
第三方面，一种交易验证的方法，其特征在于，所述方法应用于服务器，包括：
接收来自电子设备的数据凭证；对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史数据凭证进行对比，验证所述历史数据凭证没有记录的所述数据凭证中的数据的合法性；保存所述合法性验证成功的所述数据凭证。
现有技术中，服务器在验证过程中，需要对所有的数据凭证数据进行整体验证，频繁、大量验证数据凭证导致资源消耗大、性能低。通过本申请，在服务器侧通过对数据凭证进行增量验证，仅验证所述数据凭证中比所述历史记录多余的数据的合法性，减少了冗余的验证计算，从而达到服务器高并发场景下的数据凭证能够快速验证、节省服务器资源的效果。
在一种可能的实现方式中，所述历史数据凭证为已验证的数据凭证相关的数据。需要说明的是，服务器在保存历史数据凭证时，可以只保存该币串凭证的数字签名。也可以保存整个币串凭证。具体的保存形式，本申请实施例不做限制。在实施例中，将以服务器存储币串凭证的数字签名为示例进行说明。
在一种可能的实现方式中，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和子链数字签名，所述子链数字签名为根据前一次交易对应的数字签名与本次交易数据生成的数字签名。
具体的，随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。而现有技术中，每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，即每次生成数字签名都需要对所有前序交易数据进行整体签名。用链式签名方案替代整体签名方案，在对币串凭证生成数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
可以理解的是，基于上述数字签名的生成过程，当币串凭证同步到服务器、服务器进行数字签名验证时，能够减少冗余的摘要计算、提高验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
在一种可能的实现方式中，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识。
在一种可能的实现方式中，将所述数据凭证与保存在所述服务器的历史数据凭证进行对比包括：根据冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。示例性的，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，从原始币串数字签名开始遍历币串凭证的数字签名数据，将该币串凭证中每个数字签名与该历史币串凭证的节点进行对比，一旦存在数据不一致的节点，则该币串凭证验证失败；当遍历结束后，币串凭证的所有交易子链签名均对比一致，则该币串凭证有效；当该历史记录的所有分支节点均对比完成后，若币串凭证还存在未验证的交易子链的数字签名时，则迭代验证剩余的交易子链数字签名。
在一种可能的实现方式中，所述方法还包括所述方法还包括当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
在一种可能的实现方式中，所述对交易子链进行验证包括验证数字签名、发行机构签名、余额和交易流水。可以理解的是，余额和交易流水可以随币串凭证一起同步到服务器的。
在一种可能的实现方式中，所述保存验证成功的所述数据凭证包括根据冠字号将已验证的所述交易子链的子链数字签名作为特征数据存储到所述服务器。
具体的，基于上述的链式结构的数字签名方案，在币串凭证同步到服务器的过程中，服务器将验证币串凭证的有效性，验证通过后，以每个交易子链的数字签名值作为交易特征，将已验证的交易数据保存在特定的交易树结构中。示例性的，针对用户同步的币串凭证，服务器验证通过后，将币串凭证的每个交易子链的子链数字签名保存到服务器的数据库中，其中，不同冠字号的币串凭证可以保存到不同的交易树结构中，这些保存的数据将作为历史记录，在后续的验证过程中作为对比验证的参考值，即所有币串凭证在验证交易子链签名的过程中，在数据库的交易树结构中可以查询到的签名无需重复验证，只需对数据库中不存在的节点进行增量验证，并在验证成功后在交易树结构中追加已验证的节点，用于后续币串凭证的快速验证。
数字货币在流通的过程中，同一冠字号的币串凭证经过交易会被不断拆分和扩散，最终多个用户持有的币串凭证存在部分重复信息，在同步过程中将已验证的交易数据保存在特定的交易树结构中，使不同用户持有的币串凭证中的重复信息仅需要通过简单的数据比对即可验证，而不需要重复验证签名，减轻服务器侧数字签名验证的压力。
第四方面，针对本申请第一方面提供的方法，本申请实施例还提供一种交易验证的装置，该装置具有实现第一方面提供的任意一种方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该装置可以以芯片的产品形态存在。该交易验证的装置具体可以是第一电子设备，也可以是设置在第一电子设备上固定的或可移除的功能模块。
第五方面，针对本申请第二方面提供的方法，本申请实施例还提供一种交易验证的装置，该装置具有实现第二方面提供的任意一种方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该装置可以以芯片的产品形态存在。该交易验证的装置具体可以是第二电子设备，也可以是设置在第二电子设备上固定的或可移除的功能模块。
第六方面，针对本申请第三方面提供的方法，本申请实施例还提供一种交易验证的装置，该装置具有实现第三方面提供的任意一种方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该装置可以以芯片的产品形态存在。该交易验证的装置具体可以是服务器，也可以是设置在服务器上固定的或可移除的功能模块。
第七方面，本申请实施例提供一种电子设备，其特征在于，所述电子设备包括一个或多个处理器、存储器以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令；当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行第一方面的任意一种实现方式提供的方法；或者，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行第二方面的任意一种实现方式提供的方法。
第八方面，本申请实施例提供一种服务器，其特征在于，所述服务器包括一个或多个处理器、存储器以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令；当所述指令被所述一个或多个处理器执行时，使得所述服务器执行第三方面的任意一种实现方式提供的方法。
第九方面，本申请实施例提供一种交易验证的系统，其特征在于，所述系统包括第一电子设备、第二电子设备和服务器，所述第一电子设备用于执行第一方面所述方法的操作步骤，所述第二电子设备用于执行第二方面所述方法的操作步骤，所述服务器用于执行第三方面所述方法的操作步骤。
第十方面，本申请实施例提供一种存储介质，其特征在于，包括计算机程序，所述计算机程序当在一个或多个处理器上运行的时候用于实现第一方面的任意一种实现方式提供的方法；或者，所述计算机程序当在一个或多个处理器上运行的时候用于实现第二方面的任意一种实现方式提供的方法；或者，所述计算机程序当在一个或多个处理器上运行的时候用于实现第三方面的任意一种实现方式提供的方法。
第十一方面，本申请实施例提供一种计算机程序或计算机程序产品，其特征在于，当所述计算机程序或计算机程序产品在一个或多个处理器上运行的时候用于实现第一方面的任意一种实现方式提供的方法；或者，当所述计算机程序或计算机程序产品在一个或多个处理器上运行的时候用于实现第二方面的任意一种实现方式提供的方法；或者，当所述计算机程序或计算机程序产品在一个或多个处理器上运行的时候用于实现第三方面的任意一种实现方式提供的方法。
第十二方面，本申请实施例提供一种芯片系统，包括至少一个处理器和至少一个接口电路，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，当至少一个处理器执行指令时，至少一个处理器执行如上述第一方面至第三方面，以及其中任一种可能的实现方式提供的方法。
第四方面至第十二方面中任一种设计方式所带来的技术效果可参见第一方面、第二方面或第三方面中不同设计方式所带来的技术效果，此处不再赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的数字货币验证的系统架构示意图；
图2为现有技术提供的币串凭证结构示意图；
图3为现有技术提供的终端设备的逻辑功能示意图；
图4为现有技术提供的端侧双离线交易的流程示意图；
图5为现有技术提供的云端服务器验证数字货币的方法的流程示意图；
图6为本申请实施例提供的币串凭证的结构示意图；
图7为本申请实施例提供的终端设备的逻辑功能示意图；
图8为本申请实施例提供的云侧发行机构的数字货币验证的逻辑结构示意图；
图9为本申请实施例提供的一种服务器存储币串凭证的数字签名的结构示意图；
图9a为本申请实施例提供的一种交易分支示意图；
图9b为本申请实施例提供的另一种交易分支示意图；
图10为本申请实施例提供的一种服务器验证数字货币的流程示意图；
图11为本申请实施例提供的一种端侧双离线交易的流程示意图；
图12为本申请实施例提供的一种第一电子设备的装置示意图；
图13为本申请实施例提供的一种第二电子设备的装置示意图；
图14为本申请实施例提供的一种服务器的装置示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。本申请中的术语“和/或”或字符“/”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或，或A/B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
在介绍本申请实施例之前，为了便于理解本申请实施例，先对现有技术中的数字货币验证的方式进行简单介绍。以下将以云侧系统为例，来说明上述服务器的功能；将以端侧系统为例，来说明上述电子设备的功能，其中，下文将以终端设备A作为第一电子设备、终端设备B作为第二电子设备为例进行描述，下文在描述交易子链的子链数字签名时将用交易子链的数字签名代替。
以下将以数字货币验证为例来说明交易验证的系统架构、流程等。
图1为本申请实施例提供的数字货币验证的系统架构示意图。
示例性的，本申请实施例的系统主要分为云侧系统和端侧系统两部分，云侧系统和端侧系统之间可以进行币串同步或者在线交易，其中：
云侧系统包括：
数字货币发行机构后台系统：用于本发行机构币串凭证的验证、同步等功能。图1中以发行机构A，发行机构B为例进行呈现，示例性的，发行机构可以为银行。
央行机构互联互通平台：将各货币发行机构通过央行联通，用于机构间的交易通信和央行对各机构的审计等工作，图2中发行机构A与发行机构B通过央行机构互联互通平台进行机构互联。
端侧系统包含终端设备安全钱包应用，图1中示例性的示出了终端设备A和终端设备B。可以理解的是，终端设备为电子设备的一种，电子设备包括但不限于：终端设备、固定电子设备、网络设备。其中，终端设备可以是移动终端设备、固定终端设备。电子设备可以是现有技术中的电子设备，也可以是未来出现的电子设备。
示例性的，本申请的实施例中的电子设备可以是可移动电话(mobile phone)、平板电脑(pad)、带无线收发功能的电脑、个人数字助理(personal digital assistant，PDA)、智能手表、上网本、可穿戴电子设备、增强现实技术(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、车载设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、人工智能(artificial intelligence，AI)终端等。
本申请实施例提供了一种数字货币验证的方法，该方法可以应用于电子设备中。以下，将以终端设备作为电子设备的一种对本申请实施例进行描述。本申请实施例提供的技术方案可适用于具有富执行环境(Rich Execution Environment,REE)、可信执行环境(Trusted Execution Environment,TEE)和安全单元(Secure Element,SE)的终端设备:
富执行环境REE模块：也称为普通执行环境，是操作系统及其上层的各种应用的执行环境，例如，在终端设备上实现的客户端钱包应用程序，也称作软钱包，运行在终端设备REE环境中；
可信执行环境TEE模块：是基于ARM的TrustZone技术实现的，该技术在移动设备(包含智能手机、平板电脑、机顶盒、智能电视等)的主处理器上划出了一个安全区域，可以保证加载到该环境内部的代码和数据的安全性、机密性以及完整性。TEE提供的执行空间比常见的移动操作系统(如Linux、Android等)提供的空间具有更高级别的安全性。TEE通常用于运行关键的操作：(1)、移动支付：指纹验证、PIN码输入等；(2)、机密数据：私钥、证书等的安全存储；(3)、内容包括：DRM(数字版权保护)等。TEE可以为REE提供安全服务。
安全单元SE模块：是一种用于存储敏感数据和执行安全应用的微处理器芯片，可应用于身份认证、数字签名、安全存储等场景，是基于硬件的独立运行环境，不与宿主机器共享系统资源，安全级别最高。但是由于具有独立的运算单元，处理能力有限。通常的应用有运营商发放的SIM卡，一些安全公司的加密SD卡，或者内置在设备中的独立芯片模块。
端侧系统内不同的终端设备可以进行离线交易。以终端设备A与终端设备B之间进行双离线交易为例，双离线交易表示使用数字货币交易的双方均为离线状态下，仅通过终端设备传递币串凭证产生的交易，该交易会在原币串凭证末尾追加新的交易子链，新的交易子链会标记本次交易金额，末尾交易子链的金额表示了新币串凭证的价值。
基于图1所示的系统架构，下面介绍现有技术中的数字货币的数字签名的生成和验证的流程。
如图2所示，为现有技术中的币串凭证的结构示意图。
具体的，原始币串包含货币发行时的金额、货币发行机构、冠字号等必要信息，并由货币发行机构对其进行签名；随着货币的流通，会不断在末尾追加交易子链，并在每次交易的末尾对全量数据进行签名。货币的数字凭证结构由原始币串与交易子链组成序列结构，凭证传递都会产生新的交易子链，并添加数字签名保证数据完整性和有效性。
示例性的，如图2所示，在原始币串的基础上，当进行一次交易后，端侧根据原始币串的数据以及本次交易的数据生成的数字签名1，用以说明交易子链1的合法性，其中，交易1和数字签名1构成交易子链1。当发生第二次交易后，则根据原始币串、交易子链1第二次交易相关的数据生成数字签名2，用以说明交易子链2的合法性，其中，交易子链1包含数字签名1，交易2和数字签名2构成交易子链2。以此类推。
现有技术中，每次生成数字签名都需要对所有前序交易数据进行整体签名，因此，在对币串凭证生成数字签名过程中存在冗余的摘要计算。在这种实现下，由于币串凭证交易子链的签名方式为对全量数据进行签名，因此在对币串凭证进行验证过程中需要逐层验证数字签名，在验证数字签名过程中的摘要计算流程也存在冗余计算。
如图3所示，为现有技术的终端设备的逻辑功能示意图。
具体的，在数字货币场景下，终端设备的硬钱包逻辑主要在SE侧的Applet应用程序实现，其中定义了硬钱包交易流程必要的接口和数据。主要的接口功能包括：余额查询，币串同步，转入转出，币串验证等；主要的数据包括用户秘钥，数字货币币串凭证，交易记录，机构证书等，其中，用户秘钥用于标识交易双方身份。
TEE仅用来存储简单的用户标识信息如指纹密码、人脸、通讯秘钥等，其中，通讯秘钥用于设备间通信时信道的加密。
下文以转账交易为例进行说明，涉及付款、收款业务流程。
如图4所示，为现有技术的端侧双离线交易的流程示意图，具体步骤如下：
步骤S401-S402：付款方用户在REE软钱包发起付款请求，REE生成与SE交互的付款指令；
步骤S403：付款方SE接收到付款指令后执行相应的逻辑准备交易，例如余额验证；
步骤S404-S405：付款方SE在币串凭证末尾拼接交易子链产生新的币串凭证，将币串凭证返回给REE；
步骤S406：付款方REE根据新的币串凭证生成收款指令后，发给收款方；
步骤S407：收款方REE透传收款指令到SE；
步骤S408-S409：收款方SE验证币串凭证，验证通过后将币串凭证保存到本地；
步骤S410-S412：收款方返回交易确认信息，付款方接收后完成交易。
如图5所示，为现有技术提供的云端服务器验证数字货币的方法的流程示意图。具体步骤如下：
步骤S501：终端用户连接发行机构服务器，并上传带有N个交易子链的币串凭证，以及与该币串相关的余额和交易流水数据；
步骤S502-S506：云端服务器解析币串凭证数据，在币串凭证中从后往前提取交易子链的数字签名，并依次使用相应的签名算法如国密算法进行验证；
步骤S507-S508：当所有的交易子链的签名都验证通过后，提取原始币串的机构签名和原始币串数据，通过原始币串的机构签名和原始币串数据验证原始币串的合法性；若原始币串的机构签名验证不成功，则该验证流程失败，如步骤S511所示，流程结束。
步骤S509-S510：原始币串的机构签名验证通过后，验证余额和流水的有效性，如果验证成功则币串凭证有效，验证流程结束。
如上描述的现有技术能够有效实现数字货币在线、离线交易的功能，解决离线币串凭证的合法性和安全性问题，然而仍然存在验证过程中存在一定的冗余计算以及受限于性能用户体验较差的不足。这些不足的产生原因如下：
从端侧分析：币串凭证每次传递都会追加一个交易子链，每次追加都需要对所有的凭证数据进行数字签名，给端侧的签名验证带来压力。终端设备的硬钱包逻辑主要在SE中实现，TEE仅用来存储简单的用户标识信息如指纹、人脸等。终端SE为硬件隔离的独立运行环境，存储空间与计算性能受限。端侧TEE的安全略性低于SE，但性能要远高于SE，当前绝大部分的业务逻辑都在SE中实现，TEE中仅实现简单功能，没有充分利用性能。
从服务器侧分析：在服务端验证币串凭证过程中，由于币串凭证交易子链的签名方式为对全量数据进行签名，因此验证过程中需要逐层验证签名，在验签过程中的摘要计算流程存在冗余计算；同时，在数字货币流通过程中，相同冠字号币串会扩散到不同的用户终端中，不同用户的币串凭证中必然存在一定的重复信息，不同用户上传的币串凭证后存在重复的交易子链签名验证。
针对上述问题，本申请实施例提供一种数字货币验证的方法，该方法基于图1所示的系统架构，该方法主要包括如下技术点：
1、对币串凭证的数字签名采用链式结构：随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的数字签名为根据前一次交易的签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。
2、由于币串凭证的链式结构，最后一个交易子链的数字签名可以验证币串凭证整体信息的完整性和合法性。由此，在端侧交互过程中，将SE侧的业务逻辑转移至TEE侧执行，将保证交易合法性数字签名验证过程保留在SE中。
3、云服务器侧接收到端侧同步的币串凭证后，构建币串凭证交易树，以树形结构保存验证通过的交易子链的数字签名，在验证过程中，对交易子链的数字签名进行增量验证，所有币串凭证在验证交易子链签名的过程中，在数据库的交易树结构中可以查询到的签名无需重复验证，只需对数据库中不存在的节点进行增量验证，并在验证成功后在交易树结构中追加已验证的节点，用于后续币串凭证的快速验证。
如图6所示，为本申请实施例提供的币串凭证的结构示意图。
随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的数字签名为根据前一次交易的签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。
示例性的，如图6所示，在原始币串的基础上，当进行一次交易后，端侧根据原始币串的数据以及本次交易的数据生成的数字签名1，用以说明交易子链1的合法性，其中，交易1和数字签名1构成交易子链1。当发生第二次交易后，则根据数字签名1和第二次交易相关的数据生成数字签名2，用以说明交易子链2的合法性，其中，交易2和数字签名2构成交易子链2，以此类推。
这里为了方便描述链式签名的原理，将交易子链中的数字签名、原始币串中的机构签名单独呈现出来。实现过程中，交易子链可以包含数字签名，原始币串可以包含机构签名。
用链式签名方案替代整体签名方案，在对币串凭证生成数字签名和验证数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成和验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
如图7所示，为本申请实施例提供的终端设备的逻辑功能示意图。
示例性的，终端设备包括富执行环境(REE)、可信执行环境(TEE)和安全单元(SE)。
在终端设备中，可信执行环境TEE中实现了数字货币交易流程中的大部分逻辑，包括余额查询、币串同步、转入转出等，同时还保存了指纹密码、通讯秘钥、机构证书、数字货币币串、交易记录等。TEE的计算性能和存储空间都要优于SE，因此可以充分利用端侧的性能，提升用户体验。
安全单元SE中定义了硬钱包交易流程中必要的接口和数据两方面：接口主要为验证币串凭证末尾交易子链的数字签名，用于收款方验证传入币串凭证的合法性；数据主要为币串凭证末尾交易子链的数字签名，用于付款方交易前保证TEE侧的币串没有被篡改。当付款方TEE的币串凭证数据发生篡改时，末末尾交易子链的数字签名也会发生改变，传入SE后发现与SE中收到此币串凭证时存储的数字签名不一致，则验证失败。当收款方收到合法的币串凭证时，将在SE中验证末尾交易子链的数字签名，数字签名验证成功后会在SE中存储该币串凭证对应的末尾交易子链的数字签名。因此，交易的安全性依旧由SE保证，但性能通过使用TEE获得了大幅提升。
如图8所示，为本申请实施例提供的云侧发行机构的数字货币验证的逻辑结构示意图。
在发行结构中，各逻辑模块的功能如下：
币串凭证解析：从用户上传的数据中解析币串凭证各部分的内容，主要提取机构签名与交易子链的数字签名；
数字签名校验：根据本发明方案中的链式签名方法，验证币串凭证上所有数字签名的合法性，并将已验证的数字签名保存到交易树的存储结构中；
交易树存储：数字货币在上传至发行机构后台时，每一个唯一的冠字号都会生成一个表示数字签名信息的节点组成的树形结构，从树根到某一个叶节点的遍历路径代表了一个币串凭证的交易链，多个持有同一冠字号币串的用户同步操作之后，形成的树形结构表示了该原始币串的整个流通传递过程。
冠字号查询：在发行机构后台的存储中，根据币串凭证的冠字号查询相应的验证数据，即该冠字号关联的交易树；
数字签名对比：遍历币串凭证中的数字签名数据，与已验证通过的交易树节点做对比，若找到未验证的节点，则对这些节点进行增量验证。
如图9所示，为本申请实施例提供的一种服务器存储币串凭证的数字签名的结构示意图。
由于币串凭证的传递机制，数字货币流通过程中，同一冠字号的币串凭证会形成如图9所示的拓扑结构。其中数字签名x-n表示付款方x使用该币串凭证第n次付款交易产生的数字签名，使用了付款方x的私钥。
当多个用户同步币串凭证在服务器端验证币串凭证有效性时，在数据库中构建并存储如图树形结构，每个节点为相应交易子链的数字签名值，父节点与子节点的关系由之前币串凭证定义的链式签名方式决定。
示例性的，具体的增量验证方法如下：
以币串凭证经过A、B、C、D用户为例：A->B->D->F，用户D和用户F分别先后在线同步币串凭证到云侧服务器。
如图9a所示，为本申请实施例提供的一种交易分支示意图。
用户D同步币串凭证后形成如图9a的交易分支，其中连线b表示用户A向用户B付款的交易，连线d表示用户B向用户D付款的交易。当此交易分支第一次生成时，需要进行完整的合法性校验，校验内容包括：原始币串的机构签名，根据交易子链b的内容和机构签名验证数字签名A-1，根据交易子链d的内容和数字签名A-1验证数字签名B-1；同理，若交易子链更长，签名可迭代验证。
如图9b所示，为本申请实施例提供的另一种交易分支示意图。用户F同步币串凭证后形成如图9b的交易分支，其中通过简单的签名值对比可以确认交易分支b和d均已通过用户D上传的币串凭证验证完成且合法，用户F的数字签名验证只需验证用户D付款给用户F的交易f与数字签名D-1。
在上述架构示意图以及币串凭证结构示意图的基础上，下面将以两个具体的实施例进行详细描述。
如图10所示，为本申请实施例提供一种的服务器验证数字货币的流程示意图，该方法可以包括步骤S1001-步骤S1010，具体如下：
步骤S1001：用户在同步过程中上传币串凭证到发行机构服务器。
本步骤用户需要将钱包中需要同步的币串凭证根据原始币串中的信息上传到相应的发行机构进行验证。这里描述的原始币串的信息可以包括发行机构标识、币串金额、机构证书、机构保留字段等。在本步骤中每个币串凭证需要携带完整的信息包括：原始币串金额、发信机构证书、发行机构签名、每次交易产生的交易子链，其中每个交易子链中还包括：交易金额、交易信息包括交易索引、付款方公钥、付款方签名等。我们将一个币串凭证的交易子链数声明为N。
步骤S1002：根据币串冠字号查询相应的验证数据。
本步骤在具体验证币串凭证的数字签名前执行，首先从币串凭证中提取冠字号信息，然后在数据库中查询该冠字号是否有已验证的记录。
如果没有记录，则执行步骤S1009-S1010，即将以与现有方案一致的方式逐个交易子链验证数字签名，具体流程见图5，然后将每个交易子链的数字签名数据作为节点构建成一条从原始币串的机构签名开始的分支结构，用于后续币串凭证的快速验证，至此，流程结束；
若存在已验证的记录，则执行步骤S1003-S1008：
步骤S1003：将本币串凭证的数字签名与分支节点存储的已验证的数字签名对比，本步骤需要从原始币串的机构签名开始遍历币串凭证的数字签名数据，并与已验证分支的节点数据比较；
步骤S1004：判断是否存在不一致的节点：若存在数据不一致的节点，则该币串凭证验证失败，流程结束；否则，执行步骤S1005-S1008。
步骤S1005-S1008：获取已验证的交易子链数M：
若M>＝N，则币串凭证的所有交易子链的数字签名均一致，则该币串凭证有效，验证成功，流程结束；
若M<N，说明币串凭证仍然存在未验证的交易子链的数字签名，则迭代验证剩余交易子链的数字签名，然后将验证成功的交易子链的数字签名保存在追加的分支节点上，用于后续币串凭证的快速验证。所有的数字签名验证有效后，则证明币串凭证有效，可进行其他的验证流程，如流水验证、余额验证等。
如图11所示，为本申请实施例提供端侧双离线交易的流程示意图。该流程包含离线交易的两个终端设备之间的流程示意图。实际应用过程中，还包含其他场景，比如在线流程，单离线流程(包括付款方在线收款方离线，或者付款方离线收款方在线)，可以理解的是，当实际应用场景为单离线流程时，付款方或者收款方的流程在本地的处理分别与双离线流程中付款方或者收款方的处理相同。
具体步骤如下：
步骤S1101：用户在REE侧的钱包App操作，发起付款请求。
本步骤中付款方用户根据其他渠道协商收款方的目标地址，按照相应的TEE接口向TEE发送付款请求。
步骤S1102：付款方TEE读取TEE中存储的币串凭证，生成付款指令。
本步骤中TEE会根据付款金额选择合适的币串，经过TEE中的基本验证后提取币串凭证末尾的数字签名，将该数字签名传入SE。其中，基本验证包括验证交易金额是否合法；或初始化设置的限额信息如钱包限额，交易次数，交易限额等是否合法，这些限额信息可以保存到TEE或者SE中，若是保存到SE中，则可以从SE读取到TEE中，由TEE进行验证。交易次数可以通过交易子链个数或者币串凭证长度来判断。
步骤S1103：付款方SE执行付款指令逻辑；
步骤S1104：付款方SE将接收到的来自TEE的数字签名与上一次交易验证通过后保存的末尾交易子链的数字签名做对比，如果本次交易的末尾交易子链的数字签名与SE中的数字签名一致，则可证明TEE中的币串数据没有被篡改，因为SE中存储的末尾交易子链的数字签名从上一次交易完成后没有在SE中被更改。
步骤S1105-S1106：付款方SE生成新的交易子链，并将新的交易子链返回给付款方TEE。
本步骤根据付款方本次交易需要的交易金额以及随机数或其他保留字段生成交易子链数据，并根据上次交易的末尾交易子链的数字签名以及本次交易子链的数据，生成新的交易签名，最后将交易信息和数字签名拼接成新的交易子链返回给TEE，其中所述SE根据所述交易金额生成交易信息。
步骤S1107：付款方TEE将SE返回的新交易子链拼接到原有的币串凭证上，生成收款指令发送给收款方。
步骤S1108：收款方REE透传收款请求到TEE，TEE收到收款请求后执行收款逻辑，并从收款请求中提取出币串凭证的所有数据。
步骤S1109-S1113：收款方在TEE和SE协同验证币串凭证。
本申请传递的是验证签名指令：仅包含末尾签名；现在仅保存了新生成的币串签名。
现有技术的指令为收款指令，包含了整个币串；原先SE保存了整个币串。
本步骤中收款方在TEE中执行大部分的币串验证逻辑，包括原始币串的机构签名验证、余额验证，以及交易子链的数字签名验证。当验证到末尾交易子链的数字签名时，将末尾签名验证所必要的信息通过验证指令传入SE中进行验证，其中，末尾签名验证所必要的信息包括倒数第二个交易子链的数字签名、末尾交易子链的信息、末尾交易子链的数字签名。SE中验证通过后，在SE中保存末尾交易子链的数字签名用于后续交易的付款前对比验证，同时将验证结果返回给TEE。TEE确认验证结果，并将新的币串凭证存储在TEE本地，验证成功后向付款方发送确认信息。
步骤S1114-S1115：付款方接收确认信息，对确认信息进行验证后完成交易。在币串的金额使用完的情况下，对币串标记删除币串标识，后续将币串凭证同步到服务器时由服务器根据该标识将币串凭证删除。可以理解的是，这里的确认信息为上述发明内容中的第二交易响应消息的一种示例。
以上为对本申请实施例提供的数字货币验证的方法的详细说明。
上述主要从方法的角度对本申请实施例的方案进行了介绍。可以理解的是，数字货币验证装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对数字货币验证装置进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
在一个示例中，当对应各个功能划分各个功能单元时，如图12所示，为本申请实施例提供的一种第一电子设备的装置示意图。所述装置1200包括富执行环境REE模块1201、可信执行环境TEE模块1202、安全单元SE模块1203：
所述富执行环境REE模块1201用于：向所述执行环境TEE模块发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型和交易接收方标识；
所述可信执行环境TEE模块1202用于：根据所述交易类型执行第一业务逻辑以获得第一验证指令，向所述安全单元SE模块1203发送所述第一验证指令，所述第一验证指令包含数字签名；
所述安全单元SE模块1203用于：根据所述数字签名验证所述交易的合法性以获得第一验证结果，并将第一验证结果发送给所述可信执行环境TEE模块；
所述可信执行环境TEE模块1202还用于：发送第一交易响应消息给所述富执行环境REE模块，所述第一交易响应消息包含所述第一验证结果；
所述富执行环境REE模块1203还用于：根据所述接收方标识发送第二交易请求消息给第二电子设备。
一种可能的设计，所述可信执行环境TEE模块1202还用于保存至少一个数据凭证；根据所述交易类型以及所述至少一个数据凭证执行所述第一业务逻辑。
一种可能的设计，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述交易子链包括数字签名，所述数字签名用于指示所述交易子链的合法性，所述原始币串包括原始币串金额、发行机构证书、发行机构签名。
一种可能的设计，所述第一交易请求消息还包括交易金额；所述可信执行环境TEE模块1202具体用于：根据所述交易类型以及所述交易金额从所述至少一个币串凭证中选择至少一个币串凭证；对选择的所述至少一个币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；基本验证通过后，提取所述至少一个币串凭证中每个币串凭证的最后一个交易子链的数字签名，生成包括所述每一个币串凭证的最后一个交易子链的数字签名和所述交易金额的第一验证指令。
一种可能的设计，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；所述安全单元SE模块1203具体用于：根据所述第一验证指令中的所述交易金额生成交易信息；根据所述冠字号将本地存储的签名与所述第一验证指令中的所述最后一个交易子链的数字签名进行对比，当所述本地存储的签名与所述第一验证指令中的最后一个交易子链的数字签名一致时，根据所述交易信息、所述最后一个交易子链的数字签名和本地保存的私钥生成第二数字签名；根据所述第二数字签名和所述交易信息生成新的交易子链；生成包括所述新的交易子链的第一验证结果。
一种可能的设计，所述可信执行环境TEE模块1202具体用于根据冠字号将所述新的交易子链更新到所述币串凭证上。
一种可能的设计，所述富执行环境REE模块1203还用于将所述数据凭证同步到服务器。
如图13所示，为本申请实施例提供的一种第二电子设备的装置示意图。该装置1300包括富执行环境REE模块1301、可信执行环境TEE模块1302和安全单元SE模块1303：
所述富执行环境REE模块1301用于：接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述可信执行环境TEE模块1302，所述第二交易请求消息包含至少一个数据凭证，其中，所述数据凭证包括冠字号，所述冠字号为所述数据凭证的唯一标识；
所述可信执行环境TEE模块1302用于：根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，向所述安全单元SE模块1303发送所述第二验证指令，所述第二验证指令包括数字签名；
所述安全单元SE模块1303用于：根据所述数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述可信执行环境TEE模块1302，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；
所述可信执行环境TEE模块1302还用于：接收来自所述安全单元SE模块1303的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述富执行环境REE模块1301，所述第二交易响应消息用于指示交易是否成功；
所述富执行环境REE模块1301还用于：发送第二交易响应消息给第一电子设备。
一种可能的设计，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述交易子链包括数字签名，所述数字签名用于指示所述交易子链的合法性，所述原始币串包括原始币串金额、发行机构证书、发行机构签名。
一种可能的设计，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。
一种可能的设计，所述安全单元SE模块1303具体用于验证所述至少一个数据凭证的每个数据凭证的最后一个交易子链的合法性。
一种可能的设计，所述安全单元SE模块1303还用于所述最后一个交易子链的合法性验证通过后，保存所述最后一个交易子链的数字签名，所述数字签名用于后续交易时作为对比验证的参考值。
如图14所示，为本申请实施例提供的一种服务器的装置示意图。该装置1400包括：
接收模块1401，用于接收来自电子设备的数据凭证；
验证模块1402，用于对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史记录进行对比，验证所述数据凭证中比所述历史记录多余的数据的合法性，其中，所述历史记录为已验证的历史数据凭证；
保存模块1403，用于保存验证成功的所述数据凭证。
一种可能的设计，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和数字签名，所述数字签名为根据前一次交易的签名结果与本次交易数据生成的数字签名。
一种可能的设计，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；所述验证模块1402具体用于根据冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。
一种可能的设计，所述验证模块1402具体用于当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
一种可能的设计，所述验证模块1402具体用于验证数字签名、发行机构签名、余额和交易流水。
一种可能的设计，所述保存模块1403具体用于根据冠字号将已验证的所述交易子链的数字签名作为特征数据存储到所述服务器。
装置实施例中涉及到的方案的具体实现可参考前述方法实施例，在此不再赘述。
当将以上的多个功能单元(或模块)集成在一个处理单元中时，上述各个功能单元执行的动作均可由处理单元根据存储单元中存储的程序执行。其中，处理单元可以是处理器或控制器。存储单元可以是存储器。当处理单元为处理器，存储单元为存储器时，上述各个功能单元执行的动作可以由处理器根据存储器中存储的程序执行。
本申请实施例还提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行上述方法。
本申请实施例还提供了一种包含指令的计算机程序或计算机程序产品，当其在计算机上运行时，使得计算机执行上述方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，简称DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，简称SSD))等。
尽管在此结合各实施例对本申请进行了描述，然而，在实施所要求保护的本申请过程中，本领域技术人员通过查看附图、公开内容、以及所附权利要求书，可理解并实现公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。

Claims (40)

1.一种交易验证的方法，其特征在于，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第一电子设备，所述方法包括：
所述REE向所述TEE发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型；
所述TEE根据所述交易类型执行第一业务逻辑以获得第一验证指令，所述第一验证指令包括待验证的数字签名；
所述TEE向所述SE发送所述第一验证指令；
所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果，并将所述第一验证结果发送给所述TEE；
所述TEE发送第一交易响应消息给所述REE，所述第一交易响应消息包含所述第一验证结果；
所述REE在所述第一验证结果指示验证成功时，根据所述交易的接收方标识向第二电子设备发送第二交易请求消息，所述接收方标识用于指示所述第二电子设备。
2.根据权利要求1所述的方法，其特征在于，
所述TEE保存了至少一个候选的数据凭证；
所述TEE根据所述交易类型执行第一业务逻辑包括：
所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑。
3.根据权利要求2所述的方法，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
4.根据权利要求3所述的方法，其特征在于，所述第一交易请求消息还包括所述交易的交易金额；
所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑包括：
所述TEE根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证；
所述TEE对所述待验证的币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；
所述TEE提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额。
5.根据权利要求4所述的方法，其特征在于，所述通过所述基本验证的币串凭证包括冠字号，所述冠字号为所述通过所述基本验证的币串凭证的唯一标识；
所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果包括：
所述SE根据所述第一验证指令中的所述交易金额生成交易信息；
所述SE根据所述冠字号将本地存储的参考数字签名与所述第一验证指令中的所述最后一个交易子链的子链数字签名进行对比，当所述本地存储的参考数字签名与所述第一验证指令中的最后一个交易子链的子链数字签名一致时，所述SE根据所述交易信息、所述最后一个交易子链的子链数字签名和所述SE本地保存的私钥生成与所述交易对应的数字签名；
所述SE根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链，所述与所述交易对应的交易子链中的子链数字签名为所述与所述交易对应的数字签名；
所述SE生成包括所述与所述交易对应的交易子链的第一验证结果。
6.根据权利要求5所述的方法，其特征在于，所述TEE保存所述第一验证结果；
所述TEE根据所述冠字号将所述与所述交易对应的交易子链更新到所述通过所述基本验证的币串凭证上。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
所述第一电子设备将所述更新后的所述通过所述基本验证的币串凭证同步到服务器。
8.一种交易验证的方法，其特征在于，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第二电子设备，所述方法包括：
所述REE接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述TEE，所述第二交易请求消息包含至少一个数据凭证；
所述TEE根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，所述第二验证指令包括待验证的数字签名；
所述TEE向所述SE发送所述第二验证指令；
所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述TEE，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；
所述TEE接收来自所述SE的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述REE，所述第二交易响应消息用于指示交易是否成功；
所述REE发送第二交易响应消息给第一电子设备。
9.根据权利要求8所述的方法，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
10.根据权利要求9所述的方法，其特征在于，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。
11.根据权利要求9所述的方法，其特征在于，所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果包括：
验证所述至少一个币串凭证中的每个币串凭证的最后一个交易子链的合法性。
12.根据权利要求11所述的方法，其特征在于，所述方法还包括：
所述最后一个交易子链的合法性验证通过后，所述SE保存所述最后一个交易子链的子链数字签名，所述最后一个交易子链的子链数字签名用于后续交易时作为对比验证的参考值。
13.一种交易验证的方法，其特征在于，所述方法应用于服务器，包括：
接收来自电子设备的数据凭证；
对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史数据凭证进行对比，验证所述历史数据凭证没有记录的所述数据凭证中的数据的合法性；
保存所述合法性验证成功的所述数据凭证。
14.根据权利要求13所述的方法，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和子链数字签名，所述子链数字签名为根据前一次交易对应的数字签名与本次交易数据生成的数字签名。
15.根据权利要求14所述的方法，其特征在于，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；
将所述币串凭证与保存在所述服务器的历史币串凭证进行对比包括：
根据所述冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。
16.根据权利要求14所述的方法，其特征在于，所述方法还包括当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
17.根据权利要求15或16所述的方法，其特征在于，所述对交易子链进行验证包括验证子链数字签名、发行机构签名、余额和交易流水。
18.根据权利要求17所述的方法，其特征在于，所述保存验证成功的所述数据凭证包括根据所述冠字号将已验证的所述交易子链的子链数字签名作为特征数据存储到所述服务器。
19.一种第一电子设备，其特征在于，所述第一电子设备包括富执行环境REE模块、可信执行环境TEE模块、安全单元SE模块：
所述富执行环境REE模块用于：向所述执行环境TEE模块发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型；
所述可信执行环境TEE模块用于：根据所述交易类型执行第一业务逻辑以获得第一验证指令，向所述安全单元SE发送所述第一验证指令，所述第一验证指令包含数字签名；
所述安全单元SE模块用于：根据所述数字签名验证所述交易的合法性以获得第一验证结果，并将第一验证结果发送给所述可信执行环境TEE模块；
所述可信执行环境TEE模块还用于：发送第一交易响应消息给所述富执行环境REE模块，所述第一交易响应消息包含所述第一验证结果；
所述富执行环境REE模块还用于：在所述第一验证结果指示验证成功时，根据所述交易的接收方标识向第二电子设备发送第二交易请求消息，所述接收方标识用于指示所述第二电子设备。
20.根据权利要求19所述的第一电子设备，所述可信执行环境TEE模块还用于：
保存至少一个候选的数据凭证；
根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑。
21.根据权利要求20所述的第一电子设备，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
22.根据权利要求21所述的第一电子设备，其特征在于，所述第一交易请求消息还包括所述交易的交易金额；
所述可信执行环境TEE模块具体用于：
根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证；
对所述待验证的币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；
提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额。
23.根据权利要求22所述的第一电子设备，其特征在于，所述通过所述基本验证的币串凭证包括冠字号，所述冠字号为所述通过所述基本验证的币串凭证的唯一标识；
所述安全单元SE模块具体用于：
根据所述第一验证指令中的所述交易金额生成交易信息；
根据所述冠字号将本地存储的参考数字签名与所述第一验证指令中的所述最后一个交易子链的子链数字签名进行对比，当所述本地存储的参考数字签名与所述第一验证指令中的最后一个交易子链的子链数字签名一致时，根据所述交易信息、所述最后一个交易子链的子链数字签名和本地保存的私钥生成与所述交易对应的数字签名；
根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链，所述与所述交易对应的交易子链中的子链数字签名为所述与所述交易对应的数字签名；
生成包括所述与所述交易对应的交易子链的第一验证结果。
24.根据权利要求21所述的第一电子设备，其特征在于，所述可信执行环境TEE模块具体用于：
根据所述冠字号将所述与所述交易对应的交易子链更新到通过所述基本验证的币串凭证上。
25.根据权利要求24所述的第一电子设备，其特征在于，所述富执行环境REE模块还用于将所述更新后的通过所述基本验证的币串凭证同步到服务器。
26.一种第二电子设备，其特征在于，所述第二电子设备包括富执行环境REE模块、可信执行环境TEE模块和安全单元SE模块：
所述富执行环境REE模块用于：接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述可信执行环境TEE模块，所述第二交易请求消息包含至少一个数据凭证；
所述可信执行环境TEE模块用于：根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，向所述安全单元SE模块发送所述第二验证指令，所述第二验证指令包括待验证的数字签名；
所述安全单元SE模块用于：根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述可信执行环境TEE模块，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；
所述可信执行环境TEE模块还用于：接收来自所述安全单元SE模块的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述富执行环境REE模块，所述第二交易响应消息用于指示交易是否成功；
所述富执行环境REE模块还用于：发送第二交易响应消息给第一电子设备。
27.根据权利要求26所述的第二电子设备，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
28.根据权利要求27所述的第二电子设备，其特征在于，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。
29.根据权利要求26所述的第二电子设备，其特征在于，所述安全单元SE模块具体用于：
验证所述至少一个币串凭证的每个币串凭证的最后一个交易子链的合法性。
30.根据权利要求29所述的第二电子设备，其特征在于，所述安全单元SE模块还用于：
所述最后一个交易子链的合法性验证通过后，保存所述最后一个交易子链的子链数字签名，所述最后一个交易子链的子链数字签名用于后续交易时作为对比验证的参考值。
31.一种服务器，其特征在于，包括接收模块、验证模块和保存模块：
所述接收模块用于：接收来自电子设备的数据凭证；
所述验证模块用于：对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史数据凭证进行对比，验证所述历史数据凭证没有记录的所述数据凭证的数据的合法性；
所述保存模块用于：保存所述合法性验证成功的所述数据凭证。
32.根据权利要求31所述的服务器，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和子链数字签名，所述子链数字签名为根据前一次交易对应的数字签名与本次交易数据生成的数字签名。
33.根据权利要求32所述的服务器，其特征在于，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；
所述验证模块具体用于：
根据所述冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。
34.根据权利要求32所述的服务器，其特征在于，所述验证模块具体用于：
当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
35.根据权利要求33或34所述的服务器，其特征在于，所述验证模块具体用于：
验证子链数字签名、发行机构签名、余额和交易流水。
36.根据权利要求33或34所述的服务器，其特征在于，所述保存模块具体用于：
根据所述冠字号将已验证的所述交易子链的子链数字签名作为特征数据存储到所述服务器。
37.一种电子设备，其特征在于，所述电子设备包括存储器和一个或多个处理器，所述一个或多个处理器与所述存储器耦合，其特征在于：
所述存储器用于存储程序；
所述一个或多个处理器，用于执行所述存储器中的程序，使得所述电子设备执行如权利要求1-7中任一项所述的方法；或者，使得所述电子设备执行如权利要求8-12中任一项所述的方法。
38.一种服务器，其特征在于，所述服务器包括存储器和一个或多个处理器，所述一个或多个处理器与所述存储器耦合，其特征在于：
所述存储器用于存储程序；
所述一个或多个处理器，用于执行所述存储器中的程序，使得所述服务器执行如权利要求13-18中任一项所述的方法。
39.一种交易验证的系统，其特征在于，所述系统包括：
权利要求19至25中任一项所述的装置、权利要求26至30中任一项所述的装置以及权利要求31至36中任一项所述的装置。
40.一种计算机可读存储介质，其特征在于，包括计算机程序，所述计算机程序当在一个或多个处理器上运行的时候用于实现所述权利要求1-7中任意一项所述的方法；或者实现所述权利要求8-12中任意一项所述的方法；或者实现所述权利要求13-18中任意一项所述的方法。
CN202010698620.2A 2020-07-20 2020-07-20 交易验证的方法、装置 Pending CN113962676A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202010698620.2A CN113962676A (zh) 2020-07-20 2020-07-20 交易验证的方法、装置
EP21847389.0A EP4184406A4 (en) 2020-07-20 2021-03-12 TRANSACTION VERIFICATION METHOD AND APPARATUS
PCT/CN2021/080336 WO2022016886A1 (zh) 2020-07-20 2021-03-12 交易验证的方法、装置
US18/156,786 US20230177505A1 (en) 2020-07-20 2023-01-19 Transaction Verification Method and Apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010698620.2A CN113962676A (zh) 2020-07-20 2020-07-20 交易验证的方法、装置

Publications (1)

Publication Number Publication Date
CN113962676A true CN113962676A (zh) 2022-01-21

Family

ID=79459604

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010698620.2A Pending CN113962676A (zh) 2020-07-20 2020-07-20 交易验证的方法、装置

Country Status (4)

Country Link
US (1) US20230177505A1 (zh)
EP (1) EP4184406A4 (zh)
CN (1) CN113962676A (zh)
WO (1) WO2022016886A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022206446A1 (zh) * 2021-03-31 2022-10-06 中国人民银行数字货币研究所 交易凭证的生成、验证及存储方法、装置、设备和系统
CN116151827A (zh) * 2023-04-04 2023-05-23 北京银联金卡科技有限公司 一种数字钱包安全框架及基于安全框架的双离线交易方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115082067B (zh) * 2022-07-27 2022-11-25 北京大学 一种基于sm2的数字货币双离线支付方法及装置
DE102022002780A1 (de) * 2022-08-01 2024-02-01 Giesecke+Devrient Advance52 Gmbh Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015179637A1 (en) * 2014-05-21 2015-11-26 Visa International Service Association Offline authentication
CN105590201B (zh) * 2015-04-23 2019-05-10 中国银联股份有限公司 移动支付装置及移动支付系统
CN106355252A (zh) * 2016-08-29 2017-01-25 桂林电子科技大学 一种基于访问控制权限的asp知识库增量式验证方法
CN106506472B (zh) * 2016-11-01 2019-08-02 黄付营 一种安全的移动终端电子认证方法及系统
CN108229956A (zh) * 2017-12-13 2018-06-29 北京握奇智能科技有限公司 网银交易方法、装置、系统以及移动终端
CN110401538B (zh) * 2018-04-24 2022-04-22 北京握奇智能科技有限公司 数据加密方法、系统以及终端
CN111357255B (zh) * 2018-04-27 2021-11-19 华为技术有限公司 构建多个应用通用的可信应用
CN108768963B (zh) * 2018-05-11 2021-02-02 北京握奇智能科技有限公司 可信应用与安全元件的通信方法和系统
CN109766152B (zh) * 2018-11-01 2022-07-12 华为终端有限公司 一种交互方法及装置
CN111245620B (zh) * 2018-11-29 2023-10-27 北京中金国信科技有限公司 一种在终端中的移动安全应用架构及其构建方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022206446A1 (zh) * 2021-03-31 2022-10-06 中国人民银行数字货币研究所 交易凭证的生成、验证及存储方法、装置、设备和系统
CN116151827A (zh) * 2023-04-04 2023-05-23 北京银联金卡科技有限公司 一种数字钱包安全框架及基于安全框架的双离线交易方法
CN116151827B (zh) * 2023-04-04 2023-07-14 北京银联金卡科技有限公司 一种数字钱包安全系统及基于安全系统的双离线交易方法

Also Published As

Publication number Publication date
US20230177505A1 (en) 2023-06-08
EP4184406A4 (en) 2023-11-22
EP4184406A1 (en) 2023-05-24
WO2022016886A1 (zh) 2022-01-27

Similar Documents

Publication Publication Date Title
CN113962676A (zh) 交易验证的方法、装置
JP7472333B2 (ja) バリデータノードにより提供されるブロックチェーントランザクションをマイニングする方法及びシステム
EP3396576B1 (en) Client apparatus, server apparatus and access control system for authorized access
CN109345259A (zh) 基于区块链的虚拟资源转移方法、装置、介质及电子设备
KR101937220B1 (ko) 키 관리가 필요없는 블록체인을 기반한 전자서명 또는 메시지 인증 코드를 생성 및 검증 방법
JP2023532959A (ja) 許可制ブロックチェーンのためのプライバシー保護アーキテクチャ
CN112733178B (zh) 基于数字证书认证的跨链信任方法、装置、设备以及介质
CN113256297B (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质
CN110930152B (zh) 一种基于区块链的数据处理方法及相关设备
CN109447636A (zh) 一种资产转移方法及装置
KR20190132159A (ko) 스마트 컨트랙트를 이용한 블록체인 기반 암호화폐 거래 플랫폼 제공 방법
TW202139127A (zh) 用於與區塊鏈相關聯之服務平台之運算服務
CN109067544A (zh) 一种软硬结合的私钥验证方法、装置及系统
CN111325585A (zh) 一种资产转移方法、装置及计算机可读存储介质
WO2019051377A1 (en) SYSTEMS AND METHODS FOR SYNCHRONIZING A STRONG CHAMBER CHAMBER USING A DISTRIBUTED REGISTER
CN111597269A (zh) 一种基于区块链的合约实现方法、装置及设备
CN113132459B (zh) 分布式存储方法、系统、存储介质、信息数据处理终端
KR20190132160A (ko) 스마트 컨트랙트를 이용한 암호화폐 거래 플랫폼 제공 방법
CN111259411A (zh) 区块链管理方法、装置、电子设备及可读存储介质
KR102376783B1 (ko) 블록체인 기반의 거래내역 확인 시스템
CN115811412A (zh) 一种通信方法、装置、sim卡、电子设备和终端设备
AU2022245375A1 (en) Reducing transaction aborts in execute-order-validate blockchain models
JP2022032116A (ja) データ移行方法、データ移行システム、およびノード
CN111915313B (zh) 用于区块链的数字资产转移控制方法、装置及通信系统
CN107493289A (zh) 一种网银安全认证方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB03 Change of inventor or designer information
CB03 Change of inventor or designer information

Inventor after: Mu Changchun

Inventor after: Di Gang

Inventor after: Zhao Xinyu

Inventor after: Cheng Shuo

Inventor after: Zhang Heng

Inventor after: Nie Guangyao

Inventor after: Cui Peidong

Inventor after: Peng Meiling

Inventor before: Cheng Shuo

Inventor before: Zhang Heng

Inventor before: Nie Guangyao

TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20230801

Address after: Floor 20, block a, Jintang center, No. 18, Fengtai North Road, Fengtai District, Beijing 100071

Applicant after: THE PEOPLES BANK OF CHINA, DIGITAL CASH Research Institute

Applicant after: HUAWEI TECHNOLOGIES Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Applicant before: HUAWEI TECHNOLOGIES Co.,Ltd.