Vitalik's Long Article: The Exit Game of EVM Validiums and the Return of Plasma

Plasma allows us to completely bypass the data availability problem, greatly reducing transaction fees.

Written by: Vitalik Buterin

Translated by: jk, Odaily

 

Plasma is a type of blockchain scaling solution that allows all data and computation (except for deposits, withdrawals, and Merkle roots) to remain off-chain. This opens the door to massive scalability unconstrained by on-chain data availability. Plasma was first proposed in 2017 and underwent several iterations in 2018, notably Minimal Viable Plasma, Plasma Cash, Plasma Cashflow, and Plasma Prime. Unfortunately, due to (i) significant client-side data storage costs and (ii) fundamental limitations of Plasma that make it difficult to extend beyond payments, Plasma has largely been replaced by rollups.

 

The advent of validity proofs (also known as ZK-SNARKs) gives us reason to reconsider this decision. The biggest challenge to making Plasma work for payments, client-side data storage, can be effectively addressed by validity proofs. Furthermore, validity proofs provide a suite of tools that allow us to create Plasma-like chains running the EVM. Plasma’s security guarantees do not cover all users, as the fundamental reasons that make it hard to extend Plasma-style exit games to many complex applications still exist. However, in practice, it is still possible to protect a very large proportion of assets securely.

 

Below, I will detail how Plasma achieves this.

 

Overview: How Plasma Works

The simplest version of Plasma to understand is Plasma Cash. Plasma Cash works by treating each individual token as a separate NFT and tracking a separate history for each token. The Plasma chain has an operator responsible for creating and periodically publishing blocks. Transactions in each block are stored as a sparse Merkle tree: if a transaction transfers ownership of token k, it appears at position k in the tree. When the Plasma chain operator creates a new block, they publish the Merkle root on-chain and directly send each user the Merkle branch corresponding to the tokens they own.

 

 

Suppose these are the last three transaction trees in the Plasma Cash chain. Then, assuming all previous trees are valid, we know that Eve currently owns token 1, David owns token 4, and George owns token 6.

 

The main risk in any Plasma system is operator misbehavior. This can happen in two ways:

 

1. Publishing invalid blocks (for example, the operator includes a transaction transferring token 1 from Fred to Hermione, even though Fred did not own the token at that time);

 

2. Publishing unavailable blocks (for example, the operator fails to send one of his Merkle branches to Bob, preventing him from proving to others that his token is still valid and unspent).

 

If the operator’s actions relate to a user’s assets, the user is responsible for exiting immediately (specifically, within 7 days). When a user (“exitor”) exits, they provide a Merkle branch proving the inclusion of the transaction transferring the token from the previous owner to them. This initiates a 7-day challenge period, during which others can challenge the exit by providing one of three types of Merkle proofs:

 

1. Not the latest owner: a subsequent transaction signed by the exitor transferring the exitor’s token to someone else;

 

2. Double spend: a transaction transferring the token from the previous owner to someone else, included before the transaction transferring the token to the exitor;

 

3. Invalid history: a transaction transferring the token in the past 7 days without a corresponding spend. The exitor can respond by providing the corresponding spend; if they do not, the exit fails.

 

 

According to these rules, anyone owning token k needs to see all Merkle branches at position k in all historical trees from the past week to ensure they actually own token k and can exit it. They need to store all branches containing asset transfers so they can respond to challenges and safely exit their tokens.

 

Extending to Fungible Tokens

The above design works for non-fungible tokens (NFTs). However, fungible tokens like ETH and USDC are more common than NFTs. One way to apply Plasma Cash to fungible tokens is to treat each small denomination of a token (e.g., 0.01 ETH) as a separate NFT. Unfortunately, if we do this, the gas cost for exits becomes too high.

 

One solution is to optimize by processing many adjacent tokens as a unit, allowing them to be transferred or exited at once. There are two ways to do this:

 

1. Use Plasma Cash almost as is, but use complex algorithms to very quickly compute Merkle trees for large numbers of objects if many adjacent objects are the same. Surprisingly, this is not hard to do; you can see a Python implementation here.

 

2. Use Plasma Cashflow, which simply represents many adjacent tokens as a single object.

 

However, both approaches encounter the fragmentation problem: if you receive 0.001 ETH from hundreds of people buying coffee, you will have 0.001 ETH in many places in the tree, so actually exiting these ETH still requires submitting many separate exits, making gas fees too high. Defragmentation protocols have been developed, but are tricky to implement.

 

Another approach is to redesign the system with a more traditional “unspent transaction output” (UTXO) model. When you exit a token, you need to provide the history of those tokens for the past week, and anyone can challenge your exit by proving that any of those historical tokens have already been exited.

 

 

The withdrawal of the 0.2 ETH UTXO at the bottom right can be canceled by showing the withdrawal of any UTXO in its history, as shown in green. Note in particular that the UTXOs in the middle left and lower left are ancestors, but the upper left UTXO is not. This approach is similar to the order-based coloring idea in colored coin protocols around 2013.

 

There are several technical ways to achieve this. In all cases, the goal is to track some notion of “the same token” at different points in history to prevent “the same token” from being withdrawn twice.

 

Challenges in Extending to the EVM

Unfortunately, extending this beyond payments to the EVM is much more difficult. A key challenge is that many state objects in the EVM do not have a clear “owner.” Plasma’s security depends on each object having an owner who is responsible for monitoring and ensuring data availability on-chain and exiting the object if anything goes wrong. However, many Ethereum applications do not work this way. For example, Uniswap liquidity pools do not have a single owner.

 

Another challenge is that the EVM does not attempt to restrict dependencies. In block N, ETH held in account A may come from anywhere in block N-1. To exit a consistent state, an EVM Plasma chain would need an exit game where, in the worst case, someone wishing to exit using information from block N might have to pay the cost of publishing the entire block N state on-chain: costs could reach millions of dollars. UTXO-based Plasma schemes do not have this problem: each user can exit their assets from the latest block for which they have data.

 

The third challenge is that the EVM’s unlimited dependencies make it difficult to have consistent incentives for validity proofs. The validity of any state depends on everything else, so proving anything requires proving everything. In this case, due to data availability issues, it is usually impossible to make failure resolution incentive-compatible. A particularly annoying problem is that we lose the guarantee present in UTXO-based systems that the state of an object cannot be changed without the owner’s consent. This guarantee is very useful because it means owners always know the latest provable state of their assets and simplifies the exit game. Without it, creating exit games becomes much more difficult.

 

How Validity Proofs Mitigate These Issues

The most basic function of validity proofs is to prove the validity of each Plasma block on-chain. This greatly simplifies the design space: it means we only need to worry about unavailable block attacks by the operator, not invalid blocks. For example, in Plasma Cash, it eliminates concerns about historical challenges. This reduces the state users need to download from one branch per block in the past week to one branch per asset.

 

Furthermore, extracting from the latest state (in the common case where the operator is honest, all withdrawals will be from the latest state) is not subject to non-latest owner challenges, so in a validity proof Plasma chain, such withdrawals are not challenged at all. This means that, under normal circumstances, withdrawals can be made immediately.

 

Extending to the EVM: Parallel UTXO Graphs

In the case of the EVM, validity proofs also allow us to do something clever: they can be used to implement parallel UTXO graphs for ETH and ERC 20 tokens, and use SNARKs to prove the equivalence between the UTXO graph and the EVM state. Once you have this, you can implement a “regular” Plasma system on the UTXO graph.

 

 

This allows us to bypass much of the complexity of the EVM. For example, in account-based systems, someone can edit your account without your consent (by sending tokens to you, thereby increasing its balance), but this does not matter because the Plasma construction is not on the EVM state itself, but on a UTXO state parallel to the EVM, and any tokens you receive will be independent objects.

 

Extending to the EVM: Full State Exits

Simpler schemes have already been proposed to make a “Plasma EVM,” such as Plasma Free, and this article from 2019. In these schemes, anyone can send a message on L1 to force the operator to either include a transaction or make a specific state branch available. If the operator fails to do so, the chain starts reverting blocks. Once someone publishes a full copy of the entire state, or at least all data users have flagged as potentially missing, the chain stops reverting. Making withdrawals may require posting a bounty, which will pay the user’s share of the gas cost for someone to publish such a large amount of data.

 

Such schemes have a weakness in that they do not allow instant withdrawals under normal circumstances, because it is always possible that the latest state needs to be reverted.

 

Limitations of EVM Plasma Schemes

Such schemes are powerful but cannot provide complete security guarantees for all users. Their most obvious failure cases are situations where a specific state object does not have a clear economic “owner.”

 

Let’s consider the case of a CDP (collateralized debt position), a smart contract where users lock tokens that can only be released after the user repays the debt. Suppose a user locks 1 ETH (about $2000 at the time of writing) in a CDP and has a debt of 1000 DAI. Now, the Plasma chain stops publishing blocks, and the user refuses to exit. The user can simply never exit. Now, the user has a free option: if the price of ETH falls below $1000, they abandon the CDP; if the price of ETH stays above $1000, they eventually claim it. On average, such malicious users will profit from this.

 

Another example is privacy systems, such as Tornado Cash or Privacy Pools. Consider a privacy system with five depositors:

 

 

ZK-SNARKs in privacy systems keep the link between the owner of tokens entering the system and the owner of tokens leaving the system hidden.

 

Suppose only orange has withdrawn, and at this point the Plasma chain operator stops publishing data. Suppose we use a UTXO graph method with a FIFO rule, so each token matches the token below it. Then, orange can withdraw their pre-mix and post-mix tokens, and the system will treat them as two separate tokens. If blue tries to withdraw their pre-mix token, orange’s updated state will replace it; meanwhile, blue will have no information to withdraw their post-mix token.

 

If you allow the other four depositors to withdraw the privacy contract itself (which will replace the deposit), and then withdraw tokens on L1, this problem can be solved. However, actually implementing such a mechanism requires extra effort from the developers of the privacy system.

 

There are other ways to address privacy issues, such as the Intmax approach, which involves putting a few bytes on-chain in rollup style, and a Plasma-like operator passing information between users.

 

Uniswap LP positions have similar problems: if you traded ETH for USDC in a Uniswap position, you could try to withdraw your pre-trade USDC and post-trade ETH. If you collude with the Plasma chain operator, liquidity providers and other users will not have access to the post-trade state, so they will not be able to withdraw their post-trade USDC. Special logic is needed to prevent this from happening.

 

Conclusion

Even in 2023, Plasma remains an underrated design. Rollups are still the gold standard and have unmatched security properties. This is especially true from a developer experience perspective: nothing beats the simplicity of application developers not even needing to consider the ownership graph and incentive flows in their applications.

 

However, Plasma allows us to completely bypass the data availability problem, greatly reducing transaction fees. For chains that would otherwise be validiums, Plasma can be a significant security upgrade. ZK-EVMs have finally been realized this year, providing us with an excellent opportunity to re-explore this design space and propose more efficient constructions to simplify the developer experience and protect users’ funds.

Special thanks to Karl Floersch, Georgios Konstantopoulos, and Martin Koppelmann for their contributions in feedback, review, and discussion.