术语表
Anchor Peer（锚节点）
不同组织peers间通信使用
由于跨组织的通信依赖于gossip，因此必须在通道配置中至少定义一个锚节点。强烈建议每个组织都提供自己的锚节点集，以实现高可用性和冗余。
ACL（访问控制列表）
一个访问控制列表，将明确的peer资源（比如链码API，或者事件服务）访问和策略（明确需要几个、什么类型的组织或者角色）连接到一起。ACL是channel配置的一部分。（或者说就是一张表，告诉别人哪些角色或者组织可以读，可以写，可以背书，可以创建channel等）
Block（区块）
一个区块包含一个交易的排序集合,区块上有一个指针，加密链接前一个区块，被后续的区块连接，第一个区块被称为创世块。先order形成block再peer验证，提交。
Chain（链）
账本链就是交易的日志结构就像 其结构为哈希链接的交易块。先order打包再Peers根据背书策略和并发违背标记是否合法，然后再追加到文件系统。
Chaincode（链码）
对于智能合约的一个打包。
Channel（通道）
数据隔离和保密的依赖。必须通过通道对交易方进行身份验证才可以操作账本，channel被定义在配置区块中。
Commit（提交）
一个动作，Each Peer on a channel 验证完区块中的事务，验证完之后就可以提交到副本账本上了，一个区块中有合法的也有不合法的。
Concurrency Control Version Check（并发控制版本检查）
保持账本在peer之间的同步 ，Peer运行交易是并行的，在提交之前，peer检查交易被执行时读取的state是否被修改。简而言之，检查state还是不是之前的那个，保证是不是之前的时刻。如果交易读取的数据在运行和提交之间被修改了，并发控制版本检查就会被违背，交易就会在账本上被标记不合法，值就不会被更新到state数据库。
Configuration Block（配置区块）
配置数据（排序服务和channel的配置），修改的配置区块要加入合适的链，这个区块将包含genesis block的内容，加上delta（其他内容）
Consensus（共识）
为了达成一致性，共识用于在order上生成一个同意，并且证明生成的交易集合的正确性构建了一个区块
Consenter set（同意者集合）
在raft排序服务中，一个channel中实际参加的排序节点，如果存在其他的排序节点，这个排序节点必须是这个channel中的。
换句话来说就是一个channel中的排序节点的个数
Consortium （财团）
一个财团就是一个在区块链网络中非排序组织的集合。一个财团中的所有组织必须被键入到一个channel中，但是没被财团定义的组织可加入到现有的channel
财团>组织>节点
Chaincode definition （链码定义）
链码定义就是让组织在channel上使用之前对链码参数达成一致。每一个channel成员背书或者查询ledger都需要使用chaincode. 要使用一个代码就需要有链码定义，这些定义通过跟背书策略一样的默认大多数原则同意，就可以定义一个chaincode,这个chaincode就会被提交给channel（指的是channel中包含的所有），然后channel会执行chaincode的第一个调用，或者如果有要求，运行init方法。
链码部署->链码定义->链码执行第一个调用，如果是对链码进行初始化可以调用init方法
Dynamic Membership（动态成员关系）
Hyperledger Fabric 支持在不影响整个网络的情况下添加/删除成员、peer、order节点。
Endorsement（背书）
依照过程，明确的peer节点运行交易，返回一个提案响应给客户端app。链码app通过背书策略明确背书peers。背书响应包括：1.运行响应消息，读/写集（结果），事件，签名。
Endorsement policy（背书策略）
策略中的一种比较特殊的策略，定义在一个channel上的peer节点满足的形成事务的一个条件（得到的回应的组合）。策略可以根据应用程序和对认可方不当行为(有意或无意)的预期恢复水平进行策划。根据情况制定合适的策略。
Follower（跟随者）
在一个基于领导者的共识协议例如Raft，有节点复制leader产生的日志条目。在Raft, 跟随者接受leader的心跳消息。如果leader停止心跳数次，跟随者会选举出一个新的leader。
Genesis Block（创始区块）
配置区块，初始化排序排序服务，或者作为一个链的第一个区块。
Gossip Protocol（Gossip协议）
Gossip数据发布协议实现三个功能:
1.管理peer发现和channel成员关系
2.发布账本数据到channel上所有的peers
3.同步channel上所有的peers的账本状态。
Hyperledger Fabric CA（CA机构）
默认证书认证机构， 颁发基于PKI的证书给网络成员组织和他们的使用者。CA发布一个根证书给每一个成员（组织），给每个授权用户一个注册证书(ECert)。
给组织颁发根证书，用户颁发根证书下的注册证书。
组织证书等级>用户证书等级
Init（初始）
一个方法去初始化一个链码app。所有的链码都需要有一个init方法，默认这个方法从不被执行。 然而你可以使用这个方法定义去请求init方法运行去初始化链码。
Install(安装)
在peer的文件系统放置一个链码的过程
Instantiate（实例化）1.4以前的版本
在一个明确的channel上开始和初始化一个链码app的过程。实例化之后，peers拥有链码被安装，可以接受链码调用。
Invoke（调用）
被用来调用链码的方法。 一个客户端app通过发送一个事务提案给一个peer调用链码。这个节点将会运行链码返回一个背书提案响应给客户端app。客户端app将会收集足够的提案响应以满足背书策略，然后提交交易结果去排序，验证，提交。 客户端可能选择不去提交交易结果。比如如果调用只查询账本，客户端app典型地将不会提交这个只读交易，除非这个交易也是被期望去记录到日志为了审计的目的。这个调用包括一个channel标识符，链码方法，一组参数。
客户端app->提案->背书节点背书->背书节点运行产生结果->客户端app->根据背书策略（是否形成事务）->形成事务->发送给orderer->共识排序->blocks->leading peers->peers->验证->提交到账本,修改世界状态
Leader（领导者）
在一个基于领导者的共识协议例如Raft，领导的责任就是去摄取新的日志条目，复制它们给跟随排序节点，以及管理当条目被认为已提交。他就是一个orderer在某些时刻的一个角色，是哪一个，根据情况而定。
Orderers中会出像一个leader,用来达成共识，既是proposer也是learner的leader。
Leading Peer（领导peer）
每个组织可以拥有多种peers在每个他们订阅的channel上。这些peer中一个或者更多应该作为leading peer，代表组织去和网络的排序服务交流。
Leading Peer跟排序服务交流，排序好的区块发送给这个节点，这个节点发送给其他节点。
Ledger(账本)
一个账本是由两个截然不同的，但是相关的部分组成，一个是区块链，一个是状态数据库，也就是我们所说的世界状态。不像其他的账本，区块链是不可变的一旦区块被添加到链上，它不能被修改。相反，世界状态是一个数据库。
它是有帮助的去认为每一个channel有一个逻辑账本。事实上每一个在channel上的peer维持他自己的账本副本，通过共识维持一致性。逻辑上是一份的，但在一组网络节点(peer和排序服务)上分布有许多相同的副本。
账本包括两部分：区块链和世界状态。
Log entry（日志条目）
Raft排序服务中主要工作单元，日志条目从leader orderer分发到跟随者。所有日志条目的序列被称为log。如果所有成员都同意条目及其顺序，则认为日志是一致的。
Member（成员）
就是组织
Membership Service Provider（成员关系服务提供者）
MSP是一个抽象的系统组件，提供证书给客户，peers，去参与Hyperledger Fabric网络。客户端使用证书去认证事务，peers使用这些证书去认证事务进程结果（背书）。 虽然这个组件与系统的事务进程组件紧密相连，但这个接口的目的就是给MS组件定义，按照这个方式可以平滑的拔插不用修改系统交易进程组件的核心就可以接入其他的实体。
MSP是系统的一个抽象组件，负责提供证书，peers和客户使用证书让别人信任，之后才能发送交易/背书结果。设置这个组件就可以在不修改交易进程组件的核心的情况下，添加或删除其他组织/成员。
这个负责的物理层，只有通过MSP才可以定义实现MS
Membership Services（成员关系服务）
成员关系服务认证、授权、管理身份标示在一个许可的区块链网络。运行在peers和orderers成员关系服务代码都是去认证和授权区块链操作。它是一个基于PKI（用户，仓库，认证机构）的MSP抽象实现。
这个是负责逻辑层
Ordering Service（排序服务）
排序服务也就是orderer。一个定义的收集节点给要放入区块的交易排序，然后分布区块到连接的peers去验证和提交。排序服务独立于peer进程，按照先来先服务的方式给网络上所有的channels排列交易。它被设计去支持可拔插实现不局限于开箱即用的Kafka和Raft。它是一个公共的绑定对于整个网络。它包含绑定到每个成员的加密身份材料。
Organization（组织）
组织也被称为成员，组织被邀请加入去区块链网络通过一个区块链网络提供者（创造者）。一个组织加入网络通过添加它的MSP到网络中。MSP定义网络的其他成员怎样验证一个签名（比如那些交易的签名）。签名是由一个合法身份标示生成，由这个组织发送的。 一个MSP中的身份标识的特殊权利通过策略管理，策略在组织被加入到网络时商定，一个组织可以十分大，也可以就是一个个体。一个组织的交易端点是一个Peer。一个组织的集合就形成了一个财团。一个网络上的所有组织都是成员，但不是每一个组织都是一个财团的一部分。
财团>组织/成员>Peer
添加新的组织->添加MSP（包含身份标示等信息，用于验证使用），由于网络发生改动，形成新的配置区块（包含新的策略）->追加到系统链上
Peer（对等节点）
一个网络实体维持一个账本，运行链码容器为了在账本上运行读/写操作。Peers被成员拥有和维护。
一个peer拥有一个账本，一个chaincode容器，Peers被成员（组织）拥有和维护。
Policy（策略）
策略如OR(‘Org1.peer’, ‘Org2.peer’).被用于限制访问区块链资源。指明谁可以读，谁可以写，谁可以使用具体chaincodeAPI，通过ACL（ACL中存储着这些策略）。
可以在configtx.yaml中定义，指导去创建channel和排序服务，或者可以在channel中实例化一个chaincode时明确。提供一个默认的策略ship集合in the sample configtx.yaml 适合大多数网络。
策略就是一个表达式。
Private Data(私人数据)
机密数据被存储在每一个授权的peer私人的数据库中，逻辑上独立于channel账本数据。channel上经过私人数据集合定义的一个或者更多的组织才能访问这个数据。未授权的组织将会有一个私人数据的hash在channel账本作为交易数据的证据。同时，为了更隐私，私人数据的hash经过排序服务，而不是私人数据本身，保证了数据对于Order节点也是机密的。
私人数据独立于channel中的数据，只有私人数据定义了的组织才可以访问，其他的看到的都是它的hash。数据被保存在每一个授权的节点的私人数据库，其他节点只能查到数据的hash,对Order节点也保密。
Private Data Collection (Collection)（私人数据集合）
在channel上两个或者以上组织希望对其他组织去保持私密使用机密数据，私人数据收集被用于管理私人数据。集合定义描述了一个在channel上的组织的子集有资格去存储私人数据的集合，意味着只有这些组织可以交易这些私人数据。
Proposal(提案)
一个向channel上的明确节点要求背书的请求。每一个提案要么是一个init要么是一个（读/写）的调用请求。
提案：1.作用：请求背书。2.分类：init或者读/写
客户端形成链码提案，发送给背书节点
Query(查询)
查询就是一个链码的调用读取账本当前的状态但不向账本写入。链码方法可能查询账本上正确的key，或者查询一系列的keys。因为查询不改变账本状态，客户端app不会提交只读事务去排序，验证，提交。虽然不是典型的，客户端可以选择去提交只读的交易为了排序，验证，提交，例如，如果客户端想要账本链上的可审计证明，证明它在某个时间点上了解特定的账本状态
查询：客户端->背书提案->背书节点，不提交给order
但是也可以设定为提交，就可以知道什么时候发生过查询
Quorum(法定人数)
描述肯定一个提案所需要的的最小成员数量。对每一个同意者集合，他就是大多数节点。在一个拥有5个节点的容器，法定人数必须是三个以上。如果法定人数的节点由于任何原因不可行，容器的读和写操作变为不可行，并且没有新的log可以提交。
法定人数是背书所使用的，不满足的话背书不会通过，就不会产生新的logs
会议的法定人数:也就是大多数原则所指的最小数量
Raft（共识算法）
到v1.4.1，Raft是一个故障容错排序服务依靠Raft协议的etcd library实现。 Raft是一个领导者和跟随着模型，每一个channel有一个领导者它的决定会被跟随者复制。Raft排序服务比起基于kafka的排序服务应该被更简单建立和管理，他们的设计允许组织去向分布式排序服务贡献节点。
Software Development Kit (SDK)
客户端SDK构建了一个开发者lib环境,提供给开发者写和测试链码app。SDK是完全可配置的、可延申的通过一个标准接口。组成包括：签名的加密算法，日志框架，状态存储都是易在SDK中进行替换的。SDK提供APIs给交易过程，成员服务，节点遍历，事件处理。
目前，有两种官方的支持 Node.js and Java,Python and Go仍不是官方的但可以下载被测试。
Smart Contract（智能合约）
区块链网络外客户端app调用的代码。通过事务的方式访问和修改WS。peer节点安装了chaincode, chaincode的使用（调用）需要被先被定义，然后peer上才可以使用，一个链码用于多个channels。
客户端->chaincode->链码安装->链码定义->在channel中安装链码的peer节点使用链码
State Database（状态数据库）
世界状态数据为了更有效地的读和查被存储在一个状态数据库，目前只支持levelDB and couchDB。
System Chain（系统链）
包含一个配置区块定义网络系统等级。（由配置块构成的链）。这个系统链存在在order service，与channel一样，具有一个初始化配置包含MSP信息，策略，配置细节。对网络的任何改变将会产生一个新的配置区块添加到系统链上。
这个系统链可以被认为是一个channel或一组channels的公共绑定。例如，一堆金融机构可能形成一个财团（通过系统链代表），继续去创建channel关系给他们一致且变化的商业议程。
系统链包含了财团等配置，财团可以创建channel(s)。
Transaction（交易/事务）
当链码被客户端调用去账本中读写数据的时候创建了事务。Fabric app客户端提交事务提案给背书节点运行，背书，获取背书响应，打包结果和背书成一个交易，提交给order。Order服务排序，打包交易到区块，广播给peers验证，提交这些交易到账本，更新世界状态。
客户端 ->事务提案->背书节点运行和背书->结果和背书打包成事务->order形成区块->广播给leading peers->peer验证->提交事务给ledger->更新世界状态
World State（世界状态）
世界状态也就是目前状态，世界状态是HyperLedger Fabric Ledger的一个组件。世界状态代表了chain事务log的所有key的最后values（最新状态）。链码运行交易提案靠世界状态数据，因为世界状态提供直接访问最新的key-value而不是必须通过穿越整个 transaction log去计算它们。每次key-value修改或者当一个一个新的key被创建，世界状态也将会修改。总而言之，世界状态对交易流十分重要，因为的当前状态在修改之前必须被知道。Peers提交最新的values给账本世界状态，最新的values在一个通过验证的区块中。
6980
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
