Hyperledger Fabric笔记（一）

简介

Fabric 是超级账本联盟Hyperledger推出的核心区块链框架，它适合在复杂的企业内和企业间搭建联盟链。根据超级账本联盟的目标， Fabric 被建设为一个模块化的、支持可插拔组件的基础联盟链框架。Fabric网络是由Orderer节点、Peer节点、以及Fabric-CA节点组成。在生产环境中，Orderer排序服务是用Kafka实现的。不同于比特币和以太网等公有链，Fabric区块链是一个授权网络即联盟链，即网络中的每一个参与节点都有明确的身份。

Fabric区块链本质上是一个分布式的共享账本，它通过“通道”这样的逻辑结构来实现账本的隔离。具体来说，一个Fabric区块链中有若干个联盟(consortium)和若干排序服务(Orderer)组成。每个联盟由若干组织(Organization)组成，一个组织可以属于不同的联盟。在联盟的概念下可以进一步划分成若干个通道，每个通道都有一个独立的账本，仅在加入通道的组织之间共享账本数据。每个组织都管理自己的若干个Peer节点。组织中的某些Peer节点如果安装了智能合约，并且被实例化到了某个通道上，则该节点成为该通道上的该智能合约的背书节点(Endorser)；所有的Peer节点，都是committer节点。

Fabric交易流程的主要步骤如下（细节略有省略）：

组织A的客户端（通过SDK）发送一个交易提案分别给组织A和组织B的背书节点。

两个背书节点验证提案的正确性、提案用户身份合法性，然后调用智能合约进行交易仿真生成读写集合，对其进行背书后将提案响应返回给客户端。

客户端验证来自于两个背书节点的提案响应的一致性。

客户端将两个背书节点的提案响应组装成一个交易，发送给Orderer服务节点。后者将一批交易打包为区块。

区块被发送给committer节点，它们对区块链中的每一个交易验证签名是否符合背书策略的要求，并检查提案相应中读集合的数据未发生改变，据此，将交易标记为有效或者无效。

每个committer节点将区块添加到本地的区块链中，被标记为有效交易的写集合将被提交到账本的当前状态数据库。并将事件通过event hub通知给客户端。

交易流程：提案->背书->验证->排序->交易验证->写入账本。

Fabric的安全机制：

基于MSP实现了强大的身份认证机制。

实现细粒度的访问控制策略。如：通道创建和修改策略、智能合约实例化策略、背书策略等。

Fabric1.1版本还支持针对账本数据的加密存取等机制。

“上链”的挑战

业务系统上链，无论是自建底层区块链还是使用现有的区块链云服务，都将面临以下几个挑战。

挑战一，搭建Fabric区块链物理网络不是很容易。其难点在于几个方面：

Fabric自身的网络构成还是比较复杂的。

由于业务需要，联盟链的参与组织可能不希望完全中心化的运维管理。一方面他们希望对自己的Peer节点有完全的管控；另一方面希望区块链节点和自己的应用系统部署在一起。这导致联盟链的节点可能分布于不同的网络环境中。因此，区块链的运维管理需要在中心化和去中心化的两极之间找到平衡点。

区块链物理网络应当允许动态加入新节点。

挑战二，Fabric区块链需要能适应业务变化。从不同层面体现出区块链应对变化的要求：

物理网络层要求能添加新的节点、或者对已有节点进行资源扩容以提升机器性能和存储容量，从而应对访问量的增加。

在Fabric区块链领域模型层面，因为业务发展，需要吸纳新的组织（即新合作方）加入已有联盟和通道以共享账本，并且升级背书策略以让新组织参与交易背书的过程。另外往通道中增加新的节点（比如：背书节点）也会提升智能合约调用的并发能力。

新增的业务逻辑要求发布新的智能合约，然后安装部署到通道；业务逻辑的更改，会引发对已有智能合约的升级。同样的智能合约应该也可以复用到不同的通道，但希望对合约有一个全局的管理视图。另外，合约在安装部署之前，一些重要参与方会希望能审核合约代码以确保其遵从相关业务协议，在审核完成之后对合约安装包进行签名背书。这样就可以保证每个参与方都安装的是大家一致认可的智能合约。

挑战三，对Fabric区块链的运维管理要安全可控。同样，从不同维度看有不同的要求：

需对物理节点的资源消耗情况进行监控。

需安全地管理私钥和证书；对于区块链配置的更改需要有基于权限控制的审核机制。某些配置更改需多方签名同意才能完成，此时需要有一个收集签名的机制来协调大家的共识过程。比如：允许新组织加入通道时，需大多数已有成员组织签名同意，才能对完成对通道配置的修改。问题是：谁有权来发起对通道配置的修改请求？谁来负责收集各方签名后再将请求提交给Orderer服务让配置生效？

Fabric的特点是，同一份智能合约可以安装在不同节点上，这些节点可以加入到不同的通道中。并且同一个智能合约可以被实例化(instantiate)到不同的通道上。此外，智能合约可以有不同版本。如果没有一个统一的视图来管理“合约–节点–通道“之间的复杂关系，那么将是一场噩梦。

挑战四，区块链应用开发的门槛较高。主要涉及两个方面：

开发智能合约的学习成本；

开发调用智能合约的应用程序还不是很方便。原生的Fabric SDK功能非常丰富，提供的API比较基础，但直接用来开发应用程序会有些不便。比如，调用合约时，需要应用去实现发起提案、验证提案响应以及组装并发送交易的这些交易流程细节。

开发应用时，希望使用更简单的SDK，更希望有现成的智能合约可以复用。

学习资料：TechFirst PPT

—-

编译者/作者：区块链系统分析员

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。