Hyperledger-Fabric 区块链

Hyperledger Fabric概念汇总

简介

对于Fabric中经常出现的名词做的一份名词解释。

部分内容节选自:
http://hyperledger-fabric.readthedocs.io/en/latest/index.html
https://hyperledgercn.github.io/hyperledgerDocs/

1 Block – 区块

在一个通道上,区块是一组有序交易的集合。在通道中经过加密(哈希加密)后与前序区块连接。

2 Chain – 链

Zhu Jiang:账本的链是一个交易区块经过“哈希连接”结构化的交易日志。对等节点从排序服务收到交易区块,基于背书策略和并发冲突来标注区块的交易为有效或者无效状态,并且将区块追加到对等节点文件系统的哈希链中。

3 节点

3.1 Committer – 提交节点

1.0 架构中一种 peer 节点角色,负责维护区块链和账本结构。对 orderer 排序后的交易进行检查(包括交易消息结构、签名完整性、是否重复、读写集合版本是否匹配等),检查完成后选择合法的交易执行并写入存储。
同一个物理节点可以仅作为Committer角色运行,也可以同时担任Endorser和Committer这两种角色。

3.2 Endorser – 背书节点

1.0 架构中一种 peer 节点角色,负责检验某个交易是否合法,是否愿意为之背书、签名。
收到来自客户端的交易提案后,首先进行合法性和ACL权限检查,检查通过则模拟运行交易,对交易导致的状态变化(以读写集形式记录,包括所读状态的键和版本,所写状态的键值)进行背书并返回结果给客户端。注意网络中可以只有部分节点担任Endorser角色。

3.3 Orderer – 排序节点

1.0 架构中的共识服务角色,为网络中所有合法交易进行全局排序,并将一批排序后的交易组合生成区块结构。
目前Orderer支持Solo(单节点共识)、kafka(分布式队列)、PBFT(拜占庭容错)三种模式。

3.3.1 Solo – 单节点共识

order-solo模式作为单节点通信模式,所有从peer收到的消息都在本节点进行排序与生成数据块,因此不需要“共识”;对应的也就失去了高可用性与拓展性。Solo使得开发与测试非常的简便易于使用,这种模式主要是为了非生产环境而存在的。

3.3.2 kafka – 分布式队列

此模式需要加入一个kafka集群统一分配处理所有Orderer的数据。Orderer服务从kafka集群里获取相应topic,即在kafka队列中隔离出来不同的作用域供Orderer使用。kafka的分布式一致机制确保了我们的交易数据是有序的。

虽然引入了kafka带来了较高的吞吐量以及可用性,但是却没有拜占庭容错。

3.3.3 PBFT – 拜占庭容错

3.4 Peer – 节点

一个网络实体,维护账本并运行链码容器来对账本执行读写操作。peer由Member拥有和维护。

3.5 Leading Peer – 主导节点

每一个Member在其订阅的channel上可以拥有多个peer,其中一个peer会作为channel的leading peer代表该Member与ordering service通信。ordering service将block传递给leading peer,该peer再将此block分发给同一member下的其他peer。

4 Chaincode – 链码

即智能合约,是一个运行在账本上的一段代码,用来实现不同的业务逻辑,可以实现对StateDB的增删改查。
支持golang等开发语言,运行在独立的Docker环境中。从Fabric1.0开始Chaincode支持更新部署。

5 Channel – 通道

通道是构建在“Fabric”网络上的私有区块链,实现了数据的隔离和保密。通道特定的账本在通道中是与所有对等节点共享的,并且交易方必须通过该通道的正确验证才能与账本进行交互。通道是由一个“配置块”来定义的。

6 Commitment – 提交

一个通道中的每个对等节点都会验证交易的有序区块,然后将区块提交(写或追加)至该通道上账本的各个副本。对等节点也会标记每个区块中的每笔交易的状态是有效或者无效。

7 Concurrency Control Version Check – 并发控制版本检查(CCVC)

CCVC是保持通道中各对等节点间状态同步的一种方法。对等节点并行的执行交易,在交易提交至账本之前,对等节点会检查交易在执行期间读到的数据是否被修改。如果读取的数据在执行和提交之间被改变,就会引发CCVC冲突,该交易就会在账本中被标记为无效,而且值不会更新到状态数据库中。

8 Configuration Block – 配置区块

包含为系统链(排序服务)或通道定义成员和策略的配置数据。对某个通道或整个网络的配置修改(比如,成员离开或加入)都将导致生成一个新的配置区块并追加到适当的链上。这个配置区块会包含创始区块的内容加上增量。

9 Consensus – 共识

共识是贯穿整个交易流程的广义术语,其用于产生一个对于排序的同意书和确认构成区块的交易集的正确性。

和SBFT(简单拜占庭容错)三种共识方式。

10 Current State – 当前状态

ledger的current state表示其chain交易log中所有key的最新值。peer会将处理过的block中的每个交易对应的修改value提交到ledger的current state,由于current state表示channel所知的所有最新的k-v,所以current state也被称为World State。Chaincode执行交易proposal就是针对的current state。

11 Dynamic Membership – 动态成员

Fabric支持动态添加-移除members、peers和ordering服务节点,而不会影响整个网络的操作性。当业务关系调整或因各种原因需添加-移除实体时,Dynamic Membership至关重要。

12 Endorsement – 背书

Endorsement 是指一个peer执行一个交易并返回YES-NO给生成交易proposal的client app 的过程。chaincode具有相应的endorsement policies,其中指定了endorsing peer。

背书一词是有专业定义的,后来才广泛传播起来。
通俗的讲:就是A做了一件事情,但是A没有名气,大家认可度不高;现在有一个B,很知名,并且做了一个承诺:我相信A。相当于有个大佬为小喽啰做了担保说:他没问题,大家可以相信他。这样在大佬的公信力下就会选择相信小喽啰。就称之为B为A背书。

13 Endorsement policy – 背书策略

Endorsement policy定义了依赖于特定chaincode执行交易的channel上的peer和响应结果(endorsements)的必要组合条件(即返回Yes或No的条件)。Endorsement policy可指定对于某一chaincode,可以对交易背书的最小背书节点数或者最小背书节点百分比。背书策略由背书节点基于应用程序和对抵御不良行为的期望水平来组织管理。在install和instantiate Chaincode(deploy tx)时需要指定背书策略。

14 Fabric-ca

Fabric-ca是默认的证书管理组件,它向网络成员及其用户颁发基于PKI的证书。CA为每个成员颁发一个根证书(rootCert),为每个授权用户颁发一个注册证书(eCert),为每个注册证书颁发大量交易证书(tCerts)。

15 Genesis Block – 初始区块

即创世区块,Genesis Block是初始化区块链网络或channel的配置区块,也是链上的第一个区块。

16 Gossip Protocol – Gossip协议

Gossip数据传输协议有三项功能:1)管理peer发现和channel成员;2)channel上的所有peer间广播账本数据;3)channel上的所有peer间同步账本数据。

17 Member – 成员

拥有网络唯一根证书的合法独立实体。像peer节点和app client这样的网络组件会链接到一个Member。

18 Membership Service Provider – MSP

MSP是指为client和peer提供证书的系统抽象组件。Client用证书来认证他们的交易;peer用证书认证其交易背书。该接口与系统的交易处理组件密切相关,旨在使已定义的成员身份服务组件以这种方式顺利插入而不会修改系统的交易处理组件的核心。

19 Membership Services – 成员服务

成员服务在许可的区块链网络上认证、授权和管理身份。在peer和order中运行的成员服务的代码都会认证和授权区块链操作。它是基于PKI的MSP实现。
fabric-ca组件实现了成员服务,来管理身份。特别的,它处理ECert和TCert的颁发和撤销。
ECert是长期的身份凭证;TCert是短期的身份凭证,是匿名和不可链接的。

20 Ordering Service – 排序服务或共识服务

将交易排序放入block的节点的集合。ordering service独立于peer流程之外,并以先到先得的方式为网络上所有的channel作交易排序。ordering service支持可插拔实现,目前默认实现了SOLO和Kafka。ordering service是整个网络的公用binding,包含与每个Member相关的加密材料。

21 Policy – 策略

有背书策略,校验策略,区块提交策略,Chaincode管理策略和网络-通道管理策略。

22 Proposal – 提案

一种针对channel中某peer的背书请求。每个proposal要么是Chaincode instantiate要么是Chaincode invoke。

23 System Chain – 系统链

包含在系统级定义网络的配置区块。系统链存在于ordering service中,与channel类似,具有包含以下信息的初始配置:MSP信息、策略和信息配置。对整个网络的任何变化(例如新的Org加入或者添加新的Ordering节点)将导致新的配置区块被添加到系统链。
系统链可看做是一个channel或一组channel的公用binding。例如,金融机构的集合可以形成一个财团(以system chain表示),然后根据其相同或不同的业务创建channel。

24 Transaction – 交易

Chaincode的invoke或instantiate操作。Invoke是从区块链网络种中请求读写操作;Instantiate是请求在peer上启动Chaincode容器。

补充(区块链中其他概念)

1 软分叉

当新共识规则发布后,没有升级的节点会因为不知道新共识规则下,而生产不合法的区块,就会产生临时性分叉。

2 硬分叉

区块链发生永久性分歧,在新共识规则发布后,部分没有升级的节点无法验证已经升级的节点生产的区块,通常硬分叉就会发生。

3 侧链

4 冷钱包

5 热钱包

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据