这篇「矿池构建指南」来自 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 还是 ？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 会带来显著改进。 进行的 指标衡量 进一步证实了 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 名矿池的水准持平甚至更好（ 中显示的叔块率略高，因为我们有时会在生产中进行实验）。
我们的 Geth 修改方案可以在这里作为 repo 找到，也可以在这里作为 补丁 找到。可以在 这里 找到我们的 Miningcore 修改方案，且可以在 这里 找到相应的矿池配置文件。
如果您对如何改进这一参数设置有进一步的想法，请向我们发送 pull 请求或 电子邮件！
鸣谢：
Miningcore 加速由 Alexander Melnikov 开发。感谢这些朋友提供建议和想法： Alex Obadia （）、 Eyal Markovich 、 Shen Chen（bloXroute）、Xin Xu（Sparkpool）、Yang Ze （Sparkpool）、 Chris （Flexpool）和 Haseeb Qureshi（Dragonfly Capital）。
来源链接：medium.com
内容搜集自网络，整理者：BTCover，如若侵权请联系站长，会尽快删除。
