這篇「以太坊礦池構建指南」來自 Dragonfly Capital 研究合夥人 Ivan Bogatyy 構建 MiningDAO.io 礦池的第一手經驗,並概述瞭如何將叔塊率降低的方法。

撰文:Ivan Bogatyy,區塊鏈投資機構 Dragonfly Capital 研究合夥人
編譯:Perry Wang

礦池是以太坊生態系統中的主要力量。隨着礦工可提取價值(MEV)呈指數級增長,EIP-1559 升級以及即將到來的合併,礦池已成爲生態系統中更重要、更有發言權的參與者。

給萌新解釋一下:礦池是軟件提供商,使許多礦機能夠匯聚其挖礦能力並分享獎勵。從兩個層面上看,礦池在基於工作量證明(PoW)共識機制的挖礦中是必不可少的:

  • 首先,因爲個體礦工的收入波動會很大;
  • 其次,因爲圍繞挖礦構建軟件基礎設施的難度越來越高。通過資源的集中,個體礦工可以降低收入變動,因此擁有可預測性更強的業務運營。

但是這種權力也伴隨着巨大的責任,礦池擁有很大的權力,這是因爲礦池最終決定了其礦機處理哪些區塊,以及這些區塊中可以包含哪些交易。礦池決定提取哪些 MEV 以及誰可以提取它,他們對 Gas limit 進行投票,並參與重大的政治鬥爭。因此對於以太坊文化來說,礦池的入場門檻儘可能低、以最大限度地去中心化是至關重要的。

所以當我決定構建一個礦池時,我驚訝地發現它是一項非常有挑戰性的工作!關於如何運行具有高響應性、低叔塊率的競爭性礦池,很少有公開的知識分享。

所以我想:好吧,讓我們解決這個問題。

構建一個礦池包含兩部分工作:

  1. 設置一個具有良好對等網絡和快速處理速度的全節點客戶端;
  2. 將全節點連接到礦池軟件,該軟件管理哈希率並在所有礦工之間分配工作負載。

在本文中,這兩者都會談到。

這篇「以太坊礦池構建指南」來自我們構建 MiningDAO.io 礦池的第一手經驗,並概述了我們如何將叔塊率從 10%-14% 降低到大約 4%-5%,與前 10 名礦池中的部分組織保持持平,甚至更佳。

設置以太坊全節點客戶端

運行礦池需要運行以太坊全節點客戶端。該客戶端將負責接收新塊和待處理的交易,以及生成自己的區塊並將它們廣播到其他節點。本節介紹如何正確設置一個全節點客戶端。

服務器硬件要求

運行一個完全同步的節點需要相當好的硬件。我們建議至少 32GB 內存(RAM)和至少 2TB SSD 存儲(永遠需要將以太坊鏈與 HDD 同步)。

帶寬也很重要。最好儘可能靠近其他節點,以儘快接收新塊。我們建議採用其他礦池普遍採用的雲服務上使用雲託管專用機器:在歐洲是 OVHHetzner,亞洲則是阿里雲和亞馬遜雲 AWS。

Geth 還是 OpenEthereum?Geth!

下一個決定是使用哪個以太坊客戶端。最受歡迎和經過充分測試的選擇是 Geth 和 OpenEthereum (原名 Parity)。 Geth 在協議開發方面處於領先地位,並且始終保持最新狀態。

爲了進行比較,我們利用 Parity-2.7.2 (OpenEthereum 重構之前的最新穩定分支)和 OpenEthereum 進行了一些小規模實驗,但兩者在區塊導入時間和區塊生產時間方面的測試結果都很糟糕,導致叔塊率高到令人無法接受。

我們歡迎任何人進行更徹底的 A/B 測試,並與我們聯繫,爲我們提供更多數據,但在當前階段,我們只推薦 Geth。

以下是我們使用的命令行:

geth --datadir=/ssd/gethdata --syncmode=fast --cache=21000
--maxpeers=250 --txpool.globalslots=1000
--http --http.api=eth
--miner.etherbase='0xADDRESS' --mine --miner.threads=0
--miner.extradata='MiningDAO'
--miner.notify='http://127.0.0.1:8107' &>> ~/geth-log.txt

這裏 --cache=21000 表示分配 21GB 用於內存狀態存儲(這是 Geth 可以處理的峯值),命令行其餘部分將在下文予以解釋。

更重要的是,我們下文描述的對 Geth 代碼的修改可以在 這裏 找到,作爲可供下載的存儲庫,或者在 這裏,作爲要應用的補丁。

將空塊產生頻率降至最低

有兩件事會破壞礦工所獲取的價值回報:挖出叔塊和挖出空塊。

這兩者幾乎同樣糟糕:叔塊獎勵爲 1.75 ETH,空塊獎勵爲 2 ETH,兩種情況下都沒有交易費盈餘。相比之下,帶有交易費用的完整區塊的總獎勵通常達到 3-4 ETH,有時甚至更多。

爲什麼礦池有時會 產生空塊,以及如何將其產出頻率降至最低?

當另一個礦池挖出一個新區塊(比如高度 N)時,高度 N 的任何其他區塊都可能成爲叔塊。 因此每當發現新區塊時,Geth 會立即切換礦工的工作,在 N+1 高度挖出一個空區塊。這個空塊中不包含交易費用,但這還是比挖出註定要成爲叔塊的區塊要好。

隨後,Geth 在高度 N+1 處構建了一個「真正的」區塊,並再次切換礦工的工作。構建這樣一個「真實」的區塊需要時間(0.1-0.3 秒),因此需要兩步過程。但在這段 0.1 到 0.3 秒的過渡期間,其他礦工們則正在挖一個空塊。

收集所有待處理的交易,以實現費用收益最大化,可能很誘人,但像 txpool.globalslots 這樣貪婪,會大大增加 Geth 構建「真實」區塊所需的處理量(要耗時多達 1 秒或更長時間)。我們的推薦值不大於 1000 或 2000。

要了解這方面的更多詳細信息,請查看 https://github.com/ethereum/go-ethereum/issues/21899

將叔塊產生頻率降至最低

解決了空塊,我們就可以開始困難的部分了。要儘量降低叔塊率,有兩件事是關鍵:

  1. 當其他礦池生產出新區塊時,儘快掌握消息;
  2. 當您的礦池產生一個新區塊時,儘可能廣泛地傳播它(這樣其他人開始在它後面開始挖礦 )。

如前所述,實現良好對等網絡(p2p)的第一步是在臨近其他節點的雲服務器上運行您的全節點,並配備良好的帶寬。
其次,良好的帶寬允許節點處理更多的直接對等點,從而減少接收新信息所需的 p2p 中繼段(hop)數量。 Geth 命令行中對等點數的標誌是 --maxpeers。

下面我們將解釋一些更細微和強大的技巧,以最大限度地提高區塊導入速度和區塊廣播速度。

使用 bloXroute

bloXroute 是一項致力於改善礦工之間連接並降低其叔塊率的服務。大多數礦池都連接到 bloXroute,甚至主要的成熟礦池都 報告,使用 bloXroute 會帶來顯著改進。KeeperDAO 進行的 指標衡量 進一步證實了 bloXroute 相比同類服務具有巨大優勢。

我們的實驗也體現出顯著的改進。在具有默認對等設置的新同步節點上,大約 90% 的所有新區塊首先來自 bloXroute (只有 10% 來自所有其他對等節點)。

即使在我們的節點經過微調以連接到頂級對等點之後,仍有 40%-60% 的新區塊首先來自 bloXroute。

按照 bloXroute 設置教程進行操作後,不要忘記 將 bloXroute 節點添加到爲您的 Geth 設置的「受信任的對等點」中,稍後會用到它。受信任的對等點 是 Geth 將始終連接到的預設節點,無論對等點如何隨機初始化。受信任的對等點也不計入連接數限制。將 bloXroute 網關添加到受信任的對等點,可確保 Geth 的這一連接不會意外斷開。

我們進一步建議連接到太極網絡。太極網絡項目是星火礦池開發的區塊廣播網絡。可以通過將太極網絡 各個端點 添加到同一個受信任的對等文件中,來保持與太極網絡的連接。

積極廣播您的區塊

每當 Geth 成功挖出一個新區塊時,它就會發送該區塊以在網絡上廣播。默認情況下,Geth 只將其廣播到大小爲 sqrt(n_peers) 的隨機子集,後者將區塊廣播到它們的部分對等點,依此類推。

即使所有對等點都同樣有效,這種機制也不是很理想,但是當某些對等點比其他對等點更強大,而這些對等點最終沒有被包含在子集中時,這種機制的缺點尤其明顯。

特別是,在挖出新區塊時要做的第一件事是將其發送到 bloXroute,以便將其轉發到所有參與的礦池。如果 bloXroute 網關最終沒有出現在那個隨機的 sqrt(n_peers) 子集中,那麼您獲得叔塊的機率就會大大增加!

接下來,您會希望將該區塊發送給質量最高的對等點,然後再發送給所有其餘的對等點。

我們已將 以下 Geth 補丁 開源,建議將其應用於您的客戶端。它將所有新挖出的區塊廣播到所有受信任的節點(包括 bloXroute),然後廣播到所有剩餘的對等點。

培養人脈最廣的對等點

Vanilla Geth 旨在實現最大程度的去中心化和網絡結構扁平化。這種選擇非常適合愛好者,並支持由 成千上萬 個節點組成的強大生態系統。然而,正如我們在上一節中看到的那樣,對於執行關鍵職責、或一旦故障會造成高昂成本的節點而言,這些默認參數的效果不佳。

實際上,並非所有對等點都同樣有效。有些節點連接速度較慢,既不會提供新區塊,也不會幫助您的區塊進行廣播。 其他人,尤其是其他礦池的節點,則會產生源源不斷的新區塊數據。

根據星火礦池的建議,我們 調整了 Geth 參數,以記錄哪些節點最先向我們發送新區塊。經過幾個月收集這些數據,使我們能夠找出始終保持連接的最佳對等點(通過 Geth 中的「靜態」/「受信任」節點設置)。 這裏 是一個 Python 腳本,我們用來處理上述數據,並將其轉換爲 Geth 可以攝取的 trusted_nodes.json 列表。

由於 MiningDAO 礦池存在於每個地理區域(北美、歐洲、亞洲)中,我們對每個地理區域的頂級對等點列表進行了數據挖掘。不幸的是,我們不能公開分享這些節點的 IP,避免這些節點遭遇 DDoS 攻擊。對於有充分理由的嚴肅詢問者,我們可以私下分享。也很樂於分享我們自己在每個地理區域的節點,以供其他礦池連接!

設置礦池軟件

正確設置全節點後,下一步是設置礦池軟件本身。該軟件將負責處理來自所有單個礦機的連接、跟蹤工人的份額並管理支出。

挑選礦池軟件

我們簡要分析了以下 4 個選項:Miningcoreopen-ethereum-poolNOMP (node open mining portal)MPOS (mining portal open source)。 我們後來瞭解到 Flexpool Solo,但未對其進行實驗。

出於兩個原因,我們對於 Miningcore 獲得了豐富的經驗。首先,它將所有過去的數據保存在 SQL 數據庫的磁盤上,這與 open-ethereum-pool 不同,後者通過 Redis 僅將數據保存在 RAM 中。磁盤存儲提供了抗重啓的穩定性和分析歷史數據的能力。其次,我們喜歡 Miningcore 高度可讀、面向對象的代碼。

最終,MiningDAO 採用了我們自己的礦池軟件,以 Miningcore 爲模型,用 Go 語言編寫以提高速度。我們希望儘快開源我們的軟件,但同時我們推薦使用 Miningcore。

修補礦池軟件的延遲問題

我們在使用 Miningcore 時遇到的一個主要問題是它處理工作更新的方式。默認情況下,Miningcore 每 0.5 秒 ping 全節點遠程過程調用(RPC),以查看最新作業是否已更改。這一設置可能適用於其他具有區塊生產時間較長的加密貨幣(對於區塊生產時間爲 10 分鐘的比特幣來說,這是一個可以忽略不計的問題),但對於以太坊而言,這種設置會導致無法接受的高叔塊率。

做個背景知識介紹,有一種簡單的方法可以計算任何處理延遲所帶來的叔塊率增加數值。出塊時間是 泊松分佈 的,意味着無論距離上一個挖出的區塊已經過去多久,在下一秒(或毫秒或其他時間單位)內找到下一個區塊的概率總是相同的。例如,以太坊的目標是 13 秒出塊時間,意味着下一秒出塊的概率始終爲 1 秒 / 13 秒 ≈ 7.7%。 因此,如果您的礦池因任何原因在管道中的任何地方有 0.1 秒的延遲,則由於該延遲,將有 0.1 秒 /13 秒 ≈ 0.77% 的額外叔塊。叔塊將來自您的礦機處理過時工作的 0.1 秒時間段。

回到 Miningcore。使用上面的公式,礦工作業更新如果出現 0.5 秒延遲,將導致 0.5 秒 / 13 秒 ≈ 4% 額外的叔塊(絕對比例,而不是相對百分比)。 當然,如此高的非受迫性失誤率是不可接受的。我們已經廣泛嘗試將更新頻率從 0.5 秒降低到 50 毫秒及以下,但發現這一設置相當不可靠:工作更新仍然明顯延遲。

更好的解決方案是利用 Geth 的 notifyWork 功能,以便 Geth 在作業更新出現時主動將其發送到礦池軟件。我們對 Miningcore 打了補丁,以支持這一選項,併發布了 修改版。過渡到 notifyWork 後,我們發現 Geth 和 Miningcore 之間的通信延遲幾乎可以忽略不計,因此我們的叔塊率顯著降低。

總結

希望這篇文章有用,並引導更多人運營以太坊礦池;自制礦池的文化對於保持以太坊的開放性和去中心化至關重要。

簡單總結一下,我們最初採用 vanilla Miningcore 的默認參數和 vanilla Miningcore 軟件。這種默認設置的叔塊率約爲 10%-14%。我們在逐步採用了本文概述的種種修改後,使我們的叔塊率降至 4%-5%,與當前現有的前 10 名礦池的水準持平甚至更好(Etherscan 中顯示的叔塊率略高,因爲我們有時會在生產中進行實驗)。

我們的 Geth 修改方案可以在這裏作爲 repo 找到,也可以在這裏作爲 補丁 找到。可以在 這裏 找到我們的 Miningcore 修改方案,且可以在 這裏 找到相應的礦池配置文件。

如果您對如何改進這一參數設置有進一步的想法,請向我們發送 pull 請求或 電子郵件

鳴謝:

Miningcore 加速由 Alexander Melnikov 開發。感謝這些朋友提供建議和想法: Alex ObadiaFlashbots)、 Eyal MarkovichShen ChenbloXroute)、Xin XuSparkpool)、Yang Ze (Sparkpool)、 Chris (Flexpool)和 Haseeb QureshiDragonfly Capital)。

來源鏈接:medium.com