默克尔抽象语法树（MAST）旨在优化比特币性能，如果其被应用，这就意味着比特币交易将更具灵活性。MAST能够增加扩容，提供更好的用户隐私性，以及扩展比特币智能合约的灵活性。在这篇文章中，我们将探讨MAST的基础理论、潜在的优势、并就当前的比特币的发展提出建议。
痛点：未使用的脚本数据
中本聪赋予比特币一个有趣的特性，这个特性并未在原始的白皮书中提及。在比特币交易中，接收比特币不需要公钥，花费也不要求提供数字签名，中本聪赋予用户这样的职能，即通过编写程序（也称为脚本）来充当动态的公钥和签名。
当用户指定一个脚本时，即每个钱包中的默认值时，共识驱动比特币协议使得其他人不能花费你的比特币，除非脚本反馈为True。这允许用户指定限制，也可称为产权负担(encumbrances)（产权负担是指财产所有人以外的人对于此财产所拥有之任何权利或利益。）例如在支付交易时要求提供本人私钥签名。
复杂的产权负担案例，例如：Alice想要在任何时间花费她的比特币，但是如果她的比特币由于某些不可抗因素在三个月内并未花费（Alice去世或失去意识），并且Alice有意愿让她的兄弟姊妹Bob和Charlie拥有她的比特币，那么只需要他们提前达成共识例如在哪些地方可花费这些比特币就可以了。
以下所示的产权负担体现了如上所述的策略，不仅包含Alice的公钥（需要从她的私钥中验证签名），还包括超时逻辑和Bob和Charlie的公钥。
一旦Alice花费比特币，上述所有数据都必须添加到区块链中。其中包括脚本中未使用的数据，例如当Alice自己花费比特币时，Bob和Charlie提供的公钥数据也包含其中。
这样的话，账本交易数据会很笨重，自然拖慢了交易处理速度，而且由于公开披露不必要的信息进而减小隐私性，并且限制智能合约的灵活性，因为智能合约主要通过交易的大小而不是验证成本来计算。引入MAST的初衷就是想对此类情形做出改善。
MAST的起源
MAST的灵感来自于两个已经存在的概念的启发，抽象语法树和默克尔树。抽象语法树（ASTs）是源代码语法结构的一种抽象表示。它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构，这使得它更容易被分析和优化。要生成AST，只需将每个函数连接到其依赖项，直到所有依赖项都被映射出来为止。下图为上面描述的示例生成的AST：
另一方面，可通过默克尔树来验证单个元素是否是整个集合的成员。例如，比特币SPV钱包通过验证单个收到的交易区块的成员，而不需要下载完整区块，使用默克尔树可以节省带宽。
默克尔树可以看做Hash List（哈希列表）的泛化（哈希列表可以看作一种特殊的默克尔树，即树高为2的多叉默克尔树）。
在最底层，和哈希列表一样，我们把数据分成小的数据块，有相应地哈希值和它对应。但是往上走，并不是直接去运算根哈希，而是把相邻的两个哈希合并成一个字符串，然后运算这个字符串的哈希值，这样每两个哈希值就配对生成，得到一个“子哈希”。如果最底层的哈希总数是单数，那到最后必然出现一个单一的哈希，这种情况就直接对它进行哈希运算，所以也能得到它的子哈希。于是往上推，依然是一样的方式，可以得到数目更少的新一级哈希，最终必然形成一棵倒挂的树，到了树根的这个位置，这一代就剩下一个根哈希了，也可称为Merkle Root。这样的话整个集合只需要用一串唯一的数据体现。
在p2p网络下载网络之前，先从可信的源获得文件的默克尔树根。一旦获得了树根，就可以通过可信的树根来检查接收到的默克尔树。如果默克尔树中的成员存在损坏或者虚假的情况，就从其他源获得另一个默克尔树，直到获得一个与可信树根匹配的默克尔树。
验证默克尔树的成员时，可以直接下载并立即验证默克尔树的一个分支。因为可以将文件切分成小的数据块，如果有一块数据是损坏的，仅需要重新下载这个数据块。验证成员只需要在默克尔树中下载一个分支，然后立即验证这个分支，如果分支验证通过，就可以下载数据了。
简而言之，AST背后的技术允许将程序分成单独的部分，而默克尔树使得在没有下载整个程序数据的情况下验证属于完整程序的各个部分。这是MAST的基石，它增加扩容，提供隐私性，并使智能合约优化成为可能。
MAST示例
我们将上述示例分为两个子脚本：
Alice可以在任何时候花费她的比特币（图示左侧）；
或者，三个月后Aliec并未花费她的比特币，Bob和Charlie达成共识在哪些地方花费Alice的比特币（图示右侧）。
默克尔树根仅用32个数据节点唯一的定义了Alice完整的产权负担。然后Alice用另一个产权负担要求发送者必须提供默克尔树根连接到其中一个子脚本默克尔验证，并且子脚本的反馈必须是True。
子脚本的默克尔验证可视化如下所示，取决于我们想要验证的子脚本：
优势＃1 扩容
我们通过研究如何让复杂产权负担的用户创建更小的交易来检验MAST的优势。
在上述示例中，我们使用了一个包含两个子脚本的产权负担：Alice花费她的资产，或者Bob和Charlie等了三个月且他们花了这笔资产。让我们想象一个无限可扩展的版本，其中第三个子脚本说三个月零一天后，Dan和Edith丹花费这笔资产;或者第四个子脚本包含，三个月零两天后，Fred和George弗雷德乔治花费这笔资产等......
我们能够创建以下的图表，其中显示了子脚本的数量以及需要将多少产权负担数据添加到具有和不具有MAST的区块链中做对比。
虽然验证两个子脚本时，应用MAST比未应用MAST的成本要高，但是未应用MAST的成本以线性方式增长，而应用MAST的成本以对数方式增长。
如果节省字节是首要目标，此方案可以进一步优化。对于许多产权负担而言，发送者趋于考虑优先一种条件而非其他条件。例如，Alice希望能活很长时间，她在构建默克尔树时，她的花费条件总是接近顶端，其他条件位于底部。
MAST默克尔验证提供两种不同交易大小，理想的情况是Alice活着且花费了她的比特币，另一种情况就是Alice去世，其受益者花费她的比特币。
上图可以看出不管Alice添加多少个潜在的受益者到她的产权负担，在理想情况下字节数不变，而且其他潜在的花费者仅比之前的案例多一些字节。
无论Alice选择哪种方案，MAST可使得拥有多个子脚本的产权负担规模小，减小交易大小，因而使得用户花费更少的费用，使区块容纳更多笔交易。
优势＃2 隐私性增强
由于我们在之前已经深入讨论过Alice的案例，你对产权负担已经有了一定的了解，但是想象一下，如果当Alice支付她的比特币时，你看到的所有数据都被添加到区块链中(如下图左所示)：
有了上述信息，你就不可得知除了Alice之外的其他人是否可以访问这笔资金，或者有哪些条件限制他们动用这笔资金。你可能从MAST的使用上来猜测其他的条件，但是仅有一种猜测，即Alice可能假装她的默克尔树有其他可支配的部分。
或者，如果你看到的只是另一个分支（如上图右侧所示），你也获取不到是否这笔资金在所设定的时间之前已被支出，或者单人（Alice）可花费这笔资金。同样地，你可能猜测有其他条件的存在，但是你在区块链上获取不到准确的信息。
对某些用户来说，隐私性极为重要，例如：那些害怕被竞争对手知道智能合约的企业。这与那些声称专注智能合约开发的山寨币项目不同，这些山寨币项目不为合约提供任何隐私性。
隐私性为比特币用户提供的另一好处是，甚至对那些不关心产权负担隐私本身的用户也有好处。想象一下，Alice是唯一一个没有使用MAST产权负担模板的人。由于完整的产权负担是公开的，任何人都可以通过该模板追踪Alice的所有支出记录，从而破坏Alice的隐私性。
任何能轻易做用户画像的工具，同时也能轻易地追踪用户的比特币，这种现象被称为缺乏替代性。简单来说，如果有人想知道Alice的产权负担，他们可以通过贿赂或强制矿工不要挖这些交易，来防止Alice花费这笔比特币。
MAST并不能完全解决这个痛点，由于一旦Alice花费比特币，Alice（或Bob和Charlie）的产权负担就会被曝光一部分。但将很多不同的复杂的产权负担解析为少量的简单的MAST模式的产权负担是有可能的。
例如，Alice默认的花费就好似默认支付任意一笔交易，只需要提供一个签名，因此，Alice基于MAST的交易与其他基于MAST单一签名的交易融为一体。这就可帮助Alice保障隐私，同时增强可替代性，以及任意使用基于MAST产权负担且满足单一签名的用户的可替代性。
例如，Alice默认的花费就好似默认支付任意一笔交易，只需要提供一个签名，因此，Alice基于MAST的交易与其他基于MAST单一签名的交易融为一体。这就可帮助Alice保障隐私，同时增强可替代性，以及任意使用基于MAST产权负担且满足单一签名的用户的可替代性。
然而，即使这些功能还未在比特币上体现，MAST本身为复杂的产权负担提供更多的隐私性和可替代性。
优势＃3 灵活的智能合约
比特币具有三种不同的字节大小硬性限制，这些字节大小适用于各个脚本，字节的大小取决于产权负担的保留方式：2010年7月裸脚本添加10,000字节限制，P2SH的字节限制为520，segwit限制为10,000字节。
从上图可看出，即使对于非常基本的无限可扩展的示例，MAST也比其他当前所使用的机制允许更多条件性的分支。MAST允许花费时编写一长串条件，且不会导致数据的相应增长，那么这样一来，比特币上就可以创建非常复杂的智能合约。增加块大小可能进一步降低用户未来运行全节点的可能性，因为一般家用设备达不到那么高的存储要求。MAST能帮助解决扩容问题，升级不会牺牲效率、功能和隐私等方面。
其他MAST提案
BIP114
比特币首席开发者Johnson Lau在GitHub上提交了一份名为BIP114pull的请求：
该BIP定义了一种新型见证程序，使用默克尔树对脚本中的互斥分支进行编码，从而实现：1. 目前尚不能的复杂赎回/兑换（redemption）条件；2. 隐藏未执行脚本，提高隐私性；3. 以零或非常低的成本包含非共识强制数据。
BIP114其实是MAST的简化定制版。 Merkle根编码的是相互排斥的条件脚本分支，而非单个操作。虽然不是MAST的完整实现，实现的隐私、扩容效果是一样的。
Mark Friedenbach提案
比特币开发者Mark Friedenbach提出两个提案，需要合并使用才能将MAST引入比特币。
第一个是BIP116，允许“脚本编写者承诺（committo）一组数据元素，赎回时仅提供一个或多个元素，不必披露整个数据集。”他把这个操作码称为MERKLE分支验证（MERKLEBRANCHVERIFY）。
第二个是BIP117，标题为尾调用语义（Tail Call Semantics）。 Friedenbach是这么解释的：“BIP117与BIP116合并时，允许无限数量的脚本代码路径，但是会披露花费（比特币）时的代码路径。 这与一般MAST原理上是一样的：将复杂分支脚本拆分成一组无分支的扁平执行路径，可以显示整个路径集合，但是只显示花费时的路径。”
Laus的提案只能在SegWit脚本中运行，但Friedenbachs提案可以在比特币中正在使用的所有脚本中实施。
用默克尔分支验证和单一尾部递归这些简易且强大的工具来够构建MAST，在实现了复杂功能的同时，也最大限度地减少了对共识代码的修改以及相应的后续审查负担和获得性技术债 - bitseven.com.
比特塞稳 | 比特币商业交易所：比特币最高100倍杠杆交易
使用最高100倍杠杆进行比特币和其他加密货币交易。快速进
行操作，低佣金，这些只是“比特塞稳”能提供。
No comments:
Post a Comment