Hyperledger Fabric 1.4 中不同节点的区块链之间的差异

Question

系统：Hyperledger Fabric 1.4.6

拓扑：2 个组织（Org1、Org2），每个组织有 2 个对等点（peer1、peer2）和 Raft 排序服务

背书政策：任意 2 个同行

Chaincode交互方式：通过Node.jsSDK

StateDB：CouchDB

重现问题的详细步骤：

1. Org1 通过链代码方法 stub.putState()
向所有 4 个节点发送提案以进行背书，从而成功创建记录（即 record#ABC）
2. record#ABC只是简单的一层JSON（键值对）
3. 访问Org2的peer2的CouchDB入口，直接删除记录#ABC
4. 通过链码方法从所有 4 个节点 stub.getState() 和 3 个节点 return 检索记录#ABC 相同的正确结果，只有 Org2 的节点 2 return 的空结果符合预期
5. 通过链代码方法 stub.getHistoryForKey() 从所有 4 个对等点检索记录#ABC 并且所有 return 与预期的结果相同（据我了解，此方法直接从 levelDB 而不是 CouchDB 执行查询）
6. Org1 通过链代码方法向所有 4 个节点发送提案以进行背书，从而成功更新了记录#ABC 的一个值 stub.putState()
7. 通过检查 Node.js 应用程序日志，Org2 的 peer2 return 出现了预期的 No such Data 错误。由于只需要2个背书签名，所以有望通过验证
8. 通过检查 Org2 的 peer2 的 docker 日志，块 #007 已提交，但由于 MVCC_READ_CONFLICT
，其交易被状态验证器标记为无效
9. 通过链代码方法stub.getState()从所有 4 个对等点检索记录#ABC，并且只有 Org2 的对等点 2 return 为预期的空结果
10. 通过链代码方法从所有 4 个对等点检索记录#ABC stub.getHistoryForKey() 和 3 个对等点 return 2 个版本的记录#ABC 的相同结果而 Org2 的对等点 2 returns原始版本记录#ABC 没有最新版本
11. 从所有对等方检索包含更新记录#ABC 交易的最新区块（即区块#007）。所有区块的主要内容都是一样的
12. 区块链可以继续接收创建新记录的新请求。

下面是我的问题：

1. 为什么问题块 (block#007) 仍在 Org2 的 peer2 中提交？
2. 为什么区块链系统可以在不同点的区块链之间存在差异的情况下继续运行而不会抛出严重错误？是否应该重新设计以停止操作，直到差异问题得到解决？

Answer 1

1. 持久化/提交块独立于验证交易和更新状态。只要该块是正确的序列并由正确的排序者签名，它就会被提交。 Fabric 然后使用指示每个事务有效性的元数据注释块中的每个事务。

2. 由于Org1和Org2都有对交易成功背书的peer，所以交易对未被篡改的peer有效。如果没有足够的节点来为交易背书，所有节点都会认为它是无效的。无需停止系统，因为交易已在网络信任参数的上下文中得到妥善处理。