摘要：最近看源碼發(fā)現(xiàn)跟之前理解有點(diǎn)出入，目前代碼實(shí)現(xiàn)上跟白皮書上也有所出入，該文章需要更新修正前言作為的代表，他的設(shè)計(jì)是比較超前的，也是目前最被看好的項(xiàng)目之一本文從傳統(tǒng)互聯(lián)網(wǎng)碼農(nóng)思維，嘗試講述下的性能方面的設(shè)計(jì)本文只是涵蓋了基礎(chǔ)主鏈部分，暫不包括

最近看3.0源碼發(fā)現(xiàn)跟之前理解有點(diǎn)出入，目前代碼實(shí)現(xiàn)上跟白皮書上也有所出入，該文章需要更新修正

EOS作為blockchain 3.0的代表，他的設(shè)計(jì)是比較超前的，也是目前最被看好的項(xiàng)目之一
本文從傳統(tǒng)互聯(lián)網(wǎng)碼農(nóng)思維，嘗試講述下EOS的性能方面的設(shè)計(jì)
本文只是涵蓋了基礎(chǔ)主鏈部分，暫不包括off-chain,side/sharding chain等類似技術(shù)

系列文章開篇，也歡迎大家關(guān)注我的幣乎

在理解EOS的性能之前，我們需要先回顧下EOS的數(shù)據(jù)結(jié)構(gòu)和一些核心的設(shè)計(jì)，以便更好的理解

Block

?  Cycles (sequential)

?    Threads/Shards (parallel)

?       Transactions (sequential)

?           Messages (sequential)

?               Receiver and Notified Accounts (parallel)

EOS中 Cycles和Thread的概念是比較新穎的
下面我們重要看下Block,Cycle和Thread,其他概念可以參考EOS白皮書

今天看到EOS的白皮書更新了，把Threads名稱改成了Shards(一個(gè)意思)，Cycle上面加了Region層

這里Block就是傳統(tǒng)意義上的區(qū)塊
不一樣的是EOS中每個(gè)塊生產(chǎn)者在自己的time slot中是批量生產(chǎn)多個(gè)塊的（目前為6個(gè)）

demo

Cycles的概念是EOS中引入的,Block被分割成多個(gè)cycle組成，塊生產(chǎn)者可以在他的當(dāng)前塊中，生產(chǎn)多個(gè)Cycle, 也可以稱Cycle為Block中的“小鏈”

懶人畫圖： Block[Cycle,Cycle,Cycle...] <--- Block[Cycle, Cycle,Cycle...]

這樣做的好處是

提升了消息交互的效率，后面的Cycle可以依賴前面Cycle的數(shù)據(jù)，而不需要等完整的block（Cycle生成完會立刻異步廣播出去）

使網(wǎng)絡(luò)資源的使用更平滑，降低傳輸毛刺,是的塊生產(chǎn)者的交接開銷在1~2 TCP RTT,不管塊有多大

demo （下圖user_input中就是trasaction，一個(gè)trasaction對應(yīng)多個(gè)messages/actions）

引入Threads的概念，主要是為了并行執(zhí)行，BlockProducer在打包Cycle的時(shí)候，可以利用多core資源進(jìn)行并行打包，相關(guān)(參考trasaction的scope字段)的交易/消息調(diào)度路由到同一個(gè)Thread，由多帶帶的core處理，Thread與Thread之間數(shù)據(jù)不共享,EOS主網(wǎng)剛上的時(shí)候是所有的交易由單個(gè)core進(jìn)行打包

OK，數(shù)據(jù)結(jié)構(gòu)方面就不再展開了，下面我們進(jìn)入本文的重點(diǎn)，
性能，一般是在指定use case，指定資源消耗，指定并發(fā)的情況下，系統(tǒng)的吞吐和延遲
下面我們看看EOS是如何最優(yōu)化區(qū)塊鏈的性能的

有了上面的概念，我們開始講講影響區(qū)塊鏈吞吐的一些因子，以及EOS是如何優(yōu)化這些因子的

優(yōu)化數(shù)據(jù)結(jié)構(gòu)（比如merkel tree branch的優(yōu)化），編碼等,待整理EOS的優(yōu)化點(diǎn)

打包效率直接影響了單位時(shí)間Block內(nèi)的交易數(shù)量(或Cycle數(shù)量)
對于幾乎Non-Blocking的EOS來說，是吞吐的最直接最重要因子,為什么btc等打包效率不是最重要的？因?yàn)橛刑嗟腷locking time(共識開銷)
EOS會分多次迭代來優(yōu)化打包效率

單線程優(yōu)化
這里主要是處理流程、熱點(diǎn)函數(shù)、異步、批量、網(wǎng)絡(luò)、協(xié)議、執(zhí)行引擎(解析->JIT)等的優(yōu)化,EOS 6月主網(wǎng)上線時(shí)主要為該階段的優(yōu)化

多線程共享內(nèi)存
初步提升打包并行度，利用多core的資源提升吞吐，估計(jì)做到N/2倍的單線程性能,N為core的數(shù)量

因?yàn)镋OS中，需要對多租戶進(jìn)行帶寬、計(jì)算、存儲、數(shù)據(jù)庫等資源的限流，而這個(gè)限流策略是針對整個(gè)鏈來說的，所以多core上運(yùn)行的線程/進(jìn)程一般情況下需要進(jìn)行相關(guān)的原子操作及一些memory barrier

多線程不共享內(nèi)存
多core并行處理沒有資源競爭（沒有cas沒有memory barrier），這種是最理想的情況了，把之前多core需要共享的context，進(jìn)行分片,每個(gè)core/Thread都使用自己獨(dú)有的context,共享數(shù)據(jù)進(jìn)行多core分片后，性能都會比不分片要好的多

目前eos中，mongodb用來存儲block/trasaction,主要用于查詢(如eostracker)
chainbase 支持無限undo的高性能內(nèi)存數(shù)據(jù)庫，存儲合約狀態(tài)數(shù)據(jù)等
ipfs  存儲文件，其中chainbase內(nèi)存數(shù)據(jù)庫是重點(diǎn)，目前多core并發(fā)write貌似會加mutex鎖？

EOS在年底之前會進(jìn)行多次的迭代，因?yàn)椴⒉粫淖儏^(qū)塊的協(xié)議，而且整個(gè)網(wǎng)絡(luò)可以平滑的進(jìn)行升級

對多個(gè)core/thread進(jìn)行context分片后，無法做到不依賴全局統(tǒng)計(jì)數(shù)據(jù)

在并行計(jì)算的時(shí)候?yàn)榱诵阅?不會實(shí)時(shí)全局統(tǒng)計(jì)，必須要以一種相對大粒度的方式來更新統(tǒng)計(jì)數(shù)據(jù)，如Block粒度或Cycle粒度，事實(shí)上EOS中是以Cycle維度，交易先打包，Cycle處理完發(fā)送前進(jìn)行l(wèi)imit統(tǒng)計(jì)校驗(yàn),如果有賬戶超過了限制，通過修正的方式（類似于branch miss-prediction）,來UNDO這些交易,分支預(yù)測失敗是會明顯損失性能的,如何抵御此類攻擊?

熱點(diǎn)問題是任何分布式系統(tǒng)繞不過去的話題，比如一般關(guān)系型數(shù)據(jù)庫的熱點(diǎn)行事務(wù)問題，EOS中同樣也存在這個(gè)問題，熱點(diǎn)賬戶只能分配一個(gè)thread進(jìn)行處理，從而限制了該賬戶相關(guān)的tps

打包時(shí)間就是BP真正干活的時(shí)間

    打包時(shí)間*打包效率/塊間隔 = 整個(gè)鏈的吞吐
    打包時(shí)間/塊間隔 = 打包時(shí)間占比
    (塊間隔 - 打包時(shí)間)/出塊間隔 = blocking時(shí)間

EOS中塊生產(chǎn)者等到快到出塊間隔了才停止生產(chǎn)cycle(Block),幾乎沒有塊大小限制,一個(gè)Time Slot可以出6個(gè)塊,然后再交接到下一個(gè)區(qū)塊，而這個(gè)交接因?yàn)楫惒絺鬏敽偷乩砀兄木幣牛舆t會很小
所以EOS中整個(gè)鏈的blocking時(shí)間占比很小，幾乎做到non-blocking block chain !

出塊間隔當(dāng)然越小越好，畢竟塊的數(shù)據(jù)承載量/出塊間隔就是單鏈的吞吐嘛
另外，出塊間隔縮小可以降低交易確認(rèn)時(shí)間
EOS的出塊間隔是0.5秒,主要依賴如下技術(shù)

21個(gè)BP地理感知的編排出塊順序,當(dāng)前BP與下一個(gè)BP的io latency小

當(dāng)前BP在塊處理完后可以在1 RTT傳輸?shù)较乱粋€(gè)BP
因?yàn)镃ycle已經(jīng)異步傳輸了

當(dāng)前的BP不會同步依賴任何其他BP

以上可以保證當(dāng)前BP和下一個(gè)BP的交接時(shí)間最小，從而保證了即使是0.5秒的間隔，系統(tǒng)一樣會比較穩(wěn)定
而其他pow/dpos+隨機(jī)投票/pbft,下一個(gè)節(jié)點(diǎn)的隨機(jī)屬性，和塊本身可能需要多個(gè)RTT傳輸，就算沒有其他共識開銷，也做不到0.5秒的間隔，大家可以估算下中美延遲*2RTT,光是網(wǎng)絡(luò)開銷就0.5秒了，而且還是直連的模式，事實(shí)上存在多跳傳播，這類系統(tǒng)，降低塊間隔到秒級會大幅增加分叉和不穩(wěn)定性

塊傳輸延遲指的是區(qū)塊鏈?zhǔn)褂玫膒2p網(wǎng)絡(luò)，在傳輸block時(shí)消耗的時(shí)間
EOS不需要等待block生產(chǎn)完畢，而是基于Cycle的粒度進(jìn)行廣播，在生產(chǎn)塊的同時(shí)進(jìn)行異步傳輸,所以塊生產(chǎn)結(jié)束到下一個(gè)節(jié)點(diǎn)收到塊的latency，可以降低到一個(gè)1 RTT
同時(shí)又充分平滑的利用網(wǎng)絡(luò)資源
如果不是生產(chǎn)塊和傳輸塊同時(shí)進(jìn)行的模式，對于大塊，需要多個(gè)RTT才能傳輸完畢（在充分優(yōu)化TCP網(wǎng)絡(luò)的基礎(chǔ)上），而且在傳輸大塊的過程中，可能會產(chǎn)生網(wǎng)絡(luò)的抖動(dòng)

可見延遲表示用戶A發(fā)起一筆交易，用戶B最短什么時(shí)間在區(qū)塊中可見
這個(gè)延遲在一般的區(qū)塊鏈系統(tǒng)中，就是等待打包+打包時(shí)間（塊生成完)+廣播的IO延遲
EOS中，可見延遲 = 打包時(shí)間(入Cycle,無需等block完畢)+廣播的IO延遲

這里可能有些同學(xué)會問，為啥EOS的可見延遲沒有等待打包這一說?
上面的章節(jié)（見最大化塊生產(chǎn)時(shí)間）我們已經(jīng)描述了EOS的BlockProducer其實(shí)是一直在打包(生成Cycle)中的，交易可以幾乎無需等待打包入當(dāng)前BlockProducer中的當(dāng)前Cycle中，并在Cycle處理完畢就廣播出去

當(dāng)然，如果某些DAPP可以接受不入塊的數(shù)據(jù)，那么可見延遲就是傳統(tǒng)P2P的網(wǎng)絡(luò)延遲了
我們這里還是指入塊的可見延遲

共識延遲在區(qū)塊鏈里是非常重要的，尤其對金融領(lǐng)域，這個(gè)延遲代表交易被網(wǎng)絡(luò)確認(rèn)的時(shí)間
說到共識延遲之前，需要簡單回顧下EOS中的DPOS+BFT的共識算法

每一輪(主節(jié)點(diǎn)遍歷一遍代表一輪,EOS中為63秒)選出21個(gè)主節(jié)點(diǎn)（BlockProducer）和100個(gè)備份節(jié)點(diǎn)
// 當(dāng)前輪的投票結(jié)果是取的上上輪的最后一個(gè)區(qū)塊的結(jié)果

基于IO延遲感知，編排出塊順序(每個(gè)節(jié)點(diǎn)分配有自己的出塊時(shí)間片)
// 這個(gè)可以保證相鄰出塊節(jié)點(diǎn)間的io latency降低到最小
// 因?yàn)樾枰?/3的主節(jié)點(diǎn)確認(rèn)，所以這種偽隨機(jī)編排并沒有帶來安全影響

主節(jié)點(diǎn)根據(jù)自己的time slot進(jìn)行打包出塊

其他主節(jié)點(diǎn)收到塊后進(jìn)行投票,這個(gè)過程是異步并行的

投票結(jié)果會寫入到后面的區(qū)塊中，當(dāng)2/3個(gè)主節(jié)點(diǎn)通過通過后，就代表區(qū)塊不可逆
不可逆表示節(jié)點(diǎn)無法忽略不可逆的區(qū)塊而從之前的位置分叉,也就可以保證后面所有的分叉都可以看到該區(qū)塊

在上面的過程中，每個(gè)塊都會由21個(gè)BlockProducer異步并行的進(jìn)行BFT投票，大約1.5秒后，就可以被大于2/3個(gè)BlockProducer確認(rèn)，也就是共識延遲為1.5秒

EOS中官方給的平均99.9%不可逆是0.25秒

共識延遲在EOS中是可預(yù)測的，而不像別的DPOS機(jī)制或POW機(jī)制，共識延遲可能會大幅抖動(dòng)

尤其是POW，首先他的共識延遲也不能叫共識,比如比特幣，只需要6個(gè)礦工確認(rèn)，6個(gè)礦工的確認(rèn)時(shí)間是相對不穩(wěn)定的，而且6個(gè)礦工可能有些來自于同一個(gè)礦池，所以并不是共識,而是暫時(shí)(幾乎)不可逆而已

1.5秒的共識延遲對EOS來說是個(gè)非常大的優(yōu)勢,因?yàn)槠渌麉^(qū)塊鏈都是數(shù)量級上的差距(包括pos/DPOS的其他變種)

我之前看到過一篇Tendermint跟EOS的對比文章，這篇國內(nèi)也有人翻譯了，里面描述的eos的出塊等數(shù)據(jù)應(yīng)該是有問題的
EOS的數(shù)據(jù)，我們以BM的為準(zhǔn)，具體可以參考peer-review-of-cardano-s-ouroboros

長尾延遲是指可見延遲/共識延遲的毛刺
大家可能都遇到過長時(shí)間打包中甚至超時(shí)的轉(zhuǎn)賬交易
EOS中長尾延遲主要在入塊（Cycle）階段,比如你發(fā)的交易超過了你對于的資源占比
EOS中，因?yàn)槭嵌噘~戶資源隔離的，所以Peak Latency只會受自己的影響，而不會影響其他用戶,另外，這種長尾延遲是可預(yù)期的

其實(shí)可預(yù)期延遲對于區(qū)塊鏈來說也非常重要，我們這里懟一下大姨太
ETH中，可以用稍高的gas來阻塞其他用戶正常的請求，這對其他用戶來說，就是不可預(yù)期的延遲，有時(shí)入塊很快，有時(shí)又超時(shí)，雖然一些客戶端會提示gas設(shè)置，但是沒有解決這個(gè)問題

EOS 是 non-blocking 的區(qū)塊鏈，異步、批量、并行機(jī)制最大化整個(gè)網(wǎng)絡(luò)的吞吐，
就性能擴(kuò)展方面，目前我沒有發(fā)現(xiàn)其他項(xiàng)目可以媲美的，如果有，那么機(jī)制應(yīng)該也是差不多的

本文只是粗略的理解EOS的性能設(shè)計(jì)，詳細(xì)得看EOS源碼，個(gè)人因?yàn)闃I(yè)余時(shí)間不多，另外同時(shí)在研究別的項(xiàng)目，如出現(xiàn)理解錯(cuò)誤，希望指正，非常感謝

我覺得可以
EOS在打包速度上有著非常明顯的提升空間，在網(wǎng)絡(luò)和帶寬不是瓶頸下，打包速度翻一倍，吞吐基本就翻一倍（因?yàn)榇虬鼤r(shí)間/總時(shí)間接近1:1)
目前基于解釋器執(zhí)行的單線程版本已經(jīng)可以做到QPS 1000，那么按預(yù)期，年底實(shí)現(xiàn)JIT執(zhí)行多core并行不共享內(nèi)存的版本,在128 CORE的機(jī)器下，不會偏離百萬QPS太遠(yuǎn)
而這個(gè)性能迭代更新，不會影響整體協(xié)議部分，整個(gè)網(wǎng)絡(luò)可以無感平滑升級

我覺得會
未來兩年一半的初創(chuàng)公司會基于高性能區(qū)塊鏈來開發(fā)，就好比現(xiàn)在基于云計(jì)算一樣，前者不光是硬件成本，人力成本，運(yùn)維成本，更低一籌
另外，區(qū)塊鏈可以簡化系統(tǒng)復(fù)雜度，為什么呢，舉個(gè)例子，一般的局域網(wǎng)分布式系統(tǒng)中，需要避免腦裂，也就是同時(shí)多個(gè)master，這會帶來嚴(yán)重的問題，需要專業(yè)的運(yùn)維恢復(fù)所以對于強(qiáng)一致的系統(tǒng)，會犧牲可用性來保證同時(shí)只出現(xiàn)一個(gè)master, 區(qū)塊鏈中，設(shè)計(jì)上就考慮了腦裂問題，也就是分叉問題，可以自動(dòng)從分叉中修復(fù)過來而且，交易不會丟失不會報(bào)錯(cuò)，只會影響延遲，交易的處理都是異步的而一些基于同步調(diào)用模型的db(對于大多數(shù)關(guān)系型數(shù)據(jù)庫，都是這類)來說，master掛了等于當(dāng)時(shí)的交易全部失敗，這需要依賴其他的機(jī)制來重試等

所以，趕緊學(xué)習(xí)智能合約開發(fā)DAPP吧～

以上屬于個(gè)人觀點(diǎn)，不構(gòu)成投資建議呵