Rookie Series Fabric - Fabric Network Architecture introduced (4)

Fabric network architecture introduced

1. Introduction Network Architecture

As shown, fabric network architecture mainly includes the client node, CA node, Peer node, Orderer node these parts. And the fabric is installed when the tissue to be divided, each organization maintains peer nodes in different functions. orderer node belongs to the coalition, generally do not belong to an organization.

Wherein each node functions as follows:

  • CA node
    function: Fabric network members to provide information on the identity of the digital certificate. Optional. You can use third-party generated certificates
  • The client node
    function: Fabric and block chain interaction, realize the operation of the block chain. Common cli container and SDK clients. Client representatives of end-user entity. It must be connected to the block chain to communicate peer. The client can connect to any selected its peer. The client creates transaction.
  • Peer node
    fabric comprising a plurality of each organization huoz peer nodes. Each node can serve a variety of roles.
    • Endorser Peer (endorsement node)
      function: when the customer sends to sign an endorsement deal proposals, act as an endorsement node. Endorsement (Endorsement) means to perform a transaction-specific Peer node generates a transaction proposal (Proposal) the client application process returns YES / NO response. Endorsement node is a dynamic role in setting policy endorsement (Endorsement policy) at the instance of the chain code, specify which nodes are valid for endorsement deal. Only when the endorsement is an endorsement node, other times an ordinary node.
    • Leader Peer (master node)
      Function: orderer node is responsible for communicating with a sort, and sync acquisition block in the organization. The master node may be dynamically generated or specified election.
      core.yaml useLeaderElection: true orgLeader: false
    • Committer Peer (accounting node)
      Function: for blocks and blocks to authenticate transactions, verify the books written by after the blocks.
    • Anchor Peer (anchor node)
      Function: mainly responsible for communication with the anchor node other organizations.
  • Orderer node
    functions: ordering service node receives transaction included endorsement signatures for transactions unpacked ranking generation block, broadcast to Peer node. Ordered atomic broadcast service provided to ensure that a node on the same chain receive the same message, and have the same logical order.

2. Multi-channel design

In Fabric, we introduced the concept of the channel.

In general, the daughter strand is a network block chain in accordance with "1 + 1 channel members of accounts + N" basic composition.

Channel is a private "subnet" communication between two or more members of a particular network, confidential data needed for the transaction. In Fabric, create a channel equivalent to the establishment of a sub-chain.

Create a channel to limit the scope of dissemination of information, and is associated with certain books. Each transaction is unique and the associated channel. This will clearly define which entities (organizations and their members) are concerned about the deal.

Multi-channel design topology 2.1Fabric

As shown, there are three channels, each channel contains a different peer. Channel is a service provided by communication mechanism consensus, based publish - subscribe relationship, connecting node and sort Peer node according to a Topic together to form a confidential communication link (virtual), service isolation requirements.
Ordering service provides for Peer node subscribed threads (such as publish - subscribe message queue), each topic is a channel. Peer node may subscribe to a plurality of channels, and can only access their own transactions in the subscription channel, a Peer node may thus participate in the plurality of access chains by a plurality of channels.
The current channel into the channel system (System Channel) channels and applications (Application Channel). Sorting through the system service channel to channel management application, the user's transaction information passed through the 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)节点收到区块后,会对区块中的每笔交易进行校验,检查交易依赖的输入输出是否符合当前区块链的状态,完成后将区块追加到本地的区块链,并修改世界状态。

Guess you like

Origin www.cnblogs.com/jiliguo/p/11367612.html