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

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）节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改世界状态。

有兴趣的关注IT程序员客栈哦