联盟链SChain 架构设计方法*
2023-12-28赵小峰廖思捷安红章董贵山
唐 晋，赵小峰，廖思捷，白 健，安红章，董贵山
（中国电子科技集团公司第三十研究所，四川 成都 610041）
0 引 言
区块链技术作为数字时代的新型基础设施[1]，在数据共享交易[2]、分布式身份管理[3]、供应链金融[4]等领域具有重大应用潜力。2021 年12 月22 日，中央网信办等部门发布了《关于国家区块链创新应用试点入选名单的公示》[5]，共开展涉及17 个领域175 个试点项目，为区块链技术在各行业的广泛落地应用发挥了良好的示范作用。
但是，目前区块链产业应用的发展仍是“各自为战”，区块链孤岛现象严重，并未将区块链共识连通的价值发挥出来，导致区块链技术在应用中发挥的作用极为有限，更多的仅限于数据信息存证。并且，由于区块链技术架构过于复杂，用户对区块链架构了解不足，改造及接入存在一定成本，大部分应用对于区块链的使用仍停留在“炒概念”的阶段。因此，区块链技术的研究者和从业者需要对区块链架构体系进行深入分析讨论，在对区块链架构形成共识的基础上，为用户进行区块链技术普及，降低区块链架构对于应用的改造接入成本，充分发挥区块链共识连通价值，让区块链技术不再是“锦上添花”，而是“雪中送炭”。
本文主要对现有的联盟链技术架构进行分析， 包括Ethereum2.0（ 公链）、Hyperledger Fabric、Fisco Bcos，对其技术架构、工作原理、部署方式、优劣势等进行总结，提出了一种新型联盟链架构设计方法，为联盟链技术架构提供了一种新的发展思路。
1 基础介绍
1.1 不可能三角问题
以太坊（Ethereum）创始人Vitalik Buterin在2017 年提出了区块链领域的不可能三角问题（Scalability Trilemma）[6]，指一个区块链系统无法同时满足可扩展性（Scalability）、安全性（Security）和去中心化（Decentralization）这3 个特性。
（1）可扩展性：系统支持共识节点扩展，同时具有交易高速处理能力；
（2）安全性：系统具有高安全性，特别是账本不可篡改；
（3）去中心化：系统不依赖中心化的实体或者控制点。
该问题一经提出，便在区块链论坛和社区中引起了广泛的讨论，而所有的研究均是在特定应用场景需求下去解决该问题，其中最典型的就是联盟链的技术架构设计。
1.2 联盟链
联盟链由于必须符合监管审计的需求，因此能够对参与的角色进行限制，主要包括：
（1）参与共识节点权限限制：参与共识节点必须是合法合规机构，且共识过程必须通过签名进行身份校验；
（2）参与交易权限限制：参与交易的用户必须进行实名认证；
（3）联盟链运营主体限制：联盟链运营主体必须向国家监管机构进行备案登记。
上述限制降低了不可能三角问题中的去中心化特点，因此，通过采用实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT） 类共识算法，使联盟链相较于公链具有极高的处理性能[7-8]。
2 开源联盟链架构设计
2.1 Ethereum2.0
2.1.1 Ethereum2.0 系统架构
以太坊Ethereum 是首个带区块链智能合约的公链区块链架构，由于同样面临性能、安全性、分布式的压力，本文将对其进行重点介绍。为了进一步提高以太坊网络的扩展性、安全性和服务性能，以太坊发布了2.0 网络架构[9]，如图1 所示。
图1 Ethereum2.0 网络架构
从功能角度来看，主要包括信标链和分片链两个部分：
（1）信标链（Beacon Chain）：主要负责管理整个以太坊网络的交易验证和共识，仅处理验证者的验证权益和行为，主要包含验证者在分片链上负责验证交易和更新分片状态；
（2）分片链（Shard Chains）：主要负责普通交易共识，且每个分片链都拥有独立的状态、交易和智能合约，底层数据也存储在不同链上，每个分片链拥有一个独立的状态根（State Root），由该分片链上的所有状态值计算所得。
从参与的节点来看，主要包括信标链验证器和分片链验证器两个部分。
（1）信标链验证器：通过质押32 个以太币参与信标链共识，运行信标节点软件，负责生成随机数和处理跨分片交易等；
（2）分片链验证器：通过质押一定数量的以太币（根据分片链总体质押数量）参与分片链共识，主要负责特定分片链的交易验证和区块创建。
从链的角色角度来看，主要包括验证者、合约部署者和交易用户3 个部分。
（1）验证者：通过质押以太币参与信标链、分片链共识，获取收益，由交易地址代表的独立实体；
（2）合约部署者：编写智能合约，并将其部署在分片链上运行，其在合约中的权限可由其进行自定义，由交易地址代表的独立实体；
（3）交易用户：发起业务交易的用户，由交易地址代表的独立实体。
2.1.2 Ethereum2.0 核心流程
Ethereum2.0 主要采用权益证明（Proof of Stake，PoS）共识算法，用于管理Beacon Chain和Shard Chains 之间的验证和共识，其核心是验证者，验证者参与网络共识需要抵押一定数量的以太币，并通过“出块”获取奖励，主要的共识流程如图2 所示。
图2 Ethereum2.0 核心流程
（1）验证者选择：通过抵押一定的以太坊（Ethereum，ETH）便可以获得验证者身份，可以选择参与Beacon Chain 或者Shard Chains 中的多个链。
（2）随机选举：每个验证周期，验证者通过提交随机数，基于这些随机数生成一个新的随机数，通过该随机数确定哪些验证者被选中参与出块和交易验证，验证者被选中的概率和抵押ETH 的数量成正比。
（3）打包出块：验证者通过出块来获得奖励，出块的过程是验证者在Shard Chains 上验证交易，并将验证的结果汇总到Beacon Chain 上，生成新的区块。每个Shard Chains 上的出块间隔时间是独立的。
（4）验证者投票：验证者需要定期检查其他验证者是否有恶意行为，如果发现，则必须对其进行投票，将其罢免。投票的目的是确保网络的安全性和完整性。
（5）奖励和惩罚：验证者通过出块和参与网络验证来获得奖励，同时，如果发现验证者有恶意行为或者未能参与网络验证，则会受到惩罚。
2.1.3 Ethereum2.0 特点分析
（1）在可扩展性方面：Ethereum 的验证器可以通过质押以太币的方式进行无限扩展，任何拥有以太币的人员均可以参与其中，该可扩展性是目前最好的。
（2）在管理安全性方面：Ethereum 的用户角色比较单一，通过地址可以直接与验证者、用户进行身份关联绑定，管理安全性最高。
（3）在执行性能方面：Ethereum 目前的交易处理速度仅有每秒20～30 笔，按照2.0 的设计规划有可能提升1 000 倍，可能达到10 000+TPS 的处理速度，作为一个公有链的基础设施，该处理速度是目前最快的。
（4）在易用性方面：Ethereum 节点结构简单，同时也存在大量的第三方辅助的开源软件，对于节点运营方和用户的易用度均是极佳的。
2.2 Hyperledger Fabric
2.2.1 Hyperledger Fabric 网络架构
超级账本（Hyperledger Fabric）是一个开源的联盟链框架，其由Linux 基金会于2015 年发起，早期主要由IBM 公司的研发人员设计研发。其网络架构图如图3 所示。
图3 Hyperledger Fabric 网络架构
从参与角色的角度来看，主要包括背书节点、排序节点和客户端组件3 个部分。
（1）背书节点（Endorser Peer）：主要负责接收客户端交易，执行智能合约，对交易进行背书签名，同时负责接收排序节点交易区块，对交易状态进行确认更新，记录账本（背书节点可以通过配置只承担背书或者确认功能）；
（2）排序节点（Order Peer）：主要负责接收背书后的客户端交易，将交易进行排序、打包、出块，并维护系统链，对链的身份进行统一管理；
（3）客户端组件（Client）：主要负责通过应用程序编程接口（Application Programming Interface，API）或软件开发工具包（Software Development Kit，SDK）与超级账本进行交互，发起链上交易提交或查询请求，同时收集交易背书结果，发起排序请求。
从链的功能角度来看，主要包括系统链和业务链两个部分。
（1）系统链：主要负责区块链系统组织、创世块、共识策略的统一管理，在整个区块链系统中只存在一条；
（2）业务链（通道）：主要负责具体的业务交易记账，在整个区块链系统中可存在多条。
从链的角色角度来看，主要通过签发证书进行管理，包括组织、链管理者、节点和用户4 个部分。
（1）组织：负责节点、接入用户的统一身份管理，是由自签证书代表的独立实体；
（2）链管理者：负责一条业务链的创建、合约管理等，是由组织证书签发的实体；
（3）节点：实际参与背书、排序的节点，归属组织管理，一个组织可同时拥有多个节点，如果一条业务链有一个组织的两个节点参与，在共识过程中只记一票，是由组织证书签发的实体；
（4）用户：实际业务交易发起方通过服务接口调用交易执行，是由组织证书签发的实体。
2.2.2 Hyperledger Fabric 核心流程
超级账本的核心流程如图4 所示，包括发起交易、交易背书、发起共识、排序出块、交易确认。
图4 Hyperledger Fabric 核心流程
（1）发起交易：由用户对交易进行签名，通过客户端组件向区块链系统发起交易。
（2）交易背书：由背书节点通过业务智能合约对交易数据进行验证，并对验证结果进行签名。
（3）发起共识：由用户通过客户端组件收集交易背书结果，并将收集到的背书结果发送至排序节点。
（4）排序出块：由排序节点对收集到的交易数据进行排序出块，并将区块推送至背书节点。
（5）交易确认：由背书节点根据收到的区块数据对交易进行确认验证，并更新世界状态，将区块进行记录。
2.2.3 Hyperledger Fabric 特点分析
（1）在可扩展性方面：Hyperledger Fabric通过组织签发证书的方式进行节点加入，但由于其背书节点和共识节点分离的设计，且背书节点通常直接和客户端进行通信，因此，背书节点的增加不会对性能产生影响。而排序节点的增加是否影响性能，要根据排序算法决定，可扩展性非常好。
（2）在管理安全性方面：Hyperledger Fabric通过组织签发证书的方式对组织节点、用户、链管理进行统一管理，且每个节点在安装智能合约时具有独立的授权管理机制，因此管理安全性非常好。
（3）在执行性能方面：Hyperledger Fabric目前测试性能在3 000 TPS 左右，在特殊场景和优化下可达到100 000 TPS[10]，但由于Hyperledger Fabric 的背书节点和排序节点分离的设计，在高并发、关联性交易测试过程中，由于在一个区块中如果同时出现对一个交易数据状态的读和写，便会出现status 11 错误，因此，在整体联盟链测试中性能表现一般。
（4）在易用性方面：Hyperledger Fabric 两层节点的设计，以及客户端需要与背书节点和排序节点进行交易交互，因此对于运维管理和用户接入的使用体验度不佳，整体易用度表现一般。
2.3 Fisco Bcos
2.3.1 Fisco Bcos 网络架构
Fisco Bcos[11]是由金链盟开源工作组打造的开源企业级金融联盟链底层平台，并于2017 年正式对外开源，早期主要由微众银行的研发人员负责主导。其网络架构如图5 所示。
图5 Fisco Bcos 网络架构
从节点分类的角度来看，主要包括节点、WeBASE 业务管理平台和业务链管理辅助系统3 个部分。
（1）节点：负责区块链系统智能合约的执行、共识、数据状态管理、账本存储、网络通信等主要核心功能，将会周期性地通过投票选举出Leader 节点，负责交易的打包和分发；
（2）WeBASE 业务管理平台：负责智能合约的全生命周期安全管理；
（3）业务链管理辅助系统：负责根据用户数据内容组装交易，并向节点发起交易共识或者查询请求。
从链的功能角度来看，Fisco Bcos 引入多群组架构，支持区块链节点启动多个群组，群组间交易处理、数据存储、区块共识相互独立，并通过网络准入和账本白名单实现各账本间的网络消息隔离。
从用户角色的角度来看，主要包括治理方、运维方、业务方和监管方4 个部分。
（1）治理方：拥有投票权，可以参与治理投票，可以增删节点、修改链配置、添加撤销运维、冻结解冻合约、对用户接入权限控制；
（2）运维方：由治理方添加运维账号，运维账号可以部署合约、创建表、管理合约版本、冻结解冻本账号部署的合约；
（3）业务方：业务方账号由运维方添加到某个合约，可以调用该合约读写接口；
（4）监管方：监管方监管链的运行，能够获取链运行中权限变更的记录和需要审计的数据。
2.3.2 Fisco Bcos 核心流程
Fisco Bcos 的核心流程如图6 所示，包括交易生成、交易广播、交易打包、交易执行、交易共识、交易记账。
图6 Fisco Bcos 核心流程
（1）交易生成：用户客户端负责根据业务组装交易数据，生成交易并签名，发送至共识节点。
（2）交易广播：共识节点验证交易签名及检查是否重复，验证无误后广播至其他节点。
（3）交易打包：共识Leader 节点从交易池中按照先进先出的顺序提取一定数量的交易，打包成块，提交各节点进行共识。
（4）交易执行：各节点收到区块后，调用智能合约对交易内容进行执行，将执行结果和状态封装到交易中，并返回Leader 节点。
（5）交易共识：Leader 节点在接收到2/3（PBFT 共识算法）的相同执行结果后，将带有结果的区块信息再反馈给其他节点。
（6）交易记账：其他节点收到区块结果，对签名结果进行校验，成功后将交易状态进行更新，并将区块记录存入账本。
2.3.3 Fisco Bcos 特点分析
（1）在可扩展性方面：Fisco Bcos 主要采用PBFT 等共识算法，因此节点扩展主要受限于共识算法，但同时其对广播通信算法进行了优化设计，因此其可扩展性表现较好。
（2）在管理安全性方面：Fisco Bcos 主要通过交易地址对节点身份和用户身份进行管理，但是由于其节点无法对智能合约进行独立管理，因此其管理安全性较好。
（3）在执行性能方面：Fisco Bcos 通过使用块内分片技术，单链性能达到5 000 TPS 以上，特殊场景和优化下可达到100 000 TPS，且不存在块交易内容不一致的问题，因此其交易性能表现非常好。
（4）在易用性方面：Fisco Bcos 共识体系较为简单，对于节点用户使用方便，同时客户端也不需要收集交易数据，且生态辅助软件丰富，因此易用度表现非常好。
3 一种新型联盟链架构SChain
3.1 系统架构
SChain 的系统架构主要包括共识节点和管理系统两个部分。
（1）共识节点：提供交易接入、智能合约验证、世界状态维护、账本确认等功能；
（2）管理系统：提供权限管理、共识节点管理、交易解析呈现等功能，可选择性部署，仅通过可视化的方式辅助管理，并不影响共识交易的执行。
如图7 所示，相关系统关系如下：①一个组织机构可以部署多个共识节点，管理系统代表组织机构对相关的共识节点进行统一管理；②一个共识节点可同时加入多个应用链进行交易共识操作；③各应用链直接沿用Hyperledger Fabric 通道的设计进行应用数据隔离。
3.2 业务流程
3.2.1 分层管理体系设计
SChain 的分层管理体系主要包括组织机构层和应用链层两个层面，如图8所示，详细介绍如下。
图8 SChain 分层管理
（1）组织机构层：包括组织机构和共识节点。组织机构负责签发节点证书，对节点的共识权限进行统一管理，节点证书是节点参与应用链共识的唯一凭证。共识节点负责交易收集、打包出块、交易验证、块共识、世界状态维护、账本存储等核心区块链服务，一个组织机构可按需存在多个共识节点。
（2）应用链层：包括应用链管理机构和应用链。应用管理员负责签发应用链管理证书、用户接入证书，应用链管理证书是对应用链智能合约进行管理的唯一凭证，用户接入证书是用户接入交易系统的唯一凭证。应用链运行在多个共识节点上，通过智能合约提供验证服务，并最终形成不可篡改的账本。
在上述分层管理体系中，管理的唯一手段便是证书。同时，为了进一步降低系统管理的复杂度，可以将组织机构和应用链管理机构的证书使用同一个根证书进行签发管理，即组织机构和应用链管理机构进行主体合并，这种设计不会降低系统安全性，但是参与一个应用链共识的不同组织机构不能使用相同根证书，原因在于：①如果共识具有容错性要求，应用链中使用相同组织机构证书签发的多个共识节点的验证结果只能被采信1 次，有可能导致无法达成共识；②如果所有共识证书全部由根证书签名，签发的根证书直接决定账本的安全，整个去中心化的系统将成为一个中心化系统。
3.2.2 共识选主设计
SChain选主流程参照Raft选主机制进行设计，每个节点共有3种状态，分别是：①领导者（Leader），负责打包出块；②跟随者（Follower），负责对区块进行验证投票；③候选人（Candidate），负责发起竞选Leader 的投票。SChain 共识选主设计如图9 所示。
图9 SChain 共识选主设计
SChain 通过设置任期（term），每个term内最多只有一个Leader，在算法中充当逻辑时钟的作用，节点之间通信会携带term，如果节点发现接收到数据的term 小于自己的term，则拒绝该消息；如果大于自己的term，则更新自己的term。相应的选主节点流程如下：
（1）增加本节点的term，切换至Candidate状态；
（2）给本节点投票，同时发送给其他节点进行投票；
（3）接收现有节点的投票反馈，如果收到大多数节点的选票，则切换至Leader 状态，并向其他节点发送声明消息，阻止新的Leader 选举；如果收到别人的投票请求，term 大于本节点，则切换至Follower，并投票；如果投票过程超时，则再次发起选举请求。
3.2.3 交易共识设计
SChain 交易共识流程通过在共识节点中选取Leader 节点，由Leader 节点进行交易打包及消息转发，同时，通过共识权限参数的配置，实现共识门限由1 到n的改变（n是参与共识的节点个数），如图10 所示。当共识门限为1 时，系统为同步系统，所有的共识验证均由Leader节点负责；当共识门限为n时，系统具有强容错性，任意节点的验证不通过均会导致共识失败，在具体的应用场景中，可根据实际的应用需求决定使用的门限。
图10 SChain 交易共识设计
（1）交易生成：用户客户端负责根据业务组装交易数据，生成交易并签名
（2）交易发送：共识节点通过验证交易签名及检查是否重复，验证无误后发送至Leader节点。
（3）交易打包：共识Leader 节点从交易池中按照先进先出的顺序提取一定数量的交易，打包成块(Blockid,{
（4）交易执行：各节点收到区块后，调用智能合约对交易内容进行执行，将执行结果和状态封装到交易中(Blockid,{
（5）交易共识：Leader 节点在接收到转发块之后，对块签名进行验证，在收到满足门限的签名区块后，将带有签名的区块信息打包后再反馈给其他节点。
（6）交易记账：其他节点收到区块结果，对签名结果进行校验，成功后将交易状态进行更新，并将区块记录存入账本。
3.2.4 系统扩展设计
SChain 的系统扩展主要包括组织扩展、应用链扩展、节点扩展、用户扩展4 个方面。
（1）组织扩展设计：组织扩展是指在联盟链中添加新的组织机构，方式是在联盟链中通过配置交易添加组织的自签根证书，完成组织节点添加，具体步骤如下：
①组织自签证书：生成公私钥对
②组装配置交易：生成配置交易
③配置交易共识：Leader 在收到配置交易后，单独打包成块(Blockid,{
④节点信息更新：各共识节点在交易出块后，完成相应的配置信息更新。
（2）应用链扩展设计：应用链扩展是指在联盟链中添加新的应用链，方式是通过创建创世块，下发至各共识节点，完成应用链创建，具体步骤如下：
①创世块创建：应用链管理者编制创世块(ChanelID,
②创世块签名：应用链管理者对创世块进行签名{(ChanelID,
③创世块加载：各共识节点接收到签名块后，验证签名，进行创世块加载；
④应用链启动：各共识节点根据创世块中
（3）节点扩展设计：节点扩展是指在联盟链中添加新的共识节点，主要通过组织对节点进行签名实现，具体步骤如下：
①证书签发：节点生成公私钥对
②节点启动：节点配置签发证书PCert，部署软件启动服务；
③合约部署：应用链下发合约部署命令，完成智能合约部署；
④数据同步：应用链按块(Blockid,{
⑤交易共识：完成块同步后，即可参与交易共识流程。
（4）用户扩展设计：用户扩展是指在联盟链中添加能发起交易的用户，主要通过组织对用户进行签名实现，具体步骤如下：
①证书签发：用户生成公私钥对
②发起交易：生成交易数据
③交易共识：按照交易共识流程对交易数据进行共识。
3.3 安全性分析
设定联盟链节点总数为N，设置共识门限为n，作恶节点数量为f。
（1）如果f≥n，由于f+n≤N，则n≤N/2，此时系统不具备容错性，仅为数据同步系统。
在共识过程中，如果f≥n，则会出现一种情况：系统少部分节点收到满足n要求的正确共识结果，大部分节点收到满足n要求的错误共识结果（均为作恶节点投出），一部分节点无法收到满足n要求的共识结果，导致系统最终分叉，无法统一。
（2）如果f
在共识过程中，当n>N/2 时，节点一定会收到n个正确的共识结果，不存在节点会收到n个错误共识结果的可能性，因此当n>N/2 时，系统便具备容错性。同时，并不一定所有系统节点都能够实时在线，因此容错节点的数量为f>vN-n。例如，当v=2/3 时，N为9，则同时在线节点数量为6，n设置为5，则容错数为1。
4 测试验证
以Hyperledger Fabric 代码为基础（核心的数据结构、通信协议、交互接口均参考Fabric代码），根据SChain 协议流程对其进行修改，并进行SChain 性能测试，具体测试环境配置如表1 所示。
表1 测试环境配置参数
虽然性能测试可达到10 000 TPS，但目前在工程上还未进行优化，具有较大的提升空间，测试结果如表2 所示。
表2 测试数据参数
5 特点分析
本文从可扩展性、管理安全性、执行性能、基础设施组网4 个角度对SChain 技术架构进行分析总结。
5.1 可扩展性
可扩展性的核心是共识算法，从联盟链的基本定位来说，联盟链本身不会设想拥有“无数”节点参与，但还是希望可以有更多的节点加入，SChain 以PBFT 的框架为主，同时通过融入Raft的消息同步转发机制，尽可能降低分布式各节点间点对点的消息广播，压缩网络带宽消耗，提升节点共识效率。
5.2 管理安全性
SChain 的管理安全性可归纳为两个层次：节点层（组织）、应用链层（应用和用户）。节点层可以配置组织证书、节点证书，对整个共识基础网络进行分布式的管理；应用链层通过配置管理证书实现整个应用链智能合约的全生命周期安全管理，同时通过对用户的实体身份进行鉴别，为用户颁发证书。
5.3 执行性能
目前，SChain 基本性能指标实测达到10 000 TPS，虽然部分联盟链声称测到100 000 TPS性能，但均是在特定硬件配置下和特定的测试条件下开展的，不具备实际应用参考价值，SChain 从架构角度更为简洁，具有较大的优化提升空间。
5.4 基础设施组网
SChain 通过管理系统的设置，为每个共识组织机构赋予独立的管理权限，且建立应用链可以跨接不同的管理系统，有助于实现基础设施组网。
6 结 语
本文对Ethereum2.0（公链）、Hyperledger Fabric、Fisco Bcos 等开源区块链服务平台的技术架构进行了分析，从可扩展性、管理安全性、执行性能、易用度等多个方面进行了对比，提出了一种新型联盟链架构设计方法。该方法在可扩展性、管理安全性、处理性能、基础设施组网方面均有较大的优势，后续作者将会在安全性分析、性能优化两个方面进行深入研究分析，为联盟链架构的统一奠定理论和技术基础。
