Hyperledger Fabric如何处理＆＃34; invoke＆＃34;相同的Key-Value对链码？

Question

例如，如果请求＆＃34;调用＆＃34;几乎同时存在相同键值对的链码，会发生什么？

如果Hyperledger Fabric是噩梦，我们该如何应对呢？在Hyperledger core.yaml设置的一边？或链码设计的一面？

Answer 1

注意：第一个答案是与Fabric v0.6相关的。 Fabric v1 使用不同的机制。这些步骤（据我目前所知）：

1. 客户端将交易发送给背书人。
2. Endorsers执行事务，生成世界状态键/值更改集，称为读/写集。背书人将结果返回给客户。
3. 客户收到所有人的回复，并将结果和R / W设置与认可政策进行比较。
4. 客户将成功认可转发给订购服务，该服务从一组交易中创建块。
5. 订购服务将完整块转发给所有提交者（代言人，观察员等）。
6. 每个提交者按顺序应用事务的R / W集，随着时间的推移更新每个读取密钥的版本（显然使用散列映射）。在提交每个集合时，它会对读取集中的每个密钥版本执行检查，以使密钥版本不得小于当前版本号。

注意：这是v0.6中的主要更改，因为即使在调用的上下文中，只有读取才能看到完全提交的事务！如果存在任何密钥冲突，则交易在最后一分钟失败！不会发出链代码事件，但会在最后一个块中记录失败。世界状态变化丢失，交易必须由客户重新提交！

解决此问题的方法是将链代码设计为不为每个资产使用共享密钥，或者将客户端设计为流控制API调用（链代码事件，无论您想要调用哪个），资产水平，或两者都很可能。

因此，原始问题的答案是，事务在v0.6 Fabric上工作正常，第一个事务有效但第二个事务在Fabric v1上失败，如果两者发送得太紧（并且同时距离太近）。 / p>

显然，当没有关键冲突时，两者总是有效（假设交易通过共识并且是确定性的 - 就像在所有代言人身上创造相同的结果一样）。

Answer 2

所有调用和查询事务都是按顺序执行的（不是并发执行）。在this question中，它解释了如何执行交易。观察通过共识，所有执行都被排序，然后每个节点按照该顺序执行它们。因此，没有并发性。