docker-compose-files/hyperledger_fabric/latest/kafka/configtx.yaml

765 lines
32 KiB
YAML
Raw Normal View History

2017-06-07 15:53:15 +08:00
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
2017-04-06 17:50:34 +08:00
---
################################################################################
#
2019-02-28 11:21:41 +08:00
# ORGANIZATIONS
2017-04-06 17:50:34 +08:00
#
2019-02-28 11:21:41 +08:00
# This section defines the organizational identities that can be referenced
# in the configuration profiles.
2017-04-06 17:50:34 +08:00
#
################################################################################
Organizations:
2019-02-28 11:21:41 +08:00
# 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
# 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: SampleOrg
# MSPDir is the filesystem path which contains the MSP configuration.
MSPDir: msp
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# 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: &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.
2017-04-06 17:50:34 +08:00
- &OrdererOrg
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
Name: OrdererOrg
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
ID: OrdererMSP
2019-02-28 11:21:41 +08:00
# MSPDir is the filesystem path which contains the MSP configuration.
# Used by configtxgen
MSPDir: crypto-config/ordererOrganizations/example.com/msp
2017-04-06 17:50:34 +08:00
2018-09-10 14:22:00 +08:00
# 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')"
2019-02-28 11:21:41 +08:00
# 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')"
2018-09-10 14:22:00 +08:00
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
- &Org1
2019-02-28 11:21:41 +08:00
# 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
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# 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: Org1MSP
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# MSPDir is the filesystem path which contains the MSP configuration.
# Used by configtxgen
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
2017-04-06 17:50:34 +08:00
2018-09-10 14:22:00 +08:00
# 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>
2019-02-28 11:21:41 +08:00
Policies: &Org1Policies
2018-09-10 14:22:00 +08:00
Readers:
Type: Signature
2019-02-28 11:21:41 +08:00
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')"
2018-09-10 14:22:00 +08:00
Writers:
Type: Signature
2019-02-28 11:21:41 +08:00
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')"
2018-09-10 14:22:00 +08:00
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
2019-02-28 11:21:41 +08:00
Endorsement:
Type: Signature
Rule: "OR('Org1MSP.member')"
2018-09-10 14:22:00 +08:00
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
AnchorPeers:
- Host: peer0.org1.example.com
2017-04-06 17:50:34 +08:00
Port: 7051
- &Org2
2019-02-28 11:21:41 +08:00
# 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
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# 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: Org2MSP
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# MSPDir is the filesystem path which contains the MSP configuration.
# Used by configtxgen
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
2017-04-06 17:50:34 +08:00
2018-09-10 14:22:00 +08:00
# 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>
2019-02-28 11:21:41 +08:00
Policies: &Org2Policies
2018-09-10 14:22:00 +08:00
Readers:
Type: Signature
2019-02-28 11:21:41 +08:00
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')"
2018-09-10 14:22:00 +08:00
Writers:
Type: Signature
2019-02-28 11:21:41 +08:00
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')"
2018-09-10 14:22:00 +08:00
Admins:
Type: Signature
Rule: "OR('Org2MSP.admin')"
2019-02-28 11:21:41 +08:00
Endorsement:
Type: Signature
Rule: "OR('Org2MSP.member')"
2018-09-10 14:22:00 +08:00
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
AnchorPeers:
- Host: peer0.org2.example.com
2017-04-06 17:50:34 +08:00
Port: 7051
################################################################################
#
2019-02-28 11:21:41 +08:00
# CAPABILITIES
#
2019-02-28 11:21:41 +08:00
# 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
2019-02-28 11:21:41 +08:00
# supported by both.
# Set the value of the capability to true to require it.
Channel: &ChannelCapabilities
2018-09-10 14:22:00 +08:00
# V1.3 for Channel is a catchall flag for behavior which has been
2019-02-28 11:21:41 +08:00
# 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.
2019-04-22 14:19:18 +08:00
V2_0: true
V1_3: false
# Orderer capabilities apply only to the orderers, and may be safely
2019-02-28 11:21:41 +08:00
# used with prior release peers.
# Set the value of the capability to true to require it.
Orderer: &OrdererCapabilities
2019-02-28 11:21:41 +08:00
# 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.
2019-04-22 14:19:18 +08:00
V2_0: true
V1_1: false
# Application capabilities apply only to the peer network, and may be safely
2019-02-28 11:21:41 +08:00
# used with prior release orderers.
# Set the value of the capability to true to require it.
Application: &ApplicationCapabilities
2019-02-28 11:21:41 +08:00
# V1.3 for Application enables the new non-backwards compatible
# features and fixes of fabric v1.3.
2019-04-22 14:19:18 +08:00
V2_0: true
V1_3: false
2019-02-28 11:21:41 +08:00
# 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
################################################################################
#
2019-02-28 11:21:41 +08:00
# APPLICATION
#
2019-02-28 11:21:41 +08:00
# This section defines the values to encode into a config transaction or
# genesis block for application-related parameters.
#
################################################################################
Application: &ApplicationDefaults
2019-02-28 11:21:41 +08:00
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
2019-02-28 11:21:41 +08:00
# 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:
2018-09-10 14:22:00 +08:00
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
2019-02-28 11:21:41 +08:00
Policies: &ApplicationDefaultPolicies
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
2018-09-10 14:22:00 +08:00
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
2017-04-06 17:50:34 +08:00
################################################################################
#
2019-02-28 11:21:41 +08:00
# ORDERER
2017-04-06 17:50:34 +08:00
#
2019-02-28 11:21:41 +08:00
# This section defines the values to encode into a config transaction or
# genesis block for orderer related parameters.
2017-04-06 17:50:34 +08:00
#
################################################################################
Orderer: &OrdererDefaults
2019-02-28 11:21:41 +08:00
# Orderer Type: The orderer implementation to start.
# Available types are "solo" and "kafka".
OrdererType: kafka
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
Addresses:
2018-10-11 22:29:09 +08:00
- orderer0.example.com:7050
- orderer1.example.com:7050
2017-04-06 17:50:34 +08:00
2019-02-28 11:21:41 +08:00
# Batch Timeout: The amount of time to wait before creating a batch.
2017-04-06 17:50:34 +08:00
BatchTimeout: 2s
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
BatchSize:
2019-02-28 11:21:41 +08:00
# Max Message Count: The maximum number of messages to permit in a
# batch. No block will contain more than this number of messages.
2017-04-06 17:50:34 +08:00
MaxMessageCount: 10
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
2019-02-28 11:21:41 +08:00
# 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.
2017-04-06 17:50:34 +08:00
PreferredMaxBytes: 512 KB
2019-02-28 11:21:41 +08:00
# 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
2017-04-06 17:50:34 +08:00
Kafka:
2018-09-10 14:22:00 +08:00
# 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.
2017-04-06 17:50:34 +08:00
Brokers:
2017-07-21 13:19:01 +08:00
- kafka0:9092
- kafka1:9092
- kafka2:9092
- kafka3:9092
2019-02-28 11:21:41 +08:00
# EtcdRaft defines configuration which must be set when the "etcdraft"
# orderertype is chosen.
2019-04-22 14:29:05 +08:00
2019-02-28 11:21:41 +08:00
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:
2019-04-22 14:29:05 +08:00
- Host: orderer0.example.com
2019-02-28 11:21:41 +08:00
Port: 7050
2019-04-22 14:29:05 +08:00
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
2019-02-28 11:21:41 +08:00
Port: 7050
2019-04-22 14:29:05 +08:00
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
2019-02-28 11:21:41 +08:00
Port: 7050
2019-04-22 14:29:05 +08:00
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
2019-02-28 11:21:41 +08:00
# 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:
2019-04-22 14:29:05 +08:00
# TickInterval is the time interval between two Node.Tick invocations.
TickInterval: 500ms
2019-02-28 11:21:41 +08:00
# 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
2019-04-22 14:29:05 +08:00
# MaxInflightBlocks limits the max number of in-flight append messages
2019-02-28 11:21:41 +08:00
# during optimistic replication phase.
2019-04-22 14:29:05 +08:00
MaxInflightBlocks: 5
2019-02-28 11:21:41 +08:00
2019-04-22 14:29:05 +08:00
# SnapshotIntervalSize defines number of bytes per which a snapshot is taken
SnapshotIntervalSize: 20 MB
2019-02-28 11:21:41 +08:00
# Organizations lists the orgs participating on the orderer side of the
# network.
2017-04-06 17:50:34 +08:00
Organizations:
2018-09-10 14:22:00 +08:00
# 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
################################################################################
#
# 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
2017-04-06 17:50:34 +08:00
################################################################################
#
2019-02-28 11:21:41 +08:00
# PROFILES
2017-12-06 22:30:57 +08:00
#
2019-02-28 11:21:41 +08:00
# 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.
2017-12-06 22:30:57 +08:00
#
################################################################################
Profiles:
2017-12-06 22:30:57 +08:00
2019-02-28 11:21:41 +08:00
# 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:
2018-09-10 14:22:00 +08:00
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
2019-02-28 11:21:41 +08:00
Capabilities:
<<: *OrdererCapabilities
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
TwoOrgsChannel:
Consortium: SampleConsortium
2019-02-28 11:21:41 +08:00
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
2019-02-28 11:21:41 +08:00
Capabilities:
<<: *ApplicationCapabilities