一.架构图

应用层:

• API：提供了GRPC，RPC框架
• SDK：在API基础上封装的SDK，go、java、python、nodejs
• 事件:分布式系统中，达成共识需要一定时间，fabric使用异步通信模式开发，触发回调函数执行
• 身份：依托于底层的成员服务，是联盟链的认证功能，例如CA
• 账本：区块链的查询数据，是账本中查出来的，区块高度+交易ID，不重复
• 交易： 对区块链数据进行修改，先提交交易到背书节点，签名认证之后再执行
• 智能合约：做合约的安装、实例化和升级

应用程序角度

( 1 )身份管理

用户注册和登录系统后，获取到用户注册证书( ECert)，其他所有的操作都需要与用户 证书关联的私钥进行签名，消息接收方首先会进行签名验证，才进行后续的消息处理 。 网 络节点同样会用到颁发的证书，比如系统启动和网络节点管理等都会对用户身份进行认证 和授权 。

( 2 )账本管理

授权的用户是可以查询账本数据( ledger)的，这可以通过多种方式查询，包括根据区 块号查询区块 、 根据区块哈希查询区块、根据交易号查询区块、根据交易号查询交易，还 可以根据通道名称获取查询到的区块链信息 。

( 3 )交易管理

账本数据只能通过交易执行才能更新，应用程序通过交易管理提交交易提案( Proposal) 并获取到交易背书( Endorsement)以后，再给排序服务节点提交交易，然后打包生成区块 。 SDK 提供接口，利用用户证书本地生成交易号，背书节点和记账节点都会校验是否存在重 复交易 。

(4 )智能合约

实现“可编程的账本”( Programmable Ledger)，通过链码执行提交的交易，实现基于区 块链的智能合约业务逻辑 。 只有智能合约才能更新账本数据，其他模块是不能直接修改状 态数据( World State)的 。

区块链底层:

• 成员服务：提供证书，用于加密和签名
• 共识服务：CAP（不能全满足，只能满足2个，一致性、可用性和分区容忍性），实际上区块链弱化了可用性和分区容忍性，所以需要共识算法保证一致性，fabric的共识大概分为3个阶段

1. 首先客户端向背书节点发送一个背书提案，背书节点进行交易模拟，将背书结果和签名返回给客户端
2. 然后将背书后的交易，交给排序节点进行排序，由排序节点生成区块，向全网广播，网络节点接收到广播后，先验证区块交易的正确性
3. 验证通过后，存入本地账本
4. PS：排序节点与组织的锚节点使用的是GRPC通信，组织内使用的是gossip协议通信

• 链码服务：提供安全的、可隔离的交易环境，所以fabric使用docker，链码直接与docker通信，目前阶段对k8s支持的不好，会出问题
• 安全及密码服务：fabric定义了一个BCCSP接口，定义签名、加密解密等功能，默认实现了一套国际通用的密码服务，如sha256等

( I )成员管理

MSP (Membership Service Provider)对成员管理进行了抽象，每个 MSP 都会建立一套 根信任证书( Root of Trust Certificate)体系，利用 PKI (Public Key Infrastructure)对成员 身份进行认证，验证成员用户提交请求的签名 。 结合 Fabric-CA 或者第 三方 CA 系统，提供 成员注册功能，并对成员身份证书进行管理，例如证书新增和撤销 。 注册的证书分为注册 证书( ECert)、 交易证书( TCert)和 TLS 证书( TLS Cert)，它们分别用于用户身份、交易签名和 TLS传输。

( 2 )共识服务

在分布式节点环境下，要实现同一个链上不同节点区块的一致性，同时要确保区块里 的交易有效和有序。 共识机制由 3个阶段完成:客户端向背书节点提交提案进行签名背书， 客户端将背书后的交易提交给排序服务节点进行交易排序，生成区块和排序服务，之后广 播给记账节点验证交易后写入本地账本 。 网络节点的 P2P 协议采用的是基于 Gossip 的数据 分发，以同一组织为传播范围来同步数据，提升网络传输的效率。

( 3 )链码服务

智能合约的实现依赖于安全的执行环境，确保安全的执行过程和用户数据的隔离 。 Hyperledger Fabric 采用 Docker 管理普通的链码，提供安全的沙箱环境和镜像文件仓库 。 其 好处是容易支持多种语 言 的链码，扩展性很好 。 Docker 的方案也有自身的问题，比如对环 境要求较高，占用资源较多，性能不高等，实现过程中也存在与 Kubernetes、 Rancher 等平 台的兼容性问题 。

( 4 )安全和密码服务

安全问题是企业级区块链关心的问题，尤其在关注国家安全的项目中 。 其中底层 的密码学支持尤其重要， Hyperledger Fabric 1.0专门定义了一个 BCCSP ( BlockChain Cryptographic Service Provider)，使其实现**生成、哈希运算、签名验签、加密解密等基 础功能 。 BCCSP 是一个抽象的接口，默认是软实现的国标算法，目前社区和较多的厂家都 在实现国密的算法和 HSM (Hardware Security Module)。

---

二.网络拓扑图

概念：

• 客户端节点：应用程序和底层的交互媒介，与上层和peer和orderer连接发挥作用，连接peer做交易模拟
• peer节点：包含了锚节点（主节点），在一个组织内可以有多个peer，一个组织中锚节点只有一个，锚节点作用（与orderer进行通信），锚节点需要HA支持，若锚节点挂了，组织内会选举新的节点与orderer节点进行通信，背书节点（Endorse）理解为担保，与智能合约绑定的，每一个智能合约安装到区块链中，会有一个专属的背书策略，记账节点（committer）所有的peer节点都是记账节点，用于验证从orderer接收到的区块，验证交易的有效性，验证通过后，同步到本地账本
• orderer节点：排序节点，接收全网客户端节点的交易信息，按照一定规则进行排序，将排序好的交易，按照固定的时间间隔打包成区块，与其他组织的主节点进行通信，排序可以用solo（整个网络中只有一个排序节点，使用于开发和测试）和kafka（生产环境下使用，分布式消息队列）模式
• CA节点：可选的，作用：颁发证书，只有被CA认证的节点才能进行交易，fabric不存在51%攻击问题

动作和行为：

• 注册登记：由客户端发起，向CA机构表明自己的身份，获取证书，上图中是第三方的CA，也可以使用官方提供的CA
• 交易提案：向组织的背书节点提交请求，对应peer节点，组织可以理解为现实中的商业主体，组织是独立的，有两个数据来源
• 提交交易：客户端节点向排序节点发请求，orderer内部进行排序打包成区块，广播给其他组织的锚节点，上图是基于kafka的实现的，每个组织会选择一个orderer节点进行通信

---

三.交易流程图

• 客户端提交交易，最终到记账节点同步数据
• 智能合约安装要指定背书节点，正常情况下，背书节点返回相同的结果，但签名是不一样的
• 背书节点是模拟的过程，不会持久化
• 1，2，3步是交易模拟，4，5，6步的交易排序，7，8，9是交易同步和记账，交易模拟对应智能合约，交易排序对应共识机制，同步和记账对应账本存储