Hyperledger Fabric v2.3中Org2 Peer跨链码交互及权限问题咨询

普通用户无链码访问权限的常见排查方向 #

• 链码内的身份校验逻辑硬编码限制：多数新手开发的链码会在入口处直接校验调用者的MSP身份，仅允许组织管理员角色通过校验，没有为普通成员身份开放调用权限。需要调整链码内的身份判断逻辑，基于调用者的证书属性放开对应普通用户的访问范围，避免直接硬编码过滤所有非管理员身份的请求。
• 链码背书策略配置过严：2.3版本采用链码生命周期管理模式，如果部署链码时配置的背书策略仅要求管理员身份签名即可生效，普通用户发起的提案会被Peer节点直接判定不满足背书要求，无法生成合法背书结果。需要根据业务需求调整背书策略为成员级别的校验规则，比如普通查询类交易可以配置为单组织成员背书即可，写操作再要求多组织联合背书。
• 通道ACL配置权限不足：Fabric通道默认的访问控制列表如果仅对管理员角色开放peer/Propose、event/block等操作权限，普通用户身份即使有合法的客户端凭证，也无法通过Peer的基础权限校验。需要通过通道配置更新，将普通用户对应的角色权限绑定到上述操作点上。

Org2 Peer与已部署链码的交互实操步骤 #

按照2.3版本的链码生命周期流程完成以下操作，即可实现Org2 Peer对链码的正常交互：

• 前置状态校验：在Org2对应的Peer节点环境中执行peer lifecycle chaincode checkcommitreadiness，核对当前通道内已经提交的链码名称、版本、序列编号、代码哈希值，与Org2 Peer本地存储的链码信息是否一致，信息不匹配时Org2 Peer将无法响应链码调用请求。
• 链码安装操作：如果状态校验不通过，需要在Org2 Peer上安装对应版本的链码压缩包，执行peer lifecycle chaincode install <链码包的本地路径>，安装完成后通过peer lifecycle chaincode queryinstalled获取Org2 Peer上对应链码的专属package ID。
• 组织层面审批：执行peer lifecycle chaincode approveformyorg --channelID <通道ID> --name <链码名称> --version <链码版本号> --sequence <链码序列值> --packageID <上一步获取的package ID> --init-required <是否需要初始化链码>，完成Org2组织对当前版本链码的运行授权。如果链码需要初始化，第一次发起调用时必须带上--isInit参数完成初始化流程，否则后续所有调用都会返回未初始化错误。
• 连通性验证：使用Org2的普通用户客户端身份，构造链码查询提案并指定Org2 Peer为背书节点，正常返回CouchDB内的账本数据即说明交互打通。如果使用CouchDB作为状态库，需要确认Org2 Peer上的链码已经提前创建好查询所需的索引，避免大表扫描导致的调用超时。

网络内不同Peer节点的实际交互逻辑 #

结合Fabric的基础架构，通道内不同Peer的交互完全基于既定的交易流程运转，不存在跨Peer的实时逻辑交互：

• 提案背书阶段：客户端根据链码背书策略，将同一份交易提案发送给所有要求参与背书的Peer节点，每个Peer独立在本地的隔离链码容器中执行交易逻辑，读取本地CouchDB的状态数据生成读写集，附上组织签名后将响应返回给客户端。这个阶段Peer之间不会直接传输执行结果，也不会做跨Peer的结果一致性校验。
• 交易排序阶段：客户端收集到满足数量要求的合法背书响应后，将组装完成的交易请求发送给排序节点，排序节点对交易做全局排序后打包成固定大小的区块，广播给通道内所有Peer节点，这个阶段Peer同样不会直接互通，仅通过排序节点获取新区块数据。
• 账本提交阶段：每个Peer独立接收到新区块后，逐笔校验区块内交易的背书签名是否满足策略要求、交易读写集是否和本地账本存在版本冲突（即MVCC检查），校验通过的交易才会被写入本地账本并同步更新CouchDB状态库，这个过程Peer之间不会互相确认校验结果，各自完成本地账本的更新。
• 状态同步阶段：日常在线时Peer之间仅通过Gossip协议交换区块高度的心跳信息，确认自身账本进度；如果Peer离线一段时间重新上线，会主动从通道内其他Peer拉取缺失的区块数据，补全本地账本后再恢复正常服务。

内容的提问来源于stack exchange，提问作者cherry