Fun with Plasma: Talking about Plasma Cash

In the previous article, " Playing Plasma (1): Getting Started with Zero ," we talked about (1) the theoretical foundation of Plasma and (2) how the least feasible Plasma (MVP) works. Before entering the topic of this article, we may wish to discuss some of the improvements to MVP.

We return to MVP's mandatory large-scale exit vulnerability: in a sense, the root of the "problem" lies in the substitutability of the assets discussed in the article. Let's say we say that Bob "owes" 5 Ethereum. Since Ethereum is an alternative asset, it doesn't make sense to talk about what kind of specific Ethereum Bob owes. To this end, in our "tragic situation (ie, the case of the operator's evil)", when the operator attempts to take more than his own share to withdraw, we can't clearly determine "who is stealing the etheric coin." The Ethereum is the Ethereum, so the operator steals the money from the collective Plasma Ether Pool. Therefore, in a sense, other users must withdraw funds from the Plasma chain. So, is there a way to specify the owner of a particular "block" specific Ethereum? Compared to the total Ethereum balance in the Plasma contract expressed as a (very large) number, can we think that the balance is a lot of inseparable "Ether coins (yes, it's an independent clinking coin) ") The sum of the denominations?" Can this solve our problem (or maybe introduce a new one)?

Plasma Cash debut!

Plasma Cash is a variant of the Plasma architecture that became the basis for much of the Plasma community's research. It uses a "minimum viable" approach similar to MVP, but adds a new limitation from the start: all assets on the Plasma Cash chain are irreplaceable tokens. An NFT (which we call "coins") can represent anything: a fixed Ethereum denomination, an ERC-20 token, a bundle of ERC-20 tokens, a nest of mystery cats, or become able to be on a Plasma chain. The right to create a 100-segment Plasma operator in a row (disclaimer: I don't know what the consequences of doing this, I don't recommend arbitrarily imitating it). The only requirement is that the above representative can be represented as an ERC-721 asset. In other words, this thing cannot be split or merged, and it is unique.

Plasma Cash abandoned the bitcoin-based UTXO trading model in MVP. For irreplaceable currencies, the concept of creating new transaction outputs no longer applies. Instead, in each Plasma block, each currency needs to be billed: the presence of a currency indicates that the owner of the coin has changed in the Plasma block (ie, Alice sent it to Bob); The absence of the currency (ie, not in the block) means that the owner of the coin is still the same as the owner in the previous block. Therefore, the complete history of a coin can be described by its presence in each Plasma block – we simply traverse the block from the current block for the first time the coin is deposited.

As we are about to show, the complete history of a coin can fully protect the ownership of its holder. And even better, in this model, this history does not need to contain all the data in each Plasma block: if Bob wants to prove that his currency exists in a certain block, then he only needs to provide the transaction. Kerr path. However, to prove that the currency has not been transferred in a certain block, Bob needs to be able to prove the absence of the data. This is a feature that is not supported by the Merkel tree that we know and love.

• The younger brother travels around the world with a bitcoin, and travels to 20 countries in one year.
• The Werewolf Kill in the Currency Circle: Nakamoto's Prophet, is CSW a werewolf?
• April 20th market analysis: BTC shocks, when can we stimulate the market to do more enthusiasm

Therefore, in order to implement this "absence proof" feature, Plasma Cash uses an enhanced Merkel tree structure we call the Sparse Merkel Tree (SMT). SMT is a Merkel tree with additional special features: each leaf of the tree (in this case, the currency) is given a unique identification number to determine the location of the tree in which they are located. Essentially, we sort and sort these leaves, and each coin can only be in the "slot" assigned to itself. This means that if the coin is absent, then we will be able to know where it exists; on the contrary, if the coin appears, then we can prove that "the slot is 'empty' (ie equal to a null value) , such as 0 or "undefined", etc.) "Merkel branch to prove that the coin has changed hands.

So, since we can prove the existence of the currency in each block, we can trace the full history of the coin, which may look like this:

So on and so forth. The key point is that the data needed to prove this history is only the negligible Merkel proof in each block, not the full Plasma block required by MVP. Hey, the Plasma client is down! Now let's revisit the statement that Merkel's proof sequence is sufficient for the current owner of the coin to protect its own funds. In other words, as long as Steve has a complete history of his currency (in the form described above), he is objectively guaranteed:

1) If/when he tries to withdraw, he will be able to respond appropriately to any challenge.

2) If/when other participants try to withdraw his currency, then he will be able to initiate a challenge and successfully overturn the withdrawal request of others.

In the above example, Steve is the proper owner of the currency as of the 505th block. One important point to emphasize here is that if Steve wants to confirm that his collection (in this case, the payment received from Bill at the 504th block) has been finalized, he must first receive and verify. The complete history of this currency (ie verifying the Merkel certificate in each of the previous blocks). Then, and only then, can he really own the ownership of the coin.

Now, let's take a look at all the things that can happen and how Steve should respond (some of them have familiar recipes with MVP):

Since Steve establishes ownership of the coin in the 504th block, the perpetrator has two ways to steal Steve's currency, which is claimed in the previous or subsequent block.

For example, Alice attempts to steal the currency by broadcasting her "provided proof" in the 501st block. At this point, Alice arrogantly stated that the transfer that occurred in the 501st block was the most recent and valid currency transaction. In other words, she never spent the coin again. Steve's response behavior is basically the same as Bob's performance in MVP's "hittering" case. He pointed out that Alice had transferred to Bill in the 502th block (note that Steve could not falsify this evidence because the transaction needs to include Alice's signature). Alice was caught and her withdrawal request was revoked. Once again, because Steve has a complete history of the coin, he knows he can be prepared to deal with any similar fraudulent exit intentions.

Now, suppose Alice tries to withdraw her currency in the 506th block (that is, after Steve establishes ownership of the coin). It should be noted that if Alice's Merkel inclusion certificate can be accepted by the smart contract (ie Alice's hand-eyes), the operator may have to maliciously and fraudulently include the invalid payment in the 506th block. As usual, we assume that any operator may be malicious.

In this case, Steve responds by providing the transaction that occurred in the 504th block. At this time, he indicated that he not only owns the coin in the block, but also can confidently declare that he has not spent the coin since then. Now, Alice is responsible for providing Steve with the money to send the coin to the other party, but Steve knows she can't do it because he knows he doesn't actually spend the coin at all (and he has been using life to protect the valuable private key). ). Once again, Alice's exit request was revoked.

Although the above example hides some of the tricky edge cases (you can think of these edge cases privately as homework), these exit games are enough to summarize the main points of the Plasma Cash execution rules.

Wait a minute, but still missed one thing! Let's recall the MVP tragic case mentioned earlier: the operator stops providing block data and then continues to try invalid cash withdrawals. Then this time, in Plasma Cash, this withdrawal process will only contain one currency. Therefore, in the case of evil, only the actual owner of the controversial currency needs to take action. Due to irreplaceable restrictions, the risk of withdrawing funds "overflow" to other users' chain assets will no longer exist. This will make the risk of forced withdrawal equal to the risk at the channel center. If the Plasma chain is inoperable, the user will eventually (may) quit. But this exit does not bring any panic, time sensitivity, and the result of a forced large-scale exit failure.

Further

Finally, we took a moment to realize what we learned: We have upgraded the MVP Plasma structure, and now users can run the light client and basically eliminate the ugly massive exit vulnerability.

Does this mean that we have found the Plasma silver bullet we are looking for?

not quite. First, although we have minimized the amount of data each user needs to process, in reality, the amount of data is still very large. We can do some quick calculations. When a coin stays in the Plasma chain for a long enough time, the size of a single Merkel certificate for each coin in each Plasma block becomes very large. Also, keep in mind that every payment means that the user needs to transfer the relevant complete history to the payee.

However, we don't forget the initial restrictions we implemented in Plasma Cash: irreplaceability. This may provide enough functionality for some applications—such as the NFT market—but in the end, we want Plasma assets to give users the same feeling and power as real money. It is very important to be able to spend personal money in any denomination. Without this feature, the user experience of the payment network on the Plasma Cash chain might be like in a restaurant that can only pay for cash, you have no change, you can only tear the check apart.

In subsequent articles, we will continue the journey to Plasma and discuss the Plasma Cash-based approach to minimize the expansion of historical data. The most important thing is to save the alternative to payment while still retaining the advantages of Plasma Cash.

stay tuned.

About the author: Daniel Goldman is a software engineer, technical consultant and independent writer. He works mainly in Brooklyn, New York.

Thanks to Georgios Konstantopoulos for your valuable comments.

Reference link: https://www.theblockcrypto.com/2019/02/07/understanding-plasma-part-1-the-basics/

Author | Daniel Goldman Source | Contributor Network

Compile | 喏呗尔

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