当前位置：首页 > news >正文

configtx通道配置文件

news 2025/8/21 8:39:53

本Fabric中文文档专栏的阅读前言：前言

文章目录

组织权限配置（Organizations）
- MSPDir:
- Policies：不同操作的策略（权限）
Capabilities
- - **逐项对比说明**
应用通道设置（Application）
- **Organizations**
- **Policies**
- **总结**
- Organizations与Application关系
排序服务节点配置（Orderer）
- **Addresses**
- **BatchTimeout**
- **BatchSize**
- **Organizations**
- **Policies**
- **总结**
通道配置(Channel)
- **Policies**
- **Capabilities**
- **总结**
Profiles
- **顶层**
- **Orderer 部分**
- - **EtcdRaft 配置**
  - **Orderer 组织**
- **Application 部分**
- **总结**
- 系统通道的porfiles
- - 1. 为什么没有 `Application:`？
  - 2. 为什么没有 `EtcdRaft:`？
  - 3. 为什么多了 `Consortiums:`？

路径：fabric-samples/test-network/configtx/configtx.yaml

组织权限配置（Organizations）

Organizations- &Org1# DefaultOrg defines the organization which is used in the sampleconfig# of the fabric.git development environmentName: Org1MSP# ID to load the MSP definition asID: Org1MSPMSPDir: ../organizations/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/<Application|Orderer>/<OrgName>/<PolicyName>Policies:Readers:Type: SignatureRule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"Writers:Type: SignatureRule: "OR('Org1MSP.admin', 'Org1MSP.client')"Admins:Type: SignatureRule: "OR('Org1MSP.admin')"Endorsement:Type: SignatureRule: "OR('Org1MSP.peer')"

Org1MSP:组织的ID和名字

MSPDir:

MSP文件地址.MSP (Membership Service Provider) 文件夹包含：

cacerts/ → 组织的根 CA 证书
tlscacerts/ → 组织的 TLS 根 CA 证书
signcerts/ → 组织管理员的签名证书
keystore/ → 私钥

MSPDir的CONFIG.YAML里面只规定不同根CA的身份（admin,peer等），不会明文确定具体某个节点的权限，而是在判断时根据节点对应的根ca判断身份。

Policies：不同操作的策略（权限）

Readers读：
1. Types类型：Signature（表示该策略要求参与者必须提供有效的 数字签名，且满足下面定义的Rule）
2. Rule(策略)：“OR(‘Org1MSP.admin’, ‘Org1MSP.peer’, ‘Org1MSP.client’)”（获取该权限需哪些身份的签名）。
以下同理，略…

Capabilities

Capabilities:# Channel 能力集：要求 Orderer 和 Peer 均支持，否则无法加入通道Channel: &ChannelCapabilities# V2_0 表示启用 Fabric 2.0 的通道级功能# 启用后，仅支持 v2.0+ 的节点可参与通道V2_0: true# Orderer 能力集：仅作用于 Orderer 节点Orderer: &OrdererCapabilities# V2_0 表示 Orderer 需支持 2.0 特性（如 Raft 共识）# 旧版本 Orderer 将无法工作V2_0: true# Application 能力集：仅作用于 Peer 节点Application: &ApplicationCapabilities# V2_5 表示 Peer 需支持 2.5 特性（如私有数据清理）# 旧版本 Peer 将无法加入通道V2_5: true

Capabilities（能力集） 是一个关键配置项，它定义了通道内各个组件（如 Orderer、Application、Channel）所支持的 功能版本和兼容性。Capabilities 确保了网络中所有节点（Peer、Orderer）在相同的功能级别上运行，避免因版本不一致导致的分叉或错误。

逐项对比说明

配置项	组织权限配置类比	Capabilities 含义
Channel	类似组织全局策略（如 `Policies`）	定义通道级别的兼容性要求，所有节点（Orderer + Peer）必须满足。
Orderer	类似 Orderer 节点角色策略	仅 Orderer 需满足的能力（如共识算法），Peer 可忽略。
Application	类似 Peer 节点角色策略	仅 Peer 需满足的能力（如链码特性），Orderer 可忽略。
V2_0/V2_5	类似 `Rule` 中的角色条件	功能版本开关，`true` 表示启用该版本特性，节点必须支持否则无法加入。

应用通道设置（Application）

ApplicationDefaults，它主要规定应用通道（Application Channel）中和组织、策略、功能相关的默认设置。

Application: &ApplicationDefaults# Organizations is the list of orgs which are defined as participants on# the application side of the networkOrganizations:# Policies defines the set of policies at this level of the config tree# For Application policies, their canonical path is#   /Channel/Application/<PolicyName>Policies:Readers:Type: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"LifecycleEndorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"Endorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"Capabilities:<<: *ApplicationCapabilities

Organizations

Application: &ApplicationDefaults# Organizations is the list of orgs which are defined as participants on# the application side of the networkOrganizations:

这里会列出所有参与这个 应用通道 的组织（orgs），比如 Org1、Org2 等。
在 Application 部分声明的组织代表它们是应用层面的参与者，可以提交交易、背书交易等。

Policies

  # Policies defines the set of policies at this level of the config tree# For Application policies, their canonical path is#   /Channel/Application/<PolicyName>Policies:

定义通道配置树中 Application 层级的策略。
这些策略控制不同操作的权限（如读、写、管理、背书）。
它们的完整路径是 /Channel/Application/<PolicyName>。

    Readers:Type: ImplicitMetaRule: "ANY Readers"

Readers 策略
- Type: ImplicitMeta 表示这是一个“隐式元策略”。
  - 隐式元策略会基于子组织（Organizations 下的策略）自动聚合。意思是：
    1. 到 Application.Organizations 下找每个组织的 Readers 策略（比如 Org1 的 Readers，Org2 的 Readers…）。
    2. Fabric 会对这些子策略逐一评估，看调用者身份是否符合。
    3. 然后应用 "ANY Readers" 这个聚合规则：
- Rule: “ANY Readers” 表示：只要任意一个组织的 Readers 策略满足，就允许读取（比如 Org1 的 Readers 或 Org2 的 Readers）。
- 用途：控制哪些身份可以“读”通道上的数据（例如查询账本）。

Writers 策略
同上，略
Admins 策略
- 定义谁有管理权限（如修改通道配置）。
- “MAJORITY Admins” 表示：需要大多数组织的 Admins 策略满足，才能执行管理操作。
- 这是防止单个组织独断修改通道配置的安全机制。

    LifecycleEndorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"

LifecycleEndorsement 策略
- 针对 链码生命周期操作（如安装、批准、提交链码定义）的背书策略。
- “MAJORITY Endorsement” 表示：多数组织的 Endorsement 策略要满足，链码生命周期操作才有效。

    Endorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"

Endorsement 策略
- 这是 交易背书策略 的默认值。
- “MAJORITY Endorsement” 表示：多数组织的背书才算有效。
- 如果链码没有自己单独指定背书策略，就会使用这个默认的。

  Capabilities:<<: *ApplicationCapabilities

Capabilities
- 指定通道支持的功能特性（不同版本的 Fabric 功能不同）。
- <<: *ApplicationCapabilities 表示引用在别处定义的 ApplicationCapabilities。
- 常见的有 V2_0 等，启用新功能（例如新的背书语义、私有数据改进、链码生命周期 v2.0 等）。

总结

Organizations：参与应用通道的组织。
Policies：控制通道应用层的权限。
- Readers → 谁能读账本
- Writers → 谁能写交易
- Admins → 谁能改配置
- LifecycleEndorsement → 链码生命周期操作的背书要求
- Endorsement → 交易背书的默认策略(会被链码的背书策略覆盖)
Capabilities：启用 Fabric 特定版本功能。

Organizations与Application关系

这里和前面的组织权限配置（Organizations）十分相似，但是二者有实质性的区别。==Organizations为组织自己的本地规则：谁在这个组织里有读/写/管理/背书权限？后者Application 层 (ImplicitMeta) = 多组织之间的聚合规则：不同组织的规则综合起来，最终决定整个通道级别的权限。==例如Readers权限，某个调用者想要读权限时，通道首先观察调用者节点是否在Organizations里有读取权限，然后在观察Application 层,即调用者的组织在该通道是否有对应权限（Any Readers表示任意Readers权限都可以）。但如果是MAJORITY就需要不同组织的规则聚合起来综合判断。

举例：

我是 Org1 的 client 身份：
- 看 Org1 的 Readers → OK，因为 client 在OR('admin','peer','client') 里。
- 再看 Application 的 Readers (ANY Readers) → OK，因为至少 Org1 的 Readers 满足。
- 结果：我能读取通道数据。
我是 Org1 的 peer 节点，想背书交易：
- Org1 的 Endorsement → OK（Org1.peer）。
- Application 的 Endorsement (MAJORITY Endorsement) → ❌ 如果只 Org1 背书，不够；需要多数组织的 peer 一起背书。
- 结果：需要多个 org 的 peer 一起背书交易。

排序服务节点配置（Orderer）

Orderer: &OrdererDefaults# 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 definitionAddresses:- orderer.example.com:7050# Batch Timeout: The amount of time to wait before creating a batchBatchTimeout: 2s# Batch Size: Controls the number of messages batched into a blockBatchSize:# Max Message Count: The maximum number of messages to permit in a batchMaxMessageCount: 10# Absolute Max Bytes: The absolute maximum number of bytes allowed for# the serialized messages in a batch.AbsoluteMaxBytes: 99 MB# Preferred Max Bytes: The preferred maximum number of bytes allowed for# the serialized messages in a batch. A message larger than the preferred# max bytes will result in a batch larger than preferred max bytes.PreferredMaxBytes: 512 KB# Organizations is the list of orgs which are defined as participants on# the orderer side of the networkOrganizations:# 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: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"# BlockValidation specifies what signatures must be included in the block# from the orderer for the peer to validate it.BlockValidation:Type: ImplicitMetaRule: "ANY Writers"

这段配置是 OrdererDefaults，它规定了 排序服务节点（Orderer） 的通道默认配置。和之前的 ApplicationDefaults 类似，只不过这是 Orderer 侧的规则。

Addresses

Addresses:   - orderer.example.com:7050

老版本中，这里是客户端和 peer 节点连接 orderer 的地址。
现在推荐写到组织定义里的 OrdererEndpoints，这样能更好地把 地址与组织绑定（方便 TLS 验证）。
不过 Addresses 依旧可以用，主要是兼容性。

BatchTimeout

BatchTimeout: 2s

批量超时时间。
排序服务在打包交易时，最多等待 2 秒 才会生成一个区块（哪怕没达到批量阈值）。
换句话说：交易量少时，也会定期出块。

BatchSize

BatchSize:   MaxMessageCount: 10   AbsoluteMaxBytes: 99 MB   PreferredMaxBytes: 512 KB

控制 区块中能容纳多少交易：

MaxMessageCount = 10
→ 一个区块最多放 10 条交易。
AbsoluteMaxBytes = 99 MB
→ 区块序列化后大小不能超过 99 MB。
PreferredMaxBytes = 512 KB
→ 推荐的最大区块大小（即排序服务会尽量把区块控制在 512 KB 内）。
→ 但如果某笔交易本身就比 512 KB 大，也允许生成超过 512 KB 的区块，只要不超过 99 MB。

这三者结合起来决定出块大小的平衡：

高并发 → MaxMessageCount 先触发
大交易 → Preferred/AbsoluteMaxBytes 触发
交易很少 → BatchTimeout 触发

Organizations

这里会列出 参与 Orderer 服务的组织（比如 Raft 集群中的各个 orderer 组织）。
空的意思是默认配置文件没列出，具体要在网络配置时定义。

Policies

Policies:   Readers:     Type: ImplicitMeta     Rule: "ANY Readers"   Writers:     Type: ImplicitMeta     Rule: "ANY Writers"   Admins:     Type: ImplicitMeta     Rule: "MAJORITY Admins"BlockValidation:     Type: ImplicitMeta     Rule: "ANY Writers"

Readers
- 谁能读 Orderer 的数据。
- "ANY Readers" → 只要有一个组织的 Readers 策略满足就行。
Writers
- 谁能写入（即谁能把交易提交到 orderer）。
- "ANY Writers" → 任意一个组织的 Writers 策略满足即可。
Admins
- 谁能管理 Orderer 配置（如修改通道配置）。
- "MAJORITY Admins" → 需要多数组织的 Admin 策略满足。
BlockValidation
- 很关键：规定 peer 在验证一个区块时，必须看到哪些签名。
- "ANY Writers" → 意味着只要有一个 Orderer 组织的 Writer 对区块签名，就能让 peer 验证通过。
- 在 Raft 共识里，实际上 leader 会对区块签名，follower 会转发，不要求每个节点都签。

总结

Addresses：orderer 地址（新版本推荐用 OrdererEndpoints）。
BatchTimeout：定时出块。
BatchSize：控制区块大小和交易数上限。
Organizations：参与排序服务的组织。
Policies：Orderer 的访问控制。
- Readers/Writers/Admins → 跟 Application 类似。
- BlockValidation → 定义 peer 节点验块时需要哪些签名，保证区块合法性。

通道配置(Channel)

这一段是 ChannelDefaults，也就是通道顶层的默认配置。和 ApplicationDefaults、OrdererDefaults 一样，它定义了通道级别的基础策略和能力。

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' APIReaders:Type: ImplicitMetaRule: "ANY Readers"# Who may invoke the 'Broadcast' APIWriters:Type: ImplicitMetaRule: "ANY Writers"# By default, who may modify elements at this config levelAdmins:Type: ImplicitMetaRule: "MAJORITY Admins"# Capabilities describes the channel level capabilities, see the# dedicated Capabilities section elsewhere in this file for a full# descriptionCapabilities:<<: *ChannelCapabilities

Policies

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"

这是 通道级别的策略。路径是：/Channel/<PolicyName>。

Readers
- 控制谁能调用 Deliver API(Deliver API 用来从 orderer 或 peer 获取区块数据)。
- ANY Readers → 任意一个组织的 Readers 策略满足，就能读取区块。
Writers
- 控制谁能调用 Broadcast API(Broadcast API 是客户端把交易广播到 orderer 的入口)。
- ANY Writers → 任意一个组织的 Writers 策略满足，就能提交交易给 orderer。
Admins
- 控制谁能修改 Channel 层的配置（例如增加 org、修改策略等）。
- MAJORITY Admins → 需要多数组织的 Admin 策略满足，才能修改通道配置。
- 这是 Fabric 的核心安全保证：避免单个 org 就能随意改通道规则。

Capabilities

Capabilities:   <<: *ChannelCapabilities

Capabilities 表示启用哪些 通道级功能特性。
<<: *ChannelCapabilities 表示引用配置文件中另一处定义好的 ChannelCapabilities（通常是类似 V2_0: true 的配置）。
通道能力的启用会影响整个网络的行为，比如：
- 是否支持新链码生命周期（Fabric v2.x）
- 是否允许新的背书/验证语义
- 是否支持更高版本的 MSP 特性

总结

ChannelDefaults 是通道顶层的默认配置。
它定义了：
- Readers → 谁能读区块（Deliver API）
- Writers → 谁能提交交易（Broadcast API）
- Admins → 谁能改通道配置（需要多数 org admin 签名）
- Capabilities → 通道启用哪些 Fabric 功能

Profiles

这段是 Profiles 下的一个配置文件示例：ChannelUsingRaft。

在 Fabric 里 Profiles 常用于 configtx.yaml，主要用于后续生成通道创世区块或通道配置交易。可以把它看作“把前面定义的各种 Defaults 拼接成一个实际的网络配置方案”。

Profiles:ChannelUsingRaft:<<: *ChannelDefaultsOrderer:<<: *OrdererDefaultsOrdererType: etcdraftEtcdRaft:Consenters:- Host: orderer.example.comPort: 7050ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crtServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crtOrganizations:- *OrdererOrgCapabilities: *OrdererCapabilitiesApplication:<<: *ApplicationDefaultsOrganizations:- *Org1- *Org2Capabilities: *ApplicationCapabilities

顶层

Profiles:   ChannelUsingRaft:     <<: *ChannelDefaults

ChannelUsingRaft 是一个 profile 名称，你在 configtxgen 时会用到它，比如：

configtxgen -profile ChannelUsingRaft -outputBlock ./channel-artifacts/genesis.block
<<: *ChannelDefaults 表示继承前面定义的 ChannelDefaults，包括通道级别的策略（Readers/Writers/Admins）和通道能力（Capabilities）。

Orderer 部分

Orderer:   <<: *OrdererDefaults   OrdererType: etcdraft

继承 OrdererDefaults（出块规则、策略等）。
指定排序服务类型为 etcdraft（目前推荐使用的共识机制）。

EtcdRaft 配置

EtcdRaft:Consenters:     - Host: orderer.example.comPort: 7050ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crtServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt

Consenters：Raft 集群中的共识节点。
- 每个 consenter = 一个 orderer 节点，包含：
  - Host: 节点主机名
  - Port: 节点监听端口
  - ClientTLSCert: 用于客户端与该 orderer 建立 TLS 连接的证书
  - ServerTLSCert: 该 orderer 节点对外提供服务时用的 TLS 证书

在真实网络里你会配置多个 orderer 节点（3 或 5 个），组成高可用 Raft 集群。

Consenters这里和Organizations里定义的OrdererOrg关系：
MSPDir定义了一个 组织层级的身份体系（谁是合法 orderer 成员，谁是 admin）。
Consenters明确指定该OrdererOrg里 哪些具体 orderer 节点（带 Host/Port 和 TLS 证书）实际参与 Raft 共识。换句话说，即使某个节点属于 OrdererOrg（MSP 允许它存在），如果不在 Consenters 列表里，它也不会参与 Raft 共识。

Orderer 组织

Organizations:- *OrdererOrg
Capabilities: *OrdererCapabilities

指定排序服务参与的组织，这里用了前面定义好的 OrdererOrg(在Organizations部分)。
启用 Orderer 侧的功能能力（Capabilities），比如 Raft 支持。

Application 部分

Application:<<: *ApplicationDefaults   Organizations:- *Org1- *Org2Capabilities: *ApplicationCapabilities

继承 ApplicationDefaults（应用层策略，如读写、背书等）。
指定两个应用组织：Org1、Org2。
启用 Application 侧的能力（如新的背书语义、链码生命周期 v2.0 等）。

总结

ChannelUsingRaft profile 定义了一个典型的基于 Raft 共识 的 Fabric 通道配置，包含：

Channel 层：通道顶层策略（继承 ChannelDefaults）
Orderer 层：
- 使用 Raft (etcdraft)
- 配置一个 consenter 节点（通常会有多个）
- 指定 Orderer 组织和能力
Application 层：
- 定义两个应用组织（Org1、Org2）
- 指定应用能力

这个 profile 通常会用来：

生成 创世区块（orderer 启动时用）
或者生成 新通道配置交易（创建一个新通道时用）

系统通道的porfiles

注意，官方在2.3版本之后已经逐渐启用系统通道。从 Fabric v2.3 开始，引入了 Channel Participation API，允许在不依赖系统通道的情况下创建应用通道（application channel）。

系统通道主要用于定义 consortium（创建通道的权限组织列表），但在新版中可以跳过这一步，直接使用 application channel 管理流程，简化操作，提升隐私和扩展性

这里举一个创建系统通道的profiles

TwoOrgsOrdererGenesis:<<: *ChannelDefaultsOrderer:<<: *OrdererDefaultsOrganizations:- *OrdererOrgCapabilities:<<: *OrdererCapabilitiesConsortiums:SampleConsortium:Organizations:- *Org1- *Org2

上文的ChannelUsingRaft 是用来 创建应用通道（application channel） 的 Profile；而这里的 TwoOrgsOrdererGenesis 是用来 生成系统通道（system channel）的创世区块（genesis block） 的 Profile。

1. 为什么没有 `Application:`？

系统通道（orderer system channel） 主要服务于排序节点和联盟管理（consortium management），它本身不承载应用交易。
因此，在系统通道的 Profile 里，不会定义 Application: 部分（因为还没有具体的应用组织要加入通道）。
Application: 部分只会在创建应用通道的 Profile 中出现（比如 ChannelUsingRaft）。

2. 为什么没有 `EtcdRaft:`？

EtcdRaft: 只在需要指定 排序服务共识机制 时才需要。
在 TwoOrgsOrdererGenesis 里引用了 *OrdererDefaults，里面可能没有指定 OrdererType: etcdraft，而是走默认（通常是 solo 或 etcdraft，要看你在 OrdererDefaults 里设定）。
如果需要 Raft，这里也可以加上 OrdererType: etcdraft 和 EtcdRaft: Consenters，但很多示例简化了。