header-langage
简体中文
繁體中文
English
Tiếng Việt
Scan to Download the APP
Partnered With:

Vitalik's new article throws out a new direction of "ZK+Plasma", will the L2 pattern change again?

Read this article in 10 Minutes
Another political flag-waving related to Layer 2
Original author: Haotian (@tmel0211)


(Note: As per the instructions given, I have not translated the content inside the HTML tags and the English characters in the HTML tags have been omitted from translation.)

After reading Vitalik Buterin's new work on Plasma regression, I was deeply attracted by the "exit game" mechanism of Plasma based on the UTXO-like ledger, and Vitalik seems to be intentionally guiding the market towards exploring the ZK+Plasma direction, avoiding the market being stuck in the Rollup stage. Next, I will provide a detailed explanation for everyone.


In my previous interpretation of Vitalik's article, I mentioned that Ethereum's layer 2 scaling solutions originally included various options such as Plasma, Rollup, Validium, Parallel, etc. Vitalik hopes to achieve balanced development in the direction of scaling, adapting to various application scenarios for diversified layer 2 construction. However, in reality, the market is dominated by the Rollup solution, and it is increasingly becoming insular.


However, although Rollup has high security, it is too dependent on Data Availability. Pure Ethereum DA is also limited by performance and cost issues. Therefore, a Solution that relies on third-party DA has emerged in the market, which is a solution that is distorting Rollup and is not the situation that Vitalik wants to see.


Therefore, Vitalik's new article has brought up Plasma again, and has introduced a scaling solution of ZK+Plasma, which is obviously another layer2 political maneuver.


Why is Plasma currently limited to payment scenarios?


Plasma is equivalent to a sidechain solution that periodically synchronizes Merkel state data with the main network. It is a scaling solution that relies on the main network for data and computation. In this way, layer 2 can use a highly centralized and complex ledger model to efficiently expand, while also reusing the system capabilities of the main network validators.


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


1) In payment scenarios, users only need to retain the balance status. If other scenarios require retaining all off-chain state data, it will bring storage space pressure.


2) Plasma security relies on the "exit game" mechanism. If the operator behaves maliciously, users can initiate challenges to assert their assets. If the asset status is complex, it can be very troublesome.


3) Currently, Plasma has difficulty in supporting many unowned states of EVM, making it difficult for users to correspond many non-transactional states such as LP and CDP using Plasma's Merkel state tree ledger.


How does Plasma payment scenario work?


As Vitalik mentioned in the article, in simple terms:


Plasma Cash can treat each Token as an NFT with a unique identifier. When a user initiates a transfer, the operator records an updated state on the Merkle tree leaf. Each user can maintain their own global Merkle tree state, ensuring that the ledger can be traced without errors.


If the tokens are already homogenized, users may split and merge them multiple times during consumption. For example, if Xiao Wang has 1 ETH, he may split it into three parts and then merge two of them. Each part may be irregular, such as 0.001, 0.1, 0.3, etc. If there are a large number of splits, it may cause redundancy in the Merkel data, which may lead to problems when initiating the exit game mechanism (the cost of challenge and verification is high), such as finding discrepancies in the ledger when looking back over the past week. How to solve this problem? You can match a UTXO ID for each asset split or merge state, so that no matter how it is split, you can immediately locate the corresponding transaction tree leaf.


How to ensure secure "exit game" mechanism?


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


But here comes the problem. If the operator publishes an invalid block and falsely records the account, how should users deal with the theft of their assets? Users need to be able to trigger the "exit game" mechanism at any time, withdraw their assets from layer 2 back to layer 1, similar to Rollup's escape pod safety mechanism.


How to do it? Users can show their Merkle tree state proof to prove the asset transfer process and initiate a 7-day challenge period. The main network verification node will check whether the user is the final asset owner and whether there are any asset double-spending issues. (Because the main network node stores more Merkle tree states, it can verify whether the user's proof has the suspicion of malicious exit).


By using the "exit game" mechanism to constrain the misconduct of the two-layer operators, and the existence of the challenge period avoids malicious exits by users, which ensures the normal operation of the Plasma chain.


Compatibility challenge of "ownerless state" for EVM?


As mentioned earlier, Plasma is currently designed more for payment transaction scenarios as a layer 2 solution. It is a form 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 the EVM state machine are difficult to implement with Plasma's solution.


For example, assets such as USDC deposited into the Uniswap pool and assets held in a MakerDAO CDP are difficult for users to prove ownership of. If the operator experiences a shutdown issue and the contract is locked, users will be unable to "exit the game" normally.


Because it is impossible to prove that the user has money in the contract. Due to the characteristics of Plasma data, the main network can only monitor the balance of the contract. If the operator increases the amount of 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 Payment transfer transactions, how to build applications and ecosystems? Obviously, this will greatly limit the usage scenarios of Plasma.


ZK+Plasma unleashes the imagination space


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


If a user deposits an asset into a Plasma contract, they can construct a zkSNARKs proof that can initiate an "exit game" on the mainnet. This allows the user to withdraw their legitimate assets even if the pool is frozen due to security threats.


In trading scenarios involving privacy DEX, users can use zkSNARKs to prove ownership of certain assets without revealing their privacy. Additionally, when upgrading the state of Plasma's smart contracts, zkSNARKs can be used to prove the correctness of the upgrade without revealing details, thereby increasing the difficulty of contract malfeasance.







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

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit