Anchor Peer – 锚节点：如果对等方需要与另一个组织中的对等方进行通信，则可以使用该组织的通道配置中定义的锚节点 。一个组织可以为其定义零个或多个锚点，并且锚点可以帮助处理许多不同的跨组织通信场景。

Block – 区块：

　　一组有序的交易集合，在通道中经过加密(哈希加密)后与前序区块连接。是基于本地文件系统，将区块存储于文件系统的硬盘中，每个区块中保存有区块头（Block header）、区块数据（Block data）、区块元数据（Block metadata），通过区块头中的前一个区块的哈希值（Previous Block Hash）指向前一个区块的当前哈希值（Current Block Hash），连接成区块链。

Chain – 链：

　　peer节点从orderer服务收到Block，基于背书策略和并发冲突来标注区块的交易为有效或者无效状态，然后将Block追加到peer节点的文件系统的哈希链中。基于本地文件系统，将区块存储于文件系统的硬盘中，每个区块中保存有区块头（Block header）、区块数据（Block data）、区块元数据（Block metadata），通过区块头中的前一个区块的哈希值（Previous Block Hash）指向前一个区块的当前哈希值（Current Block Hash），连接成区块链。

Chaincode – 链码：

　　运行在peer上的一段程序，一般为go、java、node开发。是应用系统与区块链底层交互的中间件，通过智能合约可以实现各种复杂的应用，链码安装在peer节点上，运行在docker容器中，通过grpc与peer进行交互。

Channel – 通道：

　　将fabric网络进行分组，实现了数据的隔离和保密。通道特定的账本在通道中是与所有对等节点共享的，并且交易方必须通过该通道的验证才能与账本进行交互。是由一个配置块来定义。在网络上的交易都要在某个通道（Channel）上执行，参互交易的每个成员都需要进行身份验证和授权，才能在通道（Channel）上进行处理。每个通道都有属于自己的锚节点，通过锚节点可以与其它通道进行信息交互，但本身通道内的账本不会通过一个通道传到另一个通道上，通道对账本是分离的。

Commitment – 提交：

　　一个通道中每个peer节点都会验证交易的有序区块，然后将区块提交或者追加到该通道的账本的各个副本。

CCVC – Concurrency Control Version Check – 并发控制版本检查：

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

Configuration Block – 配置区块：

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

Consensus – 共识：

　　其用于产生一个对于排序的同意书和确认构成区块的交易集的正确性。

Endorsement -背书：

　　是指一个peer执行一个交易并返回YES-NO给生成交易proposal的client app 的过程。

Endorsement policy – 背书策略：

　　一个链码在特定的通道执行交易的时候指定的背书的规则。在instantiate链码的时候指定。

Fabric ca – 证书生成服务：

　　PKI证书颁发服务，向网络成员及其用户颁发基于PKI的证书。

Genesis Block – 创始区块：

　　初始化区块链网络或channel的配置区块，也是链上的第一个区块。

Gossip Protocol – Gossip协议：

　　1）管理peer发现和channel成员；2）channel上的所有peer间广播账本数据；3）channel上的所有peer间同步账本数据。

Leading Peer – 主导节点：

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

Ledger – 账本：

　　由channel中每个peer维护的world state或者当前状态，对channel中所有事务的执行结果的一个有序的、防篡改状态转化的记录，由一个区块链构成。同时包含一个状态数据库记录当前的状态，账本的当前状态信息是交易日志中记录过的所有键的最新值，由于当前状态表示的是通道已知的所有键的最新值，由此也被称为世界状态。区块链结构保存在本地的文件系统中；世界状态由数据库来维护，以键值对（k-v）的方式保存在数据库，默认数据库为LevelDB，数据库版本可替换为KV类型的数据库，如CouchDB等。

MSP – Membership Service Provider :

　  用于管理该组织的有效身份的规则的组件，认证证书的合法性。它允许该身份由网络的其余部分信任和识别，而无需透露成员的私钥。

 　 其并未提供任何服务。MSP要求的实现是一组文件夹，这些文件夹添加到网络的配置中，并且用于向内（组织决定其管理员是谁）和向外（通过允许其他组织验证该实体）来定义组织有权做他们想做的事情。证书颁发机构生成代表身份的证书，而MSP包含允许的身份列表。

MS – 成员服务：

　　成员服务在许可的区块链网络上认证、授权和管理身份。在peer和order中运行的成员服务的代码都会认证和授权区块链操作，它是基于PKI的MSP实现。

PKI-公共密钥基础结构

　　是在网络中提供安全通信的Internet技术的集合。

　　有四个关键要素：

　　公钥和私钥：用于身份验证，私钥进行加密，公钥用来验证所有人的签名。

　　数字证书：一种文档，其中包含与证书持有者有关的一组属性。包含证书持有者的公钥。

　　证书颁发机构：颁发和生成数字证书的服务。

　　证书吊销列表：某种原因而吊销的证书引用列表。

Orderer Service-排序服务：

　　将交易排序放入block的节点的集合，并以先到先得的方式为网络上所有的channel作交易排序打包为Block，再传递给该channel中的所有peer。支持：SOLO，KAFKA，RAFT。

　　SOLO：仅有一个Orderer服务节点负责接收交易信息进行排序，是最简单的排序算法，一般用于测试环境。

　　KAFKA：正式环境中需要使用Kafka搭建，保证数据可靠性和安全性。当排序（Orderer）节点通过RPC广播（Broadcast）接收到从节点（Peer）来的交易数据时，先判断发送交易的客户端是否有权限处理该通道（Channel）数据，如果有权限，排序（Orderer）节点会把交易保存到Kafka的分区（partition）中,每个通道（Channel）对应Kafka中的单独的单分区（partition）的类别中（topic）。排序（Orderer）节点使用该分区（partition），将接收到交易分组写入到本地区块中，并加入到本地的区块链中，最后通过RPC传输（Deliver）给需要接收的客户端。

　　排序（Orderer）操作步骤

       1）在网络的创世块中写入Kafka相关的信息

       在生成创世区块时，需要在configtx.yaml文件中配置Kafka相关的信息，如Orderer.OrdererType设置为kafka、Orderer.Kafka.Brokers设置Kafka集群中的节点IP地址和端口；

       2）设置区块最大容量

       区块最大容量在configtx.yaml文件中设置Orderer.AbsoluteMaxBytes项的值，以字节为位置，不包括区块头信息大小。

      3）创建创世区块

       使用 configtxgen 工具，根据步骤1和2中配置生成创世区块。

      4） 配置Kafka集群

          设置unclean.leader.election.enable为false；

         设置min.insync.replicas为M（数字），数据提交时会写入至少M个副本，值的范围为1<M<N（N为default.replication.factor值）；

          设置default.replication.factor为N（数字），N表示在Kafka节点上每个channel都保存N个副本的数据；值的范围为1<K（K为Kafak集群数量）；

          设置message.max.bytes值，message.max.bytes应该严格小于socket.request.max.bytes的值，socket.request.max.bytes的值默认被设置为100MB；

          设置replica.fetch.max.bytes值，每个通道获取的消息的字节数；

          设置log.retention.ms为-1，关闭基于时间的日志保留方式。

      5） 所有排序（Orderer）节点都指向创世区块

      在 orderer.yaml 文件中配置 General.GenesisFile参数， 让排序（Orderer）节点指向步骤3中所创建的初始区块。

      6）调整轮询间隔和超时时间

     在orderer.yaml 文件中配置Kafka.Retry参数， 调整 metadata/producer/consumer 请求的频率以及socket的超时时间。

      7） 设置排序节点和 Kafka 集群间为SSL 通讯

     在orderer.yaml文件中配置Kafka.TLS参数，确定是否通过TLS（安全传输层协议）进行通信。

     8） 集群启动顺序

     先启动ZooKeeper 集群,然后启动 Kafka 集群,最后启动排序（Orderer）节点。

Peer – 节点：

　　维护ledger并运行Chaincode容器来对ledger执行read-write操作。

System Chain – 系统链：

　　包含在系统级定义网络的配置区块。系统链存在于ordering service中，与channel类似，具有包含以下信息的初始配置：MSP信息、策略和信息配置。对整个网络的任何变化（例如新的Org加入或者添加新的Ordering节点）将导致新的配置区块被添加到系统链。

Client – 客户端：

　　安装在peer节点处的客户端，可以发起构建channel的请求，也可以创建和发起transaction。

Endorsing Peer – 背书节点：

　　一种特殊的节点，在channel内实例化chaincode的时候需定义对应的背书节点列表；在Client发起事务时，在背书节点上模拟该事务的执行并返回响应。

问题：

Leading Peer、Anchor Peer有何关系和不同：

　　peer节点根据通讯不同分为锚节点（Anchor peer）和主节点（Leading peer）：

　　锚节点随着通道存在，是能被其它组织发现的的节点，一个通道上包含一个或者多个锚节点。

　　主节点负责与orderer节点进行通信，把共识后的区块输入到同一个组织下的其他节点。

Commit Peer和Endorsing Peer有何关系和不同：

　　peer节点根据功能不同分为背书节点（Endorser peer）和提交节点（Committer peer）：

　　背书节点在链码实例化的时候指定背书策略的时候指定，负责对交易根据事先设定策略进行签名背书，当客户端向节点发起交易背书时，该Peer节点才具有背书功能，其它时间只是普通的记账节点。

　　提交节点负责维护状态数据和账本的副本。

      注意：Leading peer、Anchor Peer、Commit Peer、Endorsing Peer可以同时存在在同一个peer节点上同时存在，只有Anchor Peer是可选的手动指定。

MSP和PKI的关系：

　　PKI提供了一个身份列表，而MSP表示其中的哪些是参与网络的给定组织的成员。PKI就像卡提供商一样，它分配许多不同类型的可验证身份。另一方面，MSP就像商店接受的卡提供商列表一样，确定哪些身份是商店支付网络的受信任成员（参与者）。MSP将可验证的身份转换为区块链网络的成员。