Expelling Validium? Reinterpreting Layer 2 from the Perspective of the Danksharding Proposer

Author: Faust, Geek web3

Introduction: Recently, Dankrad Feist, the researcher from the Ethereum Foundation and the proposer of Danksharding, made some controversial statements on Twitter. He explicitly pointed out that modular blockchains that do not use ETH as a DA layer (Data Availability layer) are not Rollups and are also not Ethereum Layer 2. According to Dankrad, Arbitrum Nova, Immutable X, and Mantle should be "disqualified" from the Layer 2 list because they only disclose transaction data outside of ETH (by building 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, still count as Layer 2, but Validium (ZKRollup that does not use ETH as a DA layer) does not count as Layer 2.

Once Dankrad made these statements, many founders and researchers in the Rollup field questioned them. After all, many "Layer 2" projects do not use ETH as a DA layer to save costs, and 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 does not count as L2, Plasma should also not qualify as L2.

In response, Dankrad stated that Plasma users can still safely withdraw their assets to L1 when DA is unavailable (referring to the off-chain DA layer network withholding data and not disclosing transaction data); however, under the same circumstances, Validium (most projects using the StarkEx solution are Validium) can prevent users from withdrawing funds to L1, effectively freezing their money.

Clearly, Dankrad intends to define whether a scaling project is Ethereum Layer 2 based on "whether it is secure." From the perspective of "security," Validium can indeed freeze user assets on L2 and prevent them from being withdrawn to L1 in extreme cases of sequencer failure + DA layer initiating data withholding attacks (concealing new data); Plasma, due to its design being different from Validium, although it generally does not provide as much security as Validium, allows users to safely withdraw their assets to L1 during sequencer failure + DA layer data withholding attacks. Therefore, Dankrad's argument is not without merit.

This article intends to start from Dankrad's perspective and further analyze the details of Layer 2 to deeply understand why Validium is not strictly considered "Layer 2."

How to Define Layer 2?

According to the definition on ethereum.org and most members of the Ethereum community, Layer 2 is an "independent blockchain that provides scalability for Ethereum + inherits Ethereum's security." First, "providing scalability for Ethereum" refers to offloading traffic that Ethereum cannot handle, alleviating pressure on TPS. "Inheriting Ethereum's security" can actually be translated as "relying on Ethereum to ensure its own security."

For example, all transactions (Tx) on Layer 2 must complete final settlement on ETH, and erroneous Tx will not be released; if Layer 2 blocks need to be rolled back, the Ethereum blocks must first be rolled back. As long as the Ethereum mainnet does not experience a block rollback similar to a 51% attack, the L2 blocks will not roll back.

If we further explore the security of Layer 2, we actually need to consider many extreme situations. For instance, if the L2 project team runs away, the sequencer fails, or the off-chain DA layer goes down, in these extreme events, can users safely withdraw their funds from L2 to L1?

The "Forced Withdrawal" Mechanism of Layer 2

Disregarding factors like L2 contract upgrades/multi-signature risks, both Arbitrum and StarkEx have set up forced withdrawal exits for users. Suppose the sequencer of L2 initiates a censorship attack, deliberately rejecting users' transaction/withdrawal requests, or simply goes permanently offline. Arbitrum users can call the force Inclusion function of the Sequencer Inbox contract on L1 to submit transaction data directly to L1; if the sequencer does not process this "forced inclusion" transaction/withdrawal within 24 hours, the transaction will be directly included in the Rollup ledger's transaction sequence, creating a "safe exit" for L2 users to force withdrawal.

In contrast, the StarkEx solution with an Escape Hatch mechanism is even more robust. If an L2 user's Forced Withdrawal request submitted on L1 does not receive a response from the sequencer by the end of the 7-day window, that user can call the freeze Request function to put L2 into a freeze period. At this point, the L2 sequencer will not be able to update L2's state on L1, and the L2 state will remain frozen for one year before it can be unfrozen.

Once the L2 state is frozen, users can construct a Merkle Proof related to the current state to prove they have XX amount of funds on L2 and withdraw through the Escape Hatch-related contracts on L1. This is the "full withdrawal" service provided by the StarkEx solution. Even if the L2 project team is gone and the sequencer is permanently down, users still have a way to withdraw their funds from L2.

However, there is a problem: most L2s using the StarkEx solution are Validium (such as Immutable X and ApeX), which do not publish the data required for DA to ETH, meaning that the information needed to construct the current L2 state tree exists off-chain. If users cannot obtain the data needed to construct the Merkle Proof off-chain (for example, if the off-chain DA layer initiates a data withholding attack), they will not be able to withdraw through the Escape Hatch.

At this point, the reason Dankrad believes Validium is unsafe becomes clear: because Validium does not publish DA data on-chain like Rollup, users may be unable to construct the Merkle Proof required for "forced withdrawal."

The Difference Between Validium and Plasma During 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 then submits a Validity Proof (ZK Proof) to prove that the state transitions involved in the generation of the new Stateroot (changes in user funds) are correct.

(Image source: eckoDAO)

However, the Stateroot alone cannot restore the current state tree (world state trie), so it is impossible to know the specific status of each L2 account (including fund balances), and L2 users cannot construct the corresponding Merkle Proof for the current valid Stateroot. This is the disadvantage of Validium.

(Merkle Proof is actually the data required during the root generation process, which is the dark part in the image. To construct the Merkle Proof corresponding to the Stateroot, one must know the construction of the state tree and have DA data.)

It is essential to emphasize the DAC. The data involved in Validium's DA, such as the latest batch of transactions processed by the sequencer, will be synchronized to a dedicated off-chain DA network called the Data Availability Committee (DAC). The DAC consists of multiple node servers, generally operated and supervised by L2 officials, community members, or other entities (but this is just on the surface; it is challenging to verify who the DAC members are from the outside).

Interestingly, 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 match the DA data synchronized to the DAC. Only after the DAC's multi-signature submission will the new Stateroot and Validity Proof be considered valid.

Currently, Immutable X's DAC uses a 5/7 multi-signature, while dYdX, although it is a ZKRollup, also has a DAC that uses a 1/2 multi-signature. (dYdX only publishes State diff on L1, not complete transaction data. However, by obtaining the State diff from historical records, one can restore the asset balances of all L2 addresses, allowing for the construction of Merkle Proof for full withdrawal).

Dankrad's viewpoint is not without merit. If the DAC members of Validium conspire to initiate a data withholding attack, preventing other L2 nodes from synchronizing the latest data and updating the current valid Stateroot of L2, users will be unable to construct the Merkle Proof corresponding to the current valid root to withdraw (because the DA data after this point is unavailable, only the previous DA data is available).

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

But why do the theoretical problems that exist in Validium not exist in Plasma? This is because the way Plasma determines a valid Stateroot is different from Validium, due to the existence of a fraud proof window. Plasma is a Layer 2 scaling solution that predates OPRollup and, like OPR, relies on fraud proofs to ensure the security of L2.

Plasma, like OPR, has a window period setting, the new Stateroot published by the sequencer will not be immediately deemed valid; it must wait until the window period closes without any L2 nodes publishing fraud proofs. Therefore, the current valid Stateroot of Plasma and OPR is submitted days ago (similar to how we see starlight, which was emitted a long time ago), and users can often obtain DA data from the past.

At the same time, the premise for the fraud proof mechanism to take effect is that the DA data of L2 is available at that moment, meaning that the Plasma Verifier nodes can obtain the DA-related data at that moment to generate the fraud proof (if necessary).

So everything becomes straightforward: the normal operation of Plasma relies on the availability of DA data at that moment. If from that moment on, the DA of L2 becomes unavailable, can users safely withdraw their funds?

This question is not difficult to analyze. Suppose the window period of Plasma is 7 days; if from a certain point in time T0, the new DA data becomes unavailable (DAC initiates a data withholding attack, preventing honest L2 nodes from obtaining data after T0). Because the valid Stateroot at T0 and for a period afterward is submitted before T0, and the historical data before T0 is traceable, users can construct a Merkle Proof to force withdrawal.

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

Conclusion

At this point, we can roughly clarify the differences in security between Validium and Plasma:

After the sequencer of Validium publishes the Stateroot, as long as it immediately publishes the Validity Proof and DAC multi-signature, it can be deemed valid and become the latest valid Stateroot; if users and honest L2 nodes encounter a data withholding attack and cannot construct the Merkle Proof corresponding to the current valid Stateroot, they will be unable to withdraw to L1.

On the other hand, after Plasma submits a new Stateroot, it must wait for the window period to end before it can be deemed valid, and the valid Stateroot at that time is one 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 was submitted in the past), giving them enough time to force withdrawal to L1.
Thus, Dankrad's statements hold some truth. When a data withholding attack occurs, Validium has the potential to trap user assets in L2, but Plasma does not have this issue.
(In the image below, Dankrad's statement is slightly incorrect; Plasma should not allow the construction of a Merkle proof corresponding to an outdated valid Stateroot for withdrawal, as this would lead to double spending.)

Therefore, data withholding attacks on off-chain DA layers can pose many security risks, but Celestia is attempting to solve this problem. Additionally, because most Layer 2 projects provide service ports for L2 nodes to maintain off-chain synchronization with the sequencer, Dankrad's concerns are often theoretical rather than practical.

If we adopt a nitpicking attitude and propose even more extreme hypotheses: if all off-chain Plasma 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 occurring is equivalent to the probability of all nodes of a public chain collectively going permanently offline, which may never happen.

Thus, many times, people are just discussing things that are unlikely to happen. As the KGB deputy chairman says to the protagonist in the HBO series "Chernobyl": "Why worry about things that will never happen?"