A brief discussion on Restone: It is not Plasma, but an Optimium variant

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 stated“Redstone is an Alt-DA chain inspired by Plasma”。

Just the day before Redstone was released,Vitalik just published the article “Exit games for EVM validiums: the return of Plasma”. The article briefly reviewed the technical solution “Plasma” that has disappeared from the Ethereum ecosystem.And pointed out that validity proof (confused with ZK Proof) can be introduced to solve the problem of Plasma. 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 it would trigger a “revival of Plasma” in the future, and DA solutions outside the Ethereum ecosystem such as Celestia may be suppressed as a result.Because Plasma does not have 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 solution. Its claim to be “inspired by Plasma” may actually follow the hot topics of Vitalik’s article.It’s not that Vitalik really wants to stand up for 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. So, the real situation is,Everyone may have “over-interpreted” Redstone.The following will explain to readers through some simple reasoningThe principle of Plasma and why it is not friendly to smart contracts and Defi, and what exactly is Redstone.

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. The part of 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 is launched at a certain point in timeData withholding attacks (also known as data availability issues) only publish new block headers/Merkle roots but do not publish the corresponding block bodies.Without the ability to verify whether the block header/root is valid, users can only default to the “hopeless” sequencer 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”Proof of assets”. 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, so there will be a challenge mechanism.This makes Plasma and Zk Rollup operate very differently.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,What he submitted was an outdated proof of assets, which is a typical double-spending attack/double-spending.

In this regard, Plasma allows anyone to submit a proof of fraud in 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 is, 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 account, 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, Layer1 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 asset ownership. 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 distribution of public power. The thieves had previously said in an interview“It is difficult to create new things in high-performance public chains, smart contracts involve power distribution”This was mentioned in the article.

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. after that,With the popularity of ZK Rollup, Plasma itself has also withdrawn from the stage of history.Because Rollup does 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. That’s itThere 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, we must first ensure that all L2 nodes recognize the same block, which puts 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 evil space of ZK Rollup sorter is much smaller than that of Plasma——At most, it can stall Stateroot’s updates, which is equivalent to a shutdown at the UX level, or deny certain users’ requests, commonly known as transaction review. at the same time,If the sorter 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. Instead, it will first release the original DA data under the ETH chain, and then use the datahash of the DA data as an associated credential commitment and publish it to the ETH chain, saying that it has released this under the chain. The complete data corresponding to the segment datahash.

(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 sequencer needs to publish the data corresponding to the datahash on the chain to meet the challenges of 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. . at last,When the challenge period for datahash ends, the sorter will release the corresponding stateroot,That is, the root obtained after executing the transaction sequence contained in the DA data corresponding to the 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. becauseRedstone releases DA data first, and then releases the corresponding effective Stateroot, directly solving the problem of data withholding attacks.(The sorter only publishes root and not DA data). Obviously this mode is different from ordinary Optimium (OP Rollup that does not use Ethereum to implement DA, such as Arbitrum Nova).Optimium generally relies on the off-chain DAC committee to ensure data availability.DAC submits a multi-signed txn to the chain at regular intervals. After the Rollup contract on Layer1 receives the multi-signed txn, it will default to the sequencer publishing 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. so,The key difference between Redstone and Metis is in this step:The former releases datahash first, and then releases stateroot after the DA challenge period ends; Metis releases stateroot and datahash at the same time. 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 sorter never responds to the challenger’s request for DA data, the data withholding attack problem cannot be solved quickly. We 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 closer to that of Rollup, which is essentially a variant of Optimium that is superior to Arbitrum Nova and Metis.

Disclaimer：

1. This article is reprinted from [极客web3]. All copyrights belong to the original author [Faust]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.