【发布时间】：2018-02-01 15:43:58
【问题描述】：
我相信答案是否定的，但我想确认一下。
使用 Fabric，背书者根据最新状态模拟交易，并准备添加读取和写入密钥集的提案。 在提交阶段，peer 将收到来自排序服务的块，并且仅当读取集尚未更新时才应用写入集更新（版本控制检查）。 所以对于同一个区块，同一个区块的2个不同交易不能更新同一个key。
如果是这种情况，聚合价值和保持链上的平衡对于频繁交易的用例可能会有问题。这样的操作应该留给链下应用层。
【问题讨论】：
【发布时间】：2018-02-01 15:43:58
【问题描述】：
所以对于同一个区块，同一个key不能被同一个区块的2个不同事务更新。
以上是正确的。 Hyperledger Fabric 使用类似 MVCC 的模型来防止冲突（或“双花”）。在尝试再次更新状态之前，您需要等待上一个状态更改事务提交。
【讨论】：
-
排序服务是否注意属于同一块的 2 个事务不会更新相同的密钥（通过将 2 个事务分隔在不同的块中）？还是会抛出 MVCC_READ_CONFLICT 错误？
-
排序服务实际上并不解析/处理交易。它只是对它们进行排序和批处理（即它不查看交易的内容）。一旦对等点从排序服务接收到一个交易块，它实际上会进行验证（包括 MVCC 检查）
-
谢谢加里。然后我假设在这种情况下，我会从对等事件中得到一个 MVCC_READ_CONFLICT 错误。对吗？
-
没错。您应该会在事件中看到错误代码
-
如果有人担心这个限制在吞吐量方面的影响，如果密钥的更新值是十进制，那么这里提供了解决方法 [link]github.com/hyperledger/fabric-samples/tree/release/…，包括存储只有增量。