本文先介绍fabric-samples的安装和使用，然后从官方文档中摘录重要知识

fabric-samples的安装和使用

安装fabric-samples

安装Git、cURL、Go、JQ
安装Docker Desktop，并将用户添加到docker组：sudo usermod -a -G docker <username>

进入Go语言的工作目录，获取安装脚本并执行安装脚本

mkdir -p $HOME/go/src/github.com/<your_github_userid>
cd $HOME/go/src/github.com/<your_github_userid>
curl -sSLO https://raw.githubusercontent.com/hyperledger/fabric/main/scripts/install-fabric.sh && chmod +x install-fabric.sh
./install-fabric.sh

将fabric-samples/bin目录加入环境变量

运行fabric测试网络

启动网络

进入测试网络目录，即fabric-samples/test-network
给予network.sh执行权限：chmod +x network.sh
启动fabric网络：./network.sh up

部署链码

创建通道：./network.sh createChannel
使用logspout工具监控智能合约的日志：./monitordocker.sh，此时会启动一个名为logspout的容器
在通道上启动链码：./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go

调用链码

设置FABRIC_CFG_PATH指向fabric-samples/config中的core.yaml文件：export FABRIC_CFG_PATH=$PWD/../config/

要使用peer CLI，需要设置peer节点的环境变量，这将决定以谁的身份操作peer CLI

# 启用TLS
export CORE_PEER_TLS_ENABLED=true

# 以Org1管理员用户身份操作peer CLI
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=$PWD/organizations/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=$PWD/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051

# 以Org2管理员用户身份操作peer CLI
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=$PWD/organizations/peerOrganizations/org2.example.com/tlsca/tlsca.org2.example.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=$PWD/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051

切换到以Org1管理员用户身份操作peer CLI
创建一组初始资产：peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" -c '{"function":"InitLedger","Args":[]}'
获取资产列表：peer chaincode query -C mychannel -n basic -c '{"Args":["GetAllAssets"]}'
调用资产转移链码来更改资产的所有者：peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" -c '{"function":"TransferAsset","Args":["asset6","Christopher"]}'
切换到以Org2管理员用户身份操作peer CLI
查询转移后的资产：peer chaincode query -C mychannel -n basic -c '{"Args":["ReadAsset","asset6"]}'

简介

Fabric由以下模块化的组件组成：
- 可插拔的排序服务对交易顺序建立共识，然后向节点广播区块
- 可插拔的成员服务提供者负责将网络中的实体与加密身份相关联
- 可选的P2Pgossip服务通过排序服务将区块发送到其他节点
- 智能合约（“链码”）隔离运行在容器环境（例如Docker）中。它们可以用标准编程语言编写，但不能直接访问账本状态
- 账本可以通过配置支持多种数据库管理系统
- 可插拔的背书和验证策略，每个应用程序可以独立配置
许可和非许可区块链
- 对于许可区块链来说，完全拜占庭容错的共识可能是不必要的，并且大大降低了性能和吞吐量。许可区块链可以使用更传统的崩溃容错（CFT）或拜占庭容错（BFT）共识协议。
- 非许可区块链通常采用“挖矿”或交易费来提供经济激励，以抵消参与基于“工作量证明（PoW）”的拜占庭容错共识形式的特殊成本。
Fabric引入了一种新的事务架构，执行-排序-验证，即将交易流程分为三个步骤
1. 执行一个交易并检查其正确性，从而给它背书
2. 通过（可插拔的）共识协议将交易排序
3. 提交交易到账本前先根据特定应用程序的背书策略验证交易
Fabric目前提供了一种基于etcd库中Raft协议的CFT排序服务的实现
Hyperledger Fabric有一个账本子系统，包括两个组件：世界状态和交易日志。在大多数情况下，链码只与账本的数据库、世界状态（例如查询）交互，而不与交易日志交互。

更新说明

Fabric v2.0, v2.1, v2.2

智能合约的去中心化治理
用于协作和共识的新链码应用程序模式
私有数据增强
外部链码启动器
用于提高CouchDB性能的状态数据库缓存

Fabric v2.3

没有系统通道的排序者通道管理
账本快照

Fabric v2.4

Fabric Gateway
peer节点退出
计算链码包ID

Fabric v2.5

清除私有数据的历史记录
多架构二进制文件和Docker镜像

关键概念

Fabric网络结构

创建网络

创建网络或通道的第一步是同意并定义其配置

通道配置CC1已获得组织R1(Org1)、R2(Org1)和R0(ordererOrg)的同意，并包含在配置块中（由configtxgen工具根据configtx.yaml文件创建）。一旦存在配置块，就可以说通道在逻辑上存在，即使没有任何组件在物理上连接到它

Certificate Authorities（证书颁发机构）
这些组织的定义及其管理员的身份必须由与每个组织关联的证书颁发机构(CA)创建。在我们的示例中，组织R1、R2和R0分别拥有由CA1、CA2和CA0创建的认证和组织定义。
证书颁发机构在网络中发挥着关键作用，因为它们分发可用于识别属于某个组织的组件的X.509证书
X.509证书用于客户端应用程序交易提案和智能合约交易响应，以对交易进行数字签名

将节点加入通道

peer节点托管账本和链码，但排序节点保存的账本副本仅包含账本的区块链部分，而不包含状态数据库

R1的peer节点P1和R2的peer节点P2以及R0的排序服务O加入通道

安装、批准和提交链码

链码安装在peer节点上，然后在通道上定义和提交

安装、批准和提交链代码的过程称为链代码的“生命周期”
链码定义中提供的最重要的信息是背书策略。它描述了哪些组织必须在交易被其他组织接受到其账本副本上之前对其进行背书
根据用例，可以将背书策略设置为通道中成员的任意组合。如果未设置背书策略，则继承通道配置中指定的默认背书策略
虽然可以使用peer CLI驱动交易，但最佳实践是创建一个应用程序并使用它来调用链代码上的交易

在通道上使用应用程序

提交智能合约后，客户端应用程序可用于通过Fabric Gateway服务（网关）调用链码上的交易

从Fabricv2.4开始，客户端应用程序（使用Gateway SDK）与网关服务建立gRPC连接，然后网关服务代表应用程序处理交易提议和背书过程。交易提案作为链码的输入，链码使用它来生成交易响应。

身份

区块链网络中的不同参与者包括节点、订购者、客户端应用程序、管理员等。每个参与者都拥有封装在X.509数字证书中的数字身份。

为了使身份可验证，它必须来自受信任的权威机构，MSP是定义管理该组织的有效身份的规则的组件。
Fabric中默认的MSP实现使用X.509证书作为身份，采用传统的公钥基础设施(PKI)分层模型。

公钥基础设施(PKI)是在网络中提供安全通信的互联网技术的集合。PKI提供身份列表，MSP说明其中哪些是参与网络的给定组织的成员。

PKI有四个关键要素：
- Digital Certificates（数字证书）
- Public and Private Keys（公钥和私钥）
- Certificate Authorities（证书颁发机构）
- Certificate Revocation Lists（证书吊销列表）

数字证书是包含与证书持有者相关的一组属性的文档。最常见的证书类型是符合X.509标准的证书，它允许在其结构中对一方的识别详细信息进行编码。

参与者或节点能够通过系统信任的机构为其颁发的数字身份来参与区块链网络。
在生产网络下，数字身份（或简称身份）具有符合X.509标准并由证书颁发机构(CA)颁发的经过加密验证的数字证书的形式。

Fabric提供了内置的CA组件，允许在自己构建的区块链网络中创建CA。
该组件称为Fabric CA，是一个私有根CA提供商，能够管理具有X.509证书形式的Fabric参与者的数字身份。

会员服务提供商(MSP)

MSP是一种允许该身份被网络其余部分信任和识别的机制。

身份类似于您的信用卡，用于证明您可以付款。MSP类似于可接受的信用卡列表。
CA用于创建身份，但就像卡的示例一样，这些身份不能只是颁发，还需要被网络识别，MSP可以将身份转变为网络可以识别的东西。
MSP也是为成员提供网络内一组角色和权限的机制。由于定义这些组织的MSP对于网络成员来说是已知的，因此可以使用它们来验证尝试执行允许其执行的操作的网络实体。

MSP是一种使角色参与许可的区块链网络的机制。要在Fabric网络上进行交易，成员需要：
- 拥有由组织信任的CA颁发的身份。组织MSP确定组织信任哪些CA。
- 检查组织MSP是否已添加到通道中。这意味着该组织得到了网络成员的认可和认可。
- 确保MSP包含在网络上的策略定义中。
MSP出现在区块链网络中的两个域中：
- 本地在参与者的节点上（本地MSP）：本地MSP是为客户端和节点（peer和orderer）定义的。本地MSP定义节点的权限（例如，可以操作该节点的管理员）。
- 通道配置中（通道MSP）：通道MSP在通道层面定义管理和参与权利。
MSP结构
- config.yaml：用于通过启用“node OU”并定义接受的角色来配置Fabric中的身份分类功能。
- cacerts：此文件夹包含受此MSP代表的组织信任的根CA的自签名X.509证书列表。此MSP文件夹中必须至少有一个根CA证书。
- intermediatecerts：此文件夹包含该组织信任的中间CA的X.509证书列表。
- admincerts（从Fabricv1.4.3及更高版本中已弃用）
- keystore：包含节点的私钥，用于签署数据-例如签署交易提案响应，作为背书阶段的一部分。
- signcert：此文件夹包含CA颁发的节点证书。证书代表节点的身份，该证书对应的私钥可用于生成签名，任何拥有该证书副本的人都可以验证该签名。
- tlscacerts：此文件夹包含该组织信任的根CA的自签名X.509证书列表，用于使用TLS的节点之间的安全通信。TLS通信的一个示例是当对等方需要连接到排序节点以便接收账本更新时。

Policies（策略）

策略是一组规则，定义了如何制定决策和实现特定结果的结构。为此，策略通常描述谁和什么，例如个人对资产的访问或权利。

Fabric策略代表成员如何就接受或拒绝对网络、通道或智能合约的更改达成一致。最初配置通道时，策略由通道成员同意，但也可以随着通道的发展进行修改。简而言之，Fabric网络上执行的所有操作都由策略控制。

策略允许成员决定哪些组织可以访问或更新Fabric网络，并提供执行这些决策的机制。策略包含有权访问给定资源（例如用户或系统链码）的组织列表。

peer组织添加到通道的策略是在peer组织（称为Application组）的管理域内定义的。
在通道的同意者集中添加排序节点是由Orderer组内的策略控制的。
跨peer组织域和排序者组织域的操作包含在Channel组中。

ACL（访问控制列表）是指应用程序通道配置中定义的策略，并将其扩展以控制其他资源。默认的Fabric ACL集在Application: &ApplicationDefaults部分下的configtx.yaml文件中可见。

在Hyperledger Fabric中，策略中的显式签署使用Signature语法表示，隐式签署使用ImplicitMeta语法。

Signature策略定义了必须签名才能满足策略的特定用户类型，例如OR(‘Org1.peer’,‘Org2.peer’)。该语法支持AND、OR和NOutOf的任意组合。例如，可以使用AND(‘Org1.member’,‘Org2.member’)轻松表达策略，这意味着需要Org1中至少一名成员和Org2中一名成员的签名才能满足策略。

Peers

HyperledgerFabric区块链网络的基本元素是peer，因为它们管理账本和智能合约。从Hyperledger Fabricv2.4开始，默认情况下在每个peer节点上安装并启用Fabric Gateway服务。与客户端应用程序（在Fabricv2.3及更早版本中）相反，网关服务管理peer节点上的交易提议和背书。

peers与orderers一起确保通道中每个节点的账本保持一致且最新。

以下序列分三个阶段描述了客户端应用程序、在peer上运行的网关服务、orderer节点和其他peer之间的交互如何更新账本：
1. 交易提案和背书
  1. 交易提案：客户端应用程序通过连接到peer节点的网关服务来提交签名的交易提案
  2. 事务执行：网关服务选定一个peer节点点来执行事务。选定的peer节点执行提案中指定的链码，生成提案响应，签署提案响应并将其返回给网关。
  3. 交易背书：网关还将交易转发给背书策略所要求的组织中的peer节点。这些背书节点运行交易并将交易响应返回给网关服务。网关服务收集签名的提案响应并创建一个交易信封，其返回给客户端(SDK)进行签名。
2. 交易提交和排序
  1. 交易提交：客户端（SDK）将签名的交易信封发送到网关服务。网关将信封转发到排序节点并向客户端返回成功消息。
  2. 交易排序：排序节点验证签名，排序服务对交易进行排序，并将其与其他排序交易一起打包到区块中。然后，排序服务将区块分发给通道中的所有节点，以进行验证并提交给账本。
3. 交易验证和承诺
  1. 交易验证：每个节点都会检查交易信封上的客户端签名是否与原始交易提案上的签名相匹配。
  2. 交易提交：每个节点将有序的交易块提交到通道账本。
  3. 提交事件：每个提交到账本的节点都会向客户端发送一个提交状态事件以及账本更新的证明。

Ledger（账本）

Hyperledger Fabric的动机也是同样的两个问题
- 呈现一组账本状态的当前值
- 捕获确定这些状态的交易的历史记录
在Hyperledger Fabric中，账本由两个不同但相关的部分组成：
- 世界状态：一个保存一组账本状态当前值的数据库。世界状态使程序可以轻松地直接访问状态的当前值，而不必通过遍历整个事务日志来计算它。默认情况下，账本状态表示为键值对。世界状态可以经常改变，因为状态可以被创建、更新和删除。
- 区块链：一个交易日志，记录了导致当前世界状态的所有变化。交易被收集在附加到区块链的块内，这样可以了解导致当前世界状态的变化的历史。区块链的数据结构与世界状态有很大不同，它是不可变的，一旦写入就无法修改。

区块链决定世界状态，也可以说世界状态源自区块链。
世界状态是作为数据库实现的（世界状态数据库的选项目前包括LevelDB和CouchDB），区块链始终以文件的形式实现。

区块的结构：
- Block Header：该部分包含三个字段，在创建块时写入：区块号、当前区块Block Data哈希、前一个区块的块头哈希
- Block Data：包含按顺序排列的交易列表，它是在排序服务创建块时写入的
- Block Metadata：包含区块创建者的证书和签名，用于网络节点验证区块
块中交易的数据结构：
- Header：捕获有关交易的一些基本元数据，例如相关链码的名称及其版本
- Signature：由客户端应用程序创建的加密签名
- Proposal：对应用程序向智能合约提供的输入参数进行了编码
- Response：捕获世界状态之前和之后的值，作为读写集（RW-set）。它是智能合约的输出，如果交易成功验证，它将被应用于账本以更新世界状态。
- Endorsements：来自每个所需组织的签名交易响应的列表

排序服务

排序节点对通道实施基本的访问控制，限制谁可以读取和写入数据，以及谁可以配置它们。有权修改通道中配置元素的人员须遵守相关管理员在创建通道时设置的策略。

在Hyperledger Fabric中，排序服务生成的区块是最终的。一旦交易被写入区块，它在分类账中的位置就得到了不可改变的保证。Hyperledger Fabric的最终性意味着不存在账本分叉——经过验证和提交的交易永远不会被恢复或删除。

Raft是一种崩溃容错(CFT)排序服务，基于etcd中Raft协议的实现。Raft遵循“领导者和追随者”模型，其中（每个通道）选举一个领导者节点，其决策由追随者复制。

如果排序节点宕机了，重启时如何获取丢失的日志？虽然可以无限期地保留所有日志，但为了节省磁盘空间，Raft使用了一种称为“快照”的过程，用户可以在其中定义日志中保留多少字节的数据。（这取决于块中的数据量，快照中仅存储完整块）

智能合约和链码

Hyperledger Fabric经常互换使用智能合约和链码这两个术语。一般来说，智能合约定义了控制世界状态中包含的业务对象的生命周期的事务逻辑。然后将其打包成链码，然后将其部署到区块链网络。将智能合约视为管理交易，而链码则管理如何打包智能合约以进行部署。

智能合约是在链码中定义的。可以在同一个链码中定义多个智能合约。部署链码后，其中的所有智能合约都可供应用程序使用。

智能合约以编程方式访问账本的两个不同部分——一个区块链，它永久地记录所有交易的历史，以及一个世界状态，它保存这些状态的当前值的缓存，因为它是对象的当前值。

每个智能合约都有与之相关的背书政策。此背书策略确定哪些组织必须批准智能合约生成的交易，然后才能将这些交易识别为有效。背书策略示例可能定义参与区块链网络的四个组织中的三个必须签署交易才能被视为有效。所有交易都有一个标识符、一个提案和一组组织签署的响应。所有交易，无论有效还是无效，都会添加到分布式账本中，但只有有效交易才会更新世界状态。

虽然智能合约代码安装在组织对等方的链代码包内，但通道成员只能在通道上定义链代码后才能执行智能合约。链码定义是一个结构体，其中包含控制链码如何运行的参数。这些参数包括链码名称、版本和背书策略。每个通道成员通过批准其组织的链码定义来同意链码的参数。当足够数量的组织（默认为大多数）批准相同的链码定义时，可以将该定义提交给通道。然后，链代码内的智能合约可以由通道成员执行，并遵守链代码定义中指定的背书策略。背书政策同样适用于同一链码中定义的所有智能合约。

智能合约可以调用同一通道内和不同通道内的其他智能合约。通过这种方式，他们可以读取和写入由于智能合约命名空间而无法访问的世界状态数据。

链码生命周期

Chaincode是一个用Go、Node.js或Java编写的程序，它实现了规定的接口。Chaincode在与背书peer进程隔离的安全Docker容器中运行。Chaincode通过应用程序提交的交易来初始化和管理账本状态。

Fabric链码生命周期是一个过程，允许多个组织在链码在通道上使用之前就如何操作链码达成一致。

Fabric链码生命周期要求组织同意定义链码的参数，例如名称、版本和链码背书策略。渠道成员通过以下四个步骤达成一致。不过并非渠道上的每个组织都需要完成每个步骤。
1. 打包链码：此步骤可以由一个组织完成，也可以由每个组织完成。
2. 在peer上安装链码：每个将使用链码来背书交易或查询账本的组织都需要完成此步骤。
3. 批准组织的链码定义：每个将使用链码的组织都需要完成此步骤。链码定义需要得到足够数量的组织的批准，以满足通道的LifecycleEndorsement策略（默认情况下为大多数组织），然后才能在通道上启动链码。
4. 将链码定义提交到通道：一旦通道上所需数量的组织获得批准，提交交易需要由一个组织提交。提交者首先从已批准的组织的足够多的同行那里收集背书，然后提交交易以提交链码定义。

私有数据

私有数据集合可以在链码定义中显式定义。此外，每个链码都有一个为组织特定的私有数据保留的隐式私有数据命名空间。

通道能力

不存在涵盖整个通道的单一功能级别。相反，存在三种功能，每种功能代表一个管理领域。
- orderer：这些功能管理排序服务专有的任务和处理。
- application：这些功能管理peer专有的任务和处理。
- channel：包含由peer组织和排序服务共同管理的任务。

如果使用推荐的流程创建通道（即无系统通道），则所有这些功能级别都在创建的应用程序通道创世块中指定。

安全模型

Hyperledger Fabric是一个经过许可的区块链，其中每个组件和参与者都有一个身份，并且策略定义访问控制和治理。
- Identities
- Membership Service Providers
- Policies
- Channel Policies
- Channel Modification Policies
- Access Control Lists
- Chaincode Lifecycle Policy
- Chaincode Endorsement Policies
- Peers
- Ordering service nodes
- Tranport Layer Security(TLS)
- Peer and Ordering service node operations service
- Hardware Security Modules
- Fabric Applications

教程

使用Fabric测试网络

直接启动测试网络：./network up
使用Certificate Authorities启动测试网络：./network.sh up -ca

部署智能合约到通道

使用Peer CLI通过以下步骤将资产传输（基本）链代码部署到通道

Setup Logspout（可选）

此步骤不是必需的，但对于链码故障排除非常有用。要监控智能合约的日志，管理员可以使用logspout工具查看一组Docke 容器的聚合输出。该工具将来自不同Docker容器的输出流收集到一个位置，从而可以轻松地从单个窗口查看发生的情况。

启动Logspout：./monitordocker.sh fabric_test

一开始不会看到任何日志，但当部署链代码时，情况会发生变化。

打包智能合约

安装智能合约依赖项，在asset-transfer-basic/chaincode-go目录运行：GO111MODULE=on go mod vendor，如果命令成功，go软件包将安装在vendor文件夹中。

设置环境变量

# 将CLI添加到环境变量
export PATH=${PWD}/../bin:$PATH
# 将FABRIC_CFG_PATH设置为指向fabric-samples/config中的core.yaml文件
export FABRIC_CFG_PATH=$PWD/../config/

使用peer CLI创建链代码包：peer lifecycle chaincode package basic.tar.gz --path ../asset-transfer-basic/chaincode-go/ --lang golang --label basic_1.0

安装链码包

因为将设置背书策略以要求Org1和Org2都背书，所以需要在两个组织运营的peer点上安装链码

设置环境变量

# 启用TLS
export CORE_PEER_TLS_ENABLED=true
# 以Org1身份操作peer CLI
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051
# 以Org2身份操作peer CLI
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051

分别运行以下命令安装链代码：peer lifecycle chaincode install basic.tar.gz

链码是在安装链码时由peer构建的。如果智能合约代码存在问题，安装命令将从链代码中返回任何构建错误。

批准链码定义

安装链码包后，需要批准组织的链码定义。该定义包括链码治理的重要参数，例如名称、版本和链码背书策略。

部署链代码之前需要批准的通道成员集由/Channel/Application/LifecycleEndorsement策略管理。默认情况下，此策略要求大多数通道成员需要批准链码才能在通道上使用。

Chaincode在组织级别获得批准，因此该命令只需针对一个peer节点。批准通过gossip协议分发给组织内的其他同事。使用对chaincode approveformyorg命令批准链码定义。

链代码的第一次调用需要以Init函数为目标并包含–isInit标志，然后才能使用链代码中的其他函数与账本交互。

将链码定义提交到通道

当足够数量的组织批准链码定义后，一个组织可以将链码定义提交到通道。如果大多数通道成员批准了该定义，则提交交易将成功，并且链码定义中商定的参数将在通道上实现。

可以使用chaincode checkcommitreadiness命令检查通道成员是否批准了相同的链码定义。由于通道成员的组织都批准了相同的参数，因此链码定义已准备好提交给通道。可以使用chaincode commit命令将链码定义提交到通道。提交命令还需要由组织管理员提交。

运行Fabric应用程序

客户端应用程序与Fabric Gateway服务建立gRPC连接，该连接将用于与区块链网络进行交易。为此，它只需要Fabric Gateway的端点地址，并且如果配置为使用TLS，则还需要适当的TLS证书。

建立与网关的gRPC连接

应用程序使用签名证书颁发机构的TLS证书创建gRPC连接，以便验证网关TLS证书的真实性。为了成功建立TLS连接，客户端使用的端点地址必须与网关TLS证书中的地址匹配。由于客户端通过localhost地址访问网关的Docker容器，因此指定了gRPC选项来强制将此端点地址解释为网关配置的主机名。

创建网关连接

应用程序创建一个Gateway连接，用于访问Fabric Gateway可访问的任何Networks（类似于通道），以及随后的智能Contracts部署到这些网络。Gateway连接具有三个要求：
- 与Fabric Gateway的gRPC连接
- 用于与网络进行交易的客户端身份
- 签名实现用于为客户端身份生成数字签名

访问要调用的智能合约

应用程序使用Gateway连接来获取对Network的引用，然后获取对该网络上部署的链码内的默认Contract的引用。

当链代码包包含多个智能合约时，可以提供链代码的名称和特定智能合约的名称作为 getContract() 调用的参数。

用样本资产填充账本

链码包初始部署后，账本立即为空。应用程序使用submitTransaction()调用InitLedger交易函数，该函数使用一些示例资产填充分类帐。submitTransaction()将使用FabricGateway来：
1. 批准交易提案
2. 将背书的交易提交给排序服务
3. 等待事务提交，更新账本状态

调用交易函数读写资产

应用程序使用evaluateTransaction()通过执行只读事务调用来查询账本。evaluateTransaction()将使用Fabric Gateway调用事务函数并返回其结果。交易不会发送到排序服务，也不会发生账本更新。

由于事务函数可以返回任何类型的数据，因此事务函数结果始终以字节形式返回。交易函数通常返回字符串，应用程序负责正确解释结果字节。

使用CouchDB

为了利用CouchDB的优势，即基于内容的JSON查询，您的数据必须以JSON格式建模。在设置网络之前，必须决定是使用LevelDB还是CouchDB。由于数据兼容性问题，不支持将peer节点从使用LevelDB切换到CouchDB。网络上的所有peer节点必须使用相同的数据库类型。

CouchDB作为一个单独的数据库进程与peer进程一起运行。CouchDB的Docker映像可用，建议它与peer在同一服务器上运行。需要为每个peer节点设置一个CouchDB容器，并通过更改core.yaml中的配置以指向CouchDB容器来更新每个peer节点容器。

在使用Docker环境时，可以传递环境变量来覆盖core.yaml属性，例如CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS来设置CouchDB地址

尽管使用CouchDB并不强制要求索引，为了利用CouchDB的主要优势（对JSON数据执行丰富查询的能力），强烈建议使用索引以提高性能。没有索引的JSON查询可能会起作用，但会在对等日志中发出未找到索引的警告。但是，如果丰富的查询包含排序规范，则需要该字段的索引；否则，查询将失败并抛出错误。

要定义索引，需要三个信息：
- fields：要查询的字段
- 名称：索引的名称
- 类型：在此上下文中始终为json

通道

创建通道

为了简化通道创建过程并增强通道的隐私性和可扩展性，现在只需要创建应用程序通道（发生涉及资产的交易），而无需首先创建由排序服务管理的系统通道。

生成通道的创世块
1. 设置configtxgen工具和configtx.yaml文件
2. 使用configtxgen工具构建创世块
使用osnadmin CLI将第一个排序者添加到通道：每个排序节点需要先进行环境变量的设置（证书文件位置），然后使用osnadmin channel join命令加入通道
将peer节点加入通道

使用configtx.yaml构建通道配置

Organizations：每个组织由MSPID和通道MSP标识。通道MSP存储在通道配置中，包含用于识别组织的节点、应用程序和管理员的证书。configtx.yaml文件的组织部分用于为通道的每个成员创建通道MSP以及随附的MSP ID。
Capabilities
- Application capabilities：管理peer节点使用的功能，例如Fabric链代码生命周期，并设置可以由加入通道的peer节点运行的Fabric二进制文件的最低版本。
- Orderer capabilities：管理排序器节点使用的功能，例如Raft共识，并设置可以通过属于通道同意器集的排序节点运行的Fabric二进制文件的最低版本。
- Channel capabilities：设置可以由peer节点和排序节点运行的Fabric的最低版本。
Application
- 这部分定义了管理peer组织如何与应用程序渠道交互的策略。这些策略控制需要批准链码定义或签署更新通道配置请求的对等组织的数量。这些策略还用于限制对通道资源的访问，例如写入通道账本或查询通道事件的能力。
- 测试网络使用Hyperledger Fabric提供的默认应用策略。如果您使用默认策略，所有对等组织都将能够读取数据并将数据写入账本。默认策略还要求大多数通道成员签署通道配置更新，并且大多数通道成员需要批准链码定义，然后才能将链码部署到通道。
Orderer
- 每个通道配置都包括通道同意者集中的排序者节点。同意者集是一组排序节点，它们能够创建新块并将其分发给加入通道的peer节点。作为同意者集成员的每个排序节点的端点信息存储在通道配置中。
- 同意者列表中的每个排序节点均由其端点地址及其客户端和服务器TLS证书标识。如果要部署多节点排序服务，则需要提供每个节点使用的主机名、端口和TLS证书的路径。
- Policies部分为创建管理渠道同意者集的策略。测试网络使用Fabric提供的默认策略，需要大多数排序者管理员批准添加或删除排序节点、组织或更新区块切割参数。
Channel
- 这部分定义了管理最高级别通道配置的策略。在应用程序通道中，这些策略控制哈希算法、用于创建新块的数据哈希结构以及通道能力级别。
- 测试网络使用Fabric提供的默认策略，该策略要求更改需要得到大多数订购者组织和大多数渠道成员的批准。大多数用户不需要更改这些值。
Profiles：configtxgen工具使用此配置创建一个创世块

Channel policies

Signature policies：默认情况下，每个通道成员都会定义一组引用其组织的签名策略。每个签名策略都有一个规则，指定其签名可以满足该策略的组织和身份的集合。
ImplicitMeta Policies：如果您的通道使用默认策略，则每个组织的签名策略将由通道配置更高级别的ImplicitMeta策略进行评估。

操作指南

Membership Service Providers(MSP)

默认MSP实现允许组织根据x509证书的OU将身份进一步分类为客户端、管理员、peer和orderer
- 客户端：如果一个身份在网络上进行交易，则应将其归类为客户端
- 管理员：如果身份处理管理任务（例如将peer节点加入通道或签署通道配置更新事务），则应将其归类为管理员
- peer：如果一个身份认可或提交交易，则应将其归类为peer
- orderer如果身份属于排序节点，则应将其归类为orderer

证书管理指南

Registration：存储在证书颁发机构(CA)中的用户名和密码对，该注册由CA管理员用户创建
Enrollment：由组织的证书颁发机构(CA)颁发的公钥/私钥对和X.509证书
Identity：公共证书及其用于加密的私钥
TLS：授权客户端和节点通信的公共传输层安全(TLS)证书
Hyperledger Fabric实现两种类型的证书：
- 用于身份的注册证书
- 用于节点和客户端通信的TLS证书
Enrollment Certificates分为四种类型：Admin, Peer, Orderer, Client

TLS证书允许Fabric节点和客户端对通信进行签名和加密，任何通道通信都需要有效的TLS证书。

Endorsement policies

每个链代码都有一个背书策略，该策略指定通道上必须执行链代码并背书执行结果的peer集合，以便交易被视为有效。这些认可政策定义了必须认可提案执行的组织。

通道成员在为其组织批准链码定义时同意链码级背书策略。足够数量的通道成员需要批准链码定义以满足Channel/Application/LifecycleEndorsement策略（默认情况下设置为大多数通道成员），然后才能将定义提交到通道。提交定义后，链码就可以使用了。任何将数据写入账本的链码调用都需要经过足够多的通道成员的验证才能满足背书策略。

如果不指定策略，链码定义将默认使用Channel/Application/Endorsement策略，该策略要求交易得到大多数通道成员的验证。

访问控制列表 (ACL)

策略可以采用以下两种方式之一构建：
- Signature策略：这样的策略标识必须签名才能满足策略的特定用户
- ImplicitMeta策略：ImplicitMeta策略聚合配置层次结构中更深层的策略结果，这些策略最终由Signature策略定义。他们支持“大多数组织管理员”等默认规则。与Signature策略相比，这些策略使用不同但仍然非常简单的语法，例如ANY ReadersorMAJORITY Admins

The Operations Service

peer节点和排序节点托管一个HTTP服务器，该服务器提供RESTful操作API。该API与Fabric网络服务无关，旨在由运营商使用，而不是网络管理员或“用户”

该API有着以下功能：
- Log level management
- Health checks
- Prometheus target for operational metrics (when configured)
- Endpoint for retrieving version information

Securing Communication With Transport Layer Security (TLS)

Fabric支持使用TLS进行节点之间的安全通信。TLS通信可以使用单向（仅服务器）和双向（服务器和客户端）身份验证。

Configuring TLS for peers nodes

peer节点既是peerTLSpeer服务器又是peerTLSpeer客户端。当另一个peer节点、应用程序或peerCLI与它建立连接时，它是前者；当它与另一个peer节点或排序者建立连接时，它是后者。

默认情况下，peer节点在充当TLS服务器和客户端时将使用相同的证书和私钥对。要为客户端使用不同的证书和私钥对，请将peer.tls.clientCert.file和peer.tls.clientKey.file配置属性分别设置为客户端证书和密钥文件的完全限定路径。

默认情况下，当在peer节点上启用TLS时，TLS客户端身份验证将关闭。这意味着peer节点在TLS握手期间不会验证客户端（另一个peer节点、应用程序或CLI）的证书。当peer节点上启用客户端身份验证时，客户端需要在TLS握手期间发送其证书。如果客户端不发送其证书，握手将失败，peer节点将关闭连接。

当peer节点加入通道时，将从通道的配置块中读取通道成员的根CA证书链，并将其添加到TLS服务器和客户端根CA数据结构中。因此，点对点通信、点对点通信应该无缝地进行。

Configuring TLS for orderer nodes

当orderer节点加入通道时，将从通道的配置块中读取通道成员的根CA证书链，并将其添加到TLS服务器和客户端根CA数据结构中。因此，orderer节点之间的沟通应该无缝进行。但是，如果需要，您可以通过设置General.TLS.RootCAs和General.TLS.ClientRootCAs添加其他根 CA 证书。

配置和运行Raft排序服务

Raft集群在两个地方进行配置：
- 本地配置：管理节点特定方面，例如TLS通信、复制行为和文件存储。
- 通道配置：为相应通道定义Raft集群的成员资格，以及协议特定参数，如心跳频率、领导者超时等。

架构参考

Transaction Flow

客户端发起交易
背书节点验证签名并执行交易
检查提案回复
目标节点将背书组装成交易
交易已验证并提交
更新账本

Fabric Gateway

Fabric Gateway管理以下事务步骤：
1. 评估交易提案。将在单个peer节点上调用智能合约（链码）函数并将结果返回给客户端。
2. 批准交易提案。将收集足够的背书响应以满足组合签名策略，并将准备好的交易信封返回给客户端进行签名。
3. 提交交易。将签名的交易信封发送到排序服务以提交到账本。
4. 等待提交状态事件。这允许客户端等待事务提交到账本并获取提交（验证/无效）状态代码。
5. 接收链码事件。这将允许客户端应用程序在事务提交到账本时响应智能合约功能发出的事件。

Service Discovery

从v2.4开始，Fabric Gateway与服务发现交互，以确定需要哪些peer节点来背书交易，以及将交易发送到哪些排序节点。因此，使用新网关SDK编写的客户端应用程序根本不直接与服务发现交互。

发现服务可以响应以下查询：
1. 配置查询：返回通道中所有组织的MSPConfig以及通道的排序节点端点。
2. 节点成员资格查询：返回已加入通道的节点。
3. 背书查询：返回通道中给定链码的背书描述符。
4. 本地peer成员资格查询：返回响应查询的peer的本地成员资格信息。

当peer节点在启用TLS的情况下运行时，客户端在连接到peer节点时必须提供TLS证书。如果对等方未配置为验证客户端证书（clientAuthRequired为false），则此TLS证书可以是自签名的。

Defining capability requirements

如通道功能中所述，功能要求是在通道配置（在通道的最新配置块中找到）中为每个通道定义的。通道配置包含三个位置，每个位置定义不同类型的能力。

Capability Type	Canonical Path	JSON Path
Channel	/Channel/Capabilities	.channel_group.values.Capability
Orderer	/Channel/Orderer/Capabilities	.channel_group.groups.Orderer.values.Capabilities
Application	/Channel/Application/Capabilities	.channel_group.groups.Application.values. Capabilities

Read-Write set semantics

在背书模拟交易期间，会为交易准备读写集。read set包含交易在模拟期间读取的唯一键及其提交版本号（但不是值）的列表，write set包含唯一键的列表（尽管可能与读取集中存在的键重叠）及其事务写入的新值。如果事务执行的更新是删除该键，则为该键设置删除标记（在新值的位置）。

Gossip数据传播协议

节点利用gossip以可扩展的方式广播账本和通道数据。gossip消息传递是连续的，通道上的每个peer节点都不断从多个peer节点接收当前且一致的账本数据。每条gossip消息都经过签名，从而使发送伪造消息的拜占庭参与者能够轻松识别，并防止将消息分发到不需要的目标。受到延迟、网络分区或其他导致丢失块的原因影响的节点最终将通过联系拥有这些丢失块的节点来同步到当前的账本状态。

基于gossip的数据传播协议在Fabric网络上执行三个主要功能：
- 通过不断识别可用的成员peer节点并最终检测已离线的peer节点来管理peer节点发现和通道成员资格。
- 在通道上的所有节点之间传播账本数据。任何数据与通道其余部分不同步的peer节点都会识别丢失的块，并通过复制正确的数据来同步自身。
- 通过允许账本数据的点对点状态传输更新，使新连接的peer节点加快速度。

领导者选举机制用于为每个组织选举一个peer节点，该peer节点将保持与排序服务的连接，并启动在其自己组织的peer节点之间分配新到达的块，利用领导者选举使系统能够有效利用排序服务的带宽。

领导者选举模块有两种可能的操作模式：
- Static：系统管理员手动将组织中的peer节点配置为领导者
- Dynamic：节点执行领导者选举程序来选择组织中的一个节点成为领导者
gossip利用锚节点来确保不同组织中的节点相互了解。一旦每个组织的至少一个peer节点联系了锚节点，锚节点就会了解通道中的每个peer节点。

由于跨组织的通信依赖于gossip才能发挥作用，因此通道配置中必须至少定义一个锚节点。强烈建议每个组织提供自己的一组锚点以实现高可用性和冗余。

命令参考

peer

peer version：查看版本信息
peer node：用于管理员启动peer节点、暂停和恢复通道、重建数据库、将peer节点中的所有通道重置到创世块、将通道回滚到给定的块号以及升级数据库格式
peer snapshot：用于管理员在peer节点上执行快照相关的操作，例如提交快照请求、取消快照请求和列出待处理的请求
peer channel：用于管理员对peer节点执行与通道相关的操作，例如加入通道或列出peer节点加入的通道
peer chaincode：用于管理员在peer节点上执行链码相关操作，例如安装、实例化、调用、打包、查询和升级链码
peer lifecycle chaincode：用于管理员使用Fabric链码生命周期来打包链码、将其安装在peer节点上、批准组织的链码定义，然后将该定义提交到通道。定义成功提交到通道后，链码就可以使用了

其他

osnadmin channel：用于管理员对排序者执行与通道相关的操作，例如加入通道、列出排序者已加入的通道以及删除通道
configtxgen：用于用户创建和检查与通道配置相关的材料。生成的材料内容由 configtx.yaml 的内容决定
configtxlator：用于用户在结构数据结构的protobuf和JSON版本之间进行转换并创建配置更新
cryptogen：用于生成Hyperledger Fabric密钥材料的程序。它是作为一种出于测试目的而预先配置网络的方法而提供的，通常不会用于生产网络
ledgerutil：用于对Fabric网络进行故障排除，如找到通道上peer节点的账本存在分歧的原因
discover：服务发现CLI

Fabric CA(Certificate Authority)

Fabric CA用户指南

Hyperledger Fabric CA是Hyperledger Fabric的证书颁发机构(CA)，它服务器和客户端组件组成。

它提供以下功能：
- 身份注册，或连接到LDAP作为用户注册表
- 颁发注册证书（ECerts）
- 证书更新和撤销

概述

有两种与Hyperledger Fabric CA服务器交互的方式：通过Hyperledger Fabric CA客户端或通过Fabric SDK之一。与Hyperledger Fabric CA服务器的所有通信均通过REST API进行。

入门

Fabric CA提供了3种方法来配置Fabric CA服务器和客户端上的设置。优先顺序是：
1. CLI flags
2. Environment variables
3. Configuration file

Fabric CA服务器和客户端配置文件中指定文件名的所有属性都支持相对路径和绝对路径。相对路径是相对于配置文件所在的config目录的。

Fabric CA Server

初始化Fabric CA server：fabric-ca-server init -b admin:adminpw
启动Fabric CA server：fabric-ca-server start -b <admin>:<adminpw>。如果服务器之前尚未初始化，它将在第一次启动时自行初始化。在此初始化过程中，服务器将生成ca-cert.pem和ca-key.pem文件（如果尚不存在），并且还会创建默认配置文件（如果不存在）。

安全警告：Fabric CA服务器应始终在启用TLS的情况下启动（tls.enabled 设置为true）。如果不这样做，服务器就容易受到有权访问网络流量的攻击者的攻击。

Fabric CA Client

需要先自定义客户端配置文件中的CSR，然后通过调用在7054端口本地运行的Fabric CA服务器来注册ID为admin、密码为adminpw的身份fabric-ca-client enroll -u http://admin:adminpw@localhost:7054

enroll命令将注册证书(ECert)、相应的私钥和CA证书链PEM文件存储在Fabric CA客户端的msp目录的子目录中。您将看到指示PEM文件存储位置的消息。

Fabric CA操作指南

设置TLS CA

TLS CA用于颁发TLS证书。为了确保各个进程之间的通信安全，需要这些证书。

在开始使用CA客户端之前，您必须获取CA的TLS证书的签名证书。这是使用TLS连接之前必需的步骤。