如何對區(qū)塊鏈進行全面的性能測量

當一切正常時，您通常不會擔心區(qū)塊鏈測試。我們將在下面解釋為什么最好不要擱置性能評估，使用什么度量標準并充分利用它才是最好的。就讓我們一探究竟吧。

“每秒交易數”（ TPS）

在分布式系統中，TPS是一個非常模糊和反復無常的度量。

TPS測量來自分布式數據庫。它們通常使用標準化的交易類型或集合（例如，一些插入、更新、刪除以及常量選擇數）來執(zhí)行，并針對特定的集群或單獨的機器進行配置。這樣的“綜合”指標并不能反映出所討論的數據庫或區(qū)塊鏈的實際性能，因為在這樣的系統中，交易處理時間可能會有所不同。

面向共識性的數據庫（請參閱“CAP-theorem”）在從其他節(jié)點接收到足夠數量的確認之前不會提交交易——這是很慢的。

面向可用性的數據庫時，如果交易被簡單地寫入磁盤，那么它就是成功的。他們立即提供更新的數據——這是非常快的（盡管這個交易可能在將來回滾）。如果交易只更新一個數據單元，則TPS將更高。如果交易更新許多數據單元（行、索引、文件），它們將彼此阻塞。

這就是為什么我們在Oracle、MSSQL、PostgreSQL和MongoDB、Redis、Tarantool之間看不到任何“TPS競爭”的原因——它們的內部機制和任務差別很大。

在我們看來，“測量區(qū)塊鏈TPS”是指進行全面的性能測量：

a）在可重復的條件下

b）具有接近實際的塊驗證器數量

c）使用不同類型的交易：

-研究區(qū)塊鏈的典型情況（例如，主要加密貨幣的transfer （））

-加載存儲子系統（每個交易都有相當大的變化）

-加載網絡帶寬（大交易大?。?/p>

- cpu加載（大規(guī)模密碼轉換或計算）

要討論我們所珍視的“每秒交易數”，您需要描述所有網絡條件、參數和基準測試邏輯。在區(qū)塊鏈中，將交易應用到某個內部數據庫并不意味著共識會接受它。

在PoW共識中，交易永遠不會最終確定。如果一個交易包含在一臺機器上的一個塊中，這并不意味著它將被整個網絡接受（例如，另一個分叉獲勝的情況）。

如果區(qū)塊鏈有一個額外的算法來確保終結性（如EOS、Ethereum 2.0、Polkadot parachains使用與祖父終結性一共識的方式），那么處理時間可以視為節(jié)點看到交易和下一個完成塊的時間。這樣的TPS是非常有用的，但是因為它們比預期的要低，所以很少見。

TPS涉及到很多東西。保持懷疑，詢問細節(jié)。

Blockchain-specific指標

本地TPS

處理交易的數量和最大/平均/分鐘處理時間（在本地節(jié)點上）是非常方便測量的，因為執(zhí)行這些操作的函數通常用代碼表示。交易處理時間等于更新狀態(tài)數據庫所需的時間。例如，在“樂觀”區(qū)塊鏈中，已處理的交易可能已經經過驗證，但還沒有被一致接受。在這種情況下，節(jié)點將更新后的數據發(fā)送到客戶機（假設不會有任何鏈分叉。

這個度量不是很可靠：如果選擇另一個鏈分支作為主分支，那么關于交易的統計數據也必須回滾。在測試中，這一點常常被忽略。

“我們的區(qū)塊鏈昨天收到了8000個tps”。這些數字通常可以在簡短的項目報告中找到，因為它們很容易測量。只需一個運行節(jié)點和一個加載腳本就足夠了。在這種情況下，沒有網絡延遲會降低達成網絡共識的速度。

該指標反映了狀態(tài)數據庫在不受網絡影響的情況下的性能。這個數字并沒有反映真實的網絡帶寬，但是顯示了如果共識和網絡足夠快，它將努力達到的極限。任何區(qū)塊鏈交易的結果都是多個原子存儲寫。例如，一個比特幣支付交易涉及刪除幾個舊的UTXOs（刪除）和添加新的UTXOs（插入）。在以太坊中，執(zhí)行一個小型智能合約代碼并更新幾個鍵-值對。

原子存儲寫是發(fā)現存儲子系統瓶頸和區(qū)分低級邏輯問題和內部邏輯問題的優(yōu)秀指標。

區(qū)塊鏈節(jié)點可以用幾種編程語言實現——這更可靠。例如，以太坊節(jié)點有Rust和Go實現。在測試網絡性能時請記住這一點。

本地生產的區(qū)塊數量

這個簡單的指標顯示了某個驗證器生成的塊的數量。它依賴于共識，并且對于評估單個驗證者網絡的“有用性”至關重要。

因為驗證器在每個塊上都能賺錢，所以它們負責機器的穩(wěn)定運行和安全。您可以確定哪個驗證器候選是最合格的、受保護的，并且準備好在具有真實用戶資產的公共網絡中工作。公制值可以公開檢查—只需下載區(qū)塊鏈并計算塊的數量。

最后結尾и不可逆轉的塊

終局性確保在區(qū)塊鏈中包含的所有交易都不會回滾，也不會被另一個鏈分叉替換。這是PoS網絡防止雙重消費攻擊和為用戶確認加密貨幣交易的一種方式。

當有一個塊完成包含該交易的鏈時，而不是當某個交易被節(jié)點接受時，用戶認為該交易是最后塊。要完成一個塊，驗證器必須在p2p網絡中接收這個塊并相互交換簽名。這里檢查區(qū)塊鏈的實際速度，因為交易完成的時刻對用戶來說是最重要的。

終結性算法也不同，它會相交并結合主要共識（閱讀：Casper在Ethereum，最后不可逆塊在EOS，外公在奇偶Polkadot和他們的修改，例如，MixBytes RANDPA）。

對于沒有完成所有塊的網絡，一個有用的度量是在最后完成的塊和當前最新的塊之間的延遲。這個數字顯示了驗證器落后了多少，這與正確的鏈一致。如果差距很大，那么最終性算法需要額外的分析和優(yōu)化。

P2P層

點對點子系統——區(qū)塊鏈網絡的中間層——經常被忽略。這都要歸咎于塊交付和驗證器之間交易的模糊延遲。

當確認器的數量很少的時候，它們是本地化的，對等列表是硬編碼的，一切都工作得很好而且很快。但是，就像驗證器存在一樣，節(jié)點在地理上是分布的，丟失的數據是模擬的，我們正面臨嚴重的“tps”故障。

例如，當使用附加的終結性算法測試EOS共識性時，將驗證器的數量增加到80-100臺，分布在四大洲，對終結性幾乎沒有影響。與此同時，增加的包丟失嚴重影響了最終結果，這證明了需要額外的p2p層配置來更好地抵抗網絡包丟失（而不是高延遲）。不幸的是，有許多不同的設置和因素，只有基準測試允許我們了解所需的驗證器數量，并獲得相當舒適的區(qū)塊鏈速度。

p2p子系統的配置從文檔中很清楚，例如，看看［libp2p］、［Kademlia］協議或［BitTorrent］。

重要的p2p指標可以是：

· 進出流量

· 與其他對等點的成功/不成功連接的數量

· 返回先前緩存的數據塊的次數，以及為了找到所需的數據塊需要進一步轉發(fā)請求的次數（緩存命中/丟失模擬數據）

例如，在訪問數據時，較大的遺漏數意味著只有少數節(jié)點擁有請求的數據，而它們沒有時間將這些數據分發(fā)給每個節(jié)點。接收/發(fā)送的p2p通信量允許識別處理網絡配置或通道問題的節(jié)點。

區(qū)塊鏈節(jié)點的系統度量

區(qū)塊鏈節(jié)點的標準系統度量在大量的源代碼中都有描述，因此我們將簡要介紹。它們有助于發(fā)現邏輯瓶頸和錯誤。

中央處理器

CPU顯示處理器執(zhí)行的計算量。如果CPU負載高——節(jié)點正在計算一些東西，積極使用邏輯或FPU（幾乎從未在區(qū)塊鏈中使用）。例如，后一種情況會發(fā)生，因為節(jié)點正在檢查電子簽名、使用強密碼處理事務或進行復雜的計算。

CPU可以被劃分成更多指向代碼瓶頸的指標。例如，系統時間—花在內核代碼上的時間，用戶時間—花在用戶進程上的時間，io—等待來自慢速外部設備（磁盤/網絡）的i/o，等等。

內存

現代區(qū)塊鏈使用鍵值數據庫（LevelDB、RocksDB），這些數據庫不斷地在其內存中存儲“熱”數據。任何加載的服務都會受到由錯誤或針對節(jié)點代碼的攻擊所導致的內存泄漏的影響。如果內存消耗正在增加或急劇增加，很可能是由于大量的狀態(tài)數據庫鍵、大型交易隊列或不同節(jié)點子系統之間的消息量增加造成的。

內存負載不足表明可能會增加塊數據限制或最大化交易復雜性。

響應網絡客戶機的完整節(jié)點依賴于文件緩存指標。當客戶機訪問狀態(tài)數據庫和交易日志的各個部分時，可能會出現磁盤中的舊塊并替換新塊。這反過來又降低了客戶機的響應速度。

網絡

主要的網絡指標是流量的大?。ㄒ宰止?jié)為單位）、發(fā)送和接收網絡數據包的數量、丟包率。這些指標經常被低估，因為區(qū)塊鏈還不能以每秒1 Gbit的速度處理交易。

目前，一些區(qū)塊鏈項目允許用戶共享WiFi或提供存儲和發(fā)送文件或消息的服務。在測試這樣的網絡時，網絡接口流量的數量和質量變得非常重要，因為一個擁擠的網絡通道會影響機器上的所有其他服務。

存儲

磁盤子系統是所有服務中最慢的組件，常常會導致嚴重的性能問題。過多的日志記錄、意外的備份、不方便的讀/寫模式、大量的區(qū)塊鏈卷——所有這些都可能導致顯著的節(jié)點減速或過多的硬件需求。

使用磁盤的區(qū)塊鏈交易日志操作模式類似于使用寫前日志（WAL）的不同DBMS。從技術上講，交易日志可以被看作是狀態(tài)數據庫的WAL。

因此，這些存儲指標非常重要，因為它們可以確定現代鍵值數據庫中的瓶頸。讀取/寫入IOPS數、最大/最小/avg延遲以及許多其他有助于優(yōu)化磁盤操作的指標。

結論

綜上所述，我們可以將度量分為：

· 區(qū)塊鏈節(jié)點度量（產生的塊的數量、處理的事務的數量、處理時間、完成時間等）