LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资讯 > Hyperledger Fabric笔记(一)

Hyperledger Fabric笔记(一)

2020-06-04 区块链系统分析员 来源:区块链网络

简介

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

—-

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

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

LOADING...
LOADING...