区块链密码学【免费下载链接】fabricHyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.项目地址https://gitcode.com/gh_mirrors/fabr/fabric点击查看免费下载导读Hyperledger Fabric 支持在不重建网络的前提下向一个已经正常运行的排序服务Ordering Service集群中动态加入新的 Orderer 节点也可以将某个 Orderer 从网络中移除。本文以官方test-network示例为场景完整演示将第 5 个 Orderer 扩入由 4 个 Orderer 组成的 Smart BFTBFT集群的每一步从扩展crypto-config-orderer.yaml与docker-compose-bft编排文件、启动集群到用osnadminCLI 将新节点加入通道、用configtxlator修改通道配置Endpoints、BlockValidation 策略、consenter_mapping再到签名、提交配置更新并验证节点状态最后给出反向移除 Orderer 的完整流程。读完本文你将掌握 Fabric 3.x 通道参与模型Channel Participation下 Orderer 节点动态扩缩容的完整操作链路以及其底层 REST API 与状态机的工作原理。说明本文所有命令均基于 Hyperledger Fabric 官方示例仓库 fabric-samples 中的test-network目录本仓库 docs/source/create_channel/add_orderer.md 的原始操作文档即以此为例并结合当前 fabric 仓库源码cmd/osnadmin、orderer/common/channelparticipation 等补充原理性说明。一、前置知识Orderer 动态扩容的机制基础在 Fabric 3.x 中Orderer 加入通道不再依赖系统通道system channel和 genesis block 引导而是通过Channel Participation API通道参与 API完成。每个 Orderer 暴露一个独立的Admin 端点osnadminCLI 通过 HTTPS 调用该端点即可让一个 Orderer 加入某个已存在的通道。从源码看该能力由 orderer/common/channelparticipation/restapi.go 中的HTTPHandler提供路由前缀为/participation/v1/具体包括POST /participation/v1/channels—— 让 Orderer 加入join一个通道GET /participation/v1/channels[/{channelID}]—— 列出已加入的通道/查看单个通道详情DELETE /participation/v1/channels/{channelID}—— 将通道从 Orderer 移除PATCH /participation/v1/channels/{channelID}—— 用配置更新信封更新通道GET /participation/v1/channels/{channelID}/blocks/{blockID}—— 拉取指定区块。osnadmin命令的本质就是这些 REST 调用的封装。在 cmd/osnadmin/main.go 中可以看到其全局参数-o, --orderer-addressOSN 的 Admin 端点、--ca-file、--client-cert、--client-key、--no-status子命令包括channel join、channel list、channel remove、channel update、channel fetch。理解 join 之后的两个关键状态字段当 Orderer 加入一个已存在的通道后其状态由两个字段描述定义见 orderer/common/types/channelinfo.goconsensusRelation与共识集群的关系consenter—— Orderer 是通道共识集群中的正式成员已出现在通道配置的 consenters 集合中follower—— Orderer 不在共识集群中但通过从其他 Orderer 拉取区块来跟随集群config-tracker—— 不在共识集群中仅轮询通道最新配置块等待被加入通道other—— 运行非集群式共识如 solo。status追赶进度onboarding—— 正在从其他 Orderer 拉取区块追赶高度区块高度 ≤ join 块编号active—— 已追平集群高度正常参与共识或跟随inactive/failed—— 未存储任何块 / 最近一次操作失败。下文第 4、5 节的输出中你会反复看到follower → consenter、onboarding → active的转换这正是扩容过程的直观体现。二、场景搭建扩展 test-network 支持第 5 个 OrdererFabric 支持向现有网络添加新的 Orderer。我们使用test-network示例来自 Hyperledger Fabric 官方 fabric-samples 仓库来搭建一个简单但完整的演示场景。2.1 在crypto-config-orderer.yaml中登记新节点在test-network目录中编辑crypto-config-orderer.yaml新增一个 Hostname 为orderer5的节点条目SANS 至少包含localhost- Hostname: orderer5 SANS: - localhost该文件用于cryptogen生成 Orderer 组织example.com的证书与 MSP 目录新增条目后会额外生成orderer5.example.com的 msp/tls 材料organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/供后续配置卷挂载与osnadmin证书参数使用。2.2 在docker-compose-bft中定义第 5 个 Orderer 服务首先在volumes段为数据卷声明一个新卷用于持久化 Orderer 的生产数据目录volumes: ... orderer5.example.com然后添加新 Orderer 的服务定义端口可按需调整orderer5.example.com: container_name: orderer5.example.com image: hyperledger/fabric-orderer:latest labels: service: hyperledger-fabric environment: - FABRIC_LOGGING_SPECDEBUG - ORDERER_GENERAL_LISTENADDRESS0.0.0.0 - ORDERER_GENERAL_LISTENPORT7060 - ORDERER_GENERAL_LOCALMSPIDOrdererMSP - ORDERER_GENERAL_LOCALMSPDIR/var/hyperledger/orderer/msp # enabled TLS - ORDERER_GENERAL_TLS_ENABLEDtrue - ORDERER_GENERAL_TLS_PRIVATEKEY/var/hyperledger/orderer/tls/server.key - ORDERER_GENERAL_TLS_CERTIFICATE/var/hyperledger/orderer/tls/server.crt - ORDERER_GENERAL_TLS_ROOTCAS[/var/hyperledger/orderer/tls/ca.crt] - ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE/var/hyperledger/orderer/tls/server.crt - ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY/var/hyperledger/orderer/tls/server.key - ORDERER_GENERAL_CLUSTER_ROOTCAS[/var/hyperledger/orderer/tls/ca.crt] - ORDERER_GENERAL_BOOTSTRAPMETHODnone - ORDERER_CHANNELPARTICIPATION_ENABLEDtrue - ORDERER_ADMIN_TLS_ENABLEDtrue - ORDERER_ADMIN_TLS_CERTIFICATE/var/hyperledger/orderer/tls/server.crt - ORDERER_ADMIN_TLS_PRIVATEKEY/var/hyperledger/orderer/tls/server.key - ORDERER_ADMIN_TLS_ROOTCAS[/var/hyperledger/orderer/tls/ca.crt] - ORDERER_ADMIN_TLS_CLIENTROOTCAS[/var/hyperledger/orderer/tls/ca.crt] - ORDERER_ADMIN_LISTENADDRESS0.0.0.0:7061 - ORDERER_OPERATIONS_LISTENADDRESSorderer5.example.com:9450 - ORDERER_METRICS_PROVIDERprometheus working_dir: /root command: orderer volumes: - ../organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp:/var/hyperledger/orderer/msp - ../organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/tls:/var/hyperledger/orderer/tls - orderer5.example.com:/var/hyperledger/production/orderer ports: - 7060:7060 - 7061:7061 - 9450:9450 networks: - test关键环境变量解读环境变量作用ORDERER_GENERAL_BOOTSTRAPMETHODnone不使用 genesis block 引导Orderer 通过 Channel Participation API 动态加入通道对应 orderer.yaml 的 BootstrapMethod 配置ORDERER_CHANNELPARTICIPATION_ENABLEDtrue开启通道参与功能是osnadmin可用的前提ORDERER_GENERAL_CLUSTER_*排序集群节点间通信gossip/raft 等使用的 TLS 证书ORDERER_ADMIN_*OrdererAdmin 端点的 TLS 配置与监听地址ORDERER_ADMIN_LISTENADDRESS0.0.0.0:7061osnadmin连接的就是这个端口ORDERER_OPERATIONS_LISTENADDRESS运维指标端点Prometheus 等与 Admin 端点相互独立ORDERER_METRICS_PROVIDERprometheus启用 Prometheus 指标输出关于 TLS 配置上例中 Orderer 集群 TLS 与 Admin TLS 复用了同一套/var/hyperledger/orderer/tls/下的证书server.crt/server.key/ca.crt。实际生产环境通常建议为 Admin 端点单独签发证书。2.3 在 CLI 容器中挂载 Orderer 管理员的证书为了让 CLI 容器能以 Orderer 组织管理员身份操作获取配置块、签名配置更新还需在 CLI 容器定义中追加如下卷volumes: - ../organizations/ordererOrganizations/example.com/users/Adminexample.com/msp:/var/hyperledger/orderer/msp - ../organizations/ordererOrganizations/example.com/users/Adminexample.com/tls:/var/hyperledger/orderer/tls2.4 启动集群./network.sh createChannel -bft该命令将启动由4 个 Orderer 2 个 Peer 1 个 CLI组成的 BFT 网络同时也会启动第 5 个 Ordererorderer5.example.com的容器——但此时它并不属于网络只是处于运行状态等待加入。命令还会创建名为mychannel的通道4 个 Orderer 与 2 个 Peer 均参与其中。-bft标志表示使用 Smart BFT 共识smartbft它基于拜占庭容错BFT模型支持容忍f (N-1)/3个故障节点与 Raft 的容忍度不同因此下文修改BlockValidation策略时计算阈值的方式与 etcdraft 网络./network.sh createChannel不带-bft也有所差异。三、用 osnadmin CLI 将新 Orderer 加入测试通道osnadmin的完整命令参考见 docs/source/commands/osnadminchannel.md由仓库help_docs.sh生成与 cmd/osnadmin/main.go 的命令行定义一一对应。3.1 获取最新配置块peer命令通过环境变量确定它运行在哪个组织的上下文中。先将上下文切换到 Peer 组织Org1export CORE_PEER_LOCALMSPIDOrg1MSP export CORE_PEER_TLS_ROOTCERT_FILE$PEER0_ORG1_CA export CORE_PEER_MSPCONFIGPATH${PWD}/organizations/peerOrganizations/org1.example.com/users/Adminorg1.example.com/msp export CORE_PEER_ADDRESSlocalhost:7051 export ORDERER_CA${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem然后从现有 Ordererorderer.example.com:7050拉取mychannel的最新配置块peer channel fetch config config_block.pb -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel --tls --cafile $ORDERER_CA--ordererTLSHostnameOverride用于在 TLS 握手时以该主机名覆盖连接地址进行证书校验容器网络内主机名与实际监听地址不同时必用-c mychannel指定通道--cafile指向 Orderer 组织的 TLS CA 根证书。得到的config_block.pb是后续所有配置修改与osnadmin channel join的输入。3.2 将新 Orderer 加入通道切换环境变量到新 Orderer第 5 个节点的管理上下文然后执行 joinexport OSN_TLS_CA_ROOT_CERT${PWD}/organizations/ordererOrganizations/example.com/tlsca/tlsca.example.com-cert.pem export ADMIN_TLS_SIGN_CERT${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/server.crt export ADMIN_TLS_PRIVATE_KEY${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/server.key osnadmin channel join --channelID [CHANNEL_NAME] --config-block [CHANNEL_CONFIG_BLOCK] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY各占位符的替换规则CHANNEL_NAME—— 通道名称此处为mychannelCHANNEL_CONFIG_BLOCK—— 最新配置块的路径与文件名即上一步的config_block.pbORDERER_ADMIN_LISTENADDRESS—— 目标 Orderer 的Orderer.Admin.ListenAddress对应orderer.yaml中的配置此处为localhost:7061OSN_TLS_CA_ROOT_CERT—— Orderer 组织 TLS CA 根证书路径若使用中间 TLS CA需同时包含中间证书ADMIN_TLS_SIGN_CERT/ADMIN_TLS_PRIVATE_KEY—— 由 TLS CA 签发的管理员客户端证书与私钥。例如osnadmin channel join --channelID mychannel --config-block config_block.pb -o localhost:7061 --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY注意osnadmin与 Orderer 之间的连接要求双向 TLSmutual TLS因此每条osnadmin命令都必须同时传入--client-cert与--client-key分别对应管理员客户端证书与私钥均由管理员 TLS CA 签发。从 cmd/osnadmin/main.go 的源码可以看到只要指定了--ca-file客户端就会以https://前缀访问-o指定的 Admin 端点并用tls.LoadX509KeyPair加载--client-cert/--client-key建立 mTLS同时 join 前还会调用validateBlockChannelIDmain.go#L210-L229校验配置块中携带的通道 ID 与--channelID一致防止加入错误的通道。命令成功后的输出类似Status: 201 { name: mychannel, url: /participation/v1/channels/mychannel, consensusRelation: follower, status: onboarding, height: 0 }此时该 Orderer 与通道的关系为follower、状态为onboarding它已接收配置块正在从集群其他节点拉取区块追赶高度但尚未成为共识集群成员因为通道配置中还没有它的身份信息。四、修改通道配置把新 Orderer 写入共识集群以下命令需要在CLI 容器中执行或把相关文件拷入 CLI 容器。核心思路是把最新配置块解码为 JSON → 修改 4 处 → 重新编码 → 用configtxlator计算配置更新config update→ 封装成信封 → 签名并提交。4.1 将配置块转换为 JSON使用上一节拉取的config_block.pbconfigtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json从 JSON 块中提取 config 部分jq .data.data[0].payload.data.config config_block.json original_config.json4.2 四步修改配置本阶段的产物是一个配置更新交易update TX。你可以在 CLI 容器中直接计算也可以把original_config.json复制到本地机器上完成全部修改最后再将生成的 TX 拷回 CLI 容器。先创建副本cp original_config.json modified_config.json然后对modified_config.json做以下4 处修改修改 1加入已知端点Endpoints导航到channel_group → groups → Orderer → groups → OrdererOrg → values → Endpoints → value → addresses追加新 Orderer 的端点[ orderer.example.com:7050, orderer2.example.com:7052, orderer3.example.com:7056, orderer4.example.com:7058, orderer5.example.com:7060 ]该列表是客户端Peer/SDK用于发现排序节点的 已知端点。修改 2加入已知身份identities导航到channel_group → groups → Orderer → policies → BlockValidation → policy → value → identities加入新 Orderer 身份证书的 Base64 编码路径请按实际情况修正{ principal: { id_bytes: .../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/signcerts/orderer5.example.com-cert.pem, mspid: OrdererMSP }, principal_classification: IDENTITY }BlockValidation策略规定了哪些 Orderer 的签名能构成一个合法区块Peer 校验区块时依据它。更多背景可参考仓库中该策略的配置示例 orderer/common/cluster/testdata/blockverification/configtx.yaml。修改 3更新策略规则rule导航到channel_group → groups → Orderer → policies → BlockValidation → policy → value → rule根据节点总数重新计算阈值# Given that the new number of nodes in cluster is num_of_nodes: f int((num_of_nodes - 1) / 3) n ceil((num_of_nodes f 1) / 2)并为新 Orderer 追加一个signed_by对象5 节点 BFT 集群n 4{ n_out_of: { n: 4, rules: [ { signed_by: 0 }, { signed_by: 1 }, { signed_by: 2 }, { signed_by: 3 }, { signed_by: 4 } ] } }这里的signed_by: 0..4分别对应 identities 数组中下标为 04 的身份n表示区块至少需要多少个 Orderer 签名对 5 节点 BFT 集群f (5-1)/3 1n ceil((511)/2) ceil(3.5) 4即任一合法区块需满足 4-of-5 的签名规则。修改 4加入 consenter_mapping导航到channel_group → groups → Orderer → values → Orderers → value → consenter_mapping加入新 Orderer 的身份证书、客户端 TLS 证书与服务端 TLS 证书均为 Base64 编码路径按需修正{ client_tls_cert: .../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem, host: orderer5.example.com, id: 5, identity: .../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/signcerts/orderer5.example.com-cert.pem, msp_id: OrdererMSP, port: 7060, server_tls_cert: .../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem }consenter_mapping定义了每个共识集群成员consenter的节点标识id、host、port、MSP ID 及三张证书。它是集群节点间建立互信与通信的通讯录也是共识协议识别谁是集群成员的依据。id必须唯一且与集群内其他节点不同此处为 5。4.3 使用 Python 脚本自动完成上述 4 处修改为简化这一繁琐过程官方提供了一个 Python 脚本位于 fabric-samples 仓库test-network/scripts目录下的add_new_orderer_to_config.py可自动完成步骤 14。用法示例python3 scripts/add_new_orderer_to_config.py original_config.json modified_config.json \ -a orderer5.example.com:7060 \ -i ./organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/signcerts/orderer5.example.com-cert.pem \ -s ./organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -c ./organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem其中-a指定端点host:port、-i指定身份证书、-s指定服务端 TLS 证书、-c指定客户端 TLS 证书。4.4 计算配置更新 TXconfigtxlator proto_encode --input original_config.json --type common.Config --output original_config.pb configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb configtxlator compute_update --channel_id mychannel --original original_config.pb --updated modified_config.pb --output config_update.pb configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json echo {payload:{header:{channel_header:{channel_id:mychannel, type:2}},data:{config_update:$(cat config_update.json)}}} | jq . config_update_in_envelope.json configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output envelope.pb得到的envelope.pb即配置更新交易config update TX。注意它不包含任何文件路径信息若是在本地机器上生成的需要将其复制到 CLI 容器内再继续。五、签名并提交配置更新5.1 用 Peer 组织签名配置更新交易必须同时获得 Peer 组织与 Orderer 组织的签名。当前上下文是 Peer 组织Org1直接签名peer channel signconfigtx -f envelope.pb5.2 切换到 Orderer 组织并提交切换到 Orderer 组织Orderer的上下文export CORE_PEER_TLS_ENABLEDtrue export CORE_PEER_LOCALMSPIDOrdererMSP export CORE_PEER_TLS_ROOTCERT_FILE/var/hyperledger/orderer/tls/ca.crt export CORE_PEER_MSPCONFIGPATH/var/hyperledger/orderer/msp export CORE_PEER_ADDRESSlocalhost:7050提交更新peer channel update -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel -f envelope.pb --tls --cafile $ORDERER_CA成功的输出类似INFO [channelCmd] InitCmdFactory - Endorser and orderer connections initialized INFO [channelCmd] update - Successfully submitted channel update5.3 验证新 Orderer 已变为 consenter用osnadmin channel list查看指定通道详情osnadmin channel list --channelID mychannel -o localhost:7061 --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY输出中consensusRelation应自动从follower变为consenterstatus从onboarding变为active{ name: mychannel, url: /participation/v1/channels/mychannel, consensusRelation: consenter, status: active, height: 4 }这个状态转换正好对应 orderer/common/types/channelinfo.go 中定义的两种枚举加入配置后该 Orderer 进入了通道的 consenters 集合consenter且区块高度已追平集群active。新 Orderer 的日志中也会出现 Smart BFT 共识的心跳与区块消息例如DEBU [orderer.consensus.smartbft.consensus] ProcessMessages - 5 got message from 1: HeartBeat with view: 0, seq: 7 channelmychannel DEBU [orderer.consensus.smartbft.consensus] handleHeartBeat - Received heartbeat from 1, last heartbeat was 5.995614586s ago channelmychannel DEBU [orderer.consensus.smartbft.consensus] followerTick - Last heartbeat from 1 was 1.000437542s ago channelmychannel DEBU [orderer.consensus.smartbft.consensus] followerTick - Last heartbeat from 1 was 2.003549876s ago channelmychannel DEBU [orderer.consensus.smartbft.consensus] followerTick - Last heartbeat from 1 was 3.00110746s ago channelmychannel DEBU [orderer.consensus.smartbft.consensus] followerTick - Last heartbeat from 1 was 3.99966021s ago channelmychannel DEBU [orderer.consensus.smartbft.consensus] followerTick - Last heartbeat from 1 was 5.000054669s ago channelmychannel DEBU [orderer.consensus.smartbft.consensus] followerTick - Last heartbeat from 1 was 5.999811586s ago channelmychannel这些日志表明新节点已与集群中的其他节点编号 1建立心跳并同步了视图view: 0正式成为共识集群一员。Smart BFT 共识实现位于 orderer/consensus/smartbft其 follower/leader 状态机与区块复制逻辑正是上述日志的来源。六、反向操作从现有网络中移除一个 Orderer移除流程是添加流程的逆过程先从通道配置中移除该节点4 处修改的逆操作提交配置更新再用osnadmin channel remove让该 Orderer 退出通道。6.1 准备配置更新切换到 Peer 组织上下文export CORE_PEER_TLS_ENABLEDtrue export CORE_PEER_LOCALMSPIDOrg1MSP export CORE_PEER_TLS_ROOTCERT_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem export CORE_PEER_MSPCONFIGPATH/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org1.example.com/users/Adminorg1.example.com/msp export CORE_PEER_ADDRESSlocalhost:7051拉取最新配置块并转换为 JSONpeer channel fetch config config_block.pb -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel --tls --cafile $ORDERER_CA configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json jq .data.data[0].payload.data.config config_block.json original_config.json按照上一节4 处修改的逆序把待移除的 Orderer即第 5 个从 JSON 中删除保存为modified_config.json即从 consenter_mapping 删除其条目、恢复 BlockValidation 的 identities/rule、从 Endpoints 删除其端点。计算更新configtxlator proto_encode --input original_config.json --type common.Config --output original_config.pb configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb configtxlator compute_update --channel_id mychannel --original original_config.pb --updated modified_config.pb --output config_update.pb configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json echo {payload:{header:{channel_header:{channel_id:mychannel, type:2}},data:{config_update:$(cat config_update.json)}}} | jq . config_update_in_envelope.json configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output envelope.pb用 Peer 组织签名peer channel signconfigtx -f envelope.pb6.2 提交移除配置更新切换到 Orderer 组织并提交export CORE_PEER_TLS_ENABLEDtrue export CORE_PEER_LOCALMSPIDOrdererMSP export CORE_PEER_TLS_ROOTCERT_FILE/var/hyperledger/orderer/tls/ca.crt export CORE_PEER_MSPCONFIGPATH/var/hyperledger/orderer/msp export CORE_PEER_ADDRESSlocalhost:7050 peer channel update -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel -f envelope.pb --tls --cafile $ORDERER_CA预期输出INFO [channelCmd] InitCmdFactory - Endorser and orderer connections initialized INFO [channelCmd] update - Successfully submitted channel update6.3 从 Orderer 移除通道osnadmin channel remove -o localhost:7061 --ca-file $ORDERER_CA --client-cert $ORDERER_ADMIN_TLS_SIGN_CERT --client-key $ORDERER_ADMIN_TLS_PRIVATE_KEY --channelID mychannel预期输出为Status: 204对应 restapi.go 中serveRemove返回的 204 状态码表示成功移除。此时被移除的 Orderer 日志会显示通道关闭与退出INFO [orderer.consensus.smartbft.chain] Halt - Shutting down chain channelmychannel INFO [orderer.consensus.smartbft.consensus] func1 - Exiting channelmychannel INFO [orderer.consensus.smartbft.consensus] func1 - Exiting channelmychannel INFO [orderer.common.multichannel] removeMember - Removed channel: mychannel七、总结与扩展阅读本文完整覆盖了 Fabric 3.x 下 Orderer 动态扩缩容的两条关键链路节点侧本地osnadmin channel join/channel remove通过 Channel Participation APIorderer/common/channelparticipation/restapi.go让单个 Orderer 加入/退出通道其状态由consensusRelationfollower/consenter等与statusonboarding/active等描述orderer/common/types/channelinfo.go配置侧全网通过configtxlator修改通道配置Endpoints、BlockValidationidentities 与 rule、consenter_mapping把新节点写入共识集群使follower → consenter移除时按逆序操作即可。osnadmin channel的完整子命令join/list/remove/update/fetch与全部参数可查阅 docs/source/commands/osnadminchannel.mdorderer.yaml中Orderer.Admin.ListenAddress、Orderer.ChannelParticipation.Enabled等基础配置见 sampleconfig/orderer.yaml。通道参与机制更广泛的介绍含如何把第一个 Orderer 加入新通道可参考仓库内同目录的 docs/source/create_channel/create_channel_participation.md 与 docs/source/create_channel/create_channel_test_net.md。需要提醒的是动态扩容是一个有风险的管理操作生产环境务必先在测试网络验证配置修改、策略阈值计算BFT 的n/f公式与证书材料并确保所有参与签名的组织Peer 组织与 Orderer 组织都完整执行签名流程否则配置更新将因策略不满足而被拒绝。赞分享区块链密码学【免费下载链接】fabricHyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.项目地址https://gitcode.com/gh_mirrors/fabr/fabric点击查看免费下载相关推荐Hyperledger Fabric 的 osnadmin channel 命令完全指南orderer 通道参与管理实战Hyperledger Fabric 的 osnadmin channel 命令完全指南orderer 通道参与管理实战 导读 本文聚焦 Hyperledge区块链密码学猫抓 cat-catch 使用指南网页视频下载与 m3u8 解析一次讲清猫抓 cat catch 使用指南网页视频下载与 m3u8 解析一次讲清 上次想把一段网页上的教学视频存到本地右键菜单里没有下载项下载器填地址也提示无法识区块链密码学Hyperledger Fabric 通道组织移除实战从 channel 中移除 Org 的完整操作指南Hyperledger Fabric 通道组织移除实战从 channel 中移除 Org 的完整操作指南 导读 本指南基于 Hyperledger Fabri区块链密码学上一篇Buzz完全离线的专业音频转录工具保护隐私的同时提升工作效率下一篇artistic-videos未来发展方向实时风格迁移与多风格融合技术展望创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考