硬核上手指南：如何構建一個以太坊礦池？

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

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

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

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

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

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

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

所以我想：好吧，讓我們解決這個問題。

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

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

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

設置以太坊全節點客戶端

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

服務器硬件要求

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

帶寬也很重要。最好儘可能靠近其他節點，以儘快接收新塊。我們建議採用其他礦池普遍採用的雲服務上使用雲託管專用機器：在歐洲是 OVH 和 Hetzner，亞洲則是阿里雲和亞馬遜雲 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

將叔塊產生頻率降至最低

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

如前所述，實現良好對等網絡（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 個選項：Miningcore、open-ethereum-pool、NOMP （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 Obadia （Flashbots）、 Eyal Markovich 、 Shen Chen（bloXroute）、Xin Xu（Sparkpool）、Yang Ze （Sparkpool）、 Chris （Flexpool）和 Haseeb Qureshi（Dragonfly Capital）。