A Brief Discussion on Restone It is not Plasma but an Optimium Variation

An Overview of Restone Understanding the Difference Between Plasma and Its Optimum Variation

Author: Faust, Geek Web3

Recently, a project called Redstone has become a hot topic. This chain gaming-focused Layer2 infrastructure, launched by the Lattice team, was officially released on November 15th and has now gone live on the testnet. Interestingly, the Lattice team refers to Redstone as a “Plasma-inspired Alt-DA chain”.

The day before the release of Redstone, Vitalik just published an article titled “Exit games for EVM validiums: the return of Plasma”, in which he briefly reviewed the technology solution “Plasma” that had already disappeared from the Ethereum ecosystem and pointed out that introducing validity proofs (confusingly with ZK proofs) could solve Plasma’s problems.

• OpenAI’s Crisis Deepens More Resignations Pour In After CEO’s Removal
• OpenAI: Rocking the Boat or Sinking Ship?
• The Hilarious Rise of Bonk, Pepe, and Memecoin Token Prices Memeinator Takes the Crypto World by Storm

Regarding this, many friends believe that Vitalik’s article is meant to support Redstone, and some even say within the Geek Web3 community that Vitalik might have invested in Redstone. Combined with the previous heated “Ethereum Layer2 definition dispute”, people generally believe that it will trigger the “resurgence of Plasma” next, while DA solutions outside of the Ethereum ecosystem like Celestia may be suppressed because Plasma does not have strict requirements for DAs.

But according to the author of this article, Redstone does not fit the general framework of the Plasma solution. Its self-claim to be “inspired by Plasma” actually opens up the possibility of riding the wave of Vitalik’s article, rather than Vitalik genuinely endorsing Redstone. Furthermore, Redstone’s DA challenge solution has some similarities with the solution launched by the Layer2 project Metis in April 2022, except for the different order of the steps to update Stateroot and release DA data.

So, the reality is that everyone might have “overinterpreted” Redstone. The following section 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: Emergency Withdrawal When Facing Data Withholding Attacks

The history of Plasma can be traced back to the 2017 Ethereum ICO boom when Ethereum user transaction demands explosively grew, and the low TPS of ETH could not handle the load. At such a critical moment, the earliest theoretical version of Plasma was released, proposing a Layer2 scaling solution that could handle “almost all financial scenarios in the world”.

Simply put, Plasma is a scaling solution that only publishes Layer2 block headers/Merkle Roots to Layer1, while the part of the data outside of the block headers/Merkle Roots (DA data) is only published off-chain. If the Plasma operator publishes a Merkle Root on L1 that is associated with an invalid transaction (e.g., signature error), users can submit fraud proofs to prove that the root submitted by the operator is associated with an invalid transaction.

However, the problem is that to publish fraud proofs, it must ensure that DA data is not withheld. But Plasma does not have strict requirements for the DA layer, so it cannot guarantee that users or L2 nodes can receive the data. If the operator launches a data withholding attack (also known as a data availability problem) at a certain point in time, only publishing new block headers/Merkle Roots without the corresponding block bodies, it becomes impossible to verify the validity of the block headers/roots, and users can only assume that the operator is “unredeemable”. They can then use an emergency exit mechanism called “Exit Game” to withdraw assets from Layer2 to Layer1.

This step requires the user to submit a Merkle Proof, proving that they indeed have the corresponding amount of assets on L2. We can call this “Asset Proof.” The interesting thing is that Plasma’s Exit Game and ZK Rollup’s escape pod mode are different. ZK Rollup users must submit a Merkle Proof for the most recent valid State Root, while Plasma users can submit a Proof for a much earlier Merkle Root.

Why is it designed this way? Simply because the Stateroot submitted by ZK Rollup will immediately be put into judgment by the contracts on Layer1 (to check if the validity proof is valid). If this recently submitted Stateroot is valid and legitimate, then the user should submit the corresponding Merkle Proof for the valid Stateroot as asset proof.

However, the Merkle Root submitted by Plasma’s sequencer cannot be judged by the Layer1 contracts, so the L2 nodes have to actively initiate challenges to eliminate invalid Roots. This is why there is a challenge mechanism, which makes the operation principles of Plasma and ZK Rollup different.

Let’s assume the sequencer just released an invalid Merkle Root 101 and launched a data withholding attack, making it impossible for L2 nodes to prove that Root 101 is invalid. At this point, users can submit a merkle Proof for the corresponding Root 100 or earlier to withdraw their assets.

Of course, there is a problem to solve here. A user may submit asset proof for Root 30 or earlier and request to withdraw the assets to Layer1, but his asset status may have changed after the release of Root 30. In other words, he submitted outdated asset proof, which is a typical double-spending attack.

In this case, Plasma allows anyone to submit fraud proofs against the situation mentioned above, pointing out that the “asset proof” submitted by a user making a withdrawal claim is outdated. By introducing this “anyone can challenge someone else’s withdrawal claim,” Plasma doesn’t need to handle emergency withdrawal requests like ZK Rollup.

But there is still one possibility… The sequencer transfers other people’s assets to their own L2 account first, then launches a data withholding attack to prevent outsiders from challenging their cheating behavior. Later, the sequencer initiates an emergency withdrawal from their own account and submits an “asset proof” claiming that they indeed have those assets on L2.

Obviously, in such a situation, because a section of the history is missing, people cannot directly prove that the sequencer’s asset source is problematic. So what should be done in this case? Plasma’s early versions, such as Plasma MVP, considered this and proposed “withdrawal priority.” If a person’s asset proof corresponds to an earlier root, their withdrawal request will be processed with higher priority.

If the sequencer engages in the cheating behavior described above and initiates a withdrawal when submitting the 101st root, the user can submit asset proof for the corresponding 99th or earlier root for an emergency withdrawal. Obviously, as long as the sequencer cannot tamper with the historical records already published on Layer1, the user has a way to survive.

However, Plasma still has a fatal bug: as long as the sorter initiates data withholding, people have to rely on emergency withdrawals (also known as Exit Game) to ensure the safety of their assets. If a large number of users collectively withdraw their funds within a short period of time, Layer1 may struggle to process all of them;

What’s even more serious is, who should extract the assets recorded on Defi contracts to Layer1? Suppose someone deposits 100 ETH into a DEX’s LP pool, and then the Plasma sorter malfunctions or acts maliciously. In this case, people need to make emergency withdrawals, but at that time, the 100 ETH still remain under the control of the DEX contract. So, who should extract these assets to Layer1?

The best solution is actually for users to redeem their assets from the DEX pool by themselves and then transfer the funds to L1. However, the problem is that the Plasma sorter has already malfunctioned/acted maliciously, so users cannot execute the asset redemption operation. But if we allow the owner of the DEX contract to extract the contract-controlled assets to L1, it obviously grants the contract owner asset ownership. They can withdraw these assets to L1 at any time and run away, isn’t that terrifying?

Therefore, in the end, how to deal with these “public properties” supported by Defi contracts is a huge challenge. If we follow social consensus, creating a mirrored contract on Layer1 that maps to the defi contracts on Layer2 seems possible, but this would introduce considerable trouble and increase opportunity costs. It would also be a major problem to determine which individuals get to vote on the disposal method of the mirrored contract. This actually involves the difficulty of distributing public authority, a topic that Hai Ma previously discussed in his interview “High-performance public chains face difficulties, smart contracts involve power distribution.”

Of course, Vitalik also pointed out this 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. Past notable variants of Plasma, such as Plasma MVP and Plasma Cash, adopted UTXO or similar models to replace Ethereum’s account address model and do not support smart contracts. This way, the issue of “asset ownership distribution” mentioned above can be avoided. While user-owned assets certainly belong to the user, UTXO itself also has many flaws and is not friendly to smart contracts. Therefore, the Plasma solution is best suited for simple payments or order book-style exchanges.

In the future, as ZK Rollup gains popularity, Plasma itself has also been phased out of the history stage because Rollup does not have the data withholding issue that exists in Plasma. If the sorter of ZK Rollup initiates a data withholding attack and only submits Stateroot to the ETH chain without DA data, such a root will be deemed invalid and directly rejected by the Verifier contract on L1. Therefore, the DA data corresponding to the legitimate Stateroot of ZK Rollup can definitely be found on the ETH chain. Thus, there is no longer the problem of “only publishing block headers or merkle roots without publishing the corresponding block bodies,” which solves the issue of data availability/data withholding attacks.

At the same time, the past DA data of Rollup can be checked on Ethereum, and anyone can start a Layer2 node through the historical records on the ETH chain, which greatly reduces the difficulty of decentralized and even permissionless sequencer schemes. In contrast, Plasma does not have strict requirements for DA, and the difficulty of achieving decentralized sequencers is greater (to achieve replaceable decentralized sequencers, it is first necessary to ensure that all L2 nodes agree on the same block, which poses requirements for the implementation of DA).

In addition, if the sequencer of ZK Rollup attempts to include invalid transactions in the Layer2 blocks, it will also fail, which is guaranteed by the principle of validity proof.

In the final analysis, the malicious space of ZK Rollup sequencers is much smaller compared to Plasma – it can at most cause the update of Stateroot to stagnate, which is equivalent to downtime in terms of user experience, or reject certain user requests, commonly 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. In an ideal state of Rollup, the triggering probability of the Exit game mode in Plasma can be reduced to 0 (called the escape pod in ZK Rollup).

(The column “Proposer Failure” on L2BEAT shows how various L2 solutions deal with sequencer failure issues, Self Propose often refers to other nodes being able to replace the sequencer that is currently in a shutdown state)

So far, there are almost no teams in the Ethereum ecosystem still pursuing the Plasma route, and almost all Plasma projects are stillborn.

(Vitalik explains why ZK Rollup is superior to Plasma, mentioning the operation of permissionless sequencers and the DA problem)

What is Redstone: It is not Plasma but a variant of Optimium

In the previous text, we briefly explained Plasma and the key factors for its replacement by Rollup, and as for Redstone, I believe everyone has seen its differences with Plasma: Redstone can solve the problem of data withholding attacks, for example, it does not immediately release a new stateroot, but first publishes the original DA data on the ETH chain, and then uses the datahash of the DA data as an associated proof of commitment, publishing it on the ETH chain, claiming to have already published the complete data corresponding to this datahash off-chain.

(Redstone’s official explanation of their solution to prevent data withholding attacks)

Anyone can challenge and claim that the sequencer of Redstone did not publish the original data corresponding to this datahash off-chain. At this point, the sequencer needs to publish the data corresponding to the datahash on-chain in response to the challenger’s challenge. If the sequencer fails to timely publish the data on the ETH chain after being challenged, the previously published datahash/commitment will be considered invalid.

If the sequencer responds timely to the challenger’s request, then the challenger can promptly obtain the original DA data corresponding to the datahash. In the end, almost all L2 nodes can obtain the required DA data to solve the problem of data withholding attacks. Of course, the challenger itself needs to pay a fee, which is roughly 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 losses to the sequencer.

Finally, when the challenge period for datahash ends, the sorter will release 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, L2 nodes can use the fraud proof system to challenge those invalid roots. If the sorter fails to timely release the original DA data corresponding to a datahash that has been challenged, even if the sorter later publishes the stateroot corresponding to this datahash, it will still be considered invalid.

Since Redstone first releases the DA data and then releases the corresponding valid Stateroot, it directly solves the problem of data withholding attacks (sorters only publish roots without releasing DA data).

Obviously, this approach is different from the common Optimum (OP Rollup implementation without Ethereum for DA, such as Arbitrum Nova), where Optimum generally relies on an off-chain DAC committee to ensure data availability, and the DAC submits a multi-signature txn to the chain at regular intervals. After receiving the multi-signature txn, the Rollup contract on Layer1 will assume that the sorter has already published the latest batch of DA data off-chain.

(Image source: L2beat)

On the other hand, for protocols like Metis and Arbitrum Nova, both the Stateroot and datahash are submitted simultaneously. If someone believes that the sorter has withheld DA data, they will try to initiate a challenge, and the sorter will send the DA data corresponding to the datahash to the chain.

Therefore, the key difference between Redstone and Metis lies in this step: the former first releases datahash, and after the DA challenge period ends, it releases the stateroot. But Metis simultaneously releases the stateroot and datahash, and if someone initiates a challenge, then the DA data is put on the chain. Obviously, Redstone’s approach is more secure because, in Metis’ approach, if the sorter continuously fails to respond to challengers’ requests for DA data, the problem of data withholding attacks cannot be quickly resolved; it can only rely on emergency withdrawals and social consensus or have other nodes replace the current sorter.

However, in the case of Redstone, if the sorter withholds data, the stateroot it publishes is considered invalid. Therefore, stateroot and DA data are bound together, making Redstone able to achieve a DA guarantee closer to Rollup. In essence, it is a superior variation of Optimum compared to Arbitrum Nova and Metis.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!