Author: Faust, geek web3***
Recently, a project called Redstone has become a hot topic. **This Layer2 facility launched by the Lattice team was officially released on November 15 and has now been launched on the testnet. Interestingly, the Lattice team claims that “Redstone is a plasma-inspired Alt-DA chain”.
Just a day before Redstone’s release, Vitalik published the article “Exit games for EVM validiums: the return of Plasma”, in which he briefly reviewed the technical solution “Plasma” that had disappeared from the Ethereum ecosystem, and pointed out that validity proofs (confused with ZK Proof) could be introduced to solve the Plasma problem.
In this regard, many friends believe that Vitalik published this article in order to give Redstone a platform, and even in the geek Web3 community, some people say that Vitalik has not invested in Redstone. Coupled with the boiling “Ethereum Layer 2 definition dispute” in the previous rumor, it was widely believed that the next “Plasma revival” would be triggered, and DA solutions outside the Ethereum ecosystem such as Celestia may be suppressed, because Plasma does not have strict requirements for DA. **
However, according to the research of the author of this article, Redstone does not fit the general framework of the Plasma solution, and its claim to be “inspired by Plasma” has the possibility of rubbing the heat of Vitalik’s article, rather than that Vitalik really wants to stand for Redstone. In addition, Redstone’s DA challenge is similar to the Layer 2 project Metis launched in April 2022, except that the order of updating the Stateroot and publishing the DA data is different.
So, the real situation is that you may have “over-interpreted” Redstone. The following is a simple reasoning to explain how Plasma works, why it’s not friendly to smart contracts and Defi, and what exactly Redstone is. **
Plasma: Urgent withdrawal in case of data withholding attack
The history of plasma can be traced back to the Ethereum IC0 boom in 2017, when the transaction demand of Ethereum users exploded and ETH with low TPS was overwhelmed. At this juncture, the earliest theoretical version of Plasma was released, which proposed a layer-2 scaling scheme that could handle “almost all financial scenarios in the world”.
To put it simply, Plasma is a scaling solution that only publishes the Layer 2 block header/Merkle root to Layer 1, and the part of the data outside the block header/Merkle root (DA data) is only published off-chain. **If the Merkle Root published by the Plasma sequencer/Operator on L1 is associated with an invalid transaction (e.g., a digital signature error), the user can submit a fraud certificate to prove that the Root submitted by the sequencer is associated with an invalid transaction.
The problem is that in order to issue fraud proofs, it is necessary to ensure that DA data is not withheld, but Plasma does not have strict requirements for the DA layer and cannot guarantee that users or L2 nodes can receive data. If the sequencer launches a data withholding attack (also known as a data availability issue) at a certain point in time, and only publishes a new block header/Merkle root, but does not publish the corresponding block body, making it impossible to verify whether the block header/root is valid, the user can only default to the sequencer as “hopeless” and withdraw assets from Layer 2 to Layer 1 through an emergency exit mechanism called “Exit Game”.
This step requires the user to submit a Merkle Proof to prove that they do have a corresponding amount of assets on L2, which we can call “Proof of Assets”. Interestingly, Plasma’s Exit Game is not the same as ZK Rollup’s Escape Pod mode, where ZK Rollup users must submit a Merkle Proof corresponding to the most recent valid Stateroot, while Plasma users can submit a Proof corresponding to a Merkle Root from a long time ago.
Why is it designed this way? It’s just that the Stateroot submitted by the ZK Rollup will be immediately put into judgment by the contract on Layer 1 (to determine whether the validity proof is valid). If the newly submitted Stateroot is valid and legitimate, then the user should submit the Merkle Proof corresponding to the valid Stateroot as proof of assets.
However, the Merkle Root submitted by the Plasma sequencer, the Layer1 contract cannot judge whether it is valid or not, and can only let the L2 node take the initiative to challenge to exclude the invalid Root, so there will be a challenge mechanism, which makes the operation of Plasma and Zk Rollup very different. **
Suppose the sequencer has just released an invalid Merkle Root 101 and launched a data withholding attack, so that the L2 node cannot prove that the root 101 is invalid, then the user can submit the merkle Proof corresponding to root 100 or earlier root and withdraw his assets.
Of course, there is a problem that needs to be solved here, that is, a user may submit an asset certificate corresponding to root 30 or earlier, and request to withdraw the asset to Layer 1, but the asset status of this person may change after the release of root 30. In other words, he submits an outdated proof of assets, which is a typical double-spend attack/double-spend. **
In response, Plasma allows anyone to submit a fraud certificate for the above cases, stating that the “proof of equity” submitted by a user who initiated a withdrawal claim is outdated. By introducing this “anyone can challenge someone else’s withdrawal statement”, Plasma doesn’t need to handle emergency withdrawal requests like ZK Rollup.
But there’s still a possibility that the sorter will transfer someone else’s assets to their own L2 account before launching a data withholding attack that makes it impossible for outsiders to challenge their cheating. After that, the sequencer’s own account initiates an emergency withdrawal, submitting a “proof of assets” claiming that it does indeed own the assets on L2.
Obviously, because of the lack of a piece of history, there is no way to directly prove that the sequencer’s asset source is problematic. Earlier versions of Plasma, such as Plasma MVP, took this into account and came up with a “withdrawal priority”. If a person submits an asset proof corresponding to root earlier, its withdrawal request will be prioritized.
If the sequencer cheats and initiates a withdrawal when submitting root number 101, the user can submit proof of assets corresponding to root number 99 or earlier to make an emergency withdrawal. Obviously, as long as the sequencer can’t tamper with the history that has been posted to Layer 1, the user has a way to escape.
But Plasma still has a fatal bug: as long as the sequencer initiates data withholding, people have to rely on emergency withdrawals (also known as Exit Game) to ensure the safety of assets, and if a large number of users collectively withdraw in a short period of time, Layer 1 is easy to handle;
Suppose someone recharges 100 ETH to the LP pool of the DEX, and then the sequencer of the Plasma fails or does evil, and people need to withdraw urgently, at this time, the user’s 100 ETH is still controlled by the DEX contract, who should mention these assets to Layer 1 at this time?
The best way to do this is to let users redeem their assets from the DEX pool first, and then let the users withdraw their money to L1 themselves, but the problem is that the Plasma sequencer is malfunctioning/corruptible, and users cannot redeem their assets. But wouldn’t it be terrible if we allowed the owner of the DEX contract to bring the assets controlled by the contract to L1, which obviously gave the contract owner ownership of the assets, and he could raise these assets to L1 at any time and run away?
So in the end, how to deal with these “public property” supported by Defi contracts is a huge thunder. **If you follow the social consensus, it seems that it is okay to rebuild a mirror contract on Layer 1 that mirrors the defi contract on Layer 2, but this will introduce quite a huge trouble, increase the opportunity cost, and who will vote on the disposal of the mirror contract will also be a big problem. This actually involves the problem of the distribution of public power, which Xiangma has previously talked about in an interview "It is difficult for high-performance public chains to do new things, and smart contracts involve power distribution.
Of course, Vitalik also points this out in his recent article “Exit games for EVM validiums: the return of Plasma”, and highlights this as one of the factors that make Plasma unfriendly to smart contracts. **In the past, well-known Plasma variants such as Plasma MVP and Plasma Cash used UTXO or similar models to replace Ethereum’s account address model, and did not support smart contracts, which can avoid the “asset ownership distribution” problem mentioned above, although the ownership of each UTXO belongs to the user, but UTXO itself has many flaws and is not friendly to smart contracts. Therefore, the Plasma solution is best suited for simple payment or orderbook exchanges.
Later, with the popularity of ZK Rollup, Plasma itself also withdrew from the stage of history, because Rollup did not have the problem of data retention of Plasma. If the sequencer of the ZK Rollup launches a data withholding attack and only submits the Stateroot to the ETH chain without DA data, such root will be judged invalid and rejected by the Verifier contract on L1. Therefore, the DA data corresponding to the legal Stateroot of ZK Rollup must be available on the ETH chain. In this way, there is no “only publish the block header or merkle root, but not the corresponding block body”, that is, the data availability problem/data withholding attack can be solved. **
At the same time, the past DA data of Rollups is available on Ethereum, and anyone can start Layer 2 nodes through the history of the ETH chain, which greatly reduces the difficulty of decentralized or even permissionless sequencer schemes. In contrast, Plasma does not have strict requirements for DA, and it is more difficult to implement a decentralized sequencer (to implement a replaceable decentralized sequencer, you must first ensure that all L2 nodes recognize the same block, which puts forward requirements for DA implementation).
In addition, if the sequencer of the ZK Rollup tries to include invalid transactions in the Layer 2 block, it will not succeed, which is guaranteed by the principle of validity proof.
At the end of the day, the ZK Rollup sequencer has a much smaller room for action than Plasma — it can at best stall Stateroot updates, be the equivalent of downtime at the UX level, or deny certain user requests, colloquially known as transaction censorship. At the same time, if the sequencer fails in the Rollup scheme, it will be easier for other nodes to replace it. **Ideally, the probability of triggering the Exit game mode in Plasma can be reduced to 0 (called the escape pod in ZK Rollup).
(The Proposer Failure column on L2BEAT shows how each L2 solution can deal with sequencer failures, Self Pose often refers to other nodes that can replace the sequencer that is currently down)**
Today, there are almost no teams in the Ethereum ecosystem that are still sticking to the Plasma route, and almost all Plasma projects are stillborn.
(Vitalik explains why ZK Rollup is superior to Plasma, mentioning permissionless sequencer operation and DA issues)
What is Redstone: It’s not Plasma, it’s a variant of Optimium****
Above we briefly explained Plasma and the reasons why it is replaced by Rollup, and as for Redstone, you must have also seen the difference between it and Plasma: Redstone can solve the problem of data retention attacks,** For example, it will not immediately release a new stateroot, but first publish the original DA data off-chain, and then publish the datahash of the DA data on the ETH chain as an associated credential commitment, saying that it has published the complete data corresponding to this datahash off-chain.
(Redstone’s official explanation of its own plan to prevent data withholding attacks)**
Anyone can challenge Redstone’s sequencer to say that it doesn’t publish the raw data for this datahash off-chain. At this point, the sequencer needs to publish the data corresponding to the datahash on-chain to meet the challenge of the questioner. **If the sequencer does not publish data on the ETH chain in a timely manner after being challenged, its previously published datahash/commitment will be considered invalid.
If the sequencer responds to the challenger’s request in a timely manner, the challenger can obtain the original DA data corresponding to the datahash in time. Eventually, all L2 nodes can obtain the required DA data to solve the problem of data retention attacks. Of course, the challenger itself needs to pay a fee that is approximately equal to the cost of the sequencer publishing the raw DA data on the ETH chain, in order to prevent malicious challengers from challenging the sequencer at no cost and causing the latter to incur losses.
Finally, when the challenge period for datahash is over, the sequencer will publish the corresponding stateroot, which is the root obtained after executing the transaction sequence contained in the DA data corresponding to the datahash. At this point, the L2 node can use the fraud proof system to challenge those invalid roots. If the sequencer does not publish the corresponding original DA data in time after a datahash is challenged, the sequencer will be invalid by default even if the stateroot corresponding to the datahash is published later.
Since Redstone publishes DA data first, and then publishes the corresponding valid Stateroot, it directly solves the problem of data withholding attacks (the sequencer only publishes root but not DA data).
Obviously, this model is different from ordinary Optimium (OP Rollup of DA without Ethereum, such as Arbitrum Nova), Optimium generally relies on off-chain DAC committees to ensure data availability, DAC submits a multi-Sig txn to the chain every once in a while, and the Rollup contract on Layer 1 will default to the sequencer that has released the latest batch of DA data off-chain after receiving the multi-Sig txn.
(图源:L2beat)
Whereas Metis and Arbitrum Nova submit Stateroot and datahash at the same time, if someone thinks that the sequencer withholds DA data, they will try to launch a challenge, and the sequencer will send the DA data corresponding to the datahash to the chain.
Therefore, the key difference between Redstone and Metis is this: the former publishes the datahash first and waits for the end of the DA challenge period before releasing the stateroot, while Metis publishes both the stateroot and the datahash, and if someone initiates a challenge, the DA data is uploaded to the chain. Obviously, Redstone’s solution is safer, because under Metis’s scheme, if the sequencer does not respond to the challenger’s request for DA data, the data withholding attack problem cannot be quickly solved, and the only way to rely on emergency withdrawals and social consensus is to let other nodes take over the current sequencer;
However, in the case of Redstone, if the sequencer engages in data withholding, the stateroot released by it is directly considered invalid, so the stateroot and DA data are bound, which allows Redstone to obtain DA guarantees that are closer to Rollup, which is essentially a superior Optimium variant than Arbitrum Nova and Metis.
