面向负荷聚合商的智能合约微服务架构设计及实现

2022-11-14张靖琛于鹤洋周自强马骏超耿光超江全元

电力系统自动化 2022年21期

张靖琛，于鹤洋，周自强，2，马骏超，耿光超，江全元

（1. 浙江大学电气工程学院，浙江省杭州市 310007；2. 浙江华云清洁能源有限公司，浙江省杭州市 310008；3. 国网浙江省电力有限公司电力科学研究院，浙江省杭州市 310014）

0 引言

建设新型电力系统需要发挥需求响应（demand response，DR）的作用，让负荷参与系统调度。居民负荷总量较大，但单体可控负荷功率较小，在系统中分散存在，各自工作具有随机性，无法直接被系统调用。因此，客观上需要通过负荷聚合商（load aggregator，LA）利用聚合技术将规模庞大的用户侧可控负荷整合为一个或多个运行方式灵活的聚合体参与电网调度。

LA 的聚合控制可能经由开放信息网络实现，例如以硬件资源虚拟化为基础的云平台、与边缘计算结合的分布式异步通信网络以及开放多变的互联网环境。在相对开放的网络环境下，聚合优化将产生海量信息，数据存储、验证、查询的效率和安全性成为应用落地的关键所在，中心化的数据存储和管理模式难以满足需求。而区块链技术的不可篡改性、可追溯性、隐私保护性等特点为解决以上问题提供了新的思路［1］。

在能源区块链领域，为解决应用需求和系统性能之间的矛盾，已经进行了一些研究。文献［2-3］中针对自动需求响应业务需求，分析区块链的应用模式，但缺少模拟和验证。文献［4］提出储能系统基于区块链技术的自动需求响应方法，但未考虑在实际区块链系统上的运行效果。文献［5］提出多级投标的安全信息传递机制，在合约层和协议层进行分析，但未考虑系统规模扩展的影响。文献［6-8］提出基于区块链技术的分布式能源交易应用模式，减小交易风险、提高交易效率。文献［9］提出适用于大用户直购电的区块链框架来降低成本。文献［10-11］研究微电网博弈模型及信用共识机制，实现高效安全管理。文献［12］评估基于区块链的点对点能源交易性能，并分析不同底层区块链性能。文献［13］提出在微网中基于区块链的能源和碳配额交易模式。文献［14］提出基于自适应区块链技术的微电网能源交易方案。文献［15］提出在电力市场中灵活管理区块链加密货币的方法。文献［16］提出基于多代理联盟和区块链的主动配电网分布式电力交易系统架构，基于Java 环境模拟验证电力交易过程。

然而，以上研究缺少针对智能合约可扩展性问题、智能合约熔断导致的雪崩问题、合约漏洞问题的解决方案。除此之外，传统区块链平台的吞吐量不能完全满足LA 参与DR 的需求。

针对能源区块链平台的性能问题，已有部分相关研究。文献［17］对能源区块链底层技术进行重构，以适应电力系统凸优化的应用需求。文献［18-19］提出基于跨链技术的异构安全交易模型。文献［20］在跨链技术的基础上设计高能耗用户参与的调频模型。文献［21］提出双链架构的区块链点对点交易策略。

然而，针对能源区块链底层技术的改进考虑了区块链节点的可扩展性以及数据交互和存储的可扩展性，未考虑智能合约逻辑的可扩展性。除此之外，底层改进需要在系统构建初期进行统筹规划，在智能合约部署后调整难度极大，易造成类似以太坊公链的硬分叉。而LA 业务需求不断变化，初期建设难以完全兼顾后续发展需求。因此，智能合约设计架构需要长期具备可扩展性，合约迭代及漏洞修复不影响已部署的智能合约功能。

在联盟链中，将参与DR 的各主体抽象为联盟参与对象，单个对象可以部署多个物理节点，单个节点对应存储区块信息的设备，主要包括需求响应前端设备（边际节点）和后台部署区块链平台的设备（云端节点）。联盟链交易速度由共识算法决定，为适应大规模需求响应的应用要求，共识算法必须使系统具备高每秒事务处理量（transaction per second，TPS）、节点动态增删以及账本动态数据自动恢复等特性。本文选择RBFT（robust Byzantine fault tolerance）算法，该共识算法在中国浙江省某需求响应系统中应用，基本满足应用需求。此外，合约层链码调用需要消耗计算和存储资源，为防止分布式拒绝服务攻击造成的资源恶意消耗，合约中需要设置计算资源消耗上限。传统单体架构中过度耦合的链码不利于后期维护，而面向LA 的DR 项目体系复杂，虚拟机中过多计算资源消耗易造成合约熔断。

基于以上背景，为提高LA 在业务调整时智能合约可扩展性和重用性，降低运维成本，本文提出了面向LA 的智能合约微服务架构设计方法及具体实现过程，搭建了智能合约中继层（smart contract relay layer，SCRL），提出了基于单一性原则的智能合约领域分解方法，设计了面向LA 的智能合约微服务松耦合部署模式。采用去中心化联盟链平台Hyperchain 进行模拟仿真，验证提出架构的有效性及优越性。

1 区块链底层平台

区块链作为集成技术，其底层技术已经趋于成熟。在“区块链1.0”阶段，即“可编程货币”阶段，比特币是最成功的应用之一。在“区块链2.0”阶段，即“可编程金融”阶段，以太坊异军突起，推出基于区块链的智能合约开发平台。在“区块链3.0”阶段，区块链的防篡改、可匿名、去中心化等编程思想和算法被抽离与改进，从而与物联网、能源互联网、金融等社会生活的各个领域进行融合。在当前阶段，区块链的技术特性包括：去中心化、不可篡改、可追溯性、共享性、隐私保护性和高度自治［22］。传统智能合约开发平台主要包括以太坊和Hyperledger，但这些平台由于性能限制主要适用于非实时、轻量级、低吞吐、信息敏感度低的场景［17］。LA 参与DR 涉及精确到秒级的实时响应、海量数据存储、高吞吐量交易验证以及高敏感度隐私信息交互。因此，本文采用Hyperchain 作为仿真平台，多节点协同处理及数据验证过程见附录A 图A1。平台提供的负载均衡器和懒加载数据结构介绍见附录B，平台架构见附录B 图B1，智能合约引擎性能对比见附录B 表B1［23］，平台引入Oracle 预言机机制，可以进行联盟链与需求响应前端设备交互，由于本文主要关注智能合约的架构设计，未对该过程进行详细介绍和分析。

2 面向LA 的智能合约微服务架构总体设计方案

LA 参与DR 的传统智能合约单体垂直架构主要问题在于功能过于集中，不易开发、扩展和维护，易导致智能合约雪崩击穿，原理见附录A 图A2。系统性能扩展依赖于扩展集群节点，基于跨链技术设计多链结构，改进共识算法或提高硬件性能。根据LA 业务需求，一方面要求智能合约部署后能在满足触发条件时自动执行；另一方面要求LA 业务升级、漏洞修复或系统扩容时，可以对已有合约进行重用，对已部署的、存在漏洞的智能合约禁止外部访问，同时不影响其他智能合约的运行。

本文提出面向LA 的智能合约微服务架构，其最大特点是智能合约可重用、扩展灵活、松耦合，架构关键技术模块如图1 所示。在智能合约簇（smart contract cluster，SCC）与外部请求之间，智能合约微服务架构增加智能合约中继层实现隔离封装。将LA 业务模块由多个SCC 进行管理，智能合约内部属性及方法可以被重用和重写。增加的智能合约可以独立部署，与其他合约簇的运行保持隔离，多SCC 交互通过SCRL 协调，同时已经部署的SCC 在出现内部漏洞隐患或外部适应性问题需停止运行时，由SCRL 调用平台接口，实现合约状态封存和合约状态恢复。智能合约中数据存储单元通过注解和反射机制将合约中数据变量在进行序列化或反序列化后与分布式账本进行交互，联盟链节点之间通过特定端口进行双向数据交互。

图1 智能合约微服务架构的关键技术模块Fig.1 Key technical modules of smart contract micro-service architecture

2.1 智能合约中继层

本文所提架构与传统单体垂直架构不同之处在于，所有节点对于智能合约的外部调用均需要通过本文提出的智能合约中继层（smart contract relay layer，SCRL）实现隔离封装。

SCRL 是从外部扩展SCC 逻辑的耦合层，基于反射原理，利用外部注入的方式动态获取SCC 内部属性和方法，实现多合约簇协同共享管理，具体原理如图2 所示，通过SCRL 与SCC 分层解耦，拥有联盟链证书的各个节点通过账户的公钥对数据进行加密，通过私钥对数据进行解密，利用链账户以及所持有证书向SCRL 发起请求以及接收返回值，SCRL中按照链账户和证书所具有的权限，将节点请求封装成交易体，通过事务管理模块获取历史数据（包括交易体信息以及签名摘要）。对于数据的上链以及合约状态管理，通过调用合约管理模块中的接口，将交易体通过事务注入的方式输入SCC，由SCC 通过序列化与反序列化的方式进行数据的格式转化，最终与联盟链平台实现数据交互，上链信息的共识验证由共识节点完成。

图2 SCRL、SCC 与Hyperchain 交互示意图Fig.2 Schematic diagram of interaction between SCRL,SCC and Hyperchain

针对LA 参与DR 时的高并发问题，通过SCRL整合负载均衡模块，防止网络阻塞。针对LA 各SCC 内部智能合约熔断对参与DR 所带来的响应失效风险，本文利用SCRL 与SCC 分层解耦，利用SCRL 统一处理智能合约的异常事件，减小熔断风险，提高SCC 与分布式账本交互效率。针对单体架构中智能合约部署后无法对内部漏洞进行安全屏蔽的问题，SCRL 基于反射原理，对运行中存在漏洞的SCC 进行状态封存，实现松耦合部署。

2.2 基于单一性原则的智能合约领域分解

单一性原则指的是根据业务逻辑将智能合约拆分为功能相对独立的多个合约，将单合约中消耗虚拟机计算资源较多的执行语句拆分成多个基本独立的保持事务原子性的模块或合约函数，这种分解的方法和策略本文称之为单一性原则。根据单一性原则，LA 参与DR 中的业务模块被拆分为3 个子服务：投标子服务、负荷聚合子服务以及补贴结算子服务。每个子服务的智能合约函数按照单一性原则被分为4 类：供给型、消费型、封闭型以及双向型合约函数。供给型合约函数只向链上传输数据而无返回值；消费型合约函数只向链上请求获取返回值而不输入数据；封闭型合约函数既不输入数据也不返回数据，只对链上已经存储的数据进行逻辑运算和验证；双向型合约函数既注入数据又获取返回值。单一性原则需要各个合约彼此之间不直接调用，各个函数之间功能独立，彼此的交互以及多级调用依赖于SCRL。

智能合约领域分解本质是对LA 业务模块做精细化拆分，减少合约冗余性，降低合约耦合度，提高智能合约可重用性。智能合约领域分解遵循单一性原则，LA 业务拆分力求彻底组件化和原子化。单个子服务以独立形式存在于底层区块链网络的系统进程中，独立打包部署后通过合约地址进行外部调用。子服务对消耗虚拟机计算资源过多的指令进行SCC 内部分解，针对LA 中复杂优化问题，通过SCRL 进行安全外部调用，与SCC 保持解耦，避免外部优化算法对智能合约一致性及可靠性产生影响。

2.3 智能合约微服务架构松耦合部署模式

在对LA 服务拆分的基础上，本文提出智能合约微服务架构松耦合部署模式。部署规则为：LA每个业务模块由一个SCC 来管理，新增智能合约服务可以独立部署，与其他合约簇运行保持隔离，多SCC 交互通过SCRL 协调，已经部署的SCC 在出现内部漏洞隐患或外部适应性问题需要停止运行时，由SCRL 调用平台提供的接口，实现对SCC 状态封存，在进行模块调整后可恢复合约状态。SCRL 调用平台提供的冻结和解冻技术模块可以实现对已部署SCC 内部漏洞的安全处理，基本原理见图3。其中，账户和交易体主要构成要素在图中标注，联盟链平台返回数据以密文形式传递，SCC 状态由交易体中智能合约状态标志位进行管理。状态管理数据通过虚拟机与分布式账本交互。

图3 SCC 状态管理示意图Fig.3 Schematic diagram of SCC state management

SCC 间耦合程度很低，操作保持原子性，当LA业务调整，则在原先SCC 基础上按照模式迭代增加成员属性或成员方法，未改变的SCC 保持不变，重新编译构建压缩包后通过合约账户签名构建新交易体，获取压缩包序列化之后的输入流，通过对新压缩包的序列化注入实现重新部署。在此过程中，不需要对底层区块链结构做任何改变，也不需要对已经启动的SCC 做任何修改，SCC 管理的数据在新交易体验证过程中由自动同步实现固化。

3 面向LA 的智能合约微服务架构应用案例

本章以LA 聚合空调负荷为例，介绍智能合约微服务架构的应用方法，详细阐述智能合约编写以及部署过程。虽然只以空调负荷为例，但不仅限于空调等温控负荷，智能合约微服务架构对LA 参与DR 的区块链项目构建具有通用性。LA 参与DR 基本业务模块包含投标子服务、负荷聚合子服务、补贴结算子服务，下文中详细介绍实施细节。

3.1 LA 参与DR 的智能合约实现方法

3.1.1 投标子服务

LA 参加DR，首先依据对自身响应能力评估及报量报价策略进行投标，投标内容既保持半透明以确保过程公平，又保持密封性保证投标阶段信息不会泄露，使数据整体保持“可用而不可见”的状态。在投标结束后的出清阶段，SCC 必须高效进行队列排序和信息发布。领域分解形成的SCC 在内部通过多级依赖分配独立属性来存储不同时段的投标队列信息。

投标开始时，由每个LA 独立生成投标量，并通过链账户进行签名后利用SCRL 实现对SCC 调用，为验证边际注入是否成功，可以轮询获得布尔返回值，投标函数属于双向型函数。投标过程中投标量不对任何账户公开。投标结束后，按容量优先价格优先的基本原则以及去中心化的管理模式完成出清。SCC 出清算法可以设定为内部触发，在投标结束后自动出清，也可以设定为外部触发，由用户构建外部交易体进行账户签名，经过SCRL 向SCC 注入。LA、调度中心及终端用户没有访问数据明文权限，但可以通过外部注入方式执行出清算法，不同用户可以多次注入来比较出清结果，保证过程公平，出清函数为供给型函数。运算过程由SCC 在虚拟机沙箱中完成，而交易体构建及外部注入由用户完成，数据使用权限由SCC 确定，任何用户无权更改。

3.1.2 负荷聚合子服务

负荷聚合过程依赖外部优化求解器为被聚合的小微负荷间建立信任纽带，提升参加聚合的积极性，应既保证信息公开，又确保隐私保护。为确保实际运行不会发生雪崩击穿和网络阻塞，本文通过SCRL 分层耦合的方式，既保持SCC 内部资源的最小化占用，又保持对外部求解器的安全调用。

LA 在日前调用集群优化控制算法计算终端用户可控设备的响应能力曲线，根据响应时间和响应功率，生成控制指令，经由底层点对点（P2P）网络实现信息播送。终端负荷数据涉及用户隐私。因此，LA 需要有全局的数据使用权限，但是不能进行数据明文访问，所调用的负荷数据操作函数为封闭型函数。终端用户有权限跟踪自身负荷变动情况并具有通过SCRL 进行解码的权限，所调用的查询函数为消费型函数。

对终端负荷设备进行基于角色的数据访问权限隔离和隐私脱敏。响应能力评估结果封装在SCC列表中，对LA 外部注入的交易体，SCC 设置提取数据的操作权限，但在SCRL 中禁止进行数据解码，直接传递到优化控制算法中计算，不对外暴露明文访问接口，评估函数属于封闭型函数。LA 可以操作数据流传递，但不能获取明文。终端负荷可以在日前提交是否接受托管的意愿，在LA 参与DR 时通过SCRL 获取自身信息，但不能干扰LA 对数据的后续操作。所有数据访问和操作都需要链账户签名，最终在联盟链中形成交易体，而SCC 执行过程以哈希值的形式封装在交易体内部。

对于定频空调这一类的可中断温控负荷，其等效热参数模型为［24］：

式中：Tt和Tt+1分别为t时刻和t+1 时刻的室内温度；Pair为空调机组制热或制冷功率，单位为kW；ηair为空调能效比；ε为散热系数（室内温度改变的惯性系数）；A为导热系数；T0，t+1为t+1 时刻室外温度；xair，t为t时刻空调开启状态，xair，t=1 时，空调处于开启状态，xair，t=0 时，空调处于关闭状态。

以冬季空调负荷为例，为保证用户舒适度，在t时段，室内温度变化范围为：

式中：Tmax和Tmin分别为空调温度设置上、下限。

又因空调功率会在一定范围内波动，其运行功率约束为：

式中：Pair，min和Pair，max分别为空调运行功率的下限和上限。

按日前所有削峰时段LA 总收益最大构建目标函数：

式中：f为LA 在响应日的总收益；r1，j为j时段LA 从电网侧获得的补贴收益；r2，j为j时段LA 支付给所有用户的补贴支出；r3，j为j时段LA 所有用户的电费支出；P1为j时段第i户家庭可控负荷功率；Na为LA所管理的家庭总数；N为响应日内响应时段总数；c1，j为j时段电网侧响应补贴单价；c2，j为j时段LA 对用户的响应补贴单价；c3，j为j时段电费单价；xi，j为j时段第i户家庭可控负荷的开关状态，xi，j=1 时处于开启状态，xi，j=0 时处于关闭状态。

3.1.3 补贴结算子服务

式中：R为单个LA 发放补贴总额；Rc为根据合约规定削减容量来发放的补贴数额；Re为根据实际削减电量来发放的补贴数额，Re计算方法按照LA 履约程度进行阶梯式结算，与合约容量偏差越大，获得补贴数额越少。

Rc计算公式为：

式中：Cm为每个LA 每月在SCC 中输入的目标容量；P为SCC 规定的补贴单价；K为折算系数，该系数按照LA 当月无效响应次数占参与响应次数的比例进行计算。

第2 阶段是LA 对终端负荷的补贴结算。终端负荷的结算方式按照内部基线进行“两部制”补贴。通过构建两阶段SCC 结算模型，终端用户和LA 都具有对结算流程进行溯源的数据操作权限，在基线计算和实际负荷响应率的判定环节可以进行外部注入，每次验证过程都在分布式账本生成交易体，记录发起者链账户地址、被调用SCC 账户地址以及具体操作内容生成的摘要。

3.2 联盟链节点配置及部署方式

在联盟链中，将参与DR 的各主体抽象为联盟参与对象，单个对象可以部署多个物理节点，单个物理节点对应于存储区块信息的单台电脑或者服务器。任何新区块产生及交易验证，在联盟内所有节点中同步广播。联盟链节点分为共识节点和非共识节点。共识节点参与共识机制，对联盟决策拥有决策投票权。非共识节点与共识节点保持信息同步，可以对外提供数据访问权限，但不参与共识算法。

DR 市场主体包括具有监管作用的调度中心、终端负荷以及LA。对于节点配置遵循证书准入原则。调度中心持有根证书，具有签发各类证书的权限。LA 持有节点准入证书，成为共识节点。对于终端负荷应持有客户端准入证书，用于证明终端负荷的合法性。若一个终端负荷需要连接多个节点，则该终端负荷连接每个节点都需要一个客户端准入证书。服务器集群为实现资源的高效利用已基本实现基于容器的虚拟化资源管理，形成专属的云计算集群，LA 参与DR 过程中不同主体持有证书证明自身合法身份，Hyperchain 服务部署在四节点集群，对SCC 的部署和调用请求在客户端通过SCRL 执行，这样可以避免占用过多资源，也能让不具备服务器硬件设备的主体参与联盟链。

本文采用Java 作为编程语言，为实现SCC 的轻量级部署，需要对每一个SCC 项目制作压缩包，压缩包内部包含资源文件和字节码文件。压缩包中的文件经过编译和压缩，最终实现轻量级部署，并且具有良好的可移植性。SCC 部署通过合约账户对压缩包进行序列化处理，为输入流后加密形成交易体，并返回合约地址，SCRL 通过合约地址进行调用。

4 面向LA 的智能合约微服务架构性能模拟测试

4.1 系统数据

为验证本文提出的面向LA 的智能合约微服务架构有效性及优越性，以浙江杭州某大厦（LA1）及某智慧公寓（LA2）为例，分析架构扩展灵活性、安全性以及SCC 执行效率。采用4 台戴尔PowerEdge R740 2U 机架式服务器搭建分布式集群，操作系统采用CentOS7，内存96 GB，处理器采用英特尔至强金牌5220R，部署Hyperchain 版本1.8，使用轻量级liteSDK。模拟场景为LA1、LA2 参与削峰需求响应，LA1 包含18 间宿舍，LA2 包含10 间宿舍，参与主动聚合的终端温控负荷为定频空调。早峰为09：00—11：00，午峰为15：00—17：00，晚峰为18：00—20：00。

4.2 响应效果分析

1）响应能力评估

20世纪60年代，美国空军飞行力学实验室开发了气动数据库DATCOM，其包罗了从1903年第一架飞机开始直到1978年中止数据库更新的几乎全部美国飞机的飞行试验数据[1,2]。虽然DATCOM在面对一些特殊布局如飞翼式布局时，分析起来比较困难，在面对超级复杂的超常规布局时更是无法使用，但这是人类第一次将数据库技术应用到飞机数据管理中。

日前LA1、LA2 在投标前进行响应能力评估。生成第2 天的聚合功率曲线，投标结束前对响应能力曲线在SCC 中进行密封，密封前的聚合功率数据见附录A 图A3。在SCRL 中对响应能力曲线进行密封生成交易体，见附录A 表A1。

2）投标

针对响应能力评估曲线，LA1、LA2 分别独立进行投标量发布，利用SCRL 调用SCC 进行队列出清，并经由底层P2P 网络进行广播，节点间通过传输层安全协议来保证通信安全，公布各时段LA1 和LA2 的削峰指标。

投标阶段每个LA 通过链账户在SCRL 外部注入投标量，数据访问权限设置由账户签名决定。链账户由不同的加密算法生成，由平台提供的账户生成加密算法主要有：SMRAW、SMAES、SMDES、SMSM4、ECRAW、ECDES、ECAES 等（均为国密算法或国际标准算法）。参与DR 各主体可以拥有多个链账户，链账户的私钥由用户保管，使用多种加密算法可以增加从外部破解的难度，对SCRL 进行外部请求时用户通过提交完整账户信息实现注入和签名。国密算法SMSM4 加密生成的账户完整信息见附录A 表A2。

以上加密算法经过大量安全性检验，一般情况下密钥长度越长安全性相对越高。在SCC 出清之前，可以通过判断轮询返回值是否为零确定当前是否成功完成投标，但不能对投标量进行明文解码。在出清结束之后，可以通过SCRL 进行虚拟机中的返回值字节码转换，最终获取投标量明文信息。

3）聚合响应

LA1、LA2 收到广播的削峰指标，在日内由SCRL 向SCC 注入各自实际响应能力，由SCC 自动核准并进行修正。LA2 宿舍温度变化过程见附录A图A4。在SCRL 外部调用基于Gurobi 优化工具包的聚合优化算法，设定百分比误差为0.01，多次调用时间统计结果见附录A 图A5，SCRL 外部调用聚合算法与直接利用求解器相比，执行速度相差较小，可以确保安全高效。

4）补贴结算

补贴结算由SCC 执行，为保证资金流动的安全性以及事务执行的原子性，将交易切割为3 个“元操作”，包含链账户资金外部注入、链账户资金提取，链账户资金点对点转移。多次交易元操作的执行速度测试结果见图4，图中统计了发送交易体进行数据预处理并进行共识验证的时间以及通过轮询与分布式账本进行合约执行结果查询的时间。

图4 SCC 交易效率分析Fig.4 Analysis of SCC transaction efficiency

4.3 微服务部署模式的扩展性分析

智能合约单体垂直架构无法根据合约内部漏洞或逻辑扩展对已部署合约进行调整，本文模拟LA聚合服务SCC 内部执行非转账交易出现异常，通过合约冻结和解冻，在SCRL 中调整中继码，重新部署运行中抛出异常的SCC，SCC 全流程执行结果见表1。表中，1 表示对应交易可以执行，0 表示不能执行。由此可见LA 在SCRL 中可以灵活调整SCC 执行情况，有利于SCC 后期维护。

表1 智能合约冻结、解冻中的链码执行情况Table 1 Chaincode execution in freeze and unfreeze of smart contracts

4.4 微服务架构的稳定性测试

LA 参与的联盟链中，运行SCC 依赖于共识节点，通过分析共识节点宕机对SCC 性能影响进行智能合约微服务架构稳定性分析。本文通过模拟外部攻击导致单共识节点宕机，比较宕机前后LA 通过智能合约进行投标的效率，具体执行时间见图5。在宕机前后分别进行100 组模拟测试，只在第1 次测试由于节点连接失败造成轮询时间过长，其余测试中由于利用SCRL 自动调整轮询服务器队列，将后续轮询时间维持在稳定水平，证明本文所提架构在确保扩展性的同时保证了稳定性。

图5 单节点宕机时间对SCC 稳定性影响分析Fig.5 Analysis of impact of single-node downtime on SCC stability

4.5 效率分析

本文采用针对“元交易”的测试方法，对原子性交易进行测试，分析不同数据结构对SCC 运行效率的影响。以投标量注入为例，通过模拟多LA 同时进行SCRL 外部注入，SCC 中是否使用懒加载数据结构的性能差异见附录A 图A6。可以看出懒加载数据结构的数据处理效率高于传统数据结构，在第30 轮测试中由于队列元素持续增长，使用传统数据结构的SCC 抛出异常，而使用懒加载数据结构的SCC 正常执行。因此，对于LA 参与DR 中的大数据插入读取应该优先使用懒加载技术的数据结构与账本进行交互。交易过程中系统区块延时及区块交易体数量统计分析分别见附录A 图A7 及图A8。随着用户请求数增加，区块包含交易体数量平均值从10增加到50，最高TPS 从6 532 增加到33 231，性能可以满足实际应用需求。