EOS 消息设计并行处理

Posted 2021-09-17 thefist11

1. 消息的并行设计

为了最大化并行运算，同时将从程序日志中重新生成应用程序状态的计算任务降至最低，EOS将身份验证与应用程序分离

1.1 消息的验证逻辑Context free actions(signatureverification -runs parallel)

• 确认消息在内部是一致的;
• 确认所有的前置条件都是有效的;
• 修改应用程序状态。

1. 2. 只读消息处理 Read only action handlers(for asuccessful action to happen)

部分账户可能会处理一些只需要决定通过与否的消息，而不会改变自己内在状态。这种情形下，只需要有一个或多个进程包含这个特殊账户下的只读消息处理器，这些处理就能并行进行。

• 验证消息的内部一致性是只读的，不需要访问区块链状态，这意味着它可以最大化并行运算来执行。

• 验证前置条件（例如需求平衡）也是只读的，因此也可以从并行运算中获益。只有对应用程序状态进行修改才需要写访问，并且需要按顺序对每个应用程序进行处理。

• 身份验证是验证消息是否可以应用的只读过程，应用程序实际上就是在做这项工作。实时的计算都需要执行，但交易一旦被包含在区块链中，就不再需要执行身份验证操作了。

1.3. 多账户原子交易Atomic transactions with multipleaccounts

有时希望确保消息被多个帐户以原子方式交付和接受。在这种情况下，两个消息被放置在一个交易中，两个帐户将被分配相同的线程和消息按顺序执行。

• 在性能上并不理想，并且当涉及到“付费”用户的使用时，他们将会被根据交易所涉及的特殊帐户的数量来收费。最好将涉及两个或更多帐户的原子操作最小化

区块链共识取决于确定性（可重现）行为。这意味着所有并行执行都能不能使用互斥体或其他锁的原语的情况下正常运行。没有锁，必须有一些方法来保证所有帐户只能读写自己的私有数据库。这也意味着每个帐户会顺序处理其消息，并行性确定在帐户级别。

1.3. 通讯延迟 Minimizing communicationlatency(actions within a block)

并行执行还意味着当脚本生成新消息时，它不会立即发送，而是在下一个周期中发送它。无法立即发送的原因是因为接收方可能会在另一个线程中主动修改自己的状态。

使用EOS.IO软件，区块生成器的工作是将消息传递到独立的线程中，以便它们可以并行地评估。
每个帐户的状态只取决于传递给它的消息。

1.4. 调度策略 Subjective best effort scheduling (atxn. using more resources are removed)

调度表是区块生成器的输出，并且将被确定性地执行，但是生成调度的过程不必是确定性的。这意味着区块生成器可以利用并行算法来调度事务。