在 TaProot wizards Tyler 和 Rijndael 对基于 BitVM 的双向锚定运营商施加的流动性要求提出批评后，BitVM 最近受到了一些审查。 在最近围绕基于 BitVM 的第二层解决方案的所有讨论中，我理所当然地认为讨论这些解决方案并对设计空间感兴趣的人们了解该架构对运营商施加的抵押/流动性要求。 最近围绕“流动性紧缩”问题的讨论表明，我对这个假设的看法是错误的，而且除了积极参与 BitVM 开发的人之外，许多人都没有意识到这个问题。
在讨论流动性紧缩问题之前，我认为澄清 BitVM 挂钩的独特属性之一（山寨币开发者称为桥）非常重要。 在其他网络上构建的桥梁中，控制网络之间资金流动的实际桥梁合约中持有的资金用于实际处理提款。 如果是 BitVM 挂钩，则无法使用这些资金来完成提款。 系统的运营商（rollup、侧链等）实际上必须拥有自己的流动性才能处理用户提款请求。
当用户提出提款请求时，运营商实际上会向前移动汇总状态，查看每个请求，并使用自己的个人资金处理这些提款。 一段时间后，系统会在提交所有待处理提款的截止点中检查其状态。 操作员之后 已完成最后状态的所有待处理提款 然后，他们可以参与 BitVM 担保资金的索赔流程，以确保他们所拥有的所有资金都完整。 BitVM 合约的建立是为了让运营商能够在未履行最后状态下所有待处理提款的情况下要求撤销这些资金。
因此，一般的用户流程是存款进入由 BitVM 担保的合约，运营商使用自己的资金来处理提款，然后运营商定期补偿自己从 BitVM 合约中自掏腰包的钱。 这使得 BitVM 挂钩与任何其他类型的双向挂钩不同，引入了类似于闪电网络的流动性要求。
流动性紧缩
Taproot Wizards 在他们的文章中指出的问题是对运营商施加的前期流动性要求和防欺诈方案相结合的结果，该方案允许 BitVM 的验证者在不这样做的情况下撤销运营商对资金的访问权。完成给定汇总时期内的所有提款。 这给系统，特别是操作员带来了很大的潜在问题。
现在，让我们完全忽略运营商因恶意审查而故意拒绝处理提款的潜在情况。 现在在考虑潜在的问题时，这不是一个问题，就好像运营商做了这样的事情，他们 应该 他们的访问权限被撤销，并损失他们已经用于处理提款的所有资金。
对于诚实的运营商来说，绝对有可能遇到这样的情况：尽管他们没有恶意，但他们无法获得足够的流动性来处理单个汇总时期内待处理的提款。 如果发生这种情况，那么诚实的运营商现在无法从 BitVM 合约中补偿自己的损失。 有 在没有向单个验证者公开挑战他们的情况下进行处理，导致他们永久失去资金的使用权。 他们在那个时期处理提款所花费的所有资金都将成为他们无法收回的资金损失。
这给挂钩操作者带来了很大的风险。 即使没有任何恶意行为，仅仅通过自有资金的限制、借贷资金的利率上升，仅是获取资金所需的时间因素，他们就可能损失巨额资金。 这给挂钩带来了巨大的潜在不稳定因素，而且还引出了一个问题，如果运营商受到欺诈证明的打击，用户的钱会去哪里？
选项
需要注意的重要一点是，资金的最终死胡同去向取决于任何特定挂钩的实施者做出的特定设计选择。 设计选择有很大的自由度，挑战驱逐操作员后资金的最终目的地有多种选择，操作员必须完成所有提款的纪元结束后的时间是可配置的，这些都不是设置的作为配置它们的单一可能方式。
现在我们了解了问题，让我们看看一些潜在的解决方案。
节流
您可以通过限制提款来解决这个问题。 这将需要创建一个最大资金限额，运营商可以受合同约束在任何给定的汇总时期履行该资金限额。 这将使运营商能够确保他们有足够的资金来处理他们必须处理的最大金额。 每个时期，运营商都可以处理那么多的提款，通过索赔流程从 BitVM 合约中补偿自己，然后在下一个时期回收该金额以完成下一波提款。
这样做的问题是，你不知道与系统挂钩的资金何时会大幅增加，也不知道市场活动何时会调整以激励大量资金想要脱离系统。 随着锚定资金的增加，想要一次性锚定的数量大幅增加的可能性也随之增加。 这种动态本质上会导致退出系统的队列不断增长，除非您增加最大 epoch 提款金额，这也增加了运营商的流动性要求。
这加剧了这些挂钩的流动性要求，并本质上对提款造成了巨大的摩擦。 互换并不能解决问题，因为这最终会将交易对手的流动性困在这个不断增长的队列中，这与其他双向挂钩不同，在其他双向挂钩中，它们实际上可以在促成互换后立即退出。
多个操作员
BitVM 1 和 BitVM 2 都支持以不同方式拥有多个验证者，允许多个验证者参与并能够撤销运营商对资金的访问权限。 在 BitVM 2（以及一些基于 BitVM 的挂钩，例如 Citrea rollup）中也可以让多个操作员并行工作。 不止一个实体可以帮助处理从挂钩中提款，因此可以使用多个流动资金池来促进挂钩。
原则上，这将使整个流动性动态更具可扩展性，因为它将不再局限于必须提供流动性以促进及时从系统中提取的单个实体，但它引入了复杂性问题。 每个存入 BitVM 挂钩并受合约约束的 UTXO 都需要定义索赔条款。 该合同现在需要能够区分多个运营商，并确保有一种方法区分哪些提款与哪个运营商相关，并确保他们只能索取他们所促成的资金，而不是为不同运营商提供的资金。
它还需要考虑如何处理所有运营商存在的全球提款需求。 如果每个运营商都用尽了所有的资金，但仍然存在未满足的需求怎么办？ 他们都有权使用被撤销的 BitVM 资金吗？ 他们都没有吗？ 是否有类似于队列限制的过渡宽限期？ 如果有的话，如果下一个时期这些提款仍然没有得到促进，谁负责？ 这些都是需要具体解决的。
多个线性算子
除了拥有多个并行运算符之外，您还可以拥有一系列线性运算符。 单个操作员可以同时运行，方便提款，如果他们遇到流动性问题并被撤销对 BitVM 资金的访问权限，那么在挑战/撤销过程后，资金可以立即发送到一个新的 BitVM，其中包含新的运营商。 这根本无法解决单个运营商遭受流动性紧缩的风险，并且他们会意识到已经存入的任何提款的损失，但它将确保其他人可以介入并有机会继续以有能力促进提款向 BitVM 索赔。
然而，这给挂钩过程增加了大量成本。 就数据和交互性而言，生成 BitVM 实例并不便宜，这意味着要将线性 BitVM 运算符像这样链接在一起，您必须为挂钩生成一定数量的 BitVM。
逆止器
在使用 BitVM 进行挂钩的所有情况下，都存在一个终极问题：在最坏的失败情况下，资金最终会流向何处？ 最终有两个选择。 要么你实际上烧毁资金，要么你将它们置于验证者的控制之下。 第一个意味着用户的资金现在被摧毁了，每个持有挂钩资金的人现在都变得坚固了。 第二个意味着信任模型已经彻底转变为信任联盟中单方面控制资金的单个验证者或一组验证者。
在没有提款限制的模型中，烧毁资金是不可能的，因为这将验证 Taproot Wizards 所表达的最坏情况的担忧。 运营商持续失败的情况，无论是并行的还是线性的，都会导致用户的资金实际上被销毁。 唯一能保证安全的模型是带有提款节流阀的； 但即便如此，如果合同规定的运营商消失或被撤销其访问权限，永久性资金损失的风险仍然存在。
这样就可以将资金重新置于单个验证者或一组验证者的控制之下。 如果所有运营商完全失败，系统中涉及的验证者将能够收回用户的资金并使其完整。 我不认为这有那么糟糕。
每个 BitVM 实例都设置有 n-of-n 多重签名，用于处理签署 BitVM 合约中涉及的所有预签名交易。 整个方案的最终根本安全模型是，其中一个密钥持有者必须保持诚实，并拒绝签署不诚实的资金分散协议，以便系统安全。
相同的安全模型可以应用于在运营商完全失败的情况下资金的去向（减去运营商）。 但这会带来单个密钥丢失或不配合燃烧资金的风险，因此您也可以将其设为传统的 m-of-n 多重签名。
我认为这种类型的设置完全没有问题，它实现了确保用户的资金不会被不可挽回地烧毁的目标，而不会对信任模型造成巨大的改变。 最终，如果您不是 BitVM 合约的直接参与者，即您自己持有这 n 个密钥之一，您仍然信任某种形式的联盟。 在 7 中 5 的多重签名中，只需要信任一个成员诚实就能保证安全，这显然比信任 3 个人要好，但这仍然是一种委托信任的形式。
包起来
归根结底，我认为 Taproot Wizards 发现的流动性紧缩问题是一个非常合理的问题。 根据相关挂钩的具体架构，它可能会带来问题，从完全烧毁用户资金，到即使没有恶意行为也损失运营商的资金，再到简单地创建一个不断增长的退出队列，而无需停止存款或退回到n-of-n 组绕过队列。
然而，在我看来，这并不意味着使用 BitVM 来确保双向挂钩的想法从根本上来说是一个错误的想法。 我想我已经提出了很多方法，具体的实施可以支持或缓解这个问题，最终实现 n-of-n 组现有的现实，以及在失败案例中将资金推向授权组的可能性处理提款可以解决资金永久损失的风险。
最后一点，这个领域的发展速度在过去一年左右达到了我在此期间从未见过的速度，我认为在讨论这些发展时退一步并保持冷静的头脑很重要看看关于权衡和风险的讨论。 是的，公众认知是这些公共对话的一个方面，但这些讨论应该植根于准确理解当前问题的目标。 这不应该先于试图非法或捍卫任何特定的公众观念而退居二线。
#BitVM #流动性紧缩问题
