What is Plasma? Plasma Cash?
Plasma is a design pattern that allows for off-chain messages to dictate the transfer of on-chain assets. It scales the root chain by offloading transaction throughput to Plasma chains. You can think of it as a professor who needs to grade many exams in a short period of time. The professor can delegate this work to the teaching assistants, who look through every question on the exam and tally up points, but report only a grade back to the professor.
Each Plasma chain condenses messages about transaction ordering into a single hash stored on the root chain. Bitcoin and Ethereum are examples of root chains — blockchains that have stronger security and decentralization guarantees (safety and liveness). In this post, we will use Ethereum as the root chain throughout all of our examples.
“Plasma is NOT taking your centralized server and sticking a Merkle tree on it.” — Vitalik Buterin at TechCrunch in Zug, Switzerland 2018
The two main branches of Plasma design are called Plasma MVP and Plasma Cash. You can read more about the Plasma family tree of research in the links at the bottom of this post. First let’s get some context and go over a simple high-level user flow first, then delve into each component in more depth.
Let’s do a quick vocab refresh before moving on:
Sparse Merkle tree: a perfect Merkle tree of unchanging size, called ‘sparse’ because most of the leaves are empty.
Economic finality: a guarantee that an operation will never be reverted, unless the party providing the finality sets a pile of money on fire.
UTXO: stands for unspent transaction output. Each transaction must have inputs from a valid UTXO set. The outputs of each transaction become part of the new UTXO set. Bitcoin uses the UTXO model.
Aiiight let’s get started.
1: Wannabe operator deploys Plasma contract to the mainnet
Entities like exchanges that want to have high transaction throughput and low latency (even instant economic finality) would benefit from running a plasma chain and being an operator. A contract owner is included in the initialization of the contract.
2: Plasma operator creates a block
One of the operator’s many roles is to aggregate and order transactions into blocks, then to commit a 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, methods of storing state, etc. but all Plasma chains commit a hash periodically on to the root chain in order to inherit the security guarantees of the root chain.
3: Kanye, who is a new user, deposits ETH into the Plasma contract and is assigned PETH in return
In both of the main Plasma designs you can deposit any token and receive that token on the plasma chain. So if Kanye deposits ETH, he’ll get PETH! If he deposits BTC he gets PBTC! (The Plasma Cash spec better supports ERC721 assets like CryptoKitties, but not all Plasma specs will support depositing any token).
4: Kanye sends money to Donald, who is not part of the Plasma smart contract already
Kanye isn’t limited to sending money only to those who are already members of the Plasma contract! He can also send money to Donald, who is an Ethereum whale.
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 index of the leaf that the coin is assigned to is the only place the coin can be transacted. Think of buying or selling a house — the house doesn’t move when you transact it, but the person who owns the keys to the house will change, and the house’s deed is a record of the parties involved and the frequency of the ownership changing hands. This makes it extremely easy to check the history of the token because you know where in the tree to look!
Here we zoom in on the index of the token that Kanye sent Donald. Kanye must include the history of the token when he sends a token. If a token gets transacted many times, this history can get really large! We’ll go over ways to ameliorate this later. But for now, this is great for Donald who only has to download the histories of the tokens he cares about.
5: Donald has two choices: continue spending PETH or create an exit transaction to redeem for ETH on the root chain.
Donald doesn’t need to submit a message to the operator for membership in the Plasma contract in order to exit his PETH into ETH. Donald wants to immediately tumble his tokens for anonymity, so he doesn’t want to continue transacting his PETH. He gets a history of the token to prove ownership and includes it in an exit request to the Plasma contract. His exit transaction also includes gas fees and a bond as a security deposit against lying. Everything checks out, nobody challenges Donald, and he redeems his PETH for ETH on the root chain.
Great! We’ve run through a best case honest scenario at a high level, so let’s go into each of these components in depth: transactions, exits and the role of the Plasma operator. It is important to note that there are multiple specs and many differences between various implementations, but the following will familiarize you with some core Plasma concepts and vocabulary.
Transactions
Whenever Kanye sends a token, he must also send the history of that token. In Plasma Cash, users only need to download the histories of and watch the tokens they care about. Sharded client side validation allows for a lighter data load for each user.
However, if a coin is spent many many times then the history of the coin becomes infeasibly large to transact. One proposal to remedy this is to introduce checkpoints. Once a checkpoint has been finalized, clients can instead provide proofs from the finalized checkpoint onwards which would reduce the proofs to constant, rather than linear size. Plasma Cash Checkpoints are based on cryptoeconomic aggregate signatures which provide an economic guarantee that a coin is owned by person X at height Y.
Unfortunately, it is more difficult for arbitrarily small denominations of tokens to be sent in Plasma Cash (Plasma Debit or state channels are fixes for this, linked in Further Reading). When the deposit function is called, the user specifies a denomination for what they deposit. While this makes Plasma Cash good for sending ERC721 type non-fungibles, the Plasma MVP UTXO model is better equipped to handle arbitrary denominations.
Exits
An exit challenge is issued when a withdrawal is believed to be:
- Exiting an already-spent coin
- Double-exiting a coin
- Exiting a coin with an invalid history
Anybody can submit a fraud proof to challenge the exiter, who will lose their bond if they are lying.
What about hacks?
If the Plasma chain is hacked, the hacker has to submit an exit transaction for all the funds he wants to steal! In Plasma Cash, the hacker has to include a bond in his exit transaction, he can’t just abscond with all the money.
Plasma operators
The main role of the Plasma operator is to aggregate transactions into blocks and publish a Merkle root of each plasma block to the root chain.
In more complex designs, the central operator can be replaced by PoS validators which would mitigate concerns surrounding transaction censorship. However, there are a myriad of benefits to having a central operator, and lots of fun things we can do with the Plasma operator’s bond:
- Instant economic finality! Because the operator is the one creating blocks, they can provide guarantees regarding transaction inclusion and ordering. The operator puts up a bond against lying, so users know immediately if their transactions were included.
- Invalid exit penalty: We can punish the operator for allowing invalid exits to go through, and slash funds in the bond.
- Casper validation: The operator can be a Casper PoS validator with the funds in the bond!
- Can you think of any more?
The Plasmas
Just to lay it out a bit more clearly:
Further Reading
Minimum Viable Plasma
Plasma Cash
Plasma Cash Simple Spec
Plasma Debit: Arbitrary-denomination payments in Plasma Cash
Plasma XT: Plasma Cash with much less per-user data checking
Cryptoeconomic Signature Aggregation
