在本文中，我们将讨论MAST的概念及其在比特币协议中的应用。 我们将考虑MAST可以实现的属性，以及使用它的好处。 对于喜欢比特币协议和其他创新支付系统的读者来说，这篇文章将很有趣。 在在线
区块链课程“
比特币中的MAST ”的框架中，还针对该主题进行了单独的演讲。
MAST的概念意味着使用Merkle树和抽象语法树来设置在交易输出上花费硬币的条件。 让我们考虑一下它是如何工作的。
默克尔树
因此，您可以示意性地描绘Merkle树。
有些数据需要获取校验和，即从所有数据中计算哈希值。 但是，与将所有这些连接起来并为哈希函数提供单个值不同，Merkle Tree提供了另一种方法。 每条数据分别进行哈希处理。 然后将生成的哈希值成对连接并再次哈希。 依此类推，直到获得一个涵盖所有数据的哈希值。 此值称为Merkle Root。
Merkle Tree使您可以检查Merkle Root中单个数据的出现情况，而无需拥有所有其他数据。 这是宝贵的财产。
假设用户拥有Merkle Root，并且一笔交易的数据（在上图中以红色表示）。 然后，用户可以采用丢失的哈希值链（它们在图中用蓝色表示），以验证此事务是否是Merkle Root的一部分。 缺少的哈希值称为Merkle Branch。 对于特定事务，可以从存储完整块的主机请求它们。
这种在多个协议中使用散列多个数据的方法。 最著名的示例是作为块一部分的交易的散列，以及传输到BitTorrent网络以生成种子文件的文件部分的散列。
抽象语法树
现在，让我们了解抽象语法树。 下图显示了一个语法树，描述了一个非常简单的循环。 在这里，树的蓝色节点由树表示，这意味着运算，绿色是变量，红色是常量。 树的边缘指示操作之间的过渡。
因此，描述了以特定顺序执行的循环。 首先，检查变量A和常量32的相等性，如果不成立，则转到循环的主体，在变量的赋值给变量A两个值之和：变量A本身和常量2。这是抽象语法树的一般结构。
什么是MAST？
我们已经准备了理论基础，现在我们将确定MAST是什么以及它的好处是什么。 MAST是默克尔化的抽象语法树，它使用Merkle树和抽象语法树的思想来指定互斥条件以消费硬币。 同时，比特币脚本像往常一样充当描述条件的语言。 MAST概念增强了隐私并减小了交易规模。
概念发展和当前位置
Russell O'Connor，Pieter Wuille，Peter Todd和Johnson Johnson等人开始在比特币社区中发展和推广MAST的想法。 2016年初，发布了一项提案，以改善编号为114（BIP114）的比特币协议，该提案描述了使用见证程序实现此方法的选项之一的规范，而该规范又随SegWit更新引入。 BIP114还提供了一种软件实现，可在比特币协议中添加新的共识规则。
后来，在2017年，他们提出了MAST概念的替代实现，在BIP117中进行了描述。 它基于BIP114并进行了一些修改。 截至2018年，这两项提案仍在审议中。
请注意，可以使用软叉协议更新将MAST集成到比特币中。 这也许是这个概念的最重要特征。
图上的MAST
在示意图上，默克尔化抽象语法树将如下所示。
在此，MAST Root是将放置在事务输出中的根哈希值。 导致支出硬币的条件的树枝的哈希值以蓝色表示。 因此，这些分支包含可以使用硬币的互斥条件。 因此，花费硬币的人将使用一个分支或另一个分支。
黄色表示使用比特币脚本设置的条件。 此外，建议将硬币最可能使用的条件放置在尽可能靠近树根的位置-这将使硬币的所有权证明更小。
比特币交易问题
让我们确定在使用比特币脚本花费硬币的条件通常设置期间发生的问题。 首先，也是最重要的一点是，接收者需要描述或转移其想要接收付款的条件，以便发送者在其交易输出中指明这些条件。 MAST和P2SH解决了这个问题。
第二个问题：困难的条件在事务输出中占用大量内存。 结果，尽管接收者指示它们，但发送者必须为建立这种困难的接收硬币的条件付费。 P2SH和MAST也可以解决此问题，从而转移了在交易中包含大量数据的需求，这些数据将花费很多，因此增加的佣金将由接收者而非发送者支付。
第三个问题是放置在事务输出中的ScriptPubKey的大小和操作数（即OP_CODE）受到限制。 MAST概念可让您几乎完全摆脱这些限制，而不会因相互排斥的条件而损害可靠性。
第四个问题：发送硬币时，每个人都会立即看到他们的消费情况。 MAST允许您隐藏消费条件，直到消费为止。 而且，将仅公开实际使用的那些条件，而不是所有可能的选择。
MAST在比特币中提供的属性
其中一项是通过隐藏最终未使用的支出条件来提高用户隐私级别。 通过证明MAST根目录中仅包含某些条件并满足这些条件，可以实现此属性。
另一个积极的功能是可以指定更多和更复杂的硬币消费条件。 例如，使用MAST，您可以为单个交易输出指定数十万个不同的多重签名选项。 同时，花费硬币的条件和硬币的所有权证明将非常紧凑。
另外，可以在不增加交易规模的情况下在区块链上记录任意数量的数据。
该图显示了根据BIP114的MAST结构的变体。 作为附加消息，哈希值以蓝色表示，比特币脚本以黄色表示，任意数据以红色表示。 版本值包含在树的顶部。
简化的MAST方案
在此指定了两个互斥的硬币消费条件。 在第一种情况下，可以通过提供一个签名并等待一定时间来花费硬币，而在第二种情况下，您需要提供多个签名。 用户可以选择其中一个选项，而第二个选项的条件不会透露。
MAST的实际应用
在第一种情况下，可以将MAST用于HTLC（哈希时间锁定合同）的更优化实现，该协议在闪电网络协议中使用。 在另一个方面，对于托管的更优化实现。
MAST使得使用多重签名实现非常大的结构成为可能。 这将有助于解决诸如比特币被盗或丢失等紧迫问题，在某些情况下甚至可以让您放弃冷藏。
感谢MAST，在许多情况下，您可以拒绝OP_RETURN操作将数据添加到比特币区块链。 相反，您可以将此数据包含在树中，并在必要时证明特定数据已记录在比特币区块链中。 在这种情况下，您将不需要增加区块链本身的大小。
数据量优化
让我们注意最终落入区块链的数据量的优化。 请仔细查看下面的图表。 垂直轴以字节为单位指示数据量，而刻度本身为对数。 水平轴指示花费硬币的替代条件的数量。
蓝线表示不使用MAST的情况下数据量对条件数量的依赖性。 红线表示使用MAST时数据量对条件数量的依赖性。 蓝线是P2SH的比特币脚本大小限制。 绿线是见证结构中的比特币脚本大小限制。
结论很简单。 MAST概念使您能够以相同的验证可靠性和强大的功能存储少得多的数据。
现在，让我们继续关于该主题的常见问题。
常见问题
-是否将MAST根目录设置在见证结构中或在哪里列出？MAST根以及定义它的数据将在ScriptPubKey的事务输出中指示。 该数据将占用25-35个字节，最有可能将其轻松编码为通常的比特币地址。 在证明硬币所有权的见证人结构中，将显示Merkle Branch和满足支出条件的数据，例如电子签名。
-是否会扩展比特币脚本语言中的许多可用OP_CODE？目前尚不明确，因为该提案正在审议中，并且可能还会进行其他更改和改进。 为了使用MAST的灵活性，可能会添加OP_CODE（例如OP_MERKLEBRANCHVERIFY）。 也许他们会提供其他有用的东西，但这仍然是不准确的。
-在不久的将来是否有可能整合MAST？当然有一个可能性，但是它很小。 毕竟，此更新很重要，但并不紧急，因此它可以等待开发人员考虑其他协议改进。 后来，他们可以一次集成一次更新中的多项改进，就像SegWit一样。