什么是比特币 Merkelized 抽象语法树？ 这是为了什么？

Merklized Abstract Syntax Trees (MAST) 是比特币的提议升级，可实现更小的交易规模、更好的隐私和更大的智能合约。 在本文中，我们解释了 MAST 的基本原理，解释了它的潜在好处，并总结了一些当前采用该技术的提议。

问题：未使用的脚本数据

中本聪赋予了比特币一个他没有写在比特币白皮书中的有趣特性。 除了通过公钥接收比特币和使用私钥数字签名花费比特币外，用户还可以编写程序（称为“脚本”）作为动态公钥和签名。

当你指定一个脚本时——这是每个比特币钱包的基本操作——由比特币网络强制执行的比特币协议将不允许任何人花费脚本控制的比特币，除非脚本 Return True。 这允许您指定可以花费资金的条件，称为“产权负担”（财产条件），例如要求花费的交易由您的私钥签名。

更复杂的财产条件也是可能的，例如下面的例子，我们将在整篇文章中使用它：爱丽丝希望能够随时花费她的比特币比特币的好处是什么，但如果她连续三个月不花掉她的比特币（可能死亡）或无行为能力），她希望她的兄弟姐妹 Bob 和 Charlie 拥有他们的比特币，并在他们同意的任何地方使用它们。

下面的条件脚本实现了上述目标，它不仅包含了爱丽丝的公钥（需要用她的私钥验证签名），还添加了以下条件逻辑：超时条件，以及鲍勃和查理的公钥。

在目前的比特币协议中，上述所有数据都必须被添加到区块链中，而当爱丽丝花费比特币时，其中还包括与具体消费行为完全无关的部分脚本，这些部分也必须被暴露。 例如，当 Alice 花费她的比特币时，Bob 和 Charlie 的公钥也会暴露。

未使用的条件数据会增加交易的规模，并使用户获得不必要的隐私。 同时，也使得规模而非验证成本成为智能合约规模的主要限制因素。 MAST 旨在通过消除将未使用的脚本部分直接包含在区块链上的需要来改善这些情况。

MAST最初的想法

MAST1 背后的想法来自两个长期存在的概念，抽象语义树和默克尔树。 抽象语义树（AST）是一种通过将程序分解成独立的小块来描述程序的方法，使程序更易于分析和优化。 要生成 AST，您需要用箭头将所有方程与其前提连接起来，直到找到所有前提。 下图是上面示例脚本的AST。

另一方面，Merkle 树可用于在不知道集合全貌的情况下验证元素是否属于集合。 比如比特币的Simple Payment Verification Wallet（SPV wallet）就是使用Merkle树来验证某笔交易是否存在于某个区块中，这样就不需要下载完整的区块，可以节省带宽。

要生成 Merkle 树，首先对每个元素进行一次哈希处理，以生成其自己的唯一标识符； 然后将这些标识符配对并再次哈希生成这对标识符的标识符； 以此类推，直到只剩下一个标识符，称为“默克尔根”，这是一个标记整个集合的短标识符。

当验证一个元素属于一个集合时，拥有整个集合的人可以为您提供从该元素到 Merkle 根的路径上的所有标识符。 这证明该元素确实在集合中。

简而言之，AST 背后的技术可以让你把一个程序分成小块，而 Merkle 树可以让我们在不暴露整个程序的情况下验证这些小块确实是一个完整程序的一部分。 这是 MAST 的基本原理，它允许消费者用 Merkle 证明替换单笔交易中未使用的条件——减少交易规模，提高隐私性，并支持更大的合约。

桅杆的一个例子

我们以上面的属性条件为例，针对我们想要的两种可能的场景比特币的好处是什么，将其分为两个下标：

Alice可以随时花费她的比特币（左下标）或者，如果连续三个月使用Alice的签名花费，则需要Bob和Charlie的签名才能花费比特币（下图右下标）

基于这两个单独的下标创建一个 Merkle 树：

这棵 Merkle 树的根最终确定了 Alice 的完整属性条件，它只有 32 字节大小。 此后，Alice 可以使用替代条件脚本，声明只有在其中一个下标提供了它连接到 Merkle 根的证明并且子例程返回 True 时，支出交易才有效。

下标的 Merkle 证明会像下图那样直观地绘制出来，这取决于使用的是哪种下标：

好处 1 - 较小的交易

我们先来看看 MAST 如何让拥有复杂财产条件的用户创建更小的交易。 这是MAST带给我们的第一个好处。

在上面的例子中，我们使用了一个带有两个下标的属性栏：Alice 花自己的钱，或者 Bob 和 Charlie 在等待三个月后一起花她的钱。让我们想象一个无限延伸的版本，其中第三个下标指定三个月后和有一天，丹和伊迪丝可以花掉这笔资金； 第四个下标指定三个月零两天后，弗雷德和乔治可以使用这笔资金； 等等等等

这个思想实验将我们引向下图，该图显示了下标数量与需要添加到块中的条件数据量之间的关系，有无 MAST。

这是一个对数图，意思相同：

虽然MAST交易的大小会比一开始没有MAST的同条件交易大，比如我们两个子脚本的条件，非MAST的交易大小会线性增加（随着子脚本的数量） ，而 MAST 交易量只会以对数方式增加。

如果以节省数据量为主要目标，我们可以进一步优化它。 对于许多物业条件，消费者可能会更频繁地使用其中一种。 例如，爱丽丝想要长寿，所以她构建的默克尔树将她的支出条件放在更靠近顶部的位置，其他所有条件都放在树的底部：

在这个设计中，MAST Merkel 证据在不同情况下的体积是不同的。 在最理想的情况下，Alice 还活着，花的是自己的钱； 在另一种情况下，爱丽丝死了，她的受益人来花钱。 我们在图表上展示了这些因素。

可以看出，Alice在使用资金时，无论她的财产条件下有多少受益人，交易数据量总是最优的； 而当她的受益人使用这些资金时，交易数据量也是一样的。 仅比上述标准构造的 Merkle 树多几个字节。

无论 Alice 选择什么样的安排，都可以看出 MAST 可以让多标属性条件交易变得更小，因此用户可以支付更少的费用，更高级的交易可以加载到区块中。

好处 2 - 更好的隐私

在上面的解释中，我们暴露了爱丽丝所有的财产脚本，但是你可以想象，如果爱丽丝花费她自己的比特币，你在区块链上只会看到下图左侧的数据：

只有这些信息，你无法知道除了 Alice 之外是否还有其他人可以在这里花费资金，以及他们在花费时需要面对什么限制。 你可以从 MAST 中猜测可能还有一些其他条件，但这只是一个猜测——爱丽丝可能只是假装她的默克尔树有其他可花费的部分。

相应的，如果你看到另外一个分支（也就是上图中右边的子脚本），你会不知道超时前资金是否可以花掉，也不知道是否可以用只有一个私钥。 可以花掉。 你也可以猜测还有其他的消费条件，但你无法在区块链上证实这一点。

确保不暴露未使用的属性条件非常有用。 例如，一些商家可能希望他们的智能合约尽可能保密，不被潜在竞争对手看到。 这与一些声称为智能合约设计但实际上并不为这些合约提供隐私的山寨币形成对比。

隐私还可以为所有比特币用户提供额外的好处，即使一些用户根本不关心财产方面的隐私。 假设从本文开始，Alice 是唯一一个使用非 MAST 条件模板的人。 因为所有条件都是公开的，任何人都可以追踪Alice的消费行为，只要观察这个模板在区块链上的使用情况，Alice的隐私就没有了。

任何可以更容易识别特定用户的设计也会让人们更容易将自己的比特币与其他人的比特币区别对待，这被称为“缺乏同质性”。 如果有人知道爱丽丝的财产状况是什么样的，他们就可以贿赂或强制矿工不要打包这些人的交易，从而阻止爱丽丝使用自己的比特币。

MAST 不能完全解决这个问题，因为 Alice（或 Bob 和 Charlie）仍然需要揭示一些产权负担，但是许多其他复杂的属性条件可以分解为少量简单的 MAST 类型条件。

例如，Alice 的默认消费行为看起来像任何其他只需要提供单一签名的普通支付行为，因此 Alice 的基于 MAST 的交易与其他基于 MAST 的单一签名交易没有区别。 这反过来提高了爱丽丝的隐私，以及她的资金的同质性，以及所有使用基于 MAST 的单一签名条件的用户的货币同质性。

MAST 的这一好处也可能与其他提议相结合，以提高比特币的隐私性和同质性。 有提议使某些复杂的属性条件可用单一签名，例如 Pieter Wuille 和 Gregory Maxwell 的“通用阈值树”、Andrew Poelstra 的“无脚本脚本”和 Thaddeus Dryja 的“离散对数合约”；MAST 可以与这些结合计划。

但即使这些解决方案都不能在比特币上实现，MAST 本身可以为拥有复杂财产条件的用户提供更多的隐私和互换性，无论是与当前的相比，还是与支持用户自定义智能合约的山寨币相比。

好处 3——更大的智能合约

比特币现在为单个脚本设置了三种不同的大小限制：裸脚本的大小不能超过 10,000 字节，于 2010 年 7 月推出； P2SH脚本不能超过520字节； segwit 脚本不能超过 10,000 字节。 我们在上图中显示了这些尺寸：

可以看出，即使对于无限扩展的极端情况，MAST 也支持比当前所有机制更多的条件分支。 事实上，MAST 的可扩展性非常好，即使你拥有可观测宇宙中所有的能量，如果你只用它来创建一个标准（平衡）的 Merkle 树，它的 Merkle 证据也只有 8448 字节。 即使对于如此大的 Merkle 证明，任何现代笔记本电脑都可以在 1 毫秒内对其进行验证。

MAST 还可以通过将全节点从处理未使用的下标的任务中解放出来，帮助 Bitcoin Script 绕过其他一些硬性限制。 对此，MAST很好地保留并延续了比特币智能合约的长期设计目标，即合约负担尽可能由合约参与者承担，而节点为带宽付费，内存和处理能力，但不能得到补偿，因此应尽可能少地承担责任。

因此，MAST 的真正成就不是让比特币用户创建（比以往任何时候）更高级的合约，而是它在不给比特币节点增加新负担的情况下开启了这种可能性。

实施 MAST：各种​​现有提案

到目前为止，在比特币开发邮件列表上已经提出了两种在比特币协议中启用 MAST 的方法，这两种方法仍处于草案阶段并且可能会发生变化。

第一个提案是Johnson Lau（化名“jl2012”）提出的BIP114，它使用了基于隔离见证的扩展特性，使得原来的隔离见证地址（bech32）可以成为对MAST属性条件的Merkle根承诺。 因此，支出交易可以从树中选择一个子脚本。

第二个提案是 Mark Friedenbach（别名“maaku”）提出的两个未命名的 BIP (1, 2)，它增加了脚本语言的灵活性，允许程序员编写脚本来验证基于 MAST 的属性条件。 按照 Friedenbach 喜欢的方式实施，这将使 Merkle 证明可用于比特币目前支持的所有三种脚本类型（裸脚本、P2SH 和隔离见证脚本）。

这几个提议各有优缺点，但都提供了上面提到的MAST的好处（字节数可能会增加或减少）。 每个都可以用软分叉激活。

结论：我们什么时候可以使用 MAST？

上面我们解释了 MAST 的好处，并简要提到了在比特币上实施 MAST 的两个建议。 您可能还想知道我们什么时候可以使用 MAST。 很遗憾，我也不知道。

从想法，到提案，到完成实施，到提出软分叉，再到激活软分叉，路漫漫其修远兮。 围绕隔离见证升级的两年大戏充分说明了这一点。

但在我看来，MAST 背后的基本思想已经在比特币技术社区获得了广泛支持，对 MAST 最感兴趣的开发者将继续开发它，除非有人能证明这项技术是完全不可靠的。 当这些开发人员成功提出可同行评审的软分叉代码时，将由您的读者和其他比特币用户来决定 MAST 是否可以成为比特币协议的一部分。