Interpreting Vitalik’s new work ZK+Plasma Changing the Layer 2 Landscape?

Exploring Vitalik's New Project ZK+Plasma A Revolutionary Shift in the Layer 2 Landscape?

Author: Haotian, Source: author’s Twitter @tmel0211

Recently read @VitalikButerin’s new work on Plasma regression, I am deeply fascinated by the “exit game” mechanism of Plasma based on a UTXO-like ledger, and it seems that Vitalik is intentionally guiding the market towards exploring the ZK+Plasma direction, avoiding the market staying in the Rollup stage. Next, let me explain it in detail:

Key points: 1) Why is Plasma Chain suitable for payment scenarios? 2) How does Plasma payment scenario work? 3) Why is the exit game mechanism important for Plasma? 4) Why is it difficult for Plasma Chain to integrate EVM’s ownerless state? 5) What kind of imagination space can be released by ZK+Plasma?

In my previous interpretation of Vitalik’s article, I mentioned that Ethereum’s Layer 2 scaling solutions originally included: Plasma, Rollup, Validium, LianGuairallel, and other solutions. Vitalik expects the scaling direction to be balanced development, adapting to various application scenarios for diversified Layer 2 construction. But the reality of the market is that the Rollup solution dominates and is becoming more and more inward.

However, although Rollup has high security, it relies too much on Data Availability, and pure Ethereum DA is limited by performance and cost issues. Therefore, a solution that is currently rolling out a Rollup camp but relies on third-party DA is emerging. This is a solution that is distorting Rollup and is definitely not the situation Vitalik wants to see.

Therefore, Vitalik’s new article reintroduces Plasma and guides a ZK+Plasma scaling solution, which is obviously once again a political rallying cry for Layer 2.

Why is Plasma currently limited to payment scenarios?

Plasma is equivalent to a sidechain solution that periodically synchronizes Merkle state data with the main network. It is a scaling solution that relies on data and computation from the main network. In this way, the Layer 2 can be efficiently scaled using a very centralized and complex ledger model, and can also reuse the system capabilities of the main network’s validators.

In general, using Plasma in payment scenarios can ensure that ledger state is effectively tracked and recorded. Why is that?

1) In payment scenarios, users only need to retain balance states. If all off-chain state data needs to be retained in other scenarios, it will bring storage space pressure;

2) Plasma security relies on the “exit game” mechanism. If the operator behaves maliciously, users can initiate challenges and present their own assets. If the asset state is complex, it will be troublesome;

3) Currently, Plasma is difficult to be compatible with many ownerless states in EVM, making it difficult for users to use Plasma’s Merkle state tree ledger to correspond to many non-transactional states, such as LP (Liquidity Provider) and CDP (Collateralized Debt Position);

How does Plasma payment scenario work?

As mentioned in Vitalik’s article, simply put:

Plasma Cash can treat each token as an NFT, with a unique number. When a user initiates a transfer, the operator will record an updated state on the Merkle tree leaf, and each user can save their own global Merkle tree state. This way, the ledger can be traced without confusion.

If the Token is already homogeneous, users may have multiple splits and merges when consuming, such as Xiao Wang having 1 ETH, which is split into three parts and then two parts are merged. Each part is irregular, such as 0.001, 0.1, 0.3, etc. If there is a large-scale split, it may lead to redundant Merkel data, which may cause problems when initiating the game exit mechanism (high challenge and verification costs), such as finding discrepancies in the account book traced back to the past week. How to solve it? We can match a UTXO ID for each asset split or merge status, so that no matter how it is split, it can be instantly located to the corresponding transaction leaf.

How to ensure the security of the “game exit” mechanism?

Because Plasma does not have its own independent chain system like Rollups, it must ensure that its sidechain accounting is synchronized with the mainnet, which allows it to not deliberately pursue decentralization, as long as there is an efficient accounting operator.

But here comes the problem, if the operator publishes invalid blocks and falsifies accounts to steal user assets, what should be done? Users need to send out the “game exit” mechanism at any time, withdraw the 2-layer assets back to the 1-layer, similar to Rollup’s escape pod safety mechanism.

How to do it? Users can reveal their own Merkel tree state proof to prove the asset transfer process and initiate a 7-day challenge period. The mainnet verification node will check whether the user is the final asset owner and whether the user has double-spending issues. (Because the mainnet node stores more Merkel tree states, it can verify whether the user’s proof has malicious exit suspicions).

By using the “game exit” mechanism to constrain the misconduct of the 2-layer operator, and the existence of the challenge period avoids user malicious exits, this ensures the normal operation of the Plasma chain.

The challenge of compatibility with the EVM’s “no-owner state”?

As mentioned earlier, Plasma is currently more designed for 2-layer solutions in payment transaction scenarios, which is a kind of accounting that can be compared to the UTXO model, while the EVM itself is an account model. UTXO can record every balance state refresh, but many “no-owner” scenarios in EVM state machines are difficult to implement using the Plasma solution.

For example, the assets deposited in the Uniswap pool and the assets in the MakerDAO CDP are the same. It is difficult for users to prove which assets belong to themselves, so once there is a problem with the operator’s shutdown and the contract is locked, users cannot “exit the game” normally.

Because they cannot prove that they have money in the contract. Due to the characteristics of Plasma data, the mainnet can only monitor the balance of the contract. If the operator increases the money in the contract, how can the user prove which money is theirs and which money is maliciously increased?

Moreover, if a layer2 sidechain can only achieve LianGuaiyment transfer transactions, how to build applications and ecosystems, clearly, this will greatly limit the usage scenarios of Plasma.

The Imaginative Space Unleashed by ZK+Plasma

If the underlying layer of Plasma is completely transformed into ZK, user actions will exist in the form of zk-SNARK proofs, which can unlock many scenarios of the EVM state machine:

For example, if a user deposits an asset into a Plasma contract, they can construct a zkSNARKs proof that can initiate an “exit game” on the main network. This way, even if the pool is frozen due to security threats, the user can still withdraw their legitimate assets;

In the case of transactions involving privacy DEX, users can use zkSNARKs to prove ownership of a certain asset without exposing their privacy. Additionally, when upgrading Plasma’s smart contracts in complex scenarios, zkSNARKs can be used to prove the correctness of the state upgrade without revealing details, thus increasing the difficulty of contract manipulation;

That’s it.

In general, Vitalik clearly describes the current state of Plasma and the problems it faces, including the possibility of future ZK integration. In my opinion, Plasma is not innovative, and it has already found its place in the payment scene over the past few years. At this moment, Vitalik’s introduction of ZK+Plasma as a new direction is a form of guidance and political signaling. Whether the market will follow Vitalik’s lead, I personally am not very optimistic:

1) Rollup is the optimal solution in terms of market input costs, development difficulty, and ecological compatibility. ZK+Plasma is certainly a more advanced form of ZK-Rollup, but the current development of ZK-Rollup is not promising. Jumping directly to Plasma seems too hasty;

2) Validium, as an independent scaling solution, is relatively more advanced in terms of ZK application. However, it relies entirely on off-chain data availability. In comparison, ZK+Plasma seems to have a higher stickiness to the Ethereum mainnet. However, it is understandable for Vitalik to make this call. The motivation of mature ZK developers to give up Validium and pursue ZK+Plasma may be insufficient.

Note: Please be sure to read Vitalik’s article carefully before understanding this one.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Market

Decoding Ethena Arthur Hayes' Views on USDe Opportunities and Risks

Arthur Hayes is confident in the exceptional approach and high yield of Ethena's (USDe) stablecoin, which could poten...

Bitcoin

Bitcoin Soars to new heights as Kiyosaki Praises its Performance and Slams the Dollar

Kiyosaki commended Bitcoin for its impressive performance and raised valid concerns regarding the reliability of the ...

Blockchain

South Korea Considers Postponing Crypto Taxes: A Deeper Look into the Regulatory Framework

The ruling party in Korea prioritizes the establishment of regulations for cryptocurrencies over implementing immedia...

Web3

Bybit’s Crypto Ark: A Journey to Reshape the Future of Crypto Collaboration

Fashionista, get ready for seamless web3 adoption with Bybit's new Crypto Ark Trading program!

Market

Injective and Google Cloud: A Dynamic Blockchain Duo

INJ Integrates Google Cloud's BigQuery to Enhance Web3 Finance on Layer-1 Blockchain

Bitcoin

Get Ready for the Bitcoin Rollercoaster CPI Report Expected to Give Insights on Potential Rally

Fashionista readers are eagerly anticipating the upcoming CPI report, hoping it will provide some relief for BTC, whi...