哪些因素会影响 HLF 1.4.4 中块中事务的顺序？

Question

在documentation的超级账本结构交易流程中提到

“排序服务不需要检查交易的全部内容来执行它的操作，它只是从网络中的所有通道接收交易，按通道按时间顺序排列它们，并创建交易块每个频道。”

我有几个问题

1. “按时间顺序排列”是什么意思？这是否意味着通道的交易是根据在 Ordering 服务节点（Leader）收到的时间进行排序的？

2. 如果两个客户端应用程序几乎同时为分类帐上的同一密钥提交更新交易[让我们称它们为 tx1（将密钥 x 更新为值 p），tx2（将密钥 x 更新为值 q）]，所有背书节点都会模拟更新交易提议，并在交易提议响应中返回写入集。当客户端将这些背书提议请求发送到排序服务节点时，这些更新交易将按什么顺序排列在一个区块中？

区块中交易的顺序可以是 tx1,tx2 OR tx2,tx1 ，假设更新交易只有写集，没有读集，任一顺序的交易都是有效的。账本 [p 或 q] 上的密钥的最终值是多少？

我试图了解 x 的最终值是否是确定性的，以及哪些因素会影响它。

Answer 1

“按时间顺序排列”是什么意思？是不是说一个通道的交易是根据Ordering服务节点（Leader）接收到的时间来排序的？

一般来说，orderer 不保证消息传递的顺序，只是保证消息将以相同的顺序传递到所有对等节点。

在实践中，以下一般适用于当前的排序器实现：

Solo - 消息应按接收顺序传递

Kafka - 消息应该按照每个排序节点接收它们的顺序传递，通常甚至按照它们在多个排序节点中接收的顺序传递。

这也适用于最新的面料版本。

如果两个客户端应用程序几乎同时为分类帐上的同一密钥提交更新交易[让我们称它们为 tx1（将密钥 x 更新为值 p），tx2（将密钥 x 更新为值 q）]，所有背书节点都会模拟更新交易提议，并在交易提议响应中返回写入集。当客户端将这些背书提议请求发送到排序服务节点时，这些更新交易在一个区块中的排序顺序是什么？

当您提交事务时，对等方会生成一个读写集。然后在将事务提交到分类帐时使用此读/写集。它包含要读取/写入的变量的名称及其读取时的版本。如果在集合创建和提交之间，提交了不同的事务并更改了变量的版本，则原始事务将在提交期间被拒绝，因为读取时的版本不是当前版本。

要解决这个问题，您必须创建数据和事务结构以避免同时编辑相同的键，否则您可能会收到MVCC_READ_CONFLICT 错误。