Original Title: "Exit games for EVM validiums: the return of Plasma"

Original Author: Vitalik

Translated by: Luccy, BlockBeats

Editor's Note:

In recent times, the topic of the cryptocurrency industry has been heating up, and Vitalik's article on Plasma has become another focus of discussion in the community. In the article, he proposed a "exit game" mechanism based on the UTXO-like ledger and explored the direction of ZK+Plasma.

Plasma was proposed in 2017, but it was gradually replaced by Rollups in the subsequent development process. Vitalik detailed the working principle of Plasma in the article, and how the Plasma Cash version achieved off-chain data and computation by independently placing each token as a non-fungible token. He pointed out that the main risk of Plasma lies in the improper behavior of operators, which may include publishing invalid or unavailable blocks. To address these risks, Plasma introduced an exit mechanism, where the exiter provides Merkle branches to prove ownership of the assets, and other participants can challenge the proof provided by the exiter.

Regarding the applicability of Plasma to interchangeable tokens and NFTs, as well as the problem of fragment consolidation for interchangeable tokens, Vitalik mentioned the possibility of redesigning the system, considering the traditional Unspent Transaction Output (UTXO) model, and introduced two implementation methods. However, both methods face the problem of fragment consolidation and need to be solved. Based on the limitations of Plasma in the EVM, Vitalik intends to introduce effective proofs into Plasma.

Although Rollups are still the gold standard, Vitalik believes that Plasma is an underestimated design field and encourages further exploration of this design field to propose more effective constructions, simplify developer experience, and protect user funds. BlockBeats has translated the original article as follows:

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

Plasma is a type of blockchain scaling solution that allows for all data and computations, except for deposits, withdrawals, and Merkle roots, to be performed off-chain. This provides the possibility for achieving scalability on a massive scale without being limited by on-chain data availability. Plasma was first proposed in 2017 and underwent several iterations in 2018, including the notable small portable Plasma, Plasma Cash, Plasma Cashflow, and Plasma Prime. However, due to the significant cost of storing large client-side data and the fundamental limitations of Plasma, it has been difficult to promote it for complex applications that require additional payments. As a result, Rollups have largely replaced Plasma.

The emergence of valid proofs (ZK-SNARKs) provides us with a reason to reconsider this decision. One of the main challenges for Plasma to play a role in payments, which is client data storage, can be effectively solved through efficiency proofs. In addition, validity proofs provide various tools that allow us to create a Plasma chain to run the Ethereum Virtual Machine (EVM). The security guarantee of Plasma may not cover all users, as the fundamental reason why Plasma-style exit games are difficult to promote for many complex applications still exists. However, in practice, a very large proportion of assets can still be ensured to be safe.

This article describes how to restructure Plasma to achieve this goal.

Overview: Working Principle of Plasma

The most easily understandable version of Plasma is Plasma Cash. The working principle of Plasma Cash is to treat each individual token as an independent NFT and track separate histories for each token. A Plasma chain has an operator who is responsible for generating and regularly publishing blocks. Transactions in each block are stored in a sparse Merkle tree form, and if a transaction transfers ownership of token k, it will appear at position k in the tree. When the Plasma chain operator creates a new block, they publish the root of the Merkle tree to the chain and directly send Merkle branches corresponding to the tokens owned by each user.

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

In any Plasma system, the main risk is improper behavior of the operator, which can occur in two ways:

Publish invalid blocks. For example, if the operator includes a transaction in which Fred sends it to Hermione even if Fred does not own token 1 at that time.

Release unusable blocks. For example, the operator did not send Bob his block's Merkle branches, making it impossible for him to prove to others that his tokens are still valid and unused.

If the operator acts improperly in a way related to user assets, the user is responsible for immediately exiting (specifically, within 7 days). When the user ("exiter") exits, they provide a Merkle branch that proves the token was transferred from the previous owner to them in the transaction. This initiates a 7-day challenge period during which others can challenge the exit using one of the following three Merkle proofs:

Non-latest owner: Subsequent transactions signed by the exiter will transfer the exiter's tokens to others.

Double spending: A transaction that transfers tokens from the previous owner to another person, included in the transaction before the exit transaction.

Invalid history: Transactions that transferred tokens within the past 7 days have no corresponding expenditure. The exiter can respond by providing the corresponding expenditure; if they do not do so, the exit will fail.

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

Generalizing to Interchangeable Tokens

The above design is applicable to non-fungible tokens (NFTs). However, more common than NFTs are interchangeable tokens, such as ETH and USDC. One way to apply Plasma Cash to interchangeable tokens is to simply treat each token's small denomination (e.g. 0.01 ETH) as a separate NFT. However, if this is done, the gas cost for exiting will be too high.

One solution is to optimize by treating many adjacent tokens as a single unit, which can be transferred or withdrawn all at once. There are two methods to achieve this:

Using almost unchanged Plasma Cash, but using advanced algorithms to quickly calculate the Merkle tree of a very large number of objects, it is not difficult to achieve if many adjacent objects are the same; you can see a Python implementation here.

Using Plasma Cashflow, it simply represents many adjacent tokens as a single object.

However, both of these methods have encountered fragmentation issues: if you receive 0.001 ETH from hundreds of people to buy coffee, your 0.001 ETH will appear in many positions of the tree, so actually withdrawing these ETH still requires submitting many separate exits, making gas fees expensive. Although fragmentation protocols have been developed, implementation is quite tricky.

As an alternative solution, we can redesign the system and consider a more traditional "Unspent Transaction Output" (UTXO) model. When you exit a token, you need to provide the recent week's history of these tokens, and anyone can challenge your exit by proving that those historical tokens have already been exited.

The extraction of the 0.2 ETH UTXO in the lower right corner can be cancelled by displaying the extraction of any UTXO in its history (displayed in green). It is important to note that the UTXOs in the middle left and bottom left are ancestors, but the UTXO in the top left is not. This method is similar to the order-based coloring idea in the colored token protocol around 2013.

There are multiple technologies that can be used to achieve this goal. In all cases, the goal is to track the concept of "same token" across different historical periods to prevent the "same token" from being extracted repeatedly.

Challenges of Generalizing to EVM

Unfortunately, it is much more difficult to extend this concept beyond the EVM. One key challenge is that many state objects in the EVM do not have a clear "owner". The security of Plasma relies on each object having an owner who is responsible for monitoring and ensuring the availability of the chain's data, and exiting the object in case of any issues. However, many Ethereum applications do not work in this way. For example, the Uniswap liquidity pool does not have a single owner.

Another challenge is that EVM does not attempt to limit dependencies. The ETH held in account A in block N-1 may come from anywhere in N. To exit a consistent state, the EVM Plasma chain needs an exit game, and in extreme cases, someone hoping to exit using information from block N may need to pay a fee to publish the entire state of block N on the chain: this will result in millions of dollars in gas costs. UTXO-based Plasma schemes do not have this problem: each user can exit their assets from the latest block they own data for.

The third challenge is that the unlimited dependency relationship in EVM makes it harder to obtain consistent incentives for proof validity. The validity of any state depends on everything else, so proving anything requires proving everything. In this case, fixing faults often cannot maintain incentive compatibility due to data availability issues. A particularly annoying problem is that we lose the guarantee that exists in UTXO-based systems that the state of an object will not change without the consent of the owner. This guarantee is very useful because it means that the owner always knows the latest provable state of their assets and simplifies exiting the game. Without this guarantee, creating an exit game becomes more difficult.

Effective Proofs and How They Solve These Problems

The most basic thing for improving the design of Plasma chains is to prove the validity of each Plasma block on the chain. This greatly simplifies the design space: it means that the only thing we need to worry about is the operator's unavailable block attack, not invalid blocks. Taking Plasma Cash as an example, it eliminates concerns about historical challenges. This reduces the amount of state that users need to download from one branch of each block in the past week to one branch of each asset.

In addition, extracting funds from the latest state (in most cases, all withdrawals will come from the latest state) is not affected by challenges from non-latest owners. Therefore, in a validated Plasma chain, such withdrawals will not be affected by any challenges. This means that under normal circumstances, withdrawals can be instant!

Expanding to EVM: Parallel UTXO Graph

Under the EVM scenario, validity proofs also allow us to do some clever things: they can be used to implement parallel UTXO graphs for ETH and ERC20 tokens, and to prove equivalence between UTXO graphs and EVM states using SNARKs. Once this is achieved, you can implement a "regular" Plasma system on the UTXO graph.

This allows us to avoid many of the complexities of the EVM. For example, in an account-based system, someone could edit your account without your consent (by sending tokens and increasing their balance). This fact is not important in the Plasma construction because it is not built on the EVM state itself, but on a UTXO state parallel to the EVM. Any tokens you receive will be separate objects.

Expand to EVM: Total State Exit

Some simpler solutions have been proposed for creating "Plasma EVM", such as Plasma Free and this article from before 2019. In these solutions, anyone can send messages on L1, forcing the operator to either include a transaction or make a specific branch of the state available. If the operator fails to do so, the chain will begin rolling back blocks. As long as someone publishes a complete replica, i.e. the entire state, or at least all the data that users have marked as potentially lost, the chain will stop rolling back. Extracting may require a bounty to be posted, which will pay the user a share of the fuel cost of the person who publishes such a large amount of data.

The drawback of such schemes is that they do not allow for immediate extraction under normal circumstances, as the chain may always need to roll back to the latest state.

The Limitations of EVM Plasma Solution

This type of solution is very powerful, but cannot provide complete security guarantees for all users. The most obvious problem occurs when specific state objects do not have a clear economic "owner".

Let's consider the case of a Collateralized Debt Position (CDP), which is a smart contract where a user's tokens are locked and can only be released once the user repays their debt. Suppose a user has locked 1 ETH (worth approximately $2000 at the time of writing) in a CDP and has a debt of 1000 DAI. Now, if the Plasma chain stops producing blocks and the user refuses to exit, they have a free choice: they can leave and forget about the CDP if the price of ETH drops below $1000, or they can eventually withdraw if the price of ETH stays above that level. Overall, such malicious users can profit from this situation.

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

The zero-knowledge proof system (ZK-SNARKs) in privacy systems keeps the association between the owner of the tokens entering the system and the owner of the tokens leaving the system hidden.

Assuming only the orange users have withdrawn, the Plasma chain operator stops publishing data. Also assuming we use the UTXO graph method with a first-in, first-out rule, so each token matches with the token below it. Then, the orange users can withdraw their pre-mixed and post-mixed tokens, which the system treats as two separate tokens. If the blue users try to withdraw their pre-mixed tokens, the latest state of the orange users will overwrite it; at the same time, the blue users will be unable to withdraw their post-mixed tokens.

If other four depositors are allowed to withdraw the privacy contract itself (which will override the deposit) and then withdraw the tokens on L1, this problem can be solved. However, implementing such a mechanism in practice requires additional efforts from privacy system developers.

There are other methods to solve privacy issues, such as the Intmax method, which involves using an operator similar to Plasma on the chain to carry some bytes when passing information between individual users.

Uniswap LP positions face a similar issue: if you swap USDC for ETH in a Uniswap position, you can attempt to withdraw the pre-swap USDC and post-swap ETH. If colluding with a Plasma chain operator, liquidity providers and other users would be unable to access the post-swap state and therefore unable to withdraw the post-swap USDC. Special logic is needed to prevent this from happening.

Conclusion

By 2023, Plasma remains an underestimated design field. Rollups continue to be the gold standard and have unparalleled security performance. From a developer's perspective, especially in terms of simplifying application development without having to consider ownership graphs and incentive flows in their applications, nothing can match its simplicity.

However, Plasma allows us to completely bypass the issue of data availability and greatly reduce transaction fees. For chains that could have been validium, Plasma can be an important security upgrade. This year, ZK-EVM finally began implementation, which provides an excellent opportunity to explore this design space again and propose more effective ideas to simplify the developer experience and protect user funds.

「Original Link」

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia