Is it not considered Rollup if Ethereum is not used as the DA layer? Understanding Layer2 from the perspective of the Danksharding proposer.

Is it not Rollup if Ethereum isn't used as the DA layer? Understanding Layer2 from the Danksharding proposer's perspective.

Author: Faust, Geekweb3

Introduction: Recently, Dankrad Feist, the creator of Danksharding and a researcher at the Ethereum Foundation, made some controversial remarks on Twitter. He explicitly pointed out that a modular blockchain that does not adopt ETH as the DA (data availability) layer is not a Rollup, nor is it Ethereum Layer2. According to Dankrad, projects such as Arbitrum Nova, Immutable X, ApeX, and Metis may be “excluded” from the Layer2 list because they disclose transaction data outside of ETH (they have built their own off-chain DA network called DAC).

At the same time, Dankrad also stated that solutions like Plasmas and state channels, which do not require on-chain data availability to ensure security, can still be considered Layer2, but Validium (ZKRollup that does not use ETH as the DA layer) is not considered Layer2.

As soon as Dankrad made this statement, it drew many questions from founders and researchers in the Rollup field. After all, many “Layer2” projects do not use ETH as the DA layer in order to save costs. If these projects are removed from the L2 list, it will inevitably affect a considerable number of scaling networks. At the same time, if Validium is not considered L2, then Plasma should also not qualify as L2.

In response to this, Dankrad stated that Plasma users can still securely withdraw their assets to L1 when the DA is unavailable (referring to the off-chain DA network withholding transaction data). However, in the same situation, Validium (most projects that adopt the StarkEx solution are Validium) can freeze user funds and prevent them from being withdrawn to L1.

Obviously, Dankrad intends to define whether a scaling project is Ethereum Layer2 based on “security”. From the perspective of “security”, in extreme cases such as sequencer failure + DA layer launching data withholding attacks (concealing new data), Validium can indeed freeze user assets on L2 and prevent them from being transferred to L1. Although Plasma’s security guarantees are generally not as good as Validium’s, it allows users to securely withdraw their assets to L1 in the event of sequencer failure + DA layer launching data withholding attacks. Therefore, Dankrad’s argument is not without reason.

This article intends to delve into why Validium is not strictly speaking “Layer2” from Dankrad’s perspective by further analyzing the details of Layer2.

How to Define Layer2?

According to the ethereum.org website and the definition of most Ethereum community members, Layer2 is an “independent blockchain that allows Ethereum to scale + inherits Ethereum’s security”. First of all, “allowing Ethereum to scale” refers to diverting the traffic that Ethereum cannot handle and relieving the pressure on TPS. And “inheriting Ethereum’s security” can be translated as “relying on Ethereum to ensure its own security”.

For example, all transactions on Layer2 need to be finalized on ETH for settlement. Transactions with incorrect data will not be released. If you want to rollback the blocks on Layer2, you need to rollback the Ethereum blocks first. As long as the Ethereum mainnet does not experience block rollback similar to a 51% attack, the L2 blocks will not be rolled back.

If we further discuss the security of Layer2, we actually need to consider many extreme situations. For example, if the L2 project party runs away, the sequencer fails, or the off-chain DA layer crashes, can users safely withdraw their funds from L2 to L1 in these extreme events?

The “Forced Withdrawal” Mechanism of Layer2

Without considering factors such as L2 contract upgrades or multisignature vulnerabilities, projects like Arbitrum or StarkEx have set up forced withdrawal exits for users. Assuming the sequencer of L2 launches a censorship attack, intentionally rejects users’ transaction/withdrawal requests, or simply permanently crashes, Arbitrum users can call the force inclusion function of the Sequencer Inbox contract on L1 to directly submit the transaction data to L1. If within 24 hours, the sequencer does not process this transaction/withdrawal that needs to be “force included,” the transaction will be directly included in the transaction sequence of the Rollup ledger, which creates a “safe exit” for L2 users to force withdrawals.

In comparison, the StarkEx solution with an escape hatch mechanism goes even further. If the Forced Withdrawal request submitted by an L2 user on L1 does not receive a response from the sequencer when the 7-day window period ends, the user can call the freeze request function to put L2 into a frozen state. At this time, the L2 sequencer will be unable to update the L2 state on L1, and the L2 state will remain frozen for 1 year before it can be unfrozen.

After the L2 state is frozen, users can construct a Merkle Proof related to the current state to prove their funds on L2. They can then use the escape hatch related contracts on L1 to withdraw funds. This is the “full withdrawal” service provided by the StarkEx solution. Even if the L2 project party disappears and the sequencer permanently fails, users still have a way to withdraw their funds from L2.

However, there is a problem here: most L2s that use the StarkEx solution are Validiums (such as Immutable X and ApeX), which do not publish the data required by the DA to ETH. The information for constructing the current L2 state tree exists off-chain. If users cannot obtain the data required to construct the Merkle Proof off-chain (such as when the off-chain DA layer initiates a data withholding attack), they cannot withdraw funds through the escape hatch.

So, the reason Dankrad mentioned at the beginning of the article that Validium is not secure is actually clear: because Validium, unlike Rollup, does not publish the DA’s data to the chain, users may not be able to construct the Merkle Proof required for “forced withdrawal”.

Differences between Validium and Plasma in the event of data withholding attacks

In fact, the sequencer of Validium only publishes the latest Stateroot (the root of the state tree) of L2 on the L1 chain and submits a Validity Proof (ZK Proof) to prove that the new Stateroot generation process involves correct state transitions (user fund changes).

However, relying solely on the stateroot cannot restore the current state tree world state trie, and therefore the specific states of each L2 account (including fund balances) cannot be known. L2 users cannot construct a corresponding Merkle Proof for the current valid Stateroot. This is a disadvantage of Validium.

It is necessary to emphasize the DAC (Data Availability Committee) here. The data involved in Validium’s DAC, such as a batch of transactions processed by the sequencer, will be synchronized to the L2 exclusive DAC network. DAC consists of multiple node servers and is generally operated and supervised by L2 officials, community members, or other entities (but this is only superficial, and it is difficult for outsiders to verify who the DAC members are).

The interesting thing is that the DAC members of Validium need to frequently submit multi-signatures on L1 to prove that the new Stateroot and Validity Proof submitted by the L2 sequencer on L1 match the DA data synchronized by DAC. After the multi-signatures of DAC are submitted, the new Stateroot and Validity Proof will be considered valid.

Currently, Immutable X’s DAC adopts a 5/7 multi-signature, and although dYdX is a ZKRollup, it also has a DAC that uses a 1/2 multi-signature. (dYdX only publishes the State diff, which is the state change, on L1, not the complete transaction data. But once the State diff in the historical records is obtained, the asset balances of all L2 addresses can be restored, and at this time, a Merkle Proof can be constructed for full withdrawal).

Dankrad’s point of view is not unreasonable. If the DAC members of Validium collude and initiate a data withholding attack, preventing other L2 nodes from synchronizing the latest data and updating the current legal Stateroot of L2, users cannot construct a valid Merkle Proof corresponding to the current root for withdrawal (because the current DA data is not available, only the previous DA data is available).

However, Dankrad is considering extreme theoretical situations. In reality, most Validium sequencers will broadcast newly processed transaction data to other L2 nodes in real-time, including honest nodes. As long as there is one honest node that can obtain DA data in a timely manner, users can withdraw from L2.

Why does the problem theoretically exist in Validium but not in Plasma? This is because the way Plasma determines a valid Stateroot is different from Validium’s and has a fraud-proof window period. Plasma is an L2 expansion solution before OPRollup and, like OPR, relies on fraud proofs to ensure L2 security.

Plasma, like OPR, has a window period setting. The newly released stateroot by the sequencer is not immediately deemed valid. It has to wait until the window period closes and no L2 node publishes fraudulent proof. Therefore, the current valid stateroot for Plasma and OPR is submitted several days ago (similar to the starlight we see, which was actually emitted a long time ago), and users can often obtain DA data from past moments.

At the same time, for the fraud proof mechanism to take effect at this moment, the DA of L2 must be available, that is, the Plasma Verifier node can obtain the relevant DA data at this moment, so that it can generate a fraud proof at this moment (if necessary).

So everything is quite simple: the prerequisite for Plasma to work normally is that the DA data of L2 at this moment is available. If the DA of L2 becomes unavailable from this moment onwards, can users withdraw their funds safely?

This question is not difficult to analyze. Assuming that the window period for Plasma is 7 days, if from a certain point in time T0, the new DA data becomes unavailable (DAC initiates data withholding attacks, preventing honest L2 nodes from obtaining data from T0 onwards). Because the valid stateroot for T0 and the subsequent period is submitted before T0, and the historical data before T0 is traceable, users can construct a Merkle Proof to force withdrawals.

Even if many people cannot immediately detect the anomaly, because there is a window period (OP is 7 days), as long as the stateroot submitted at T0 has not yet been validated and the DA data before T0 is traceable, users can safely withdraw their funds from L2.

Summary

So now we can roughly clarify the differences in security between Validium and Plasma:

After the sequencer of Validium releases the stateroot, as long as the Validity Proof and DAC multisignature are immediately published, it can be deemed valid and become the latest valid stateroot. If users and honest L2 nodes encounter data withholding attacks and cannot construct the Merkle Proof corresponding to the current valid stateroot, they cannot withdraw to L1.

However, after Plasma submits a new stateroot, it has to wait for the window period to end before it becomes valid. At this time, the valid stateroot is submitted in the past. Because there is a window period (ARB is 3 days, OP is 7 days), even if the DA data of the newly submitted stateroot is unavailable, users still have the DA data of the current valid stateroot (the valid root is submitted in the past) and enough time to force withdrawals to L1.

Therefore, Dankrad’s statement makes sense. When a data withholding attack occurs, Validium may trap user assets in L2, but Plasma does not have this problem.

Therefore, data withholding attacks on the off-chain DA layer can cause many security risks, but Celestia is trying to solve this problem. In addition, because most Layer2 projects provide server ports for L2 nodes to maintain off-chain synchronization with the sequencer, Dankrad’s concerns are often only theoretical, not practical.

If we adopt a critical attitude and make more extreme assumptions: if all Plasma off-chain nodes become unavailable, then ordinary users who have not run L2 nodes will be unable to force withdrawals to L1. However, the probability of such an event is equivalent to the probability that all nodes of a public chain collectively permanently crash, and this may never happen.

So, many times, people are just talking about things that will never happen. Just like the famous quote from the American TV series “Chernobyl” where Deputy Chairman Bryukhanov said to the protagonist, “Why worry about things that will never happen?”