Ark V2 介绍

到目前为止，对 Ark 的主要担忧集中在流动性锁定的问题上。随着网络上的交易量增加，服务提供商必须锁定更多的流动性，导致 Ark 被描述为一个容量高但速度慢的网络。

在服务器上运行 Ark 已经有效地解决了流动性问题。在服务器上，Ark 可以以 24 小时为周期运行，允许 ASP 每天回收资金。仅这一点就代表了比闪电网络 (Lightning) 的巨大改进，因为设置服务器可以轻松接受付款，而无需打开通道。

虽然在服务器上运行 Ark 在流动性方面已经非常高效，但 Ark 背后的基本理念是消除技术障碍，并以用户友好的方式为所有人扩展比特币支付。这就是 Ark v2 的用武之地。

Ark v2 使 Ark 服务提供商 (ASP) 能够回收其流动性，而无需等待到期期限（4 周）。这听起来几乎好得令人难以置信，哈？

对于当前 Ark 设计，共享 UTXO 的 TapTree 结构如下所示：

Ark V1 - 共享 UTXO 的 TapTree 结构

有两个分支：sweep (清扫) 分支和 unroll (展开) 分支。

sweep (清扫) 分支可以在 4 周后由 ASP 触发，以有效地回收锁定的资金。

unroll (展开) 分支可以由任何人随时触发，以开始将拥塞控制树一直展开到叶子节点。

对于 Ark V2 设计，新的 TapTree 结构如下所示：

Ark V2 - 共享 UTXO 的 TapTree 结构

有两个上层 TapBranch：左上层 TapBranch 和 右上层 TapBranch。

sweep (清扫) 和 unroll (展开) 分支保留在 左上层 TapBranch 下，其中：

1. sweep (清扫) 分支保持不变。
2. unroll (展开) 分支不能再随时触发；相反，它可以在树创建后 2 周触发。

上层 TapBranch 被添加到根。我们将此分支命名为 右上层 TapBranch，或简称为 撤销分支 (revocation branch)。此分支对应于各种撤销可能性的组合。

当足够多的用户花费他们的 vTXO 时，ASP 进入 撤销分支 (revocation branch) 以有效地回收相应部分的流动性，而不涉及任何时间限制。

撤销分支 (Revocation Branch)

Ark v2 引入了一种类似于闪电网络撤销机制的机制。在闪电网络中，用户通过暴露一个秘密来撤销他们的通道状态。类似地，在 Ark v2 中，用户在花费 vTXO 时暴露一个秘密。但是，与闪电网络的撤销方案不同，这里的撤销秘密被聚合，并用于集体赎回资金。

每个 vTXO 所有者都拥有一个单独的撤销秘密。当足够多的 vTXO 所有者暴露他们的秘密时，ASP 会聚合它们；

聚合撤销秘密 (Aggregate revocation secret) = sec1 + sec2 + sec3 … + secn 聚合撤销公钥 (Aggregate revocation public) = sec1⋅G + sec2⋅G + sec3⋅G … + secn⋅G

通过从这个聚合秘密生成的有效签名，ASP 可以访问 撤销分支 (revocation branch) 中的一些相应叶子节点。

一个 撤销分支 (revocation branch) 可以包含多达数百万甚至数十亿个叶子节点，每个叶子节点代表一个 聚合撤销公钥 (aggregate revocation public) 的组合，这反过来又对应于一个特定的撤销可能性。虽然构建如此庞大的树可能在计算上是昂贵的，但可以使用简单的 CHECKSIG 轻松解锁相应的叶子节点：

<aggregate_revocation_public> OP_CHECKSIG

撤销叶子节点 (revocation leaf) 还必须使用一个 covenant 来约束花费交易的输出到 ASP 和剩余的树，将锁定的资金导回 ASP，同时将资金重新分配给 vTXO 持有者。

撤销叶子节点 (revocation leaf) 最终生成的脚本将是 ；

<aggregate_revocation_key> OP_CHECKSIGVERIFY <asp_key> OP_CHECKSIGVERIFY

<constrained_outputs_template> OP_CHECKTEMPLATEVERIFY

一个具有 16 个 vTXO 的共享 UTXO 包含一个总共具有 805 个叶子节点的 撤销分支 (revocation branch)。这样的分支可以很容易地由 ASP 构建，并且可以由客户端重新构建以验证分支的内容。

如果一轮中注册的 vTXO 数量超过 16 个，则组合树会加深，可能需要一个具有数百万甚至数十亿个叶子节点的 撤销分支 (revocation branch)。幸运的是，MAST 可以容纳多达 340282366920938463463374607431768211456 个叶子节点，并且它在控制块的链上占用空间上以 log n 很好地扩展，这进一步受益于见证折扣。

问题不在于链上占用空间，而在于计算。为了构建如此庞大的 撤销分支 (revocation branch)，ASP 需要像 VPU 这样的定制硬件。

由于客户端无法重新构建如此庞大的 撤销分支 (revocation branch)，他们必须使用由 ASP 提供给他们的 VPU 生成的零知识证明来验证 撤销分支 (revocation branch) 的内容。

Coin Targets Table (币目标表)

或者，ASP 可以将共享 UTXO 输出分成几个块，每个块包含 16 个 vTXO，每个块加起来 43 vBytes。

总的来说，新的设计似乎涉及相当大的努力，但它似乎是值得的。

请注意，撤销设计更改了 vTXO 的 outpoint 引用，导致基于 CHECKSIG 的连接器不可用。相反，新的设计必须采用自省 (introspection) 与基于 CSFS 的连接器相结合。这意味着 vTXO 现在必须只签名连接器的 outpoint 引用以放弃自己，从而将自己的 outpoint 上下文从签名消息中排除。

特别感谢 Matt Corallo 激励我去研究撤销设计。

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