前言

毕业Case的项目主要基于公链，且没有面向企业的应用场景，之前对其的了解大多仅停留在权限管理机制、通道、灵活的智能合约编写等几个特色概念上，对其架构、各个节点的角色、运行机制等都只是一知半解。最近正在修读HKU的课程，教授针对工作原理、网络搭建以及链码相关知识，给出了极为详尽的阐释，自己收获良多，借由本文进行一番梳理，要是存在错漏之处，欢迎沟通指正。

概述

要学习 ，先来看看它的母项目是什么。

企业级应用存在较为复杂的业务逻辑，有着参与者角色划分，对业务执行效率要求很高，对安全性要求也很高，并且针对常见场景比如支付、数据/信息交易等，隐私保护也是非常重要的，所以，常见的比特币、以太坊等公链不符合大部分企业应用的需求。区块链具有分布式、不可篡改的历史账本等特性，这些特性在溯源、跨境电商等场景中，能够避免因各个国家/地区法律法规、货币等造成的复杂操作流程，可大大提高效率。因此，针对企业的联盟链也在不断发展。

联盟链严格意义上并非真正的“去中心化”，它引入了权限管理机制，该机制结合企业在现实业务中的角色，弱化了对节点作恶的预防机制，进而能提高效率，还能应对复杂的业务逻辑。

它是一组开源项目，由基金会维护，专注于跨行业分布式技术，旨在创建企业级、开源、分布式的分类框架和代码库以支持业务用例，提供中立、开放和社区驱动的基础设施，建立技术社区并推广，开发区块链和共享账本概念验证、使用案例、试验和部署，建立行业标准，鼓励更多企业参与到分布式账本技术的建设和应用中，形成开放的生态体系，教育公众关于区块链科技的市场机会。

设计理念

有如下几个核心设计理念：

它能提升企业具体业务场景的效率，在溯源等场景有独特优势，每个企业可针对自身场景维护独立项目，所以，它不像公链那样需通过数字货币激励用户参与区块链系统 。企业的应用场景复杂，通常只是参与了其中的某个或某些环节，所以与其他现有系统的交互是必不可少的，故而在设计上注重配备完整的 API 供其他系统调用与交互，其框架结构模块化、可拓展，企业能依据具体业务需求选择不同模块，避免复杂业务逻辑和臃肿系统。企业应用的安全性至关重要，特别是许多应用场景涉及高价值交易或敏感数据，所以提供了诸多机制保障安全性（比如通道机制等）。除了与现有系统交互，企业未来的区块链应用还可能与许多不同的区块链网络交互，因而大部分智能合约/应用应具备跨区块链网络的可移植性，从而形成更复杂且强大的网络。

框架

下面有如下几个项目，其中有一个项目目前应用最为广泛，本文也将主要介绍区块链网络。

它主要用于更方便地搭建和管理区块链服务，能降低项目框架部署、维护的复杂度，可用来搭建区块链BaaS平台，还能通过它创建和管理区块链，让技术人员更方便地进行开发和部署，并且可以将SaaS部署模型引入区块链系统，帮助企业进一步开发框架。它是一个可视化区块链的操作工具，能用来创建对用户友好的Web应用程序，它是首个区块链浏览器，用户能够查看交易信息，能够调用交易信息，能够部署交易信息，能够查询交易信息，还能查看网络信息，能调用网络信息，能部署网络信息，能查询网络信息，能查看智能合约信息，能调用智能合约信息，能部署智能合约信息，能查询智能合约信息，能查看存储信息，能调用存储信息，能部署存储信息，能查询存储信息。

我们着重来讲讲其中应用最为广泛的项目，它是一个模块化、可拓展的区块链联盟链项目，由基金会进行维护，不依赖任何加密货币，它为有着共同目标（业务需求）但彼此不完全信息的实体之间的业务提供保护，比如跨境电商、资金交易、溯源等。

架构

在大部分公链当中，其架构是这样的。就拿比特币区块链来说，要是出现一个新交易，首先会运用PoW机制对其进行排序，接着比特币网络里的每个节点会逐个展开验证，最终更新状态。由于要依照顺序进行验证，所以这种方式致使其执行效率比较低。

而采用了 - - - 架构。

收到一笔新交易，首先将其提交至背书节点，在本地模拟交易执行，并且进行背书，接着把已背书交易排序，然后进行广播，各个节点对交易进行验证，之后更新状态。

正如上述联盟链特性中所讲，网络的加入要获得许可，也就是进行身份验证，网络里的每个节点都有自身的身份。

总的来说，采用模块化、可插拔的架构来支撑企业的复杂业务场景，借助身份验证（绑定现实身份）来削弱节点作恶，运用通道机制极大地提高了系统的安全性和隐私保护。

MSP 成员服务提供商

那么，参与网络的身份是怎样管理的呢？

有一个成员管理提供商，它主要用于管理CA证书，以验证哪些成员是可信任的。CA模块是独立的，它能够管理证书服务，还能允许第三方CA接入，这大大拓展了系统的应用范围。

如上图所示，CA 提供了客户端、SDK 这两种与 CA 交互的方式，每个 CA 都有一个根 CA 或者中间 CA，为进一步提高 CA 的安全性，可采用集群搭建中间 CA。

更具体地去看CA的层级体系，通常采用的是根CA、业务CA和用户CA三层树结构，所有下层CA会继承上层CA的信任体系，根CA用于签发业务CA，业务CA用于签发具体的用户CA，比如身份认证CA、交易签名、安全通讯CA等

通道

上文提到利用通道机制保障交易安全与隐私性，本质上每个通道都是一个独立账本，还是一个独立区块链，有不同的世界状态，网络中的一个节点能够同时加入多个通道，这种机制能很好划分不同业务场景，且不用担心交易信息泄露问题。

链码

也有类似以太坊的智能合约，它被称为链码，智能合约能让外部的应用程序与网络中的账本进行交互。它不同于其他，使用某种方式而不是特定的虚拟机来存放链码，这种方式提供了一个安全、轻便的语言执行环境。

链码主要分为系统链码和用户链码这两种类型，系统链码嵌入于系统内部，能够提供对系统进行配置以及管理的支持，用户链码运行在单独的容器里，可为上层应用提供支持，用户借助与链码相关的 API 编写用户链码，进而能够对账本中的状态执行更新操作。

链码安装后可被调用，安装时要指定具体安装到哪个Peer节点，有的节点可不安装链码，实例化时还需指定通道及背书策略。

链码之间也可以相互调用，从而创建更灵活的应用逻辑。

共识机制

中广义的共识机制涵盖三个环节，分别是背书，排序，验证，狭义的共识指的是排序。

在区块链网络里，不同参与者之间进行交易，这些交易必须依照发生的顺序，被记录到分布式账本中，这一过程依赖共识机制，而共识机制主要有三种：

网络协议

那网络中各个节点的状态分发又是怎么进行的呢？

外界的客户端借助gRPC对网络里的各个节点展开远程调用，P2P网络里各个节点之间的同步依靠协议来实现。

协议主要用于网络中多个节点之间的数据交换，它比较容易实现，并且容错率很高，其原理是，数据发送一方从网络中随机选取若干个节点发送数据，等几个节点接收到这些数据后，再随机发送给除发送方外的若干节点，不断重复这个过程，最终所有节点达成一致，其复杂度为LogN 。

分布式账本

最终，所有交易都会被记录到分布式账本中，这是区块链诸多特性的核心。交易能够存储相关业务信息，区块是一组排列后的交易集合，把区块通过密码算法链接起来便是区块链。分布式账本主要记录世界状态，这是最新的分布式账本状态，通常使用它便于查询。它还记录事务日志，事务日志是世界状态的更新历史，记录着区块链结构并被使用。对账本的每个操作都会记录在日志中，且不可篡改。

应用编程接口

对于基于的应用，主要提供了两种交互方式，一种是SDK开发工具包，另一种是CLI命令行。

区块链核心角色

首先要提及的是，网络中的角色都是逻辑角色，举例来说，Peer节点A有可能是排序节点，在某些业务中，它也有可能是背书节点，并且，一个角色并非仅由单一节点担任。

接下来介绍一下各个角色的作用和职能。

客户端主要负责给交易签名，之后提交交易给背书节点，接着接收已经背书后的交易并广播给排序节点；背书节点会在本地模拟执行交易，以此验证交易（策略由其制定），随后签名并返回已背书交易；排序节点会将交易打包，然后广播至各个节点，该节点不参与交易的执行和验证，多个排序节点能够组成OSN；所有的节点都对区块链账本进行维护。

优势总结

将企业应用的各个复杂环节分配到各个逻辑角色节点，比如背书、排序等，这样一来，不需要所有节点都承担像排序这种资源消耗较大的操作，进而消除了网络瓶颈，分配角色后，某些交易只在特定节点部署和执行，并且能够并发执行，这大大提升了效率和安全性，还隐藏了一些商业逻辑，所以，可以依据不同业务需要形成多种灵活的分配方案，极大增强了系统的拓展性。

把共识机制设置为可插拔，把权限管理设置为可插拔，把加密机制设置为可插拔，把账本等模块设置为可插拔，不同的链码可以设置不同的背书策略，信任机制更加灵活，如此便能根据业务需要设置自己的高效系统。

成员身份管理的CA是单独的项目，它能提供更多功能，还能与许多第三方CA直接进行接入和交互，其功能更强大，适合企业复杂的场景。

多通道具有这样的特性，不同通道之间的数据是彼此隔离的，这提高了安全性，也提高了隐私保护 。

链码支持不同的编程语言，例如Java、Go、Node等，它更加灵活，还支持更多第三方拓展应用，能够降低业务迁移成本，也能降低业务维护成本。

应用开发及交互

上图展示的内容，是关于一个区块链开发者，在应用区块链时的开发流程，以及与之相关的交互流程 。

开发者主要负责开发应用，开发者还负责开发智能合约（链码），应用借助SDK与智能合约进行交互，智能合约的逻辑能够对账本进行get操作，智能合约的逻辑还能对账本进行put等操作。

工作流程

接下来通过一个完整的交易流来梳理一下网络的工作原理

在所有操作之前，需要向 CA 获取合法身份，并且指定通道。首先，提交交易（含自己的签名）至背书节点。背书节点接收到交易后，用本地状态模拟执行，对交易进行背书、签名并返回（其中包含 Read - Set、签名等）。收集到足够的背书后（策略由制定，如图中示例为得到 2 个背书），提交已背书交易至排序节点（OSN）。排序节点将交易打包，排序（不执行或验证交易正确性）并广播至所有节点。所有节点对新进行验证并提交至账本。

接下来对每个环节进行一些详细的拆解

执行/背书环节

提交交易之后，背书节点会首先核对签名，通过本地状态模拟执行，对交易进行签名以及Read - Set回滚，R - W Sets主要包含key、、三个属性，Read - Set包含交易执行中读取的所有变量及其值，对账本进行写操作会产生变化， - Set包含所有被编辑的变量及其新值。

背书节点在执行交易时，会依据本地区块链的状态，检查链码是否正确，然后执行并返回。

支持多种背书策略，在提交至排序节点前会进行验证，看是否满足背书要求，值得注意的是，若只做了查询账本操作，便不会提交至OSN。

上文提到的交易，主要包含链码，还包含链码的输入值，以及签名，而背书节点返回的信息，包括返回值，包括模拟执行结果的R-W Set，还包括背书节点的签名，组合起来就是已背书节点。

背书是相关组织对交易的认可，意味着相关节点要对交易进行签名。对于链码交易而言，背书策略是在链码实例化时指定的。一笔有效交易必须经背书策略相关组织签名才能生效。本质上，区块链中的交易验证基于对背书节点的信任。这也是称其并非严格意义上去中心化的原因之一 。

以下是一个简单的链码执行示例

在这个简单示例中，链码的主要操作是更新key-值，进行这个操作后，会发生变化。

执行后返回的 R-W Set 为

key: 1 其Json形式为，值为产品，产品名称是“Test Product”，描述是“Just a test product to make sure chaincode is running”，创建者是“admin”，产品ID是“1” 。

排序环节

提交已背书交易至排序节点，排序节点可通过一些共识策略组成 OSN，排序节点接收到交易后，会将其打包，按照配置中的规则进行排序，在此过程中，只执行排序操作，不进行任何执行或验证，排序完成后发送至所有节点。

排序服务可对全网交易达成一致，它只负责让交易顺序达成一致，如此便避免了整个网络出现瓶颈，还更容易进行横向拓展来提升网络效率，目前它支持两种方式，区块链网络的统一与完整性依赖于排序节点的一致性 。

Raft共识机制属于非拜占庭共识机制，它采用领导者和跟随者模型，当选出一个领导者后，日志信息会从领导者向跟随者单向复制，这种方式更容易管理，在设计上允许所有节点都能成为跟随者节点，相较于其他机制它更中心化，实际上它也允许采用PBFT共识机制，不过其性能往往较差。

验证环节

当节点接收到排序节点发送来的区块，它会对区块中的所有交易进行验证，标记这些交易是否可信。主要验证两个方面，一方面是是否满足背书策略，另一方面是交易结构的合法性，是否存在状态冲突，比如 Read-Set 中的是否一致等 。

总结

以上就是对架构进行梳理的内容了，尽管舍弃了部分去中心化的理念，不过作为一个面向企业应用的开源联盟链，它激励了更多企业投身于分布式账本技术的建设与应用当中，当下国内存在许多联盟链的自研平台，像蚂蚁链、趣链等，相信未来会有更多企业加入到这个开放的生态体系！

参考资料, Au，HKU，张应平