CN109670955A - 基于区块链通证实现银行承兑票据的方法与装置 - Google Patents

Abstract

本发明公开了基于区块链通证实现银行承兑票据的方法与装置。该方法包括：基于针对通证的业务请求，确定通证是否处于与业务请求相对应的第一状态，其中，通证与票据相关联；当通证处于第一状态时，基于业务请求来调用银行承兑通证协议中相应的智能合约接口来确定与业务请求相对应的业务计算结果；以及当业务计算结果在区块链中共识成功时，将通证的持有方地址修改为业务请求的被请求方的地址。

Description

基于区块链通证实现银行承兑票据的方法与装置

技术领域

本发明属于区块链领域，尤其涉及通过区块链来实现的银行承兑通证化的方法与系统。

背景技术

区块链是利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全，生成不可篡改和不可伪造的分布式账本，建立互相信任的数据网络。

银行承兑票据是商业票据的一种，表示由付款人委托银行开具的一种延期支付票据，票据到期银行具有见票即付的义务，是常见的融资手段之一，并具有流通价值。总体来讲，银行承兑票据具有信用好，承兑性强，灵活性高的特点，有效节约了资金成本。在我国，银行承兑票据的形式包括纸质票据和电子票据两种，纸质票据有效期不超过六个月，电子票据不超过一年。其中，纸质票据即将停用，目前主要集中在百万一下的金额，而电子票据则通过人行电子商业票据系统以中心化方式交易。

目前的银行承兑票据在流通中有诸多信任问题，可以通过区块链技术进行显著的优化，业界也提出了很多基于区块链的票据解决方案。但是，现有方案更多的是将原有系统的运行方式套用到区块链中，以区块链智能合约实现原有电子票据系统的代码。这样的方式会带来的问题是，不同的基于区块链的票据系统之间仍旧是割裂的，不具备统一的接口标准和数据标准，同时跨区块链网络下的信任成本无法解决。其次，无论在同一个区块链网络还是和外部系统交互的过程上，在流通中传递的仍旧是分散的、结构化的数据，没有一个具体的票据实体或者对象，对票据本身的证明和背书、贴现行为仍需要线下的合同补充证明。

发明内容

针对上述问题，本发明提出了一种通过将票据通证化来在区块链中实现对票据进行处理的方法。

本发明一方面提出了在区块链节点设备处执行的票据处理方法，包括：基于针对通证的业务请求，确定所述通证是否处于与所述业务请求相对应的第一状态，其中，所述通证与所述票据相关联；当所述通证处于第一状态时，基于所述业务请求来调用银行承兑通证协议中相应的智能合约接口来确定与所述业务请求相对应的业务计算结果；以及当所述业务计算结果在区块链中共识成功时，将所述通证的持有方地址修改为所述业务请求的被请求方的地址。

本发明还提出了一种信息处理装置，包括：处理器；以及存储器，其用于存储指令，当所述指令在执行时使得所述处理器执行前述的方法。

通过本发明的技术方案，可以实现将票据通证化，基于通证的特点来管理票据，进而实现票据可以跨银行地进行快速流通。

附图说明

参考附图示出并阐明实施例。这些附图用于阐明基本原理，从而仅仅示出了对于理解基本原理必要的方面。这些附图不是按比例的。在附图中，相同的附图标记表示相似的特征。

图1为依据本发明实施例的通证业务处理流程图；

图2为依据本发明实施例的贴现方法的流程图；

图3为依据本发明实施例的背书方法的流程图；

图4为依据本发明实施例的信息处理装置的示意图。

具体实施方式

在以下优选的实施例的具体描述中，将参考构成本发明一部分的所附的附图。所附的附图通过示例的方式示出了能够实现本发明的特定的实施例。示例的实施例并不旨在穷尽根据本发明的所有实施例。可以理解，在不偏离本发明的范围的前提下，可以利用其他实施例，也可以进行结构性或者逻辑性的修改。因此，以下的具体描述并非限制性的，且本发明的范围由所附的权利要求所限定。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

在本发明中，通过统一的通证协议，将银行承兑票据转化为区块链上的票据资产通证，通过实现通证的流通，实现银行承兑票据的资产价值与数据的流通。

首先，需要定义业务的具体参与方和包含的功能，包括：

(1)企业方：企业方可以对票据进行签发、持有、背书、贴现；

(2)商业银行方：商业银行方可以承兑、付款、接收贴现、转贴现、接收转贴现、再贴现；

(3)央行方：央行方通过再贴现方式收取商业银行方持有的票据；

(4)监管方：对所有业务进行监管。

其次，需要定义标准的银行承兑通证协议(BATP，Bank Acceptance TokenProtocol)，协议包括了多个智能合约接口，通过接口的形式来定义银行承兑票据的相关功能，包括：

(1)签发接口-SignAndIssue()：表示由出票人提交出票申请，包含交易合同、收款人信息等，交由银行进行承兑；

(2)承兑接口-Accept()：商业银行方通过出票申请，对票据承兑；

(3)背书接口-Endorsement()：收款人/持票人在票据到期前将票据转让给第三方企业，获取资金通融；

(4)贴现接口-Discount()：持票人在票据到期前将票据转让给银行，获取资金通融；

(5)转贴现接口-TransferDiscount()：商业银行方将通过贴现获得的未到期票据转让给其他商业银行，获取资金通融；

(6)再贴现接口-Rediscount()：商业银行方将为到期票据转让给央行方，获取资金通融；

(7)付款接口-Pay()：由付款方(譬如，商业银行方)根据票据票据金额进行付款；

(8)前手列表-Prioriparties()：查询通证当前持有人的所有“前手”。

基于上述接口，每项针对通证的业务请求，均可以由相应的接口来实现相应的业务。譬如，出票人经由签发接口-SignAndIssue()提交出票申请，然后银行方通过承兑接口-Accept()对该通证进行承兑。同样，通证持有人可以使用背书接口-Endorsement()将该通证转让给其它方。类似的，通过转贴现接口-TransferDiscount()、再贴现接口-Rediscount()、支付接口-Pay()均可以实现执行相应的业务。通过前手接口-Prioriparties()可以实现对通证当前持有人的所有“前手”的查询。

通过银行承兑通证协议，可以实现调用具体的银行承兑通证合约，即通过区块链智能合约进行通证的定义和实现上述接口对应的函数，用以对通证在生命周期中的信息管理。

通过一个结构体实现对银行承兑通证的定义，可以包括如下属性：通证ID、签发人区块链账户地址、签发日期、承兑银行、票面金额、票据到期时间、当前持有人、通证状态、背书记录列表(可以包括背书人、被背书人、背书时间、转让金额)、贴现记录列表(可以包括贴现人、被贴现人、贴现时间、转让金额、贴现类型(贴现类型分为贴现、转贴现、被贴现))。可以理解的，上述属性可以根据具体的应用来进行调整，而并非限制为上述内容。

通证可以通过企业方提交签发申请信息来创建，譬如，通过提交交易合同、对应承兑银行地址、收款人等必要信息来实现通证。此时创建通证，但状态为“签发”，不可进行流通。商业银行方通过审核申请信息、保证金并且授信后确认对该通证予以承兑。当商业银行承兑后，通证状态变更为“已承兑”，可以进行流通。通证的支付是指通证到达指定的付款日期时，由承兑银行向持票人进行支付，由承兑银行调用支付接口触发。支付成功后，通证状态改为“已支付”，通证不再具有资产价值。前手表示通证在当前持有人之前的持有人、承兑银行、签发企业。在区块链系统中，可以通过有元组组成的列表来表示前手信息，其中，有元组包括前手地址、时间。

图1为依据本发明实施例的通证业务处理流程图。

步骤S101：接收针对通证的业务请求

在该步骤中，节点设备可以接收来自客户端的对通证的业务请求，譬如，贴现、转贴现、再贴现、背书等业务请求。

步骤S102：根据通证的状态确定业务执行结果。

在该步骤中，节点设备根据通证的状态，来确定该业务计算结果。具体地，当接收到贴现的业务请求时，将判断该通证是否已经承兑。若已经承兑，则基于贴现率来确定该通证对应的余额。

步骤S103：共识成功后，修改通证持有方地址。

在该步骤中，将基于区块链对业务计算结果的共识结果来进行相应的操作。当共识成功后，节点设备将修改通证持有方的地址；当共识未成功，节点将不对通证持有方的地址进行操作。

下面分别以贴现业务、背书业务为例，来阐述本发明的构思。

图2为依据本发明实施例的贴现方法的流程图。

贴现指通证持有方将通证转让给商业银行方，由商业银行方根据当前贴现率进行计算。在本实施例中，通证持有方对应于客户端设备，商业银行方对应于节点端设备。

步骤S201：客户端设备向节点端设备发送贴现请求。

在该步骤中，客户端设备调用Discount接口，以向节点端设备发送贴现请求，该贴现请求可以包括通证的标识信息、贴现时间信息。可以理解的，根据应用场景的变化，贴现请求还可以包括其它所需的信息，譬如，票面金额信息、查询承兑状态信息等等。

步骤S202：基于贴现请求，判断该通证是否已经处于承兑状态。

在该步骤中，节点端设备从贴现请求中获取通证的标识信息，进而可以从数据库中查询该通证是否已经处于承兑状态。

若通证已经处于承兑状态，则向外部查询设备发送贴现率查询请求(步骤S203a)，进而从外部查询设备获取贴现率查询结果(步骤S204)；否则，向客户端设备发送拒绝贴现请求(步骤S203b)，以告知客户端设备贴现请求失败。

步骤S205：节点端设备确定贴现后余额

在该步骤中，节点端设备基于指定的公式来确定贴现后的余额，譬如，贴现后余额＝票面金额－(票面金额×贴现率×剩余时间/360)－相关服务费，其中，剩余时间为当前时间到该通证到期日期的天数。

当节点端设备计算好余额后，将该余额计算结果发送到区块链中，以参与区块链对该余额计算结果的共识。当共识成功时，基于计算后的余额，节点端设备可以发起支付操作，以将该余额所对应的资产信息传送给客户端设备，而与客户端设备相对应的资产总量将包括该余额；当共识失败时，则向客户端设备发送贴现失败的信息。

步骤S206：节点端设备修改通证的持有人信息和状态信息。

在该步骤中，节点端设备在贴现将通证的持有人信息修改为节点端设备的地址(譬如，业务请求的被请求方地址)，并且将通证状态改为“贴现”。通证状态改为“贴现”，状态为贴现后，不可进行背书操作。可以理解的，一个节点端设备可以对应着多个被贴现方，因此，业务请求的被请求方是指被贴现方地址，通证的持有人信息与业务请求的被请求方相关联。

步骤S207：节点端设备在贴现记录列表中添加本次贴现记录。

在该步骤中，节点端在贴现成功后，将在贴现记录列表中添加本次贴现记录信息，譬如，添加表示原通证持有人区块链地址的贴现方信息、表示节点端设备(譬如，贴现请求所对应的商业银行)的区块链地址的被贴现人信息、当前时间戳、贴现后余额、贴现类型。

本发明还提出了基于区块链来实现的转贴现的方法。转贴现指商业银行间的通证流通，当商业银行通过贴现持有通证后，若通证未到期但需要资金，可通过转贴现转让给其他商业银行。

对于转贴现过程，通证持有方(银行A)通过调用TransferDiscount()接口向节点端设备(对应于其它商业银行)发送转贴现请求。类似地，该转贴现请求可以包括通证的标识信息、贴现时间信息。节点端设备基于转贴现请求，判断该通证是否已经处于贴现状态。若通证已经处于贴现状态，则向外部查询设备发送贴现率查询请求，以获取贴现率查询结果。基于所获得的贴现率，可以确定贴现后余额。当对该余额的共识成功后，节点端设备将通证状态改为“转贴现”，并将该次转贴现记录添加至贴现记录列表。

在本实施例中，转贴现记录可以包括如下信息：贴现方，当前通证持有方(银行A)的区块链地址；被贴现方，表示商业银行区块链地址；贴现时间，当前时间戳；转让金额，贴现后余额；贴现类型，转贴现。

同样，对于再贴现过程，通证持有方可将尚未到期的已贴现通证，再以贴现的方式向央行转让，以获取资金。类似的，通证持有方(商业银行A)通过调用Rediscount接口来向节点端设备(对应于央行)发送再贴现请求。节点端设备基于再贴现请求，判断该通证是否已经处于贴现状态。若通证已经处于贴现状态，则向外部查询设备发送贴现率查询请求，以获取贴现率查询结果。基于所获得的贴现率，可以确定贴现后余额。当对该余额的共识成功后，节点端设备将通证状态改为“再贴现”，并将该次转贴现记录添加至贴现记录列表。

图3为依据本发明实施例的背书方法的流程图。

背书是由通证持有人发起，将当前持有的通证转让给被背书人。背书人和被背书人都是企业用户，转让金额由双方议价确认。因此，对于贴现、转贴现或再贴现的通证，无法进行背书。

步骤S301：客户端设备发送背书请求。

在该步骤中，客户端设备(即，通证持有方)向节点设备发送背书请求，以请求将当前持有的通证转让给被背书人，其中，背书请求可以包括通证标识信息。

步骤S302：节点端设备判断该通证是否已经被贴现。

在该步骤中，节点端设备基背书请求来确定所要背书的通证是否已经被贴现。譬如，通过通证标识信息来获得与所要背书的通证相关联的信息，进而确定该通证的状态。

当该通证被贴现，则节点端设备向客户端设备发送拒绝背书请求(步骤S303a)；当该通证未被贴现，则触发协商操作，即节点端设备与客户端设备基于指定的规则来协商该通证所对应的金额(步骤S303b)。

步骤S304：节点端确定支付金额。

当节点端根据协商的结果确定支付金额后，将该支付金额发送到区块链中，以参与区块链对该支付余额的共识。当共识成功时，基于所确定的支付金额，节点端设备可以发起支付操作，以将该支付金额所对应的资产信息传送给客户端设备，而与客户端设备相对应的资产总量将包括该支付金额；当共识失败时，则向客户端设备发送背书失败的信息。

步骤S305：节点端设备修改通证持有方为被背书方区块链账户地址。

在该步骤中，背书成功后，通证的当前持有方信息改为被背书人区块链账户地址。

步骤S306：添加背书记录。

在该步骤中，节点端设备在背书记录列表中添加背书记录信息。背书记录信息可以包括：背书人，原始持有方账户地址；被背书人，背书后企业账户地址；背书时间，当前时间戳；转让金额，协商所确定的价格。

为了便于查询，可以将贴现记录列表和背书记录列表中的数据根据时间排序(譬如，倒序)，然后形成不包括承兑银行和签发企业的前手列表。可以理解的，还可以将承兑银行、签发机构追加到列表末尾。通过调用Prioriparties()接口，来查询通证当前持有人的所有“前手”。

图4为依据本发明实施例的信息处理装置的示意图。

信息处理装置400包括处理器410以及存储器420，其中，该存储器420用来存储指令。当该指令在执行时，能够使得处理器410执行如前述的方法，譬如，贴现、转贴现、再贴现或查询的方法，在此不再赘述。

上述的部署方法的流程还代表机器可读指令，该机器可读指令包括由处理器执行的程序。该编程指令存储于有形计算机可读介质上，如硬盘、闪存、只读存储器(ROM)、光盘(CD)、数字通用光盘(DVD)、高速缓存器、随机访问存储器(RAM)和/或任何其他存储介质，在该存储介质上信息可以存储任意时间(例如，长时间，永久地，短暂的情况，临时缓冲，和/或信息的缓存)。如在此所用的，该术语有形计算机可读介质被明确定义为包括任意类型的计算机可读存储的信息。附加地或替代地，可利用编码指令(如计算机可读指令)实现图1-3中的示例过程，该编码指令存储于非暂时性计算机可读介质，在该存储介质信息可以存储任意时间。可以理解的，该计算机可读指令还可以存储在网络服务器中、云端平台上，以便于用户使用。

另外，尽管操作以特定顺序被描绘，但这并不应该理解为要求此类操作以示出的特定顺序或以相继顺序完成，或者执行所有图示的操作以获取期望结果。在某些情况下，多任务或并行处理会是有益的。同样地，尽管上述讨论包含了某些特定的实施细节，但这并不应解释为限制任何发明或权利要求的范围，而应解释为对可以针对特定发明的特定实施例的描述。本说明书中在分开的实施例的上下文中描述的某些特征也可以整合实施在单个实施例中。反之，在单个实施例的上下文中描述的各种特征也可以分离地在多个实施例或在任意合适的子组合中实施。

Claims (10)

1.一种在区块链节点设备处执行的票据处理方法，包括：

基于针对通证的业务请求，确定所述通证是否处于与所述业务请求相对应的第一状态，其中，所述通证与所述票据相关联；

当所述通证处于第一状态时，基于所述业务请求来调用银行承兑通证协议中相应的智能合约接口来确定与所述业务请求相对应的业务计算结果；以及

当所述业务计算结果在区块链中共识成功时，将所述通证的持有方地址修改为所述业务请求的被请求方的地址。

2.如权利要求1所述的方法，其中，当所述业务请求为贴现业务的请求时，所述第一状态为已承兑，并且基于第一贴现率来确定所述贴现业务的业务计算结果。

3.如权利要求2所述的方法，还包括，当所述业务计算结果在区块链中共识成功时，将所述第一状态修改为已贴现。

4.如权利要求1所述的方法，其中，当所述业务请求为转贴现业务或再贴现业务的请求时，所述第一状态为已贴现，并且基于第二贴现率来确定所述转贴现业务或再贴现业务的业务计算结果。

5.如权利要求4所述的方法，还包括将当所述业务的计算结果在区块链中共识成功时，将所述第一状态修改为转贴现或再贴现。

6.如权利要求1所述的方法，其中，当所述业务请求为背书业务的请求时，所述第一状态为未贴现，并且基于指定金额来确定所述背书业务的业务计算结果。

7.如权利要求1所述的方法，其中，所述业务请求包括所述通证的标识信息、贴现时间信息。

8.如权利要求1所述的方法，还包括，当所述业务计算结果在区块链中共识成功时，在所述通证的业务记录列表中添加与所述业务相关联的信息，并且所述业务记录列表中的数据根据时间排序。

9.如权利要求1所述的方法，还包括，当所述通证未处于第一状态时，向业务请求方发送拒绝业务请求信息。

10.一种信息处理装置，包括：

处理器；以及

存储器，其用于存储指令，当所述指令在执行时使得所述处理器执行如权利要求1至9中任一项所述的方法。