基于联盟链的铁塔电费结算管理系统

2021-04-20居彬赵静杰吴洲洋李敏潘钺

电子技术与软件工程 2021年3期

居彬赵静杰吴洲洋李敏潘钺

（1.江苏电信软件研究院江苏省南京市 210000 2.江苏电信财务共享服务中心江苏省南京市 210000）

1 引言

传统的铁塔电费结算方案一般先由电力公司对电费进行托收，铁塔公司账户垫付，由铁塔公司分别向各运营商提供涉及的电费数据。各运营商根据推送的电表信息、用电数据以及不同分摊比例，计算分摊金额进行线下人工对账，确认无误后付款。最后，铁塔公司收回垫付电费并核销汇总，完成一轮周期的回款。传统方案面临的问题主要有：

（1）业财分离，缺乏有效管理；

（2）结算频次参差不齐，收、支确认时间长，造成回款周期长；

（3）信息共享率低，各方维护的数据不一致；

（4）存在信任问题，数据的准确性无法确定；

（5）关联往来核对困难，全流程缺乏闭环管理，审计风险大。

日益扩大的电表规模，以及电费结算过程中的复杂性，无疑大大增加了电费结算的管理难度[1]。

针对以上问题，本文提出并实现了一种基于联盟链的铁塔电费结算管理系统。通过构建铁塔公司和运营商间的电费结算联盟链，将铁塔和电表基本信息、用电原始信息、用电分摊比例和电费缴纳流水等数据通过智能合约上链，并在链上计算各方的分摊金额。各运营商和铁塔公司共同管理、维护区块数据，且每方都拥有完整的账本副本，实现数据和结算流程的透明。电费结算周期更灵活，发起方和付款方进行投票确认后，即可进入到结算环节。而当结算存在异议时，查询各自账本进行历史流程溯源，验证对比，达到有据可依、有据可查。由此实现结算过程中数据的多方闭环管理，防篡改、可溯源，提升了结算的开放性、透明度和效率[2]。

2 基于联盟链的结算系统

2.1 系统总体架构

IaaS 层提供区块链网络和业务系统运行所需的云资源，通过Docker 容器化技术提供微服务。

区块链模块提供底层区块链服务，包括分布式账本、共识排序、智能合约、点对点通信和背书策略。

（1）组织、节点管理：负责添加组织、添加节点、节点加入移出。

（2）成员管理：成员身份注册和身份认证。

（3）通道管理：主要功能包括通道创建、加入通道、通道信息查看和网络加入。

（4）智能合约管理：智能合约开发、部署及升级。

根据1997年《刑法》第416条第2款的规定，阻碍解救被拐卖、绑架妇女儿童罪在客观方面表现为:负有解救职责的国家机关工作人员利用职务阻碍解救被拐卖、绑架的妇女、儿童。在司法实践中，就本罪客观方面的认定而言，应当注意把握以下两个方面的问题:

（5）链上数据管理：数据上链、数据查询、索引删除和历史流程溯源等。

业务系统模块功能：

（1）系统管理：组织内部的用户、角色及权限管理。

（2）基础信息管理：负责站址、电表、固定比例和分摊比例等基础信息维护。

（3）投票确认：数据上链时需发起投票并由参与方确认，以满足背书策略。

（4）异常告警：配置预警模版，比较历史用电和各个电表的结算均值，进行异常告警。

前台展示功能分为管理界面和区块链浏览器，管理界面为用户操作窗口，区块链浏览器提供区块链网络的可视化界面，展示区块高度、交易数量和交易频次等信息。

2.2 链上链下联动处理模式

采用链上链下联动模式进行数据交互，减少上链的开销，如图2 所示。将电表、电费和结算等需要供多方查询、修改（以追加的形式）、共享的数据上链，这些数据贯穿了结算流程的起始、过程与结尾，需要对真实性进行背书，其他数据链下存储。将电费的分摊金额进行链上计算，而数据异常分析等复杂业务逻辑放在链下处理，精简合约代码和计算量，聚焦关键验证逻辑。对于发票流水等文件存储，直接将文件上链意义不大。将具体文件存储在文件服务器，计算文件的数字指纹，结合文件的URI 地址、持有人及签名信息一起上链。验证文件的真实性时，携带身份信息访问URI 地址，下载文件后重新计算数字指纹，对比验证即可[3]。

3 实验与测试

3.1 环境配置

4 台Linux 虚拟机，每台配置为操作系统为CentOS 7、CPU 16核、内存32GB、数据盘500GB、带宽100Mbps。区块链引擎采用Hyperledger Fabric[4]，提供底层区块链服务。采用Docker 容器化方式部署，复用虚拟机资源。其中排序节点3 个，铁塔节点2 个，电信节点2 个，CA 中心2 个，系统前后台服务各1 个。性能测试工具采用Jmeter。

3.2 数据上链速度测试

Fabric 上链测试的数据类型、共识算法、出块时间、出块交易数、背书策略、采用的状态数据库和通信加密方式，分别设置为Key/Value 形式、Etcd-raft、2 秒、10 个、电信和铁塔节点同时背书、CouchDB 和单向通信加密。

分别用样本数量10、25、50、75、100 对数据上链进行多次多并发测试，TPS 依次为65.6±2.9、111.2±3.5、137.5±4.1、145.3±5.2和144.9±6.3。由实验数据得知，系统在50 并发量时上链性能已接近饱和。并发量小于50 时，TPS 随着并发量提高。并发量大于50 时，如图3 为并发量100 时的走势图，TPS 基本维持在140 水平。

3.3 链上查询速度测试

测试查询速度设置与上链相同，分别用样本数量10、25、50、75、100 对数据上链进行多次多并发测试，TPS 依次为488.6±2.1、528.2±3.0、538.3±3.4、545.3±4.2 和544.9±4.6。分析数据可知，系统在25 并发量时，查询性能已接近峰值。查询操作占用的开销小，速度快。如图4 所示，链上查询TPS 的波动比数据上链TPS 的波动小，更稳定。

3.4 链改前后周期估算

对链改前后的结算周期进行估算：改进前，线下对账5～7 天、报账受结算周期影响7～15 天、数据缺乏闭环管理审批核销3～5 天，总回款时间约为15～27 天。改进后，线上对账2～3 天、报账周期分批灵活5～7 天，账本数据共享一致审批核销2～3 天，总回款时间约9～13 天。链改后方案缩短结算周期近1 倍，降低人工成本的同时，使整个结算流程闭环可控，加快回款。