由于 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 毫秒及以下，但发现这一设置相当不可靠：工作更新仍然明显延迟。 (责任编辑：admin)