# Copyright IBM Corp. All Rights Reserved. # # SPDX-License-Identifier: Apache-2.0 # --- ################################################################################ # # ORGANIZATIONS # # This section defines the organizational identities that can be referenced # in the configuration profiles. # ################################################################################ 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. - &SampleOrg # 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: SampleOrg # 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: SampleOrg # MSPDir is the filesystem path which contains the MSP configuration. MSPDir: msp # Policies defines the set of policies at this level of the config tree # For organization policies, their canonical path is usually # /Channel/// Policies: &SampleOrgPolicies Readers: Type: Signature Rule: "OR('SampleOrg.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('SampleOrg.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('SampleOrg.admin')" Endorsement: Type: Signature Rule: "OR('SampleOrg.member')" # 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. AnchorPeers: - Host: 127.0.0.1 Port: 7051 # 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 # 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. # Used by configtxgen MSPDir: 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/// 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')" Admins: Type: Signature Rule: "OR('OrdererMSP.admin')" - &Org1 # 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: Org1MSP # 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: Org1MSP # MSPDir is the filesystem path which contains the MSP configuration. # Used by configtxgen 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/// Policies: &Org1Policies Readers: Type: Signature Rule: "OR('Org1MSP.member')" # If your MSP is configured with the new NodeOUs, you might # want to use a more specific rule like the following: # Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')" Writers: Type: Signature Rule: "OR('Org1MSP.member')" # If your MSP is configured with the new NodeOUs, you might # want to use a more specific rule like the following: # Rule: "OR('Org1MSP.admin', 'Org1MSP.client')" Admins: Type: Signature Rule: "OR('Org1MSP.admin')" Endorsement: Type: Signature Rule: "OR('Org1MSP.member')" # 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. AnchorPeers: - Host: peer0.org1.example.com Port: 7051 - &Org2 # 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: Org2MSP # 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: Org2MSP # MSPDir is the filesystem path which contains the MSP configuration. # Used by configtxgen MSPDir: crypto-config/peerOrganizations/org2.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/// Policies: &Org2Policies Readers: Type: Signature Rule: "OR('Org2MSP.member')" # If your MSP is configured with the new NodeOUs, you might # want to use a more specific rule like the following: # Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')" Writers: Type: Signature Rule: "OR('Org2MSP.member')" # If your MSP is configured with the new NodeOUs, you might # want to use a more specific rule like the following: # Rule: "OR('Org2MSP.admin', 'Org2MSP.client')" Admins: Type: Signature Rule: "OR('Org2MSP.admin')" Endorsement: Type: Signature Rule: "OR('Org2MSP.member')" # 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. AnchorPeers: - Host: peer0.org2.example.com Port: 7051 - &Org3 # 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: Org3MSP # 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: Org3MSP # MSPDir is the filesystem path which contains the MSP configuration. # Used by configtxgen MSPDir: crypto-config/peerOrganizations/org3.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/// Policies: &Org3Policies Readers: Type: Signature Rule: "OR('Org3MSP.member')" # If your MSP is configured with the new NodeOUs, you might # want to use a more specific rule like the following: # Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')" Writers: Type: Signature Rule: "OR('Org3MSP.member')" # If your MSP is configured with the new NodeOUs, you might # want to use a more specific rule like the following: # Rule: "OR('Org2MSP.admin', 'Org2MSP.client')" Admins: Type: Signature Rule: "OR('Org3MSP.admin')" Endorsement: Type: Signature Rule: "OR('Org3MSP.member')" # 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. AnchorPeers: - Host: peer0.org3.example.com Port: 7051 ################################################################################ # # 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 # V1.3 for Channel is a catchall flag for behavior which has been # determined to be desired for all orderers and peers running at the v1.3.x # level, but which would be incompatible with orderers and peers from # prior releases. # Prior to enabling V1.3 channel capabilities, ensure that all # orderers and peers on a channel are at v1.3.0 or later. V1_4_3: true V1_4_2: false V1_3: false V1_1: false # 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 V1.1 orderer capabilities, ensure that all # orderers on a channel are at v1.1.0 or later. V1_4_2: true V1_1: false # 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. V1_4_2: true # V1.3 for Application enables the new non-backwards compatible # features and fixes of fabric v1.3. V1_3: false # V1.2 for Application enables the new non-backwards compatible # features and fixes of fabric v1.2 (note, this need not be set if # later version capabilities are set) V1_2: false # V1.1 for Application enables the new non-backwards compatible # features and fixes of fabric v1.1 (note, this need not be set if # later version capabilities are set). V1_1: false ################################################################################ # # 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. # # User's 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 "CommitChaincodeDefinition" function _lifecycle/CommitChaincodeDefinition: /Channel/Application/Writers # ACL policy for _lifecycle's "QueryChaincodeDefinition" function _lifecycle/QueryChaincodeDefinition: /Channel/Application/Readers # ACL policy for _lifecycle's "QueryNamespaceDefinitions" function _lifecycle/QueryNamespaceDefinitions: /Channel/Application/Readers #---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 "GetConfigTree" function cscc/GetConfigTree: /Channel/Application/Readers # ACL policy for cscc's "SimulateConfigTreeUpdate" function cscc/SimulateConfigTreeUpdate: /Channel/Application/Readers #---Miscellanesous 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/Readers #---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/ 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 ################################################################################ # # 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" and "kafka". OrdererType: etcdraft # Addresses here is a nonexhaustive list of orderers the peers and clients can # connect to. Adding/removing nodes from this list has no impact on their # participation in ordering. # NOTE: In the solo case, this should be a one-item list. Addresses: - orderer0.example.com:7050 - orderer1.example.com:7050 - orderer2.example.com:7050 # 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. If the "kafka" OrdererType is # selected, set 'message.max.bytes' and 'replica.fetch.max.bytes' on # the Kafka brokers to a value that is larger than this one. 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 - kafka3: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: 7055 ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt - Host: orderer1.example.com Port: 7050 ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt - Host: orderer2.example.com Port: 7050 ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt ServerTLSCert: 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: 20 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/ 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 ################################################################################ # # 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/ 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 ################################################################################ # # PROFILES # # Different configuration profiles may be encoded here to be specified as # parameters to the configtxgen tool. The profiles which specify consortiums # are to be used for generating the orderer genesis block. With the correct # consortium members defined in the orderer genesis block, channel creation # requests may be generated with only the org member names and a consortium # name. # ################################################################################ Profiles: # SampleSingleMSPSolo defines a configuration which uses the Solo orderer, # and contains a single MSP definition (the MSP sampleconfig). # The Consortium SampleConsortium has only a single member, SampleOrg. SampleSingleMSPSolo: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults Organizations: - *SampleOrg Consortiums: SampleConsortium: Organizations: - *SampleOrg # SampleSingleMSPKafka defines a configuration that differs from the # SampleSingleMSPSolo one only in that it uses the Kafka-based orderer. SampleSingleMSPKafka: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults OrdererType: kafka Organizations: - *SampleOrg Consortiums: SampleConsortium: Organizations: - *SampleOrg # SampleInsecureSolo defines a configuration which uses the Solo orderer, # contains no MSP definitions, and allows all transactions and channel # creation requests for the consortium SampleConsortium. SampleInsecureSolo: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults Consortiums: SampleConsortium: Organizations: # SampleInsecureKafka defines a configuration that differs from the # SampleInsecureSolo one only in that it uses the Kafka-based orderer. SampleInsecureKafka: <<: *ChannelDefaults Orderer: OrdererType: kafka <<: *OrdererDefaults Consortiums: SampleConsortium: Organizations: # SampleDevModeSolo defines a configuration which uses the Solo orderer, # contains the sample MSP as both orderer and consortium member, and # requires only basic membership for admin privileges. It also defines # an Application on the ordering system channel, which should usually # be avoided. SampleDevModeSolo: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" Application: <<: *ApplicationDefaults Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" Consortiums: SampleConsortium: Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" # SampleDevModeKafka defines a configuration that differs from the # SampleDevModeSolo one only in that it uses the Kafka-based orderer. SampleDevModeKafka: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults OrdererType: kafka Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" Application: <<: *ApplicationDefaults Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" Consortiums: SampleConsortium: Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" # SampleSingleMSPChannel defines a channel with only the sample org as a # member. It is designed to be used in conjunction with SampleSingleMSPSolo # and SampleSingleMSPKafka orderer profiles. Note, for channel creation # profiles, only the 'Application' section and consortium # name are # considered. SampleSingleMSPChannel: <<: *ChannelDefaults Consortium: SampleConsortium Application: <<: *ApplicationDefaults Organizations: - <<: *SampleOrg # SampleDevModeEtcdRaft defines a configuration that differs from the # SampleDevModeSolo one only in that it uses the etcd/raft-based orderer. SampleDevModeEtcdRaft: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults OrdererType: etcdraft Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" Application: <<: *ApplicationDefaults Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" Consortiums: SampleConsortium: Organizations: - <<: *SampleOrg Policies: <<: *SampleOrgPolicies Admins: Type: Signature Rule: "OR('SampleOrg.member')" TwoOrgsOrdererGenesis: <<: *ChannelDefaults Capabilities: <<: *ChannelCapabilities Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg Capabilities: <<: *OrdererCapabilities Consortiums: SampleConsortium: Organizations: - *Org1 - *Org2 TwoOrgsChannel: Consortium: SampleConsortium <<: *ChannelDefaults Capabilities: <<: *ChannelCapabilities Application: <<: *ApplicationDefaults Organizations: - *Org1 - *Org2 Capabilities: <<: *ApplicationCapabilities