# 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: - &OrderingNodes Name: OrderingNodes ID: NodesMSP MSPDir: crypto-config/ordererOrganizations/node.bft/msp Policies: Readers: Type: Signature Rule: "OR('NodesMSP.member')" Writers: Type: Signature Rule: "AND('NodesMSP.member','NodesMSP.member')" Admins: Type: Signature Rule: "OR('NodesMSP.admin')" - &Frontends Name: Frontends ID: FrontendsMSP MSPDir: crypto-config/ordererOrganizations/frontend.bft/msp Policies: Readers: Type: Signature Rule: "OR('FrontendsMSP.member')" Writers: Type: Signature Rule: "OR('FrontendsMSP.member')" Admins: Type: Signature Rule: "OR('FrontendsMSP.admin')" - &LaSIGE Name: LaSIGE ID: LaSIGEMSP MSPDir: crypto-config/peerOrganizations/lasige.bft/msp Policies: Readers: Type: Signature Rule: "OR('LaSIGEMSP.member')" Writers: Type: Signature Rule: "OR('LaSIGEMSP.member')" Admins: Type: Signature Rule: "OR('LaSIGEMSP.admin')" AnchorPeers: - Host: 0.peer.lasige.bft Port: 7051 - &IBM Name: IBM ID: IBMMSP MSPDir: crypto-config/peerOrganizations/ibm.bft/msp Policies: Readers: Type: Signature Rule: "OR('IBMMSP.member')" Writers: Type: Signature Rule: "OR('IBMMSP.member')" Admins: Type: Signature Rule: "OR('IBMMSP.admin')" AnchorPeers: - Host: 0.peer.ibm.bft 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_3: 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 V1.1 orderer capabilities, ensure that all # orderers on a channel are at v1.1.0 or later. V1_1: 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 # V1.3 for Application enables the new non-backwards compatible # features and fixes of fabric v1.3. V1_3: true # 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 #---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 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: solo # 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: - bft.frontend.1000:7050 - bft.frontend.2000: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: 10 # 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: 512 KB # 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 #JCS: BFT-SMaRt options BFTsmart: # ConnectionPoolSize: The size of the connection pool that links the golang component to the java component. ConnectionPoolSize: 20 # RecvPort: The localhost TCP port from which the java component sends blocks to the golang component. RecvPort: 9999 # 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: raft0.example.com Port: 7050 ClientTLSCert: path/to/ClientTLSCert0 ServerTLSCert: path/to/ServerTLSCert0 - Host: raft1.example.com Port: 7050 ClientTLSCert: path/to/ClientTLSCert1 ServerTLSCert: path/to/ServerTLSCert1 - Host: raft2.example.com Port: 7050 ClientTLSCert: path/to/ClientTLSCert2 ServerTLSCert: path/to/ServerTLSCert2 # 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: BFTGenesis: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults OrdererType: bftsmart Addresses: - 1000.frontend.bft:7050 - 2000.frontend.bft:7050 Organizations: - *OrderingNodes - *Frontends Consortiums: BFTConsortium: Organizations: - *LaSIGE - *IBM BFTChannel: Consortium: BFTConsortium Application: <<: *ApplicationDefaults Organizations: - *LaSIGE - *IBM