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

原文標題：《a16z：為什麼鏈的表現難以衡量？ 》

原文作者：Joseph Bonneau，a16z 

原文編譯：Katie 辜負， Odaily 星球日報

效能和可擴展性是加密領域備受討論的挑戰，與 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% 的錢。去這個公園是個好主意嗎？這可能是因為他們更有效率，用更少的錢獲得了同等的安全。另一種可能是花費超過所需的費用來確保遊樂設施的安全，而沒有任何好處。但也可能是第一個公園很危險。區塊鏈系統也類似。一旦剔除吞吐量，費用較低的區塊鏈的費用較低，因為它們對驗證者的獎勵（因此激勵）較少。我們現在沒有好的工具來評估這是否可性，或者它是否會使系統容易受到攻擊。總而言之：

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

結論

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

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

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia