浅论Redstone：它不是Plasma，而是Optimium变体

近期，一个叫Redstone的项目成为了热点。这个由Lattice团队推出的链游专项Layer2设施，于11月15日正式发布，目前已上线测试网。有趣的是，Lattice团队称“Redstone是受到Plasma启发的Alt-DA链”。

就在Redstone发布的前一天，Vitalik刚刚发表了文章“Exit games for EVM validiums: the return of Plasma”，文中简单回顾了本已消失在以太坊生态的技术方案“Plasma”，并指出可以引入有效性证明（与ZK Proof混淆），来解决Plasma的问题。

对此，有不少朋友认为，Vitalik发表这篇文章，是为了给Redstone站台，甚至在极客Web3社群内也有人说，Vitalik搞不好投资了Redstone。再加上此前传的沸沸扬扬的“以太坊Layer2定义之争”，一时间人们普遍认为，接下来会引发“Plasma的复兴”，而Celestia等以太坊生态外的DA方案可能因此被抑制，因为Plasma没有对DA的严格要求。

但据本文作者考证，Redstone并不符合Plasma方案的大致框架，其自称“受到Plasma启发”反而有蹭Vitalik文章热点的可能性，而不是Vitalik真要为Redstone站台。此外，Redstone的DA挑战方案与Layer2项目Metis在2022年4月推出的方案颇有相似之处，只不过两者在更新Stateroot——发布DA数据这两个步骤上的先后次序不同。

所以，真实的情况是，大家可能对Redstone产生了“过度解读”。下文中将通过一些简单的推理来为读者解释Plasma的原理及其为何对智能合约及Defi不友好，以及Redstone到底是什么东西。

Plasma：遇到了数据扣留攻击就要紧急提款

Plasma的历史可以追溯到2017年以太坊IC0热潮时期，彼时以太坊用户的交易需求呈爆炸式增长，而TPS低下的ETH不堪重负。在这样的关头，Plasma最早的理论版本发布了，文中提出了一种二层扩容方案，可以处理“世界上几乎所有的金融场景”。

简单来说，Plasma是一种只把Layer2的区块头/Merkle Root发布到Layer1上的扩容方案，区块头/Merkle Root之外的那部分数据（DA数据）只在链下发布。如果Plasma的排序器/Operator在L1上发布的Merkle Root关联了一笔无效交易（数字签名错误等场景），相关用户可以提交欺诈证明，证明排序器提交的Root关联着一笔无效交易。

但问题在于，要发布欺诈证明必须保证DA数据不被扣留，但Plasma对DA层没有严格要求，不能保证用户或L2节点可以接收到数据。如果排序器在某个时间点发动数据扣留攻击（也被称作数据可用性问题），只发布新的区块头/Merkle root，却不发布对应的区块体，让人无法验证区块头/root是否有效，用户就只能默认排序器“无药可救”，通过名为“Exit Game”的紧急退出机制，把资产从Layer2撤到Layer1上。

这一步操作需要用户提交Merkle Proof，证明自己在L2上的确有相应数额的资产，我们可以将此称为“资产证明”。有意思的地方在于，Plasma的Exit Game和ZK Rollup的逃生舱模式并不一样，ZK Rollup用户必须提交对应最近一个有效Stateroot的Merkle Proof，而Plasma用户却可以提交很久前的Merkle Root对应的Proof。

为什么设计成这样？只是因为，ZK Rollup提交的Stateroot，会被Layer1上的合约立刻投入判断（判断有效性证明是否有效）。如果这个刚提交不久的Stateroot是有效并合法的，那么用户就应当提交对应合法Stateroot的Merkle Proof来充当资产证明。

但Plasma的排序器提交的Merkle Root，Layer1合约无法判断是否有效，只能让L2节点主动发起挑战来排除无效Root，所以会有挑战机制，这使得Plasma和Zk Rollup的运作原理迥然不同。

假设排序器刚发布了一个无效的Merkle Root 101，同时发动数据扣留攻击，让L2节点无法证明101号root是无效的，此时用户可以提交对应100号root或更早以前root的merkle Proof，把自己的资产提走。

当然这里有个问题需要解决，就是某个用户可能提交对应30号root或更早期root的资产证明，请求把资产撤到Layer1，但这个人在30号root发布后，资产状况可能有变化。换句话说，他提交的是过时的资产证明，这就是典型的双花攻击/双重支付。

对此，Plasma允许任何人针对上述情况提交欺诈证明，指出某个发起提款声明的用户提交的“资产证明”是过时的。通过引入这种“任何人都可以挑战别人的提款声明”，Plasma不需要像ZK Rollup那样处理紧急提款请求。

但还是有一种可能，就是排序器先把其他人的资产划转到自己的L2账户下，然后再发动数据扣留攻击，让外人无法对自己的作弊行为发起挑战。之后，排序器自己的账户发起紧急提款，提交“资产证明”宣称自己的确在L2上拥有这些资产。

显然，这种时候因为缺失了一段历史记录，人们无法直接证明排序器的资产来源有问题。那么这种情况下该怎么办？Plasma的早期版本比如Plasma MVP考虑到了这点，他们提出了“提款优先级”。如果一个人提交的资产证明对应的root更早，它的提款请求就会被优先处理。

假如排序器是在提交第101号root时进行上面说的作弊行为并发起提款，那么用户可以提交对应99号或更早root的资产证明来紧急提款。显然，排序器只要无法篡改已经发布到Layer1上的历史记录，用户就有办法逃出生天。

但Plasma还是有一个致命bug：只要排序器发动数据扣留，人们就要靠紧急提款（又称Exit Game）来保证资产安全，如果短时间内大量用户集体提款，Layer1很容易处理不过来；

更严重的是，像Defi合约上记录的资产，该由谁来提取到Layer1？假设有人往DEX的LP池子充了100个ETH，之后Plasma的排序器故障或作恶了，人们需要紧急提款，这时候用户的100个ETH都还为DEX合约所控制，请问这个时候这些资产该由谁提到Layer1上？

最好的办法其实是先让用户从DEX池子里赎回自己的资产，再由用户自己去把钱提到L1上，但问题是Plasma排序器已经故障/作恶了，用户没法执行赎回资产的操作。可如果我们允许DEX合约的owner去把合约控制的资产提到L1，显然会赋予合约owner以资产所有权，他可以随时把这些资产提到L1上并跑路，这岂不是太可怕了？

所以到最后，该怎么处置这些由Defi合约所支配的“公共财产”，是一个巨大的雷。如果走社会共识，在Layer1上重建一个映射了Layer2上defi合约的镜像合约，似乎也可以，但这会引入相当巨大的麻烦，增加机会成本，由哪些人来投票决定镜像合约的处置方式，也会是个大问题。这其实涉及到公权力分配的难题，此前响马曾在访谈《高性能公链难出新事，智能合约涉及权力分配》中谈到过这点。

当然，Vitalik在最近的文章“Exit games for EVM validiums: the return of Plasma”中也指出了这一点，并强调这是Plasma对智能合约不友好的因素之一。过往的知名Plasma变体如Plasma MVP和Plasma Cash等，采用了UTXO或类似的模型来替代以太坊的账户地址模型，并且不支持智能合约，这样可以避免上面谈及的“资产所有权分配”问题，每个UTXO的所有权固然归属于用户自己，但UTXO本身也有诸多缺陷，且对智能合约不友好。所以Plasma方案最适合简单的支付或订单簿式交易所。

到后来，随着ZK Rollup的走红，Plasma本身也退出了历史舞台，因为Rollup不存在Plasma的数据扣留问题。假如ZK Rollup的排序器发动数据扣留攻击，只往ETH链上提交Stateroot但没有DA数据，这样的root会判定为无效，直接被L1上的Verifier合约拒绝。所以，ZK Rollup的合法Stateroot对应的DA数据，在ETH链上必定可查。这样就不存在“只发布区块头或merkle root，却不发布对应的区块体”，也就是可以解决数据可用性问题/数据扣留攻击。

同时，Rollup的过往DA数据在以太坊上可查，任何人都可以通过ETH链上的历史记录来启动Layer2节点，这将去中心化乃至无需许可的排序器方案难度大幅降低。相比之下，Plasma对DA没有严格要求，实现去中心化排序器的难度也更大（要实现可替换的去中心化排序器，首先要保证所有的L2节点都认可相同的block，这就对DA实现方式提出了要求）。

此外，如果ZK Rollup的排序器尝试把无效交易包含进Layer2区块，也无法成功，这是由有效性证明的原理来保障的。

归根结底，ZK Rollup排序器的作恶空间与Plasma相比要狭小许多——它最多能让Stateroot的更新停滞，在UX层面相当于停机，或者拒绝某些用户的请求，俗称交易审查。同时，Rollup方案中如果排序器故障了，其他节点要替代它也会更容易。理想状态下的Rollup，可以将Plasma中Exit game模式的触发概率降至0（ZK Rollup中叫逃生舱）。

（L2BEAT上的Proposer Failure一栏，展示了各个L2方案如何应对排序器故障问题，Self Propose往往指其他节点可以替代当前处于停机状态的排序器）时至今日，以太坊生态内几乎没有团队还在坚持Plasma路线了，几乎所有的Plasma项目都胎死腹中。

（Vitalik解释为何ZK Rollup比Plasma更优越，其中有提到无需许可的排序器运行和DA问题）

Redstone是个啥：它不是Plasma，而是Optimium的变体

上文我们简单阐述了Plasma以及其被Rollup替代的简要因素，而至于Redstone，想必大家也看到了它和Plasma的不同：Redstone可以解决数据扣留攻击问题，比如它不会立刻发布新的stateroot，而是先在ETH链下发布原始的DA数据，然后把DA数据的datahash作为一个关联的凭证commitment，发布到ETH链上，称自己在链下已发布这段datahash所对应的完整数据。

（Redstone官方对自己的防止数据扣留攻击方案的解释）

任何人都可以发起挑战，称Redstone的排序器没有在链下发布这段datahash对应的原始数据。此时，排序器需要在链上发布datahash对应的数据，以应对质疑者的挑战。如果排序器被挑战后，没有及时在ETH链上发布数据，则它之前发布的datahash/commitment会被视为无效。

如果排序器及时响应了挑战者的请求，那么挑战者就可以及时获取到datahash对应的原始DA数据。最终，所有L2节点基本都可以获取到所需的DA数据，以解决数据扣留攻击问题。当然，挑战者本身需要先支付一笔费用，这笔费用约等于排序器在ETH链上发布原始DA数据的成本，这个举措是为了防止恶意挑战者无成本的挑战排序器，致使后者蒙受损失。

最后，当针对datahash的挑战期结束后，排序器将发布对应的stateroot，也就是执行datahash对应的DA数据中 包含的交易序列后，得到的root。此时L2节点可以使用欺诈证明系统来挑战那些无效的root。如果此前某个datahash在被挑战后，排序器没有及时发布对应的原始DA数据，则排序器即便后面发布了这个datahash对应的stateroot，也会被默认为无效。

由于Redstone是先发布DA数据，之后才发布对应的有效Stateroot，直接解决了数据扣留攻击问题（排序器只发布root而不发布DA数据）。

显然这种模式和普通的Optimium（不用以太坊实现DA的OP Rollup，比如Arbitrum Nova）不同，Optimium一般依赖于链下DAC委员会确保数据可用性，DAC每隔一段时间向链上提交一个多签txn，Layer1上的Rollup合约收到多签txn后，会默认排序器已在链下发布最新一批的DA数据。

（图源：L2beat）

而像Metis和Arbitrum Nova等是同时提交Stateroot和datahash，如果有人认为排序器扣留了DA数据，便会尝试发起挑战，排序器会把datahash对应的DA数据发到链上。

所以，Redstone和Metis的关键区别在这一步：前者是先发布datahash，等DA挑战期结束，才发布stateroot；Metis却是同时发布stateroot和datahash，如果有人发起挑战，则把DA数据上链。显然Redstone的方案更安全些，因为Metis的方案下，如果排序器一直不响应挑战者对DA数据的请求，则数据扣留攻击问题无法快速解决，只能依靠紧急提款和社会共识，或是让其他节点接替当前的排序器；

但换做Redstone，如果排序器搞数据扣留，则其发布的stateroot直接被认作无效，所以stateroot和DA数据是绑定关系，这使得Redstone可以获得和Rollup较接近的DA保证，本质上是比Arbitrum Nova和Metis更优越的Optimium变体。