[区块链]EOS 消息设计（3）并行处理之状态评估

1. 部分区块链状态评估Partial evaluation of Blockchainstate(only needful)

EOS.IO系统允许任何完整的节点选择性的运行任意应用子集。传递给其他应用的消息将被安全地忽略，因为应用的状态完全来自于传递给它的消息。

• 出于将交易状态显示给用户的目的，交易应用的开发者将维护一个完整的节点。这款交易应用不需要与其他社交媒体应用关联状态。

• 对于多帐户之间的通信有一些重要的影响。最重要的是，不能假定另一个帐户的状态在同一台机器上是可访问的。它还意味着，虽然允许一个帐户同步调用另一个帐户的“锁”是一种诱人的设计模式，但如果其他帐户不在内存中，这种设计模式将会崩溃。

因此，所有帐户间的状态通信必须通过区块链上的消息进行传递。

2. 自主最优任务安排

EOS.IO系统不能强制阻止区块生成者向其他帐户发送的任何消息。这种对计算、资源成本的主观评估将使区块链不必精确地去度量运行一个任务需要多长时间。有了这个设计，就不需要精确地数指令，这将极大地增加优化的机会，而不会打破共识。

2.1 区块节点生成者

每个区块的生成者对处理交易都有自己的主观度量，无论这个交易是由用户生成的还是由脚本自动生成的。

• 计算复杂度
• 时间复杂度
• 网络层面
  EOS.IO系统处理的每一笔交易都有固定的计算带宽成本，不管它是耗费01ms还是10 ms来处理它。但是，使用该系统的每个单独的区块生成者会使用它们自己的算法和度量来衡量资源使用。当一个区块生成者发现一个交易或帐户已经消耗了大量的计算能力时，他们会在生成自己的块时拒绝该交易；但是，如果其他区块生成者认为它是有效的，他们仍然会处理该交易。

2.2 区块验证

一般来说，只要一个区块生成者认为一个交易是有效的，并且所消耗的资源是可控的，那么其他所有的区块生成者也会接受它，但可能要花费1分钟才能使该交易传播到这个区块生成者处。

在某些情况下，区块生成者可以创建一个区块，其中包括在可接受范围之外的交易。在这种情况下，下一个区块生成者可能会选择拒绝这个区块，而这条线路将会被第三个区块生成者终结。这与一个大区块导致网络传播延迟所引发的情况没有什么不同。社区会注意到这种异常模式，并最终清理该流氓区块生成者的选票。