a16z：衡量區塊鏈性能的關鍵原則

性能和可擴展性是加密領域備受討論的挑戰，與 L1 項目和 L2 解決方案有關。然而，我們沒有標準化的指標或基準。數據報告的方式往往不一致且不完整，這使得準確比較項目變得困難，並常常模糊了實踐中最重要的內容。

我們需要一種更細緻和徹底的方法來衡量和比較性能——將性能分解為多個組件，並在多個數據軸上比較權衡。本文定義了區塊鏈性能基本含義和概述了其存在的挑戰，並提供了評估區塊鏈性能時需要牢記的指導原則和關鍵原則。

可擴展性 vs. 性能

首先，可擴展性和性能具有標準的計算機科學含義，在區塊鏈中經常被誤用。性能度量系統當前能夠實現的目標。正如我們下面將要討論的，性能指標可能包括每秒交易數或交易確認時間中位數。另一方面，可擴展性衡量系統通過添加資源來提高性能的能力。

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

在區塊鏈中也可以使用其他一些一次性的技巧（如 SegWit），但你需要一個可擴展的架構來實現持續的性能改進，其中添加更多的資源可以隨著時間的推移提高性能。這也是許多其他計算機系統的傳統思路，比如構建一個網路服務器。通過一些常見的技巧，可以構建一個運行速度快的服務器。但最終需要一個多服務器架構，通過不斷添加額外的服務器來滿足不斷增長的需求。

理解這種區別還有助於避免在語句中發現的常見類別錯誤，比如「區塊鏈 X 是高度可擴展的，它每秒可以處理 Y 個交易」。第二種說法可能令人印象深刻，但它是一個性能指標，而不是可擴展性指標，並不是指通過添加資源來提高性能的能力。

可擴展性本質上要求利用並行性。在區塊鏈空間中，L1 擴展似乎需要分叉 或類似於分叉的東西。分叉的基本概念是將狀態分割成塊，以便不同的驗證器可以獨立處理，與可擴展性的定義非常匹配。在 L2 還有更多的選項，允許添加並行處理，包括鏈下通道、Rollup 服務器和側鏈。

延遲 vs. 吞吐量

通常，區塊鏈系統性能是通過兩個維度進行評估的，即延遲和吞吐量。延遲度量確認單個交易的速度，而吞吐量度量隨著時間的推移交易的總速率。這些軸既適用於 L1 和 L2 系統，也適用於許多其他類型的計算機系統（如數據庫查詢引擎和 web 服務器）。

但是延遲和吞吐量的測量和比較都很複雜。此外，個人用戶實際上並不關心吞吐量（這是一個系統範圍的度量）。他們真正關心的是延遲和交易費用。更具體地說，他們的交易儘可能快、儘可能通過便宜的價格得到確認。儘管許多其他計算機系統也以成本/性能為基礎進行評估，但交易費用是區塊鏈系統的一個新的性能軸，這在傳統計算機系統中並不真正存在。

測量延遲的挑戰

延遲一開始看起來很簡單：交易需要多長時間才能得到確認？但有幾種不同的方法來回答這個問題。

首先，我們可以測量不同時間點之間的延遲，得到不同的結果。例如，當用戶在本地點擊「提交」按鈕時，還是當交易到達內存池時，我們開始測量延遲？當交易在一個提議的區塊中，或者當一個區塊被一個或六個後續區塊確認時，我們才停止計算時間嗎？

最常見的方法是從驗證者的角度，測量從用戶第一次廣播交易到合理地「確認」交易的時間。當然，不同的商家可能採用不同的驗收標準，甚至單個商家也可能根據交易金額的不同採用不同的標準。

以驗證器為中心的方法在實踐中忽略了一些重要的事情。首先，它忽略了點對點網路上的延遲（從客戶端廣播一個交易到大多數節點聽到它需要多長時間？）和客戶端延遲（在客戶端的本地機器上準備一個交易需要多長時間？）客戶端延遲可能性非常小，對於簽署以太坊支付等簡單的交易來說是可以預測的，但對於更複雜的情況，如證明屏蔽的 Zcash 交易是正確的，則可能非常重要。

即使我們將試圖測量延遲的時間窗口標準化，答案也是視情況而定。迄今為止，還沒有一個加密貨幣系統提供固定的交易延遲。一個基本的經驗法則是：

延遲是一個分布狀態，而不是一個數字。

網路研究界早就明白這一點。特彆強調的是分布的「長尾」，因為即使 0.1% 的交易（或 web 服務器查詢）的高延遲也會嚴重影響最終用戶。

在區塊鏈中，確認延遲的變化有很多原因：

批處理：大多數系統以某種方式將交易批處理，例如，在大多數 L1 系統上將交易批處理到區塊中。這將導致可變的延遲，因為一些交易將不得不等待，直到批處理填滿。其他人可能會幸運地最後加入。這些交易立即得到確認，並且不會經歷任何額外的延遲。

可變擁塞：大多數系統都會出現擁塞，這意味著發布的交易比系統能夠立即處理的交易要多。當交易在不可預測的時間進行廣播時，或者當新交易在一天或一周內的速度發生變化時，或者在對像熱門 NFT  啟動這樣的外部事件時響應，擁塞的程度會發生變化。

共識層差異：在 L1 確認交易通常需要一組分布式節點來達成對一個區塊的共識，這可能會增加可變的延遲，無論擁塞情況如何。工作量證明系統在不可預測的時間找到區塊。PoS  系統還可以添加各種延遲（例如，如果在線節點數量不足，不能在一輪中組成一個委員會，或者如果需要改變觀點以應對領導者的崩潰）。

基於這些原因，一個好的指導原則應該是：

關於延遲的聲明應該顯示確認時間的分布，而不是像平均值或中位數這樣的單個數字。

雖然像平均值、中位數或百分位數這樣的匯總統計提供了部分情況，但準確地評估一個系統需要考慮整個分布。在某些應用程序中，如果延遲分布相對簡單，則平均延遲可以提供很好的洞察。但在加密貨幣中，這種情況幾乎從未發生過。通常情況下，確認時間很長。

支付渠道網路（如閃電網路 ）就是一個很好的例子。這是一個經典的 L2 擴展解決方案，這些網路大多數時候提供非常快的支付確認，但偶爾他們需要通道重置，這可能會增加延遲的數量級。

即使我們對確切的延遲分布有很好的統計，它們也可能會隨著系統和系統需求的變化而變化。另外，如何比較相互競爭的系統之間的延遲分布也並不總是很清楚。例如，假設一個系統確認的交易延遲均勻分布在 1 到 2 分鐘之間（平均和中位數為 90 秒）。如果一個競爭系統在 1 分鐘內準確確認 95% 的交易，而在 11 分鐘內確認另外 5% 的交易 (平均 90 秒，中位數 60 秒)，那麼哪個系統更好？答案可能是，有些應用程序更喜歡前者，有些則更喜歡後者。

最後，需要注意的是，在大多數系統中，並非所有交易的優先級都是相同的。用戶可以支付更多的錢來獲得更高的優先級，所以除了以上這些，延遲也取決於所支付的交易費用。總而言之：

延遲是複雜的。報告的數據越多越好。理想情況下，應該在不同的擁塞條件下測量完整的延遲分布。將延遲分解為不同的組件（本地、網路、批處理、共識延遲）也是有幫助的。

測量吞吐量的挑戰

表面上看吞吐量似乎也很簡單：一個系統每秒可以處理多少交易？但有兩個主要的困難：究竟什麼是「交易」，以及我們是否在度量一個系統今天做什麼或者它可能做什麼？

雖然「每秒交易數」（tps）是度量區塊鏈性能的實際標準，但作為度量單位的交易存在問題的。對於提供通用可編程性（智能合約）或甚至有限功能的系統，如比特幣的多路交易或多信號驗證選項，其基本問題是：

不是所有的交易都是平等的。

這在以太坊中明顯是正確的，在以太坊中，交易可以包括任意代碼和任意修改狀態。以太坊中的 gas 概念用於量化（並收取費用）交易正在進行的總體工作量，但這與 EVM 執行環境高度相關。沒有簡單的方法來比較一組 EVM 交易與一組使用 BPF 環境的 Solana  交易平台做的工作總量。將兩者與一組比特幣交易進行比較同樣令人擔憂。

將交易層劃分為共識層和執行層的區塊鏈可以使這一點更加明確。在（純）共識層，吞吐量可以用每單位時間添加到鏈上的字節來衡量。執行層更複雜。

更簡單的執行層，例如只支持支付交易的 Rollup 服務器，避免了量化計算的困難。即使在這種情況下，支付也會因投入和產出的數量而變化。支付通道交易可能因所需的「跳躍次數」而異，這將影響吞吐量。Rollup 服務器吞吐量取決於將一批交易「聯網」到更小的匯總更改集的程度。

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

總而言之：

吞吐量聲明需要仔細解釋交易工作負載和驗證器的數量（它們的數量、實現和網路連接）。在沒有任何明確標準的情況下，來自以太坊等流行網路的歷史工作量就足夠了。

延遲和吞吐量權衡

延遲和吞吐量通常是一種權衡。這種權衡通常不是一帆風順的，當系統負載接近最大吞吐量時，延遲會急劇增加。

零知識匯總系統是吞吐量/延遲權衡的一個自然例子。大量的交易會增加證明時間，從而增加延遲。但鏈上的足跡，無論是在證明大小和驗證成本方面，將分攤到更多的交易，更大的批處理大小，增加吞吐量。

交易費用

可以理解的是，終端用戶更關心延遲和費用之間的權衡，而不是延遲和吞吐量之間的權衡。用戶根本沒有關心吞吐量的直接原因，他們只關心能夠以儘可能低的費用快速確認交易（有些用戶更關心費用，而有些用戶更關心延遲）。高額收費受多種因素影響：

有多少市場需求進行交易？

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

系統提供給驗證者或礦工的總收入是多少？

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

前兩個因素大致是導致市場清算價格的供需曲線（儘管有人聲稱，礦工像聯盟企業一樣將費用提高到這一點以上）。在其他條件相同的情況下，更高的吞吐量應該會導致更低的費用，但還有更多因素要處理。

特別是上面的第 3 點和第 4 點是區塊鏈系統設計的基本問題，但是我們對它們都缺乏良好的原則。相對於交易費用，我們對給予礦工以通貨膨脹獎勵的好處和壞處有一定的了解。然而，儘管有許多關於區塊鏈共識協議的經濟分析，我們仍然沒有一個被廣泛接受的模型來說明需要多少收入給驗證器。今天，大多數系統都建立在一個有根據的猜測中，即有多少收入足以讓驗證器誠實地工作，而不會扼殺系統的實際使用。在簡化的模型中，可以看出，安裝 51% 攻擊的成本與驗證程序的回報成正比。

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

比較不同系統之間的費用可能會產生誤導。雖然交易費用對用戶來說很重要，但除了系統設計本身之外，還會受到很多因素的影響。吞吐量是分析整個系統的更好指標。

結論

公平準確地評估性能是很難的。這同樣適用於測量汽車的性能。就像區塊鏈一樣，不同的人會關心不同的事情。對於汽車，有些用戶會關心最高速度或加速，有些人會關心油耗，還有一些人會關心牽引能力。所有這些都不容易得到準確值。例如，在美國，環境保護署就制定了詳細的指導原則，規定如何評估汽油里程數，以及在經銷商處必須如何向用戶展示。

區塊鏈空間距離這個級別的標準化還有很長的路要走。在某些領域，未來我們可能會使用標準化的工作負載來評估系統的吞吐量，或者使用標準化的圖形來表示延遲分布。目前，對評價者和建設者來說，最好的辦法是收集和公布儘可能多的數據，並對評價方法進行詳細的描述，以便它能夠被複製和與其他系統進行比較。

原文連結