EOS的性能分析
理解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 的区块链,异步、批量、并行机制最大化整个网络的吞吐,
就性能扩展方面,目前我没有发现其他项目可以媲美的,如果有,那么机制应该也是差不多的!
Congratulations @billyang! You received a personal award!
You can view your badges on your Steem Board and compare to others on the Steem Ranking
Vote for @Steemitboard as a witness to get one more award and increased upvotes!