用于减轻票据融资欺诈的方法和设备与流程

1.本说明书总体涉及计算机技术，更具体地，涉及用于减轻票据融资欺诈的方法和设备。


背景技术：

2.票据融资是企业以应收账款(包括，例如，应收客户账款)借款的一种方式。票据融资帮助企业改善现金流，向员工和供应商付款，并且相比于企业必须等到客户全额支付余额，可以更早地对运营和增长再投资。
3.与票据融资相关的风险之一是欺诈。例如，一些企业可能会通过单方面制作假票据并试图使用此类票据借钱来实施欺诈。一些企业通过与他人勾结而实施欺诈。一些企业可能会通过从多个资金提供者或投资人以相同票据多次借钱来实施欺诈。此类欺诈活动难以检测和减轻。


技术实现要素：

4.在一个方面，一种计算机实施的用于减轻票据融资欺诈的方法包括：接收来自第一用户的第一交易，第一交易包括票据的第一承诺值和用于证明第一用户是票据的开具方的第一证明，第一承诺值基于第一用户对应的第一令牌生成；验证第一证明；接收来自第二用户的第二交易，第二交易包括第一用户对应的第一令牌、票据的第二承诺值、以及用于证明第二用户已经认证票据的第二证明，第二承诺值基于第二用户对应的第二令牌和第二用户生成的认证文件生成；确定第一令牌有效并验证第二证明；接收来自第三用户的第三交易，第三交易包括第二用户对应的第二令牌和由第三用户生成的第三证明；确定第二令牌有效并验证第三证明，以确定没有票据融资欺诈。
5.在另一方面，一种计算机实施的用于减轻票据融资欺诈的方法包括：接收来自第一用户的第一交易，第一交易包括票据的第一承诺值和用于证明第一用户是票据的开具方的第一证明，第一承诺值基于第一用户对应的第一令牌生成；验证第一证明；接收来自第二用户的第二交易，第二交易包括第一用户对应的第一令牌、票据的第二承诺值、以及用于证明第二用户是票据的接收方的第二证明，第二承诺值基于第二用户对应的第二令牌生成；确定第一令牌有效并验证第二证明；接收来自第三用户的第三交易，第三交易包括第二用户对应的第二令牌、票据的第三承诺值、以及用于证明第三用户已审核并认证过票据的第三证明，第三承诺值基于第三用户对应的第三令牌和第三用户生成的认证文件生成；确定第二令牌有效并验证第三证明；接收来自第四用户的第四交易，第四交易包括第三用户对应的第三令牌和由第四用户生成的第四证明；确定第三令牌有效，验证第四证明，以确定没有票据融资欺诈。
6.在另一方面，一种用于减轻票据融资欺诈的设备包括：一个或多个处理器；一个或多个计算机可读存储器，耦接到一个或多个处理器并且其上储存有指令，该指令可由一个或多个处理器执行以：接收来自第一用户的第一交易，第一交易包括票据的第一承诺值和
用于证明第一用户是票据的开具方的第一证明，第一承诺值基于第一用户对应的第一令牌生成；验证第一证明；接收来自第二用户的第二交易，第二交易包括第一用户对应的第一令牌、票据的第二承诺值、以及用于证明第二用户已经认证票据的第二证明，第二承诺值基于第二用户对应的第二令牌和第二用户生成的认证文件生成；确定第一令牌有效并验证第二证明；接收来自第三用户的第三交易，第三交易包括第二用户对应的第二令牌和由第三用户生成的第三证明；确定第二令牌有效并验证第三证明，以确定没有票据融资欺诈。
7.在又一方面，一种非暂态计算机可读介质，计算机可读介质中存储有指令，指令当由设备的处理器执行时，使设备执行用于减轻票据融资欺诈的方法。该方法包括：接收来自第一用户的第一交易，第一交易包括票据的第一承诺值和用于证明第一用户是票据的开具方的第一证明，第一承诺值基于第一用户对应的第一令牌生成；验证第一证明；接收来自第二用户的第二交易，第二交易包括第一用户对应的第一令牌、票据的第二承诺值、以及用于证明第二用户已经认证票据的第二证明，第二承诺值基于第二用户对应的第二令牌和第二用户生成的认证文件生成；确定第一令牌有效并验证第二证明；接收来自第三用户的第三交易，第三交易包括第二用户对应的第二令牌和由第三用户生成的第三证明；确定第二令牌有效并验证第三证明，以确定没有票据融资欺诈。
附图说明
8.包含在本文中并构成本文一部分的附图示出了实施例。在参考附图的以下描述中，除非另有所示，否则不同附图中的相同数字表示相同或类似的元素。
9.图1是根据实施例的区块链系统的示意图。
10.图2是根据实施例的用于实现区块链系统中的节点的计算设备的示意图。
11.图3是根据实施例的用于减轻票据融资欺诈的方法的流程图。
12.图4是根据实施例的用于减轻票据融资欺诈的方法的流程图。
13.图5是根据实施例的用于减轻票据融资欺诈的方法的流程图。
14.图6是根据实施例的用于减轻票据融资欺诈的方法的流程图。
15.图7是根据实施例的用于减轻票据融资欺诈的设备的框图。
具体实施方式
16.本说明书的实施例提供了用于减轻票据融资欺诈的方法和设备。该方法和设备可以利用区块链系统来验证用户提交的票据。可以检测到假票据，并且可以防止使用此类假票据进行借钱的欺诈性的尝试。该方法和设备还可以实现确定多个用户是否相互勾结的协议。所述方法和设备可以进一步实现确定票据是否已经使用于票据融资的协议。如果确定票据已经使用于票据融资，则该方法和设备可以防止使用相同票据进行其他融资尝试。该方法和设备可以进一步实现保护用户隐私的协议。以这种方式，该方法和设备可以使用区块链系统验证票据，而无需向公众透露票据的具体内容。
17.本说明书中公开的实施例具有一个或多个技术效果。在一些实施例中，所述方法和设备要求用户提交证明以便验证用户提交的票据。由此，该方法和设备可以检测假票据并防止使用假票据借钱的欺诈性的尝试。在一些实施例中，方法和设备支持使用区块链系统验证票据。由此，该方法和设备可以将票据存储在数据结构中，其可以防止恶意方的篡改
和操纵。在一些实施例中，所述方法和设备还支持可以确定多个用户是否相互勾结的协议。由此，该方法和设备可以使用区块链系统上的数据记录来检测和防止勾结。在一些实施例中，这些方法和设备还支持一种协议，该协议可以使用区块链系统计算待验证的票据的承诺值。针对票据计算出的承诺值(commitment value)可以与令牌(token)和随机值相关联。令牌可用于在承诺值被用户泄露后使承诺值无效。由此，该方法和设备可以防止使用相同票据的双重融资。随机值可用于引入额外的随机性以进一步保护用户隐私。由此，该方法和设备可以利用区块链系统验证票据，而无需向公众透露任何私人信息。
18.区块链系统，也称为分布式账本系统(dls)或共识系统，可以使参与各方安全且不可篡改地存储数据。在不参考任何特定用例的情况下，区块链系统可以包括任何dls并且可以用于公有区块链网络、私有区块链网络和联盟区块链网络。公有区块链网络向所有实体开放，以使用该系统并参与共识过程。私有区块链网络为特定实体提供，该特定实体集中控制读写权限。联盟区块链网络针对选择的实体组群提供，该实体组群控制共识过程，并且联盟区块链网络包括访问控制层。
19.区块链系统使用点对点(peer-to-peer，p2p)网络实现，其中节点彼此之间直接通信，例如，不需要固定的中央服务器。p2p网络中的每个节点可以发起与p2p网络中的另一节点的通信。区块链系统维护一个或多个区块链。
20.区块链是以防止恶意方篡改和操纵数据的方式存储诸如交易等数据的数据结构。以这种方式存储的交易可以是不可变的并且在随后被验证。区块链包括一个或多个区块。每个区块通过包括紧邻其之前的前一区块的加密哈希值(cryptographic hash)连接到该前一区块。每个区块还可以包括时间戳、自身的加密哈希值以及一个或多个交易。通常已经由区块链系统的节点验证的交易可以经哈希处理并编码成诸如默克尔(merkle)树等数据结构。在默克尔树中，树的叶节点处的数据是经哈希处理的，并且在该树的每个分支中的所有哈希值可以在该分支的根处连接。此过程沿着树持续一直到整个树的根部，在整个树的根部处存储了代表树中所有数据的哈希值。声称具有存储在树中的交易的哈希值可以通过确定其是否与树的结构一致而被快速验证。
21.区块链系统包括管理、更新和维护一个或多个区块链的计算节点的网络。所述网络可以是公有区块链网络、私有区块链网络或联盟区块链网络。例如，许多实体，诸如数百、数千或甚至数百万实体，可以在公有区块链网络中操作，并且每个实体操作公有区块链网络中的至少一个节点。因此，公有区块链网络可被认为是关于参与实体的公有网络。有时，大多数实体(节点)必须对每个区块签名才能使该区块有效并被添加到区块链网络的区块链中。示例性公有区块链网络包括利用被称为区块链的分布式账本的特定点对点(peer-to-peer)支付网络。
22.通常，公有区块链网络可以支持公开交易。公开交易为公有区块链网络内的所有节点共享，并存储在全局区块链中。全局区块链是跨所有节点复制的区块链，并且所有节点相对于全局区块链处于完全共识状态。为了达成共识(例如，同意向区块链添加区块)，在公有区块链网络中实施共识协议。共识协议的示例包括工作量证明(pow)(例如，在一些加密货币网络中实现)、权益证明(pos)和权威证明(poa)。
23.通常，可以为特定实体提供私有区块链网络，该特定实体集中控制读写权限。该实体控制哪些节点能够参与到区块链网络中。因此，私有区块链网络通常被称为许可网络，其
对谁被允许参与网络，以及它们的参与程度(例如，仅在某些交易中)进行限制。可以使用各种类型的访问控制机制(例如，现有参与者对添加新实体进行投票，监管机构可以控制准入)。
24.通常，联盟区块链网络在参与实体之间是私有的。在联盟区块链网络中，共识处理由一组授权的节点控制，一个或多个节点由相应实体(例如，金融机构、保险公司)操作。例如，由十(10)个实体(例如，金融机构、保险公司)组成的联盟可以操作联盟区块链网络，每个实体可以操作联盟区块链网络中的至少一个节点。因此，联盟区块链网络可以被认为是关于参与实体的私有网络。在一些示例中，每个实体(节点)必须对每个区块签名，以使区块有效并被添加到区块链中。在一些示例中，至少实体(节点)的子集(例如，至少7个实体)必须对每个区块签名，以使区块有效并被添加到区块链中。
25.图1示出了根据实施例的区块链系统100的示意图。参考图1，区块链系统100可以包括被配置为在区块链120上操作的多个节点，例如节点102-110。节点102-110可以形成网络112，例如点对点(p2p)网络。节点102-110中的每一个可以是被配置为存储区块链120的副本的计算设备，诸如计算机或计算机系统，或者可以是在计算设备上运行的软件，诸如进程或应用。节点102-110中的每一个可以具有唯一标识符。
26.区块链120可以包括为诸如图1中的区块b1-b5的数据区块形式的记录增长列表。区块b1-b5中的每一个可以包括时间戳、前一区块的加密哈希值，以及当前区块的数据，该数据可以是诸如货币交易等交易。例如，如图1所示，区块b5可以包括时间戳、区块b4的加密哈希值和区块b5的交易数据。此外，例如，可以对前一个区块执行哈希操作以生成前一个区块的加密哈希值。哈希操作可以通过诸如sha-256等哈希算法将各种长度的输入转换为固定长度的加密输出。
27.节点102-110可以被配置为对区块链120执行操作。例如，当节点(例如，节点102)想要将新数据存储到区块链120上时，该节点可以生成要被添加到区块链120的新区块，并将该新区块广播到网络112中的例如节点104-110的其他节点。基于新区块的合法性，例如，其签名和交易的有效性，其他节点可以确定接受该新区块，使得节点102和其他节点可以将该新区块添加到它们各自的区块链120的副本中。随着重复该过程，可以将越来越多的数据区块添加到区块链120。
28.图2示出了根据实施例的用于实现在区块链系统中的节点(例如，节点102(图1))的计算设备200的示意图。参考图2，计算设备200可以包括通信接口202、处理器204和存储器206。
29.通信接口202可以便于计算设备200与实现网络中其他节点(例如，节点104-110(图1))的设备之间的通信。在一些实施例中，通信接口202被配置为支持一个或多个通信标准，诸如互联网标准或协议、综合业务数字网(isdn)标准，等等。在一些实施例中，通信接口202可以包括以下中的一个或多个：局域网(lan)卡、电缆调制解调器、卫星调制解调器、数据总线、电缆、无线通信信道、基于无线电的通信信道、蜂窝通信信道、基于互联网协议(ip)的通信设备、或用于有线和/或无线通信的其他通信设备。在一些实施例中，通信接口202可以基于公有云基础设施、私有云基础设施、混合公有/私有云基础设施。
30.处理器204可以包括一个或多个专用处理单元、专用集成电路(asic)、现场可编程门阵列(fpga)或各种其他类型的处理器或处理单元。处理器204与存储器206耦合，并且被
配置为执行存储在存储器206中的指令。
31.存储器206可以存储可处理器可执行指令和数据，例如区块链120(图1)的副本。存储器206可以包括任何类型的易失性或非易失性存储器设备或其组合，例如静态随机存取存储器(sram)、电可擦除可编程只读存储器(eeprom)、可擦除可编程只读存储器(eprom)、可编程只读存储器(prom)、只读存储器(rom)、磁存储器、闪存或磁盘或光盘。当存储器206中的指令由处理器204执行时，计算设备200可以对区块链120执行操作。
32.图3图示了根据实施例的用于减轻票据融资欺诈的方法300的流程图。参考图3，多个用户可以在区块链上，例如区块链120(图1)，拥有账户。可以实施区块链以支持各种类型的用户或各方，包括例如个人、企业、银行、金融机构、医院以及其他类型的公司、组织等。
33.为了说明，图3中描绘了三个用户。包括卖方、银行和被称为权威(authority)的受信任用户。假设卖方有兴趣从银行获得票据融资。卖方可能试图通过声称具有向买方(也可能是区块链的用户，如下文将参考图4描述)开具的未结票据来获得该融资。卖方可能出于各种原因开具票据，包括例如过去或未来提供的服务或出售给买方的产品。如果卖方确实具有向买方开具的未结票据，如果卖方同意使用未结票据获得融资，银行可能愿意向卖方提供票据融资。但是，银行可能希望确保票据确实存在并且尚未用于从其他机构获得融资。因此，在银行同意向卖方提供票据融资之前，银行可能会要求卖方证明票据的有效性。
34.在一些实施例中，如果卖方能够请求权威基于下面详细描述的方法300确认票据的有效性，银行可能愿意接受票据的有效性。在一些实施例中，权威可以是受信任的用户，例如政府机构或海关官员。权威也可能是代表政府机构或海关官员的受信任用户。
35.在步骤302，卖方可以生成数字票据。数字票据可以采用多种格式，包括例如区块链用户已同意的标准化格式。数字票据可以包含数据字段，包括例如卖方的身份或标识符、买方的身份或标识符、所提供的产品或服务的描述、应付金额、付款条件(或付款方式)等。
36.卖方还可以在步骤302生成记录在区块链上的承诺值。在一些实施例中，卖方可以通过考虑票据本身的至少一部分信息、卖方信息和卖方信息来计算承诺值cm_invoice。在一些实施例中，cm_invoice可以基于单向函数来计算。本领域普通技术人员将理解，函数是单向的，如果，给定一个随机元素很难计算出y∈d以得到g(y)＝x。换句话说，很难从单向函数的输出变量值计算单向函数的输入变量值，使得该函数实际上无法求逆，因此，该函数被称为“单向”。哈希函数，诸如sha256等，是单向函数的示例。
37.例如，在一些实施例中，cm_invoice可以计算为(pk_seller，pk_buyer，invoice_digest，tn，r)的哈希值，其中pk_seller和pk_buyer分别代表卖方和买方的公钥，invoice_digest代表数字票据的哈希值，或数字票据的一个或多个部分的哈希值。tn可以表示卖方生成的令牌，可用于防止卖方使用数字票据多次获得融资(即防止双重融资)。在一些实施例中，tn可以包括随机数。然而，应当理解，tn还可以包括字母数字值，并且在一些实施例中，tn可以包括序列号。r可以表示卖方生成的随机因素，以进一步保护pk_seller、pk_buyer和invoice_digest中包含的信息。在一些实施例中，r可以是随机数或随机字母数字值。
38.在步骤302，卖方还可以生成零知识证明，记为seller’s_proof。零知识证明是指允许证明者向验证者证明声明为真，而不透露任何超出声明本身有效性以外信息的技术。在步骤302，卖方是证明者，其可以向区块链或在区块链上执行的智能合约(作为验证者)证
明卖方是所讨论的票据的真正开具方。卖方可以尝试证明此情况通过指出：(1)cm_invoice格式正确，(2)卖方确实是卖方本身。
39.在实施例中，为了证明cm_invoice格式正确，卖方可以向区块链证明(pk_seller，pk_buyer，invoice_digest，tn，r)的承诺值是cm_invoice。在实施例中，为了证明卖方是卖方本身，卖方可以向区块链证明卖方拥有卖方的私钥，或者向区块链证明pk_seller＝h(sk_seller)，其中sk_seller代表只有卖方知道的私钥，h()是用于根据私钥计算公钥的哈希函数。
40.在一些实施例中，卖方和区块链可以同意实施零知识证明技术，例如零知识简洁非交互知识论证(zero-knowledge succinct non-interactive argument of knowledge，缩写为zk-snark)等。卖方可以向区块链证明卖方知道私密输入w，使得对于公共输入x，x和w之间的特定关系成立。在一些实施例中，该关系可以被定义为算术电路(arithmetic circuit)。在一些实施例中，算术电路可以基于多项式方程来定义，可以基于x和w评估该多项式方程。在一些实施例中，基于算术电路和为零知识证明建立的一个或多个安全参数，可以在设置阶段生成证明密钥和验证密钥。本领域的普通技术人员将理解，设置阶段可以由受信方执行，或者由多个独立方协作使用多方计算来执行。
41.在一些实施例中，卖方可以将x为cm_invoice并将w设置为基于pk_seller、pk_buyer、invoice_digest、tn、r和sk_seller生成的值。例如，可以通过将pk_seller、pk_buyer、invoice_digest、tn、r和sk_seller连接在一起来生成w。以这种方式，卖方可以使用私密输入和公共输入以及证明密钥生成seller’s_proof，以向区块链证明卖方拥有私密输入w。在一些实施例中，区块链可以使用公共输入和在设置阶段生成的验证密钥来验证seller’s_proof。在一些实施例中，如果区块链接受卖方关于卖方拥有私密输入w的证明，区块链可以接受卖方的声明为真。
42.在步骤304，卖方可以向区块链提交交易，交易的负载(payload)包含{cm_invoice，seller’s_proof}。出于说明目的，此交易可称为“issue_invoice”交易。
43.在步骤306，区块链可以验证seller’s_proof以确定卖方是否拥有私密输入w。在一些实施例中，区块链可以利用在区块链上执行的一个或多个智能合约来实施该确定。智能合约可以是以计算机代码形式执行的计算机协议，其被纳入到区块链中，以促进、验证或执行合约的协商或履行。例如，区块链的用户可以使用诸如c 、java、solidity、python等编程语言将商定的条款编程为智能合约，并且当满足条款时，智能合约可以在区块链自动执行，例如执行交易。又例如，智能合约可以包括多个子例程或函数，每个子例程或函数可以是执行专用任务的一系列程序指令。智能合约可以是在完全或部分没有人工交互的情况下执行的操作代码。
44.在一些实施例中，可以将智能合约纳入区块链以确定seller’s_proof是否可接受。智能合约可以使用公共输入和验证密钥来验证seller’s_proof。如果seller’s_proof无法通过验证，智能合约可能会拒绝让卖方继续进行。另一方面，如果seller’s_proof可以通过验证，那么智能合约可以确定seller’s_proof是可接受的并继续在卖方提交的票据池中记录cm_invoice。在一些实施例中，卖方提交的票据池可以被构造为默克尔树t_invoice，并且cm_invoice可以记录在默克尔树t_invoice的叶节点上。
45.在步骤308，卖方可以继续要求权威验证该卖方生成的数字票据。在一些实施例
中，卖方可以通过链下通信渠道(off-chain communication channel)将数字票据以及tn的值和r的值私下发送给权威。卖方也可以向权威发送cm_invoice。替代地或附加地，权威可以根据数字票据和从卖方收到的tn的值和r的值重建cm_invoice。
46.在步骤310，权威可以检查数字票据以确定数字票据是否有效。例如，权威可以将数字票据中声明的未结金额与权威维护的或可访问的记录进行比较。例如，如果卖方是出口商，并且为出口到海外买方的产品开具数字票据，则权威可以将数字票据与海关官员维护的记录进行比较，以确定在产品描述和应付金额上是否有差异。权威还可以将数字票据与其他类型的记录进行比较，包括例如税务记录、财务披露等。
47.在一些实施例中，权威可以使数字票据无效，如果权威确定cm_invoice没有记录在卖方提交的票据池中，或者记录的cm_invoice与(pk_seller，pk_buyer，invoice_digest，tn，r)的承诺值不匹配。以这种方式，如果卖方试图绕过步骤304-306，或试图更改数字票据或更改tn的值或r的值，则此类尝试可以被权威检测到，然后权威可以使数字票据无效并防止欺诈。另一方面，如果权威确定数字票据是有效的，则权威可以继续生成经认证的承诺值，以记录在区块链上。在一些实施例中，权威可以将经认证的承诺值cm_cert_invoice计算为：commitment(pk_seller，pk_buyer，invoice_digest，cert_digest，tn’，r’)。
48.在一些实施例中，cm_cert_invoice可以基于与卖方用来计算cm_invoice相同的单向函数来计算，其中pk_seller、pk_buyer和invoice_digest的值相同。cert_digest可以表示由权威生成的一份或多份认证文件的哈希值。认证文件可以采用多种格式，包括例如由政府机构或海关官员为提供认证而制定的标准化格式。权威也可以生成一个新的tn’和一个新的r’。以此方式，权威可以计算出与卖方计算出的承诺值不同的承诺值，有效防止无关用户将两个承诺值连接在一起，进而防止无关用户将卖方和权威连接在一起。
49.在步骤310，权威还可以生成零知识证明，记为authority’s_proof。权威可以生成authority’s_proof以向区块链证明权威已经审核并认证了卖方提供的票据。权威可以尝试证明此情况通过指出：(1)cm_invoice格式正确，(2)cm_invoice记录在卖方提交的票据池中，(3)cm_cert_invoice格式正确。
50.在实施例中，为了证明cm_invoice格式正确，权威可以向区块链证明权威知道pk_seller、pk_buyer、invoice_digest、tn和r的值以及证明(pk_seller，pk_buyer，invoice_digest，tn，r)的承诺值是cm_invoice。在实施例中，为了证明cm_invoice记录在卖方提交的票据池中，权威可以向区块链证明cm_invoice是默克尔树t_invoice中的有效叶节点。在实施例中，为了证明cm_cert_invoice格式正确，卖方可以向区块链证明(pk_seller，pk_buyer，invoice_digest，cert_digest，tn’，r’)的承诺值是cm_cert_invoice。
51.在一些实施例中，权威和区块链可以同意实施上述零知识证明技术。例如，权威可以向区块链证明权威知道私密输入w，使得对于公共输入x，x和w之间的特定关系成立。在一些实施例中，该关系可以被定义为算术电路，算术电路可以基于多项式方程来定义，可以基于x和w评估该多项式方程。在一些实施例中，基于算术电路和为零知识证明建立的一个或多个安全参数，可以在设置阶段生成证明密钥和验证密钥。在一些实施例中，权威可以设置x为包含tn和cm_cert_invoice的值，并设置w为基于pk_seller、pk_buyer、invoice_digest、cert_digest、r、tn’、r’和cm_invoice生成的值。以这种方式，权威可以生成
authority’s_proof以向区块链证明该权威拥有私密输入w。在一些实施例中，如果区块链接受权威关于权威拥有私密输入w的证明，区块链可以接受权威的声明为真。
52.在步骤312，权威可以将认证文件和tn’和r’的值发送给卖方，以便卖方之后可以使用认证文件从银行获得融资。在步骤314，权威可以向区块链提交交易，交易的负载包含{tn，cm_cert_invoice，authority’s_proof}。出于说明目的，此交易可称为“authority_certified_invoice”交易。在一些实施例中，权威可以具有在区块链上注册的公共的受信任身份。在这些实施例中，权威可以使用权威的私有签名密钥对交易和负载进行签名。
53.在步骤316，区块链可以利用智能合约来验证权威的身份(例如，基于权威用于签署交易的签名)并检查包含在负载中的tn是否已经被使用或被消耗。在一些实施例中，智能合约可以在区块链上维护使用的令牌列表以记录使用的令牌。如果负载中包含的tn被列在已用令牌列表中，则智能合约可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。另一方面，如果负载中包含的tn未被列在已用令牌列表中，则智能合约可以继续验证authority’s_proof是否可接受。智能合约可以使用公共输入和验证密钥来验证authority’s_proof。如果authority’s_proof可以被验证通过，那么智能合约可以确定authority’s_proof是可接受的并且继续在权威认证的票据池中记录cm_cert_invoice。在一些实施例中，经权威认证的票据池可以被构造为默克尔树t_cert_invoice并且cm_cert_invoice可以记录在默克尔树t_cert_invoice的叶节点上。智能合约还可以添加tn到已用令牌列表以指示该tn已经被使用，因此，使该tn在未来的使用中无效。
54.在步骤318，卖方可以继续请求来自银行的票据融资。在一些实施例中，卖方可以通过链下通信渠道(off-chain communication channel)将数字票据、认证文件以及tn’和r’的值私下发送给银行。卖方也可以计算cm_cert_invoice的值并将cm_cert_invoice的值发送给银行。替代地或附加地，银行可以根据数字票据、认证文件和从卖方收到的tn’的值和r’的值重建cm_cert_invoice。
55.在步骤320，银行可以确定数字票据和认证文件是否有效。例如，如果数字票据未经权威认证，银行可以使数字票据无效。银行可以通过确定cm_cert_invoice是否记录在权威认证的票据池中(例如，在默克尔树t_cert_invoice中)来做出此确定。如果cm_cert_invoice未记录在经权威认证的票据池中，银行可以确认数字票据无效，并拒绝卖方继续进行。另一方面，如果cm_cert_invoice记录在经权威认证的票据池中，则银行可以确定数字票据是有效的。然后，银行可以继续决定是否向卖方提供票据融资。由于cm_cert_invoice至少部分是根据认证文件生成的，因此只有当银行从卖方收到真认证文件时，银行才能在经权威认证的票据池中找到cm_cert_invoice。以此方式，卖方进行的制造假认证文件的任何尝试都会被检测到，进而这样的欺诈活动可以被阻止。
56.在一些实施例中，银行还可以确定卖方提供的tn’是否已经被使用。在一些实施例中，银行可以调用在区块链上执行的智能合约以确认tn’是否被列在已用令牌列表中。如果tn’被列在已用令牌列表中，则银行可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。如果tn’未被列在已用令牌列表中，银行可继续决定是否向卖方提供票据融资。
57.应当理解，银行在确定是否向卖方提供票据融资时可能会考虑各种因素。这样的因素可以包括例如票据的大小、卖方的信用评分和信用历史、银行与卖方的先前交易等等。
其他因素可能包括，例如，买方的信用评分和银行与买方的先前交易。
58.如果银行决定拒绝卖方的票据融资请求，银行可以通过链下通信渠道私下将该决定传达给卖方，在这种情况下，卖方可以选择重复步骤318，并向不同的资金提供方请求票据融资。另一方面，如果银行决定向卖方提供票据融资，银行可以在步骤320继续生成零知识证明，记为bank’s_proof，以向区块链证明银行已验证卖方要求提供票据融资的有效性。银行可以尝试证明此情况通过指出：(1)cm_cert_invoice格式正确，(2)cm_cert_invoice记录在权威认证的票据池中。
59.在实施例中，为了证明cm_cert_invoice格式正确，银行可以向区块链证明银行知道pk_seller、pk_buyer、invoice_digest、cert_digest、tn’和r’的值以及证明(pk_seller，pk_buyer，invoice_digest，cert_digest，tn’，r’)的承诺值是cm_cert_invoice。在实施例中，为了证明cm_cert_invoice记录在权威认证的票据池中，银行可以向区块链证明cm_cert_invoice是默克尔树t_cert_invoice中的有效叶节点。
60.在一些实施例中，银行和区块链可以同意实施上述零知识证明技术。例如，银行可以向区块链证明银行知道私密输入w，使得对于公共输入x，x和w之间的特定关系成立。在一些实施例中，该关系可以被定义为算术电路，算术电路可以基于多项式方程来定义，可以基于x和w评估该多项式方程。在一些实施例中，基于算术电路和为零知识证明建立的一个或多个安全参数，可以在设置阶段生成证明密钥和验证密钥。在一些实施例中，银行可以将x为tn’，并将w设置为基于pk_seller、pk_buyer、invoice_digest、cert_digest、r’和cm_cert_invoice生成的值。以这种方式，银行可以生成bank’s_proof以向区块链证明该银行拥有私密输入w。在一些实施例中，如果区块链接受银行关于银行拥有私密输入w的证明，区块链可以接受银行的声明为真。
61.在步骤322，银行可以向区块链提交交易，交易的负载包含{tn’，bank’s_proof}。出于说明目的，此交易可称为“issue_financing”交易。
62.在步骤324，区块链可以使用智能合约来检查包含在负载内的tn’是否已经使用。在一些实施例中，智能合约可以检查tn’是否被列在已用令牌列表中。如果tn’被列在已用令牌列表中，则智能合约可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。如果tn’未被列在已用令牌列表中，智能合约可以继续验证bank’s_proof是否可接受。智能合约可以使用公共输入和验证密钥来验证bank’s_proof。如果可以验证bank’s_proof，则智能合约可以确定bank’s_proof是可接受的并使该tn’无效(例如，通过将该tn’添加到已用令牌列表)，并在步骤326向银行报告根据收到的交易没有检测到欺诈，以便银行可以继续向卖方发放票据融资。
63.应当理解，虽然上述示例使用了一个已用令牌列表来记录所有使用过的令牌，但是这种实施方式仅作为示例提供，并不意味着限制。在一些实施例中，可以使用一个已用令牌列表来记录由卖方生成的使用过的令牌，并且可以使用不同的已用令牌列表来记录由权威生成的使用过的令牌。应当理解，也可以使用其他类型的数据结构来记录使用过的令牌。此外，应理解，上述函数、变量和交易的声明仅作为示例呈现，并不意味着限制。
64.值得注意的是，通过要求用户确认票据的有效性，方法300可以避免对无效票据进行双重融资。方法300还可以减轻卖方可能制造假票据并试图使用这种票据借钱的欺诈活动。方法300可以通过使用承诺值隐藏用户身份、应付金额、支付条款和其他与票据相关的
信息来进一步保护隐私。方法300还可以确保记录在区块链上的交易不能被无关用户链接，从而防止无关用户知道与这些交易相关的用户。此外，在一些实施例中，如果用户想要进一步隐藏用户提交给区块链的“issue_invoice”交易的编号或“issue_financing”交易的编号，用户可以选择使用一次性匿名区块链身份来提交此类交易。
65.还应注意，方法300可以扩展为允许买方确认卖方生成的数字票据的有效性。例如，如果卖方错报未结金额或伪造票据，买方可以检查数字票据并使数字票据无效。
66.图4图示了根据实施例的用于减轻票据融资欺诈的方法400的流程图。以说明为目的，图4中描绘了4个用户，包括卖方、买方、银行和被称作权威的受信任用户。假设卖方有兴趣从银行获取票据融资，在银行同意向卖方提供票据融资之前，银行可以要求卖方证明票据的有效性。在一些实施例中，如果卖方能够请求买方和权威基于下面详细描述的方法400确认票据的有效性，银行可能愿意接受票据的有效性。
67.在步骤402，卖方可以生成如上述的数字票据、承诺值cm_invoice和零知识证明seller’s_proof。cm_invoice可以计算为(pk_seller，pk_buyer，invoice_digest，tn，r)的哈希值，其中pk_seller和pk_buyer分别代表卖方和买方的公钥，invoice_digest代表数字票据的哈希值，或数字票据的一个或多个部分的哈希值。tn可以表示卖方生成的令牌，可用于防止卖方使用数字票据多次获得融资(即防止双重融资)。r可以表示卖方生成的随机因素，以进一步保护pk_seller、pk_buyer和invoice_digest中包含的信息。
68.在步骤404，卖方可以向区块链提交“issue_invoice”交易，交易的负载包含{cm_invoice，seller’s_proof}。在步骤406，区块链可以验证seller’s_proof以确定seller’s_proof是否可接受。在一些实施例中，如上所述，区块链可以使用智能合约通过使用公共输入和验证密钥来验证seller’s_proof。如果seller’s_proof无法通过验证，智能合约可能会拒绝让卖方继续进行。另一方面，如果seller’s_proof可以通过验证，那么智能合约可以确定seller’s_proof是可接受的并继续在卖方提交的票据池中记录cm_invoice。在一些实施例中，卖方提交的票据池可以被构造为默克尔树t_invoice，并且cm_invoice可以记录在默克尔树t_invoice的叶节点上。
69.在步骤408，卖方可以继续要求买方验证卖方生成的数字票据。在一些实施例中，卖方可以通过链下通信渠道将数字票据以及tn的值和r的值私下发送给买方。卖方也可以向买方发送cm_invoice。替代地或附加地，买方可以根据数字票据和从卖方收到的tn的值和r的值重建cm_invoice。
70.在步骤410，买方可以检查数字票据以确定数字票据是否有效。如果，例如卖方错报了未结金额或伪造票据，买方可以使数字票据无效。如果买方确定cm_invoice没有记录在卖方提交的票据池中，或者记录的cm_invoice与(pk_seller，pk_buyer，invoice_digest，tn，r)的承诺值不匹配，买方也可以使数字票据无效。以这种方式，如果卖方试图绕过步骤404-406，或试图更改数字票据或更改tn的值或r的值，则此类尝试可以被买方检测到，然后买方可以使数字票据无效并防止欺诈。
71.如果买方确定数字票据有效，则买方可以继续生成经买方验证的承诺值，以记录在区块链上。在一些实施例中，买方可以将经买方证实的承诺值cm_bv_invoice计算为：
72.commitment(pk_seller，pk_buyer，invoice_digest，tn’，r’)。
73.在一些实施例中，cm_bv_invoice可以基于与卖方用来计算cm_invoice相同的函
数来计算。值得注意的是，虽然pk_seller、pk_buyer和invoice_digest的值可能相同，但买方可能需要生成新的tn’和新的r’。以此方式，买方可以计算出与卖方计算出的承诺值不同的承诺值，有效防止无关用户将两个承诺值连接在一起，进而防止无关用户将卖方和买方连接在一起。
74.在步骤410，买方还可以生成零知识证明，记为buyer’s_proof。买方可以生成buyer’s_proof向区块链证明买方是票据的真正接收方。买方可以尝试证明此情况通过指出：(1)cm_invoice格式正确，(2)cm_invoice记录在卖方提交的票据池中，(3)cm_bv_invoice格式正确，(4)买方确实是买方本身。
75.在实施例中，为了证明cm_invoice格式正确，买方可以向区块链证明买方知道pk_seller、pk_buyer、invoice_digest、tn和r的值以及证明(pk_seller，pk_buyer，invoice_digest，tn，r)的承诺值是cm_invoice。在实施例中，为了证明cm_invoice记录在卖方提交的票据池中，买方可以向区块链证明cm_invoice是默克尔树t_invoice中的有效叶节点。在实施例中，为了证明cm_bv_invoice格式正确，买方可以向区块链证明(pk_seller，pk_buyer，invoice_digest，tn’，r’)的承诺值是cm_bv_invoice。在实施例中，为了证明买方确实是买方本身，买方可以向区块链证明买方拥有买方的私钥，或者证明pk_buyer＝h(sk_buyer)，其中sk_buyer表示私钥，该私钥只有买方知道。
76.在一些实施例中，买方和区块链可以同意实施上述零知识证明技术。例如，买方可以向区块链证明买方知道私密输入w，使得对于公共输入x，x和w之间的特定关系成立。在一些实施例中，该关系可以被定义为算术电路，算术电路可以基于多项式方程来定义，可以基于x和w评估该多项式方程。在一些实施例中，基于算术电路和为零知识证明建立的一个或多个安全参数，可以在设置阶段生成证明密钥和验证密钥。在一些实施例中，买方可以设置x为包含tn和cm_cert_invoice的值，并设置w为基于pk_seller、pk_buyer、invoice_digest、r、tn’、r’和sk_seller生成的值。以这种方式，买方可以生成buyer’s_proof以向区块链证明该买方拥有私密输入w。在一些实施例中，如果区块链接受买方关于买方拥有私密输入w的证明，区块链可以接受买方的声明为真。
77.在步骤412，买方可以将tn’的值和r’的值发送给卖方，以便卖方之后可以使用这些值向权威请求认证。在步骤414，买方可以向区块链提交交易，交易的负载包含{tn，cm_bv_invoice，buyer’s_proof}。出于说明目的，此交易可称为“buyer_validated_invoice”交易。
78.在步骤416，区块链可以使用智能合约来检查包含在负载内的tn是否已经被使用或被消耗。在一些实施例中，智能合约可以在区块链上维护使用的令牌列表以记录使用的令牌。如果负载中包含的tn列在已用令牌列表中，则智能合约可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。另一方面，如果负载中包含的tn未被列在已用令牌列表中，则智能合约可以继续验证buyer’s_proof是否可接受。智能合约可以使用公共输入和验证密钥来验证buyer’s_proof。如果buyer’s_proof可以通过验证，那么智能合约可以确定buyer’s_proof是可接受的并且继续在权威认证的票据池中记录cm_bv_invoice。在一些实施例中，经买方证实的票据池可以被构造为默克尔树t_bv_invoice并且cm_bv_invoice可以记录在默克尔树t_bv_invoice的叶节点上。智能合约还可以添加tn到已用令牌列表以指示该tn已经被使用，因此，使该tn在未来的使用中无效。
79.在步骤418，卖方可以继续要求权威验证卖方生成的数字票据。在一些实施例中，卖方可以通过链下通信渠道将数字票据以及tn’的值和r’的值私下发送给权威。卖方也可以向权威发送cm_bv_invoice。替代地或附加地，权威可以根据数字票据和从卖方收到的tn’的值和r’的值重建cm_bv_invoice。
80.在步骤420，权威可以检查数字票据以确定数字票据是否有效。在一些实施例中，权威可以使数字票据无效，如果权威确定cm_bv_invoice没有记录在经买方证实的票据池中，或者记录的cm_bv_invoice与(pk_seller，pk_buyer，invoice_digest，tn’，r’)的承诺值不匹配。以这种方式，如果卖方试图绕过任何先前的步骤，或试图更改数字票据或更改tn’的值或r’的值，则此类尝试可以被权威检测到，然后权威可以使数字票据无效并防止欺诈。另一方面，如果权威确定数字票据是有效的，则权威可以继续生成经认证的承诺值，以记录在区块链上。在一些实施例中，权威可以将经认证的承诺值cm_cert_invoice计算为：
81.commitment(pk_seller，pk_buyer，invoice_digest，cert_digest，tn”，r”)。
82.在一些实施例中，cm_cert_invoice可以基于与卖方用来计算cm_invoice相同的函数来计算，其中pk_seller、pk_buyer和invoice_digest的值相同。cert_digest可以表示由权威生成的一份或多份认证文件的哈希值。认证文件可以采用多种格式，包括例如由政府机构或海关官员为提供认证而制定的标准化格式。权威也可以生成一个新的tn”和一个新的r”。以此方式，权威可以计算出与卖方和买方计算出的承诺值不同的承诺值，有效防止无关用户将三个承诺值连接在一起，进而防止无关用户将卖方、买方和权威连接在一起。
83.在步骤420，权威还可以生成零知识证明，记为authority’s_proof。权威可以生成authority’s_proof以向区块链证明权威已经审核并认证了卖方提供的票据。权威可以尝试证明此情况通过指出：(1)cm_bv_invoice格式正确，(2)cm_bv_invoice记录在买方提交的票据池中，(3)cm_cert_invoice格式正确。
84.在实施例中，为了证明cm_bv_invoice格式正确，权威可以向区块链证明权威知道pk_seller、pk_buyer、invoice_digest、tn’和r’的值以及证明(pk_seller，pk_buyer，invoice_digest，tn’，r’)的承诺值是cm_bv_invoice。在实施例中，为了证明cm_bv_invoice记录在买方提交的票据池中，权威可以向区块链证明cm_bv_invoice是默克尔树t_bv_invoice中的有效叶节点。在实施例中，为了证明cm_cert_invoice格式正确，权威可以向区块链证明(pk_seller，pk_buyer，invoice_digest，cert_digest，tn”，r”)的承诺值是cm_cert_invoice。
85.在一些实施例中，权威和区块链可以同意实施上述零知识证明技术。例如，权威可以向区块链证明权威知道私密输入w，使得对于公共输入x，x和w之间的特定关系成立。在一些实施例中，该关系可以被定义为算术电路，算术电路可以基于多项式方程来定义，可以基于x和w评估该多项式方程。在一些实施例中，基于算术电路和为零知识证明建立的一个或多个安全参数，可以在设置阶段生成证明密钥和验证密钥。在一些实施例中，权威可以设置x为包含tn和cm_cert_invoice的值，并设置w为基于pk_seller、pk_buyer、invoice_digest、cert_digest、r’、tn”、r”和cm_bv_invoice生成的值。以这种方式，权威可以生成authority’s_proof以向区块链证明该权威拥有私密输入w。在一些实施例中，如果区块链接受权威关于权威拥有私密输入w的证明，区块链可以接受权威的声明为真。
86.在步骤422，权威可以将认证文件和tn”和r”的值发送给卖方，以便卖方之后可以
使用认证文件从银行获得融资。在步骤424，权威可以向区块链提交“authority_certified_invoice”交易，交易的负载包含{tn’，cm_cert_invoice，authority’s_proof}。
87.在步骤426，区块链可以利用智能合约来验证权威的身份(例如，基于权威提供的签名)并检查包含在负载中的tn’是否已经被使用或被消耗。在一些实施例中，智能合约可以在区块链上维护使用的令牌列表以记录使用的令牌。如果负载中包含的tn’被列在已用令牌列表中，则智能合约可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。另一方面，如果负载中包含的tn’未被列在已用令牌列表中，则智能合约可以继续验证authority’s_proof是否可接受。智能合约可以使用公共输入和验证密钥来验证authority’s_proof。如果authority’s_proof可以通过验证，那么智能合约可以确定authority’s_proof是可接受的并且继续在权威认证的票据池中记录cm_cert_invoice。在一些实施例中，权威认证的票据池可以被构造为默克尔树t_cert_invoice并且cm_cert_invoice可以记录在默克尔树t_cert_invoice的叶节点上。智能合约还可以添加tn’到已用令牌列表以指示该tn’已经被使用，以使该tn’在未来的使用中无效。
88.在步骤428，卖方可以继续请求来自银行的票据融资。在一些实施例中，卖方可以通过链下通信渠道将数字票据、认证文件以及tn”和r”的值私下发送给银行。卖方也可以计算cm_cert_invoice的值并将cm_cert_invoice的值发送给银行。替代地或附加地，银行可以根据数字票据、认证文件和从卖方收到的tn”的值和r”的值重建cm_cert_invoice。
89.在步骤430，银行可以确定数字票据和认证文件是否有效。例如，如果数字票据未经权威认证，银行可以使数字票据无效。银行可以通过确定cm_cert_invoice是否记录在权威认证的票据池中(例如，在默克尔树t_cert_invoice中)来做出此确定。如果cm_cert_invoice未记录在经权威认证的票据池中，银行可以确认数字票据无效，并拒绝卖方继续进行。另一方面，如果cm_cert_invoice记录在经权威认证的票据池中，则银行可以确定数字票据是有效的。然后，银行可以继续决定是否向卖方提供票据融资。
90.在一些实施例中，银行还可以确定卖方提供的tn”是否已经被使用。在一些实施例中，银行可以调用在区块链上执行的智能合约以确认tn”是否被列在已用令牌列表中。如果tn”被列在已用令牌列表中，则银行可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。如果tn”未被列在已用令牌列表中，银行可继续决定是否向卖方提供票据融资。
91.如果银行决定拒绝卖方的票据融资请求，银行可以通过链下通信渠道私下将该决定传达给卖方，在这种情况下，卖方可以选择重复步骤428并向不同的资金提供方请求票据融资。另一方面，如果银行决定向卖方提供票据融资，银行可以在步骤430继续生成零知识证明，记为bank’s_proof，以向区块链证明银行已验证卖方要求提供票据融资的有效性。银行可以尝试证明此情况通过指出：(1)cm_cert_invoice格式正确，(2)cm_cert_invoice记录在权威认证的票据池中。
92.在实施例中，为了证明cm_cert_invoice格式正确，银行可以向区块链证明银行知道pk_seller、pk_buyer、invoice_digest、cert_digest、tn”和r”的值以及证明(pk_seller，pk_buyer，invoice_digest，cert_digest，tn”，r”)的承诺值是cm_cert_invoice。在实施例中，为了证明cm_cert_invoice记录在权威认证的票据池中，银行可以向区块链证明cm_cert_invoice是默克尔树t_cert_invoice中的有效叶节点。
93.在一些实施例中，银行和区块链可以同意实施上述零知识证明技术。例如，银行可以向区块链证明银行知道私密输入w，使得对于公共输入x，x和w之间的特定关系成立。在一些实施例中，该关系可以被定义为算术电路，算术电路可以基于多项式方程来定义，可以基于x和w评估该多项式方程。在一些实施例中，基于算术电路和为零知识证明建立的一个或多个安全参数，可以在设置阶段生成证明密钥和验证密钥。在一些实施例中，银行可以将x为tn”并将w设置为基于pk_seller、pk_buyer、invoice_digest、cert_digest、r”和cm_cert_invoice生成的值。以这种方式，银行可以生成bank’s_proof以向区块链证明该银行拥有私密输入w。
94.在步骤432，银行可以向区块链提交“issue_financing”交易，交易的负载包含{tn’，bank’s_proof}。在步骤434，区块链可以使用智能合约来检查包含在负载内的tn”是否已经使用。在一些实施例中，智能合约可以检查tn”是否被列在已用令牌列表中。如果tn”被列在已用令牌列表中，则智能合约可以拒绝继续进行，因为卖方正试图使用相同数字票据多次获得融资。如果tn”未被列在已用令牌列表中，智能合约可以继续验证bank’s_proof是否可接受。智能合约可以使用公共输入和验证密钥来验证bank’s_proof。如果可以验证bank’s_proof，则智能合约可以确定bank’s_proof是可接受的并使tn”无效(例如，通过将tn”添加到已用令牌列表)，并在步骤436向银行报告根据收到的交易没有检测到欺诈，以便银行可以继续向卖方发放票据融资。
95.图5图示了根据实施例的用于减轻票据融资欺诈的方法500的流程图。方法500可以由区块链系统中的一个或多个节点执行，例如，区块链系统100(图1)中的节点102-110。区块链系统100中的节点102-110可以在区块链上执行操作，例如区块链120(图1)。区块链120可以实现为上述示例中的区块链。
96.在步骤502，节点，例如节点102，可以接收由第一用户提交的第一交易。第一用户可以是例如卖方(图3)，卖方是票据的开具方并且正试图使用该票据获得融资。第一交易可以包括上述“issue_invoice”交易(图3)，其可以包括票据的第一承诺值，例如cm_invoice，和第一证明，例如seller’s_proof。
97.在步骤504，节点102可以确定第一证明是否可接受，并且响应于确定第一证明是不可接受的，报告检测到欺诈。在一些实施例中，第一证明可以是由第一用户生成的零知识证明，以证明第一用户是票据的真实开具方。在一些实施例中，第一用户可以尝试向节点102证明票据的第一承诺值格式正确并且第一用户确实是第一用户本身。在一些实施例中，如果节点102确定第一证明是不可接受的，则节点102可以报告检测到可疑欺诈。另一方面，如果节点102确定第一证明是可接受的，则节点102可以将第一承诺值记录在第一票据池中，该第一票据池在图3中被称为卖方提交的票据池。
98.在步骤506，节点102可以接收由第二用户提交的第二交易。第二用户可以是，例如，权威(图3)，权威是受区块链系统100信任以认证由第一用户开具的票据。第二交易可以包括上述“authority_certified_invoice”交易(图3)，其可以包括由第一用户生成的第一令牌，例如tn，票据的第二承诺值，例如cm_cert_invoice，以及第二证明，例如，authority’s_proof。
99.在步骤508，节点102可以确定第一令牌是否有效，以及第二证明是否可接受。响应于确定第一令牌无效或第二证明是不可接受的，节点102可以报告检测到欺诈。在一些实施
例中，节点102可以通过确定第一令牌是否被列在已用令牌列表中来确定第一令牌是否有效。在一些实施例中，第二证明可以是由第二用户生成的用于证明第二用户是票据的接收方的零知识证明。在一些实施例中，如果节点102确定第一令牌无效或第二证明是不可接受的，则节点102可以报告检测到可疑欺诈。另一方面，如果节点102确定第一令牌有效并且第二证明是可接受的，则节点102可以将第二承诺值记录在第二票据池中，该第二票据池在图3中被称为权威认证的票据池。节点102也可以使第一令牌无效。在一些实施例中，节点102可以通过将第一令牌添加到已用令牌列表来使第一令牌无效。
100.在步骤510，节点102可以接收由第三用户提交的第三交易。第三用户可以是例如银行(图3)，其是已收到向第一用户提供票据融资的请求的资金提供方。第三交易可以包括上述“issue_financing”交易(图3)，其可以包括由第二用户生成的第二令牌，例如tn’，以及由第三用户生成的第三证明，例如bank’s_proof。
101.在步骤512，节点102可以确定第二令牌是否有效以及第三证明是否可接受。响应于确定第二令牌无效或第三证明是不可接受的，节点102可以报告检测到欺诈。在一些实施例中，节点102可以通过确定第二令牌是否被列在已用令牌列表中来确定第二令牌是否有效。在一些实施例中，第三证明可以是由第三用户生成的零知识证明，以证明第三用户已经验证了向第一用户提供票据融资的请求的有效性。在一些实施例中，如果节点102确定第二令牌无效或第三证明是不可接受的，则节点102可以报告检测到可疑欺诈。另一方面，如果节点102确定第二令牌有效并且第三证明是可接受的，则节点102可以使第二令牌无效并向第三用户报告基于接收到的交易没有检测到欺诈。在一些实施例中，节点102可以通过将第二令牌添加到已用令牌列表来使第二令牌无效。第三用户可以继续向第一用户发放票据融资。
102.图6示出了根据实施例的用于减轻票据融资欺诈的方法600的流程图。方法600可以由区块链系统中的一个或多个节点执行，例如，区块链系统100(图1)中的节点102-110。区块链系统100中的节点102-110可以在区块链上执行操作，例如区块链120(图1)。区块链120可以实现为上述示例中的区块链。
103.在步骤602，节点，例如节点102，可以接收由第一用户提交的第一交易。第一用户可以是例如卖方(图4)，卖方是票据的开具方并且正试图使用该票据获得融资。第一交易可以包括上述“issue_invoice”交易(图4)，其可以包括票据的第一承诺值，例如cm_invoice，和第一证明，例如seller’s_proof。
104.在步骤604，节点102可以确定第一证明是否可接受，并且响应于第一证明是不可接受的，报告检测到欺诈。另一方面，如果节点102确定第一证明是可接受的，则节点102可以将第一承诺值记录在第一票据池中，该第一票据池在图4中被称为卖方提交的票据池。
105.在步骤606，节点102可以接收由第二用户提交的第二交易。第二用户可以是，例如买方(图4)，买方是票据的接收方。第二交易可以包括上述“buyer_validated_invoice”交易(图4)，其可以包括由第一用户生成的第一令牌，例如tn，票据的第二承诺值，例如cm_bv_invoice，以及第二证明，例如，buyer’s_proof。
106.在步骤608，节点102可以确定第一令牌是否有效，以及第二证明是否可接受。响应于确定第一令牌无效或第二证明是不可接受的，节点102可以报告检测到欺诈。另一方面，如果节点102确定第一令牌有效并且第二证明是可接受的，则节点102可以将第二承诺值记
录在第二票据池中，该第二票据池在图4中被称为经买方证实的票据池。节点102也可以使第一令牌无效。在一些实施例中，节点102可以通过将第一令牌添加到已用令牌列表来使第一令牌无效。
107.在步骤610，节点102可以接收由第三用户提交的第三交易。第三用户可以是例如权威(图4)，权威受区块链系统100信任以认证由第一用户发出的票据。第三交易可以包括上述“authority_certified_invoice”交易(图4)，其可以包括由第二用户生成的第二令牌，例如tn’，票据的第三承诺值，例如cm_cert_invoice，以及第三证明，例如authority’s_proof。
108.在步骤612，节点102可以确定第二令牌是否有效以及第三证明是否可接受。响应于确定第二令牌无效或第三证明是不可接受的，节点102可以报告检测到欺诈。另一方面，如果节点102确定第二令牌有效并且第三证明是可接受的，则节点102可以将第三承诺值记录在第三票据池中，该第三票据池在图4中被称为权威认证的票据池。节点102还可以使第二令牌无效。在一些实施例中，节点102可以通过将第二令牌添加到已用令牌列表来使第二令牌无效。
109.在步骤614，节点102可以接收由第四用户提交的第四交易。第四用户可以是例如银行(图4)，其是已收到向第一用户提供票据融资的请求的资金提供方。第四交易可以包括上述“issue_financing”交易(图4)，其可以包括由第三用户生成的第三令牌，例如tn”，以及由第四用户生成的第四证明，例如bank’s_proof。
110.在步骤616，节点102可以确定第三令牌是否有效以及第四证明是否可接受。响应于确定第三令牌无效或第四证明是不可接受的，节点102可以报告检测到欺诈。另一方面，如果节点102确定第三令牌有效并且第四证明是可接受的，则节点102可以使第三令牌无效并向第四用户报告基于接收到的交易没有检测到欺诈。在一些实施例中，节点102可以通过将第三令牌添加到已用令牌列表来使第三令牌无效。第四用户可以继续向第一用户发放票据融资。
111.图7是根据实施例的票据融资欺诈减轻装置700的框图。装置700可以由软件过程实现，并且可以对应于方法500(图5)和方法600(图6)。参考图7，装置700可以包括接收模块702、确定模块704、记录模块706和报告模块708。
112.接收模块702可以接收用户提交的交易。交易可以包括上述“issue_invoice”交易、“authority_certified_invoice”交易、“buyer_validated_invoice”交易和“issue_financing”交易。接收模块702可以将接收到的交易提供给确定模块704。
113.确定模块704可以处理如上所述接收到的交易。如果检测到可疑欺诈，则确定模块704可以请求报告模块708报告检测到欺诈。否则，确定模块704可以将包含在接收到的交易中的承诺值提供给记录模块706，记录模块706可以将承诺值记录在如上所述对应的票据池中。在一些实施例中，如果接收到的交易是“issue_financing”交易并且确定模块704没有检测到欺诈，则确定模块704可以请求报告模块708报告没有检测到欺诈，以便可以处理由第一用户提交的票据融资请求。
114.上述模块中的每一个都可以实现为软件、或硬件、或软件和硬件的组合。例如，上述模块中的每一个模块可以使用处理器来实现，储存器执行存储在存储器中的指令。而且，例如，每个上述模块可以使用一个或多个专用集成电路(asic)、数字信号处理器(dsp)、数
字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子组件来实施以执行所描述的方法。进一步地，例如，上述模块中的每一个可以通过使用计算机芯片或实体来实施，或者通过使用具有特定功能的产品来实施。在实施例中，装置700可以是计算机，并且计算机可以是个人计算机、膝上型计算机、蜂窝电话、照相手机、智能手机、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板电脑、可穿戴设备或这些设备的任何组合。
115.对于装置700中每个模块的功能和角色的实施过程，可以参考上述方法中的相应步骤。为了简明，这里省略了细节。
116.在一些实施例中，计算机程序产品可以包括非暂态计算机可读存储介质，其上存储有计算机可读程序指令，用于使处理器执行上述方法。
117.计算机可读存储介质可以是有形设备，其可以存储供指令执行设备使用的指令。所述计算机可读存储介质可以是，例如，但不限于电子存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或前述的任何合适组合。计算机可读存储介质的更具体示例的非详尽列表包括以下内容：便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom)、静态随机存取存储器(sram)、便携式光盘只读存储器(cd-rom)、数字通用光盘(dvd)、记忆棒、软盘、机械编码设备(例如，凹槽中的穿孔卡或凸起结构，其上记录有指令)，以及前述的任何合适的组合。
118.用于执行上述方法的计算机可读程序指令可以是汇编指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据或者以一种或多种编程语言的任意组合编写的源代码或目标代码，该编程语言包括面向对象的编程语言和传统的过程编程语言。计算机可读程序指令可以完全在计算设备上作为独立软件包执行，或者部分在第一计算设备上执行、部分在远离第一计算设备的第二计算设备上执行。在后一种情况下，第二远程计算设备可以通过包括局域网(lan)或广域网(wan)的任何类型的网络连接到第一计算设备。
119.计算机可读程序指令可以被提供给通用或专用计算机的处理器或其他可编程数据处理装置以产生机器，使得指令经由计算机的处理器或其他可编程数据处理装置执行，创建用于实施上述方法的机构。
120.附图中的流程图和框图示出了根据本文的各种实施例的设备、方法和计算机程序产品的可能实现的架构、功能和操作。在这方面，流程图或框图中的框可以表示软件程序、代码的段或部分，其包括用于实现特定功能的一个或多个可执行指令。还应注意，在一些可选实施例中，框中提到的功能可以不按图中所示的顺序发生。例如，连续示出的两个框实际上可以基本上同时执行，或者这些框有时可以以相反的顺序执行，这取决于所涉及的功能。还应注意，图和/或流程图的每个框以及图和流程图中的框的组合，可以由执行指定功能或动作的专用目的的基于硬件的系统来实施，或由专用目的的硬件和计算机指令的组合来实施。
121.应当理解，为了清楚起见，在不同实施例的上下文中描述的本公开的某些特征也可以在单个实施例中组合提供。相反，为了简洁起见，在单个实施例的上下文中描述的本公开的各种特征也可以单独提供或者以任何合适的子组合提供，或者在本公开的任何其他描述的实施例中合适地提供。除非另有说明，否则在各种实施例的上下文中描述的某些特征
不是那些实施例的必要特征。
122.尽管已经结合具体实施例描述了本公开，但是许多替换、修改和变体对于本领域技术人员而言将是显而易见的。因此，以下权利要求包含落入权利要求的范围内的所有这些替代、修改和变体。