Hyperledger Fabric中如何阻止Org2通过CH1链码修改Org1创建的状态？

咱们先明确Hyperledger Fabric的核心规则：只有满足预设背书策略的交易，才会被账本接受并更新状态。你设置的背书策略是AND(Org1.member,Org2.member)，理论上Org2单独发起的交易（仅拿到自己的背书）应该会在提交阶段被验证节点拒绝，不会影响Org1创建的状态。如果现在出现了Org2能单独修改状态的情况，大概率是背书策略没正确生效，或者交易流程有问题，下面是具体的解决步骤：

1. 确认链码背书策略已正确应用到通道实例 #

链码的背书策略是在通道实例化/升级时设置的，和链码安装操作无关。如果实例化时没指定正确的策略，会使用默认规则（比如任意一个组织的背书即可生效），这就会导致Org2单独的交易能通过验证。

你可以重新升级链码并明确指定背书策略，命令示例如下（注意替换成你的网络参数）：

peer chaincode upgrade -o orderer.example.com:7050 -C mychannel -n CH1 -v 1.1 -c '{"Args":[]}' -P "AND('Org1MSP.member','Org2MSP.member')"

这里要注意：Org1MSP和Org2MSP是你网络中两个组织的MSP名称，必须和配置文件里的一致，别写错大小写或名称。

2. 验证交易的背书收集流程是否合规 #

客户端发起交易时，必须同时向Org1和Org2的peer节点请求背书，收集到两个组织的签名后才能提交给排序节点。如果你的客户端只向Org2的peer发送背书请求，那这个交易的背书集合不满足策略，提交后会被peer节点的验证环节拒绝，不会写入账本。

你可以查看Org2 peer节点的日志，如果交易不符合背书策略，日志里会出现类似Endorsement policy check failed的错误提示，这就说明验证机制在正常工作。

3. 补充链码层面的访问控制（可选） #

如果想在链码逻辑里再加一层防护，限制只有Org1的用户能发起交易，可以用Fabric的基于属性的访问控制（ABAC）。在链码中添加调用者身份校验逻辑，示例如下（以Go语言链码为例）：

import (
    "fmt"
    "encoding/json"
    "github.com/hyperledger/fabric-contract-api-go/contractapi"
)

type SmartContract struct {
    contractapi.Contract
}

func (s *SmartContract) CreateAsset(ctx contractapi.TransactionContextInterface, assetID string, value string) error {
    // 获取调用者的MSP ID
    callerMSP, err := ctx.GetClientIdentity().GetMSPID()
    if err != nil {
        return fmt.Errorf("failed to get caller MSP ID: %v", err)
    }

    // 只允许Org1的用户发起该交易
    if callerMSP != "Org1MSP" {
        return fmt.Errorf("only members of Org1 can initiate this transaction")
    }

    // 后续业务逻辑
    asset := map[string]string{
        "ID":    assetID,
        "Value": value,
    }
    assetJSON, err := json.Marshal(asset)
    if err != nil {
        return err
    }

    return ctx.GetStub().PutState(assetID, assetJSON)
}

这样即使Org2的peer安装了链码，调用这类交易时也会被链码本身直接拒绝。

4. 检查通道配置权限（兜底排查） #

确认Org2在通道配置中没有被赋予修改链码策略的过高权限。不过一般来说，链码的背书策略是实例化时固定的，后续需要升级链码才能修改，只要你严格控制链码升级的权限（比如只有Org1能发起升级），就不会出现策略被篡改的情况。

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