和數傳媒：公鏈效能難題解析

公鏈作為區塊鏈世界的基礎設施中的基石，極大地影響著上層應用的效率、成本以及使用者體驗。如果從比特幣開始算起，公鏈一路走來已經 10 年了，但至今為止還遠未到技術收斂的階段。在這第 11 個年頭，細數一下已經被大家廣為關注的方向和一些尚未被大家關注的方向。

效能難點1——速度

效能問題從區塊鏈最開始就被大家意識到，直觀的體驗就是速度，也就是一個交易多久能被確認。最初這個瓶頸是共識演算法，Nakamoto 共識最初 10 分鐘一次出塊，平均交易確認延遲是 5 分鐘。而後以太坊將出塊間隔降到了 15 秒，期望平均交易確認延遲是 7 秒。但真的是 7 秒就能被確認了嗎？其實並不是。這時，效能的瓶頸變成了吞吐量，雖然交易確認延遲是 7 秒，但是大多數交易在排隊，除非給出很高的交易手續費來插隊。

吞吐量之所以受到限制，是因為普通全節點的頻寬，也就是網際網路的平均頻寬。這個限制和共識演算法是本質無關的。這一點終於被很多團隊認識到，避免設計出一些只能執行在本地資料中心內部的高吞吐量系統。要突破這個限制，唯一的出路是切分吞吐量，讓不同的全節點負責不同的部分。分片（Sharding）就是完成這種切分的有效方案，當然未來也可能有其它的方案。

在吞吐量問題解決之後，速度上的體驗又會回到交易確認延遲這個事情上。當然這個時候的要求就不是要達到幾十秒，而是應用會希望可以達到更低的延遲，比如 1 秒甚至以下。計算機系統，在同一個層面的設計上，吞吐量和延遲通常會有矛盾。例如區塊鏈這種分批交易確認方式，一個批次越大，也就是 block 越大，吞吐量就會越大，而這時出塊的間隔就需要更長，也就使得交易確認延遲變大。

公鏈的 Layer 1 技術將工作量切分之後，吞吐量將獲得幾個數量級的提升，然而其交易確認延遲卻沒有顯著的改善。我自己的預判是，這裡才是 Layer 2 的側鏈真正發揮作用的地方，而不是像現在很多側鏈專案宣稱的那樣，所要攻克的問題幾乎和 Layer 1 要攻克的問題完全一樣。

效能難點2——容量

容量問題受到關注就少了很多。其實容量問題包含兩個方面，一個是記憶體中的賬簿狀態，每個使用者的餘額以及智慧合約的狀態，另一個是磁碟中歸檔的歷史交易記錄。

比特幣幾乎沒有被擴充套件使用者狀態，並且吞吐量又很低，所以在那個時候，這個容量完全不是問題。但是在吞吐量提升，並且 DApp 開始逐漸繁榮之後，容量問題便逐漸凸顯出來。和吞吐量類似，這個問題之所以受到限制，是因為普通全節點的記憶體和硬碟的容量限制所致。這個限制也是和共識演算法本質無關的。

突破這個限制，唯一的出路也是切分容量的負擔，讓不同的全節點負責不同部分的賬簿狀態以及交易歸檔。分片（Sharding）就是完成這種切分的有效方案，當然未來也可能有其他的方案。賬簿狀態壓縮，歷史交易壓縮都是很好的實踐，可以和分片方案一起用。但是這些方向始終受限於單個全節點的本地資源限制，能提高几倍已經是非常不易，而設計良好的分片系統可以提高成百上千倍。

效能難點3——分片

我最初來到這個領域，看其中的效能問題。按說分片是非常靠譜並且直接的解決方案。在區塊鏈以外的計算系統，哪個不是通過劃分工作量，分散到不同的計算單元，從而獲得幾個數量級的效能提升？GPU、Mapreduce、CDN 哪個商用高效能體系不是用這樣的架構？當然最初是源自資料庫領域。然而，當時圈子裡的人卻和我說分片是個偽科學，是一個不切實際的方案，無法為區塊鏈擴容提供任何幫助。我當時是驚了，這區塊鏈有什麼特殊之處，使得切分工作量變得不可行了？

最後我發現了問題所在。並不是區塊鏈有什麼特別之處，而是有個叫 Z 的專案，做了一個不完整的分片方案，僅僅切分了交易處理的工作量，而交易仍舊需要廣播給全網所有節點，每個節點仍舊需要維護全網的賬簿狀態，每個交易的對賬簿狀態更新計算，所有節點也都仍要算一遍。這意味著完全沒有實現分片的好處，也沒有吞吐量和容量的提升，同時還引入了額外的開銷，導致其實際效能比不分片的系統還差。

但是，這個系統總體上安全性是沒問題的，繼承了之前共識演算法的安全特性，所以他們的論文會被 ACM CCS 這樣專注計算和通訊安全的會議接受，倒也不令人驚訝。而真正在效能和容量上有突破的工作，為什麼要找安全領域專家去評審，難道不應該是找效能領域的專家去評審嗎？例如 ACM SIGCOMM、OSDI、SOSP、NSDI 那樣的網路系統的會議。當然，在那個空氣幣都飈上天的年份，出來用這樣的技術方案，發個幣毫無壓力。

所以這裡還是要給分片技術正名，雖然有相當難度，但這是正途。

同時隱私有兩個方面的內涵，一是使用者的狀態，例如使用者的賬戶餘額，二是使用者之間的活動記錄，例如 A給B轉了X個幣。監管和隱私也許可以在這兩個方面分開找到權衡的點。