對於任何分散式系統，非技術人員最喜歡問的問題是“您的區塊鏈上有多少 tps？” 然而，答案中給出的數字通常與提問者希望聽到的數字沒有什麼共同點。 事實上，他想問“你的區塊鏈能滿足我的業務需求嗎”，而這些需求不是一個數字，而是很多條件——這裡有網路容錯性、最終性要求、規模、交易性質和許多其他參數。 因此，「多少 tps」這個問題的答案不太可能簡單，而且幾乎永遠不會完整。 具有數十或數百個節點執行相當複雜計算的分散式系統可能處於與網路狀態、區塊鏈內容、技術故障、經濟問題、網路攻擊和許多其他原因相關的大量不同狀態。 可能出現效能問題的階段與傳統服務不同，區塊鏈網路伺服器是一種結合了資料庫、Web 伺服器和 torrent 用戶端功能的網路服務，這使得它在所有子系統的負載情況方面極為複雜：處理器、記憶體、網路、儲存
碰巧，對於中心化軟體開發人員來說，去中心化網路和區塊鏈是非常具體且不尋常的軟體。 因此，我想強調去中心化網路的效能和永續性的重要方面，以及衡量它們和尋找瓶頸的方法。 我們將研究限制向區塊鏈用戶提供服務的速度的各種效能問題，並注意此類軟體的功能特徵。
區塊鏈客戶端的服務請求的階段
為了誠實地談論任何或多或少複雜的服務的質量，您不僅需要考慮平均值，還需要考慮最大值/最小值、中位數、百分位數。 理論上，我們可以在某些區塊鏈中談論1000 tps，但是如果900 筆交易以極快的速度完成，並且100 筆交易「卡住」了幾秒鐘，那麼所有交易收集的平均時間對於客戶端來說並不是一個完全公平的指標我無法在幾秒鐘內完成交易。 由於錯過共識回合或網路分裂而導致的臨時「漏洞」可能會極大破壞在測試平台上表現出出色效能的服務。
為了識別此類瓶頸，有必要充分了解真正的區塊鏈可能難以為用戶服務的階段。 讓我們描述一下交付和處理交易以及獲取區塊鏈的新狀態的周期，客戶端可以從中驗證他的交易是否已被處理和記帳。
- 交易在客戶端形成
- 交易在客戶端簽名
- 客戶端選擇其中一個節點並向其發送交易
- 客戶端訂閱節點狀態資料庫的更新，等待其交易結果出現
- 節點透過 p2p 網路分發交易
- 多個或一個 BP（區塊生產者）處理累積的交易，更新狀態資料庫
- BP處理完所需數量的交易後形成一個新的區塊
- BP 透過 p2p 網路分發新區塊
- 新區塊被傳送到客戶端正在存取的節點
- 節點更新狀態資料庫
- 節點看到有關客戶端的更新並向他發送事務通知
現在讓我們仔細看看這些階段並描述每個階段潛在的效能問題。 與集中式系統不同，我們還將考慮在網路用戶端上執行程式碼。 通常，在測量 TPS 時，交易處理時間是從節點收集的，而不是從客戶端收集的 - 這並不完全公平。 客戶並不關心節點處理他的交易的速度有多快；對他來說最重要的是他可以獲得區塊鏈中包含的有關該交易的可靠資訊的那一刻。 這個指標本質上就是交易執行時間。 這意味著不同的客戶端，即使發送相同的交易，也可能收到完全不同的時間，這取決於節點的通道、負載和鄰近度等。 因此絕對有必要在客戶端上測量這個時間，因為這是需要最佳化的參數。
在客戶端準備交易
讓我們從前兩點開始：交易由客戶端形成並簽署。 奇怪的是，從客戶端的角度來看，這也可能是區塊鏈效能的瓶頸。 這對於中心化服務來說是不尋常的，中心化服務接管了所有與資料相關的計算和操作，客戶端只需準備一個簡短的請求，就可以請求大量的資料或計算，從而獲得現成的結果。 在區塊鏈中，客戶端程式碼變得越來越強大，區塊鏈核心變得越來越輕量級，海量運算任務通常轉移到客戶端軟體。 在區塊鏈中，有些客戶可以準備一筆交易相當長的時間（我指的是客戶端的各種梅克爾證明、簡潔證明、閾值簽名和其他複雜操作）。 簡單的鏈上驗證和客戶端交易的繁重準備的一個很好的例子是基於 Merkle-tree 的列表中的成員資格證明，此處 .
另外，不要忘記客戶端程式碼並不是簡單地將交易發送到區塊鏈，而是先查詢區塊鏈的狀態 - 而此活動可能會影響網路和區塊鏈節點的擁塞。 因此，在進行測量時，盡可能完整地模擬客戶端程式碼的行為是合理的。 即使你的區塊鏈裡有普通的輕客戶端，在最簡單的交易上打上常規的數位簽名來轉移一些資產，每年客戶端上的海量計算仍然越來越多，加密演算法越來越強大，這部分處理可以成為未來的重要瓶頸。 因此，請注意，不要錯過這樣的情況：在一個持續 3.5 秒的交易中，2.5 秒用於準備和簽署交易，1.0 秒用於將交易發送到網路並等待回應。 要評估此瓶頸的風險，您需要從客戶端電腦收集指標，而不僅僅是從區塊鏈節點收集指標。
發送交易並監控其狀態
下一步是將交易發送到選定的區塊鏈節點並接收接受其進入交易池的狀態。 此階段類似於常規資料庫存取；節點必須將交易記錄在池中，並開始透過 p2p 網路分發有關該交易的資訊。 這裡評估效能的方法類似於評估傳統Web API微服務的效能，區塊鏈中的交易本身可以更新並主動改變其狀態。 一般來說，更新某些區塊鏈上的交易資訊可能會發生多次，例如在鏈分叉之間切換時或當 BP 宣布打算將交易包含在區塊中時。 該池的大小和其中的交易數量的限制可能會影響區塊鏈的性能。 如果事務池被填滿到最大可能的大小，或者記憶體無法容納，網路效能可能會急劇下降。 區塊鏈沒有集中的手段來防止大量垃圾訊息，如果區塊鏈支援大容量交易和低費用，這可能會導致交易池溢出——另一個潛在的效能瓶頸。
在區塊鏈中，客戶端向他喜歡的任何區塊鏈節點發送交易，交易的哈希值通常在發送之前客戶端就已知，因此他所需要做的就是實現連接，傳輸後等待區塊鏈發生變化它的狀態，使他的交易成為可能。 請注意，透過測量“tps”，對於連接區塊鏈節點的不同方法，您可以獲得完全不同的結果。 這可以是常規的 HTTP RPC 或允許您實作「訂閱」模式的 WebSocket。 在第二種情況下，客戶端會更早收到通知，節點會花費更少的資源（主要是記憶體和流量）來回應交易狀態。 因此，在測量“tps”時，有必要考慮客戶端連接到節點的方式。 因此，為了評估這一瓶頸的風險，基準區塊鏈必須能夠按照與真實網路相對應的比例模擬具有 WebSocket 和 HTTP RPC 請求的客戶端，並改變交易的性質及其大小。
要評估此瓶頸的風險，您還需要從客戶端電腦收集指標，而不僅僅是從區塊鏈節點收集指標。
透過 p2p 網路傳輸交易和區塊
在區塊鏈中，點對點（p2p）網路用於在參與者之間傳輸交易和區塊。 交易從一個節點開始傳播到整個網絡，直到到達對等區塊生產者，後者將交易打包到區塊中，並使用相同的 p2p 將新區塊分發到所有網路節點。 大多數現代 p2p 網路的基礎是 Kademlia 協定的各種修改。 該協議的一個很好的總結，以及 - 一篇對 BitTorrent 網路進行各種測量的文章，從中可以了解到這種類型的網路比集中式服務的嚴格配置的網路更複雜且更難以預測。 還， 關於測量以太坊節點的各種有趣指標的文章。
簡而言之，此類網路中的每個對等點都維護自己的其他對等點的動態列表，從這些對等點請求按內容尋址的資訊區塊。 當對等點收到請求時，它要么提供必要的信息，要么將請求傳遞給列表中的下一個偽隨機對等點，並在收到響應後將其傳遞給請求者並緩存一段時間，給出此下次早一點資訊塊。 這樣，流行的資訊最終會被大量節點的大量緩存，而不流行的資訊會逐漸被取代。 同行記錄了誰向誰傳輸了多少信息，並且網絡試圖通過提高活躍的分發者的評級並為他們提供更高水平的服務來刺激活躍的分發者，自動將不活躍的參與者從同行列表中取代。
因此，交易現在需要分佈在整個網路中，以便區塊生產者可以看到它並將其包含在區塊中。 節點主動向所有人「分發」新交易，並監聽網絡，等待索引中出現所需交易的區塊，以通知等待的客戶端。 網路在 p2p 網路中相互傳輸有關新交易和區塊的資訊所需的時間取決於許多因素：附近工作的誠實節點的數量（從網路的角度來看）、「熱節點」的數量。這些節點的快取、區塊的大小、交易、變化的性質、網路地理、節點數量和許多其他因素。 在此類網路中對效能指標進行複雜的測量是一件複雜的事情；有必要同時評估客戶端和對等點（區塊鏈節點）上的請求處理時間。 任何一個p2p機制出現問題，不正確的資料驅逐和緩存，對活躍節點列表的無效管理等許多因素都可能導致延遲，影響整個網路的整體效率，而這個瓶頸是最難分析的、測試和結果解釋。
區塊鏈處理和狀態資料庫更新
區塊鏈最重要的部分是共識演算法、其對從網路接收的新區塊的應用以及交易處理並將結果記錄在狀態資料庫中。 向鏈添加新區塊然後選擇主鏈應該盡快進行。 然而，在現實生活中，“應該”並不意味著“有效”，例如，我們可以想像這樣一種情況：兩條長的競爭鏈不斷地在自身之間切換，每次切換都會更改池中數千筆交易的元數據，不斷回滾狀態資料庫。 這個階段，就定義瓶頸而言，比p2p網路層更簡單，因為交易執行和共識演算法是嚴格確定性的，在這裡更容易測量任何東西。
最主要的是不要將此階段性能的隨機下降與網絡問題混淆- 節點傳遞塊和有關主鏈的信息的速度較慢，對於外部客戶端來說，這可能看起來像一個緩慢的網絡，儘管問題在於一個完全不同的地方。
為了優化此階段的效能，從節點本身收集和監控指標非常有用，並將與更新狀態資料庫相關的指標包含在其中：節點上處理的區塊數量、大小、交易數量、鏈分叉之間的切換次數、無效區塊的數量、虛擬機器運作時間、資料提交時間等。 這將防止網路問題與鏈處理演算法中的錯誤混淆。
處理交易的虛擬機器可以成為可以優化區塊鏈操作的有用資訊來源。 記憶體分配數量、讀取/寫入指令數量以及其他與合約程式碼執行效率相關的指標可以為開發人員提供許多有用的信息。 同時，智能合約是程序，這意味著理論上它們可以消耗任何資源：CPU/內存/網絡/存儲，因此交易處理是一個相當不確定的階段，此外，在版本之間移動時，它會發生很大的變化以及更改合約代碼時。 因此，還需要與交易處理相關的指標來有效優化區塊鏈效能。
客戶收到將交易納入區塊鏈的通知
這是區塊鏈客戶端接收服務的最後階段；與其他階段相比，沒有很大的開銷成本，但仍然值得考慮客戶端從節點接收大量回應的可能性（例如，智能合約）返回資料數組） 。 無論如何，這一點對於提出「你的區塊鏈中有多少 tps？」這個問題的人來說是最重要的，因為此時，記錄了接受服務的時間。
在這個地方，總是有一個客戶端必須花費整個時間來等待區塊鏈響應的發送；正是這個時間，用戶將在他的應用程式中等待確認，這就是它的優化開發人員的主要任務。
結論
因此，我們可以描述在區塊鏈上執行的操作類型並將其分為幾類：
- 密碼轉換、證明構造
- 點對點網路、交易和區塊複製
- 交易處理、智能合約執行
- 將區塊鏈中的變更應用到狀態資料庫，更新交易和區塊的數據
- 對狀態資料庫、區塊鏈節點 API、訂閱服務的唯讀請求
總的來說，現代區塊鏈節點的技術要求極為嚴格——用於密碼學的快速CPU、用於儲存和快速存取狀態資料庫的大量RAM、使用大量同時開啟的連接的網路互動以及大儲存。 如此高的要求和豐富的不同類型的操作不可避免地導致節點可能沒有足夠的資源，然後上面討論的任何階段都可能成為整體網路效能的另一個瓶頸。
在設計和評估區塊鏈的性能時，您必須考慮所有這些要點。 為此，您需要同時從客戶端和網路節點收集和分析指標，尋找它們之間的相關性，估計為客戶端提供服務所需的時間，考慮所有主要資源：CPU/記憶體/網路/存儲，了解它們如何使用以及如何相互影響。 所有這些使得以「多少 TPS」的形式比較不同區塊鏈的速度成為一項極其吃力不討好的任務，因為存在大量不同的配置和狀態。 在大型中心化系統中，數百台伺服器的叢集中，這些問題也很複雜，也需要收集大量不同的指標，但在區塊鏈中，由於p2p網路、虛擬機器處理合約、內部經濟、度數自由度大得多，這使得即使在多個伺服器上進行測試，它也是非指示性的，僅顯示與現實幾乎沒有聯繫的極其近似的值。
因此，在區塊鏈核心開發時，為了評估效能並回答「與上次相比是否有所改進？」的問題，我們使用相當複雜的軟體來協調具有數十個節點的區塊鏈的啟動，並自動啟動基準測試並收集指標；如果沒有這些信息，調試與多個參與者一起使用的協議將極其困難。
因此，當您收到「您的區塊鏈中有多少TPS？」的問題時，請為您的對話者提供一些茶，並詢問他是否準備好查看十幾個圖表，並聽取區塊鏈性能問題的所有三個框以及您的建議解決他們...
來源： www.habr.com