Data Withholding and Fraud Proofing: Why Plasma Doesn’t Support Smart Contracts

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 under the Ethereum chain is unreliable, and data withholding is easy to occur. Once data withholding occurs, fraud proof is difficult to carry out;The mechanism design of Plasma itself is extremely unfriendly to smart contracts, and it is especially difficult to support the migration of contract status to Layer 1.These two points make Plasma basically only use UTXO or similar models.

In order to understand the above two core points, let’s start with the issues of DA and data withholding.The full name of DA is Data Availability, which is literally translated as data availability. It is now misused by many people.So much so that it is seriously confused with “historical data can be checked”. But in fact, “historical data can be checked” and “storage proof” are problems that Filecoin and Arweave have already solved.According to the Ethereum Foundation and Celestia, the DA issue purely explores data withholding scenarios.

Merkle Tree and Merkle Root and Merkle Proof

To explain what data withholding attacks and DA issues actually mean,We need to briefly talk about Merkle Root and Merkle Tree first.In Ethereum or most public chains, a tree-like data structure called Merkle Tree is used to serve as a summary/directory of the status of all accounts, or to record the transactions packaged in each block.

The leaf node at the bottom of the Merkle Tree is composed of hashes of original data such as transactions or account status.These hashes are summed in pairs and iterated repeatedly, and finally a Merkle Root can be calculated.

（The record at the bottom of the figure is the original data set 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 data sets will have different Merkle Roots, just like different people have different fingerprints. The proof verification technology called Merkle Proof takes advantage of this property of Merkle Tree. Taking the above picture as an example, if Li Gang only knows the value of Merkle Root in the picture, he does not know what data the complete Merkle Tree contains. We want to prove to Li Gang that Record 3 is indeed related to the Root in the picture, or in other words, prove that the hash of Record 3 exists on the Merkle Tree corresponding to the Root. We only need to submit Record3 and the three digest data blocks marked gray to Li Gang, without having to submit the entire Merkle Tree or all its leaf nodes.Such is the simplicity of Merkle Proof.When the underlying records of Merkle Tree contain very many leaves, for example, it contains 2 to the 20th power of data blocks (approximately 1 million), Merkle Proof only needs to contain at least 21 data blocks.

(Data block 30 and H2 in the figure can constitute Merkle Proof, proving that data block 30 exists on the Merkle Tree corresponding to H0)This “simplicity” of Merkle Proof is often used in Bitcoin, Ethereum or cross-chain bridges. The light node we know is actually Li Gang mentioned above. He only receives the block header from the full node, not the complete block. It needs to be emphasized here that Ethereum uses a Merkle tree called State Trie to serve as a summary of all accounts. As long as the status of an account associated with the State Trie changes, the Merkle Root of the State Trie, called the StateRoot, will change.In the block header of Ethereum, the StateRoot will be recorded, and the Merkle Root of the transaction tree (referred to as Txn Root) will also be recorded., one difference between a transaction tree and a state tree is that the data represented by the underlying leaves is different. If block No. 100 contains 300 transactions, the leaves of the transaction tree represent these 300 Txn. Another difference is that the overall data volume of State Trie is extremely large. Its bottom leaves correspond to all addresses on the Ethereum chain (in fact, there are many outdated state hashes), so the original data set corresponding to State Trie will not be released. In the block, only the StateRoot is recorded in the block header. The original data set of the transaction tree is the Txn data in each block, and the TxnRoot of this tree will be recorded in the block header.

Since the light node only receives the block header and only knows the StateRoot and TxnRoot, it cannot deduce the complete Merkle Tree based on the Root (this is determined by the properties of the Merkle Tree and the hash function), soLight nodes cannot know the transaction data contained in the block, nor do they know what changes have occurred in the account corresponding to the State Trie.If Wang Qiang wants to prove to a light node (Li Gang mentioned earlier) that block No. 100 contains a certain transaction, and it is known that the light node knows the block header of block No. 100 and knows TxnRoot, then the above problem is transformed into: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 light weight 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 specifically receive block headers from other chains (such as Polygon). When the Relayer submits the header of Polygon’s 100th block to the contract on the ETH chain, the contract will verify the validity of the header (for example, whether it has collected the signatures of 2/3 POS nodes in the Polygon network). If the Header is valid and a user declares that he initiated a cross-chain Txn from Polygon to ETH, the Txn will be packaged into the 100th block of Polygon. He only needs to use Merkle Proof to prove that the cross-chain Txn initiated by him can correspond to the TxnRoot in the block header No. 100 (in other words,It is to prove that the cross-chain Txn initiated by you is recorded in Polygon block 100.). However, ZK Bridge will use zero-knowledge proof to compress the calculation amount required to verify Merkle Proof, further reducing the verification cost of cross-chain bridge contracts.

DA and Data Withholding Attack Issues

After talking about Merkle Tree, Merkle Root, and Merkle Proof, let’s return to the issue of DA and data withholding attacks mentioned at the beginning of the article. This issue has been discussed as early as 2017. Celestia’s original paper has the source of the DA issue. Conduct archeology.Vitalik himself mentioned in a document from 2017 to 2018 that the block producer may deliberately conceal certain data fragments of the block and release incomplete blocks to the outside world.As a result, the full node cannot confirm the correctness of transaction execution/state transition.

At this time, the block producer can steal user assets, such as transferring all the coins in A’s account to other addresses, but the full node cannot judge whether A himself has done this because they do not know the complete transaction included in the latest block. data.

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 block headers from the network.We only know the StateRoot and TxnRoot, but we don’t know whether the Header and the original blocks corresponding to the two Roots are valid.

In the Bitcoin white paper, there is actually some thinking about this situation. Satoshi Nakamoto once believed that most users would tend to run light nodes with lower configuration requirements, and light nodes cannot judge whether the block corresponding to the block header is valid. If a block is invalid, honest full nodes will send an alert to light nodes.

However, Satoshi Nakamoto did not conduct a more detailed analysis of this solution. Later, Vitalik and Celestia founder Mustafa combined this idea with the results of other predecessors and introduced DA data sampling to ensure that honest full nodes can restore each area. block of complete data and generate alerts when necessary.

Note: DA Data Sampling (DAS) and Celestia are not the focus of this article. Interested readers can read past articles of “Geek Web3”:“Misunderstanding of Data Availability: DA = Data Release ≠ Historical Data Retrieval”

Plasma’s fraud proof

simply put,Plasma is an expansion solution that only publishes the block header of Layer2 to Layer1, and the DA data outside the block header (complete transaction data set/status changes of each account)Only released off-chain. In other words, Plasma is like a cross-chain bridge based on light clients. It uses contracts to implement Layer 2 light clients on the ETH chain. When users declare that they want to cross assets from L2 to L1, they must submit a Merkle Proof to prove themselves. does own these assets.The verification logic of assets crossing from L2 to L1 is similar to the ZK bridge mentioned above, except that Plasma’s bridging model is based on fraud proof, not ZK proof, and is closer to the so-called “optimistic bridge”.Withdrawal requests from L2 to L1 in the Plasma network will not be released immediately, but there will be 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 only broadcasts each L2 block off-chain, and nodes that are willing to obtain L2 blocks can obtain it themselves. Afterwards, the sorter will publish the header of the L2 block to Layer1. For example, the sequencer first broadcasts block No. 100 off-chain, and then publishes the block header to the chain. If block 100 contains invalid transactions, any Plasma node can submit Merkle Proof to the contract on ETH before the end of the “challenge period”.Prove that block header No. 100 can be associated with an invalid transaction,This is a scenario covered by fraud proof.

Plasma’s fraud proof application scenarios also include the following:1. Assume that the progress of the Plasma network reaches block No. 200. At this time, user A initiates a withdrawal statement, saying that when he was in block No. 100, he had 10 ETH. But in fact, user A spent the ETH on his account after block 100. Therefore, A’s behavior is actually: after spending 10 ETH, he declares that he had 10 ETH in the past, and tries to withdraw these ETH. This is a typical “double withdrawal” and double spending. at this time,Anyone can submit Merkle Proof to prove that user A’s latest asset status does not satisfy his withdrawal statement, that is, to prove that A has not withdrawn the money stated after block 100.(Different Plasma schemes have inconsistent proof methods for this situation, and the account address model is far more troublesome than UTXO’s double-spend proof). 2. If it is a Plasma solution based on the UTXO model (this was mainly the case in the past), the block header does not contain StateRoot, only TxnRoot (UTXO does not support the Ethereum-style account address model, and there is no global state such as State Trie) design). In other words, a chain using the UTXO model only has transaction records and no status records. At this time, the sequencer itself may launch a double-spend attack, such as spending a UTXO that has been spent again, or issuing additional UTXO to a user out of thin air.Any user can submit a Merkle Proof to prove that the usage record of the UTXO has appeared (was spent) in past blocks, or to prove that there is a problem with the historical source of a certain UTXO.

1. For EVM-compatible/State Trie-supported Plasma solutions, the sorter may submit an invalid StateRoot. For example, after executing the transaction contained in the 100th block, the StateRoot should be converted to ST+, but the sorter goes to Layer1 What was submitted was ST-. The fraud proof in this case is more complicated and requires replaying the transaction in block No. 100 on the Ethereum chain. The calculation amount and required input parameters will consume a lot of gas.Teams that early adopted Plasma had difficulty in achieving such complex fraud proofs, so most of them adopted the UTXO model. After all, UTXO-based fraud proofs are simple and easy to implement.(Fuel, the first rollup solution to provide fraud proof, is based on UTXO)

Data Withholding and Exit GameOf course, the above scenarios where the fraud proof can be effective are only established when the DA/data release is effective. If the sequencer engages in data withholding and does not publish complete blocks 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 issue fraud proofs smoothly.

At this point, the sequencer can steal user assets,For example, privately transfer all the coins in account A to account B, then transfer money from account B to account C, and finally initiate a withdrawal in the name of C. Accounts B and C are owned by the sequencer itself. Even if the transfer B->C is made public, it will not cause any harm;But the sorter can withhold the data of the invalid transfer A->B, and people cannot prove that there is a problem with the source of the assets of B and C.(To prove that the source of B’s assets is fishy, ​​it is necessary to point out that the digital signature of “a certain Txn transferred to B” is incorrect). The UTXO-based Plasma solution has targeted measures. For example, when anyone initiates a withdrawal, they must submit all historical sources of the assets. Of course, there will be more improvement measures later. But if it is an EVM-compatible Plasma solution, it will appear weak in this area.Because if Txn related to the contract is involved, verifying the state transition process on the chain will incur huge costs,Therefore, Plasma, which supports account address models and smart contracts, cannot easily implement a verification scheme for the validity of withdrawals. Furthermore, aside from the above topic,Whether it is Plasma based on UTXO or the account address model, once data withholding occurs, it will basically cause people to panic because you don’t know what transactions the sequencer has executed.Plasma nodes will find something is wrong, but they will not be able to issue fraud proofs because the Plasma sequencer has not issued the data required for fraud proofs. At this time, people can only see the corresponding block header, but they don’t know what is in the block or what has become of their account assets. Everyone will collectively initiate a withdrawal statement and use the corresponding block header. Merkle Proof attempts to withdraw money,Triggering an extreme scenario called “Exit Game”, this situation will lead to a “ stampede “, causing serious congestion in Layer 1, and will still cause some people’s assets to be damaged.(People who have not received honest node notifications or do not check Twitter will not know that the sequencer is stealing coins).

so,Plasma is an unreliable Layer 2 expansion solution. Once a data withholding attack occurs, the “Exit Game” will be triggered, which can easily cause users to suffer losses. This is a major reason for its abandonment.Why Plasma has difficulty supporting smart contractsAfter talking about the Exit Game and data retention issues, let’s look at why Plasma has difficulty supporting smart contracts. There are two main reasons: First,If it is an asset of a Defi contract, who should withdraw it to Layer1? Because this is essentially migrating the contract status from Layer2 to Layer1.Suppose someone deposits 100 ETH into the DEX LP pool, and then the Plasma sequencer does something evil, and people want to withdraw money urgently. At this time, the user’s 100 ETH are still controlled by the DEX contract. Who should own these assets at this time? Mentioned on Layer1? The best way seems to be to let users redeem assets from DEX first, and then let users transfer the money to L1 themselves. But the problem is that the Plasma sorter has done evil and may reject user requests at any time. So, what if we set up the Owner for the DEX contract in advance and allow him to lift the contract assets to L1 in an emergency? Obviously this will give the contract owner ownership of public assets. He can lift these assets to L1 and run away at any time. Isn’t this terrible? Obviously,How to deal with these “public properties” controlled by Defi contracts is a huge surprise.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.

Secondly, if the contract is not allowed to migrate, it will suffer huge losses;If the contract is allowed to migrate its state to Layer1, there will be a double withdrawal that is difficult to solve in Plasma fraud proof:For example, weAssume that Plasma adopts the account address model of Ethereum and supports smart contracts., there is a mixer, currently deposited with 100 ETH, and the owner of the mixer is controlled by Bob; assume that Bob withdraws 50 ETH from the mixer in the 100th block. Afterwards, Bob initiates a withdrawal statement and transfers the 50 ETH to Layer1; then, Bob uses the past contract state snapshot (such as the 70th block) to migrate the past state of the mixer to Layer1, which will The 100 ETH that the mixer “used to own” was also transferred to Layer1; obviously, this is a typical “double withdrawal”, that is, a double spend.150 ETH were mentioned by Bob to Layer 1, but Layer 2 network users only paid 100 ETH to the mixer/Bob, and 50 ETH were withdrawn out of thin air. This could easily drain Plasma’s reserves dry。In theory, one could initiate a fraud proof to prove that the state of the mixer contract changed after the 70th block. But if after block No. 70, all Txn that interacted with the mixer contract did not change the contract status, except for the transaction in which Bob took away 50 ETH; if you want to show evidence, point out that the mixer contract is in If there is a change after block No. 70, all the Txn mentioned above must be run on the Ethereum chain, and finally the Plasma contract can be confirmed. The status of the mixer contract has indeed changed (the reason why it is so complicated is because Determined by the structure of Plasma itself).If the number of Txn in this batch is extremely large, the fraud proof cannot be published on Layer1 at all.(It will exceed the gas limit of a single block of Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretically, in the above double-spend scenario, it seems that only the current state snapshot of the mixer is submitted (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 you Whether the submitted state snapshot is valid.This is because the sequencer itself may initiate data withholding, submit invalid state snapshots, and maliciously incriminate any withdrawr.For example, when you declare that you have 50 ETH in your account and initiate a withdrawal, the sequencer may privately clear your account to 0, then initiate data withholding, send an invalid StateRoot to the chain, and submit the corresponding state snapshot , falsely accusing you of running out of money in your account.At this time, we cannot prove that the StateRoot and state snapshot submitted by the sequencer are invalid, because it has initiated data withholding, and you cannot obtain sufficient data required for fraud proof.In order to prevent this, when a Plasma node presents a state snapshot to prove that someone has double-spended, it will also replay the transaction records during this period. This can prevent the sequencer from using data withholding to prevent others from withdrawing money. In Rollup, if you encounter the above-mentioned double withdrawal, theoretically there is no need to replay historical transactions, becauseRollup does not have data withholding issues and will “force” the sequencer to publish DA data on the chain.If the Rollup sequencer submits an invalid StateRoot-state snapshot, it will either fail contract verification (ZK Rollup) or will be challenged soon (OP Rollup).In fact, in addition to the coin mixer example mentioned above, scenarios such as multi-signing contracts can also lead to double withdrawals on the Plasma network. Fraud proof is very inefficient in handling this scenario.This situation is analyzed in ETH Research. In summary,Since the Plasma solution is not conducive to smart contracts and basically does not support the migration of contract status to Layer 1, mainstream Plasma has to use UTXO or similar mechanisms.Because UTXO does not have the problem of asset ownership conflicts and can support fraud proof very well (it is much smaller in size), the price is that it has a single application scenario and can basically only support transfers or order book exchanges. In addition, because the fraud proof itself has a strong dependence on DA data, if the DA layer is unreliable, it will be difficult to implement an efficient fraud proof system. However, Plasma’s handling of the DA problem is too crude and cannot solve the problem of data withholding attacks.With the rise of Rollup, Plasma slowly faded from the stage of history.

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.