区块链密码学【免费下载链接】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 是面向企业的许可制分布式账本框架其**服务发现Service Discovery**模块负责在去中心化网络中同步哪些 Peer 在线、谁装了链码、背书策略是什么等关键元数据是 Fabric Gateway 与客户端应用能够自动完成背书节点选择、交易提交的前提。本文基于当前仓库中的官方文档 discovery-overview.rst 与配套的 discovery-cli.md结合 discovery 目录下的源码实现系统讲解服务发现的工作原理、四类查询能力、TLS 特殊要求以及如何使用discover命令行工具完成配置持久化、Peer 成员查询、通道配置查询与背书者查询。读完本文你将能够独立完成 Peer 的 discovery 配置并用 CLI 验证通道内各组织的背书拓扑。为什么需要服务发现客户端应用通过 Fabric Gateway 在 Peer 上执行链码、向 Orderer 提交交易并查询交易状态。为此Peer 上的 Gateway 服务必须知道两件事相关链码的背书策略endorsement policy哪些 Peer安装了该链码。Discovery service服务发现服务的职责就是在 Peer 之间保持这些信息的同步。随后Fabric Gateway 与服务发现交互来确定一笔交易需要哪些 Peer 背书、以及把交易发送给哪些 Orderer 节点。简言之服务发现把静态配置背书节点清单变成了动态、实时地计算背书计划这是 Fabric 网络规模化部署下客户端无需关心节点拓扑的基础。服务发现在 Fabric 中的工作方式整体流程可概括为以下环节引导Bootstrap应用启动时只需知道一个或多个被应用开发者/管理员信任的 Gateway Peer。一个理想的候选 Peer 是与应用同属一个组织的 Peer。前提条件要让 Peer 被服务发现所感知它必须配置peer.gossip.externalEndpoint具体配置方式见下文及 discovery-cli.md。未配置该字段的 Peer 会被 Fabric 视为不应被披露不会出现在其他组织的发现结果中。查询与刷新服务发现客户端如discoverCLI 或另一个 Gateway Peer向服务发现服务发起配置查询configuration query获取通道内 Peer 的信息该信息可在任意时刻通过向某 Peer 的服务发现服务再次发起查询来刷新。数据来源服务发现服务运行在 Peer 上使用gossip 通信层维护的网络元数据判断哪些 Peer 在线同时从 Peer 的**状态数据库state database**获取诸如背书策略之类的信息。这一点在源码接口中有清晰体现discovery/api.go 中定义了GossipSupportPeersOfChannel、Peers、IdentityInfo与EndorsementSupportPeersForEndorsement、PeersAuthorizedByCriteria等能力接口服务发现正是通过它们聚合 gossip 层与账本层的信息。背书描述符Layouts 与 EndorsersByGroups借助服务发现代表客户端应用的 Peer Gateway 只需向服务发现服务发送一个查询给定通道和链码 ID需要哪些 Peer服务发现服务随后计算出一个描述符descriptor该描述符由两个对象构成Layouts布局一组 Peer 分组以及每个分组中应被选中的 Peer 数量。Group to peer mapping分组到 Peer 的映射从布局中的分组映射到通道中的 Peer。实践中每个分组通常代表一个组织但由于服务 API 是通用的、不感知组织的存在这里只称为分组group。以下是对策略AND(Org1, Org2)求值得到的一个描述符示例每个组织各有两个 PeerLayouts: [ QuantitiesByGroup: { Org1: 1, Org2: 1, } ], EndorsersByGroups: { Org1: [peer0.org1, peer1.org1], Org2: [peer0.org2, peer1.org2] }换句话说背书策略要求来自 Org1 的一个 Peer 与来自 Org2 的一个 Peer 的签名同时描述符给出了这些组织中可用于背书的 Peer 名称Org1 与 Org2 中都有peer0和peer1。当协调一笔交易时Peer Gateway 会选择一个背书布局如上例中 Org1ANDOrg2 的策略然后依据当前哪些 Peer 可用、以及它们的**账本高度ledger height**等信息从布局中挑选目标背书 Peer。从源码层面看该描述符的生成逻辑位于 discovery/endorsement/endorsement.goPeersForEndorsement方法先通过peersByCriteria过滤出安装了链码且满足私有数据集合collection授权的 Peer再结合从通道策略管理器中取出的principalsSets主体集合由背书策略派生计算出最终的EndorsementDescriptor。也就是说描述符是背书策略求值 gossip 成员视图两个信息源的交叉结果。服务发现服务的能力服务发现服务能够响应以下四类查询Configuration query配置查询返回通道中所有组织的MSPConfig以及通道的 Orderer 端点。Peer membership queryPeer 成员查询返回已加入该通道的 Peer。Endorsement query背书查询返回给定通道中指定链码的背书描述符。Local peer membership query本地 Peer 成员查询返回响应查询的那个 Peer 的本地成员信息。默认情况下只有该 Peer 的管理员才能执行此类查询。这四类查询与源码中的分发器一一对应。在 discovery/service.go 中NewService将通道级查询注册为ConfigQueryType配置查询、ChaincodeQueryType背书查询、PeerMembershipQueryTypePeer 成员查询而本地查询仅注册LocalMembershipQueryTypedispatch方法会根据查询是否携带通道名将请求路由到不同的分发器discovery/service.go本地查询只会被路由到无通道channel-less分发器。另外需要说明的是服务发现服务默认启用其开关与认证缓存参数位于 Peer 的core.yaml中详见下文服务发现相关配置小节。特殊要求TLS当 Peer 以 TLS 启用状态运行时客户端在连接 Peer 时必须提供 TLS 证书。如果 Peer 未配置验证客户端证书即clientAuthRequired为false则该 TLS 证书可以是自签名的。这一要求在源码的请求校验逻辑中有更严格的体现validateStructurediscovery/service.go在 TLS 启用时会从 gRPC 流上下文中提取客户端 TLS 证书哈希并与请求内声明的ClientTlsCertHash比对不一致则直接拒绝请求——因此即使 Peer 未强制要求客户端认证discovery 层的请求仍然需要携带 TLS 证书。服务发现 CLIdiscover使用指南服务发现服务拥有自己的命令行界面CLI它使用一个YAML 配置文件来持久化证书路径、私钥路径以及 MSP ID 等属性。discover命令包含以下子命令saveConfigpeersconfigendorsers命令的完整用法如下usage: discover [flags] command [args ...] Command line client for fabric discovery service Flags: --help Show context-sensitive help (also try --help-long and --help-man). --configFileCONFIGFILE Specifies the config file to load the configuration from --peerTLSCAPEERTLSCA Sets the TLS CA certificate file path that verifies the TLS peers certificate --tlsCertTLSCERT (Optional) Sets the client TLS certificate file path that is used when the peer enforces client authentication --tlsKeyTLSKEY (Optional) Sets the client TLS key file path that is used when the peer enforces client authentication --userKeyUSERKEY Sets the users key file path that is used to sign messages sent to the peer --userCertUSERCERT Sets the users certificate file path that is used to authenticate the messages sent to the peer --MSPMSP Sets the MSP ID of the user, which represents the CA(s) that issued its user certificate Commands: help [command...] Show help. peers [flags] Discover peers config [flags] Discover channel config endorsers [flags] Discover chaincode endorsers saveConfig Save the config passed by flags into the file specified by --configFile这些子命令的注册逻辑位于 discovery/cmd/cmd.gopeers、config子命令均支持--server与--channel标志endorsers子命令额外支持--chaincode、--collection与--noPrivateReads标志。各子命令执行时通过Stub.Send将请求发送给目标 Peer再由各自的ResponseParser将响应解析为 JSON 输出例如 discovery/cmd/config.go 中ConfigResponseParser使用json.MarshalIndent格式化输出配置结果。配置外部端点externalEndpoint要让 Peer 暴露给服务发现必须在core.yaml中配置peer.gossip.externalEndpoint。否则Fabric 会假定该 Peer 不应被披露。该配置项的注释与默认值可见于 sampleconfig/core.yaml# This is an endpoint that is published to peers outside of the organization. # If this isnt set, the peer will not be known to other organizations and will not be exposed via service discovery. externalEndpoint:该值也可以通过环境变量覆盖CORE_PEER_GOSSIP_EXTERNALENDPOINTpeer1.org1.example.com:8051注意core.yaml中 gossip 下还有一个endpoint字段其注释明确指出它覆盖 Peer 向本组织内Peer 发布的端点而外部组织看到的是externalEndpointsampleconfig/core.yaml。因此若希望 Peer 被跨组织发现务必设置externalEndpoint。持久化配置saveConfig要持久化配置需要通过--configFile指定配置文件名称并使用saveConfig命令discover --configFile conf.yaml --peerTLSCA tls/ca.crt --userKey msp/keystore/ea4f6a38ac7057b6fa9502c2f5f39f182e320f71f667749100fe7dd94c23ce43_sk --userCert msp/signcerts/User1org1.example.com-cert.pem --MSP Org1MSP saveConfig执行上述命令后将生成如下配置文件$ cat conf.yaml version: 0 tlsconfig: certpath: keypath: peercacertpath: /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/User1org1.example.com/tls/ca.crt timeout: 0s signerconfig: mspid: Org1MSP identitypath: /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/User1org1.example.com/msp/signcerts/User1org1.example.com-cert.pem keypath: /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/User1org1.example.com/msp/keystore/ea4f6a38ac7057b6fa9502c2f5f39f182e320f71f667749100fe7dd94c23ce43_sk配置文件的tlsconfig段保存 TLS 相关路径certpath、keypath、peercacertpath、timeoutsignerconfig段保存签名者身份mspid、identitypath、keypath这些字段正是 CLI 向 Peer 发送签名请求与建立 TLS 连接时所需的全部凭据。TLS 行为细节当 Peer 启用 TLS 运行时Peer 上的服务发现服务要求客户端以**双向 TLSmutual TLS**连接即使 Peer 未将tls.clientAuthRequired设为true。当tls.clientAuthRequired为false时Peer 仍然会请求客户端 TLS 证书如果客户端提供了会进行验证但不强制要求。因此如果客户端不传 TLS 证书TLS 连接虽然可以建立到 Peer却会在 Peer 的 discovery 层被拒绝。为此discovery CLI 在用户未显式设置 TLS 证书时会自行生成一个当配置文件配置了peercacertpath但certpath与keypath未配置如上面的 conf.yaml 所示时discovery CLI 会生成一个自签名 TLS 证书并用它连接 Peer。当peercacertpath也未配置时discovery CLI 将以无 TLS方式连接——这是非常不推荐的做法因为信息将以明文、未加密的形式在网络上传输。执行查询三种服务端查询实战discovery CLI 作为服务发现客户端需要针对某个 Peer 执行通过--server标志指定目标 Peer。此外由于查询是通道作用域的必须使用--channel标志。唯一不需要通道的查询是本地成员查询且默认只有被查询 Peer 的管理员可以使用。discover CLI 支持所有服务端查询Peer 成员查询、配置查询、背书者查询。下面逐一演示它们的调用方式与输出解析。Peer 成员查询Peer membership query$ discover --configFile conf.yaml peers --channel mychannel --server peer0.org1.example.com:7051 [ { MSPID: Org2MSP, LedgerHeight: 5, Endpoint: peer0.org2.example.com:9051, Identity: -----BEGIN CERTIFICATE-----\nMIICKTCCAc...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, Chaincodes: [ mycc ] }, { MSPID: Org2MSP, LedgerHeight: 5, Endpoint: peer1.org2.example.com:10051, Identity: -----BEGIN CERTIFICATE-----\nMIICKDCCAc...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, Chaincodes: [ mycc ] }, { MSPID: Org1MSP, LedgerHeight: 5, Endpoint: peer0.org1.example.com:7051, Identity: -----BEGIN CERTIFICATE-----\nMIICKDCCAc6...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, Chaincodes: [ mycc ] }, { MSPID: Org1MSP, LedgerHeight: 5, Endpoint: peer1.org1.example.com:8051, Identity: -----BEGIN CERTIFICATE-----\nMIICJzCCAc6...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, Chaincodes: null } ]如上所示该命令输出一个 JSON包含被查询 Peer 所拥有的、关于通道内所有 Peer 的成员信息。每个 Peer 条目给出MSPID所属组织LedgerHeight账本高度Gateway 挑选背书 Peer 的重要依据Endpoint对外端点即externalEndpointIdentity该 Peer 的注册证书enrollment certificateChaincodes该 Peer 上安装的链码列表null表示未安装该链码。返回的Identity可以使用jq与openssl组合解析为可读证书文本$ discover --configFile conf.yaml peers --channel mychannel --server peer0.org1.example.com:7051 | jq .[0].Identity | sed s/\\\n/\n/g | sed s/\//g | openssl x509 -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 55:e9:3f:97:94:d5:74:db:e2:d6:99:3c:01:24:be:bf Signature Algorithm: ecdsa-with-SHA256 Issuer: CUS, STCalifornia, LSan Francisco, Oorg2.example.com, CNca.org2.example.com ... Subject: CUS, STCalifornia, LSan Francisco, OUpeer, CNpeer0.org2.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) ...在源码层面通道成员查询的响应由channelMembershipResponsediscovery/service.go构造它先通过PeersAuthorizedByCriteria获取通道内 Peer再按组织分组并仅返回同时存在于通道视图channel view中的 Peer通过比对 stateInfo 消息实现最后包装为PeerMembershipResult。配置查询Configuration query配置查询返回MSP ID 到 Orderer 端点的映射以及可用于验证所有 Peer 和 Orderer 节点的FabricMSPConfigSDK 用它校验节点身份$ discover --configFile conf.yaml config --channel mychannel --server peer0.org1.example.com:7051 { msps: { OrdererOrg: { name: OrdererMSP, root_certs: [ LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNMekNDQWRhZ0...(base64 编码的证书此处省略)... ], admins: [ LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNDVENDQWJDZ0...(base64 编码的证书此处省略)... ], crypto_config: { signature_hash_family: SHA2, identity_identifier_hash_function: SHA256 }, tls_root_certs: [ LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNORENDQWR1Z0...(base64 编码的证书此处省略)... ] }, Org1MSP: { name: Org1MSP, root_certs: [ ... ], admins: [ ... ], crypto_config: { signature_hash_family: SHA2, identity_identifier_hash_function: SHA256 }, tls_root_certs: [ ... ], fabric_node_ous: { enable: true, client_ou_identifier: { certificate: ...(base64 编码的证书此处省略)..., organizational_unit_identifier: client }, peer_ou_identifier: { certificate: ...(base64 编码的证书此处省略)..., organizational_unit_identifier: peer } } }, Org2MSP: { ... }, Org3MSP: { ... } }, orderers: { OrdererOrg: { endpoint: [ { host: orderer.example.com, port: 7050 } ] } } }需要特别注意的是这里的证书是base64 编码的应按类似如下方式解码$ discover --configFile conf.yaml config --channel mychannel --server peer0.org1.example.com:7051 | jq .msps.OrdererOrg.root_certs[0] | sed s/\//g | base64 --decode | openssl x509 -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: c8:99:2d:3a:2d:7f:4b:73:53:8b:39:18:7b:c3:e1:1e Signature Algorithm: ecdsa-with-SHA256 Issuer: CUS, STCalifornia, LSan Francisco, Oexample.com, CNca.example.com ...配置查询在源码中对应configQuerydiscovery/service.go它直接调用Config(channel)从通道配置中取出完整的 MSP 与 Orderer 信息并原样返回。从输出中可以看到配置查询覆盖了组织的 root 证书、admin 证书、TLS 根证书、加密配置哈希族 SHA2 / SHA256以及 Fabric 节点 OU 标识client与peer两种 OU这些信息足以让 SDK 独立验证网络中各节点的身份。背书者查询Endorsers query要查询链码调用的背书者需要额外提供以下标志--chaincode必填指定链码名称。如果要查询链码到链码的调用需要重复--chaincode标志传入所有链码。--collection指定链码预期使用的私有数据集合。为了把集合与--chaincode传入的链码对应起来使用如下语法collectionCC:Collection1,Collection2,...。--noPrivateReads用于指示某链码的交易不会读取私有数据。这对私有数据的盲写blind writes等场景很有用。例如要查询一个同时调用 cc1 和 cc2、且 cc2 会向私有数据集合 col1 写入的链码调用需要指定--chaincodecc1 --chaincodecc2 --collectioncc2:col1如果链码 cc2 预期不会从集合col1读取数据则应使用--noPrivateReadscc2。下面是在背书策略为AND(Org1.peer, Org2.peer)时对链码mycc执行背书者查询的输出$ discover --configFile conf.yaml endorsers --channel mychannel --server peer0.org1.example.com:7051 --chaincode mycc [ { Chaincode: mycc, EndorsersByGroups: { G0: [ { MSPID: Org1MSP, LedgerHeight: 5, Endpoint: peer0.org1.example.com:7051, Identity: -----BEGIN CERTIFICATE-----\nMIICKDCCAc...(证书内容此处省略)...\n-----END CERTIFICATE-----\n } ], G1: [ { MSPID: Org2MSP, LedgerHeight: 5, Endpoint: peer1.org2.example.com:10051, Identity: -----BEGIN CERTIFICATE-----\nMIICKDCCAc...(证书内容此处省略)...\n-----END CERTIFICATE-----\n }, { MSPID: Org2MSP, LedgerHeight: 5, Endpoint: peer0.org2.example.com:9051, Identity: -----BEGIN CERTIFICATE-----\nMIICJzCCAc6...(证书内容此处省略)...\n-----END CERTIFICATE-----\n } ] }, Layouts: [ { quantities_by_group: { G0: 1, G1: 1 } } ] } ]可以看到输出正是文档概述中描述的EndorsersByGroups Layouts描述符结构G0对应 Org1只需选择 1 个 PeerG1对应 Org2也只需选择 1 个 Peer而 Org2 下同时提供了peer0与peer1两个可选背书者——Gateway 可以结合可用性与账本高度从中择优。在源码中背书查询由chaincodeQuerydiscovery/service.go处理它先通过validateCCQuery校验查询中至少包含一个链码兴趣interest且链码名非空discovery/service.go然后对查询中的每个 interest 调用PeersForEndorsement生成背书描述符最终包装为ChaincodeQueryResult返回。多链码兴趣链码间调用与集合约束则通过ChaincodeInterest结构携带由 discovery/endorsement/endorsement.go 的peersByCriteria完成按已安装链码过滤 按集合成员授权过滤的两层筛选。不使用配置文件执行查询discovery CLI 也可以不借助配置文件直接将所有所需配置作为命令行标志传入。下面是加载管理员凭据执行本地 Peer 成员查询的示例$ discover --peerTLSCA tls/ca.crt --userKey msp/keystore/cf31339d09e8311ac9ca5ed4e27a104a7f82f1e5904b3296a170ba4725ffde0d_sk --userCert msp/signcerts/Adminorg1.example.com-cert.pem --MSP Org1MSP --tlsCert tls/client.crt --tlsKey tls/client.key peers --server peer0.org1.example.com:7051 [ { MSPID: Org1MSP, Endpoint: peer1.org1.example.com:8051, Identity: -----BEGIN CERTIFICATE-----\nMIICJzCCAc6...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, }, { MSPID: Org1MSP, Endpoint: peer0.org1.example.com:7051, Identity: -----BEGIN CERTIFICATE-----\nMIICKDCCAc6...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, }, { MSPID: Org2MSP, Endpoint: peer0.org2.example.com:9051, Identity: -----BEGIN CERTIFICATE-----\nMIICKTCCAc...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, }, { MSPID: Org2MSP, Endpoint: peer1.org2.example.com:10051, Identity: -----BEGIN CERTIFICATE-----\nMIICKDCCAc...(证书内容此处省略)...\n-----END CERTIFICATE-----\n, } ]与通道作用域的成员查询不同本地成员查询返回的是被查询 Peer 自身的 gossip 成员视图包括组织内与组织外的所有已知 Peer且不需要--channel标志。从源码看它对应localMembershipResponsediscovery/service.go只按组织聚合computeMembership的结果不做通道视图过滤。同时要注意默认情况下本地查询仅对 Peer 管理员开放——这由core.yaml中peer.discovery.orgMembersAllowedAccess控制见下文。服务发现相关配置速查Peer 端服务发现的开关与认证缓存参数位于core.yaml的peer.discovery段sampleconfig/core.yaml# The discovery service is used by clients to query information about peers, # such as - which peers have joined a certain channel, what is the latest # channel config, and most importantly - given a chaincode and a channel, # what possible sets of peers satisfy the endorsement policy. discovery: enabled: true # Whether the authentication cache is enabled or not. authCacheEnabled: true # The maximum size of the cache, after which a purge takes place authCacheMaxSize: 1000 # The proportion (0 to 1) of entries that remain in the cache after the cache is purged due to overpopulation authCachePurgeRetentionRatio: 0.75 # Whether to allow non-admins to perform non channel scoped queries. # When this is false, it means that only peer admins can perform non channel scoped queries. orgMembersAllowedAccess: false各参数含义如下enabled默认true服务发现总开关。由于 Gateway 依赖服务发现获取 Peer/Orderer 连接信息并计算背书组合凡启用 Gateway 服务的 Peer 上服务发现必须始终保持开启参见 gateway.md 中的说明。authCacheEnabled默认true是否启用认证缓存。启用后客户端对服务发现的授权判定结果会被缓存降低重复查询的开销。authCacheMaxSize默认1000认证缓存的最大条目数超过该值将触发清理。authCachePurgeRetentionRatio默认0.75缓存因过载被清理后保留的条目比例0 到 1 之间。orgMembersAllowedAccess默认false是否允许非管理员执行非通道作用域查询即本地成员查询。为false时只有 Peer 管理员可以执行此类查询。这些参数在源码中与 discovery/service.go 的Config结构TLS、AuthCacheEnabled、AuthCacheMaxSize、AuthCachePurgeRetentionRatio一一对应并在NewService中传入newAuthCache构建认证缓存。此外请求的授权判定EligibleForService发生在processQuerydiscovery/service.go中若查询的通道不存在或客户端身份不满足通道访问控制服务会返回access denied。与 Fabric Gateway 的协作关系服务发现并非孤立的工具模块它是 Fabric Gateway 交易流程的核心依赖。Gateway 在端到端处理一笔交易时会通过以下步骤使用服务发现先在一个选定的 Peer 上模拟simulate交易提案捕获被访问的状态以及由此涉及的背书策略组合包括链码背书策略、私有数据集合背书策略与基于状态背书 SBE 策略将捕获到的策略信息组装为ChaincodeInterestprotobuf 结构传给服务发现服务以推导出针对该提案的背书计划Gateway 按背书计划向各所需组织请求背书并在每个组织中优先选择账本高度最高的可用 Peer。其中背书计划正是前文描述符Layouts EndorsersByGroups的应用形态。当组织内某个节点不可用时Gateway 会借助服务发现的成员信息进行重试尝试该组织的其他 Peer若某组织整体背书失败则转向另一个满足背书策略的组织组合详见 gateway.md。此外涉及私有数据尤其是 transient data的交易Gateway 会把背书组织集合限制为私有数据集合的成员组织以保护敏感数据不流向非授权组织。结语服务发现是 Hyperledger Fabric 网络去静态配置化的关键能力它以 gossip 成员视图为感知基础、以账本中的背书策略为计算依据将这笔交易该找谁背书、该发给哪个 Orderer转化为可动态计算的问题。本文从 discovery-overview.rst 概述出发结合 discovery-cli.md 的完整 CLI 操作并对照 discovery 源码与 sampleconfig/core.yaml 配置覆盖了描述符原理、四类查询能力、TLS 互认要求、discover工具的配置持久化与三种查询实战。建议读者在部署测试网络后依次执行saveConfig、peers、config、endorsers四条命令观察不同背书策略下描述符的输出差异从而建立对 Fabric 背书拓扑的直观理解。赞分享区块链密码学【免费下载链接】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点击查看免费下载相关推荐Backstage Discovery Service 深度解析插件间服务发现与内外部 Base URL 配置指南Backstage Discovery Service 深度解析插件间服务发现与内外部 Base URL 配置指南 Discovery Service 是 B开发者门户后端前端基于 gRPC Python 的 CSDSClient Status Discovery Service调试服务原理、接入与实战基于 gRPC Python 的 CSDSClient Status Discovery Service调试服务原理、接入与实战 导读 本文以 gRPC后端RPC框架微服务通信服务发现Service Discovery实战指南经典模式、注册中心与生态工具选型服务发现Service Discovery实战指南经典模式、注册中心与生态工具选型 导读 本文基于 Awesome Software Architectu文档知识库上一篇Helm Dashboard本地开发环境搭建终极指南从源码到运行的完整教程下一篇Snapcast会话持久化保存与恢复你的播放状态创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考