Compile - Odaily
Organize - jk
Special thanks to Karl Floersch, Georgios Konstantopoulos, and Martin Koppelmann for their contributions to feedback, review, and discussion.
Plasma is a class of blockchain scaling solutions that allows all data and computation (except deposits, withdrawals, and Merkle roots) to remain off-chain. This opens the door to massive scalability that is not limited by on-chain data availability. Plasma was first proposed in 2017 and went through several iterations in 2018, notably Minimum Viable Plasma, Plasma Cash, Plasma Cashflow, and Plasma Prime. Unfortunately, Plasma has been largely replaced by rollups due to (i) substantial client-side data storage costs and (ii) fundamental limitations of Plasma that make it difficult to generalize to applications beyond payments.
The emergence of proofs of validity (aka ZK-SNARKs) gives us reason to reconsider this decision. The biggest challenge in making Plasma useful for payments, client-side data storage, can be efficiently addressed through validity proofs. Additionally, the validity proof provides a set of tools that allow us to create Plasma-like chains running EVM. Plasmas security guarantees will not cover all users, as the fundamental reasons for extending Plasma-style exit games to many complex applications remain. However, a very large percentage of assets can actually still be secured.
Below, I will describe in 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 an independent NFT and tracking a separate history for each token. The Plasma chain has an operator who is responsible for producing and publishing blocks regularly. 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 Plasma chain operators create a new block, they publish the root of the Merkle tree to the chain and directly send each user the Merkle branch corresponding to the tokens the user owns.
Assume these are the last three transaction trees in the Plasma Cash chain. So, 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 misconduct. This can happen in two ways:
1. Publish an invalid block (for example, the operator includes a transaction that transfers token 1 from Fred to Hermione, even though Fred does not own the token at that time);
2. Publishing unavailable blocks (e.g. the operator does not send one of his Merkle forks to Bob, preventing him from proving to others that his tokens are still valid and unspent).
If the Operators actions are related to the Users assets, the User is obliged to exit immediately (specifically, within 7 days). When a user (exiter) exits, they provide a Merkle branch proving the inclusion of the transaction that transferred that token to them from the previous owner. This initiates a seven-day challenge period, during whichOthers can challenge the withdrawal by providing one of three Merkel certifications:
1. Non-latest owner: A subsequent transaction signed by the exitor transfers the exitor’s tokens to others;
2. Double spending: a transaction that transfers tokens from a previous owner to someone else is included before a transaction that transfers tokens to the withdrawr;
3. Invalid history: Transactions that transferred tokens within the past 7 days without corresponding costs. Exiters can respond by providing a corresponding spend; if they do not do so, the exit will fail.
According to these rules, anyone who owns token k needs to see all Merkle branches at position k in all history trees over the past week to ensure that they actually own token k and can exit it. They need to store all forks containing asset transfers so that they can handle challenges and safely exit their tokens.
Expansion to fungible tokens
The above design applies to non-fungible tokens (NFTs). However, more common than NFTs are fungible tokens such as ETH and USDC. One way to apply Plasma Cash to fungible tokens is to treat each small denomination token (e.g. 0.01 ETH) as a separate NFT. Unfortunately, if we did this, the gas bill for exit would be too high.
One solution is to optimize by treating many adjacent tokens as a unit that can be transferred or exited at once. There are two ways to do this:
1. Uses Plasma Cash almost as-is, but uses a complex algorithm to very quickly compute a Merkle tree for a large number of objects, if many adjacent objects are identical. This is surprisingly not difficult 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 suffer from the problem of fragmentation: if you receive 0.001 ETH each from hundreds of people buying coffee, you will have 0.001 ETH in many places in the tree, so actually withdrawing those ETH still requires a commit Many separate exits, making gas costs prohibitive. Defragmentation protocols have been developed but are tricky to implement.
Another approach is to redesign the system to consider the more traditional “unspent transaction output” (UTXO) model.When you exit a token, you need to provide the most recent weeks history of those tokens, and anyone can challenge your exit by proving that these historical tokens have exited.
The withdrawal of the 0.2 ETH UTXO in the lower right can be canceled by showing the withdrawal of any UTXO in its history, as shown in green in the figure. Note in particular that the center-left and bottom-left UTXOs are ancestors, but the top-left UTXO is not. This approach is similar to the order-based coloring idea found in colored token protocols around 2013.
There are several techniques for achieving this. In all cases, the goal is to track some notion of the same coin at different points in history to prevent the same coin from being withdrawn twice.
Challenges of generalizing to EVM
Unfortunately, generalizing this to EVM beyond payments is much more difficult.A key challenge is that many state objects in the EVM do not have an explicit owner.The security of Plasma relies on each object having an owner, who is responsible for monitoring and ensuring the availability of data on the chain, and for exiting the object if any issues arise. However, many Ethereum applications do not work this way. For example, the Uniswap liquidity pool does not have a single owner.
Another challenge is that EVM does not try to limit dependencies.In block N, the ETH held in account A could have come from anywhere in block N-1. In order to exit a consistent state, an EVM Plasma chain will need to have an exit game, and in extreme cases, someone wishing to exit using block Ns information may need to pay a fee to publish the entire block N state to the chain: the cost is up to Millions of dollars. The UTXO-based Plasma scheme does not have this problem: every user can withdraw their assets from the latest block for which they have data.
The third challenge is that the infinite dependencies in EVM make it difficult to have consistent incentives to demonstrate effectiveness.The validity of any state depends on everything else, so proving any one thing requires proving everything. In this case, it is often not possible to make resolution failure compatible with incentives due to data availability issues. 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 consent of its owner. This guarantee is extremely useful as 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.
Effectiveness demonstrates how to mitigate these issues
The most basic function of validity proof is to prove the validity of each Plasma block on the chain. This greatly simplifies the design space: it means we only need to worry about unusable block attacks by operators, not invalid blocks. In Plasma Cash, for example, it removes concerns about historical challenges. This reduces the amount of state users need to download, from one fork per block over the past week, to one per asset.
Furthermore, withdrawals from the latest state (in the common case of operator honesty, all withdrawals will be made from the latest state) will not be challenged by non-latest owners, so in a validity-proof Plasma chain, such withdrawals will not be possible at all be challenged by anything. this means,Under normal circumstances, withdrawals can be made immediately.
Extending to EVM: Parallel UTXO Graphs
In the case of the EVM, validity proofs also allow us to do some clever things: they can be used to implement parallel UTXO graphs for ETH and ERC 20 tokens, and prove the equivalence between the UTXO graph and the EVM state with SNARKs. Once you have this, you can implement a regular Plasma system on UTXO graphs.
This allows us to bypass many of the complexities of the EVM. For example, in an account-based system, someone could edit your account without your consent (by sending you tokens, thereby increasing its balance), which doesnt matter because Plasma is not built in the EVM state itself On the UTXO state in parallel with the EVM, any tokens you receive will be independent objects.
Extended to EVM: Exit with full status
There have been simpler solutions proposed to make a Plasma EVM, such as Plasma Free, and before that this 2019 article. In these scenarios, anyone can send a message on L1, forcing the operator to either include a transaction or make a specific branch of state available. If the operator fails to do this, the chain starts reverting blocks. The chain stops rolling back once someone publishes a complete copy of the entire state, or at least all the data that the user flagged as potentially missing. Making a withdrawal may require posting a bounty, which would pay someone a gas fee for a user share of posting such a large amount of data.
One weakness of schemes like this is that they do not allow instant withdrawals under normal circumstances, as there is always the possibility of needing to roll back the latest state.
Limitations of the EVM Plasma solution
Such a solution is powerful, but cannot provide complete security guarantees for all users.Their most obvious failure case is the case 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 in which a user locks tokens that can only be released after the user repays the debt. Let’s say a user has 1 ETH locked in a CDP (about $2,000 at the time of writing) and has a debt of 1,000 DAI. Now, the Plasma chain has stopped publishing blocks and users are refusing to quit. The user can simply never exit. Now, users have a free option: If the price of ETH drops below $1,000, they abandon the CDP, and if the price of ETH stays above $1,000, they eventually claim it. On average, such malicious users make money doing 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 connection between the owners of tokens entering the system and the owners of tokens leaving the system hidden.
Assume that only orange has been extracted, at which point the Plasma chain operator stops publishing data. Suppose we use a UTXO graph approach with a first-in-first-out rule, so each token matches the token below it. Orange can then withdraw their pre-mixed and post-mixed tokens and the system will treat them as two separate tokens. If Blue attempts to withdraw their premixed tokens, Oranges updated status will replace it; at the same time, Blue will have no information to withdraw their postmixed tokens.
This problem can be solved if you allow four other depositors to withdraw the privacy contract itself (which will replace the deposit) and then withdraw the tokens on L1. However, actually implementing such a mechanism requires additional effort on the part of developers of privacy systems.
There are other ways to solve privacy concerns, such as the Intmax method, which involves putting a few bytes on the chain in a rollup style, and a Plasma-like operator passing information between individual users.
Uniswap LP positions have a similar problem: if you traded ETH for USDC in a Uniswap position, you can 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 required to prevent this from happening.
in conclusion
Even in 2023, Plasma is still an underrated design. Rollups remain the gold standard and have unrivaled safety attributes. This is especially true from a developer experience perspective: nothing beats the simplicity of app developers not even having to think about ownership graphs and incentive flows in their apps.
However, Plasma allows us to completely bypass the data availability issue and significantly reduce transaction fees. Plasma can be a major security upgrade for chains that would otherwise be validiums. ZK-EVMs are finally coming to fruition this year, giving us the perfect opportunity to re-explore this design space and come up with more efficient ways to build that simplify the developer experience and protect users’ money.
