Author: Faust, geek web3
As for why Plasma has been buried for a long time, and why Vitalik will strongly support Rollup, the clues mainly point to two points: implementing DA off-chain on the Ethereum chain is unreliable, and data withholding is easy to occur, and once data withholding occurs, fraud proof is difficult to develop; **These two points make Plasma basically only UTXO or approximate models.
To understand these two core points, let’s start with DA and data retention. DA stands for Data Avalibility, which literally translates to data availability, and is now misused by many people, so much so that it is seriously confused with “historical data can be checked”. But in reality, “historical data” and “proof of storage” are long-standing problems that have been solved by the likes of Filecoin and Arweave. According to the Ethereum Foundation and Celestia, the DA issue is purely about data withholding scenarios. **
Merkle Tree & Merkle Root & Merkle Proof
To illustrate what data withholding attacks and DA problems mean, we need to first briefly talk about Merkle Root and Merkle Tree. **In Ethereum, or most public chains, a tree-like data structure called the Merkle Tree is used to act as a summary/directory of the state of the entire account, or to record the transactions packaged within each block.
**The leaf node at the bottom of the Merkle Tree is composed of hashes of raw data such as transactions or account status, **These hashes are summed in pairs and iterations, and a Merkle Root can finally be calculated.
(The record at the bottom of the diagram is the original dataset corresponding to the leaf node)
Merkle Root has a property: if a leaf node at the bottom of the Merkle Tree changes, the calculated Merkle Root will also change. Therefore, Merkle Trees corresponding to different original datasets will have different Merkle Roots, just like different people have different fingerprints. The proof verification technology, known as Merkle Proof, takes advantage of this property of the Merkle Tree.
For example, if Li Gang only knows the value of the Merkle Root in the figure, he does not know what data the complete Merkle Tree contains. We need to prove to Li Gang that Record 3 is indeed related to the root in the picture, or that the hash of Record 3 exists on the Merkle tree corresponding to the root.
We only need to submit Record3 and the 3 digest blocks marked as gray to Li Gang, instead of committing the entire Merkle Tree or all of its leaf nodes, which is the simplicity of Merkle Proof. When the underlying record of the Merkle Tree has a large number of leaves, such as 2 to the power of 2 data blocks (about 1 million), Merkle Proof only needs to contain at least 21 data blocks.
(The data block 30 and H2 in the figure can constitute a Merkle Proof, proving that the data block 30 exists on the Merkle Tree corresponding to H0)**
In Bitcoin, Ethereum, or cross-chain bridges, this “simplicity” of Merkle Proof is often used. The light node we know is actually the above-mentioned Li Gang, who only receives the block header from the full node, not the full block. It is important to emphasize here that Ethereum uses a Merkle tree called the State Trie, which acts as a summary of the entire account. The State Trie’s Merkle Root, called StateRoot, changes whenever the state of one of the accounts associated with the State Trie changes.
In the block header of Ethereum, StateRoot will be recorded, and the Merkle Root (referred to as Txn Root) of the transaction tree will also be recorded. If block 100 contains 300 transactions, then the leaves of the trading tree represent these 300 Txn.
Another difference is that the overall amount of data in State Trie is particularly large, and its underlying leaf corresponds to all addresses on the Ethereum chain (in fact, there are many obsolete state hashes), so the original dataset corresponding to State Trie will not be published to the block, only the StateRoot will be recorded in the block header. The original dataset of the transaction tree is the Txn data in each block, and the TxnRoot of the tree will be recorded in the block header.
Since the light node only receives the block header, only knows the StateRoot and TxnRoot, and cannot deduce the complete Merkle Tree based on the root (this is determined by the nature of the Merkle Tree and the hash function), the light node cannot know the transaction data contained in the block, nor does it know what changes have occurred to the account corresponding to the State Trie. **
If Wang Qiang wants to prove to a light node (Li Gang mentioned earlier) that block 100 contains a certain transaction, and it is known that the light node knows the block header of block 100 and knows TxnRoot, then the above problem translates to: prove that this Txn exists on the Merkle Tree corresponding to TxnRoot. At this time, Wang Qiang only needs to submit the corresponding Merkle Proof.
In many cross-chain bridges based on light client solutions, the lightness and simplicity of light nodes and Merkle Proof mentioned above are often used. For example, ZK bridges such as Map Protocol will set up a contract on the ETH chain to receive block headers from other chains (such as Polygon). When Relayer submits the header of the 100th block of Polygon to the contract on the ETH chain, the contract will verify the validity of the header (such as whether it has enough signatures from 2/3 POS nodes in the Polygon network).
If the header is valid and a user declares that they have initiated a cross-chain Txn from Polygon to ETH, the Txn is packed into the 100th block of Polygon. He only needs to prove through Merkle Proof that the cross-chain Txn he initiated can correspond to the TxnRoot of block 100 header (in other words, it proves that the cross-chain Txn he initiated has a record in block 100 of Polygon). However, the ZK bridge will use zero-knowledge proofs to compress the amount of computation required to verify Merkle Proof, further reducing the verification cost of cross-chain bridge contracts.
DA and Data Retention Attack Issues
After talking about Merkle Tree and Merkle Root and Merkle Proof, let’s go back to the DA and data withholding attack problem mentioned at the beginning of the article, which was explored before 2017, and Celestia’s original paper archaeologized the origin of the DA problem. In a 2017~18 document, Vitalik himself talked about how blockers may deliberately conceal certain data fragments of the block and publish incomplete blocks, so that full nodes cannot confirm the correctness of transaction execution/state transitions.
At this point, the block producer can steal the user’s assets, such as transferring all the coins in account A to another address, and the full node cannot determine whether A himself has done so, because they do not know the complete transaction data contained in the latest block.
In Layer 1 public chains such as Bitcoin or Ethereum, honest full nodes will directly reject the above invalid blocks. But light nodes are different, they only receive the block header from the network, they only know the StateRoot and TxnRoot, and they don’t know whether the original block corresponding to the header and the two roots is valid.
In the Bitcoin white paper, there is actually a brain hole for this situation, Satoshi Nakamoto once believed that most users will tend to run light nodes with lower configuration requirements, and light nodes cannot judge whether the block corresponding to the block header is valid, and if a block is invalid, the honest full node will send an alarm to the light node.
But Satoshi Nakamoto didn’t do a more detailed analysis of this solution, and later Vitalik and Celestia founder Mustafa built on this idea, combined with the work of other predecessors, to introduce DA data sampling to ensure that honest full nodes can restore the complete data of each block and raise an alarm when necessary.
Note: DA Data Sampling (DAS) and Celestia are not the focus of this article, interested readers can read the previous article of Geek Web3: “Misconceptions about Data Availability: DA= Data Publishing ≠ Historical Data Retrieval”
Plasma’s Fraud Proof
To put it simply, Plasma is a scaling solution that only publishes Layer 2 block headers to Layer 1, and DA data outside of the block header (complete transaction data set/state change per account) is only published off-chain. In other words, Plasma is like a cross-chain bridge based on light clients, implementing a Layer 2 light client with a contract on the ETH chain, and when a user declares that they want to cross assets from L2 to L1, they must submit a Merkle Proof to prove that they actually own the assets.
**The verification logic for assets spanning from L2 to L1 is similar to the ZK bridge mentioned above, except that the Plasma bridge model is based on fraud proofs rather than ZK proofs, which is closer to the so-called “optimistic bridge”. **Withdrawal requests from L2 to L1 in the Plasma network are not released immediately, but have a “challenge period”, as for the purpose of the challenge period, we will explain below.
Plasma does not have strict requirements for data release/DA, the sequencer/operator just broadcasts each L2 block off-chain, and the nodes that are willing to obtain the L2 block do so on their own. After that, the sequencer will publish the header of the L2 block to Layer 1. For example, the sequencer broadcasts block 100 off-chain and then publishes the block’s header on-chain. If block 100 contains invalid transactions, any plasma node can submit a Merkle Proof to the contract on ETH before the end of the “challenge period” to prove that block 100 header can be associated with an invalid transaction, which is a scenario covered by fraud proofs.
Plasma’s fraud proof use cases also include the following:
- Suppose the progress of the Plasma network reaches block 200, and user A initiates a withdrawal statement, saying that he has 10 ETH in block 100. But in fact, user A spent the ETH on the account after block 100.
So, A’s behavior is actually to spend 10 ETH, declare that he had 10 ETH in the past, and try to withdraw the ETH. This is the classic “double withdrawal”, double spending. At this time, anyone can submit a Merkle Proof to prove the latest asset status of user A, and does not meet its withdrawal statement, that is, to prove that A did not have a withdrawal statement after block 100 (different Plasma schemes have inconsistent proof methods for this situation, and the account address model is far more troublesome than the double-spend proof of UTXO).
- If it is a Plasma scheme based on the UTXO model (which was mainly the case in the past), there is no StateRoot in the block header, only TxnRoot (UTXO does not support the Ethereum-style account address model, nor does it have a global state design like State Trie). In other words, a chain that adopts the UTXO model only has transaction records, not state records.
In this case, the sequencer itself may launch a double-spend attack, such as spending a UTXO that has already been spent, or issuing additional UTXOs to a user out of thin air. Any user can submit a Merkle Proof to prove that the UTXO’s usage history has appeared (been spent) in previous blocks, or to prove that the historical origin of a UTXO is questionable. **
- For EVM-compliant/State-Trie-enabled Plasma schemes, it is possible for the sequencer to submit an invalid StateRoot, for example, after executing the transaction contained in block 100, the StateRoot should be converted to ST+, but the sequencer submits ST- to Layer 1.
In this case, the fraud proof is more complex and requires the transaction in block 100 to be replayed on the Ethereum chain, which consumes a lot of gas with the amount of computation and input parameters required. It is difficult for the early Plasma adoption teams to achieve such complex fraud proofs, so most of them use the UTXO model, after all, UTXO-based fraud proofs are very simple and easy to implement (Fuel, the first Rollup scheme to launch fraud proofs, is based on UTXO)
Data Retention & Exit Game****
Of course, the above-mentioned scenarios where fraud proofs can take effect are only established when the DA/data release is valid. If the sequencer withholds data and does not publish the full block off-chain, the Plasma node will not be able to confirm whether the block header on Layer 1 is valid, and of course it will not be able to publish the fraud proof smoothly.
At this time, the sequencer can steal the user’s assets, such as transferring all the coins from account A to account B, then transferring money from account B to C, and finally initiating a withdrawal in the name of C. Accounts B and C are owned by the sequencer, and the transfer of B->C is harmless even if it is publicized to the public.** But the sequencer can withhold the data of the invalid transfer of A->B, and people cannot prove that there is a problem with the source of assets of B and C** (to prove that the source of B’s assets is problematic, it is necessary to point out that the digital signature of “a certain Txn transferred to B” is incorrect).
The UTXO-based Plasma solution is targeted by the fact that anyone initiating a withdrawal must submit the full history of the asset, although there are more improvements later. However, if it is an EVM-compatible Plasma solution, it will be weak in this area. Because if the contract-related Txn is involved, there will be a huge cost in verifying the state transition process on the chain, so it is difficult to implement a verification scheme for the validity of withdrawals by supporting the account address model and smart contract Plasma.
Also, aside from the topic above, whether it’s UTXO-based or account-address model-based Plasma, data withholding can cause panic because you don’t know what transactions the sequencer is performing. **Plasma nodes will find something wrong, but they will not be able to publish fraud proofs because the Plasma sequencer will not send out the data required for fraud proofs.
At this time, people can only see the corresponding block header, but they don’t know what’s in the block, and they don’t know what their account assets have become, so they will collectively initiate a withdrawal statement and try to withdraw with the Merkle Proof corresponding to the historical block, triggering an extreme scenario called “Exit Game”, which will lead to a “stampede”, which will make Layer 1 seriously congested, and will still cause some people’s assets to be damaged (People who don’t receive honest node notifications or don’t swipe Twitter won’t know that the sequencer is stealing coins.)
Therefore, Plasma is an unreliable Layer2 scaling solution, and once a data withholding attack occurs, it will trigger an “Exit Game”, which is easy for users to suffer losses, which is a major reason for its abandonment. **
Reasons why plasma is difficult to support smart contracts****
After talking about Exit Game and data retention issues, let’s look at why Plasma is difficult to support smart contracts, mainly for two reasons:
First, if it is an asset of a Defi contract, who should withdraw it to Layer 1? Because this is essentially migrating the state of the contract from Layer 2 to Layer 1, suppose someone charges 100 ETH to the LP pool of the DEX, and then the Plasma sequencer does evil, and people want to withdraw urgently, at this time, the user’s 100 ETH is still controlled by the DEX contract, who should mention these assets to Layer 1 at this time?
The best way to do this seems to be to let the user redeem the assets from the DEX first, and then the user will withdraw the money to L1 by himself, but the problem is that the Plasma sequencer has done something bad and may reject the user’s request at any time.
So, what if we set up an Owner for the DEX contract in advance, allowing him to put the contract assets on L1 in case of an emergency? Obviously, this will give the contract owner ownership of the public assets, and he can put these assets on L1 at any time and run away, wouldn’t that be terrible?
Obviously, what to do with these “public property” dominated by Defi contracts is a huge thunder. **This actually involves the problem of the distribution of public power, which Xiangma has previously talked about in an interview with “It is difficult for high-performance public chains to do new things, and smart contracts involve the distribution of power”.
Second, if the contract is not allowed to migrate its state, it will suffer a huge loss, and if the contract is allowed to migrate its state to Layer 1, there will be double withdrawals that are difficult to solve with Plasma fraud proof:
For example, let’s assume that Plasma adopts Ethereum’s account address model, supports smart contracts, has a coin mixer, currently deposits 100 ETH, and the owner of the coin mixer is controlled by Bob;
Let’s say Bob withdraws 50 ETH from the mixer at block 100. After that, Bob initiated a withdrawal statement and crossed the 50 ETH to Layer 1;
After that, Bob uses a snapshot of the past contract state (e.g., block 70) to migrate the past state of the mixer to Layer 1, which will also cross the 100 ETH that the mixer “once had” to Layer 1.
Obviously, this is a typical “double drawdown”, which is a double spend. 150 ETH was mentioned by Bob to Layer 1, but Layer 2 network users only paid 100 ETH to the mixer/Bob, and 50 ETH was withdrawn out of thin air. This can easily drain Plasma’s reserves. Theoretically, one could initiate a fraud proof to prove that the state of the mixer contract has changed after block 70.
But if you want to show evidence that the Mixer contract has changed after Block 70, you have to run all the Txn mentioned above on the Ethereum chain to finally let the Plasma contract determine that the state of the Mixer contract has indeed changed (the reason why it is so complex is determined by the structure of Plasma itself). If the amount of Txn is so large, the fraud proof will not be published on Layer 1 at all (it will exceed the gas limit for a single block of Ethereum).
Theoretically, in the above double-spend scenario, it seems that you only need to submit a snapshot of the current state of the mixer (which is actually the Merkle proof corresponding to StateRoot), but in fact, since Plasma does not publish transaction data on the chain, the contract cannot determine whether the snapshot of the state you submit is valid. **This is because the sequencer itself may initiate data holding, submit invalid status snapshots, and maliciously point out any withdrawal. **
For example, when you declare that you have 50 ETH on your account and initiate a withdrawal, the sequencer may privately clear your account to 0, and then initiate data withholding, send an invalid StateRoot to the chain, and submit a corresponding state snapshot to falsely accuse you of running out of money in your account. At this point, you can’t prove that the StateRoot and State Snapshot submitted by the sequencer are invalid, because he initiated data holding, and you don’t get the enough data needed to prove fraud. **
To prevent this, the Plasma node also replays the transaction history during this period when presenting a snapshot of the state to prove that someone has double-spend, which prevents the sequencer from withholding data to prevent others from withdrawing. In Rollup, if you encounter the above-mentioned double withdrawal, you don’t need to replay the historical transaction in theory, because Rollup does not have the problem of data withholding and will “force” the sequencer to publish DA data on the chain. **Rollup sequencers that submit an invalid StateRoot-state snapshot will either fail contract validation (ZK Rollup) or will soon be challenged (OP Rollup).
In fact, in addition to the example of the coin mixer mentioned above, scenarios such as multi-signature contracts can also lead to double withdrawals on the Plasma network. Fraud proofs are inefficient in handling such scenarios. **This situation is analyzed in ETH Research.
To sum up, because the Plasma scheme is not conducive to smart contracts and basically does not support the migration of contract state to Layer 1, the mainstream Plasma has to choose UTXO or similar mechanisms, because UTXO does not have the problem of asset ownership conflict, and can well support fraud proof (much smaller in size), but at the cost of a single application scenario, it can basically only support transfer or order book exchanges.
In addition, because the fraud proof itself has a strong dependence on DA data, it will be difficult to achieve an efficient fraud proof system if the DA layer is unreliable. However, Plasma’s handling of DA problems is too rudimentary to solve the problem of data withholding attacks, and with the rise of Rollup, Plasma has slowly faded out of history. **
