摘要：最近看源碼發現跟之前理解有點出入，目前代碼實現上跟白皮書上也有所出入，該文章需要更新修正前言作為的代表，他的設計是比較超前的，也是目前最被看好的項目之一本文從傳統互聯網碼農思維，嘗試講述下的性能方面的設計本文只是涵蓋了基礎主鏈部分，暫不包括

最近看3.0源碼發現跟之前理解有點出入，目前代碼實現上跟白皮書上也有所出入，該文章需要更新修正

EOS作為blockchain 3.0的代表，他的設計是比較超前的，也是目前最被看好的項目之一
本文從傳統互聯網碼農思維，嘗試講述下EOS的性能方面的設計
本文只是涵蓋了基礎主鏈部分，暫不包括off-chain,side/sharding chain等類似技術

系列文章開篇，也歡迎大家關注我的幣乎

在理解EOS的性能之前，我們需要先回顧下EOS的數據結構和一些核心的設計，以便更好的理解

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(一個意思)，Cycle上面加了Region層

這里Block就是傳統意義上的區塊
不一樣的是EOS中每個塊生產者在自己的time slot中是批量生產多個塊的（目前為6個）

demo

Cycles的概念是EOS中引入的,Block被分割成多個cycle組成，塊生產者可以在他的當前塊中，生產多個Cycle, 也可以稱Cycle為Block中的“小鏈”

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

這樣做的好處是

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

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

demo （下圖user_input中就是trasaction，一個trasaction對應多個messages/actions）

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

OK，數據結構方面就不再展開了，下面我們進入本文的重點，
性能，一般是在指定use case，指定資源消耗，指定并發的情況下，系統的吞吐和延遲
下面我們看看EOS是如何最優化區塊鏈的性能的

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

優化數據結構（比如merkel tree branch的優化），編碼等,待整理EOS的優化點

打包效率直接影響了單位時間Block內的交易數量(或Cycle數量)
對于幾乎Non-Blocking的EOS來說，是吞吐的最直接最重要因子,為什么btc等打包效率不是最重要的？因為有太多的blocking time(共識開銷)
EOS會分多次迭代來優化打包效率

單線程優化
這里主要是處理流程、熱點函數、異步、批量、網絡、協議、執行引擎(解析->JIT)等的優化,EOS 6月主網上線時主要為該階段的優化

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

因為EOS中，需要對多租戶進行帶寬、計算、存儲、數據庫等資源的限流，而這個限流策略是針對整個鏈來說的，所以多core上運行的線程/進程一般情況下需要進行相關的原子操作及一些memory barrier

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

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

EOS在年底之前會進行多次的迭代，因為并不會改變區塊的協議，而且整個網絡可以平滑的進行升級

對多個core/thread進行context分片后，無法做到不依賴全局統計數據

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

熱點問題是任何分布式系統繞不過去的話題，比如一般關系型數據庫的熱點行事務問題，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秒了，而且還是直連的模式，事實上存在多跳傳播，這類系統，降低塊間隔到秒級會大幅增加分叉和不穩定性

塊傳輸延遲指的是區塊鏈使用的p2p網絡，在傳輸block時消耗的時間
EOS不需要等待block生產完畢，而是基于Cycle的粒度進行廣播，在生產塊的同時進行異步傳輸,所以塊生產結束到下一個節點收到塊的latency，可以降低到一個1 RTT
同時又充分平滑的利用網絡資源
如果不是生產塊和傳輸塊同時進行的模式，對于大塊，需要多個RTT才能傳輸完畢（在充分優化TCP網絡的基礎上），而且在傳輸大塊的過程中，可能會產生網絡的抖動

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

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

當然，如果某些DAPP可以接受不入塊的數據，那么可見延遲就是傳統P2P的網絡延遲了
我們這里還是指入塊的可見延遲

共識延遲在區塊鏈里是非常重要的，尤其對金融領域，這個延遲代表交易被網絡確認的時間
說到共識延遲之前，需要簡單回顧下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秒

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

共識延遲在EOS中是可預測的，而不像別的DPOS機制或POW機制，共識延遲可能會大幅抖動

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

1.5秒的共識延遲對EOS來說是個非常大的優勢,因為其他區塊鏈都是數量級上的差距(包括pos/DPOS的其他變種)

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

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

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

EOS 是 non-blocking 的區塊鏈，異步、批量、并行機制最大化整個網絡的吞吐，
就性能擴展方面，目前我沒有發現其他項目可以媲美的，如果有，那么機制應該也是差不多的

本文只是粗略的理解EOS的性能設計，詳細得看EOS源碼，個人因為業余時間不多，另外同時在研究別的項目，如出現理解錯誤，希望指正，非常感謝

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

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

所以，趕緊學習智能合約開發DAPP吧～

以上屬于個人觀點，不構成投資建議呵