支撑财政转移支付的区块链技术方案研究

张建根

河北省财政厅 信息中心，石家庄 050051

随着中央与地方财政事权和支出责任划分改革不断深入，财政转移支付资金规模逐年加大，中央对一般公共预算安排地方转移支付支出已占支出总额的65%以上。如何实现对财政转移支付资金的科学管理、高效运转、有效监督，给财政信息化建设带来巨大挑战，也带来了难得的机遇。国家信息中心原首席工程师宁家骏就指出[1]：“财政信息化建设在财政管理中始终发挥着基础性、保障性作用。”“对财政信息化建设而言，深化财税体制改革既带来挑战，更多的是难得的机遇。”

早在2009年，河北省财政厅[2]依托“金财工程”应用支撑平台的全面实施，建成了财政专项资金即时分析监控系统，建立起财政资金分配、下达、使用的即时监控体系，提高了财政管理和监督工作精细化、高效化、自动化水平。海南省财政厅[3]构建了全省一体化平台，涵盖了一级政府从预算编制、预算执行、预算监督到执行分析的一体化的财政业务管理全过程。集中部署既统一了全省财政业务管理模式，也有效缓解了集成财政部门经费短缺和技术人员不足的问题。河南省财政厅[4]自动汇聚省市县预算执行、财政专户资金管理和一卡通等财政业务应用系统中财政扶贫资金分配审核拨付的全业务流程数据，构建监控模型，建成功能完善、应用高效扶贫资金动态监控系统，实现对省市县乡扶贫资金的分配、下达及支付全流程监控。

然而，随着各省财政信息化的不断发展，逐渐形成了地方财政部门“各自搭台，分头唱戏”的现象，建成了以地方财政部门为中心的财政信息化系统，导致财政业务数据标准不一致，资金使用数据难以共享的信息壁垒，给对中央转移支付资金监控带来了极大的困难。例如林鹭[5]指出财政部在全国范围内部署开展财政扶贫资金动态监控工作以来。由于数据自动共享难度大，广西省财政部门的预算指标和分配信息需要手工录入，这不仅严重降低了工作效率，而且无法保证录入数据的质量。更为严重的是，由于监控数据来自于手工录入，上级财政部门不具备有效手段验证采集数据的真实性，无法发现下级财政部门弄虚作假，甚至恶意篡改数据的行为，这给财政转移支付资金运行带来极大的风险。

区块链技术[6]具有去中心化、防篡改、可追踪等特性，可以在不可信环境下完成可信交易。正好符合转移支付资金管理涉及各级财政部门，资金安全必须保障、业务链条应追踪到底等业务需求。因此本文基于区块链技术，提出了一种针对转移支付资金管理的解决方案。以联盟链为基础，构建了包含中央、省、市、县四级行政区划的财政转移支付体系，共识机制提高了转移支付业务办理效率，通道划分满足了转移支付管理的隐私保护，防篡改特性实现了转移支付数据的安全保障，可追踪特性提升了对转移支付资金的监督审计质量。

1 相关工作

1.1 区块链技术简介

区块链可以认为是一整套利用时间戳、非对称加密、点对点传输、共识算法、智能合约、链式数据结构、分布式存储等技术手段重构信任问题的解决方案。其本质上是一种加密的分布式即时账簿系统。

账簿系统的所有参与节点通过互联网相互连接，可以直接通信。任意参与节点都保存账簿全部信息。账簿仅允许添加新的交易内容，不允许任何删除和修改。所有参与节点利用非对称加密算法保证交易信息传输过程中的数据安全，利用共识算法完成新交易内容确认。参与者将交易按照时间先后顺序链接成一种链式数据结构：区块链。任意节点单方面篡改区块链中交易记录都不影响其他节点保持的账簿内容，因此这种单方面的篡改是无效的。此外，区块链2.0[7]后任意可编程的交易逻辑都可在区块链系统内在满足预设条件时自动执行，确保交易规则的公平公正。

因此区块链技术最显著的内涵在于通过一系列数学算法和信息技术的巧妙组合和应用，确保数据不可篡改，全程可追溯，规则可正确执行，改变社会交易中以第三方机构背书的信任机制，形成一种以严格数学算法为保障，高新信息技术为支撑，人人为我背书，我为人人背书的社会信任机制，从而可快速并高效完成资源的公平配置，达到确保所有参与者的目标一致、行为规范的目的。

公有链[6-7]允许任意节点匿名加入，是区块链最初的形态。但节点的匿名性和数量无限制性的特性给区块链监管以及区块链交易速度带来了极大的困难，因此促进了有准入控制机制的私有链和联盟链的发展。私有链的网络系统和数据的管理权限、使用权限均归属于某个组织或者机构，常用于单一机构的内部管理。联盟链集合了公有链的多节点参与特征以及私有链的节点准入特征，克服了交易速度，业务隐私、数据监管等方面的障碍，受到了企业界普遍的欢迎。Linux 基金会发起的Hyperledger项目先后提出多个联盟链平台[8]，满足不同业务场景的需求；金融区块链联盟提出Corda[9]，着力于解决金融行业数据隐私和监管之间的矛盾，反对数据全网广播，及每个节点拥有全部数据；企业以太坊联盟[6]推动全球性的标准规范，促进以太坊技术在企业级的应用；微软提出CCF 框架[10]，提出了区块链协议的加速机制，能够提供更高效易用的联盟链实现方案；我国金链盟提出FISCO BCOS[11]，旨在整合及协调金融区块链技术研究资源，满足金融行业高频交易、安全、合规方面的需求。

在国内，基于以上区块链平台的应用研究领域非常广泛。例如：张亮等[12]对传统房地产供应链运用区块链技术思想，提出了基于以太坊智能合约的房地产供应链建议。谭海波等[13]将以太坊区块链与全球互联的分布式文件系统结合，提出一种基于区块链的档案数据保护与共享方法。禹忠等[14]将超级帐本应用与医药溯源场景，不仅提升了溯源数据的房篡改能力，而且将溯源信息延伸至药品生产、物流及使用等信息。张森等[15]提出了基于超级帐本的冷链物流技术方案，提高了冷链物流行业的可信性和数据的安全性。刘东伟等[16]针对学位证书存证的教育业务场景，提出了以超级账本作为底层区块链技术平台的解决方案，解决了交易吞吐量低以及中心化存储所具有的单点故障问题。汪允敏等[17]基于区块链技术，提出一套工业互联网标识解析的安全防护策略，通过对数据权限控制、加密管理、接口安全，来保护互联网标识数据的安全。

1.2 Hyperledger Fabric简介

Hyperledger Fabric[18]是当前15 个Hyperledger 项目中最活跃的平台项目。Hyperledger Fabric 采用模块化架构，可插拔的身份认证服务、订单服务、P2P服务、智能合约、数据库管理系统、认可和验证策略使其成为可满足多种行业的通用解决方案。Hyperledger Fabric 允许特定交易的参与者构成通道（Channel），只有通道的成员才能存储和查看交易数据，满足了交易的隐私性和机密性。Hyperledger Fabric为网络节点分配角色，将交易处理和交易排序分开，提高了整个系统的交易吞吐量。Hyperledger Fabric 提出新的“execute-order-validate”架构来完成交易，支持通用编程语言编写的智能合约。

Hyperledger Fabric 具有高度灵活性、保密性、弹性和扩展性。使其在教育、电信、医疗、供应链多个行业具有广泛的应用，已有包括马士基、沃尔玛、联想、邮储银行等大客户在内的400多个项目（包括可研阶段）。我国蚂蚁金服、智链万源、点融、知产链、医洁（香港）、华为、旺链科技、小米、安妮股份等知名企业已成为Hyperledger Fabric服务提供商。

2 系统设计

2.1 整体架构

本文提出的基于区块链技术的财政转移支付系统，将财政转移支付业务逻辑与区块链技术深度融合，形成了无中心化组织、运转高效、信息准确的解决方案。其以Hyperledger Fabric为基础，整体结构分为三层，包括系统应用层、业务逻辑层和区块链基础平台层，如图1所示。

图1 系统整体结构Fig.1 Overall system structure

系统应用层是采用Web 相关开发技术实现的用户交互功能，与业务逻辑层采用HTTPS协议通信，实现用户的登入/登出、基础信息设置、转移支付业务办理、统计查询、数据分析等用户操作功能。业务逻辑层采用Java技术实现转移支付业务的办理流程、控制规则等业务逻辑，为系统应用层提供Restful 接口、调用Fabric-Java-SDK 实现转移支付业务数据上链、并提供与其他系统通信的数据交换接口。区块链基础平台层采用Hyperledger Fabric，主要提供SDK 接口、成员管理、共识服务、智能合约、通道隔离、P2P 网络、区块存储等。SDK接口提供业务逻辑层的访问接口，实现业务数据上链功能；成员服务控制转移支付业务参与节点的加入和退出，为参与节点提供身份认证服务；共识服务采用Hyperledger Fabric 提出“execute-order-validate”过程来完成转移支付业务交易过程，确保各参与节点保存转移支付业务数据的一致性；智能合约采用JAVA语言编写转移支付交易逻辑，保证相关交易逻辑的自动执行；通道隔离将转移支付业务涉及方组成单一通道，实现数据隔离和隐私保护；P2P 网络采用Gossip 协议[19]完成交易数据广播，保证同一通道内所有参与节点保存的交易数据是一致的；区块存储采用可以建立索引、具有高效查询效率的CouchDB数据库，实现转移支付业务数据的存储。

2.2 系统节点架构

本文主要解决转移支付项目库管理和转移支付批复下达业务的去中心化管理。以中央转移支付资金为例，其业务管理方包括中央、省、市、县四级行政区划，如图2所示。中央财政设立转移支付项目，并分批下达至省级财政；省级财政将接收到的中央转移支付资金细化分解后用于本级部门预算支出或对下级的转移支付支出，其业务办理结果接受中央财政的监督；市级财政将接收到的省级转移支付资金细化分解后用于本级部门预算支出或对下级的转移支付支出，其业务办理结果接受中央、省级财政的监督；县级财政将接收到的市级转移支付资金细化分解后用于本级部门预算支出，其业务办理结果接受中央、省级、市级财政的监督；在满足以上业务特点的情况下，本系统为尽可能地降低系统网络结构的复杂度，采用单一组织管理方式，将各级次行政区划映射为组织内的Peer节点。其网络结构模型，如图3所示。

图2 中央转移支付业务流程图Fig.2 Flow chart of central transfer payment business

图3 系统节点架构图Fig.3 Architecture diagram of system nodes

身份认证节点管理客户端、中央省市县等Peer节点、排序节点和系统用户的注册和注销，为其颁发数字身份证书，从而实现节点之间数据传输的数字签名和验证。只有获得证书的用户才可调用Fabric SDK。中央省市县等Peer节点部署链码，提供背书和记账功能。系统采用Kafka[20]共识机制，部署Kafka 集群及Zookeeper提升系统崩溃容错和交易吞吐能力。

为保护各级财政转移支付业务数据隐私，并实现必要的业务监管，本系统引入Fabric 建立的通道机制，共建立6类通道（图3中虚线矩形所示）。

（1）中央-省通道：记录该省转移支付部门细化项目和批复部门业务数据，由中央节点和某省节点构成，全部节点为背书节点和记账节点。

（2）中央-各省通道：记录中央转移支付项目及中央下达省级业务数据，由中央节点和全部省节点构成，可为提高背书效率，中央节点和随机选择的部分省节点为背书节点，全部节点为记帐节点。

（3）中央-省-市通道：记录该市转移支付部门细化项目和批复部门业务数据，由中央节点、某省节点和该省辖某市构成，全部节点为背书节点和记账节点。

（4）中央-省-各市通道：记录该省转移支付项目及该省下达市级业务数据，由中央节点、某省节点和该省辖全部市构成，为提高背书效率，省节点和随机选择的部分市节点为背书节点，全部节点为记帐节点。

（5）中央-省-市-县通道：记录该县转移支付部门细化项目和批复部门业务数据，由中央节点、某省节点、该省辖某市和该市辖某县构成，全部节点为背书节点和记账节点。

（6）中央-省-市-各县通道：记录该市转移支付项目及该市下达县级业务数据，由中央节点、某省节点、该省辖某市和该市辖全部县构成，为提高背书效率，市节点和随机选择的部分县节点为背书节点，全部节点为记帐节点。

2.3 共识过程

图3 中客户端提请转移支付业务办理申请后，经过图4 所示共识过程，业务结果才会最终被记入区块链账本。

图4 转移支付业务办理共识过程Fig.4 Consensus process of transfer payment business

（1）交易提交：客户端收集转移支付业务提案相关信息，并将其发送至由背书策略确定的背书节点。

（2）交易背书：各背书节点独立调用链码执行业务提案，对执行结果签名后发送回客户端。客户端收集背书结果，直到满足背书策略约定的条件时才会将业务提案标记为有效业务并创建相应的业务交易。

（3）交易排序：排序服务接收客户端发送的业务交易，将同一通道内业务交易按照时间顺序排序，按照约定的区块最大容量或时间间隔生成区块并签名。

（4）交易广播：排序服务将新生成的区块广播至通道内的记账节点和背书节点。

（5）交易确认：记账节点和背书节点对新区块的交易进行背书策略验证，并按时间顺序执行“读-写冲突”检验。将未通过验证的交易标记为无效后，记入本地区块链帐本。

3 智能合约

Hyperledger Fabric 将智能合约称为链码（Chaincode）。应用层链码是运行在由背书节点进程中独立的Docker 容器环境中应用程序，应用层链码之间相互独立，互不影响。在本系统中，转移支付项目智能合约用于转移支付项目的设立、修改、历史查询等功能，其主要数据要素如表1 所示。部门细化项目智能合约用于部门细化项目的设立、编辑、历史查询等功能，其主要数据要素如表2 所示。转移支付批复部门智能合约用于转移支付批复部门的登记、修改、历史查询等功能，其主要数据要素如表3 所示。转移支付下达下级智能合约用于转移支付下达下级的登记、修改、历史查询等功能，其主要数据要素如表4所示。

表1 转移支付项目主要数据要素Table.1 Main data elements of transfer payment project

表2 部门细化项目主要数据要素Table.2 Main data elements of department detail project

表3 转移支付批复部门主要数据要素Table.3 Main data elements of transfer payment approval department

表4 转移支付下达下级主要数据要素Table.4 Main data elements of transfer payment approval subregion

数据存储采用基于Key-Value存储结构的CouchDb作为存储媒介，将ID+时间戳作为key，序列化其他字段后的值作为value。

4 系统测试

4.1 测试环境

依据图3所示网络环境搭建测试环境，整个测试环境由26台虚拟机组成，包括1个CA节点，1个中央节点，2个省级节点，4个市级节点（每省设两市），8个县级节点（每市设两县），3个排序节点，4个Kafka集群节点以及3个Zookeeper节点。虚拟机配置及各软件版本如表5所示。

表5 测试环境配置信息Table 5 Configuration information of experiment environment

4.2 测试用例及结果

针对财政转移支付业务，测试用例模拟了中央、省级、市级转移支付项目各35 项，下达下级业务各40 次；省级、市级、县级部门细化项目各20 项，批复部门业务各20次。其中中央转移支付项目和资金下达结果如图5所示，显示了该系统的可行性。

图5 中央转移支付项目和资金下达结果Fig.5 Results of central transfer payment projects and funds approval

4.3 性能测试

性能测试检测在不同情况下系统每秒的交易吞吐量（TPS）。根据Androulaki 等[18]研究结果，当区块大小为2M 时，Hyperledger Fabric 平台各指标综合表现最佳，因此该实验固定区块大小为2M。具体实验方法是高并发调用智能合约，统计系统TPS变化。

如图6 分别显示中央转移支付项目（CS1）、中央转移支付下达（CS2）、市级转移支付下达（CS3）、县级批复部门（CS4）4 组实验，每组实验重复20 次的实验结果。可以看出环境因素造成各组实验统计结果略有差异，系统吞吐量保持在280～370 TPS之间。四类测试场景中，中央转移支付项目表现出最好交易效率，平均为325 TPS；市级转移支付下达表现出最差交易效率，平均为317 TPS，这与该业务涉及较多背书节点和记账节点有关，整体来看本设计达到了较高的TPS。

图6 交易吞吐量测试结果Fig.6 Testing results of TPS

5 结论

本设计将区块链技术与财政转移支付业务深度融合，提出了一种基于区块链技术的财政转移支付系统方案，重塑了转移支付业务流程，达成了由一方发起，多方背书的业务新流程，实现了一种业务高效办理、数据安全可信、监督即时可行的转移支付新模式。

在未来的工作中，将从以下两个方面改进提升本设计方案：一是进一步调和数据防篡改能力和数据隐私之间的矛盾。例如，一方面增加中央-省通道节点数据，通过增加背书节点数量提升数据的防篡改能力，另一方面通过背书节点仅保持业务数据哈希值而不保持业务原始数据的方式提升数据隐私性。二是引入国密算法，通过改造Hyperledger Fabric 相关接口，使本方案实现支持国密算法的能力，从而提升整个系统的可控性。