一种基于Baas架构的区块链跨境跨行支付方法和系统与流程

本发明涉及金融领域，尤其涉及一种基于baas架构的区块链跨境跨行支付方法和系统。

背景技术：

如今，电子商务已逐步由本地化向全球化发展，并且全球性的资金转账也随着全球化的进程而越发频繁。在该情况下，跨境下的跨行支付变得越发重要，能够帮助用户和商家直接进行交易，方便在全球进行购物、消费，并且相比于通过本地的购物中介，直接进行交易既能够提高购物品类，也能够保障商品质量，方便售后服务。因此，如何实现便捷的跨境跨行支付已经成为亟待解决的问题。

目前采用的解决方案是通过第三方中介。考虑一个情景，中国的甲将自己a银行卡中的100元转到美国的乙的b银行卡中，其中a、b两家银行没有直接的合作。在第三方中介出现前，该业务不能执行，想要实现支付行为只能双方办理同一银行或者具有跨境跨行服务的银行的银行卡；在第三方中介出现后，只要该中介与a、b两家银行都办理了相关业务，就能够实现。通过a银行将钱从账户转给c，告诉c自己的汇款对象，c将钱换成外汇转给b中乙的账户。由此最终实现转账的功能。

这套解决方案存在以下几个问题。第一，第三方中介需要具有相当的资质和信用，只有这样，各银行才会和其合作，这就导致对应服务的准入门槛高，服务量相对稀缺。第二，由于引入了第三方中介，支付成本不可避免地上升，对于数额较小的情况影响很大。第三，可扩展性差，银行和第三方双方需要前期投入大量精力来制定服务的细节，随着参与银行增多，第三方中介的维护成本上升，压力大增。第四，转账存在延迟，第三方为了节约成本，小额的支付一般是打包之后在固定时间结算，这就造成到账的延迟，一笔跨境的支付业务可能会消耗数天。在电子商务中，这样带给客户的体验较差。第五，由于数据不共通，保证交易数据的一致性难度较大，一单交易，需要在付款银行、第三方中介、收款银行处都留有记录，每隔一段时间，银行对所有交易进行整理的时候，考虑到交易的频繁和范围广泛，成本很高，并且由于数据不共通，一旦转账出现了问题，想要追查问题变得十分麻烦，需要两家银行和第三方参与，对于数量巨大的小额交易来说，出现问题是常见的，对于银行和第三方来说成本也是很高的。

技术实现要素：

本发明的目的在于提供一种基于baas架构的区块链跨境跨行支付方法，该方法不采用第三方中介，而是采用覆盖全球的云服务器中心模式，银行将储户数据处理后交给云服务器中心，通过服务器中心进行交易，其中服务器中心采用区块链技术保证储户数据安全、交易记录可靠可查询，并为银行提供便捷的查询服务，实现跨境跨行支付成本的降低和服务质量的提高。

一种基于baas架构的区块链跨境跨行支付方法，包括以下步骤：

(1)银行将用户的账户信息导入云服务器中心组并采用区块链技术进行保存，云服务器中心组为银行设置结算账户；

(2)用户向付款账户所属银行发起支付请求；

(3)付款账户所属银行将支付请求发送给云服务器中心组，云服务器中心组中的各个云服务器中心通过共识算法判断支付能否发生；

(4)若支付能发生，则各个云服务器中心将减少付款账户及付款账户所属银行结算账户的余额，增加收款账户及收款账户所属银行结算账户的余额，减少或增加的金额等于支付金额。

本发明采用后端即服务baas架构，银行不需要在数据的维护上投入成本，仅仅需要将数据导入云服务器中心就可以向用户提供跨境跨行支付服务。

步骤(1)为数据的初始化，银行向云服务器中心组导入数据，同时确保云服务器中心组中的所以云服务器中心存储一份相同的数据备份。

云服务器中心组包括全球范围内的所有云服务器中心。

步骤(1)包括：

(1-1)银行在云服务器中心组中选择一个云服务器中心作为导入中心，将用户的账户信息导入，该导入中心将导入的数据存储在脱链数据库中，同时为该银行设置结算账户；

所述账户信息包括账号和余额；

(1-2)银行与导入中心进行数据一致性验证，若二者数据不一致，返回步骤(1-1)重新向导入中心导入数据；若二者数据一致，则进入下一步；

数据一致性验证的方法为：

分别将银行和导入中心中的账户信息进行分块，通过sha256算法计算哈希值，若二者的哈希值不同，则二者数据不一致；反之，则二者数据一致。

(1-3)导入中心将导入的数据同步至云服务器中心组中的其余云服务器中心；

(1-4)导入中心与其余云服务器中心进行数据一致性验证，若数据不一致，返回步骤(1-3)重新同步数据；若数据一致，则进入步骤(2)；

数据一致性验证的方法为：

分别将导入中心和其余云服务器中心中的账户信息进行分块，通过sha256算法计算哈希值，若二者的哈希值不同，则二者数据不一致；反之，则二者数据一致。

步骤(2)包括：用户向付款账户所属银行发起支付请求并提供付款账户的账号和密码，付款账户所属银行验证所述账号和密码是否匹配，若不匹配，则提示用户密码错误；若匹配，则进入步骤(3)。

步骤(3)付款账户所属银行将支付请求信息发送给云服务器中心组，在云服务器中心组采用跨中心共识算法判断支付能否发生。支付能否发生主要从两个方面进行判断：一是通过签名实现信息来源正确性的判断，二是判断支付本身的正确性，通过各个云服务器中心脱链数据库中的数据，检测收款账户是否存在，付款账户余额是否充足。

步骤(3)包括：

(3-1)付款账户所属银行在云服务器中心组中选择一个云服务器中心作为接收中心，接收中心接收并加密付款账户所属银行发送的支付请求信息后，转送给云服务器中心组中的其余各个中心；

支付请求的信息包括：付款银行信息、付款账户、支付金额、收款账户及收款银行信息。

加密方法为：接收中心将自身中心编号附加在支付请求信息之后，用自身私钥进行加密形成签名。

接收中心将签名、自身中心编号附加在支付请求之后发送给其余各个中心。

(3-2)其余各个中心确认支付请求来源的真实性后，判断支付能否发生，并将判断结果在云服务器中心组中广播；支付能发生的判断结果为是，支付不能发生的判断结果为非；

其余各个中心通过验证签名的正确性来判断支付请求来源的真实性。

当支付请求来源的真实性得到验证后，判断支付本身能否发生，主要验证收款账户是否存在、付款账户余额是否足够。若收款账户存在、付款账户余额足够，则判断结果为是；若收款账户不存在或付款账户余额不足，则判断结果为非。

(3-3)每个云服务器中心统计判断结果，当判断结果为是或为非的云服务器中心数超过总云服务器中心数的一半时，将该判断结果作为最终结果；

(3-4)在云服务器中心间进行数据同步，使各个云服务器中心的判断结果与最终结果一致；

具体包括以下步骤：

(i)若云服务器中心的判断结果与最终结果不一致，则该云服务器中心在云服务器中心组中广播数据同步请求；统计数据同步请求数；

(ii)当数据同步请求数小于预设阈值时，广播数据同步请求的中心自行选择一判断结果与最终结果一致的中心进行数据同步；

当数据同步请求数大于或等于预设阈值时，云服务器中心组中进行所有中心间的数据同步。

所有中心间的数据同步方法为：对各个云服务器中心的数据进行分块并通过sha256算法计算哈希值，将哈希值在云服务器中心组中进行广播，各个云服务器中心对哈希值进行统计，选择数量最多的哈希值所对应的数据在中心间进行同步。

所有中心间的数据同步针对脱链数据库和操作日志区块链分别进行。

若各个云服务器中心的判断结果与最终结果一致，则不需要数据同步。

各个云服务器中心的数据一致后进入下一步。

(3-5)若最终结果为非，则支付失败；

若最终结果为是，则各个云服务器中心减少付款账户及付款账户所属银行结算账户的余额，增加收款账户及收款账户所属银行结算账户的余额，减少或增加的金额等于支付金额；将操作日志记录在云服务器中心的区块链上；

(3-6)云服务器中心组向付款账户所属银行返回支付失败结果；

或云服务器中心组向银行返回操作指令，修改银行数据。

本发明还公开了一种基于baas架构的区块链跨境跨行支付系统，包括：

用户层，向银行发送支付请求，接收支付结果；

银行层，接收用户层发送的支付请求并转发给云服务器层；

云服务器层，包括操作日志区块链和存储用户账户信息的脱链数据库；接收支付请求信息，通过共识算法判断支付能否发生；

若支付能发生，则进行支付操作并将操作记录如操作日志区块链，将支付操作结果返回给银行层；

若支付不能发生，则向银行层反馈支付失败。

用户需要在银行申请专门的账号用于跨境跨行支付，该账号所有操作通过上述跨境跨行支付方法进行。

对于银行层，每一家银行需要存储的是自身所有用户的账号和对应的密码，可以选择存储的信息为任一用户账户的余额情况、交易情况。银行间不需要专门的通信，仅与云服务器中心交互。银行从用户层接收支付的相关信息，直接调用云服务器层提供的接口，不直接操作数据，从云服务器层获取返回结果，返回给用户相应结果。银行能够根据自身资金状况选择灵活的方案，可以获取所有的账号信息以进行相关分析，也可以选择获取部分银行用户的数据。

作为优选，云服务器层采用后端即服务baas架构，仅向银行层提供服务接口；底层的细节不对外开放。

所述的服务接口支持导入操作、查询操作、支付操作。

导入操作接收银行所有的初始数据，查询操作支持操作记录查询、账户查询等，支付操作接收相应操作参数，返回结果。

云服务器层的每一中心都有确定的编号，都有唯一的一对公钥和私钥用于中心间的通信。

与现有采用第三方中介的跨境跨行支付相比，本发明的有益效果为：

首先，本发明采用了baas架构。采用后端即服务的优势在于显著降低了银行成本，通过本发明，银行实现跨境跨行服务不需要额外的成本，只需要提供给云服务器中心对应的数据即可，数据的维护不需要银行参与，同时，这又加快了新银行加入的速度。只要通过审核，将数据导入之后就能立刻提供服务，不再需要去布置服务器等前期准备工作，服务的细节也不再需要去逐一商榷。

其次，支付转账的结果大大加快。由于采用云服务器中心作为区块链中的节点，节点的数量是较少的，审核交易的速度是非常快的，借助于银行结算账户，基本能够实现实时到账。相比于第三方中介动辄数天的用时来说，用户体验可以说是显著提升了。

此外，采用区块链的技术方案，数据的一致性能够得到保证。并且交易统计工作将不再需要多方参与，仅需要云服务器中心进行统计，并将对应的统计结果接口开放给银行即可。在本发明中，一旦操作出现问题，由于区块链所有记录公开的特性，任何一家银行都能够通过云服务器中心查找到任意交易的相关信息，查错成本也能够降低。

附图说明

图1为基于baas架构的区块链跨境跨行支付系统的结构示意图；

图2为数据初始化的流程示意图；

图3为支付操作的流程示意图；

图4为共识算法的流程示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步详细描述。

如图1所示，基于baas架构的区块链跨境跨行支付系统，包括三层：

一层是用户层。用户需要在银行申请专用的跨境跨行支付账号用于支付，该账号所有操作需要通过本发明实现。用户可以向银行申请通过专用的跨境跨行支付账号进行支付支付，接收支付结果。

一层是银行层。每一家银行需要存储的是自身所有用户的账号、对应的密码以及其余的用户信息，可以选择存储的信息为任一用户账户的余额情况、交易情况。银行间不需要专门的通信，仅与云服务器中心交互。银行从用户层接收支付的相关信息，直接调用云服务器层提供的接口，不直接操作数据，从云服务器层获取返回结果并返馈给用户。银行能够根据自身资金状况选择灵活的方案，可以获取所有的账号信息以进行相关分析，也可以选择获取部分银行用户的数据。

一层是云服务器层。该层采用后端即服务baas架构，底层的细节不对外开放，仅提供服务相关的接口。其中，提供的接口包括导入操作、查询操作、支付操作。导入操作接收银行所有的初始数据，查询操作支持操作记录查询、账户查询等，支付操作接收相应操作参数，返回结果。每一中心存储一份脱链数据库和操作日志区块链的备份。其中脱链数据库包括所有账户的简要数据库和银行结算账户数据库，操作日志区块链采用区块链记录整个系统的操作日志，每一区块上记录着操作日志。每一中心都有确定的编号，都有唯一的一对公钥和私钥用于中心间的通信。

一种基于baas架构的区块链跨境跨行支付方法，包括以下步骤：

(1)数据初始化，如图2所示，具体如下：

(1-1)支付银行选择用于数据导入的云服务器中心。支付银行考虑距离、交通、通信等因素，从云服务器中心组中选择一个，作为数据导入的对象；

(1-2)支付银行将数据导入选定云服务器中心。所导入的数据为用户的银行账户及该银行账户余额所组成的键值对。该选定云服务器中心将导入数据存储在脱链数据库中，同时该选定云服务器中心为该支付银行设置结算账户，用于处理银行间的结算业务。支付银行需要确保自身的结算账户余额处于一定阈值内。

(1-3)支付银行和该选定云服务器中心进行数据一致性验证。通过sha256算法分别计算支付银行导入数据的哈希值和选定云服务器中心接受到的数据的哈希值，如果哈希值存在不同，说明数据值存在不同，需要返回步骤(1-2)重新导入数据；如果哈希值完全相同，可认为记录完全相同，进入下一步操作。可将数据分块后计算其哈希值，加快验证速度。

(1-4)将选定云服务器中心的导入数据同步至其余云服务器中心。

(1-5)验证选定云服务器中心与其余云服务器中心数据的一致性。方法与步骤(1-3)类似，判断其余云服务器中心数据的哈希值与选定云服务器中心数据的哈希值是否一致，如果不一致，则不一致中心重新从选定云服务器中心同步数据。当所有云服务器中心的数据都一致后，就确保了系统开始运作时各个子节点的数据一致。

(2)支付流程，如图3所示，具体包括：

(2-1)用户向付款银行发起支付请求，向付款银行提供付款账号、付款账号密码、支付金额、收款账号、收款银行信息。参与交易账号需为本发明专用账号，所有操作需通过银行调用后端接口完成，不能单独由某一银行操作完成。

(2-2)付款银行收到用户支付请求后，通过所储存的详细数据库验证账号和密码是否匹配。如果不匹配，则提示用户密码错误。如果匹配，则选择就近的云服务器中心作为接收中心，将支付请求发送给接收中心，该过程通过调用服务器层的接口实现。

当银行给就近的云服务器中心发送支付请求后，在一定时间内该中心如果未发回反馈，则银行判断该中心出错，更换中心后重新发送请求。如果中心正常运行，将会进入下一步骤。

(2-3)接收中心收到请求后，通过共识算法对支付请求信息进行验证，决定接下来的操作。

如图4所示，具体包括以下步骤：

(a)接收中心会将自身的中心编号附加在支付请求信息(包括付款银行信息、付款账号、支付金额、收款账号、收款银行信息)之后，用自身私钥加密进行加密形成签名，将生成的签名、自身的中心编号附加在支付请求信息)之后，发送给其余所有中心；

(b)其余所有中心在接收到信息后，首先会判断信息来源的真实性，主要通过验证数字签名的正确性实现。当来源的真实性验证后，就会判断支付本身能否发生，主要验证收款账户是否存在，付款账户余额是否足够。若接收到的信息来源真实，收款账户存在且付款账户余额充足，则判断结果为是，否则，判断结果为非。

无论判断结果为是还是为非，各个中心都会广播自身的判断结果。广播信息由接收到的支付请求信息、自身的中心编号、判断结果、自身私钥加密生成的数字签名组成。广播信息将会发送给所有中心。

(c)每个中心将会统计每个支付请求的判断结果。

当某个云服务器中心接收到其余中心的广播判断信息时，将首先通过签名判断信息来源的真实性，如果通过，则会统计其判断结果。当判断结果为是或为非的中心数超过总中心数的一半时，将该超过总中心数一半的判断结果作为最终结果。

由于不同中心运算速度存在差异，可能二者均未达到一半，这时中心将会进入等待状态。同时，中心为每一项支付请求设置一定的时间阈值，达到阈值后将直接向未收到其判断结果的中心发出返回其判断结果的请求。

(2-4)如果某个云服务器中心的判断结果和最终结果不一致，说明该中心的数据一致性遭到破坏。该中心广播请求进行一次中心间的数据同步。

当数据同步请求数小于预先设置阈值时，请求中心自行选择某一自身判断结果与最终结果一致的中心进行数据同步；当数据同步请求超过阈值后，需要进行所有中心间的数据同步。

所有中心间的数据同步方法为：将各个中心中的数据进行分块，通过sha256算法计算出哈希值并将哈希值在云服务器中心组中进行广播，接着云服务器中心组对哈希值进行统计，计算每一个哈希值有多少个云服务器中心发送过，选择其中数量最多的哈希值所对应的数据同步至所有中心。

数据同步针对脱链数据库和操作日志区块链分别进行。

(2-5)当所有中心的判断结果统一成最终结果后，执行相应操作。

如果最终结果为是，则各个中心执行操作：包括将操作日志记录至区块中，减少付款账户余额，增加收款账户余额，减少付款银行结算账户余额，增加收款银行结算账户余额。增加或减少的金额等于支付金额。执行完成后，云服务器中心组会根据距离等因素选择合适的中心向银行返回操作指令，修改银行数据，银行也可以通知用户支付成功。

如果最终结果为非，则云服务器中心组会根据距离等因素选择合适的中心向银行返回支付失败结果。