區塊鏈的速度困境：「貴」在信任，「慢」得其所

（本文原創做者：張開翔-FISCO BCOS首席架構師 ）

區塊鏈領域最受關注的一個方面是「性能」，或者說「TPS」，比起來有種「不服就跑個分」的感受。跑分項包括TPS（每秒處理交易數）、併發能力（同時承擔交易量）、交易響應時間等。然而，相比每秒能發送200萬封電子郵件、支持數百萬用戶同時登陸一個社交平臺的互聯網服務來講，區塊鏈的速度簡直是太！慢！了！ 甚至有人調侃說「區塊鏈，不就是最慢的分佈式數據庫嗎」（這句話能夠展開多方面解析，本篇先討論慢的問題）

區塊鏈技術前景無限美好，可若是沒有高性能表現做爲支撐，沒法運行快速的、執行復雜的智能合約邏輯，快速的完成交易事務，那些使人振奮的前景就只能是摘不到的鏡中花，撈不着的水中月。

 

#舉個例子

數錢，好比數一個億（是否是好刺激~）

一、若是一我的數，慢，但好在專一，盡心盡力，在可見的時間內能夠數完。這叫單線程密集計算。

二、若是N我的一塊兒數，每人平分，分頭同時數，最後彙總總數，所用時間基本上是第一種狀況的1/N，參與的人越多，所需時間就越少，TPS就越高。這叫並行計算和MapReduce。

三、若是N我的一塊兒數，但因爲這N我的互相不信任，得彼此盯着，首先抽籤選一我的，這我的撿出一疊錢（好比一萬塊一疊）數一遍，打上封條，簽名蓋章，而後給另外幾我的一塊兒同時從新數一遍，數好的人都簽名蓋章，這疊錢纔算點好了。而後再抽籤換我的檢出下一疊來數，如此循環。由於一我的數錢時別人只是盯着，並且一我的數完且打上封條和簽名的一疊錢，其餘人要重複數一遍再簽名確認，那麼可想而知，這種方式確定是最慢的。這就叫區塊鏈。

但換個角度，方式1，一我的數有可能會數錯，這我的有可能生病或休假，致使沒有人幹活，更壞的結果是，這我的可能調換假幣或者私藏一部分錢，報一個錯的總數。

方式2，N我的中會有必定比例數錯，也可能其中一我的休假或者怠工，致使最終結果出不來，更可能由於人多手雜，出現部分人偷錢、換假錢、報假數……

方式3，很慢，可是很安全，由於全部人都會盯着全過程進行驗算，因此確定不會數錯。若是其中有人掉線，能夠換人撿出新的一疊錢繼續數，工做不會中斷。全部數過的錢上面都有封條和簽名，不會被作手腳，萬一出錯了也能夠找到責任人進行追責。這種狀況下，資金安全是徹底獲得保障的，除非全部的參與者都串通一氣了。該模式下，參與的人越多，資金安全性就越高。

因此，區塊鏈方案致力追求的是，在缺少互相信任的分佈式網絡環境下，實現交易的安全性、公允性，達成數據的高度一致性，防篡改、防做惡、可追溯，付出的代價之一就是性能。

最著名的比特幣網絡，平均每秒只能處理5~7筆交易，10分鐘出1個塊，達到交易的最終肯定性須要6個塊也就是1個小時，且出塊過程至關損耗算力（POW挖礦）。

號稱「全球計算機」的以太坊，每秒能處理的交易數也僅是2位數的量級，十幾秒出1個塊。以太坊目前也是採用損耗算力的共識機制POW挖礦，會逐步遷移到POS共識機制。

這兩個網絡在粉絲們爆炸性地進行交易時，可能會陷入擁堵狀態，大量的交易發出後，一兩天甚至更長的時間纔會被打包確認。

但在資金安全就是命的場景下，有些事情是「必須」的，因此，即便慢，仍是會考慮選擇區塊鏈。

 

#區塊鏈爲何慢

分佈式系統裏有一個著名的理論叫CAP理論：2000年，Eric Brewer教授提出一個猜測：一致性、可用性和分區容錯性三者，沒法在分佈式系統中被同時知足，而且最多隻能知足其中兩個。

CAP的大體解釋

Consistency(一致性) ：數據一致更新，全部數據變更都是同步的

Availability(可用性)：好的響應性能

Partition tolerance(分區容錯性)： 可靠性

 這個理論雖然有一些爭議，但從工程實踐中看，和光速理論同樣，能夠無限逼近極致可是難以突破。

區塊鏈系統能把一致性和可靠性作到極致，可是「好的響應性能」方面一直有點被人詬病。

咱們面向的「聯盟鏈」領域，由於在准入標準，系統架構、參與節點數、共識機制等方面都和公鏈不一樣，其性能表現遠高於公有鏈，可是目前幾個主流的區塊鏈平臺，在常規PC級服務器硬件上實測，TPS通常是在千級的樣子，交易延遲通常在1秒到10秒這個級別。（據說TPS十幾萬級和百萬級千萬級區塊鏈已經作出來了？好吧，期待）

筆者曾在大型互聯網公司工做多年，在海量服務領域，面對C10K問題（concurrent 10000 connection，萬級併發）已經有輕車熟路的解決方案，對通常的電商業務或內容瀏覽服務，普通pc級服務器單機達到幾萬TPS，且平均延時在500毫秒之內，飛通常的體驗已是常態，畢竟互聯網產品卡一下說不定就會致使用戶流失。對於快速增加的互聯網項目，經過平行擴容、彈性擴容、立體擴容的方式，幾乎能無底線、無上限地面對山呼海嘯的海量流量。

相比而言，區塊鏈的性能比互聯網服務慢，並且難以擴容，根因仍是在其「用計算換信任」的設計思路上。

具體哪裏慢呢？

從「古典」區塊鏈的系統內部來看👇

一、爲了安全防篡改防泄密可追溯，引入了加密算法來處理交易數據，增長了CPU計算開銷，包括HASH、對稱加密、橢圓曲線或RSA等算法的非對稱加密、數據簽名和驗籤、CA證書校驗，甚至是目前還慢到使人髮指的同態加密、零知識證實等。在數據格式上，區塊鏈的數據結構自己包含了各類簽名、HASH等交易外的校驗性數據，數據打包解包、傳輸、校驗等處理起來較爲繁瑣。

對比互聯網服務，也會有數據加密和協議打包解包的步驟，可是越精簡越好，優化到了極致，如無必要，毫不增長累贅的計算負擔。

二、爲了保證交易事務性，交易是串行進行的，並且是完全的串行，先對交易排序，而後用單線程執行智能合約，以免亂序執行致使的事務混亂、數據衝突等。即便在一個服務器有多核的CPU，操做系統支持多線程多進程，以及網絡中有多個節點、多臺服務器的前提下，全部交易也是有條不紊地、嚴格地按單線程在每臺計算機上單核地進行運算，這個時候多核CPU其餘的核可能徹底是空閒的。

而互聯網服務則是能用多少服務器的多少個核，採用全異步處理、多進程、多線程、協程、緩存、優化IOWAIT等等，必定會把硬件計算能力跑滿。

三、爲了保證網絡的總體可用性，區塊鏈採用了P2P網絡架構以及相似Gossip的傳輸模式，全部的區塊和交易數據，都會無差異地向網絡廣播，接收到的節點繼續接力傳播，這種模式可使數據儘量地傳達給網絡中的全部人，即便這些人在不一樣的區域或子網裏。代價是傳輸冗餘度高，會佔用較多的帶寬，且傳播的到達時間不肯定，可能很快，也可能很慢（中轉次數不少）。

對比互聯網服務，除非出錯重傳，不然網絡傳輸必定是最精簡的，用有限的帶寬來承載海量的數據，且傳輸路徑會爭取最優，點對點傳輸。

四、爲了支持智能合約特性，相似以太坊等區塊鏈解決方案，爲了實現沙盒特性，保證運行環境的安全和屏蔽不一致性因素，其智能合約引擎要麼是解釋型的EVM，或者是採用docker封裝的計算單元，智能合約核心引擎的啓動速度，指令執行速度，都沒有達到最高水平，消耗的內存資源也沒有達到最優。

而用常規計算機語言如C++、JAVA、go、rust語言直接實現海量互聯網服務，在這方面經常沒有限制。

五、爲了達到可容易校驗防篡改的效果，除了第一條提到的，區塊數據結構裏攜帶數據較多以外，針對交易輸入和輸出，會採用相似merkle樹、帕特里夏（Patricia ）樹等複雜的樹狀結構，經過層層計算獲得數據證實，供後續流程快速校驗。樹的細節這裏不展開，能夠經過網絡上的資料來學習其機制。

基本上，生成和維護這種樹的過程是很是很是很是很是繁瑣的，既佔用CPU的計算量，又佔用存儲量，使用了樹後，總體有效數據承載量（即客戶端發起的交易數據和實際存儲下來的最終數據對比）急劇降低到百分之幾，極端狀況下，可能接受了10m的交易數據後，在區塊鏈磁盤上可能實際須要幾百兆的數據維護開銷），由於存儲量的幾何級數增長，對IO性能要求也會更高。

互聯網服務由於基本不考慮分佈式互驗互信的問題，不多有使用這種樹的證實結構，了不得算下MD5和HASH作爲協議校驗位。

六、爲了達到全網一致性和公信力，在區塊鏈中全部的區塊和交易數據，都會經過共識機制框架驅動，在網絡上廣播出去，由全部的節點運行多步複雜的驗算和表決，大多數節點承認的數據，纔會落地確認。

在網絡上增長新的節點，並不會增長系統容量和提高處理速度，這一點完全顛覆了「性能不足硬件補」的常規互聯網系統思惟，其根因是區塊鏈中全部節點都在作重複的驗算以及生成本身的數據存儲，並不複用其餘節點數據，且節點計算能力良莠不齊，甚至會使最終確認的速度變慢。

在區塊鏈系統中增長節點，只會增長可容錯性和網絡的公信力，而不會加強性能表現，使得在同一個鏈中，平行擴展的可能性基本缺失了。 

而互聯網服務大可能是無狀態的，數據可緩存可複用，請求和返回之間的步驟相對簡單，容易進行平行擴展，能夠快速調度更多的資源參與服務，擁有無限的彈性。

七、由於區塊數據結構和共識機制特性，致使交易到了區塊鏈以後，會先排序，而後加入到區塊裏，以區塊爲單位，一小批一小批數據的進行共識確認，而不是收到一個交易馬上進行共識確認，好比：每一個區塊包含1000個交易，每3秒共識確認一次，這個時候交易有可能須要1~3秒的時間才能被確認。

更壞的狀況是，交易一直在排隊，而沒有被打包進區塊（由於隊列擁堵），致使確認時延更長。這種交易時延通常遠大於互聯網服務500ms響應的標準。因此區塊鏈其實並不適合直接用於追求快速響應的實時交易場景，行業一般說的「提升交易效率」是把最終清結算的時間都算在內的，好比把T+1長達一兩天的對帳或清結算時延，縮短到幾十秒或幾分鐘，成爲一個「準實時」的體驗。

綜上所述，區塊鏈系統天生就揹着幾座大山，包括單機內部計算開銷和存儲較大，揹着串行計算的原罪，網絡結構複雜冗餘度高，區塊打包共識的節奏致使時延較長，而在可擴展性上又難以直接增長硬件來平行擴容，致使scale up和scale out兩方面，都存在明顯瓶頸。

Scale Out（等同scale horizontally）：橫向擴展，向外擴展，如：向原有系統添加一組獨立的新機器，用更多的機器來增長服務容量

Scale Up（等同Scale vertically）：縱向擴展，向上擴展，如向原有的機器添加CPU、內存，在機器內部增長處理能力

直面區塊鏈的速度困境，FISCO BCOS的開發者發揮「愚公移山」的精神，努力優化。通過一段時間的努力，已經移山倒海，修出了一條又一條高速通道，使區塊鏈找到了邁向極速時代的路子。FISCO BCOS修出來的高速通道是怎麼樣的，歡迎你們關注【FISCO BCOS開源社區】公衆號，期待下一篇《FISCO BCOS的性能優化》，咱們將具體闡述FISCO BCOS是如何將區塊鏈交易處理性能提高的。

---

 

咱們鼓勵機構成員、開發者等社區夥伴參與開源共建事業，有你在一塊兒，會更了不得。多樣參與方式：

1 進入微信社羣，隨時隨地與圈內最活躍、最頂尖的團隊暢聊技術話題（進羣請添加小助手微信，微信ID：fiscobcosfan）；

2 訂閱咱們的公衆號：「FISCO BCOS開源社區」，咱們爲你準備了開發資料庫、最新FISCO BCOS動態、活動、大賽等信息；

3 來Meetup與開發團隊面對面交流，FISCO BCOS正在全國舉辦巡迴Meetup，深圳、北京、上海、成都……歡迎您公衆號在菜單欄【找活動】中找到附近的Meetup，前往結識技術大咖，暢聊硬核技術；

4 參與代碼貢獻，您能夠在Github提交Issue進行問題交流，歡迎向FISCO BCOS提交Pull Request，包括但不限於文檔修改、修復發現的bug、提交新的功能特性。

代碼貢獻指引：

https://github.com/FISCO-BCOS/FISCO-BCOS/blob/master/docs/CONTRIBUTING_CN.md

 

本文首發於公衆號【FISCO BCOS開源社區】，如轉載請註明出處，原創不易，謝謝珍惜