我写这篇文章是为了帮助组织和理清一些思路

我写这篇文章是为了帮助组织和阐明一些围绕比特币“去中心化矿池”的思考、它们的要求，以及在该事物能够被完全指定之前必须解决的一些未解决的问题。

比特币的去中心化矿池

一个去中心化矿池由以下组件组成：

1. 一个弱区块和难度目标机制，
2. 一个用于收集和统计 shares 的共识机制，
3. 一个支付承诺，要求一定数量的参与者签署 share 支付，
4. 一个签名程序，用于对支付承诺进行签名，以便矿池参与者得到适当的支付，
5. 一个交易选择机制，用于构建有效的比特币区块。

StratumV2 项目正在进行的改进还包括与矿机进行加密通信。这些问题在很大程度上可以从矿池本身分解出来，因此我们不在这里讨论，但假设任何去中心化矿池都将使用 StratumV2 通信机制。

弱区块

share 是一个“弱区块”，它被定义为一个不满足比特币的目标难度 $T$，但满足某个较低难度目标 $t$ 的标准比特币区块。矿池指定这个参数 $t$，当找到“弱区块”时，它会被传递给矿池。

share 本身是一个不记名凭证，证明已完成一定量的 sha256 计算。share 本身必须具有表明它“属于”特定矿池的结构。在中心化矿池的情况下，这种情况发生是因为矿池本身会分发与矿池创建的区块相对应的“工作单元”（比特币头），交易选择由（中心化）矿池完成。

在去中心化矿池的情况下，share 本身必须具有额外的结构，向矿池中的其他矿工表明该 share 属于该矿池，并且如果它满足了比特币的难度目标，则该 share 包含承诺，使得矿池中的所有其他矿工都将根据矿池的去中心化共识机制 中实现的 share 统计来获得报酬。

没有提交额外元数据以证明 share 是矿池一部分的 shares 或区块必须从 share 计算中排除，并且这些矿工不是矿池的“一部分”。换句话说，除非该 share 的最终支付（如果它成为一个比特币区块）可以以这样一种方式支付矿池，使得所有其他哈希器都得到报酬，否则向矿池提交一个随机的 sha256 头不应被算作 share 贡献。

例如，考虑一个去中心化矿池的“share”，它看起来像：

    Version | Previous Block Hash | Merkle Root | Timestamp | Difficulty Target | Nonce
    Coinbase Transaction | Merkle Sibling | Merkle Sibling | ...
    Pool Metadata

这里的第二行中的 Merkle Siblings 是交易 Merkle 树中的附加节点，用于验证指定的 Coinbase Transaction 交易是否包含在 Merkle Root 中。我们假设这个 Coinbase Transaction 提交给矿池共识机制 所需的任何附加数据，例如在 OP_RETURN 输出中。

Coinbase Transaction 是一个没有输入的标准交易，应该有以下输出：

    OutPoint(Value:0, scriptPubKey OP_RETURN <Pool Commitment>)
    OutPoint(Value:<block reward>, scriptPubKey <P2TR pool_pubkey>)

<block reward> 是这个减半时期的所有费用和区块奖励的总和，pool_pubkey 是一个由矿池以协作方式控制的地址，以便共识机制 只能以这样一种方式来使用它，即按照其 share 记账所描述的方式支付给所有哈希器。

<Pool Commitment> 是 Pool Metadata 的哈希值，它提交给矿池运行所需的任何附加数据。至少，这必须包括弱难度目标 $t$（或者必须可以从此元数据计算出来）。此 share 的验证要求此比特币头的 PoW 哈希值小于此弱难度目标 $t$。

人们可能想包含在 <Pool Commitment> 中的其他内容是：

1. 可用于协作签署支付承诺的哈希器的公钥，
2. 与此矿工进行加密通信所需的密钥，
3. 允许其他矿工与此矿工进行带外通信的识别信息，例如 IP 地址、TOR 地址或其他路由信息
4. 此 share 的父级（在 braidpool 的情况下为 bead），或者如果使用其他共识机制，则使用其他共识特定数据。
5. 多轮阈值签名仪式中涉及的中间共识数据。

最后，我们注意到有一个关于使用 covenant（CTV）进行挖矿协调 的提案，它不使用弱区块，对哈希率的采样速度不比比特币区块快，并且无法降低方差。因此，它不是通常意义上的“矿池”，我们将不再进一步考虑该设计，尽管 covenant 对于去中心化矿池可能仍然有用，我们将在支付承诺中讨论这一点。

共识机制

在中心化矿池中，中心矿池运营商接收所有 shares 并对其进行记账。虽然这种记账很简单，但去中心化矿池的重点在于我们不想信任任何单个实体来正确地执行此操作，也不想让任何单个实体控制来窃取矿池中的所有资金，或者错误地发布支付的权力。

因此，所有哈希器必须接收所有其他哈希器的 shares。每个 share 如果符合比特币的难度目标，则可能已经是一个比特币区块，并且必须提交给如上所述的矿池元数据。

对于给定时期的 shares 集合，我们必须对 shares 应用共识机制，以便矿池的所有参与者都同意这些是有效的 shares，并且应该根据矿池的支付机制获得报酬。

共识机制必须具有比比特币快得多的特性，以便它可以在有效的比特币区块之间收集尽可能多的有效 shares。这样做的原因是矿池的主要目标之一是降低方差。P2Pool 通过使用块时间为 30 秒的标准区块链来实现这一点，而 Monero p2pool 则通过使用 10 秒的块时间来实现这一点。

比特币已经催生了大量的共识算法研究，可以考虑在此处使用，包括 GHOST 协议、异步 PBFT、诸如 Avalanche 和 DFinity 使用的“采样”算法以及 基于 DAG 的 算法。（这不是详尽的参考书目，而只是选项的代表性样本）

所有共识算法的一个共同特征是，达到共识的速度不能快于大致的全球网络延迟。无论选择哪种共识算法，所有参与者都必须看到进入当前状态的所有数据，并且能够同意这是正确的当前状态。调查使用上述算法开发的网络，发现它们能够达成共识的最快速度约为一秒。因此，不同算法的确切“共识时间”因 O(1) 常量而异，所有算法都在 1 秒左右。这比比特币区块快大约 600 倍，并且可以使小 600 倍的矿工能够做出贡献，并且与单独挖矿相比，方差降低了 600 倍。

虽然方差减少 600 倍是一个值得实现的目标，但这还不足以让单个现代挖矿设备充分降低其方差以使其值得。因此，必须为小于特定哈希率的矿工找到不同的解决方案。我们在 子矿池 中提出了一些想法。

从我们的角度来看，共识算法的明显选择是 DAG，它以与比特币本身相同的精神重用比特币的工作量证明——也就是说，链尖由最重的工作加权尖端定义，并且 DAG 中的冲突解决使用工作加权。请注意，这与仅在恒定难度下才起作用的“最长链规则”相同，但我们假设 DAG 没有恒定难度，因此必须正确完成难度的组合。解决方案是识别从创世区块到链尖的最重权重线性路径，其中难度沿路径求和。

最后，我们警告说，在考虑纳入更小矿工的机制时，不得违反比特币的“无进展”特性。也就是说，不应将来自一小组较小矿工的工作相加，以在 DAG 中获得更高工作的区块。

支付承诺

支付承诺是比特币上的 coinbase 输出，其中包含来自该区块奖励和费用的所有资金。此支付必须提交给在挖掘该区块时计算出的 share 支付结构。换句话说，它必须代表并提交给去中心化矿池 share 记账的共识。

验证 共识机制 的输出远远超出了比特币脚本的能力。因此，通常必须找到一种机制，以便 braidpool 参与者的绝大多数（拜占庭容错子集）可以对输出进行签名，这本质上是将关于 share 支付的共识反映到比特币中。

未花费的哈希器支付输出（UHPO）机制

对于支付承诺，我们提出了一种新的简单的 share 记录记账方法。将共识机制视为类似于比特币的基于 UTXO 的区块链。共识机制的“UTXO 集”是所有哈希器的支付输出集，金额由记录的 shares 和共识机制规则决定。

我们将哈希器支付集称为未花费的哈希器支付输出（UHPO）集。这是去中心化矿池的“UTXO 集”，UHPO 集的计算和管理是去中心化矿池的主要目标。

UHPO 集可以简单地表示为一个交易，该交易的输入是矿池挖掘的所有未花费的 coinbase，每个唯一矿工的一个输出，金额由其 share 贡献决定，但要遵守共识机制规则。

在 p2pool 中，此 UHPO 集直接放置在每个区块的 coinbase 中，导致向哈希器支付大量非常小的付款。传统矿池的一个优势在于，它们会将这些付款聚合到多个区块中，从而减少每个哈希器的提款数量。去中心化矿池也应该这样做。这样做的结果是，在 p2pool 中，带有小输出的大 coinbase 与付费交易竞争区块空间。

在 coinbase 输出中提交 UHPO 集是一种机制，允许在去中心化矿池在此区块之后关闭或失败的情况下正确支付所有哈希器费用。因此，UHPO 集交易必须是正确形成的、完全签名且有效的比特币交易，可以广播。有关如何签名/授权此 UHPO 交易的注意事项，请参阅支付授权。

我们永远不希望实际广播此 UHPO 集交易，除非在矿池出现故障的情况下。与其他乐观协议（如闪电网络）类似，我们将从比特币中保留此交易，并相对于比特币带外更新它。对于每个新区块，我们将更新 UHPO 集交易以解释自矿池挖掘的最后一个区块以来的任何新 shares。

此外，去中心化矿池应支持哈希器的“提款”。这将采取发送到矿池（并由矿池内的共识同意）的特殊消息或交易的形式，以从UHPO 集交易中删除哈希器的输出，并创建一个新的单独交易，该交易支付给该哈希器，授权 它，并将其广播到比特币。

矿池交易和衍生工具

如果去中心化矿池支持其自身的交易，则可以将“发送 shares”给另一方。此操作将 UHPO 集交易中的一方地址替换为另一方的地址。这样，未支付的 shares 可以交付给交易所、做市商或 OTC 平台，以换取即时付款（例如，通过闪电网络）或作为衍生品合约的一部分。

shares 的交付可以构成衍生品合约的原因是它们实际上是对哈希率的衡量，并且尚未结算为比特币。虽然我们可以在任何时候计算 UHPO 集，并根据矿池当前挖掘的比特币数量将其转换为比特币输出，但仍然不确定矿池在请求结算之前将挖掘多少个区块，以及这些区块将有多少费用。

可以创建一个私人安排，一方预先购买另一方的未来 shares 以换取比特币。这是一份期货合约，矿工的交易对手承担着矿池“运气”风险和费率风险。

为了形成哈希率衍生品，必须能够在两个不同的难度调整窗口 $d_1$ 和 $d_2$ 之间交付 shares。由于难度调整本身，一个难度调整窗口中的 shares 与另一个窗口中的 shares 相比，具有不同的价值 $BTC_1$ 与 $BTC_2$。如果可以计算离散导数

$$ \frac{d({\rm hashrate})}{d({\rm BTC})} = \frac{d_1-d_2}{BTC_1 - BTC_2} $$

那么可以通过私人合约构建期权和期货等衍生工具，其中来自不同难度调整时期的 shares 将交付给衍生品合约交易对手以换取 BTC，可能存在时间限制。我们在这里不再描述如何实现这一点，我们只是指出去中心化矿池支持私人合约衍生工具的充分条件是：

1. 能够将 shares 发送给另一方
2. 能够在关于难度调整的明确时间点（例如，对于前一个时期，在调整之后）将 shares 结算为 BTC
3. 能够跨两个难度调整窗口交易 shares。

将去中心化矿池变成一个带有订单簿的完整 DeFi 市场可能很诱人。我们告诫说，矿工可提取价值 (MEV) 问题是一个严重的问题，它会破坏系统的公平性和信心，应在此处避免。我们在这里考虑的唯一操作是 (a) 将 shares 发送给另一方，以及 (b) 请求以 BTC 支付 shares。

最后，让我们注意到在每次难度调整之后，“share” 的价值自然是固定的。在一个为期两周的难度调整窗口内，每次 sha256d 哈希尝试在 BTC 方面都有一个固定的价值，但确切的 BTC 数量在下一次难度调整之前是未知的。因此，为期 2 周的难度调整窗口是自动广播上一时期的 UHPO 树并结算上一时期所有 shares 的自然点。

支付授权

在支付承诺中，我们描述了一种简单的机制来表示由任何时间点的 shares 共识机制 决定的 shares 和 share 支付。然而，比特币无法评估矿池共识机制的逻辑，我们必须找到一种更简单的方法向比特币表示该 share 支付共识，以便 coinbase 输出不能以矿池共识决定的方式之外的任何其他方式使用。

授权 share 支付和对 coinbase 输出进行签名的最直接的方法可能是使用大型阈值多重签名。签名者集合可以是运行矿池共识机制并具有所有数据可用性以查看该共识机制链尖的任何矿池参与者。我们假设在弱区块元数据中，矿池参与者包含一个公钥，他们将使用它来协作签署支付授权。

授权 coinbase 花费的最合乎逻辑的签名者集合是已经成功挖掘比特币区块的矿工集合。我们希望避免任何单个矿工单方面控制 coinbase 并能够在不支付其他哈希器的情况下窃取资金。因此，使用拜占庭协议文献中的 $(3f+1)$ 规则，签名者的最小数量为四。这意味着在矿池启动时，前 4 个区块必须直接且立即支付给哈希器，因为没有足够已知方来签署多重签名，我们甚至不知道他们的公钥来构造（P2TR、P2SH 等）比特币输出地址和 scriptPubKey。

在前 4 个区块之后，我们假设先前挖掘过区块的 66%+1 矿工必须对 coinbase 输出进行签名，支付到 UHPO 集交易中。

这可能是构建去中心化矿池中最大的未解决问题——如何协调大量的签名者。如果我们假设 shares 在每次难度调整时都支付到比特币上，这将是 2016 个区块，并且有多达 1345 个签名者必须协作才能进行阈值多重签名。这是一个非常大的数字，通常远远超出可用签名算法（例如 FROST、ROAST、MP-ECDSA 或 Lindell 的阈值 Schnorr 算法）的能力。

下面我们将更详细地讨论阈值 Schnorr，但这可能不是提交和授权将 coinbase 支出到 UHPO 树中的唯一方法。我们鼓励读者找到解决此问题的其他解决方案。我们能够找到的所有签名算法的最大缺点是它们无法容忍故障。

Schnorr 阈值签名

我们已经回顾了大量关于 Schnorr 阈值算法的文献。

它们通常都涉及使用 Pedersen 的 DKG 的变体的分布式密钥生成 (DKG) 阶段，通常使用 Feldman 引入的多项式承诺来增强它，以实现 可验证的秘密共享方案 (VSS)。有很多论文对这个想法进行了修改，每篇论文都侧重于组织通信轮次、关于通信的假设（例如是否存在广播通道）和安全证明。

阈值签名中的参与者通过创建秘密共享其对他人的贡献，从而在 DKG 阶段贡献熵。通过这种方式，可以使用来自所有参与者的熵输入创建密钥，以便没有参与者知道该密钥，但在 DKG 结束时，所有参与者都持有它的 shares，以便必须对 t-of-n 阈值数量的 shares 进行 Lagrange 插值以重构密钥。

然后，这些秘密 shares 用于计算签名。不是直接重构秘密密钥（这将使执行重构的一方具有单方面支出控制权），而是使用秘密 share 作为私钥来计算签名，然后对生成的签名集执行 Lagrange 插值。

ECDSA 和 Schnorr 签名都需要一个 nonce $k$，签名参与者必须在签名之前就此达成一致，并在签名本身中提交。这通常通过运行另一轮 DKG 来计算 $k$ 来完成，以便每个人都拥有它的秘密 share。

分布式密钥生成

交易选择

Stratum V2 项目的重点是矿工负责构建区块和选择交易的模型。这是对 Stratum V1 的改进，在 Stratum V1 中，（中心化）矿池选择区块和交易。

这里的风险在于，矿池要么在政府实体的指示下审查有效交易，要么通过带外支付优先处理交易，从而危及系统的“抗审查”特性。

在弱区块部分，我们没有说明如何进行交易选择。这是一个可以分解的问题，对于去中心化矿池，我们还假设各个哈希器正在构建区块，并且矿池对参与哈希器挖掘的区块的交易内容没有进一步的限制。事实上，对于不符合比特币难度阈值的弱区块，最好完全省略交易集，以便更快地验证 shares。这带来了一个问题，即哈希器可以构建一个包含无效交易的区块，但如果该哈希器挖掘了一个区块，这将很容易被发现，并且他的 shares 可能会失效。

使用去中心化矿池和 Stratum V2 的交易选择机制应该能够轻松地插入到去中心化矿池所需的区块结构中，如 弱区块 中所示，只要 Stratum V2 能够容忍所需的 coinbase 和元数据结构。

我们认为，简单地允许哈希器进行交易选择是不够的，因为中心化矿池可以简单地拒绝付款，除非哈希器按照矿池规定的规则选择交易。恢复比特币抗审查性的完整解决方案还需要去中心化支付。

未解决的问题和未来方向

这里最大的未解决问题是支付授权。虽然现成的算法（例如 ROAST）是可用的，但它们需要修复签名者的集合，并且无法容忍 nonce 生成阶段、签名阶段或这两者都失败。必须选择阈值数量的参与者，并且所有参与者都必须在密钥生成和签名阶段保持在线。如果任何参与者失败，则必须选择不同的子集并重新启动该过程。Joshi 等人 提出了一种方法，尽管设置阶段仍然无法容忍失败，但以额外的预处理步骤为代价使最终签名聚合异步，假设随机数生成是成功的。

ECDSA 和 Schnorr 签名都需要 nonce $k$ 这一事实是一个很大的缺点，它需要每个人都在线的额外密钥生成轮次，而 BLS 等其他系统则没有。

在实践中，如果没有找到新算法并且使用了现有的 Schnorr 阈值签名（涉及 DKG 和 Shamir 共享），则必须在拥有太多签名者而无法在合理的时间内对付款进行签名，以及签名者太少而导致系统不安全并且 coinbase 可能被一小部分人窃取之间取得平衡。

可以考虑的一种方法是对签名者的集合进行子采样，并以某种方式聚合来自子集的签名。由于生成的签名将具有不同的 nonce，因此无法直接聚合它们，但这与聚合交易或区块中的不同签名是相同的问题，并且 跨输入签名聚合 (CISA) 的方法可能在此处使用，并且可能表明未来朝这个方向进行软分叉的愿望。

Covenants

可以将 UHPO 集交易转换为树结构，使用 covenant 在后代交易中强制执行树的结构。这通常在基于 covenant 的软分叉提案的上下文中完成，以便一方可以执行他的提款，而不必强迫其他人同时提款。

由于去中心化矿池是一个活跃的在线系统，因此使用交互方法编写用于提款的新交易似乎比允许广播树的一部分更好。如果广播了树的一部分，那么所有矿工也必须注意到这一点并更新 share 支付。

我们认为，广播整个 UHPO 集交易的唯一原因是矿池出现故障或关闭，在这种情况下，树只会增加链上数据负载，而没有任何好处。

子矿池

由于共识系统无法比全局延迟更快地达成共识，因此 share 大小的改进最多约为 1000 倍。为了支持更小的哈希器，可以考虑“链接”去中心化矿池以创建子矿池。

子矿池不是将 coinbase UTXO 作为其 UHPO 集的输入，而是将来自父矿池的 UHPO 集条目作为其 UHPO 集中的条目。通过与其父矿池分离的共识机制，两个去中心化矿池的链可以允许小 1000000 倍的哈希器参与。原则上，矿池可以动态地创建和销毁子矿池，并根据观察到的哈希率在子矿池和主矿池之间移动矿工，以便为所有哈希器确定恒定的方差。

• 原文链接： github.com/mcelrath/brai...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～