Plasma is a design pattern that allows the transfer of assets on the chain-driven message chain. It extends the root chain by shifting transaction throughput to the Plasma chain. You can think of it as a professor who needs to correct many exam papers in a short time. The professor can delegate this work to the TA. They look at each question on the exam and calculate the corresponding score, but only report the total score to the professor.
Each Plasma chain compresses the information sorted by the transaction into a single hash and is stored on the root chain. Root chains like Bitcoin and Ethereum – these blockchains are more secure and de-neutralized (safety and activity). This article will use Ethereum as an example of the root chain throughout the text.
- Viewpoint | Ethereum plunged, it is time to throw away the illusion that Ethereum has skyrocketed again
- Bitcoin fluctuates within a narrow range, waiting patiently for the market to restart
- Ethereum entered the outbreak! Ethereum Foundation allocates 30 million US dollars to escort Ethereum 1.0, 1x, 2.0, etc.
- Analysis: A Brief Discussion on the Loss of Developers in Ethereum
- Is the Ethereum futures contract really coming?
- Market Analysis: Can the bulls withstand the impact of the turmoil in the capital market?
"Plasma is not attaching a Merkle tree to a centralized server."
– Vitalik Buterin, TechCrunch, 2018, Zug, Switzerland The two main branches of Plasma design are called Plasma MVP and Plasma Cash. First, let's take a look at the background information, understand the simple user flow from a macro perspective, and then explore each part in more depth.
Before we get started, let's take a quick look at the basic concepts:
Sparse Merkle tree from: https://doi.org/10.1007/978-3-319-47560-8_13
Sparse Merkle Tree: A perfect Merkle tree of constant size, called "sparse" because most leaves are empty.
The ultimateity of the economy: guarantee that the operation will never be reversed, unless the party providing the final result burns a large sum of money.
UTXO: Unspent transaction output. Each transaction must have input from a valid UTXO set. The output of each transaction will be part of the new UTXO collection. Bitcoin uses the UTXO model.
Now let's talk about Plasma.
1: The operator deploys the Plasma contract to the main network
Entities such as exchanges, such as entities that want to have high transaction throughput and low latency (even real-time economic endurance) will benefit from running the Plasma chain and becoming an operator. The contract owner is included in the initialization of the contract.
2: Plasma operator creates block
One of the many roles of the operator is to aggregate and sort transactions, package them into blocks, and then submit the hash of the Plasma block to the root chain.
There are many ways to implement Plasma. Different Plasma chains can have different governance rules, different tokens, storage state methods, etc., but all Plasma chains periodically submit hashes to the root chain to inherit the security of the root chain.
3: Kanye is a new user, depositing ETH in a Plasma contract and assigning it back to PETH
Image courtesy of Ali Graham
In the two main Plasma designs, you can deposit any token into the Plasma chain and receive the corresponding token. So if Kanye deposits ETH, he will get PETH! If he deposits in BTC, he will get PBTC! (Plasma Cash's specification better supports ERC721 assets, such as crypto cats, but not all Plasma specifications support the storage of any tokens).
4: Kanye sends money to Donald, but Donald is not in the Plasma Smart Contract.
Kanye is not limited to remittances to those who are already members of the Plasma contract! He can also send money to the Ethereum whales like Donald.
In the "Plasma Cash" specification, each token you deposit is assigned a unique ID. These unique IDs are stored in a sparse Merkle tree. The token has an index of the leaves (Merkle tree) that are allocated, and these indexes are the only places where these tokens can be used for trading.
Think about buying and selling real estate – when you trade a house, the house won't move, but the person who owns the house key will change, and the deed of the house is the party's record and the frequency of ownership changes. This makes it very easy to check the history of tokens because you can easily find them in the Merkle tree!
Image courtesy of Adam Ellis
Here, we look specifically at the index that Kanye sent to Donald's token. Kanye must include the history of the token when sending the token. If the token is traded multiple times, its history may become very lengthy! We will discuss how to improve this situation later. But for now, this is acceptable for Donald, he only needs to download the history of token transactions he cares about.
5: Donald has two options: Continue to spend PETH or create an exit transaction to redeem ETH on the root chain
Donald does not need to submit a message to the operator to become a member of the Plasma contract in order to exit PETH and redeem ETH. Donald wants to change the token immediately to remain anonymous, so he doesn't want to continue using his PETH.
He took the history of the token to prove ownership and placed the record in the exit request submitted to the Plasma contract. His exit transaction also includes the gas fee and the security deposit as a mortgage (to prevent lying). When everything stops, if no one challenges Donald, he can redeem ETH with PETH on the root chain.
Excellent! We have already outlined an ideal scenario at the macro level, so let's delve into each part of this workflow: trading, exiting, and the role of the Plasma operator. It's important to note that there are multiple specifications, and there are differences between the specifications of different implementation scenarios, but the following will familiarize you with some of the core Plasma concepts and vocabulary.
When Kanye sends a token, he must also send the history of the token. In Plasma Cash, users only need to download the transaction history of the tokens they care about. Fragment client authentication allows each user's data load to be lighter.
However, if a token is spent many times, the history of the token will become very long and difficult to transfer in the transaction. One proposal to solve this problem is to introduce checkpoints. Once the checkpoint is finalized, the customer only needs to provide proof from the checkpoint (with finality) so that the size of the proof can be made constant instead of linearly increasing.
The Plasma Cash checkpoint is based on the cryptographic economic aggregate signature, which provides an economic guarantee for the ownership of the tokens by the user X at the height of the Y block.
Unfortunately, it is more difficult to send tokens of any small denomination in Plasma Cash (Plasma debit or status channel is an improvement to this defect). When the deposit function is called, the user specifies the denomination of the deposit. This scheme makes Plasma Cash suitable for sending ERC721 non-homogeneous tokens, while Plasma MVP's UTXO model is more suitable for processing any denomination transactions.
When the withdrawal is considered to be the case, the exit creates a challenge:
1. Exit a token that has already been spent
2. Double exit tokens
3. Exit tokens with invalid history
Anyone can submit a fraud certificate to challenge the exiter, and if they are lying, they will lose their deposit.
What about hacking?
Plasma chain security is as good as the root chain. If the Plasma chain is hacked, the hacker must submit an exit transaction to get all the money he wants to steal! In Plasma Cash, the hacker must include a margin in his exit transaction, and he cannot abscond with all stolen funds.
The primary role of the Plasma operator is to aggregate transactions into blocks and publish the Merkle tree for each Plasma block to the root chain.
In more complex designs, central operators can be replaced by PoS verifiers, alleviating concerns about transaction review. However, having a central operator has many benefits, and we can do a lot of interesting things with the margin of the Plasma operator:
· Instant economic finality! Since operators are responsible for creating blocks, they can provide assurance about the inclusion and ordering of transactions. Operators will pay the price of losing their deposits because of lying, so users will immediately know if their transactions are included.
· Invalid exit penalty: You can punish the operator for allowing the invalid exit to pass and reduce the funds in its margin.
· Casper verification: the operator can be a Casper PoS certifier (the verifier has a margin)
· Can you think of other things?
Image courtesy of Hayden Adams
The author of this article, Jinglan Wang, is translated by the "Cipher" of the Blue Fox Notes community.