Hyperledger Fabric/Fabric-samples 安装及使用（Mac）

Posted 2023-04-04 被代码耽误的演员

因为未找到mac相关的安装方式，故根据优秀博主的文档以及本人安装、使用的经验整理此文。

1.安装清单

• brew
• Git
• cUrl
• docker
• docker-compose
• GoLang
• Fabric
• Fabric-samples

2.开始安装

2.1 Git

mac自带git，也可自行安装：brew install git

2.2 curl

brew install curl

2.3 docker

brew install docker

2.4 docker-compose

无需操作，docker安装完成后，也含有了docker-compose

以上安装细节也可自行百度，网上都有^.^

2.5 GoLang

1> 下载 Golang

• 照旧使用brew install go

2> 配置环境变量

• vi ~/.bash_profile
• 在最后一行写入：

export PATH=/usr/local/Cellar/go@1.13/1.13.15/bin:$PATH

• 刷新环境变量 source ~/.bash_profile

3> 使用go verison查看环境变量是否生效

xiaomanong@xiaomanongdeMacBook-Pro ~ % go version
go version go1.13.15 darwin/amd64

2.6 fabric

1> 创建目录并进入

mkdir -p ~/go/src/github.com/hyperledger
cd ~/go/src/github.com/hyperledge

2> 拉取fabric源码

git clone https://github.com/hyperledger/fabric.git

也可通过浏览器打开git地址，自行下载源码。
3> 切换到指定分支

cd ./fabric
查看分支：git branch -a 
切换分支: git checkout release-1.4

2.7 fabric-samples

1> docker配置镜像加速
可参考：Mac下Docker镜像加速

2> 拉取依赖
在 fabric/scripts 目录下找到 bootstrap.sh 脚本，复制到与 fabric 同级目录下，执行脚本（需要有VPN）：

./bootstrap.sh 1.4.12 1.4.9 0.4.22

该脚本做的事情：

• 如果当前目录没有 hyperledger/fabric-samples，会从 github.com 克隆 hyperledger/fabric-samples 存储库；
• 使用 checkout 签出对应指定的版本标签；
• 将指定版本的 Hyperledger Fabric 平台特定的二进制文件和配置文件安装到 fabric-samples 存储库的根目录中；
• 下载指定版本的 Hyperledger Fabric Docker 镜像文件;
• 将下载的 Docker 镜像文件标记为 “lastest"。

注意：执行脚本输入的版本号不通，下载的fabric-samples版本就不同，新版本的fabric-samples中没有first-network文件夹，我本地的Fabric网络是通过first-network启动的所以需要用到。

由于我的mac使用的vpn不适用到终端中，所以第三步需要手动在浏览器下载操作：
https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric/hyperledger-fabric
https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric-ca/hyperledger-fabric-ca

下载的 hyperledger-fabric-darwin-amd64-1.4.12.tar.gz压缩包内有 bin 和 config 两个文件夹， hyperledger-fabric-ca-darwin-amd64-1.4.9.tar.gz压缩包内有 bin 文件夹，将两个 bin 文件夹内的二进制文件汇总在一个 bin 文件夹内。 最后将 bin 和 config 文件夹复制到 fabric-samples 文件夹内。
Linux系统需要注释下图中执行binariesInstall的这行代码，并重新执行./bootstrap.sh 1.4.12 1.4.9 0.4.22

3> 设置环境变量

启动 fabric-samples/first-network 网络所需二进制文件的默认路径为 fabric-samples/bin，可以将该路径添加入环境变量中：

vim ~/.bash_profile
export PATH=$PATH:/Users/xiaomanong/Documents/tool/fabric/go/src/github.com/hyperledger/fabric-samples/bin
source ~/.bash_profile

测试环境变量是否生效：

xiaomanong@xiaomanongdeMacBook-Pro ~ % fabric-ca-client version
fabric-ca-client:
 Version: 1.4.9
 Go version: go1.14.10
 OS/Arch: darwin/amd64

4> 生成证书
进入first-network目录，使用byfn.sh脚本生成证书

cd ./fabric-samples/first-network/ && ./byfn.sh generate

5> 测试网络

1. 启动网络

cd ./fabric-samples/first-network/ && ./byfn.sh up

启动时间会比较长，最终出现一个“END”日志表示启动成功，可通过docker ps命令可以查看到节点的启动情况。

注意：该命令会检查网络实体的证书是否生成，如果没有会先生成证书。因此，可以直接执行 ./byfn.sh up 命令，而无需执行 ./byfn.sh generate 命令。

2. 关闭网络

cd ./fabric-samples/first-network/ && ./byfn.sh down

通过docker ps命令可看到各个镜像已停止并销毁。

---

安装合约流程

1. 进入first-network目录，修改docker-compose-cli.yaml文件

• 在最后的volumes中增加自己的项目映射：

   - /Users/xxx/Documents/MyProject/czkj/projects:/opt/gopath/src/github.com/hyperledger/fabric/peer/chaincode
  

2. 重新启动网络frist-network
   ./byfn.sh down&&./byfn.sh up
3. 进入hyperledger/fabric-tools:latest容器
   docker ps; docker exec -it xx /bin/bash
4. 查看当前目录下是否存在chaincode目录，进入chaincode目录查看是否为合约的工程目录
5. 确认无误后执行脚本（我的是进入testCommands目录，执行./installAllChainCode4SinglePeer.sh脚本），安装并部署启动合约相关服务

---

个人遇到的问题:

启动服务，代码报health相关的错误时，可能是没有启动心跳检测节点，需要修改fabric-samples/first-network/base下的两个yaml文件。

• 在peer-base.yaml文件和docker-compose-base.yam文件的orderer.example.com中的environment增加：

 - CORE_OPERATIONS_LISTENADDRESS=0.0.0.0:9443

• 在docker-compose-base.yam各个节点中增加对应的port
• 重启网络：./byfn.sh down&&./byfn.sh up

参考：
Hyperledger中文文档
Fabric1.4：运行 first-network 网络
Hyperledger Fabric1.4 安装（大部分流程参考此文档整理）

菜鸟系列Fabric——Fabric 网络架构介绍

Fabric 网络架构介绍

1. 网络架构介绍

如图所示，fabric网络架构主要包含客户端节点、CA节点、Peer节点、Orderer节点这几个部分。并且fabric架构是安装组织来进行划分当，每个组织都维护不同功能的peer节点。orderer节点属于整个联盟，一般不属于某个组织。

其中，各个节点功能如下：

• CA节点
  功能：Fabric网络中的成员提供基于数字证书的身份信息。可选。可以用第三方生成的证书
• 客户端节点
  功能：与Fabric区块链交互，实现对区块链的操作。常见cli容器及SDK客户端。客户端代表代表最终用户的实体。它必须连接到peer与区块链进行通信。客户端可以连接到其选择的任何peer。客户端创建交易。
• Peer节点
  fabric每个组织都包含一个huoz多个peer节点。每个节点可以担任多种角色。
  • Endorser Peer（背书节点）
    功能：对客户端发送交易提案时进行签名背书，充当背书节点的角色 。背书(Endorsement)是指特定Peer节点执行交易并向生成交易提案( proposal )的客户端应用程序返回YES/NO响应的过程。背书节点是动态的角色在链码实例化的时设置背书策略(Endorsement policy)，指定哪些节点对交易背书才有效。只有在背书时是背书节点，其他时刻是普通节点。
  • Leader Peer（主节点）
    功能：主要负责与orderer排序节点通信，获取区块及在本组织进行同步。主节点的产生可以动态选举或者指定。
    core.yaml useLeaderElection: true orgLeader: false
  • Committer Peer（记账节点）
    功能：对区块及区块交易进行验证，验证通过后将区块写入账本中。
  • Anchor Peer（锚节点）
    功能：主要负责与其他组织的锚节点进行通信。
• Orderer节点
  功能：排序服务节点接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给Peer节点。排序服务提供的是原子广播，保证同一个链上的节点为接收到相同的消息，并且有相同的逻辑顺序。

2.多通道设计

在Fabric中，引入了通道的概念。

一般情况下，一条区块链网路的子链是按照“1个通道+ 1个账本+ N个成员 ”的基本组成。

通道是两个或多个特定网络成员之间的通信的私有“子网”，用于进行需要数据保密的交易。在Fabric中，建立一个通道相当于建立了一个个子链。

创建通道是为了限制信息传播的范围，是和某一个账本关联的。每个交易都是和唯一的通道关联的。这会明确地定义哪些实体（组织及其成员）会关注这个交易。

2.1Fabric多通道设计拓扑图

如图所示，存在3个通道，每个通道包含不同的peer。通道是共识服务提供的一种通讯机制，基于发布-订阅关系，将Peer节点和排序节点根据某个Topic连接在一起，形成一个具有保密性的通讯链路（虚拟），实现业务隔离的要求。
排序服务提供了供Peer节点订阅的主题（如发布-订阅消息队列），每个主题是一个通道。Peer节点可以订阅多个通道，并且只能访问自己所订阅通道上的交易，因此一个Peer节点可以通过接入多个通道参与到多条链中。
目前通道分为系统通道（System Channel）和应用通道（Application Channel）。排序服务通过系统通道来管理应用通道，用户的交易信息通过应用通道传递。

在创建通道的时候就定义了多个组织，每个组织一般包含多个peer，这些peer实体的msp证书都可以追溯到组织的证书。并且每个组织还定义了对应锚节点（anchor peer），通过锚节点来和其他组织锚节点通信。其相关配置都在configtx.yaml文件中，即在通道创世块中。并且在后续如果想增加组织/成员/排序节点都可以通过修改配置块来实现。

    - &Org1
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org1MSP

        # ID to load the MSP definition as
        ID: Org1MSP

        MSPDir: crypto-config/peerOrganizations/org1.example.com/msp

        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org1MSP.admin')"

        # leave this flag set to true.
        AnchorPeers:
            # AnchorPeers defines the location of peers which can be used
            # for cross org gossip communication.  Note, this value is only
            # encoded in the genesis block in the Application section context
            - Host: peer0.org1.example.com
              Port: 7051

    # 系统通道定义
    TwoOrgsOrdererGenesis:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    # 应用通道定义
    TwoOrgsChannel:
        Consortium: SampleConsortium
        <<: *ChannelDefaults
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities:
                <<: *ApplicationCapabilities

3.交易流程

Fabric区块链的交易分两种，部署交易和调用交易。
部署交易把链码部署到Peer节点上并准备好被调用，当一个部署交易成功执行时，链码就被部署到各个背书节点上。
调用交易是客户端应用程序通过Fabric提供的API调用先前已部署好的某个链码的某个函数执行交易，并相应地读取和写入KV数据库，返回是否成功或者失败

典型的交易图如图所示。

交易流程图如图所示，其基本步骤为：

1. 客户端构建交易提案并发送给一个或多个背书节点。
   消息格式：
   ```
   PROPOSE消息的格式是<PROPOSE,tx,[anchor]>，以下 tx是必需和anchor可选参数
   tx=<clientID,chaincodeID,txPayload,timestamp,clientSig>
   clientID 是提交客户端的ID，
   chaincodeID 指交易所涉及的链码，
   txPayload 是包含提交的事务本身的有效负载，
   timestamp 是由客户端维护的单调递增（对于每个新事务）整数，
   clientSig是客户端的签名

   txPayload调用事务和部署事务之间的细节将有所不同（即，调用引用特定于部署的系统链代码的事务）。
   对于调用交易， txPayload将包含两个字段
   txPayload = <operation, metadata>
   operation 表示链代码操作（函数）和参数
   metadata 表示与调用相关的属性。
   对于部署交易，txPayload将包含三个字段
   txPayload = <source, metadata, policies>
   source 表示链码的源代码，
   metadata 表示与链代码和应用程序相关的属性，
   policies包含与所有对等方都可访问的链代码相关的策略
   ```

2. 背书节点模拟执行交易及签名
   背书节点（endorser）收到交易提案后，验证签名并确定提交者是否有权执行操作。背书节点将交易提案的参数作为输入，在当前状态KV数据库上执行交易，生成包含执行返回值、读操作集和写操作集的交易结果（此时不会更新账本），交易结果集、背书节点的签名和背书结果（支持/拒绝）作为提案的结果返回给客户端。
   读写集：
   对于交易k读取的每个密钥，将对(k,s(k).version)添加到readset。
   对于交易k修改为新值的每个键v‘，(k,v‘)都会添加对writeset
   请注意，背书在此步骤中不会更改其状态，由交易模拟生成的更新不会影响状态！

3. 客户端把交易发送到排序服务节点
   客户端收到背书（Endorser）节点返回的信息后，判断提案结果是否一致，以及是否参照指定的背书策略执行，如果没有足够的背书，则中止处理；否则，客户端把数据打包到一起组成一个交易并签名，发送给Orderers。

4. 共识排序，生成新区块及Committer节点确认
   Orderers对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交（Committer）节点；提交（Committer）节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改世界状态。