近年来，面对银行线上电子支付服务的快速发展，传统企业也迎来了业务创新机会。企业信息化系统通过银行提供的银企直连接口、电子支付接口、第三方支付通道，可以快速实现日常业务电子转账、交易查询、余额查询。自动化及快速高效的资金收支体验，使得企业对电子支付系统给予业务支持的期望也越来越高。但是电子支付通道带给企业支付便捷性的同时，也增加了系统支付的安全风险。
随着数字经济在全球的迅速发展，新一代信息技术对各行各业的影响日益扩大，许多金融机构都开始研究区块链技术，并尝试将其运用于现实，试图改变金融体系所面临的各种安全性、中心化等问题。
区块链是综合运用密码学、分布式数据库、P2P通信、智能合约等技术，在一个去中心化、去信任网络中，利用加密算法在链式数据结构中验证和存储数据。其技术实现就是运用数学算法和加密技术，应用不可逆的哈希函数、时间戳、分布式共识机制等技术手段，构建互联网环境下无须第三方信用背书的金融认证体系。总的来看，区块链的本质是一个对等网络的分布式账本数据库。
从目前社会上已经公布的研发成果看，区块链的应用已有一些重大进展，但是很多项目尚处于研发和摸索阶段。对传统企业来讲，区块链技术的应用面临较大的系统成本、技术成本和人力成本。与带来的收益相比，其资本回报率低。真正的区块链技术在实际应用中也存在一些问题，比如交易确认耗时长、能耗高等。并且区块链技术的应用，需要对传统的信息化系统进行重构，这势必会带来系统的不稳定性。
但是区块链技术的应用有其独特的优势，比如区块链具有不可篡改的特点，一旦发生交易，各个节点中都有记录，从而避免了业务和资金之间的数据不一致而产生纠纷问题。区块链数据前后相连构成的不可篡改的时间戳，使得监管部门对交易履历的查阅成本降低，完全透明的数据存储体系提供了可信任的追溯途径，可以实现监管政策全覆盖，降低了监管成本。
区块链的“共识算法”、“加密算法”等核心技术，可以保证原始交易信息不被篡改，保证其在各个交易节点的一致性和安全性。
因此基于对区块链技术劣势和优势的分析后，对企业使用中的电子支付系统，不直接应用“区块链”技术，以一种全新的设计思路，对原有电子支付系统的功能架构进行微调，增加中心交易账本模块。
通过加密算法加强对访问支付系统的用户身份的验证，通过对每笔支付交易的关键信息的HASH值记录跟踪，建设支付系统内部一条类“区块链”，以达到系统访问用户身份安全认证、原始交易信息无篡改增强检查，并且可以通过这条内部交易链，做到业务可追溯、可审计，提高支付系统安全性的目的。
1、总体设计概述
1. 系统目标
建立支付系统的中心交易账本，方便每一笔支付交易的生命周期跟踪，为业务系统、资金系统相关用户提供查询服务。通过“交易链”，将每一笔付款单的生命历程串联起来，可以查询到每一笔交易的运行路径，为审计提供查询线索。通过“交易链”上的上下游的唯一HASH交易号，在支付环节验证数据前后一致性，防止支付申请被人为篡改，防范支付风险。
2. 技术路线
（1）开发平台
系统采用本公司自行研发的i Plat4J V6技术开发平台。按照“大平台、微服务”的架构模式进行设计，采用面向服务（SOA）及微服务（MSA）的技术架构模式，具有开放、轻量、解耦的特性，帮助企业快速构建扁平化、组件化、服务化应用系统。
（2）前台
基于全新的i Plat UI组件库，采用HTML、CSS、Java Script等标准的Web技术，可以方便地实现在PC端和移动端的统一展示页面。
（3）微服务
该系统原来采用微服务的软件架构，微服务就是把一个大型的单个应用程序和服务抽象为颗粒度更小的微服务。因此本次增加的账本服务模块，只需要提供单独的服务组件，和原有服务建立的接口服务，或者更新应用程序的单个组件，而不会影响原系统核心服务部分。
（4）接口
采用REST API。REST API的好处是基于标准的HTTP协议，对软件依赖性小、兼容性较好。
（5）数据库
本系统设计基于DB2数据库。
2、系统架构设计
1. 系统功能结构
交易账本模块在整个电子支付系统中主要承担两个主要功能，首先是对访问用户的密钥管理及身份验证；其次是对交易信息HASH值得记录及关键节点HASH的校验核对。中心交易账本功能结构如图1所示：
图1 中心交易账本功能结构
2. 账本数据模型
中心账本数据模型采用账本头、账本明细及交易明细三层结构存贮交易数据。账本主要记录每一笔付款单在每一个时间戳上对应的关键交易信息的HASH值。详见图2。
图2 中心账本数据模型
3. 系统使用算法
（1）数据签名认证采用非对称加密RSA算法
区块链的模型设计中，一般采用非对称加密技术对数据进行加密验证。RSA算法是目前常用的非对称加密算法之一，它既能用于数据加密，又能用于数字签名。RSA包含一对密钥对，公钥对外公开，而私钥是私密的，由用户保管。本设计方案采用RAS算法，对于发起支付申请的访问系统身份进行验证。由于不同的访问用户分配的公私密钥不同，从而可以保证信息只能由通信双方获取，因此在数据加密方面安全可靠。
（2）交易账本登记信息采用HASH算法
中心账本中各个节点之间对交易的验证使用HASH算法。由于该算法在电子支付系统内部及和电子支付系统交互的相关业务系统中使用，因此从交易量上考虑，使用SHA1就能满足系统需求。SHA1是一种数据加密算法，该算法是可以将一段明文，以一种不可逆的方式将它转换成一段长度较短、位数固定的信息摘要的过程。系统采用SHA1哈希函数，将交易明细信息用SHA1哈希函数进行处理后将计算结果存储到账本中。
3、应用场景说明
1. 密钥签发管理
每一个外部系统调用电子支付系统之前，先登记注册。密钥签发中心给每一个申请的业务系统生成一对密钥。该业务系统的私钥和电子支付系统的公钥同时分发给业务系统。公私钥对：（sk,pk):=generate Keys（keysize),sk私钥发给申请人使用，pk公钥由电子支付系统保留。同时将电子支付系统本身的公钥发给业务系统，用于对整个发送报文的加密。
业务系统密钥注册成功，并设置一定有效期。到期后系统将会重新生成密钥，并通知对方同时进行更换。主要数据结构设计见表1。
表1 密钥管理数据结构
2. 密钥分发
电子支付系统密钥生成后，将该业务系统的私钥和电子支付系统的公钥同时分发给业务系统。业务系统密钥注册成功，并设置一定有效期。到期后系统将会重新生成密钥，并通知对方同时进行更换。
由于电子支付系统的公钥面向所有来访业务系统发放，为避免频繁更换导致所有业务系统同步调整，因此将资金系统的公钥有效期限适当延长。见图3密钥分发图。
图3 密钥分发图
3. 数据加密签名及解密验证
电子支付系统要求接入系统必须对原始报文信息按照统一的加密及数字签名后，才能将申请支付信息发送给电子支付系统。电子支付系统收到支付申请后，对签名进行验证和数据核对，确保该表交易的签名和实际提交人的签名一致后，支付申请才被接收。报文非对称加密解密示意图参考图4。
（1）业务系统加密
业务系统发起支付申请前，对支付申请的明细报文信息进行SHA1计算出HASH值H1。
H1=SHA1（detailMessage: P1）
然后对此HASH值用分配给业务系统的私钥进行数据签名。
H1': = sign（SK2, H1）
业务系统将包含加密后的HASH值H1'、交易明细报文P1及报文头组装后形成报文C1,C1用资金系统分发的公钥Pk1对C1进行加密，然后将加密后的信息通过系统间REST接口，传入电子支付系统。
C1=（P1, H1', HEAD）
C1': = sign（PK1,（P1, H1', HEAD））
图4 非对称加密解密示意图
（2）电子支付系统解密：
电子支付系统在收到业务系统的支付申请C1'后，先用电子支付系统的私钥Sk1对此交易进行解密。
C1:=verify（Sk1,C1'），然后得到C1
从C1记录中，获取交易明细P1，用SHA1进行计算得出交易明细结果H1
H1=SHA1（P1）
然后对交易记录C1中的H1'，用资管系统的公钥Pk2进行解密，得出结果H1
H1: =verify（PK2, H1'），
最后，如果第2步和第3步的结果相同，则说明该申请数据确实来源于资管系统并且数据在传递过程中没有被篡改。验证成功。
4. 账本登记
业务系统通过REST接口，将支付申请发送到电子支付系统。支付系统收到该笔申请，将报文中的收方账号信息、付方账号信息、金额、业务类型、申请人等关键要素组合后，用SHA1算法生成HASH值，调用中心交易账本的交易登记接口服务，将照申请单号、时间戳、来源系统、HASH值等信息记录到中心账本。
在资金审批环节，审批中心对收到的支付申请信息，将报文中的关键要素组合后，用SHA1算法生成HASH值，调用中心交易账本的交易登记接口服务，将当前交易记录信息及HASH值记录到中心账本。
在电子支付系统每一个流经节点，都会将当前节点收到的支付申请报文按照申请单号、时间戳、支付申请报文的关键要素的HASH值等写入中心账本，同时将报文明文信息单独计入明细报文表中。
5. 交易HASH值校验
资金审批环节，审批中心根据当前收到的支付申请明文报文，组装报文中的核心关键要素，按照SHA1算法对组合后的关键要素字符串进行HASH值计算，然后按照时间戳，获取中心账本中该支付申请单的最新的一条HASH值，和当前计算的HASH值进行对比，HASH值核对一致，是资金审批通过的前提条件。核对不一致，则退回给业务系统。
资金支付环节，将支付申请发送到银行之前，需要再次核对当前节点获取到的支付申请数据是否真实有效。将当前节点收到的支付申请明文报文中关键要素组合后，用SHA1算法计算HASH值，和该笔申请单的上一个节点的HASH值进行比较。
如果比较结果一致，则继续和该笔支付申请单的时间戳上最早的第一笔交易上的HASH值进行比较，如果两次比较下来，HASH值一致，则说明数据从业务系统发出后，在电子支付系统的各个处理环节，数据未被篡改，满足支付的基本前提条件。
6. 账本查询
各业务系统对访问中心账本查询交易时，需提前进行系统注册登记，登记后方可获取私钥。业务系统的查询报文，需要通过私钥对报文进行加密后发给中心账本，中心账本通过该系统的公钥验证签名是否正确，签名验证通过则允许访问中心账本进行查询。中心交易账本可以查询到每一笔支付申请交易所经过的所有节点，每一笔节点上的时间戳、参与人、签名、交易明文及处理结果。
7. 日志管理
账本在生成时，采用同步和异步两种模式对账本进行记录。同步模式，在每一笔交易发生时，将签名、加密报文、明文等信息写入账本中。同时异步事务，将交易记录在文本中。在系统账本发生异常时，可根据交易文本对系统账本进行恢复。
4、系统分析
1. 安全性分析
通过中心交易账本模块建设，增加了支付系统访问用户的身份有效性验证及支付申请交易的HASH值在各个节点的一致性对比。通过身份认证，确保支付系统收到的每一笔支付申请，数据来源都是在支付系统登记及密钥验证通过的。
通过支付申请报文关键要素HASH值计算及在支付环节上下道工序间数据的一致性比对，确保每一笔支付申请从业务系统发出，在到达银行之前，任何节点对数据的恶意破坏或者人为修改，都会使支付申请在发给银行前进行内部拦截，无法实际支付。
2. 效率分析
从效率上来讲，通过非对称加密算法，来访系统对身份进行签名加密，支付系统对来访系统身份进行解密验证，在系统实际使用中，支付系统在对来访系统身份验证后再对支付申请报文验收入库速度未见明显卡顿或者缓慢。
支付系统在各个处理节点都增加了账本登记功能，由于系统在交易账本登记处理逻辑和支付系统每个节点的主体处理逻辑上采用异步事务处理模式，因此各个处理节点上的账本登记并未对支付系统的整体流程效率有较大的影响。
5、结论
所谓的“区块链”，就是每个区块经过加密，由此形成区块链。其实质是一个不断加长的列表记录，但是以分布式存储在网络的所有节点。
通过区块链技术的学习和在日常项目中应用的启发，该系统经过局部改造后，基于数据库数据存储功能，增加了中心交易账本应用模块，将每一张支付申请作为一个区块，将每张支付申请经过的业务处理和资金处理全路径形成的列表记录作为链，形成了该系统的“交易链”。通过中心交易账本模块，让每一笔业务记录清晰可见，审计查询也有线索进行追溯。
交易日志可以随时对被意外破坏的账本进行还原，增加了账本的安全性。该系统方案采用了传统的数据库结构和局部功能重构，原系统改造人工成本小，软硬件投入成本低，技术实现简单，因此对提升传统企业支付系统安全性方面的支付系统升级改造，有一定的借鉴意义。
