Hyperledger Fabric结合CouchDB部署时数据修改相关问题咨询

现象1：单节点peer查询返回篡改后数据的原因 #

peer chaincode query命令默认仅向单个指定peer节点发起查询请求，不会做多节点结果校验。你直接修改的是该peer节点对应的本地CouchDB世界状态副本，查询单个节点自然会返回篡改后的值，这仅代表该节点本地数据被篡改，不等于整个网络的账本数据被修改，也不绕过共识机制——共识是针对交易上链的流程，单节点本地副本的篡改不会同步到其他节点，也无法被整个网络承认。

现象2：Go SDK调用报错的原因 #

你使用的Fabric Gateway SDK的EvaluateTransaction接口，默认会根据链码的背书策略，自动向多个符合要求的背书节点同时发起查询请求，并校验所有节点返回的结果一致性。你仅修改了单个节点的CouchDB数据，其他未被篡改的节点返回的是正确的原始数据，多个节点返回的结果不一致，就会触发ENDORSEMENT_MISMATCH错误。
就算你篡改了所有节点的世界状态，Fabric还有不可篡改的区块账本存储，所有世界状态的变更都可以通过区块中的交易读写集校验溯源，篡改很容易被发现。

• 严格管控CouchDB的网络访问权限：仅允许对应peer节点的IP访问CouchDB端口，不对外暴露公网访问，关闭CouchDB的公开管理界面，开启CouchDB的强身份认证，禁用默认无密码配置。
• 加固peer节点运行环境：操作系统层面配置严格的访问控制，仅授权运维人员登录节点服务器，禁止无关人员操作CouchDB或peer进程。
• 定期做数据一致性校验：定期比对peer节点的世界状态和区块账本的执行结果，一旦发现不一致即可判定数据被篡改，触发告警和数据恢复流程。

• 避免使用单节点查询：调用SDK查询时，不要仅请求单个节点，使用Gateway API的默认校验逻辑，要求多个背书节点返回一致结果后再采信数据，只要多个独立节点返回相同结果，即可证明数据未被篡改且经过共识。
• 搭配历史数据校验：对于关键数据，可以调用链码的历史查询接口（如GetHistoryForKey）获取该数据的所有变更记录，核对所有变更都来自已上链的合法交易，不存在异常修改。
• 必要时校验区块证据：对于极高安全要求的场景，可以在查询到数据后，请求对应交易的区块头和读写集，验证交易确实经过排序共识、存在于合法区块中，且读写集和查询结果一致。

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