揭秘Plasma不支持智能合约的原因：数据被扣留与欺诈证明规避
探索Plasma不支持智能合约的原因：数据滞留和欺诈证明机制
作者：Faust，极客web3
在数字资产的世界里，Plasma这个伟大的技术方案被长期埋没。大神Vitalik对它也一直不离不弃，深受其启发，并坚定地支持Rollup的发展。那么，问题来了，为什么Plasma会被埋没呢？为什么Vitalik会如此看重Rollup呢？我相信这两个问题将揭开一个答案的面纱。
首先，我们要从两个核心观点入手。第一观点，以太坊链下实现数据可用性是不可靠的，容易发生数据扣留。一旦数据扣留，欺诈证明就无法展开，游戏翻盘的机会也就少之又少。第二观点，Plasma的机制设计极其不友好，尤其难以支持合约状态迁移到Layer1。这两个观点使得Plasma基本只能采用UTXO或类似的模型。
先来说说第一个观点，也就是数据可用性问题。数据可用性的全称是Data Avalibility，翻译过来就是数据可用性。但遗憾的是，很多人误用了这个概念，以至于它和“历史数据可查”混为一谈。实际上，DA只探讨了数据扣留的场景。
那么什么是数据扣留攻击呢？为了让大家能够更好地理解，我们先来介绍一下Merkle Tree和Merkle Proof。在以太坊或其他公链中，Merkle Tree是一种树状数据结构，用来表示全体账户状态的摘要或者记录每个区块内打包的交易。
Merkle Tree最底层的叶子节点是由交易或账户状态的原始数据的hash值构成的。通过迭代计算，最终得到一个Merkle Root。有趣的是，如果Merkle Tree底层的某个叶子节点发生变化，计算得到的Merkle Root也会发生变化。可以把Merkle Root看作是一个“指纹”，不同的人有不同的指纹。利用Merkle Tree的这个性质，Merkle Proof证明技术得以诞生。
举个例子来说明，假设李刚只知道Merkle Root的数值，不知道完整的Merkle Tree包含哪些数据。我们要向李刚证明，Record 3的确和Merkle Root有关联。我们只需要把Record 3以及与之相连的几个数据块提交给李刚，而不必把整个Merkle Tree都提交过去。这就是Merkle Proof的简洁性。
在跨链桥和轻节点方案中，Merkle Proof被广泛使用。轻节点只接收区块头，无法推导出完整的Merkle Tree，所以无法获知区块内的交易数据和账户状态的变化。如果某个区块内发生了双重支付等欺诈行为，轻节点就无法察觉。
说到数据可用性和数据扣留，就不得不提到Plasma和Rollup。Plasma是一种将Layer2的区块头发布到Layer1的扩容方案，而数据扣留就是Plasma的致命伤。在Plasma网络中，数据发布并没有严格的要求，排序器只需要在链下广播每个Layer2区块，并把区块头发布到Layer1。这个过程中，你无法得知区块内的交易数据，也无法证明排序器是否在链下发布了完整的区块。
如果发生数据扣留攻击，排序器可以盗取用户资产，而用户无法证明排序器作恶。这很容易引发用户的恐慌，人们会集体发起提款声明，试图提取资产。这一极端场景被称为“Exit Game”，会导致链上严重拥堵，进而造成人们资产的损失。
与此同时，Plasma难以支持智能合约的原因也变得清晰起来。首先是资产迁移的问题，如果是DeFi合约的资产，应该由谁来提取到Layer1呢？如果由用户自己提取，存在排序器作恶导致用户无法提取的风险；如果由合约Owner提取，则将给合约Owner赋予了公共资产的所有权，这是一种巨大的潜在风险。
而如果允许合约迁移状态，可能会导致双重提款问题。以一个混币器的例子来说明，假设混币器中有100个ETH，Bob在第100个区块把50个ETH提走，并发起了提款声明。然后，Bob将混币器过去的状态迁移到了Layer1上，这就出现了双重提款的问题。这种情况对于Plasma网络来说是致命的，因为欺诈证明的处理效率非常低。而在Rollup中，因为不存在数据扣留的问题，可以很好地解决这种双重提款的问题。
综上所述，Plasma作为一种不可靠的Layer2扩容方案，存在严重的数据扣留和智能合约支持的问题。与之相比，Rollup方案以其高效率、可靠性和更广泛的应用场景日益受到青睐。有没有一种更好的解决方案呢？大家不妨留言分享一下你的想法。
原文链接：https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598
We will continue to update 算娘; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
