Author: Faust, geek web3
Recently, a project called Redstone has become a hot topic. This special Layer 2 facility for chain games launched by the Lattice team was officially released on November 15 and is now online on the test network. Interestingly, the Lattice team claims that “Redstone is an Alt-DA chain inspired by Plasma.”
Just the day before Redstone was released, Vitalik had just published the article "Exit games for EVM validiums: the return of Plasma". The article briefly reviewed the technical solution "Plasma" that had disappeared from the Ethereum ecosystem, and pointed out that validity could be introduced. Proof (confused with ZK Proof), to solve Plasma's problem.
In this regard, many friends believe that Vitalik published this article to support Redstone. Some people even said in the geek Web3 community that Vitalik might have invested in Redstone. Coupled with the heated "Ethereum Layer 2 definition dispute" in this prequel, people generally believed that the next step would be a "revival of Plasma", and DA solutions outside the Ethereum ecosystem such as Celestia may be suppressed because of this . There are no strict requirements for DA.
However, according to the research of the author of this article, Redstone does not conform to the general framework of the Plasma plan. Its claim to be "inspired by Plasma" may actually be based on the hot topics of Vitalik's article, rather than Vitalik really wanting to support Redstone. In addition, Redstone’s DA challenge plan is quite similar to the plan launched by the Layer 2 project Metis in April 2022, except that the order of the two steps of updating Stateroot and publishing DA data is different.
Therefore, the real situation is that everyone may have "over-interpretation" of Redstone. The following will use some simple reasoning to explain to readers the principles of Plasma and why it is not friendly to smart contracts and Defi, as well as what exactly Redstone is.
Plasma: Urgent withdrawals are required in the event of a data withholding attack
The history of Plasma can be traced back to the Ethereum ICO boom in 2017. At that time, the transaction demand of Ethereum users exploded, and ETH, which had low TPS, was overwhelmed. At this juncture, the earliest theoretical version of Plasma was released, which proposed a second-layer expansion plan that can handle "almost all financial scenarios in the world."
Simply put, Plasma is an expansion solution that only publishes the block header/Merkle Root of Layer2 to Layer1, and the data (DA data) other than the block header/Merkle Root is only published off-chain. If the Merkle Root issued by Plasma's sorter/Operator on L1 is associated with an invalid transaction (digital signature error, etc.), the relevant user can submit a fraud certificate to prove that the Root submitted by the sorter is associated with an invalid transaction.
But the problem is that to issue a fraud certificate, it is necessary to ensure that DA data is not withheld, but Plasma does not have strict requirements on 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, it will only publish the new block header/Merkle root, but not the corresponding block body, making it impossible to verify whether the block header/root is If it is effective, the user can only default to the "hopeless" sorter and withdraw assets from Layer 2 to Layer 1 through an emergency exit mechanism called "Exit Game".
This step requires the user to submit Merkle Proof to prove that they indeed have a corresponding amount of assets on L2. We can call this "asset proof" . What’s interesting is that Plasma’s Exit Game and ZK Rollup’s escape hatch mode are different. ZK Rollup users must submit the Merkle Proof corresponding to the most recent valid Stateroot, while Plasma users can submit the Proof corresponding to the Merkle Root long ago.
Why is it designed like this? Just because the Stateroot submitted by ZK Rollup will be immediately put into judgment by the contract on Layer1 (to determine whether the validity certificate is valid). If the newly submitted Stateroot is valid and legal, then the user should submit the Merkle Proof corresponding to the legal Stateroot to serve as an asset certificate.
However, the Layer1 contract cannot determine whether the Merkle Root submitted by Plasma's sequencer is valid. It can only allow the L2 node to actively initiate a challenge to eliminate invalid Roots. Therefore, there is a challenge mechanism, which makes the operating principles of Plasma and Zk Rollup very different.
Assume that the sequencer has just issued an invalid Merkle Root 101 and launched a data withholding attack so that the L2 node cannot prove that root No. 101 is invalid. At this time, the user can submit a merkle Proof corresponding to root No. 100 or earlier root. Withdraw your own 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 No. 30 or earlier and request to withdraw assets to Layer 1. However, this person's asset status may change after root No. 30 is released. In other words, he submitted an outdated proof of assets, which is a typical double spend attack/ double spend.
In this regard, Plasma allows anyone to submit a proof of fraud for the above situation, pointing out that the "proof of assets" submitted by a user who initiated a withdrawal statement is out of date. By introducing this “anyone can challenge someone else’s withdrawal claim”, Plasma does not need to handle emergency withdrawal requests like ZK Rollup.
But there is still a possibility that the sequencer first transfers other people's assets to its own L2 account, and then launches a data withholding attack so that outsiders cannot challenge its cheating behavior. Afterwards, the sequencer initiated an emergency withdrawal from its own account and submitted a "proof of assets" claiming that it indeed owned these assets on L2.
Obviously, at this time, because a historical record is missing, people cannot directly prove that there is a problem with the source of the sorter's assets. So what should you do in this situation? Early versions of Plasma such as Plasma MVP took this into consideration, and they proposed "Withdrawal Priority" . If the asset certificate submitted by a person corresponds to an earlier root, his withdrawal request will be processed first.
If the sequencer performs the above-mentioned cheating behavior and initiates a withdrawal when submitting root No. 101, then the user can submit an asset certificate corresponding to root No. 99 or earlier to make an emergency withdrawal. Obviously, as long as the sorter cannot tamper with the historical records that have been published to Layer1, the user will have 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. If a large number of users withdraw money collectively in a short period of time, Layer 1 will easily be unable to handle it;
What’s more serious is, who should withdraw the assets recorded on the Defi contract to Layer 1? Suppose someone charges 100 ETH into the LP pool of DEX, and then Plasma's sequencer fails or does something evil, and people need to withdraw funds urgently. At this time, the user's 100 ETH are still controlled by the DEX contract. At this time, what should these assets be? Who mentioned Layer1?
The best way is actually to let users redeem their assets from the DEX pool first, and then let the users transfer the money to L1 themselves. However, the problem is that the Plasma sequencer has malfunctioned/has done evil, and users cannot redeem assets. operation. But if we allow the owner of the DEX contract to lift the assets controlled by the contract to L1, it will obviously give the owner of the contract ownership of the assets. He can lift these assets to L1 and run away at any time. Wouldn't this be terrible?
So in the end, how to deal with these "public properties" controlled by Defi contracts is a huge surprise. If we follow social consensus, it seems possible to reconstruct a mirror contract on Layer 1 that maps the defi contract on Layer 2, but this will introduce considerable trouble and increase opportunity costs. Who will vote to decide how to dispose of the mirror contract? It will be a big problem. This actually involves the problem of public power distribution. The thieves have previously talked about this in the interview "It is difficult to create new things in high-performance public chains, and smart contracts involve power distribution."
Of course, Vitalik also pointed this out in his recent article "Exit games for EVM validiums: the return of Plasma" and emphasized that this is one of the factors that makes Plasma unfriendly to smart contracts. Well-known Plasma variants in the past, 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 himself, UTXO itself also has many flaws and is not friendly to smart contracts. Therefore, the Plasma solution is most suitable for simple payment or order book exchanges.
Later, with the popularity of ZK Rollup, Plasma itself also withdrew from the stage of history, because Rollup did not have the data retention problem of Plasma. If ZK Rollup's sequencer launches a data withholding attack and only submits Stateroot but no DA data to the ETH chain, such a root will be judged as invalid and directly 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 publishing the block header or merkle root, but not the corresponding block body", which means that it can solve the data availability problem/data withholding attack.
At the same time, Rollup's past DA data can be checked on Ethereum, and anyone can start Layer 2 nodes through the historical records on the ETH chain, which will greatly reduce the difficulty of decentralized and even permissionless sequencer solutions. In contrast, Plasma does not have strict requirements for DA, and it is more difficult to implement a decentralized sorter ( to implement a replaceable decentralized sorter, you must first ensure that all L2 nodes recognize the same block, which means Put forward requirements for DA implementation ).
In addition, if ZK Rollup's sequencer tries to include invalid transactions into Layer 2 blocks, it will not succeed. This is guaranteed by the principle of validity proof.
In the final analysis, the ZK Rollup sorter's room for evil is much narrower than that of Plasma - it can at most stall Stateroot's updates, which is equivalent to downtime at the UX level, or deny certain user requests, commonly known as transaction review. At the same time, if the sequencer fails in the Rollup scheme, it will be easier for other nodes to replace it. An ideal Rollup can reduce the probability of triggering the Exit game mode in Plasma to 0 (called an escape hatch in ZK Rollup).
(The Proposer Failure column on L2BEAT shows how each L2 solution responds to sequencer failure. Self Propose often refers to other nodes that can replace the currently down sequencer)
Today, almost no team in the Ethereum ecosystem is still adhering to the Plasma route, and almost all Plasma projects have been stillborn.
(Vitalik explains why ZK Rollup is superior to Plasma, mentioning permissionless sequencer operation and DA issues)
What is Redstone: It is not Plasma, but a variant of Optimium
Above we briefly explained Plasma and the brief factors why it was replaced by Rollup. As for Redstone, you must have also seen the difference between it and Plasma: Redstone can solve the problem of data withholding attacks. For example, it will not release a new stateroot immediately, but It first publishes the original DA data under the ETH chain, and then publishes the datahash of the DA data to the ETH chain as an associated certificate commitment, claiming that it has published the complete data corresponding to this datahash under the chain.
(Redstone’s official explanation of its plan to prevent data withholding attacks)
Anyone can initiate a challenge, saying that Redstone's sorter did not publish the original data corresponding to this datahash off-chain. At this time, the sorter needs to publish the data corresponding to the datahash on the chain to meet the challenge of the doubters. If the sequencer fails to publish data on the ETH chain in time after being challenged, the datahash/commitment it previously published will be considered invalid.
If the sorter responds to the challenger's request in time, the challenger can obtain the original DA data corresponding to the datahash in time. In the end, all L2 nodes can basically obtain the required DA data to solve the problem of data withholding attacks. Of course, the challenger itself needs to pay a fee first, which is approximately equal to the cost of the sequencer publishing the original DA data on the ETH chain. This measure is to prevent malicious challengers from challenging the sequencer at no cost, causing the latter to suffer losses. .
Finally, when the challenge period for datahash ends, the sequencer will release the corresponding stateroot, which is the root obtained after executing the transaction sequence contained in the DA data corresponding to datahash. At this point, L2 nodes can use the fraud proof system to challenge those invalid roots. If the sorter does not release the corresponding original DA data in time after a previous datahash is challenged, even if the sorter later releases the stateroot corresponding to this datahash, it will be invalid by default.
Since Redstone releases DA data first and then releases the corresponding valid Stateroot, it directly solves the problem of data withholding attacks (the sequencer only releases the root but not the DA data).
Obviously this model is different from ordinary Optimium (which does not use Ethereum to implement DA's OP Rollup, such as Arbitrum Nova). Optimium generally relies on the off-chain DAC committee to ensure data availability. The DAC submits a multi-signature txn to the chain at regular intervals. After the Rollup contract on Layer1 receives the multi-signed txn, it will default that the sequencer has released the latest batch of DA data off-chain.
(Source: L2beat)
For example, Metis and Arbitrum Nova submit Stateroot and datahash at the same time. If someone thinks that the sorter has withheld DA data, they will try to challenge it, and the sorter will send the DA data corresponding to the datahash to the chain.
Therefore, the key difference between Redstone and Metis is this step: the former releases datahash first, and then releases stateroot after the DA challenge period is over; Metis releases stateroot and datahash at the same time, and if someone initiates a challenge, the DA data is uploaded to the chain. Obviously Redstone's solution is safer , because under Metis's solution, if the sequencer never responds to the challenger's request for DA data, the data withholding attack problem cannot be solved quickly and can only rely on emergency withdrawals and social consensus, or let Other nodes take over the current sorter;
But in Redstone, if the sorter engages in data withholding, the stateroot issued by it will be directly considered invalid, so the stateroot and DA data are bound. This allows Redstone to obtain a DA guarantee that is closer to Rollup, which is essentially a comparison The more superior Optimium variants of Arbitrum Nova and Metis .
