Hyperledger Fabric 通道配置文件解析

Hyperledger Fabric 通道配置文件解析

fabric 版本 v2.4.1

Fabric網絡是分佈式系統,採用通道配置(Channel Configuration)來定義共享賬本的各項行爲。通道配置的管理對於網絡功能至關重要。

通道配置一般包括通道全局配置、排序配置和應用配置等多個層級,這些配置都存放在通道的配置區塊內。通道全局配置定義該通道內全局的默認配置,排序配置和應用配置分別管理與排序服務相關配置和與應用組織相關配置。

用戶可採用configtx.yaml文件初始化通道配置,使用配置更新交易更新通道配置。

configtx.yaml配置文件一般包括若干字段:Organizations、Capabilities、Channel、Orderer、Application和Profiles。用戶可指定直接使用其中某個Profile,自動引用其他字段中的定義。

配置項 作用
Organizations 一系列組織的結構定義,包括名稱、MSP路徑、讀寫和管理權限、錨節點等,可被Profiles等部分引用
Capabilities 一系列能力定義,如通道、排序服務、應用等的能力,可被Channel等部分引用
Channel 定義通道相關的默認配置,包括讀寫和管理權限、能力等,可被Prof iles等部分引用
Orderer 與排序服務相關的配置,包括排序服務類型、地址、切塊時間和大小、參與排序服務的組織、權限和能力,可被Profiles等部分引用
Application 與應用通道相關的配置,主要包括默認訪問控制權限、參與應用網絡的組織、權限和能力,可被Prof iles等部分引用
Profiles 一系列的配置定義,包括指定排序服務配置、應用配置和聯盟配置等,直接被configtxgen工具指定使用

Organizations 部分

Organizations:

    # SampleOrg defines an MSP using the sampleconfig. It should never be used
    # in production but may be used as a template for other definitions.
    - &OrdererOrg
        # Name is the key by which this org will be referenced in channel
        # configuration transactions.
        # Name can include alphanumeric characters as well as dots and dashes.
        Name: OrdererOrg

        # SkipAsForeign can be set to true for org definitions which are to be
        # inherited from the orderer system channel during channel creation.  This
        # is especially useful when an admin of a single org without access to the
        # MSP directories of the other orgs wishes to create a channel.  Note
        # this property must always be set to false for orgs included in block
        # creation.
        SkipAsForeign: false

        # ID is the key by which this org's MSP definition will be referenced.
        # ID can include alphanumeric characters as well as dots and dashes.
        ID: OrdererMSP

        # MSPDir is the filesystem path which contains the MSP configuration.
        MSPDir: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/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('OrdererMSP.member')"
                # If your MSP is configured with the new NodeOUs, you might
                # want to use a more specific rule like the following:
                # Rule: "OR('SampleOrg.admin', 'SampleOrg.peer', 'SampleOrg.client')"
            Writers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
                # If your MSP is configured with the new NodeOUs, you might
                # want to use a more specific rule like the following:
                # Rule: "OR('SampleOrg.admin', 'SampleOrg.client')"
            Admins:
                Type: Signature
                Rule: "OR('OrdererMSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"

        # OrdererEndpoints is a list of all orderers this org runs which clients
        # and peers may to connect to to push transactions and receive blocks respectively.
        OrdererEndpoints:
            - "orderer0.example.com:7050"
            - "orderer1.example.com:8050"
            - "orderer2.example.com:9050"

        # AnchorPeers defines the location of peers which can be used for
        # cross-org gossip communication.
        #
        # NOTE: this value should only be set when using the deprecated
        # `configtxgen --outputAnchorPeersUpdate` command. It is recommended
        # to instead use the channel configuration update process to set the
        # anchor peers for each organization.
        #AnchorPeers:
        #    - Host: 127.0.0.1
        #      Port: 7051

    - &Org1

        Name: Org1MSP
        ID: Org1MSP
        MSPDir: /usr/project/fabric-docker-multiple/crypto-config/peerOrganizations/org1.example.com/msp
        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')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org1MSP.peer')"
        AnchorPeers:
            - Host: peer0.org1.example.com
              Port: 7051


    - &Org2

        Name: Org2MSP
        ID: Org2MSP
        MSPDir: /usr/project/fabric-docker-multiple/crypto-config/peerOrganizations/org2.example.com/msp
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org2MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org2MSP.peer')"
        AnchorPeers:
            - Host: peer0.org2.example.com
              Port: 7051
配置項 作用
Name 組織名稱
SkipAsForeign 指定在創建新通道時是否從系統通道內繼承該組織,configtxgen 會忽略從本地讀取
ID MSP 的 ID
MSPDir MSP 文件本地路徑
Policies.Readers 讀角色
Policies.Writers 寫角色
Policies.Admins 管理角色
Policies.Endorsement 背書策略
OrdererEndpoints 排序節點地址列表
AnchorPeers 錨節點地址,用於跨組織的 gossip 信息交換

Capabilities 部分

Capabilities字段主要定義一系列能力模板,分爲通道能力、排序服務能力和應用能力三種類型,可被其他部分引用.

################################################################################
#
#   CAPABILITIES
#
#   This section defines the capabilities of fabric network. This is a new
#   concept as of v1.1.0 and should not be utilized in mixed networks with
#   v1.0.x peers and orderers.  Capabilities define features which must be
#   present in a fabric binary for that binary to safely participate in the
#   fabric network.  For instance, if a new MSP type is added, newer binaries
#   might recognize and validate the signatures from this type, while older
#   binaries without this support would be unable to validate those
#   transactions.  This could lead to different versions of the fabric binaries
#   having different world states.  Instead, defining a capability for a channel
#   informs those binaries without this capability that they must cease
#   processing transactions until they have been upgraded.  For v1.0.x if any
#   capabilities are defined (including a map with all capabilities turned off)
#   then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
    # Channel capabilities apply to both the orderers and the peers and must be
    # supported by both.
    # Set the value of the capability to true to require it.
    Channel: &ChannelCapabilities
        # V2.0 for Channel is a catchall flag for behavior which has been
        # determined to be desired for all orderers and peers running at the v2.0.0
        # level, but which would be incompatible with orderers and peers from
        # prior releases.
        # Prior to enabling V2.0 channel capabilities, ensure that all
        # orderers and peers on a channel are at v2.0.0 or later.
        V2_0: true

    # Orderer capabilities apply only to the orderers, and may be safely
    # used with prior release peers.
    # Set the value of the capability to true to require it.
    Orderer: &OrdererCapabilities
        # V1.1 for Orderer is a catchall flag for behavior which has been
        # determined to be desired for all orderers running at the v1.1.x
        # level, but which would be incompatible with orderers from prior releases.
        # Prior to enabling V2.0 orderer capabilities, ensure that all
        # orderers on a channel are at v2.0.0 or later.
        V2_0: true

    # Application capabilities apply only to the peer network, and may be safely
    # used with prior release orderers.
    # Set the value of the capability to true to require it.
    Application: &ApplicationCapabilities
        # V2.0 for Application enables the new non-backwards compatible
        # features and fixes of fabric v2.0.
        # Prior to enabling V2.0 orderer capabilities, ensure that all
        # orderers on a channel are at v2.0.0 or later.
        V2_0: true
配置項 作用
Channel 通道範圍能力版本
Orderer 排序服務能力版本
Application 應用範圍能力版本

Channel 部分

默認的通道配置模板,包括讀寫和管理權限、能力等。主要被其他部分引用。完整的通道配置應該還包括應用和排序字段。

################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
    # Policies defines the set of policies at this level of the config tree
    # For Channel policies, their canonical path is
    #   /Channel/<PolicyName>
    Policies:
        # Who may invoke the 'Deliver' API
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        # Who may invoke the 'Broadcast' API
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        # By default, who may modify elements at this config level
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"


    # Capabilities describes the channel level capabilities, see the
    # dedicated Capabilities section elsewhere in this file for a full
    # description
    Capabilities:
        <<: *ChannelCapabilities
配置項 作用
Policies.Readers 通道讀角色權限,可獲取通道內信息和數據
Policies.Writers 通道寫角色權限,可以向通道內發送交易
Policies.Admins 通道管理員角色權限,可修改配置
Capabilities 引用通道默認的能力集合

Orderere 部分

Orderer字段定義與排序服務相關的配置,包括排序服務類型、地址、切塊時間和大小、最大通道數、參與排序服務的組織、權限和能力。

################################################################################
#
#   ORDERER
#
#   This section defines the values to encode into a config transaction or
#   genesis block for orderer related parameters.
#
################################################################################
Orderer: &OrdererDefaults

    # Orderer Type: The orderer implementation to start.
    # Available types are "solo", "kafka" and "etcdraft".
    OrdererType: etcdraft

    # Addresses used to be the list of orderer addresses that clients and peers
    # could connect to.  However, this does not allow clients to associate orderer
    # addresses and orderer organizations which can be useful for things such
    # as TLS validation.  The preferred way to specify orderer addresses is now
    # to include the OrdererEndpoints item in your org definition
    Addresses:
        - orderer0.example.com:7050
        - orderer1.example.com:8050
        - orderer2.example.com:9050

    # Batch Timeout: The amount of time to wait before creating a batch.
    BatchTimeout: 2s

    # Batch Size: Controls the number of messages batched into a block.
    # The orderer views messages opaquely, but typically, messages may
    # be considered to be Fabric transactions.  The 'batch' is the group
    # of messages in the 'data' field of the block.  Blocks will be a few kb
    # larger than the batch size, when signatures, hashes, and other metadata
    # is applied.
    BatchSize:

        # Max Message Count: The maximum number of messages to permit in a
        # batch.  No block will contain more than this number of messages.
        MaxMessageCount: 500

        # Absolute Max Bytes: The absolute maximum number of bytes allowed for
        # the serialized messages in a batch. The maximum block size is this value
        # plus the size of the associated metadata (usually a few KB depending
        # upon the size of the signing identities). Any transaction larger than
        # this value will be rejected by ordering.
        # It is recommended not to exceed 49 MB, given the default grpc max message size of 100 MB
        # configured on orderer and peer nodes (and allowing for message expansion during communication).
        AbsoluteMaxBytes: 10 MB

        # Preferred Max Bytes: The preferred maximum number of bytes allowed
        # for the serialized messages in a batch. Roughly, this field may be considered
        # the best effort maximum size of a batch. A batch will fill with messages
        # until this size is reached (or the max message count, or batch timeout is
        # exceeded).  If adding a new message to the batch would cause the batch to
        # exceed the preferred max bytes, then the current batch is closed and written
        # to a block, and a new batch containing the new message is created.  If a
        # message larger than the preferred max bytes is received, then its batch
        # will contain only that message.  Because messages may be larger than
        # preferred max bytes (up to AbsoluteMaxBytes), some batches may exceed
        # the preferred max bytes, but will always contain exactly one transaction.
        PreferredMaxBytes: 2 MB

    # Max Channels is the maximum number of channels to allow on the ordering
    # network. When set to 0, this implies no maximum number of channels.
    MaxChannels: 0

    Kafka:
        # Brokers: A list of Kafka brokers to which the orderer connects. Edit
        # this list to identify the brokers of the ordering service.
        # NOTE: Use IP:port notation.
        Brokers:
            - kafka0:9092
            - kafka1:9092
            - kafka2:9092

    # EtcdRaft defines configuration which must be set when the "etcdraft"
    # orderertype is chosen.
    EtcdRaft:
        # The set of Raft replicas for this network. For the etcd/raft-based
        # implementation, we expect every replica to also be an OSN. Therefore,
        # a subset of the host:port items enumerated in this list should be
        # replicated under the Orderer.Addresses key above.
        Consenters:
            - Host: orderer0.example.com
              Port: 7050
              ClientTLSCert: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt
              ServerTLSCert: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt
            - Host: orderer1.example.com
              Port: 8050
              ClientTLSCert: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
              ServerTLSCert: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
            - Host: orderer2.example.com
              Port: 9050
              ClientTLSCert: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
              ServerTLSCert: /usr/project/fabric-docker-multiple/crypto-config/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt

        # Options to be specified for all the etcd/raft nodes. The values here
        # are the defaults for all new channels and can be modified on a
        # per-channel basis via configuration updates.
        Options:
            # TickInterval is the time interval between two Node.Tick invocations.
            TickInterval: 500ms

            # ElectionTick is the number of Node.Tick invocations that must pass
            # between elections. That is, if a follower does not receive any
            # message from the leader of current term before ElectionTick has
            # elapsed, it will become candidate and start an election.
            # ElectionTick must be greater than HeartbeatTick.
            ElectionTick: 10

            # HeartbeatTick is the number of Node.Tick invocations that must
            # pass between heartbeats. That is, a leader sends heartbeat
            # messages to maintain its leadership every HeartbeatTick ticks.
            HeartbeatTick: 1

            # MaxInflightBlocks limits the max number of in-flight append messages
            # during optimistic replication phase.
            MaxInflightBlocks: 5

            # SnapshotIntervalSize defines number of bytes per which a snapshot is taken
            SnapshotIntervalSize: 16 MB

    # Organizations lists the orgs participating on the orderer side of the
    # network.
    Organizations:

    # Policies defines the set of policies at this level of the config tree
    # For Orderer policies, their canonical path is
    #   /Channel/Orderer/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        # BlockValidation specifies what signatures must be included in the block
        # from the orderer for the peer to validate it.
        BlockValidation:
            Type: ImplicitMeta
            Rule: "ANY Writers"

    # Capabilities describes the orderer level capabilities, see the
    # dedicated Capabilities section elsewhere in this file for a full
    # description
    Capabilities:
        <<: *OrdererCapabilities
配置項 作用 默認值
OrdererType 要啓動的 orderer 類型,支持 solo , kafka , etcdraft solo
Addresses 排序服務地址列表 N/A
BatchTimeout 切塊最大超時時間 2s
BatchSize 控制寫入區塊交易個數 N/A
BatchSize.MaxMessageCount 一批消息最大個數 500
BatchSize.AbsoluteMaxBytes batch 最大字節數,任何時候不能超過 10 MB
BatchSize.PreferredMaxBytes 通常情況下切塊大小,極端情況下(比如單個消息就超過)允許超過 2 MB
MaxChannels 最大支持的應用通道數,0 表示無限 0
Kafka 採用 Kafka 類型共識時相關配置,僅在 1.x 版本中使用 N/A
EtcdRaft 採用 EtcdRaft 類型共識時相關配置,推薦在 2.x 版本中使用
EtcdRaft.Consenters 共識節點地址 N/A
EtcdRaft.Options.TickInterval etcd 集羣當作一次 tick 的時間,心跳或選舉都以 tick 爲基本單位 500ms
EtcdRaft.Options.ElectionTick follower 長時間收不到 leader 消息後,開始新一輪選舉的時間間隔 10
EtcdRaft.Options.HeartbeatTick 兩次心跳之間的間隔,必須小於選舉時間 1
EtcdRaft.Options.MaxInflightBlocks 複製過程中最大的傳輸中的區塊消息個數 5
EtcdRaft.Options.SnapshotIntervalSize 每次快照間隔的大小 16 MB
Organizations 維護排序服務組織,默認爲空,可以在 Profile 中自行定義 N/A
Capabilities 引用排序服務默認的能力集合 <<: *OrdererCapabilities

Application 部分

定義了與應用通道相關的配置,包括默認訪問控制權限、參與應用網絡的組織、權限和能力。可被Profiles部分引用.

################################################################################
#
#   APPLICATION
#
#   This section defines the values to encode into a config transaction or
#   genesis block for application-related parameters.
#
################################################################################
Application: &ApplicationDefaults
    ACLs: &ACLsDefault
        # This section provides defaults for policies for various resources
        # in the system. These "resources" could be functions on system chaincodes
        # (e.g., "GetBlockByNumber" on the "qscc" system chaincode) or other resources
        # (e.g.,who can receive Block events). This section does NOT specify the resource's
        # definition or API, but just the ACL policy for it.
        #
        # Users can override these defaults with their own policy mapping by defining the
        # mapping under ACLs in their channel definition

        #---New Lifecycle System Chaincode (_lifecycle) function to policy mapping for access control--#

        # ACL policy for _lifecycle's "CheckCommitReadiness" function
        _lifecycle/CheckCommitReadiness: /Channel/Application/Writers

        # ACL policy for _lifecycle's "CommitChaincodeDefinition" function
        _lifecycle/CommitChaincodeDefinition: /Channel/Application/Writers

        # ACL policy for _lifecycle's "QueryChaincodeDefinition" function
        _lifecycle/QueryChaincodeDefinition: /Channel/Application/Writers

        # ACL policy for _lifecycle's "QueryChaincodeDefinitions" function
        _lifecycle/QueryChaincodeDefinitions: /Channel/Application/Writers

        #---Lifecycle System Chaincode (lscc) function to policy mapping for access control---#

        # ACL policy for lscc's "getid" function
        lscc/ChaincodeExists: /Channel/Application/Readers

        # ACL policy for lscc's "getdepspec" function
        lscc/GetDeploymentSpec: /Channel/Application/Readers

        # ACL policy for lscc's "getccdata" function
        lscc/GetChaincodeData: /Channel/Application/Readers

        # ACL Policy for lscc's "getchaincodes" function
        lscc/GetInstantiatedChaincodes: /Channel/Application/Readers

        #---Query System Chaincode (qscc) function to policy mapping for access control---#

        # ACL policy for qscc's "GetChainInfo" function
        qscc/GetChainInfo: /Channel/Application/Readers

        # ACL policy for qscc's "GetBlockByNumber" function
        qscc/GetBlockByNumber: /Channel/Application/Readers

        # ACL policy for qscc's  "GetBlockByHash" function
        qscc/GetBlockByHash: /Channel/Application/Readers

        # ACL policy for qscc's "GetTransactionByID" function
        qscc/GetTransactionByID: /Channel/Application/Readers

        # ACL policy for qscc's "GetBlockByTxID" function
        qscc/GetBlockByTxID: /Channel/Application/Readers

        #---Configuration System Chaincode (cscc) function to policy mapping for access control---#

        # ACL policy for cscc's "GetConfigBlock" function
        cscc/GetConfigBlock: /Channel/Application/Readers

        # ACL policy for cscc's "GetChannelConfig" function
        cscc/GetChannelConfig: /Channel/Application/Readers

        #---Miscellaneous peer function to policy mapping for access control---#

        # ACL policy for invoking chaincodes on peer
        peer/Propose: /Channel/Application/Writers

        # ACL policy for chaincode to chaincode invocation
        peer/ChaincodeToChaincode: /Channel/Application/Writers

        #---Events resource to policy mapping for access control###---#

        # ACL policy for sending block events
        event/Block: /Channel/Application/Readers

        # ACL policy for sending filtered block events
        event/FilteredBlock: /Channel/Application/Readers

    # Organizations lists the orgs participating on the application side of the
    # network.
    Organizations:

    # Policies defines the set of policies at this level of the config tree
    # For Application policies, their canonical path is
    #   /Channel/Application/<PolicyName>
    Policies: &ApplicationDefaultPolicies
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

    # Capabilities describes the application level capabilities, see the
    # dedicated Capabilities section elsewhere in this file for a full
    # description
    Capabilities:
        <<: *ApplicationCapabilities
配置項 作用
_lifecycle 指定新的 _lifecycle 系統鏈碼的提交,查詢方法的默認策略
lscc lscc (Lifecycle System Chaincode) 系統鏈碼的方法調用權限
qscc qscc (Query System Chaincode) 系統鏈碼的方法調用權限
cscc cscc (Configuration System Chaincode) 系統鏈碼的方法調用權限
peer 通道內鏈碼調用權限
event 接收區塊事件權限

Profiles 部分

Profiles 字段定義了一系列的配置模板,每個模板代表了特定應用場景下的自定義的通道配置,可以用來創建系統通道或應用通道。配置模板中可以包括ApplicationCapabilitiesConsortiumConsortiumsPoliciesOrderer等配置字段,根據使用目的不同,一般只包括部分字段。

除了通道默認的配置,創建系統通道初始區塊的模板一般需要包括OrdererConsortiums字段信息(也可以包括Applicaion字段定義初始應用通道配置):

● Orderer,指定Orderer系統通道自身的配置信息。包括排序服務配置(類型、地址、批處理限制、Kafka信息、最大應用通道數目等),參與此Orderer的組織信息。網絡啓動時,必須首先創建Orderer系統通道。

● Consortiums,Orderer所服務的聯盟列表。每個聯盟中組織彼此使用相同的通道創建策略,可以彼此創建應用通道。

應用通道模板中一般至少包括Application、Consortium字段信息(Orderer信息從系統通道自動複製):

● Application,指定屬於應用通道的配置信息。主要包括屬於通道的組織、能力、ACL和策略信息。

● Consortium,該應用通道所關聯的聯盟信息,可以包括一系列組織。

一般建議將Prof ile分爲Orderer系統通道配置(至少包括指定Orderers和Consortiums)和應用通道配置(至少包括指定Applications和Consortium)兩種。

注意:在YAML文件中,&KEY所定位的字段信息,可以通過<<:KEY語法來引用,相當於導入定位部分的內容。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章