可信区块链联盟链平台架构由上层应用由桌面客户端、移动客户端、浏览器客户API组成。用户主要由API 将业务数据接入到系统。该平台架构底层是基于Hyperledger Fabric V1.0.0架构构建的。该底层架构主要由接入网关、区块链应用两大部分功能组成，接入网关包含了注册、认证、授权、监控、审计五大功能，区块链应用则主要由链上程序、区块链管理、可拨插共识模块三大模块组成。可信区块链联盟链平台架构如图所示。

链上程序主要包括智能合约、图灵完备高级语言、合约容器/虚拟机。Hyperledger Fabric的智能合约smart contract称为链码chaincode，是一段代码，它处理网络成员所同意的业务逻辑。和以太坊相比，Hyperledger Fabric链码和底层账本是分开的，升级链码时并不需要迁移账本数据到新链码当中，真正实现了逻辑与数据的分离。链码可采用Go、Java、Node.js语言编写。链码被编译成一个独立的应用程序，fabric用Docker容器来运行chaincode，里面的base镜像都是经过签名验证的安全镜像，包括OS层和开发chaincode的语言、runtime和SDK层。一旦chaincode容器被启动，它就会通过gRPC与启动这个chaincode的Peer节点连接。

区块链管理主要包括账户管理、区块链管理、区块校验、交易校验。Hyperledger Fabric是目前为止在设计上最贴近联盟链思想的区块链。联盟链考虑到商业应用对安全、隐私、监管、审计、性能的需求，提高准入门槛，成员必须被许可才能加入网络。Fabric成员管理服务为整个区块链网络提供身份管理、隐私、保密和可审计的服务。成员管理服务通过公钥基础设施PKI和去中心化共识机制使得非许可的区块链变成许可制的区块链。可拨插共识模块，Hyperledger Fabric使用建立在HTTP/2上的P2P协议来管理分布式账本。采取可插拔的方式来根据具体需求来设置共识协议，比如PBFT，Raft，PoW和PoS等。

1. 超级账本联盟链区块链网络的创建

超级账本联盟链区块链网络的创建主要包括客户端节点创建、Peer节点创建、排序服务节点创建及CA证书节点创建。

客户端节点的创建：客户端是用户和应用跟区块链网络打交道的桥梁。客户端主要包括两大职能：

1）操作Fabric网络：包括更新网络配置、启停节点等；

2）操作运行在网络中的链码：包括安装、实例化、发起交易调用链码等。

Peer节点的创建：Peer意味着在网络中负责接受交易请求、维护一致账本的各个fabric-peer实例。这些实例可能运行在裸机、虚拟机甚至容器中。节点之间彼此通过gRPC消息进行通信。按照功能角色划分，Peer可以包括三种类型：

1）Endorser（背书节点）：负责对来自客户端的交易提案进行检查和背书；

2）Committer（确认节点）：负责检查交易请求，执行交易并维护区块链和账本结  构；

3）Submitter（提交节点）：负责接收交易，转发给排序者，目前未单独出现。

排序服务节点的创建：负责对所收到的交易在网络中进行全局排序。Orderer主要提供了Broadcast（srv ab.AtomicBroadcast_BroadcastServer） error和Deliver（srvab.AtomicBroadcast_DeliverServer） error两个接口。前者代表客户端将数据（交易）发给Orderer，后者代表从Orderer获取到排序后构造的区块结构。客户端可以使用atomicBroadcastClient结构访问这两个接口。

CA证书节点的创建：负责网络中所有证书的管理（分发、撤销等），实现标准的PKI架构。主要代码在单独的fabric-ca项目中。CA在签发证书后，自身不参与到网络中的交易过程。

2. 身份管理功能

在Gossip网络中，每个节点都有超级账本网络认可的MSP（Membership Service Provider）颁发的证书（身份，Indentity），从证书计算哈希值导出（目前的实现是直接用Endpoint转换而来的）的一个标识符称为节点的PKI-ID。

超级账本的Peer节点组成了一个P2P的网络，客户端SDK(Go、Java、Python、Node. js等不同语言)会提交请求给Per节点，Peer节点处理后会提交交易提案（TransactionProposal）给背书节点（Endorser），然后进行背书签名（Endorsement），最后经过排序服务达成共识后广播给Peer节点。

身份管理模块管理节点标识符和证书之前的映射，在内部维护了以PKI-ID为键、证书为值的映射表pkiID2Cert，可以通过PKI‑ID获取节点的证书，也可以更新节点的证书。同时还内置了MCS（MessageCryptoService）模块，它可以对消息进行签名和验证。更新节点证书的时候也会通过MCS模块验证证书是否有效，检查从证书导出的标识符是否和PKI-ID匹配。

在生成环境中，假设所有节点都是双向TLS部署的，TLS连接的双方都有一个有效的TLS证书。当节点和对端节点第一次连接时，会有一个握手协议，这个协议验证它是否拥有TLS证书的私钥，因而在TLS会话中绑定成员身份。握手是相互的，过程比较简单，握手节点主动发送给对端点一条ConnEstablish消息，包含的内容有：

节点TLS证书的哈希值。

节点的PKI-ID。

MSP身份证书。

3. 账本管理功能

在Fabric中，账本（Ledger）是一个有序的、防篡改的全交易记录的区块哈希链，它被ordering service构造，记录了所有的成功和不成功的状态更新交易。在1.0的版本中每个信道（channel）在orderer上都存储了一个独立的账本，信道中的每个参与节点（peer）都存储了一份该账本的拷贝。同时账本提供了SQL形式的查询功能，以便进行高效的对账和争议解决。

因为账本是建立在信道的基础上，并通过链码（chaincode）对其进行操作或修改，这就产生了两种方式：第一种是账本可以在整个网络中共享（可以理解为整个网络是一个特殊的公共信道），第二种是账本可以私有化，只包括一组特定的参与者。在后一种方式中，这些参与者将创建一个单独的信道，从而分离其交易事务（transactions）和账本。为了解决透明度和隐私的冲突，链码只会被安装在拥有读写权限的参与节点上，换句话说如果没有合适的链码支持，参与节点将无法与账本进行正确数据的对接。更进一步在混淆数据，链码中操作的键值可以在被追加到账本之前使用像AES这样的算法进行全部或选择性的加密。

4. 交易管理

区块链客户端把交易请求发给之前约定好的所有背书节点（endorsing peer）。这里说明一下endorsing peer的选择是有一定范围的，并不是在所有的endorsing peer里随意选择，是由交易所属的ChainCode和该Chaincode所定义的Endorsement Policy共同决定的。

背书节点收到上述信息后，首先用Client的公钥验证它的签名，背书节点执行智能合约（是模拟交易，不会写到账本里），将执行的结果反馈给客户端。

客户端搜集“足够”多的背书节点的结果后，就说明这个交易通过了Endorsement阶段。通过之后就打包发给共识节点（orderers）。其中“足够”的数量是多少，取决于背书策略Endorsement Policy是如果规定的，相反如果Client没有搜集到足够多的信息的话，这个交易就会被废止掉。Client可以选择重新发起交易。

共识阶段虽然有不同的算法，不过目的都是把有效的交易加入新生成的区块，并通知所有节点使他们账本保存一致。共识节点将结果广播所有的节点（peer）。然后各节点再更新自己账本。

5. 链码生命周期管理

链码提供了4个管理链码生命周期的命令，分别是链码的打包、安装、实例化、升级。在以后的版本中，还可能提供链码的停止和启动命令，在不删除链码的情况下可以停止和启动链码。链码在安装和实例化以后，就处于激活的状态，应用程序或者命令就可以调用和触发智能合约的功能了。链码安装以后随时都是可以升级的。

链码的打包

链码的内容主要包括以下3个部分：

1）链码源码，但需要通过ChaincodeDeploymentSpec或CDS定义。CDS依据代码及其  他一些属性来定义链码。

2）实例化策略。

3）链码的签名。

链码的安装

链码安装的时候会把链码的源码到前面已经介绍过的结构Chaincode DeploymentSpec中，安装到需要运行链码的Peer节点上。链码安装是针对节点的，每次安装只对单个节点有效。需要给每个要运行链码的背书节点都安装一遍，具体需要安装到哪些节点，可以根据背书策略来选择。

从安全角度考虑，链码应该只需要安装在需要执行的背书节点上，可以保护链码的逻辑被未授权的节点获取到。没有安装链码的节点是不能执行链码的智能合约的，但是可以验证链上的交易并且提交到本地账户中。

链码的实例化

链码的实例化会调用链码生命周期系统链码（LSCC）在通道上创建和初始化链码。链码在实例化之前是和通道无关的，实例化的时候才和通道绑定。链码可以和多个通道绑定，在通道上初始化后记录到通道的状态数据库中。同一个链码在不同通道上的数据是隔离的。

链码实例化的时候会检查是否符合链码实例化的策略和通道的写入策略。实例化的策略验证过程是检查实例化交易的签名是否符合策略的规则，验证通过才会写入到账本和状态数据中。通道的写入策略是在创建通道时指定的，这也是从安全角度考虑的，避免未授权的用户部署链码和调用链码。默认的实例化策略是通道的任何一个管理员，所以链码的实例化交易提交者必须也是通道的管理员链码的实例化会指定链码的背书策略，用来确定通道上哪些节点执行的交易才能添加到账本中。
链码的升级

链码安装以后是随时于可以升级的，链码的名称需要保持不变，必须要更新的是链码的版本，其他的部分，比如链码的所有者和实例化策略都是可选的。链码的版本是用字符串表示的，并没有指定比较版本大小的规则，是以更新的先后顺序为准的，具体的操作方法线下自行确定。

同样，升级之前还需要把链码安装到对应的背书节点上。链码的升级和实例化是类似的操作，也是绑定链码到通道上，执行初始化的操作。链码升级只会影响到指定的通道没有绑定链码新版本的通道还是继续旧的版本。同一个背书节点上，不同通道绑定的链码可能是不同的版本，所以升级的时候不会主动删除旧的版本。

链码升级的时候同样会检查实例化策略，采用的是通道上链码最新版本的实例化策略检查通过以后才会更新为链码新版本指定的实例化策略。

链码的停止和启动

链码的停止与启动功能还没实现，只能手动删除链码的容器和镜像，再删除背书节点本地保存的链码。

6. 通道的管理

Hyperledger Fabric 通道是两个或多个特定网络成员之间的通信的私有“子网”，用于进行需要数据保密的交易。channel由成员（组织）、每个成员的锚点、共享账本，链码应用程序和order服务节点定义。网络上的每个transaction都在一个channel上执行，每个通信方必须经过身份验证并授权在该channel上进行交易。加入channel的每个peer都具有由成员服务提供商（MSP）给出的自己的身份。

要创建新的channel，客户端SDK会调用configuration system chaincode和引用属性，如锚点和成员（组织）。该请求为channel ledger创建一个genesis block，它存储有关channel策略，成员和锚点的配置信息。当将新成员添加到现有channel时，这个genesis block或最近被重新配置的块将会分享给新成员。

channel中每个成员的leading peer的选举决定了哪个peer代表成员与ordering service进行通信。如果没有指定leader，则可以使用算法来指定leader。共识服务将交易排序并以一个block的形式发送给一个leader，然后leader将其分发给其成员 peer，并用gossip 协议进行跨channel通信。

虽然任何一个锚点可以属于多个信道，并且因此维护多个账本，但没有账本数据可以从一个channel传递到另一个channel。ledger按channel分隔，由configuration chaincode，identity membership service和gossip数据传播协议来定义和实现。被隔离的数据包括交易信息，账本状态和channel成员资料，这些数据仅限于在channel上具有可验证成员资格的peer间传播。通过信道隔离peer和账本数据，允许需要私有和机密事务的网络成员与同一个块链网络上的业务竞争对手和其他受限制的成员共存。

7. Docker管理链码

链码运行在与承认对等体进程隔离的安全Docker容器中。Chaincode通过应用程序提交的交易来初始化和管理分类帐状态。链码通常处理网络成员所同意的业务逻辑，因此可被视为“智能合同”。 由链码创建的状态仅限于该链码，不能被另一个链码直接访问。 然而，在同一个网络中，给定适当的权限，链码可以调用另一个链码来访问其状态。Docker管理链码，确保智能合约的安全执行环境，同时也确保安全的执行过程与用户数据的隔离。Docker提供了安全的沙箱环境和镜像文件仓库。

8. 超级账本联盟链共识服务

超级账本中把共识分为交易背书、交易排序和交易验证3个阶段。

1）交易背书

应用程序根据背书策略的要求选择背书节点，给这些节点发送需要执行的交易提案（Proposal）。背书节点调用链码（Chaincode）执行这些交易提案,交易过程是执行是模拟执行的，并不真正提交数据到账本中。执行完成以后调用交易背书系统链码ESCC对模拟执行结果进行签名背书。

2）交易排序

排序阶段接受已经签名背书的交易，确定交易的顺序和数量，将排好序的交易打包到区块中，广播给Peer节点进行验证。通常，从效率方面考虑，排序服务不会输出单个交易作为一个区块，而是把多个交易打包成一个区块。

3）交易验证

Peer节点验证接收到区块里包含的交易的有效性，包括背书策略验证及双花检测（double-spending）。可以将验证错误分为两大类:语法错误和逻辑错误。语法错误包括无效输入、未验证的签名以及重复的交易（双花攻击），重复的交易应该丢弃。第二类错误比较复杂，比如会导致双花或者MVCC失败的交易，这需要定义策略来决定程序是继续执行还是终止。策略还可以定义是否需要记录日志以便对这类交易进行审计。交易验证依赖链码的业务逻辑，目前默认的交易验证系统链码ⅤSCC只支持背书策略的验证。

9. Kafka的排序服务

基于Kafka的排序服务利用Kafka作为交易的消息队列，实现高吞吐量的数据分发每个通道都对应Kafka的一个主题（topic），排序服务节点在不同阶段充当不同的角色。

1）接收交易阶段：排序服务节点充当的是Kafka的生产者（producer），接收到交易后

通过权限检查转发给对应通道的主题。

2）消息处理阶段：排序服务节点充当的是Kafka的消费者（consumer），实时监听消息进行后续的处理，生成区块或者交易分割消息等。

10. 超级账本联盟链数据区块的构建                   

联盟链数据区块主要包括状态数据和账本数据两大模块，其中账本数据主要包含交易数据及构建的区块信息数据。

状态（state）

区块链的最新状态被建模为一个版本化的键值存储（KVS），键是名字，值是任意二进制大对象（blobs）。这些键值对被运行在区块链上的链码（应用程序）通过put和getKVS操作来操纵。状态被持久化存储并且状态的更新被记录为日志。请注意状态模型采用的是版本化的KVS，具体实现可以使用实际的KVS存储，但是也可以用关系数据库系统或其他的解决方案。

状态由对等点维护，而不是order节点和客户端。状态分区。KVS中的键可以从它们链码的名字识别，在这个意义上，只有一个特定链码的交易可以修改属于这个链码的键。原则上，任何链码都可以读取属于其他链码的键。为了支持跨链码交易，修改属于两个或更多个链码的状态作为一个V1后的功能点。

账本

账本提供一份可验证历史信息，记录所有在系统操作中发生的成功的状态改变（即有效交易）和未成功的对改变状态的尝试（即无效交易）。账本由排序服务构建为一个完整排序的交易（有效的和无效的）区块的哈希链。哈希链强制要求账本中的区块是完全排序的并且每个区块内包含的交易是完全排序的。

账本存储在所有的对等点里，也可以选择保存在一部分排序者里。存在排序者节点内的账本我们叫排序者的账本（OedererLedger），而存在对等点的账本我们叫对等点账本（PeerLedger）。对等点账本与排序者账本不同之处在于对等点账本本地维护一个比特掩码来区分有效交易和无效交易。

对等点可以修订对等点账本。排序者维护排序者账本用于容错和（对等点账本的）可用性并可以随时决定修订对等点账本，前提是排序服务的属性保持不变。账本允许对等点重播所有交易的历史来重构状态。因此，状态是一个可选的数据结构。

可信联盟区块链产品系统系统应用领域如图所示。