默克尔化抽象语法树是一项为比特币提议的升级，可以实现更小的交易体积、更好的隐私性，以及更大的智能合约。在本文中，我们会解释MAST的基本原理，讲解其潜在好处，并总结目前一些包含这项技术的提案。
问题：没用到的脚本数据
中本聪给了比特币一个有趣的特性，是他没有写在比特币白皮书里的。除了可以通过公钥来接收比特币、用私钥数字签名来花费比特币，用户还可以编写程序，当成动态的公钥和签名来用。
当你指定一个脚本后——这在每一种比特币钱包里都是基本操作——由比特币网络强制执行的比特币协议就不会让任何人花费这个脚本所控制的比特币，除非脚本返回True。这让你可以指定资金的花费条件，称为“encumbrances”，比如要求花费的交易一定要得到你的私钥签名。
更加复杂的财产条件也是有可能实现的，比如下面这个例子，我们会用它贯穿整篇文章：Alice希望能够随时花费她的比特币，但如果她连续三个月没有花费自己的比特币，她希望自己的兄弟姐妹Bob和Charlie拥有自己的比特币，在任何两人能达成一致的地方使用这些财产。
下面这个条件脚本就实现了上文所说的目标，它不仅纳入了Alice的公钥，但也加入了以下条件性逻辑：一个超时条件，以及Bob和Charlie的公钥。
在当前的比特币协议中，上述所有的数据都必须添加到区块链中，在Alice的比特币花费的时候，也包括在特定的花费行为中完全无关的脚本部分，也要曝光。就比如在Alice花费自己的比特币时Bob和Charlie的公钥也要曝光。
未使用的条件数据增大了交易的体积，也使用户在必要之外曝光了更多的隐私，同时，也使体积而非验证代价成为智能合约大小的主要限制因素。MAST旨在改善这些情况，办法就是移除在区块链上直接包含未使用的脚本部分的需要。
MAST初始构想
MAST?1?背后的观念来自于两种久已存在的概念，?抽象语义树和默克尔树。抽象语义树是一种通过将一个程序分割成独立的小块来描述程序的方法，这样会让程序变得更容易分析和优化。为了生成一个AST，你需要把所有的方程与其前提用箭头连接起来，直至所有的前提都被找出。下图即是上文示例脚本的AST。
另一方面，默克尔树则可用来验证某个元素是否是属于某个集合，且无需知晓整个集合的全貌。举个例子，比特币的简易支付验证钱包就使用默克尔树来验证某笔交易是否存在于某个区块中，这样无需下载完整的区块，可以节省带宽。
要生成一棵默克尔树，先要把每个元素都各自哈希一次，生成各自唯一的标识符；然后这些标识符配对之后再次哈希，生成这一对标识符的标识符；如此不断重复，直至只剩下一个标识符，称为“默克尔根”，它就是一个短小精悍、但是标记了整个集合的标识符了。
在验证某个元素属不属于某个集合时，拥有整个集合的人可以向你提供从那个元素到默克尔根路径上的所有标识符。这样就能证明，这个元素确实在这个集合内。
简而言之，AST背后的技术让你可以把一个程序分成多个小块，而默克尔树让我们可以验证这些小块确实是一个完整程序的一部分，且不必暴露整个程序。这就是MAST的基本原理，可以让花费者用一个默克尔证明来替换在单次交易中没有用到的条件——减少交易体积、提高隐私性，并支持更大的合约。
MAST的一个例子
我们以上文的财产条件为例，为我们希望的两种可能场景分割为两个子脚本：
Alice可以随时花费自己的比特币或者，如果连续三个月使用Alice的签名来花费，则需要Bob和Charlie的签名来花费此中的比特币基于这两个独立的子脚本，创建一棵默克尔树：
这棵默克尔树的树根最终标识了Alice的完整财产条件，而且只有32字节的体积。此后，Alice可以使用一个替代性的条件脚本，声明：一笔花费交易，只有提供其中一个子脚本连接到默克尔根的证据、并且子程序返回True的时候，才是有效的。
子脚本的默克尔证据，形象地画出来会像下图这样，就看用的是哪个子脚本了：
好处#1——更小的交易
我们先来看看MAST如何能让复杂财产条件的用户创建更小的交易。这是MAST给我们带来的第一个好处。
在上文的例子中，我们使用了一个具备两个子脚本的财产条：要么Alice自己花自己的钱，要么Bob和Charlie在等待三个月之后一起花她的钱。我们来设想一个无限延伸的版本：其第三个子脚本指明，三个月零一天后，Dan和Edith可以花费此中的资金；第四个子脚本指明，三个月零二天后，Fred和George可以使用这笔资金；等等等等
这个思维实验可以使我们得到下面的这张图，它显示了，子脚本的数量与需要加入区块的条件数据量，在有和没有MAST时候的关系。
只有这些信息，你是没法知道Alice以外是否还有人能花费这里的资金、以及他们花费是需要面对什么约束条件的。你可以从MAST中猜测可能有一些别的条件，但也仅限于猜测而已——Alice可能只是假装她的默克尔树还有其它可以花费的部分。
对应地，如果你看到的是另一个分支，你不会知道这笔资金在超时之前是否能花费，也不知道是不是只需一把私钥就能花费它。你同样可以猜测存在其它的花费条件，但你没法在区块链上确证这一点。
保证未使用的财产条件不曝光在某些时候非常有用，比如某些商人可能希望自己的智能合约尽可能保密，不要被潜在的竞争对手看到。这一点与某些标榜自己是专为智能合约设计、但实际上又不能为这些合约提供隐私性的山寨币恰好相反。
隐私性也可以为所有的比特币用户提供额外的好处，即使某些用户根本不在乎财产条件的隐私性。假设从本文一开始，Alice就是唯一一个使用非MAST条件模板的人。因为所有条件都是公开的，那么任何人都可以跟踪Alice的花费行为，只需在区块链上观察这个模板被使用的情形即可，这样Alice的隐私就荡然无存。
任何让识别特定用户更容易的设计，也会让人们可以更容易地区别对待他们的比特币和别人的比特币，这叫做“同质性的缺失”。如果某些人知道了Alice的财产条件长什么样，他们就可以贿赂或者强迫矿工不要打包这些人的交易，以此阻止Alice使用自己的比特币。
MAST不能完全解决这个问题，因为Alice仍然需要揭示部分的产权负担，但是许多别的复杂财产条件可以解析成少量的简单MAST类型条件。
举个例子，Alice的默认花费行为看起来就像其它只需提供单签名的普通支付行为，所以Alice的基于MAST的交易跟其它基于MAST的单签名交易就没有任何分别。这反过来提高了Alice的隐私性，也提高了她的资金的同质性，以及所有使用基于MAST的单签名条件的用户的货币同质性。
MAST的这一好处还很有可能与其他提高比特币隐私性和同质性的提议结合在一起。有些提议是让某些复杂的财产条件可以用单签名来使用，比如PieterWuille和GregoryMaxwell的“通用门限树”、AndrewPoelstra的?“无脚本式脚本”，还用ThaddeusDryja的?“离散对数合约”；MAST就可以和这些方案相结合。
但即使这些方案都不能在比特币上实现，MAST自身也能为复杂财产条件的用户提供更多的隐私性和可互换性，不论是与当前相比，还是与支持用户自定义智能合约的山寨币相比。
好处#3——更大的智能合约
比特币现在为单个脚本设置了三种不同的体积限制：裸露脚本大小不能超过1万字节，在2010年7月引入；P2SH脚本不能超过520字节；segwit脚本不能超过1万字节。我们把这几个大小在上面的图中展示出来：
可以看出来，即使是极端的无限延长的例子，MAST也比当前所有的机制支持更多的条件分支。实际上，MAST的扩展性非常之好，以至于即使你拥有现在可观测的宇宙中所有的能量，若是只用来创建一棵标准的默克尔树，其默克尔证据也只有8448字节。即使是这么大的默克尔证据，任何现在的笔记本电脑，都能在1毫秒之内完成验证。
因为免去了全节点处理未使用的子脚本的任务，MAST还能帮比特币脚本绕过别的一些硬性限制。在这一方面，MAST很好地保存和延伸了比特币智能合约长期的设计目标，也就是合约的负担应尽可能由合约的参与者承担，而节点付出了带宽、内存和处理能力，却无法得到补偿，因此应尽可能少承担。
所以，MAST的真正成就不是让比特币用户可以创建更加高级的合约，而是它打开了这种可能性，还不会给比特币的节点增加新的负担。
实现MAST：现有的多种提议
迄今为止，bitcoin-dev邮件组里提出了两种方法在比特币协议中启用MAST，两种方法都仍在草案阶段，可能会有所变更。
第一种提议是JohnsonLau提出的?BIP114，使用了一个基于隔离见证的延伸特性，使得原生的隔离见证地址可以成为对MAST财产条件的默克尔根的承诺。花费交易因此可以从树上选择一个子脚本。
第二种提议是MarkFriedenbach提出的两个未命名的BIP，它提高了脚本语言的灵活性，使得编程者可以编写脚本来验证基于MAST的财产条件。如果用Friedenbach更喜欢的方式来实现，那会让比特币现在支持的三种脚本类型都可以使用默克尔证据。
这几种提议互有短长，但都提供了上文所说的MAST的好处。每一个都可以用软分叉来激活。
结论：我们什么时候才能用上MAST？
上文我们讲解了MAST的好处，也简要提及了两种在比特币上实现MAST的提案，你可能也好奇，什么时候我们能用上MAST。遗憾的是，我也不知道。
从理念，到提案，到完整的实现，到提议软分叉，到激活软分叉，道阻且长。围绕隔离见证升级，为期两年的大戏已经很清楚地展现了这一点。
但从我的角度看，MAST背后的基本理念已经在比特币技术社区中获得了广泛的支持，而对MAST最感兴趣的开发者也会继续开发，除非有人能证明这种技术完全不靠谱。有朝一日这些开发者成功提出可供同行审议的软分叉代码，就轮到读者你们和其他比特币用户，来决定MAST是否能成为比特币协议的一部分了。
延伸阅读
BIP114:MerklizedAbstractSyntaxTree?byJohnsonLauTailCallSematics?byMarkFriedenbachMerkleBranchVerifyopcode?byMarkFriedenbachDiscussionatcore.techmeetup?byMarkFriedenbach(transcribedbyBryanBishop)MerklizedAbstractSyntaxTrees?byJeremyRubin,ManaliNaik,NityaSubramanianAnexplanationandjustificationofthetail-callandMBVapproachtoMAST?byMarkFriedenbachMakingMASTMeaningful?byBrianDeeryThenextsteptoimproveBitcoin?byAaronvanWirdum
致谢
感谢MarkFriedenbach、JimmySong和JohnNewbery对本文草稿的评论。当然，文中出现的所有谬误，都属于我的责任。
脚注
RussellO’Connor被公认为是第一个描述了MAST雏形的人，有些来源则还会加上PieterWuille。来源：PeterTodd、GregoryMaxwell和MarkFriedenbach。感谢JohnNewbery。
根据自由创作-分享协议4.0，保留署名权，且在后续分享和改编中应维持同样的要求。
原文链接:
https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f
作者:DavidA.Harding
翻译:?阿剑
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。