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

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

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

可擴展性 & 性能

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

為什么說我們要先明確定義，因為實際上許多提高性能的方法根本不會提高可擴展性。一個簡單的例子是使用更高效的數字簽名方案，例如 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%。去這個公園是個好主意嗎？可能是它們效率更高，并且能以更少的錢獲得同等的安全性。也許另一個人的花費超過了保持游樂設施安全所需的費用，而沒有任何好處。但也可能是第一個公園很危險。區塊鏈系統是類似的。一旦考慮到吞吐量，費用較低的區塊鏈費用較低，因為它們獎勵較少。我們今天沒有好的工具來評估這是否可行，或者它是否會使系統容易受到攻擊。總的來說：比較系統之間的費用可能會造成一定程度的誤導。盡管交易費用對用戶來說很重要，但除了系統設計本身之外，它們還受到許多因素的影響。吞吐量是分析整個系統的更好指標。

結論

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

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