解锁比特币更多应用，Miniscript 的昨天、今天和明天

译者前言：由于比特币脚本（Script）的存在，今天比特币可以实现简单的交易功能和各种多重签名、原子互换、闪电网络交易。 然而，脚本的功能不仅限于这些，其复杂性却限制了更多应用的可能性，而Miniscript的目的就是让比特币脚本更易于使用，最终解锁比特币的更多应用。

对此，Pieter Wuille 和 Andrew Poelstra 写了一篇文章《Miniscript：精​​简的比特币脚本》来解释 Miniscript 的起源和作用，以及它未来的发展方向。

以下为译文：

（图片来自blockstream）

比特币脚本简介

比特币一直有一种机制，可以通过比单一密钥更复杂的策略使代币可消费：脚本系统。 虽然该脚本主要用于单密钥支付，但它也是各种多重签名钱包、原子交换结构和闪电网络的基础。

然而，这些并不是脚本能够实现的全部功能。 脚本可用于表达发出交易所需的复杂条件，例如（A、B、C中的两个）和（D或（E和F）），其中AF表示唯一键和哈希原像校验、时间锁、和一些更奇特的结构。

比特币脚本的问题：难以验证

但我们未能充分发挥比特币脚本潜力的原因之一是为复杂任务构建脚本非常麻烦：很难验证它们的正确性和安全性比特币交易软件，甚至很难找到最经济的编写方式。

这是问题的一部分：即使你知道正确的脚本、设计应用程序和协议来协商和构造交易，每次你设计一个新的构造时，都需要大量额外的开发工作。 每增加一次，就需要更多的工程资源来进行分析和质量保证。

那么，如果比特币应用程序可以使用任何脚本，而不仅仅是一些脚本设计呢？ 我们不再局限于使用一次性设计，而是可以根据用户指定的要求开始设计应用程序。 钱包开发人员还可以引入更多基于脚本的选项，同时保持与其他钱包的互操作性。

什么是Miniscript

让我们进入Miniscript的世界，Miniscript是一种结构化表达比特币脚本的语言，支持高效分析、合成、通用签名等功能。

比特币脚本的一个例子：

 OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_CSV OP_ENDIF

其中A和B代表公钥，转换成Miniscript表示法为：

or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))

这个例子清楚地表明，脚本的语义允许在 144 个区块后出现 A 签名或 B 签名时支付。 大多数有意义的脚本都可以这样写。 使脚本具有可读性只是Miniscript的特性之一，其主要目的是实现脚本的自动推理，如下面的应用实例所示。

Miniscript的应用

使用比特币脚本构建复杂的支出条件目前非常困难，需要为每个新用例开发、测试和部署专用软件。 而 Miniscript 可以跨越任意一组支出条件，并且通常比临时解决方案更简单、更可靠。

应用一、优化脚本

其中一个例子是找到一个最佳脚本来实现一组给定的支出条件。 在比特币脚本中，有许多不同的方法需要签名，描述连接或分离，或实现阈值。 即使对于经验丰富的比特币脚本开发人员，正确的选择也取决于满足不同条件的相对概率，并且难以计算。 还有我们的在线编译器，它可以立即找到与给定支出策略相对应的最佳 Miniscript。

介绍中的示例适用于以下编译策略：

or(99@pk(A),1@and(pk(B),older(144)))

这是这样写的，左边的 A 签名有 99% 的概率出现，而右边的（144 个区块后的 B 签名）有 1% 的概率出现。

应用 2. 全民消费

一旦找到工作脚本，许多脚本使用的一个常见障碍是不同支出机制之间缺乏互操作性。 希望实现长期时间锁（timelocks）或复杂的多重签名需求的用户可能会担心这一点。 另一方面，Miniscript 允许通过直接表达支出条件来表达任意策略，这样任何人都可以：

计算脚本的相对地址； 确定哪些签名者在给定时间签名是必要的或足够的； 给定足够的签名集，生成有效的交易；

用户不必担心所有参与者是否都在使用兼容的软件，或者当需要这样的时间锁定设置时该软件将继续存在。 他们也不必担心他们的需求可能会以与签名软件不兼容的方式发生变化，确保使用比特币脚本不会限制他们。

申请三、储备金证明

与签名问题相关的是储备证明问题，这是一个公司证明它可以在不实际使用比特币的情况下花费部分比特币的过程。 虽然这方面的工具已经存在，例如 Blockstream 的储备证明工具，但行业中没有通用标准。 如果没有 Miniscript，可能就不会有涵盖当前托管解决方案多样性的储备证明标准。

支出策略的组成部分

让我们看一个受互操作性需求限制的比特币脚本开发人员的具体示例。 以一家托管大量 BTC 的公司为例，只有在大多数董事同意的情况下，它才会使用这些比特币。 然而，一些独立董事希望使用他们现有的钱包软件和硬件，并且不希望参与需要他们使用专用应用程序的单一密钥签名方案。

如果没有 Miniscript，生成一个包含所有签名者要求的脚本，同时向所有签名者保证完整的脚本是合理和完整的，并且他们的钱包软件与结果兼容，将是一个无法克服的挑战。

使用 Miniscript，这些主管可以简单地在他们的钱包软件中编写策略，构建一个描述门槛要求的单一策略，然后将其编译成 Miniscript。 他们可以直接验证编译器的输出是否与原始策略匹配，以及原始策略是否满足每个人的需求。 然后，他们可以使用任何兼容 Miniscript 的软件来计算接收硬币的地址，在花费时收集签名，并将这些签名组合成有效的交易。

一个简单的假设示例：一家公司正在使用一个定制的多重签名存储钱包，有两名董事，其中一名使用 Blockstream Green 钱包（配置为 2-of-2 多重签名，经过一段时间延迟后变为 1-of-2 )，而另一个正在使用 Electrum 钱包（标准一对一）。 如果没有允许组合安全、可互操作的脚本策略的工具，使用绿色钱包的董事就不可能将他们的策略作为“参与者”添加到公司的多重签名方案中。 而如果Green和用于构建公司多重签名的软件都支持Miniscript，那么两位董事就可以直接使用自己喜欢的钱包比特币交易软件，甚至不知道钱包的底层脚本是什么。

动态联邦

Miniscript的作用，我们可以在Blockstream的Liquid侧链中找到一个具体的例子。 Blockstream 目前正在开发一项功能（内部称为动态联合），这是一个允许现有 Liquid 成员管理新成员添加或更新以控制联合托管比特币可用性的脚本。 Miniscript 为联盟成员提供了快速高效地构建此类脚本的工具（事实上，Miniscript 编译器发现了现有 Liquid 脚本的 22 字节缩短版本，比我们最初的手动优化脚本工作量节省了 5%）。 但更重要的是，Miniscript 允许成员自动验证提议脚本的重要属性，减少成员相互协调或对提议脚本执行昂贵的手动安全审计的需要。

特别是，成员可以自动验证任何脚本提案是否包括：

他们自己的钥匙； 一个时间锁定的紧急支出条件，它是正确的并且在未来足够远。

它还允许他们验证新联邦的参与者是否有能力使用旧联邦控制的硬币。 此检查对于确保此转换不会导致硬币丢失至关重要，即使对于在转换时将硬币转移到系统中的用户也是如此，如果没有 Miniscript，这几乎是不可能的。

Miniscript的历史

Miniscript 的想法可以追溯到 2018 年夏天。当年 7 月中旬，Pieter Wuille 推出了 Bitcoin Core 的输出描述符方案，这是一种描述 Core 支持的多种不同地址类型的通用方法。 与此同时，时任 Blockstream 实习开发人员的 Andy Chow 正在研究部分签名的比特币交易（PSBT，也称为 BIP 174），这是一种在钱包领域越来越受欢迎的钱包互操作性协议。 受到广泛关注。

PSBT 的一个重要部分是终结器，它是从 PSBT 中包含的一组签名者数据组装实际比特币交易的参与者。 该程序集需要满足脚本的知识，这意味着支持 PSBT 的钱包必须实现自己的专用终结器，这需要额外的开发并限制互操作性。

当时，Andrew Poelstra 正试图将 PSBT 实现引入 Rust 版本的比特币（用 Rust 编程语言编写的通用比特币库）软件中（这个实现最初是由 Carl Dong 提出的）。 Poelstra 在 IRC 通讯频道上观察到：

“如果你有高度结构化的脚本模板，你就不需要真正理解脚本。”

正是这个想法最终成为了 Miniscript 的核心。 事实上，Poelstra 和 Wuille 一直在从事与托管相关的项目，但由于缺乏可用于复杂的多参与者脚本的标准工具而感到沮丧。 两人于 2018 年 8 月会面讨论此事，Wuille 建议实施这些“高度结构化的脚本模板”作为比特币核心输出描述符的扩展。

随着扩展的形成，它演变成比特币脚本的结构化子集，最终成为 Miniscript，以及一种更简单的“政策语言”，可以直接表达支出条件，并编译成 Miniscript。 2019 年 1 月，Wuille 在斯坦福区块链会议上展示了该计划的初步结果。

今年 5 月，Sanket Kanjalkar 加入 Blockstream 进行为期三个月的实习，重点是实现 Miniscript 工具并帮助其与 Bitcoin Core 集成。 在他的帮助下，MiniScript 变得更小、更高效、更易于分析，并且更好地防止了可伸缩性问题。

经过这些反复的工作，终于形成了今天的Miniscript。

相关工作

Miniscript 建立在并补充了比特币生态系统中的许多其他项目。 特别是，Miniscript 扩展了 Bitcoin Core 的钱包输出描述符并补充了 PSBT，如上所述，用于完全通用的更新器和终结器。

可以将 Miniscript 与 Ivy 进行比较，Ivy 是另一种旨在使比特币脚本的高级功能易于访问的语言。 但是，相对于Ivy，Miniscript是脚本（子集）的直接表示，这意味着可以有效地验证“miniscript”的正确性和健全性。 Miniscript 还可以接受许多其他形式的静态分析，这是 Script 和 Ivy 都做不到的。

Miniscript 的策略语言与 Ivy 类似，都是抽象的，都必须编译才能在区块链上使用。 然而，Miniscript 的策略语言在结构上与 Miniscript 本身非常相似，因此很容易验证编译器的输出是否与编译器的输入相匹配（实际上，这甚至可以手动检查），并且很容易验证满足用户期望。

另一种与 Miniscript 相关的区块链语言是 Blockstream 的 Simplicity。 与 Miniscript 一样，Simplicity 是一种低级语言，旨在直接嵌入到区块链交易中。 此外，Simplicity 还支持多种形式的静态分析，这在部署区块链合约时非常重要，但在以太坊 EVM 等替代方案中很难甚至不可能实现。

此外，Miniscript 并不像 simplicity 那样强大，无法表示任何可计算函数，它的范围非常有限：它可以表示签名要求、时间锁、哈希原像以及它们的任意组合。 这种范围的缩小使 Miniscript 更容易解释它涵盖的用例，而且重要的是，允许它在现有的比特币区块链上工作。 相比之下，简单性与比特币脚本截然不同，比特币脚本仍处于早期开发阶段。

未来的工作和结论

在设计 Miniscript 时，我们着手让比特币脚本更易于访问。 虽然很多工作都集中在调查和提议未来对脚本和比特币共识规则的修改以添加额外的功能，但我们也看到基础设施甚至没有以通用、安全、可组合和可互操作的方式使用。 现有的功能，这是目前缺乏的。

这项工作尚未完全完成。 我们有两个 Miniscript 实现（C++ 和 Rust 版本）和一个策略编译器，但为了使该技术易于访问，我们需要将其集成到通用软件中。 通过与 Miniscript 兼容的 PSBT 实现（更新器和终结器），即使没有明确支持，许多 PSBT 签名者（包括基于硬件钱包的签名者）也可以用于复杂的脚本。 此外，编译器可以改进，因为在策略到脚本的转换中有许多尚未考虑的优化。

一路走来，我们学到了很多：

脚本资源限制使策略优化复杂化：大量共识和标准强加的资源限制（最大操作码、最大脚本大小、最大堆栈大小……）的存在使得很难找到最佳的好脚本。 这很有趣，因为它可能会指导未来的脚本改进建议。 与此相关，我们也惊讶地发现，比特币共识规则实际参与执行 OP_CHECKMULTISIG(VERIFY) 的密钥数量计入每个脚本 201 个非推送操作码的限制。 可变的见证大小使费用估算复杂化：简单的支付和多重签名结构的见证大小独立于精确的现有密钥集。 一旦我们转向更复杂的脚本，见证规模就会变得更大，这可能会使成本估算变得复杂。 特定交易输出的潜在签名者可能需要对将采用的廉价路径做出乐观的猜测，并相应地构建交易。 如果并非该路径的所有密钥或哈希最终都可用，则交易本身可能需要更改以说明增加的费用。 Segregated Witness (Segwit) 堆栈编码使优化复杂化：因为 segwit 的输入堆栈不再编码为脚本，而是直接编码为堆栈元素列表。 这具有将“true”的编码从 1 个字节更改为 2 个字节的不幸副作用。 因此，Miniscript 需要关心哪些子表达式进入 if/else/endif 结构的哪一侧。 可扩展性：由于隔离见证，交易可扩展性不再是协议正确性的破坏者，但它仍然会产生不利影响（例如广播交易时费率的不确定性，减慢紧凑块）传播并干扰哈希锁作为全局的使用发布机制）。 出于这些原因，我们在设计 Miniscript 时考虑到了不可延展性，并了解了一般证人不可延展性的推理。 为实现这一点，Miniscript 依赖于某些特定于隔离见证的规则。 消除公共子表达式很困难：尽管进行了多次尝试，Miniscript 仍然不支持优化重复子表达式。 虽然这在某些特定情况下是可能的，但通常在脚本中似乎很难做到。 添加某些堆栈操作操作码可能会改变这一点。