Hyperledger Fabric网络交易报错：read/writes result sets do not match index=1

这个错误我之前在部署Hyperledger Fabric网络时也碰到过，本质是NodeJS SDK在对比两个Peer节点的提案响应时，发现它们生成的读写集（readSet/writeSet）不一致导致的——虽然交易最终被Orderer打包上链了，但客户端这边的校验没通过。下面是我整理的几个排查方向，你可以一步步来：

1. 校验Peer节点的区块与世界状态一致性 #

• 首先检查两个Peer的区块高度是否同步：分别在两个Peer节点上执行命令

  peer channel getinfo -c <你的通道名称>
  

  对比输出的Blockchain height值，如果不一致，说明某个Peer没有同步到最新区块，大概率是Gossip配置或锚节点设置有问题。
• 如果区块高度一致，再对比同一个键的世界状态：用链码查询命令分别在两个Peer上查询同一个数据键

  peer chaincode query -C <你的通道名称> -n <链码名称> -c '{"Args":["<查询函数名>","<要查询的键>"]}'
  

  如果返回结果不同，说明其中一个Peer的链码容器或底层数据库（比如CouchDB）出现了状态不一致的问题。

2. 排查提案响应的差异细节 #

• 开启NodeJS SDK的Debug日志，设置环境变量：

  export DEBUG=fabric-sdk-node:*
  

  重新提交交易，查看日志中两个Peer返回的提案响应，重点对比readSet和writeSet的内容，找出具体哪部分不一致。常见的原因包括链码中存在非确定性逻辑（比如使用本地时间、随机数，或者依赖Peer本地文件而非账本状态）。
• 确认两个Peer上安装的链码版本完全一致：在每个Peer上执行

  peer chaincode list --installed
  

  检查链码的版本号和哈希值是否相同，如果不同，重新安装并升级链码到同一版本。

3. 检查通道配置与Gossip同步设置 #

• 验证锚节点配置是否正确：先拉取通道配置区块

  peer channel fetch config config_block.pb -o <Orderer地址:端口> -c <你的通道名称>
  

  用configtxlator解析成JSON后，检查锚节点配置是否包含两个Peer的地址，确保Gossip可以正常同步状态。
• 检查Peer的core.yaml配置：确认gossip.bootstrap指向了正确的锚节点地址，gossip.useLeaderElection和gossip.orgLeader的配置符合你的网络架构，避免出现Leader选举异常导致的同步问题。

4. 处理交易已上链但客户端报错的临时方案（不推荐长期使用） #

• 先确认交易确实已成功上链：用命令查询交易详情

  peer channel gettransactionbyid -c <你的通道名称> -t <交易ID>
  

  或者通过链码查询确认数据已更新。
• 如果确认交易没问题只是客户端校验失败，可以临时调整SDK的提交策略：比如在提交交易时，将request.targets只指定一个Peer节点，或者修改通道的背书策略，确保提案响应的一致性。但这只是权宜之计，还是要找到根本原因解决。

5. 检查底层数据库的健康状态 #

• 如果你用的是CouchDB，先检查服务是否正常运行：

  curl http://<CouchDB地址>:5984/_all_dbs
  

  确认对应的通道数据库存在且无损坏。如果CouchDB有异常，可以尝试重启服务，或者恢复数据库备份（如果有的话）。

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