重读EOS白皮书——性能|周明强有话说

zhouyagen (47)in #cn • 7 years ago (edited)

性能为王
（账户与合约是相关的，下文中提到账户是指账户下的合约）

EOS.IO的性能目标是要做到支持数百万的用户，要达到每秒百万级别的交易量（tps）。要达到这样级别的性能，除了需要硬件支持，还需要软件设计上的支持。

我们已经知道EOS.IO使用DPOS共识算法。目前使用DPOS算法的区块链有bitshares、steem、yoyow……他们的性能都还不错，能达到几千PTS甚至能达到一万PTS。像基于Steem的社交媒体平台Steemit，几乎可以媲美中心化的应用了，基本上可以说不用感知到区块链。

除了共识算法，还有权限设计，我在《重读EOS白皮书——权限》里介绍EOS.IO的权限设计。权限在一个区块里是只读的，如果用户的权限修改消息正在这个区块里执行，修改后的权限是要在下一个区块才起做用。EOS.IO把权限与具体的业务逻辑解耦，使得权限可以有更大的优化空间，也使得性能优化也有更大的空间。

想要提高性能，多线程是重要的优化点。把原本单线程执行的功能，使用多线程设计、执行可以巨大地提高系统性能。EOS.IO的白皮书里提到了多线程提升EOS.IO的性能。我们来看下EOS.IO的多线程设计。

要实现多线程执行某个功能、事务，就需要对共享资源、数据进行加锁，或使用互斥的技术实现对数据的准确修改。比如说某电商平台上有某个产品要举办秒杀活动，产品的数量是有限的，而人民群众的热情是无限的，要对共享数据——产品的数量——上锁，已避免被秒杀购买的产品数量大于实际设定的产品数量。如果没有锁，将可能导至商家出现亏损或信誉问题。

区块链共识依赖于确定的、可重复的行为（ deterministic (reproducible) behavior）。区块链是由成千上万的节点共同维互，每个节点都会把事务执行一遍，执行事务的结果必须是一致，所以叫共识。这也意味着在区块链上不能使用锁、互斥的多线程技术。如果把这些技术用到区块链上，那么会出现不同的节点的状态不一致的情况。比如上面的秒杀例子，张三在某个节点秒杀成功了，而在另一个节点却秒杀失败了。

提高性能就要用多线程技术，但却不能使用几乎和多线程伴生的锁、互斥技术。EOS.IO如何解决这个问题呢？EOS.IO的多线程是在账户层面上，每个账户的消息是顺序执行的，这就报保证了账户相关的状态的一致性，又可以使用多线程技术来提高EOS.IO的性能。

EOS.IO的合约也可以产生一条新消息，这条消息并不会立即执行，正如上面提到的，多线程并行是在账户层面上的。新生成的消息的相关账户可能正在别的线程中执行。新生成的消息会并安排到下一个cycle或block中执行。

EOS.IO使用了一种数据结构来实现这样的多线程并发执行。每一区块中包含多个Cycle,EOS.IO将会顺序执行每一个Cycle。Cycle下是Thread数据结构，对应上面说的，每一个Thread其实对应的是一个账户。Thread这个结构是可以并发执行的。每一个Thread结构里包含了一定的事务，这些事务将顺序执行。每一个事务结构是有消息集合组成。在执行过程中可能会生成新的消息，这些将会被打包到下一个Cycle或者下一个区块，这取决于区块生产者的调度。（一个事务里包含了多个消息，这个不是很理解，难到不是一个消息一个事务吗？有明白的请不吝赐教）
eos的区块结构
(eos 的区块结构)
EOS.IO的这样的区块结构，不但能实现账户层面上的并行，还可以实现最小消息延迟。这里的延迟是指从一个账户（合约）发送消息到另一个账户（合约），并接到这条消息响应的时间。执行脚本生成的消息可以被包含在下一个Cycle中执行，也就是实现了通常说的区块内部通信。