我們在以太坊2.0測試網運行了近3000個Validator
編者按：本文來自HashQuark社區（ID：HashQuarkPool），Odaily經授權轉載。
二級標題
二級標題
我們復刻了Medalla 測試網，搭建HashQuark 自己的ETH2.0 Beacon Chain，進行了兩輪測試，一共14 個測試用例，跑了數十萬計Validator。 Prsym 的實現非常優秀，對於擁用少量ETH （幾十到上百個Validator）想參與以太坊Staking 的普通用戶而言，一台4 核8G 的雲服務器就能夠平穩地運行Beacon Chain Node 和Validator，但運行過程中遇到的技術問題都不是非技術人員的普通用戶能解決的。
對於運行上萬個Validator 的專業化PoS 礦池，需要更高的配置才能保證超高出塊率。出塊率會隨著Validator 數量的增加而減少。
二級標題
二級標題
二級標題
以下測試採用的雲主機部署，我們選取通用型N 機型，CPU 平台為Intel/Broadwell。系統採用Ubuntu 18.04.2 LTS。 geth 版本為1.9.19-stable，Prysm 版本為v1.0.0-alpha.24。
二級標題
二級標題
二級標題
二級標題
二級標題
二級標題
表 1
二級標題
二級標題
二級標題
在測試1 中，2 核4G 的Beacon Chain Node 內存階段性上升，在運行約6 小時後，內存使用率達到100%，導致進程出現內存不足錯誤被迫停止，同時CPU 使用率也逐步提高。如下圖所示：
圖片描述
圖片描述
圖片描述
圖 2
二級標題
二級標題
圖片描述
圖片描述
此外，在本階段的測試中，對磁盤的I/O 性能和外網帶寬要求很低，可能是由於私網的原因，具體的對應的性能要求還需要在ETH2.0 官方測試網中進行測試。
二級標題
二級標題
二級標題
二級標題
二級標題
二級標題
圖片描述
圖片描述
表 2
表 2
ETH1.0 網絡由三台2 核4G 雲服務器組成，兩台位於香港，一台位於聖保羅。出塊時間設置為15s。
我們分別在香港、新加坡、洛杉磯、法蘭克福、聖保羅、倫敦六個地區部署了Beacon Chain Node 和Validator Node。各個地區的Beacon Chain Node 和Validator Node 通過內網連接。配置和相應的驗證人數量如上圖。
二級標題
二級標題
二級標題
測試網參數選擇
我們先在ETH1.0 網絡上部署了deposit 合約，生成所需數量的驗證人密鑰後，批量發送了存款交易。 Prysm 啟動時修改了以下參數 :
MinGenesisActiveValidatorCount 設置為8192，由於我們的測試中包含了40k 驗證人，所以能夠滿足；
Eth1FollowDistance 設置為20，也就是ETH1.0 網絡上的存款合約在5 分鐘後會被ETH2.0 網絡監測到；
二級標題
二級標題
二級標題
數據統計和測試結果
我們額外部署了一個Beacon Chain Node 來連接到ETH2.0 私有網絡，來查詢數據。加上--slots-per-archive-point=1 的參數來持久化存儲每個區塊的數據，從而加快查詢速度。加上--rpc-max-page-size=1000 的參數，使得我們每次可以查詢更多的數據，從而減少請求次數加快總體速度。
圖片描述
圖片描述
表 3
表 3
圖片描述
圖片描述
圖片描述
圖片描述
表 5
二級標題
二級標題
圖片描述
圖片描述
Beacon Chain Node
表 6
Validator Node
表 6
此外，生成驗證者密鑰文件方面，我們採用的是一個推薦的python 命令行工具二級標題
二級標題
二級標題
二級標題
二級標題
後續測試方案和待優化步驟
在本輪測試中，以下幾方面佔據較多的準備時間：
驗證者密鑰對生成
部署deposit 合約
Validator Node 導入密鑰對
在後續方案中，計劃對上述步驟採取優化，提高測試效率。
此外，在後續測試計劃中，考慮到不同地區的網絡之間的穩定性及其對驗證人指標的影響，可以考慮以下幾點改進：
在同一地區增加多個測試實例，來對比是否為地區造成的差異；
部署多個ETH1.0 節點，使Beacon Chain Node 能夠暢通連接ETH1.0 網絡，減少造成的影響；增加單獨同一地區對比測試，增加驗證者數量，控制變量，單純比較驗證者數量的影響。一級標題
一級標題
一級標題
圖片描述
圖片描述
圖片描述
圖 4
圖片描述
圖片描述
圖片描述
圖 5
解決方案：我們目前採用清除節點的數據重新同步來解決。測試中我們發現，隨著Beacon Chain 節點的數量增多，該問題便不再發生。issue圖片描述
圖片描述
