a16z：如何客觀評估區塊鏈效能？

公平而準確地評估區塊鏈效能並非易事。

圍繞效能和可擴充套件性的討論，是整個加密世界最經久不衰的辯題。

關於一層和二層解決方案優劣以及有效性的爭論一直在進行，不過由於缺乏標準化的指標和考核標準，爭論中各方拿出的資料往往缺乏一致性，無疑進一步加劇了觀點的分歧。

簡單來說，我們需要一種更加細緻和更加徹底的方法來進行效能的比較，比如說我們需要把效能分為幾個維度進行分別對比，並找到一個綜合性的權衡標準。本文中，我將從基本術語講起，概述目前市場所面臨的挑戰，並針對評估區塊鏈效能時需要牢記的一些基本原則進行展開。

可擴充套件性 & 效能

首先，讓我們定義兩個術語，可擴充套件性和效能。這兩個詞具有標準的計算機科學含義，但卻經常在區塊鏈環境中被濫用。效能一般用於衡量系統所能夠實現的目標功效，效能指標可能包括每秒能處理的程序數量或者特定需求下所需要的時間長短。而可擴充套件性則是被用於衡量系統透過新增一定資源來提升效能的能力如何。

為什麼說我們要先明確定義，因為實際上許多提高效能的方法根本不會提高可擴充套件性。一個簡單的例子是使用更高效的數字簽名方案，例如 BLS 簽名，其大小大約是 Schnorr 或 ECDSA 簽名的一半。如果比特幣從 ECDSA 切換到 BLS，每個區塊的交易數量可能會增加 20-30%，從而在一夜之間提高效能。但是我們只能這樣做一次——沒有更節省空間的簽名方案可以切換（BLS 簽名也可以聚合以節省更多空間，但這同樣也只是另一個一次性的技巧）。

實際上，區塊鏈網路中還有很多提升的技巧也是一次性的（例如 SegWit），但對於我們來說，真正需要的是一個可擴充套件的架構來實現持續的效能改進，只有這樣我們才能透過持續新增資源來持續提升效能。實際上在 Web2 時代，這已經是一種通用的手段了，以搭建伺服器為例，雖然我們可以直接搭建一個足夠快的伺服器，但最終一般都需要升級成為多伺服器架構，其間就需要透過不斷新增新的伺服器來滿足不斷增長的資料儲存 / 處理需求。

理解這種區別後還有助於避免在諸如「某區塊鏈具有高度可擴充套件性，它每秒可以處理多少筆交易！」之類的陳述中出現常識性錯誤。雖然這種話術可能很具有煽動性，但事實上處理多少筆交易是效能指標而不是可擴充套件性指標。

可擴充套件性本質上需要利用並行性。在區塊鏈領域，一層擴充套件往往需要分片或看起來像分片的東西。分片的基本概念其實就是將狀態分成幾塊，以便讓不同的驗證者可以獨立處理其中一部分，而這與可擴充套件性的定義非常吻合。當然，二層還有更多選項允許新增並行處理，包括鏈下通道、Rollup 和側鏈等等。

延遲與吞吐量

過去我們往往習慣用延遲和吞吐量兩個維度評估區塊鏈的效能：延遲可用於衡量單筆交易可以多快得到確認，而吞吐量則用於衡量特定時間內可以確認的交易總量。這種衡量方式既適用於一層和二層網路，甚至在區塊鏈以外的其他型別計算機系統中也完全適用。

不幸的是，延遲和吞吐量這兩個緯度實際上都很難測量和比較。而且另一個很重要點在於，

個人使用者實際上並不關心吞吐量，他們真正關心的只有延遲和交易費用。

交易費用是區塊鏈系統中的一個重要維度，而這個在傳統計算機領域中並不存在。

測量延遲的挑戰

延遲的測量看起來似乎很簡單：交易需要多長時間才能得到確認？但實際操作中問題才會顯現出來。首先，我們在不同時間點測量的延遲往往是不一樣的，我們究竟是從使用者本地點選提交按鈕開始計算？還是在任務到達記憶體池的那一刻開始計算？還有就是當區塊確認時，我們是否要立即停止計時？不同的操作細節都會帶來不同的結果。

最常見的方法是從驗證者的角度來衡量，從客戶首次廣播交易到交易被合理確認的時間（從某種意義上說，現實世界的商家會考慮收到付款併發出商品）。當然，不同的商戶可能採用不同的接受標準，甚至單個商戶也可能根據交易金額的大小而採用不同的標準。

以驗證者為中心的方法忽略了一些在實踐中很重要的事情。首先，它忽略了點對點網路上的延遲（從客戶端廣播交易到大多數節點聽到它需要多長時間？）和客戶端延遲（準備交易需要多長時間？在客戶端的本地機器上需要載入多久？）。對於簽署以太坊支付等簡單交易，客戶端延遲可能非常小且可預測，但對於更復雜的情況（例如證明隱私交易是正確的）就不同了。

即使我們標準化了測量延遲的時間視窗，最終的答案也依舊是視情況而定的。從來沒有一個加密貨幣系統能保證恆定的交易延遲。要記住的基本經驗法則其實是：

延遲是一個分佈，而不是一個數字。

網路研究社群早就意識到了這一點，並指出長尾至關重要，即使是 0。1% 的程序出現延遲也會嚴重影響最終的使用者體驗。

對於區塊鏈來說，確認延遲可能會因多種原因而有所不同：

批處理

：大多數系統以某種方式批處理事務，這會導致產生可變延遲，因為某些事務必須等到批處理佇列被填滿後才會被處理。網路參與者可能會很幸運地乘上該批次的末班車。這些交易會立即得到確認，不會出現任何額外的延遲，但那些提前進入佇列的人們就必須要花費更長的時間去等待確認。

不確定的擁堵

：大多數系統都經歷過擁堵的狀況，這意味著釋出的交易超過了系統可以立即處理的數量。當交易在不可預測的時間（通常抽象為泊松過程）廣播時，或者當新交易的速率在一天或一週內發生變化時，或者響應外部事件時，擁堵程度可能會有所不同。

共識層差異

：在一層確認交易通常需要一組分散式節點才能就區塊達成共識，這可能會增加可變延遲，而不受擁堵的影響。工作量證明系統在不可預測的時間發現塊。權益證明系統還可能增加各種延遲。

由於這些原因，一個好的指導方針是：

關於延遲的宣告應該以確認時間的分佈呈現，而不是像平均值或中位數這樣的單個數字。

雖然平均值、中位數或百分位數等彙總統計資料也能表明部分規律，但準確評估系統需要考慮整個分佈。在某些應用程式中，如果延遲分佈相對簡單，平均延遲可以提供很好的洞察力。但在加密貨幣中這種理想狀況並不多見：通常情況下，確認時間會很長。

支付渠道網路（例如閃電網路）就是一個很好的例子。作為經典的 L2 擴充套件解決方案，這些網路在大多數情況下都提供非常快速的支付確認服務，但有時它們需要通道重置，而這就可能會導致延遲提升幾個數量級。

即使我們對確切的延遲分佈有很好的統計資料，它們也可能會隨著系統和系統需求的變化而隨時間變化，如何比較競爭系統之間的延遲分佈也非常模糊。例如，考慮一個系統，它確認事務的均勻分佈延遲在 1 到 2 分鐘之間（平均和中位數為 90 秒）。如果一個競爭系統在 1 分鐘內準確地確認了 95% 的交易，而在 11 分鐘內確認了另外 5%（平均 90 秒，中位數為 60 秒），那麼哪個系統更好？答案是不同類別的應用可能選擇並不一致。

最後，需要注意的是，在大多數系統中，並非所有事務的優先順序都相同。使用者可以支付更多費用來獲得更高的包含優先順序，因此除了上述所有內容之外，延遲還取決於支付的交易費用。總之：

延遲很複雜。前提條件中的細節越多越好。理想情況下，應在不同的擁堵條件下測量完整的延遲分佈。將延遲分解為不同的元件（本地、網路、批處理、共識延遲）也很有幫助。

測量吞吐量的挑戰

吞吐量乍一看似乎也很簡單：一個系統每秒可以處理多少事務？但事實上問題同樣被隱藏在水面之下。難點主要體現在兩個方面，第一是究竟什麼算交易，我們是在衡量一個系統今天做了些什麼？還是要去衡量他能做到些什麼？

雖然每秒交易筆數（或 TPS）是衡量區塊鏈效能的通用標準，但交易作為衡量單位是有問題的。對於提供通用可程式設計性（智慧合約）甚至比特幣的多重交易或多重簽名驗證選項等限定功能的系統，一個最基本的問題是：

並非所有交易都是平等的。

在以太坊網路中，交易可以包含任意程式碼以及任意狀態。以太坊中的 Gas 概念用於量化（並收取費用）交易正在執行的總工作量，但這是高度限定於 EVM 執行環境的。沒有簡單的方法可以將一組 EVM 事務完成的工作總量與使用 BPF 環境的一組 Solana 事務進行直接比較。將其中任何一個與一組比特幣交易進行直接比較也並不合理。

將交易層分為共識層和執行層的區塊鏈可以使這一點更加清晰。在（純）共識層，吞吐量可以以每單位時間新增到鏈中的位元組數來衡量。而執行層會複雜很多。

更簡單的執行層，例如只支援支付交易的 rollup 伺服器，避免了量化計算的困難。但是，即使在這種情況下，支付的輸入和輸出數量也會有所不同。支付渠道交易所需的可變引數數量可能會有所不同，這會影響吞吐量。rollup 伺服器的吞吐量可能取決於一批事務可以在多大程度上「歸結」為一組較小的資料包。

吞吐量的另一個挑戰是超越憑經驗測量當今的效能來評估理論容量。這引入了各種建模問題來評估潛在容量。首先，我們必須確定執行層的實際事務工作負載。其次，真實系統幾乎從未達到理論容量，尤其是區塊鏈系統。出於穩健性的原因，我們希望節點實現在實踐中是異構的和多樣化的（而不是所有客戶端都執行一個軟體實現）。這使得區塊鏈吞吐量的準確模擬更加難以進行。

總的來說，

權衡吞吐量需要仔細解釋交易工作量和驗證者的數量。在沒有任何明確標準的情況下，只能以以太坊這種比較流行的網路歷史負載作為標準來對比計量。

延遲與吞吐量二者的綜合考量

延遲和吞吐量各自統計過後，我們還需要在二者之間進行綜合權衡。正如 Lefteris Kokoris-Kogias 所述，這種權衡通常並不順利，當系統負載接近其最大吞吐量時，延遲會急劇上升。

ZK Rollup 系統提供了吞吐量 / 延遲權衡的自然示例。大批次交易增加了證明時間，從而增加了延遲。但是，在證明大小和驗證成本方面，鏈上算力將像更大規模的交易簇傾斜，從而提高吞吐量。

交易費用

可以理解的是，終端使用者更關心延遲和費用之間的權衡，而不是延遲和吞吐量。使用者根本沒必要關心吞吐量，他們只希望可以以儘可能低的費用快速確認交易（一些使用者更關心費用，而其他使用者更關心延遲）。總體而言，費用受多種因素影響：

有多大的市場需求？

系統可實現的總吞吐量是多少？

該系統為驗證者或礦工提供了多少收入？

這筆收入中有多少是基於交易費用與通貨膨脹獎勵？

簡單來說，在其他條件相同的情況下，更高的吞吐量應該會導致更低的費用。不過上面提到的第 3 點和第 4 點是區塊鏈系統設計的基本問題。儘管對區塊鏈共識協議進行了許多經濟分析，但對於驗證者需要多少收入，我們仍然沒有達成一個共識性的模型。今天大多數系統都建立在有根據的猜測之上，即提供多少收入足以讓驗證者誠實行事的同時還不會影響網路對於使用者的吸引力。在簡化的模型中，讓發起 51% 攻擊的成本與驗證者的獎勵成正比即可。

提高攻擊成本是一件好事，但我們也不知道多少安全性「夠用」。想象一下，您正在考慮去兩個遊樂園。其中一個聲稱在乘車維護上的花費比另一個少 50%。去這個公園是個好主意嗎？可能是它們效率更高，並且能以更少的錢獲得同等的安全性。也許另一個人的花費超過了保持遊樂設施安全所需的費用，而沒有任何好處。但也可能是第一個公園很危險。區塊鏈系統是類似的。一旦考慮到吞吐量，費用較低的區塊鏈費用較低，因為它們獎勵較少。我們今天沒有好的工具來評估這是否可行，或者它是否會使系統容易受到攻擊。總的來說：

比較系統之間的費用可能會造成一定程度的誤導。儘管交易費用對使用者來說很重要，但除了系統設計本身之外，它們還受到許多因素的影響。吞吐量是分析整個系統的更好指標。

結論

公平而準確地評估效能是很困難的。衡量區塊鏈和衡量一款車值不值得買一樣複雜，不同的人會關心不同的事情，對於汽車來說，一些使用者會關心極限速度或百公里加速成績，有一些人關心油耗，還有一些人則只關心這輛車能裝多少貨。正因如此，美國環境保護署甚至直接出臺了一個汽車評定準則的指導方針。

而區塊鏈領域中，我們還遠沒有來到可以出臺一個標準化準則的時刻，某些時候我們可能會找到一個標準的工作負載並以此繪製區塊鏈網路吞吐量和延遲分佈的「標準圖表」，但現如今對於研究者和建設者來說，最好的方法只有去收集儘可能多的資料，並在發表觀點前儘可能詳盡地描繪出測試環境，因為只有這樣我們才能得到一個相對客觀的對比結果。