configtx.yaml简介
transaction的英文缩写是TX(表示交易),configtx表示交易配置,所以和交易相关的配置,如应用通道、锚节点、Orderer服务等,都是在configtx.yaml文件中配置的。它主要生成通道创世区块${CHANNEL_NAME}.block。
configtx.yaml 配置文件一般包括若干字段:Organizations、Capabilities、Channel、Orderer、Application和Profiles。用户可指定直接使用其中某个Profile,自动引用其他字段中的定义。
configtx.yaml分析主要配置如下
配置项 | 作用 |
---|---|
Organizations | 一系列组织的结构定义,包括名称、MSP路径、读写和管理权限、锚节点等,可被Profiles等部分引用 |
Capabilities | 一系列能力定义,如通道、排序服务、应用等的能力,可被Channel等部分引用 |
Channel | 定义通道相关的默认配置,包括读写和管理权限、能力等,可被Prof iles等部分引用 |
Orderer | 与排序服务相关的配置,包括排序服务类型、地址、切块时间和大小、参与排序服务的组织、权限和能力,可被Profiles等部分引用 |
Application | 与应用通道相关的配置,主要包括默认访问控制权限、参与应用网络的组织、权限和能力,可被Prof iles等部分引用 |
Profiles | 一系列的配置定义,包括指定排序服务配置、应用配置和联盟配置等,直接被configtxgen工具指定使用 |
Organizations部分
组织配置,用来定义不同的组织机构实体,以便后续配置中引用。例如以下配置文件中,定义了三个机构:OrdererOrg、Org1、Org2
MSP(Membership Service Provider)是一个组织的身份标识,在Fabric中组织是由MSP来唯一标识的;
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段定义了fabric程序要加入网络所必须支持的特性。
例如,如果添加了一个新的MSP类型,那么更新的程序可能会根据该类型识别并验证签名,但是老版本的程序就没有办法验证这些交易。这可能导致不同版本的fabric程序中维护的世界状态不一致。
因此,通过定义通道的能力,就明确了不满足该能力要求的fabric程序,将无法处理交易,除非升级到要求的版本。
################################################################################
#
# 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 部分
Channel配置段用来定义要写入创世区块或配置交易的通道参数。
Channel: &ChannelDefaults
# 定义本层级的通道访问策略,推荐路径为 /Channel/<PolicyName>
Policies:
# 谁可能调用'Deliver' API
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
# Writes策略定义了调用Broadcast API提交交易的许可规则
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
# Admin策略定义了修改本层级配置的许可规则
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# 前面Capabilities配置段中的ChannelCapabilities配置项,这里直接引用(Capabilities配置描通道
# 层级的能力需求)
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 中自行定义 vN/A | |
Capabilities | 引用排序服务默认的能力集合 | <<: *OrdererCapabilities |
Application 部分
Application配置段用来定义要写入创世区块或配置交易的应用参数。
Application: &ApplicationDefaults
# 组织是定义为网络应用程序端参与者的组织列表
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
# Capabilities配置描述应用层级的能力需求,这里直接引用
# 前面Capabilities配置段中的ApplicationCapabilities配置项
Capabilities:
<<: *ApplicationCapabilities
配置项 | 作用 |
---|---|
_lifecycle | 指定新的 _lifecycle 系统链码的提交,查询方法的默认策略 |
lscc lscc (Lifecycle System Chaincode) | 系统链码的方法调用权限 |
qscc qscc (Query System Chaincode) | 系统链码的方法调用权限 |
cscc cscc (Configuration System Chaincode) | 系统链码的方法调用权限 |
peer | 通道内链码调用权限 |
event | 接收区块事件权限 |
Profiles 部分
Profiles配置段用来定义用于configtxgen工具的配置入口。包含联盟(consortium)的配置入口可以用来生成排序节点的创世区块。
Profiles:
# # TwoOrgsOrdererGenesis用来生成orderer启动时所需的block,用于生成创世区块,名字可以任意
TwoOrgsApplicationGenesis:
<<: *ChannelDefaults
# 指定Orderer系统通道自身的配置信息
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg # 引用 Orderer 部分的配置 &OrdererDefaults
Capabilities: *OrdererCapabilities #引用&OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Capabilities: *ApplicationCapabilities
使用命令
使用下面命令生成通道创世区块。
# 创建创世区块:生成创世区块mychannel.block文件,根据配置文件../configtx/configtx.yaml来创建Orderer系统通道的创世块
configtxgen -profile TwoOrgsApplicationGenesis -outputBlock ./channel-artifacts/${CHANNEL_NAME}.block -channelID $CHANNEL_NAME