（图中最下面的record就是叶子节点对应的原始数据集）
Merkle Root有一个性质：如果Merkle Tree底层某个叶子节点发生变化，计算得到的Merkle Root也会发生变化。所以，对应不同原始数据集的Merkle Tree，会有不同的Merkle Root，就好比不同的人有不同的指纹。而被称作Merkle Proof的证明验证技术，利用了Merkle Tree的这个性质。
以上图为例，假如李刚只知道图中Merkle Root的数值，不知道完整的Merkle Tree包含哪些数据。我们要向李刚证明，Record 3的确和图中的Root有关联性，或者说，证明Record 3的哈希存在于Root对应的那棵Merkle Tree上。
我们只需要把Record3，以及标记为灰色的那 3 个digest数据块，提交给李刚，而不必把整个Merkle Tree或其所有叶子节点都提交过去，这就是Merkle Proof的简洁性。当Merkle Tree底层记录的叶子特别多时，比如包含了2的20次幂个数据块（约100万），Merkle Proof最少只需要包含21个数据块。
（图中的数据块30和H2就可以构成Merkle Proof，证明数据块30存在于H0对应的Merkle Tree上）
在比特币、以太坊或跨链桥中，经常用到Merkle Proof的这种“简洁性”。我们所知的轻节点，其实就是上文提到的李刚，他只从全节点那里接收区块头header，而不是完整的区块。这里需要强调，以太坊用称为State Trie的默克尔树，充当全体账户的摘要。只要State Trie关联着的某个账户状态发生变化，State Trie的Merkle Root——称为StateRoot就会变化。
以太坊的区块头中，会记录StateRoot，同时也会记录交易树的Merkle Root（简称Txn Root），交易树和状态树的一个区别，在于底层叶子所代表的数据不同。假如第100号block内包含300笔交易，则交易树的叶子，代表的就是这300笔Txn。
另一个区别在于，State Trie整体的数据量特别大，它的底层叶子对应着以太坊链上所有地址（实际上还有很多过时的状态哈希），所以State Trie对应的原始数据集不会发布到区块中，只在区块头记录下StateRoot。而交易树的原始数据集就是每个区块内的Txn数据，这棵树的TxnRoot会记录在区块头里。
由于轻节点只接收区块头，只知道StateRoot和TxnRoot，不能根据Root反推出完整的Merkle Tree（这是由Merkle Tree和哈希函数的性质决定的），所以轻节点无法获知区块内包含的交易数据，也不知道State Trie对应的账户发生了哪些变化。
如果王强要向某个轻节点（前面提过的李刚）证明，第100号block中包含某笔交易，已知轻节点知道100号block的区块头，知道TxnRoot，那么上述问题转化为：证明这笔Txn存在于TxnRoot对应的那棵Merkle Tree上。这个时候，王强只要提交对应的Merkle Proof即可。
在很多基于轻客户端方案的跨链桥中，常常会用到上面讲到的，轻节点和Merkle Proof的轻量与简洁性。比如说，Map Protocol等ZK桥，会在ETH链上设置一个合约，专门接收其他链的区块头（比如Polygon）。当Relayer向ETH链上的合约，提交Polygon第100个区块的header后，合约会验证header的有效性（比如是否凑足了Polygon网络内2/3 POS节点的签名）。
如果Header有效，且某用户声明，自己发起了从Polygon到ETH的跨链Txn，该Txn被打包进了Polygon第100个区块。他只要通过Merkle Proof，证明自己发起的跨链Txn，能对应上100号区块头的TxnRoot（换句话说，就是证明自己发起的跨链Txn 在Polygon的100号区块内有记录）。只不过ZK桥会通过零知识证明，压缩验证Merkle Proof所需的计算量，进一步降低跨链桥合约的验证成本。
DA与数据扣留攻击问题
讲完了Merkle Tree和Merkle Root、Merkle Proof，我们回到文章最开头说到的DA与数据扣留攻击问题，这一问题早在2017年以前就被人探讨过，Celestia原始论文有对DA问题的来源进行考古。Vitalik本人则在2017~18年的一个文档中，谈到出块者可能故意隐瞒block的某些数据片段，对外发布不完整的区块，这样一来，全节点就无法确认交易执行/状态转换的正确性。
此时，出块者可以盗取用户资产，比如把A账户中的币全部划转到别的地址，而全节点无法判断A本人是否有这么做，因为他们不知道最新区块包含的完整交易数据。
在比特币或以太坊等Layer1公链中，诚实全节点会直接拒收上述无效区块。但轻节点则不同，他们只从网络中接收区块头Header，只知道StateRoot和TxnRoot，不知道Header和两个Root对应的的原始区块是否有效。
在比特币白皮书中，其实有对这种情况作出脑洞，中本聪曾认为，大多数用户会倾向于运行配置要求较低的轻节点，而轻节点无法判断区块头对应的block是否有效，如果某个block无效，诚实全节点会向轻节点发出警报。
但中本聪没有对这个方案进行更细致的分析，后来Vitalik和Celestia创始人Mustafa在这个idea之上，结合其他前人的成果，引入了DA数据采样，确保诚实全节点能够还原出每个区块的完整数据，并在必要时刻发出警报。
注：DA数据采样（DAS）与Celestia并不是本文要探讨的重点，感兴趣的读者可以阅读《极客web3》过往文章：《对数据可用性的误解：DA=数据发布≠历史数据检索》
Plasma的欺诈证明
简单来说，Plasma是一种只把Layer2的区块头发布到Layer1上的扩容方案，区块头之外的DA数据（完整的交易数据集/每个账户的状态变化）只在链下发布。换句话说，Plasma就像基于轻客户端的跨链桥一样，在ETH链上用合约实现了Layer2的轻客户端，当用户声明要把资产从L2跨到L1时，要提交Merkle Proof，证明自己的确拥有这些资产。
资产从L2跨到L1的验证逻辑，和前文中谈到的ZK桥比较类似，只不过Plasma的桥接模型基于欺诈证明，而不是ZK证明，更接近于所谓的“乐观桥”。Plasma网络中从L2到L1的提款请求不会被立刻放行，而是有一个“挑战期”，至于挑战期的目的是什么，我们会在下面讲解。
Plasma对数据发布/DA没有严格要求，排序器/Operator只是在链下广播每个L2区块，有意愿获取L2区块的节点去自行获取。之后，排序器会把L2区块的Header发布到Layer1。比如说，排序器先在链下广播第100号区块，之后把区块的header发布到链上。如果100号区块中包含无效交易，任何Plasma节点都可以在“挑战期“结束前，向ETH上的合约提交Merkle Proof，证明第100号区块头能关联到某笔无效交易，这就是欺诈证明涵盖的一个场景。
Plasma的欺诈证明应用场景还包括以下几种：
1.假设Plasma网络的进度到了200号区块，此时A用户发起提款声明，称自己在第100号区块时，有10枚ETH。但实际上，A用户在100号区块之后，曾把账上的ETH花掉。
所以，A的行为实际上是：花掉10枚ETH后，声明自己在以前有10枚ETH，并尝试把这些ETH提走。这就是典型的“双重提款”，双花。此时，任何人都可以提交Merkle Proof，证明A用户最新的资产状况，不满足其提款声明，也就是证明A在100号区块后，没有提款声明的那些钱（不同的Plasma方案针对这种情况的证明方法不一致，账户地址模型远比UTXO的双花证明麻烦的多）。
2.如果是基于UTXO模型的Plasma方案（过去主要都是这种），区块头中是不包含StateRoot的，只有TxnRoot（UTXO不支持以太坊式的账户地址模型，也没有State Trie这种全局状态设计）。换言之，采用UTXO模型的链只有交易记录，没有状态记录。
此时，排序器自身可能发动双花攻击，比如把某个已经被花掉的UTXO再花一次，或者给某个用户凭空增发UTXO。任何一个用户都可以提交Merkle Proof，证明该UTXO的使用记录在过往区块中出现过（被花过），或者证明某个UTXO的历史来源有问题。
3.对于EVM兼容/支持State Trie的Plasma方案，排序器有可能提交无效的StateRoot，比如说，在执行了第100个区块中包含的交易后，StateRoot应该转换为ST+，但排序器往Layer1提交的却是ST-。
这种情况下的欺诈证明比较复杂，需要在以太坊链上重放第100号区块中的交易，计算量和需要的输入参数会消耗大量gas。早期采用Plasma的团队难以实现如此复杂的欺诈证明，所以大多采用了UTXO模型，毕竟基于UTXO的欺诈证明很简洁，也好实现（首个上线欺诈证明的Rollup方案Fuel，就是基于UTXO的）
数据扣留与Exit Game
当然，上述欺诈证明能生效的场景，都是在DA/数据发布有效时，才成立的。如果排序器搞数据扣留，不在链下发布完整的区块，Plasma节点就无法确认Layer1上的区块头是否有效，当然也无法顺利发布欺诈证明。
此时，排序器可以盗取用户资产，比如私自把A账户的币全部划转到B账户，再从B账户给C转账，最后用C的名义发起提款。B和C账户是排序器自己拥有的，B->C这笔转账就算对外公示，也无伤大雅；但排序器可以扣留A->B这笔无效转账的数据，人们无法证明B和C的资产来源有问题（要证明B的资产来源有猫腻，就要指出”给B转账的某笔Txn“的数字签名有误）。
基于UTXO的Plasma方案有针对性的举措，比如任何人发起提款时，都要提交资产的全部历史来源，当然后来有更多的改良措施。但如果是EVM兼容的Plasma方案，会在这块显得软弱无力。因为如果涉及与合约相关的Txn，在链上验证状态转换过程会产生巨量成本，所以支持账户地址模型和智能合约的Plasma，不好实现针对提款有效性的验证方案。
此外，抛开上面的话题，无论是基于UTXO还是基于账户地址模型的Plasma，一旦发生数据扣留，基本都会引发人们的恐慌，因为你不知道排序器都执行了哪些交易。Plasma的节点会发现不对劲，但又无法针对性的发布欺诈证明，因为欺诈证明所需的数据，Plasma排序器没发出来。
这个时候，人们只能看到对应的区块头，但不知道区块里面都有什么，不知道自己的账户资产变成了什么样，大家会集体发起提款声明，用对应着历史区块的Merkle Proof尝试提款，引发被称作“Exit Game”的极端场景，这种情况会导致“踩踏”，使得Layer1严重拥堵，并仍会导致一些人资产受损（没有接收到诚实节点通知或者不刷推特的人，根本不会知道排序器正在盗币）。
所以，Plasma是一种不可靠的Layer2扩容方案，一旦发生数据扣留攻击，就会触发“Exit Game”，很容易让用户蒙受损失，这是其被废弃的一大原因。
Plasma难以支持智能合约的原因
在讲过了Exit Game和数据扣留问题后，再来看Plasma为什么难以支持智能合约，主要是两个理由：
其一，如果是Defi合约的资产，该由谁来提取到Layer1？因为这本质上就是把合约的状态从Layer2迁移到Layer1，假设有人往DEX的LP池子充了100个ETH，之后Plasma的排序器作恶了，人们要紧急提款，这时候用户的100个ETH都还为DEX合约所控制，请问这个时候这些资产该由谁提到Layer1上？
最好的办法，似乎是先让用户从DEX赎回资产，再由用户自己去把钱提到L1上，但问题是Plasma排序器已经作恶了，随时可能拒绝用户请求。
那么，如果我们事先给DEX合约设置Owner，允许他在紧急情况下，把合约资产提到L1上呢？显然这会赋予合约Owner以公共资产的所有权，他可以随时把这些资产提到L1上并跑路，这岂不是太可怕了？
显然，该怎么处置这些由Defi合约所支配的“公共财产”，是一个巨大的雷。这其实涉及到公权力分配的难题，此前响马曾在访谈《高性能公链难出新事，智能合约涉及权力分配》中谈到过这点。
其二，如果不允许合约迁移状态，会使其蒙受巨额损失；如果允许合约把自己的状态迁移到Layer1，会出现Plasma欺诈证明难以解决的双重提款：
比如，我们假设Plasma采用以太坊的账户地址模型，支持智能合约，有一个混币器，目前存入了100枚ETH，混币器的Owner由Bob控制；
假设Bob在第100个区块时，从混币器提走50枚ETH。之后Bob发起提款声明，把这50枚ETH跨到了Layer1上；
之后，Bob用过去的合约状态快照（比如第70个区块），把混币器过去的状态迁移到Layer1上，这会把混币器“曾经拥有”的100枚ETH也跨到Layer1上；
显然，这是典型的“双重提款”，也就是双花。有150枚ETH被Bob提到了Layer1，但Layer2网络用户只向混币器/Bob付出100枚ETH，有50枚ETH被凭空抽走。这很容易把Plasma的储备金抽干。理论上人们可以发起欺诈证明，证明混币器合约的状态在第70个区块之后有变化。
但假如在第70号区块之后，所有和混币器合约产生交互的Txn，都没有改变合约状态，除了Bob抽走50枚ETH那笔交易；如果你要出示证据，指出混币器合约在第70号区块后有变化，就要在以太坊链上把上述提及的所有Txn跑一遍，最终才能让Plasma合约确定，混币器合约状态的确发生过变化（之所以这么复杂，是由Plasma本身的构造决定的）。如果这批Txn数量极大，欺诈证明根本无法在Layer1上发布（会超出以太坊单个区块的gas上限）。
https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598
理论上来说，上面的双花场景中，似乎只要提交混币器当前的状态快照（其实就是对应StateRoot的默克尔证明），但实际上，由于Plasma不在链上发布交易数据，合约无法确定你提交的状态快照是否有效。这是因为排序器自己可能发动数据扣留，提交无效的状态快照，恶意指证任何一名提款者。
比如说，当你声明自己账上有50枚ETH并发起提款时，排序器可能私自把你账户清0，然后发动数据扣留，把一个无效的StateRoot发到链上，并提交对应的状态快照，诬告你账户里没钱了。这个时候大家没法证明排序器提交的StateRoot和状态快照无效，因为他发动了数据扣留，你得不到欺诈证明需要的足量数据。
为了防止这种情况，Plasma节点在出示状态快照证明某人有双花行为时，还要重放这段时间内的交易记录，这可以防止排序器用数据扣留来阻止别人提款。而在Rollup中，如果遇到上述双重提款，理论上不需要重放历史交易，因为Rollup不存在数据扣留问题，会"强制要求"排序器在链上发布DA数据。Rollup排序器如果提交一个无效StateRoot-状态快照，要么无法通过合约验证（ZK Rollup），要么很快就会被挑战（OP Rollup)。
其实除了上面谈到的混币器的例子外，多签合约等场景一样可以导致Plasma网络发生双重提款。而欺诈证明对这种场景的处理效率很低。在ETH Research中有对这种情况作出分析。
综上所述，由于Plasma方案不利于智能合约，基本不支持合约状态迁移到Layer1，主流的Plasma只好选用UTXO或类似的机制，因为UTXO不存在资产所有权冲突问题，并且能很好的支持欺诈证明（尺寸小很多），但代价是应用场景单一，基本只能支持转账或者订单簿交易所。
此外，因为欺诈证明本身对DA数据有较强的依赖，如果DA层不可靠，将难以实现高效率的欺诈证明系统。而Plasma对于DA问题的处理太简陋，无法解决数据扣留攻击问题，随着Rollup的崛起，Plasma慢慢就淡出了历史舞台。
