浅论 Redstone:它不是 Plasma,而是 Optimium 变体
本文将为大家介绍Plasma的原理及其为何对智能合约及Defi不友好,以及Redstone到底是什么东西。

作者:Faust,极客web3

近期,一个叫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变体

作者极客web3@eternal1997L