Hyperledger fabric与Hyperledger composer的联系
文章目录
一、Fabric简介
在介绍Fabric之前,我们得首先了解什么是区块链。
1.1 分布式账本(A Distributed Ledger)
区块链网络的核心是一个分布式账本,用于记录在网络上发生的所有交易。区块链账本通常被描述为去中心化的,因为它被复制到许多网络参与者中,每个参与者都在协作维护。我们将看到,分权和协作是反映企业在现实世界中交换产品和服务方式的强大属性。
除了去中心化和协作之外,记录在区块链中的信息只能追加,使用加密技术可保证一旦交易添加在账本中,便无法对其进行修改。这种无法篡改的特性使得判断信息的来源变得很简单,因为参与者可以肯定信息在事后没有被改变。这就是区块链有时被描述为证明体系的原因。
1.2 智能合约(Smart Contracts)
为了支持信息一致性更新 —— 启用一整个作用于账本的功能(交易,查询等) —— 区块链网络使用智能合约来提供对账本访问控制。
智能合约不仅是简单的封装信息在整个网络中同步,它们也可以被写入以允许参与者的一些交易能自动执行。例如,可以写一份智能合约,通过物品何时到达来决定传输费用。双方一旦同意该条款并写入账本中,当商品到达时,相应的资金将会自动被转入。
1.3 共识(Consensus)
通过网络保持分类账交易同步的过程 — 确保账本只有在交易获得相应的参与者批准时才更新,并且当账本更新时,它们以包含相同的顺序区块来更新账本 — 这个过程就称为共识。
随着了解的逐渐深入,会越来越对区块链有更加深入的了解。不过就目前简介而言,将区块链视为共享的、复制的交易系统就足够了,该交易系统通过智能合约进行更新,并通过称为共识的协作过程保持一致同步。
1.4 什么是 Hyperledger Fabric?
Linux 基金会于2015年创立了 Hyperledger,以推进跨行业区块链技术。相对于声明一个的区块链标准,它鼓励通过社区协作流程来开发区块链技术,鼓励开源来开发知识产权并最终采用一套标准。
Hyperledger Fabric 是 Hyperledger 中的区块链项目之一。像其他区块链技术一样,它具有账本,使用智能合约,并且系统是参与者管理其交易的。
Hyperledger Fabric从其他一些区块链系统中脱颖而出的地方在于它是私密的并且是权限化的。相对于允许未知身份参与网络的开放式权限系统(需要工作证明等协议来验证交易和保护网络)。Hyperledger Fabric 网络的成员通过注册可信成员服务提供商(Membership Service Provider 简称 MSP)来保证系统的私密性。
Hyperledger Fabric 还提供多种可热插拔选项。账本数据可以以多种格式来存储,共识机制可以随时切换开关,并支持多种的MSP。
Hyperledger Fabric 还提供了创建频道(channels)的能力,允许一组参与者创建单独的交易账本。对网络参与者中有潜在的竞争对手的情况下,这是一个特别重要的选择 — 例如,他们向某些参与者提供的特殊价格 — 每位参与者都知道。如果两个参与者都在一个频道,那么这些参与者(没有其他人)就拥有该频道的账本副本。
共享账本(Shared Ledger)
Hyperledger Fabric 的账本系统有两个组件:世界状态(world state)和事务日志(transaction log)。每个参与者都将分类帐的副本分配给所属的每个 Hyperledger Fabric 网络。Hyperledger Fabric 中的网络参与者都有一本账本副本。
世界状态组件描述了在特定时间点下账本的状态。这是相当于账本的数据库。交易日志组件记录了构成世界状态的所有交易;由此得出,账本是世界状态数据库和交易日志历史记录的组合。
账本对世界状态有可替换的数据存储。默认情况下,这是一个 LevelDB 键值存储数据库。事务日志不需要是可插拔的。它只记录区块链网络中使用的账本数据库的前后值。
智能合约(Smart Contracts)
Hyperledger Fabric 的智能合约是用 chaincode 实现的,并且被区块链外部应用程序所调用,以此来与账本交互。在大多数情况下,chaincode 仅与账本的数据库组件(世界状态)(例如查询)交互,而不与交易日志交互。
Chaincode 可以用几种编程语言实现。目前支持的 chaincode 的语言是 Go,未来将支持 Java 和其他语言。
私密性(Privacy)
根据网络的需求,企业对企业(B2B)网络的参与者可能对他们共享多少信息非常敏感。对于其他区块链网络而言,隐私不会成为首要问题。
相遇对其他的区块链网络,隐私(使用频道方法)对于 Hyperledger Fabric 是非常关键的要求。
共识(Consensus)
交易必须按照发生的顺序写入账本中,网络中不同的参与者皆是如此。要做到这点,必须建立交易顺序,并且必须实施一种方法,用于拒绝错误(或恶意)插入账本的不良交易。
这是一个老生常谈的计算机科学领域,有很多方法可以实现共识算法,每个方法都有不同的利弊。例如,PBFT(Practical Byzantine Fault Tolerance)可以提供文件副本相互通信的机制,以保持每个副本的一致性,即使在发生损坏的情况下。或者,在比特币中,通过计算加密问题(也被称为挖矿)来实现共识,谁先算出来该区块就算谁的。
Hyperledger Fabric 被设计为允许网络初始者选择最能代表参与者之间存在关系的共识机制。与隐私一样,还有一系列需求:从关系高度结构化的网络到更加点对点的网络。
二、Composer简介
Hyperledger Composer是一个广泛的开放式开发工具集和框架,配合fabric使用,可简化开发区块链应用程序的过程。其主要目标是缩短实现价值的时间,并使区块链应用程序与现有业务系统的集成更加容易。可以使用Composer快速开发用例,并在数周而不是数月内部署区块链解决方案。Composer允许对业务网络进行建模,并将现有系统和数据与区块链应用程序集成。
Hyperledger Composer支持现有的Hyperledger Fabric区块链基础架构和运行时,它支持可插拔的区块链共识协议,以确保指定的业务网络参与者根据策略对交易进行验证。
日常应用程序可以使用业务网络中的数据,从而为最终用户提供简单且受控的访问点。
使用Hyperledger Composer可以快速建模当前的业务网络,其中包含现有资产以及与之相关的交易。资产是有形或无形的商品,服务或财产。作为业务网络模型的一部分,可以定义与资产交互的交易。商业网络还包括与它们互动的参与者,每个参与者都可以跨多个商业网络与唯一身份相关联。
2.1 Composer基本概念
Blockchain State Storage:交易历史和资产都会直接保存在区块链上,用区块链做存储。
Connection Profiles:是一组JSON配置文件,定义了各种网络连接参数,Composer通过这组被称为Connection Profiles配置文件,定义了应该连接到哪个系统上。Connection Profile通常需要由系统创建者提供,定义了各种网络连接参数。
Assets:可以指代任何有型的和无形的资产,必须有唯一标识符,还可以添加一些额外的信息,用于关联其他资产或者参与者等等。
Participants:是商业网络的成员,可以拥有资产或发起交易,必须有唯一的标识符,此外也可以包含其他可选属性。一个参与者可以有一个或多个身份。
Identities:对应Fabric的PKI认证的概念,通过**确认用户身份的。
Business Network cards:是一个Identitie,一个connection profile,以及元数据的组合,元数据包含一个可选的连接到商业网络名称。
Transactions:交易,资产转移的过程。
Queries:查询返回的是区块链当中的数据。只需要定义好商业网络,以及相关的变量,就可以轻松的利用Composer API从区块链网络中提取所需数据。
Events:事件是在商业网络中定义的,就跟定义资产或参与者同样的方式。定义事件之后,就可以通过交易处理函数触发。应用程序可以通过composer-client API订阅这些事件。
Access Control:访问控制规则,允许细粒度控制什么角色在什么条件下有什么样的权限控制什么资产。
Historian registry:是专门用于成功交易记录的,包含了发起交易的参与者和身份信息。historian将交易保存为HistorianRecord资产,定义在 Composer系统的namespace中。
网络模型文件 (.cto):包含资产、参与方和交易的定义。
JavaScript 文件 (.js):定义交易函数。
ACL 文件 (.acl):包含访问控制规则,用于定义业务网络中不同参与方的权利。
查询文件 (.qry):定义可在网络中运行的查询。
BNA:Composer创建出Model File(.cto文件), Script File(.js文件), ACL(.acl文件), Query File(.qry文件)等等,进行打包成一个商业网络文件(.bna文件),发布到Fabric网络中。BNA 文件包含可执行的交易处理器函数,可将其视为使用 JavaScript 编写的智能合约。可以使用 Hyperledger Composer API 来编写客户端应用以访问 BNA 函数。
三、Fabric与Composer版本联系
下表是我整理的fabric与composer大致版本更新时间
注:“()”中包含的是composer版本更新时所添加的描述
Time | composer version | fabric version |
---|---|---|
16 Sep 2016 | v0.6.0-preview | |
25 Jan 2017 | v0.3.3 | |
31 Jan 2017 | v0.4.0 | |
10 Mar 2017 | v0.5.0 | |
29 Apr 2017 | v0.7.0 | |
15 Jun 2017 | v0.8.0 | |
30 Jun 2017 | v0.9.0 | |
12 Jul 2017 | V1.0.0 | |
20 Jul 2017 | v0.10.0 | |
3 Aug 2017 | v0.11.0 (Add some firm warnings to not use v0.6 of Fabric) | |
31 Aug 2017 | v0.12.0 | |
21 Sep 2017 | v0.13.0 | |
12 Oct 2017 | v0.14.0 | |
10 Nov 2017 | v0.15.0 | |
28 Nov 2017 | v0.16.0 | |
12 Jan 2018 | v0.17.0 | |
6 Mar 2018 | v0.18.0 | |
16 Mar 2018 | V1.1.0 | |
28 Mar 2018 | v0.19.0 | |
4 Jul 2018 | V1.2.0 | |
5 Jul 2018 | v0.19.12 (Add extra parameters necessary for Fabric 1.1 curl / bash) | |
10 Aug 2018 | v0.20.0 | |
11 Oct 2018 | V1.3.0 | |
10 Jan 2019 | V1.4.0 | |
30 Aug 2019 | v0.20.9 (stop) | |
30 Jan 2020 | V2.0.0 |
从中我们可以看到,在composer刚发布时所使用的fabric版本还在v 0.6.0。在fabric v1.0.0发布之后不久,composer立马更新了其所使用的fabric版本,即在v 0.11.0之后不再使用v 0.6.0版本fabric。在18年3月份,fabric公布了v 1.1.0,这之前不久composer来到了v 0.18.0。七月,在composer v 0.19.12中适配了fabric v1.1。而在最后版本的composer中,fabric适配版本已经来到了v 1.2。19年8月份,官方宣布composer项目停止、弃用。在2020年1月,fabric版本正式来到了v 2.0。
四、Composer弃用之后的开发
composer最开始的项目目标就是配合fabric使用,简化开发区块链应用程序的过程,缩短实现价值的时间,并使区块链应用程序与现有业务系统的集成更加容易。但随着fabric项目的快速发展,其本身就拥有了不少快速部署的特性,编写chaincode并部署即可快速完成开发。而Hyperledger项目下又有不少子项目搭配fabric使用,例如cello等。因此想要开发出一个fabric程序,了解并学会使用fabric是关键,况且还大大简化了使用方法。
参考:
Hyperledger Composer GitHub主页
Hyperledger Fabric GitHub主页
Hyperledger Composer和Hyperledger Fabric的关系、区别及概念
Hyperledger Composer 官方文档