基於最新的性能指標比較以太坊 2.0 主網上 5 個主要客戶端。

原文標題:《以太坊 2.0 主網客戶端性能比較》
撰文:Afri Schoedon
翻譯:ETH 中文站

2020 年 12 月以太坊 2.0 信標鏈發佈之後,現在是時候介紹以及比較現有的協議實現了。本文作爲該系列文章的第一部分,將按照字母排序比較 5 個主要客戶端的信標鏈節點性能和資源利用率。

  • Lighthouse (Rust, Sigma Prime)

  • Lodestar (TypeScript, ChainSafe Systems)

  • Nimbus (Nim, Status)

  • Prysm (Go, Prysmatic Labs)

  • Teku (Java, ConsenSys Quorum)

以太坊 2.0 主網基礎設施由三個主要組件組成:

  • 信標鏈是 PoS (權益證明) 鏈。當前的以太坊 1.x 鏈 (共識爲 PoW) 與以太坊 2.0 合併之後,信標鏈將成爲保障以太坊安全的主幹網。

  • 驗證就好比 PoS 共識中的礦工。所有人都可以質押 32 ETH 成爲驗證者,有權提議新區塊、對區塊敲定進行投票,然後獲得獎勵。

  • 罰沒者正監視驗證者是否作惡,以防攻擊事件發生。任何一名驗證者違反規則,都會受到懲罰並被移出網絡。

需要注意的是,本文主要關注第一點,信標鏈是以太坊 2.0 網絡的基礎。研究人員可以在 Github 上找到所有相關的腳本、數據和繪圖,以便進一步分析:

byz-f / eth2-bench-mainnet

本文將重點列出這些發現👇

同步指標

第一個也是最令人興奮的問題:同步以太坊 2.0 信標鏈節點信息需要多長時間,結果見下圖。

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

在上表中,通過比較客戶端同步相同的 slot 需要花多少時間來比較其同步進程。在評選結果之前 (雖然這不是本文的討論範圍),關於該圖表我們需要知道三件事。

1. Prysm (紫色線) 有個特殊的地方是,它會連接以太坊 1.x 節點,從驗證者信息登記處獲取所有 ETH 存款,然後從 Eth1 狀態下構建 Eth2 創世。雖然從安全的角度來看,這一特性蠻有用的,因爲用戶不必信任 Prysm 的開發者以獲得正確的創世狀態,但是這一過程需要些時間。因此,客戶端啓動與同步啓動的時間有明顯的偏移。(#8209)。

2. 由於出現 JavaScript 堆內存不足的問題,在基準測試時 Lodestar (灰色線) 出現了崩潰 (#2005)。但是,它在 10 秒後由腳本自動重啓。

3. 不可見:在初始同步時,Loderstar 還沒有完全驗證所有簽名 (#1217)。因此,目前尚不清楚 Loderstar 與其他客戶端的比較情況。

上面的圖表中,我們可以看到 Lighthouse (橙色線) 整體表現出色,Prysm、Teku (綠色線) 和 Nimbus (藍色線) 在保持速度方面表現出色。但是,讓我們再來看看下面的圖表:

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

在這個圖表中,我們把 Prysm 客戶端啓動和同步啓動 (即第一個信標鏈區塊產生) 之間的時間偏移刪去。那麼可以看出,單純比較同步速度的話,Prysm 的表現略優於 Lighthouse,不到兩個小時就能同步完成,而 Lighthouse 需要兩個半小時。Teku 和 Nimbus 大概需要五個小時。

值得注意的是,Eth2 TypeScript 實現 (Lodestar 使用的語言) 並不是僅爲了成爲運行一個全信標鏈或者驗證者節點的首選客戶端。相反,Lodestar 將爲以太坊 2.0 去中心化應用的所有 web、瀏覽器和基於插件的組件提供基礎設施。

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

假設我們知道了客戶端的信標頭區塊當前所在的 slot 高度,並且可以查看在這 60 秒之前區塊頭的高度的話,我們就可以通過展示各客戶端每秒同步的 slot 數 (用點表示),來計算過去 60 秒的移動平均值以比較各客戶端的同步速度。移動平均值超過 10 分鐘的則用實線表示。

結果與前一個圖表一致。儘管 Prysm 因爲要花時間獲取 Eth1-狀態,它仍是同步速度最快的客戶端,每秒同步 60 slots。Lighthouse 緊跟其後,每秒同步 46 slots。稍顯落後的是 Teku (23/ 秒) 和 Nimbus (22/ 秒)。

然而什麼是 slot 呢?在傳統的區塊鏈如比特幣和 Eth1 鏈中,要麼有區塊要麼沒有。那麼當比較這些鏈上的客戶端性能時,我們會以塊數 / 秒爲單位來比較其同步速度。這跟以 slot 數 / 秒 爲單位有何不同呢?

在以太坊 2.0 中,每 12 秒總有一個指定的 slot。如果驗證者被分配到一個 slot 中提議區塊,該 slot 便有一個區塊。然而,如果驗證者錯過該 slot,那麼便是個空 slot (沒有區塊),但儘管如此,slot 的計數將繼續進行。因此,在以太坊 2.0 中,我們以 slots/ 秒 爲單位計算同步速度。

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

在這個圖表中,我們把 (時間) 這一變量刪去,橫座標爲已同步的 slot 數,並把上一個圖表中的同步速度映射到該圖表中。所有客戶端都顯示一個趨勢:隨着 slot 的增加同步速度下降。由於該數據是在以太坊 2.0 主網上搜集的,我們知道有一條驗證者隊列正排隊等候進入 2.0 網絡。在撰寫本文時,等候隊列上有 13_458 名驗證者,按照每天新增 900 名驗證者的速度來算,需要等待將近 15 天。

瞭解了以太坊 2.0 主網驗證者數量呈線性增長之後,我們可以假設活躍驗證者集的規模變大使得同步速度減緩。

計算資源指標

在上半部分中,我們僅分析了同步指標,選出同步最快的客戶端。但是哪個客戶端在資源利用方面快且高效呢?

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

上面的圖表中,隨着同步 slot 的數量增加,比較各客戶端的數據庫容量。值得注意的是,關於完全同步主網節點 (420_000 slots),Lodestar 的佔用空間最小,總共只有 1.49 GiB。Lighthouse (2.98 GiB) 和 Prysm (3.16 GiB) 的結果也不錯。

我們知道 Eth1 節點存儲完整的區塊歷史數據。儘管如此,Eth1 節點還是移除了歷史狀態以最小化數據庫所需的磁盤空間。Eth2 節點與這個概念相當。在磁盤上儲存所有塊的同時,他們會刪除最終狀態。兩者的主要區別爲:爲了方便起見,應將歷史狀態存儲於時段邊界中 (epoch boundaries)。目前,Nimbus 每 32 個 epoch 在時段邊界存儲狀態,然而 Lodestar 每 1024 個 epoch 將狀態記錄在磁盤中。在圖中可以清楚地看出差異。

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

該圖表相同,但是繪製了同步期間每個客戶端的常駐內存集的大小。從圖中得出,Nimbus 客戶端非常高效,在信標鏈主網的整個處理過程僅需要約 1 GiB RAM。緊接其後的是 Lighthouse 和 Lodestar,均略低於 3 GiB。

注意:Java 分配給 Teku 的堆外內存不在客戶端開發者的控制範圍之內。JVM 對可用內存的消耗量特別大。Teku 的指標結果在可用內存總量不同的情況下差異十分大。

主要以太坊 2.0 客戶端性能如何?從同步速度和計算資源維度比較

最後但同樣重要的一點是,讓我們看一下 CPU 的利用率。在上面圖表中可以看到客戶端之間的一些有趣差異。

區塊鏈屬於一種高度分層的數據結構。同步區塊鏈數據、驗證區塊以及計算最新狀態,大部分工作都是按序列進行的。因此,客戶端面臨的挑戰便是儘可能地使該進程平行化。圖表顯示的結果與同步速度指標相當,Prysm 和 Lighthouse 領先 (數值更高意味着更加有效),而 Teku 保持良好。


FAQ

Q:文章不錯,但請問爲什麼你沒有比較流量指標呢?

A:我有比較,只是沒有對所有指標比較都進行評論。你可以在 Github 上找到沒有進行註釋的點對點、流量指標,想要進一步研究的話 訪問

Q:你個人來說推薦哪個客戶端?

A:這個問題很難回答。靠感覺走的話,我選擇 Lighthouse,我覺得它的總體用戶體驗、性能、功能以及工具可用性都很好。然而,Prysm 仍是最成熟並且是目前最快的客戶端。Teku 的使用體驗也很好,我認爲所有客戶端都是產品級別的。

Q:信標鏈數據庫大小會超過 1 TiB 嗎?

不,首先,與 Eth1 相比,信標鏈本身相對較小。驅動數據庫大小的主要因素是信標狀態。然而,與 Eth1 相比,Eth2 並不需要將所有狀態存儲在磁盤中,因爲用戶總是可以從本地運行的區塊中重建任何狀態。

除此之外,PoS 有敲定這一工序,而 PoW 沒有 (reorgs, 51% 攻擊)。一旦區塊被敲定,該區塊永遠不會被篡改。敲定的意思是,將來客戶端不用再從創世開始同步鏈的數據,而是獲取最後敲定的 epoch 的最新鏈頭的數據。

來源鏈接:dev.to