如何在最新版Fabric中通过Fabric Gateway实现多组织交易背书与权限管控

一、解决交易失败：实现多组织背书 #

你当前交易失败的核心原因是网关仅关联了Org1的身份，无法从其他符合背书策略的组织获取背书。要满足OutOf(2, ...)的规则，需要让交易获得至少两个指定组织的背书，具体实现步骤如下：

1. 扩展客户端连接，包含目标组织Peer节点 #

确保你的Fabric客户端（client对象）配置了Org1和Org2的Peer节点连接信息。可以修改连接配置文件（如connection-org1.json），添加Org2的Peer节点地址、TLS证书等内容，保证客户端能访问到Org2的背书节点。

2. 为Org2创建身份和签名者 #

复制Org1的身份生成逻辑，为Org2生成对应的身份与签名者：

async function newOrg2Identity(): Promise<Identity> {
    const org2CertPath = "/path/to/org2/cert.pem"; // 替换为Org2的证书实际路径
    const org2MspId = "Org2MSP";
    const credentials = await fs.readFile(org2CertPath);
    return { mspId: org2MspId, credentials };
}

async function newOrg2Signer(): Promise<Signer> {
    const org2KeyDir = "/path/to/org2/keys"; // 替换为Org2的私钥目录路径
    const files = await fs.readdir(org2KeyDir);
    const keyPath = path.resolve(org2KeyDir, files[0]);
    const privateKeyPem = await fs.readFile(keyPath);
    const privateKey = crypto.createPrivateKey(privateKeyPem);

    return signers.newPrivateKeySigner(privateKey);
}

3. 添加Org2身份到网关并指定背书组织 #

在网关初始化后，将Org2的身份加入网关，并在创建交易时显式指定需要背书的组织，确保交易从Org1和Org2的Peer节点收集足够背书：

async function main(): Promise<void> {
    const gateway = connect({
         client,
         identity: await newIdentity(), // 默认使用Org1身份
         signer: await newSigner(),
         // 超时配置保持不变
         evaluateOptions: () => { return { deadline: Date.now() + 5000 }; },
         endorseOptions: () => { return { deadline: Date.now() + 15000 }; },
         submitOptions: () => { return { deadline: Date.now() + 5000 }; },
         commitStatusOptions: () => { return { deadline: Date.now() + 60000 }; },
    });

    // 将Org2的身份添加到网关
    await gateway.addIdentity(await newOrg2Identity(), await newOrg2Signer());

    try {
        const expirationDate = "12-12-2022";
        // 创建交易对象并指定需要的背书组织
        const transaction = contract.createTransaction("CreateAsset");
        transaction.setEndorsingOrganizations("Org1MSP", "Org2MSP");
        const result = await transaction.submit(expirationDate);
        console.log("交易成功:", result.toString());
    } catch( error ) {
        console.error("交易失败:", error);
    } finally {
        gateway.disconnect();
    }
}

通过setEndorsingOrganizations指定组织后，网关会自动从对应组织的Peer节点收集背书，满足OutOf(2)的策略要求。

二、更优的背书组织限制方式（替代链码if判断） #

除了在链码中硬编码组织判断，更推荐使用Fabric原生机制限制背书组织，灵活性与可维护性更强：

1. 通道级背书策略（你当前使用的方式） #

通过configtx.yaml的Application Policies配置通道默认背书策略，属于全局层面的控制，适用于通道内所有链码（除非链码单独指定策略）。后续需要添加组织时，只需通过configtxlator生成通道配置更新提案并提交，无需修改链码或重新部署。

2. 链码级背书策略 #

在链码实例化或升级时，通过-P参数为特定链码单独设置背书策略，优先级高于通道默认策略。例如：

# 实例化链码时指定仅Org1和Org2可参与背书
peer chaincode instantiate -o orderer.example.com:7050 -C mychannel -n assetcc -v 1.0 -c '{"Args":["Init"]}' -P "OutOf(2, 'Org1MSP.member','Org2MSP.member')"

这种方式可以为不同链码设置差异化的背书规则，适合多链码场景。

3. 属性基访问控制（ABAC） #

如果需要更灵活的身份控制（比如允许组织内特定角色的用户背书），可以结合Fabric CA为身份颁发属性，在背书策略中通过属性定义规则。例如：

Rule: "OutOf(2, 'Org1MSP.admin', 'Org2MSP.role=endorser')"

这样只有Org1的管理员和Org2中拥有endorser属性的身份才能参与背书，比固定组织的控制更精细。

以上三种方式均无需修改链码，属于Fabric原生的策略控制机制，是限制背书组织的最优方案，避免了链码硬编码带来的维护成本。

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