理解EOS的性能设计

作者：杨金宝

EOS出块时间

EOS的出块顺序

1个生产节点连续出12个块
1个生产节点内的12个块不存在接收等待问题，是0等待，肯定也不存在跳块问题。比如生产区块2时，肯定能拿到区块1的数据.

21个生产节点的出块顺序是固定的，且直连

EOS区块不可逆时间

EOS的特殊BFT

EOS的数据结构和一些核心的设计

Block

Cycles

Cycles的概念是EOS中引入的,Block被分割成多个cycle组成，块生产者可以在他的当前块中，生产多个Cycle, 也可以称Cycle为Block中的“小链”
这样做的好处是
提升了消息交互的效率，后面的Cycle可以依赖前面Cycle的数据，而不需要等完整的block（Cycle生成完会立刻异步广播出去）

使网络资源的使用更平滑，降低传输毛刺,是的块生产者的交接开销在1~2 TCP RTT,不管块有多大

Threads/Shards

引入Threads的概念，主要是为了并行执行，BlockProducer在打包Cycle的时候，可以利用多core资源进行并行打包，相关(参考trasaction的scope字段)的交易/消息调度路由到同一个Thread，由单独的core处理，Thread与Thread之间数据不共享,EOS主网刚上的时候是所有的交易由单个core进行打包

如何最大化吞吐量 - TPS

优化数据密度

优化数据结构（比如merkel tree branch的优化），编码等,待整理EOS的优化点

最大化打包效率

打包效率直接影响了单位时间Block内的交易数量(或Cycle数量)
对于几乎Non-Blocking的EOS来说，是吞吐的最直接最重要因子,为什么btc等打包效率不是最重要的？因为有太多的blocking time(共识开销)

EOS会分多次迭代来优化打包效率

单线程优化

多线程共享内存

多线程不共享内存

EOS并行化的挑战 之限流

EOS并行化的挑战 之热点

热点问题是任何分布式系统绕不过去的话题，比如一般关系型数据库的热点行事务问题，EOS中同样也存在这个问题，热点账户只能分配一个thread进行处理，从而限制了该账户相关的tps

最大化打包时间占比

打包时间就是BP真正干活的时间

打包时间*打包效率/块间隔 = 整个链的吞吐
打包时间/块间隔 = 打包时间占比 (追求最大化打包时间, 最小化块间隔)
(出块间隔 - 打包时间)/出块间隔 = blocking时间

EOS中块生产者等到快到出块间隔了才停止生产cycle(Block),几乎没有块大小限制,一个Time Slot可以出6个块,然后再交接到下一个区块，而这个交接因为异步传输和地理感知的编排，延迟会很小
所以EOS中整个链的blocking时间占比很小，几乎做到non-blocking block chain !

最小化块间隔

出块间隔当然越小越好，毕竟块的数据承载量/出块间隔就是单链的吞吐嘛
另外，出块间隔缩小可以降低交易确认时间
EOS的出块间隔是0.5秒,主要依赖如下技术
21个BP地理感知的编排出块顺序,当前BP与下一个BP的io latency小
当前BP在块处理完后可以在1 RTT传输到下一个BP
因为Cycle已经异步传输了
当前的BP不会同步依赖任何其他BP
以上可以保证当前BP和下一个BP的交接时间最小，从而保证了即使是0.5秒的间隔，系统一样会比较稳定
而其他pow/dpos+随机投票/pbft,下一个节点的随机属性，和块本身可能需要多个RTT传输，就算没有其他共识开销，也做不到0.5秒的间隔，大家可以估算下中美延迟*2RTT,光是网络开销就0.5秒了，而且还是直连的模式，事实上存在多跳传播，这类系统，块间隔到秒级会大幅增加分叉和不稳定性。
备注：RTT(Round-Trip Time): 往返时延，在计算机网络中它也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延;

如何最小化延迟

块传输延迟 I/O Latency
块传输延迟指的是区块链使用的p2p网络，在传输block时消耗的时间
EOS不需要等待block生产完毕，而是基于Cycle的粒度进行广播，在生产块的同时进行异步传输,所以块生产结束到下一个节点收到块的latency，可以降低到一个1 RTT
同时又充分平滑的利用网络资源
如果不是生产块和传输块同时进行的模式，对于大块，需要多个RTT才能传输完毕（在充分优化TCP网络的基础上），而且在传输大块的过程中，可能会产生网络的抖动

可见延迟 Visibility Latency

可见延迟表示用户A发起一笔交易，用户B最短什么时间在区块中可见
这个延迟在一般的区块链系统中，就是等待打包+打包时间（块生成完)+广播的IO延迟
EOS中，可见延迟 = 打包时间(入Cycle,无需等block完毕)+广播的IO延迟
这里可能有些同学会问，为啥EOS的可见延迟没有等待打包这一说?
上面的章节（见最大化块生产时间）我们已经描述了EOS的BlockProducer其实是一直在打包(生成Cycle)中的，交易可以几乎无需等待，打包入当前BlockProducer中的当前Cycle中，并在Cycle处理完毕就广播出去
当然，如果某些DAPP可以接受不入块的数据，那么可见延迟就是传统P2P的网络延迟了
我们这里还是指入块的可见延迟
共识延迟 Consensus Latency
共识延迟在区块链里是非常重要的，尤其对金融领域，这个延迟代表交易被网络确认的时间
说到共识延迟之前，需要简单回顾下EOS中的DPOS+BFT的共识算法
每一轮(主节点遍历一遍代表一轮,EOS中为63秒)选出21个主节点（BlockProducer）和100个备份节点
// 当前轮的投票结果是取的上上轮的最后一个区块的结果
基于IO延迟感知，编排出块顺序(每个节点分配有自己的出块时间片)
// 这个可以保证相邻出块节点间的io latency降低到最小
// 因为需要2/3的主节点确认，所以这种伪随机编排并没有带来安全影响
主节点根据自己的time slot进行打包出块
其他主节点收到块后进行投票,这个过程是异步并行的
投票结果会写入到后面的区块中，当2/3个主节点通过通过后，就代表区块不可逆
不可逆表示节点无法忽略不可逆的区块而从之前的位置分叉,也就可以保证后面所有的分叉都可以看到该区块

完全不可逆

在上面的过程中，每个块都会由21个BlockProducer异步并行的进行BFT投票，大约1.5秒后，就可以被大于2/3个BlockProducer确认，也就是共识延迟为1.5秒

99%不可逆

EOS中官方给的平均99.9%不可逆是0.25秒
共识延迟在EOS中是可预测的，而不像别的DPOS机制或POW机制，共识延迟可能会大幅抖动
尤其是POW，首先他的共识延迟也不能叫共识,比如比特币，只需要6个矿工确认，6个矿工的确认时间是相对不稳定的，而且6个矿工可能有些来自于同一个矿池，所以并不是共识,而是暂时(几乎)不可逆而已
1.5秒的共识延迟对EOS来说是个非常大的优势,因为其他区块链都是数量级上的差距(包括pos/DPOS的其他变种)

长尾延迟 Trail/Peak Latency

长尾延迟是指可见延迟/共识延迟的毛刺
大家可能都遇到过长时间打包中甚至超时的转账交易
EOS中长尾延迟主要在入块（Cycle）阶段,比如你发的交易超过了你对于的资源占比
EOS中，因为是多账户资源隔离的，所以Peak Latency只会受自己的影响，而不会影响其他用户,另外，这种长尾延迟是可预期的
其实可预期延迟对于区块链来说也非常重要，我们这里怼一下大姨太
ETH中，可以用稍高的gas来阻塞其他用户正常的请求，这对其他用户来说，就是不可预期的延迟，有时入块很快，有时又超时，虽然一些客户端会提示gas设置，但是没有解决这个问题

总结

EOS 是 non-blocking 的区块链，异步、批量、并行机制最大化整个网络的吞吐，
就性能扩展方面，目前我没有发现其他项目可以媲美的，如果有，那么机制应该也是差不多的!