Prysm 是優秀的 ETH2.0 的實現，也是目前 Medalla 測試網上執行最多的實現。Prysm 採用 Beacon Chain Node + Validator Node 的架構，前者負責同步區塊資料，後者負責簽名出塊和見證。由於 Validator Node 可同時負載多個驗證人，為了對其可負載驗證人數量以及相關驗證人部署步驟有一個定性和定量的認知，我們特安排此次測試。
測試結論
我們復刻了 Medalla 測試網，搭建 HashQuark 自己的 ETH2.0 Beacon Chain，進行了兩輪測試，一共14個測試用例，跑了數十萬計 Validator。Prsym 的實現非常優秀，對於擁用少量 ETH （幾十到上百個 Validator）想參與以太坊 Staking 的普通使用者而言，一臺4核8G的雲伺服器就能夠平穩地執行 Beacon Chain Node 和 Validator，但執行過程中遇到的技術問題都不是非技術人員的普通使用者能解決的。
對於執行上萬個 Validator 的專業化 PoS 礦池，需要更高的配置才能保證超高出塊率。出塊率會隨著 Validator 數量的增加而減少。
我們接下來會在公開測試網 Medalla 進行下一輪測試，以更貼近主網環境，目前我們已經在 Medalla 正常執行了近3000個 Validator，佔整個網路的5%。
測試環境
我們採用 geth 來搭建私有 ETh2.0 網路，與公開測試網 Rinkeby 或 goerli 一樣，採用 ‘clique’ proof-of-authority 演算法，因為其相比 PoW 對資源需求更少。Prysm 採用測試時的最新的 release 版本。
以下測試採用的雲主機部署，我們選取通用型 N 機型，CPU 平臺為 Intel/Broadwell。系統採用 Ubuntu 18.04.2 LTS。geth 版本為1.9.19-stable，Prysm 版本為 v1.0.0-alpha.24。
第一階段初步嘗試
測試方案
我們先從不同數量的驗證人對伺服器資源的壓力進行簡單測試以獲得基本認知。
採用最基礎的兩臺 ETh2.0 節點 + 兩臺 ETH2.0 Beacon Chain Node + 兩臺 Validator Node 架構搭建私網作為起始嘗試方案。網路穩定執行一天為觀察的時間段。
測試用例
下表為我們進行測試的概覽：
表 1
測試指標
測試過程中我們收集了各個例項伺服器的 CPU、記憶體、磁碟 IO、網路頻寬 IO 等指標。
測試過程
在測試1中，2核4G的 Beacon Chain Node 記憶體階段性上升，在執行約6小時後，記憶體使用率達到100%，導致程序出現記憶體不足錯誤被迫停止，同時 CPU 使用率也逐步提高。如下圖所示：
圖 1
圖 2
之後，我們提升了 Beacon Chain Node 的配置為4核8G。
在例項2-5中，依次提升驗證者數量1k-10k來觀察伺服器 CPU、記憶體、磁碟 IO、頻寬等指標資料，均無壓力，也沒有異常。
之後我們在不同地區部署 ETH2.0 節點，來觀察不同地區的網路互聯情況是否會對各指標產生較大影響，實驗結果均無異常。
測試小結
根據私網測試情況來看，Beacon Chain Node 建議4核8G配置，Validator 節點2核4G的配置夠用，但是在匯入 key 檔案時會佔用1核 CPU，該 CPU 佔用率為100%（如下圖所示），穩妥起見，建議 4C6G 的配置。
圖 3
此外，在本階段的測試中，對磁碟的 I/O 效能和外網頻寬要求很低，可能是由於私網的原因，具體的對應的效能要求還需要在 ETH2.0 官方測試網中進行測試。
第二階段對比測試
測試方案
第一階段主要測試了不同數量的驗證人對於伺服器資源的壓力，此外，驗證者的出塊和見證也是也是對於驗證人很重要的指標。為此我們進行了對比測試。在同一個網路中，將不同數量的驗證人部署在不同的地區來進行對比測試。
測試指標
測試過程中我們將收集各個例項伺服器的 CPU、記憶體、磁碟 IO、網路頻寬 IO、應出的塊數、實際出塊數、應該見證的塊數、實際見證的塊數等指標。
測試用例
以下為我們的測試用例：
表 2
ETh2.0 網路由三臺2核4G雲伺服器組成，兩臺位於香港，一臺位於聖保羅。出塊時間設定為15s。
我們分別在香港、新加坡、洛杉磯、法蘭克福、聖保羅、倫敦六個地區部署了 Beacon Chain Node 和 Validator Node。各個地區的 Beacon Chain Node 和 Validator Node 透過內網連線。配置和相應的驗證人數量如上圖。
例項1和例項2都是1k驗證人，區別在於 Validator Node 的配置，用於對比不同配置的驗證人數量對指標的影響。
例項3,4,5,6增加了驗證人數量。鑑於實際情況下我們不太可能將超過10k的驗證人置於單臺機器上，因此我們將測試數量停在了20k。
各個地區的 Beacon Chain Node 與其餘 node 相連。
測試網引數選擇
我們先在 ETh2.0 網路上部署了 deposit 合約，生成所需數量的驗證人金鑰後，批次傳送了存款交易。Prysm 啟動時修改了以下引數:
MinGenesisActiveValidatorCount 設定為8192，由於我們的測試中包含了40k驗證人，所以能夠滿足；
Eth2FollowDistance 設定為20，也就是 ETh2.0 網路上的存款合約在5分鐘後會被ETH2.0網路監測到；
SecondsPerETh2Block 設定為 15，這與 ETh2.0 網路每個塊時間設定的一致；
MinGenesisTime 設定為1599811200，也就是說最早在2020-09-11T16:00:00+08:00啟動。
實際上，由於我們事先傳送了所有的存款交易，滿足最早啟動時間設定的最小驗證人數量，整個 ETH2.0 網路在1599811207(2020-09-11T16:00:07+08:00)啟動。
資料統計和測試結果
我們額外部署了一個 Beacon Chain Node 來連線到 ETH2.0 私有網路，來查詢資料。加上--slots-per-archive-point=1 的引數來持久化儲存每個區塊的資料，從而加快查詢速度。加上--rpc-max-page-size=1000的引數，使得我們每次可以查詢更多的資料，從而減少請求次數加快總體速度。
我們選取了網路相對穩定的一段時間 ，從75 epoch（大約2020-09-12 00:00:00 +0800）到1200 epoch（2020-09-17 00:00:00 +0800）取樣，獲取這段時間內處於不同例項中驗證者的出塊和見證的資料加以分析，得出如下結果:
所有驗證人都成功出塊，無漏塊情況；
不同地區的驗證者見證情況略有差異：
表 3
這裡我們定義見證率為在一段時間內被包含的見證數除以被分配到見證數。不難看出，總體來說，隨著驗證人數量的上升，見證率會下降。但在例項3中，雖然驗證人只有2k，但見證率卻比6k甚至10k的見證率都要低。
為了探究導致例項3總體見證率異常的原因，我們統計每個例項裡驗證者的見證率加以分析，看是否由於個別驗證者出了問題拉低總體比例。
我們將每個驗證者比例按照範圍劃分，得到以下資料：
表 4
由於各個例項驗證人數量不同，換算成比例會更加直觀：
表 5
可以看到，例項3中大多數驗證人的見證率都不高，這也意味著例項3應該出了問題。
為此，我們檢查了例項3的日誌，發現 Beacon Chain Node 與其它節點以及 ETh2.0 的連線並不穩定，猜測是由此導致了見證率的異常，有待後續檢驗。
伺服器壓力
在本輪測試中，我們觀察到如下表的效能指標資料：
表 6
- Beacon Chain Node
例項1-5中，Beacon Chain Node 的 CPU 使用率在5%-10%之間，例項6的 Beacon Chain Node 的 CPU 使用率約為12%。記憶體方面呈現平穩增加，在12%-17%之間，磁碟IO與頻寬無明顯差異。
- Validator Node
隨著驗證者數量的增加，Validator Node 的各項指標均平穩增多，可以看到，磁碟IO與頻寬基本上正比於驗證者的數量。
此外，生成驗證者金鑰檔案方面，我們採用的是一個推薦的python命令後工具(https://github.com/ethereum/eth2.0-deposit-cli)，該工具生成金鑰的效率相對不高，在多核的機器上只佔用1核，生成2000個金鑰對需要2.5小時左右。另一方面，Validator Node 匯入金鑰對也是單核執行，匯入2000個金鑰對的時間大約為40分鐘。
測試小結
透過本輪測試，我們在私有網路中觀察到，驗證人數量的增加會影響節點上所有驗證人的出塊率，對於單個驗證人來說，在最好的情況和最壞的情況下，平均每天少見證約10個塊。出塊方面在我們的測試中並未發現不同。記憶體與磁碟 IO 的使用率相對於 CPU 和頻寬，更加明顯地隨著驗證人數量的增加而提升。
後續測試方案和待最佳化步驟
在本輪測試中，以下幾方面佔據較多的準備時間：
驗證者金鑰對生成
部署 deposit 合約
Validator Node 匯入金鑰對
在後續方案中，計劃對上述步驟採取最佳化，提高測試效率。
此外，在後續測試計劃中，考慮到不同地區的網路之間的穩定性及其對驗證人指標的影響，可以考慮以下幾點改進：
在同一地區增加多個測試例項，來對比是否為地區造成的差異；
部署多個 ETh2.0 節點，使 Beacon Chain Node 能夠暢通連線 ETh2.0 網路，減少造成的影響；
增加單獨同一地區對比測試，增加驗證者數量，控制變數，單純比較驗證者數量的影響。
在統計資料方面，考慮增加更多維度，如考慮到見證被包含的距離等，可參考這篇關於見證效率（https://www.attestant.io/posts/defining-attestation-effectiveness/）的文章。
測試問題彙總
GRPC 資料量超過預設大小
當增加到近4k驗證人時，Validator Node 會報錯 grpc 獲取的訊息大小5350532(5M)超過最大值4194304（4M）。
圖 4
解決方案：啟動 Validator Node 時透過--grpc-max-msg-size 引數將 grpc 允許的訊息大小適量調大。
Beacon chain node 無法同步
進行第一輪測試時，在網路中只存在兩個 Beacon Chain Node 的情況下，容易出現兩個節點之間無法同步區塊的問題，兩個節點都不認為對方是合適的 peers。如下圖所示：
圖 5
解決方案：我們目前採用清除節點的資料重新同步來解決。測試中我們發現，隨著 Beacon Chain 節點的數量增多，該問題便不再發生。
存款金額誤報不夠
如發生下述計算 activeEpoch 過大或存款金額不夠而實際已夠的情況，則表示 Prysm 實現存在問題，參考這個issue(https://security.feishu.cn/link/safety?target=https://github.com/prysmaticlabs/prysm/pull/7138&lang=en-US&scene=messenger&logParams={"location":"messenger"})，該問題已在編寫本報告的最新版本修復。
圖 6
