A16z：為什么區塊鏈性能很難衡量？

2022-08-09 16:08:00

原文：https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure/

作者：Joseph Bonneau

性能和可擴展性是加密領域中備受討論的挑战，與第 1 層項目（獨立區塊鏈）和第 2 層解決方案（如rollup和鏈下通道）相關。然而，我們沒有標准化的指標或基准。數字通常以不一致和不完整的方式報告，這使得准確比較項目變得困難，並常常模糊了實踐中最重要的內容。

我們需要一種更細致、更徹底的方法來衡量和比較性能——一種將性能分解為多個組件，並在多個軸上進行權衡比較的方法。在這篇文章中，我定義了基本術語，概述了挑战，並提供了在評估區塊鏈性能時要牢記的指導方針和關鍵原則。

可擴展性與性能

首先，讓我們定義兩個術語，可擴展性和性能，它們具有標准的計算機科學含義，在區塊鏈環境中經常被濫用。性能衡量系統當前能夠實現的目標。正如我們將在下面討論的那樣，性能指標可能包括每秒交易數或交易確認時間中值。另一方面，可擴展性衡量系統通過添加資源來提高性能的能力。

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

許多其他一次性技巧（例如隔離見證）在區塊鏈中是可能的，但你需要一個可擴展的架構來實現持續的性能改進，其中添加更多資源會隨着時間的推移提高性能。這也是許多其他計算機系統中的傳統智慧，例如構建 Web 服務器。通過一些常用技巧，你可以構建一個非常快速的服務器；但最終，你需要一個多服務器架構，通過不斷添加額外的服務器來滿足不斷增長的需求。

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

可擴展性本質上需要利用並行性。在區塊鏈領域，第 1 層擴展似乎需要分片或看起來像分片的東西。分片的基本概念——將狀態分成幾塊，以便不同的驗證者可以獨立處理——與可擴展性的定義非常吻合。第 2 層還有更多選項允許添加並行處理——包括鏈下通道、rollup服務器和側鏈。

延遲與吞吐量

傳統上，區塊鏈系統性能通過延遲和吞吐量兩個維度進行評估：延遲衡量單個交易可以多快得到確認，而吞吐量衡量交易隨時間的總速率。這些軸適用於第 1 層和第 2 層系統，以及許多其他類型的計算機系統（例如數據庫查詢引擎和 Web 服務器）。

不幸的是，延遲和吞吐量都很難測量和比較。此外，個人用戶實際上並不關心吞吐量（這是一個系統範圍的衡量標准）。他們真正關心的是延遲和交易費用——更具體地說，他們的交易被盡快確認並盡可能便宜。盡管許多其他計算機系統也在成本/性能的基礎上進行評估，但交易費用是區塊鏈系統的一個新的性能軸，這在傳統計算機系統中並不存在。

測量延遲的挑战

延遲一开始似乎很簡單：交易需要多長時間才能得到確認？但總有幾種不同的方法可以回答這個問題。

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

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

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

即使我們標准化了我們試圖用延遲測量的時間窗口，答案幾乎總是取決於它。從來沒有一個加密貨幣系統能夠提供固定的交易延遲。要記住的基本經驗法則是：

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

網絡研究社區早就明白這一點。特別強調分布的“長尾”，因為即使是 0.1% 的交易（或 Web 服務器查詢）的高度延遲也會嚴重影響最終用戶。

在區塊鏈中，確認延遲可能會因多種原因而有所不同：

批處理：大多數系統以某種方式批處理交易，例如大多數第 1 層系統上的塊。這會導致可變延遲，因為某些交易必須等到批處理填滿。其他人可能會很幸運並最後加入該批次。這些交易會立即得到確認，不會出現任何額外的延遲。

可變擁塞：大多數系統都遭受擁塞，這意味着要處理的交易（至少在某些時候）超過了系統可以立即處理的數量。當交易在不可預測的時間（通常抽象為泊松過程）廣播時，或者當新交易的速率在一天或一周內發生變化時，或者響應外部事件（如流行的 NFT 發行）時，擁塞程度可能會有所不同。

共識層差異：在第 1 層確認交易通常需要一組分布式節點才能就區塊達成共識，這可能會增加可變延遲，而不受擁塞的影響。工作量證明系統在不可預測的時間發現塊（也抽象為泊松過程）。權益證明系統還可能增加各種延遲（例如，如果在线節點數量不足，無法在一輪中組成委員會，或者需要更改視圖以響應領導者崩潰）。

由於這些原因，一個好的指南是：

關於延遲的說法應該呈現確認時間的分布（或直方圖），而不是像平均值或中位數這樣的單個數字。

雖然平均值、中位數或百分位數等匯總統計數據提供了部分情況，但准確評估系統需要考慮整個分布。在某些應用程序中，如果延遲分布相對簡單（例如，高斯分布），平均延遲可以提供很好的洞察力。但在加密貨幣中，幾乎從不這樣：通常情況下，確認時間會很長。

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

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

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

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

測量吞吐量的挑战

吞吐量乍一看似乎也很簡單：一個系統每秒可以處理多少交易？出現了兩個主要困難：究竟什么是“交易”，我們是在衡量一個系統今天做了什么，或者它可能能夠做什么？

雖然“每秒交易數”（tps）是衡量區塊鏈性能的事實上的標准，但交易作為衡量單位是有問題的。對於提供通用可編程性（“智能合約”）甚至比特幣的多重交易或多重籤名驗證選項等有限功能的系統，基本問題是：

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

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

將交易層分為共識層和執行層的區塊鏈可以使這一點更加清晰。在（純）共識層，吞吐量可以以每單位時間添加到鏈中的字節數來衡量。執行層總是更復雜。

更簡單的執行層，例如只支持支付交易的rollup服務器，避免了量化計算的困難。但是，即使在這種情況下，支付的輸入和輸出數量也會有所不同。支付通道交易所需的“跳數”數量可能會有所不同，這會影響吞吐量。rollup服務器的吞吐量可能取決於一批交易可以在多大程度上“歸結”為一組較小的匯總更改。

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

整體上：

吞吐量聲明需要仔細解釋交易工作量和驗證者的數量（他們的數量、實施和網絡連接）。在沒有任何明確標准的情況下，來自像以太坊這樣的流行網絡的歷史工作負載就足夠了。

延遲-吞吐量權衡

延遲和吞吐量通常是一種權衡。正如 Lefteris Kokoris-Kogias 所述，這種權衡通常並不順利，當系統負載接近其最大吞吐量時，延遲會急劇增加。

零知識rollup系統提供了吞吐量/延遲權衡的自然示例。大批量交易增加了證明時間，從而增加了延遲。但是，在證明大小和驗證成本方面，鏈上足跡將分攤到更多具有更大批量的交易中，從而提高吞吐量。

交易費用

可以理解的是，最終用戶更關心延遲和費用之間的權衡，而不是延遲和吞吐量。用戶根本沒有直接的理由關心吞吐量，只是他們可以以盡可能低的費用快速確認交易（一些用戶更關心費用，而其他用戶更關心延遲）。總體而言，費用受多種因素影響：

有多少市場需求進行交易？
系統實現的總吞吐量是多少？
該系統為驗證者或礦工提供了多少總收入？
這筆收入中有多少是基於交易費用與通貨膨脹獎勵？

前兩個因素大致是導致市場出清價格的供需曲线（盡管有人聲稱礦工作為卡特爾將費用提高到這一點之上）。在其他條件相同的情況下，更多的吞吐量應該會導致更低的費用，但還有很多事情要做。

特別是上面的第 3 點和第 4 點是區塊鏈系統設計的基本問題，但我們對它們都缺乏好的原則。我們對從通脹獎勵與交易費用中給予礦工收入的優缺點有了一些了解。然而，盡管對區塊鏈共識協議進行了許多經濟分析，我們仍然沒有廣泛接受的模型來確定需要多少收入流向驗證者。今天，大多數系統都建立在有根據的猜測，即有多少收入足以讓驗證者誠實行事，而不會妨礙系統的實際使用。在簡化的模型中，可以顯示發起 51% 攻擊的成本與對驗證者的獎勵成正比。

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

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

結論

公平而准確地評估性能是很困難的。這同樣適用於衡量汽車的性能。就像區塊鏈一樣，不同的人會關心不同的事情。對於汽車，一些用戶會關心最高速度或加速度，其他用戶會關心油耗，還有一些用戶會關心牽引能力。所有這些都不容易求值。例如，在美國，環境保護署就如何評估汽油裏程以及必須如何向經銷商處的用戶提供詳細的指導方針。

區塊鏈領域距離這種標准化水平還有很長的路要走。在某些領域，我們將來可能會通過標准化的工作負載來評估系統的吞吐量或用於呈現延遲分布的標准化圖表。就目前而言，評估者和建設者最好的方法是收集和公布盡可能多的數據，並詳細描述評估方法，以便可以復制並與其他系統進行比較。