Plasma for beginners
Plasma is one of the main frameworks for scaling Ethereum. Here’s an introduction, as gentle as I could make it.
Background
For many use cases Ethereum is too slow and expensive — it takes more than 10 seconds to process a transaction, and it costs more than 0.10$ to do a single transaction.
There's lots of very creative work happening on the frontier-of-maths-and-game-theory-and-cryptography-and-engineering that aims to improve Ethereum in this regard.
Roughly, there are two approaches to make Ethereum faster and cheaper: we can improve the core system itself (code name: "Ethereum 2.0"), or we can graft faster systems on top of an unchanged Ethereum chain (these are called "Level Two solutions", and examples are Polkadot, state/payment channels in many variants , Truebit). Plasma is of the second type.
Kickstarted by an ambitious paper by Vitalik and Joseph Poon from 2017, Plasma is really a family of ideas. The project is has gotten a lot of love in the past year, with contributions from developers and researchers from Consensys, OmiseGo, Protocol Labs, CryptoKitties, the Ethereum Foundation itself, and many others.
So what is the problem exactly?
Nakamoto Consensus, which is used by Bitcoin and Ethereum to decide on the shared state of the block chain, is, of course, brilliant. It is also inherently slow and expensive. There are electricity costs for Proof-of-Work which must be high to secure the network; there is inefficiency as as code must be executed and data must be stored by all full nodes; and we need ~10 seconds between blocks to give all the participants around the globe the time to communicate and reach consensus.
At the same time, we know of consensus mechanims that are much faster and cheaper. "Proof-of-authority", for example: instead of literally giving anyone a chance to produce new blocks, as in Nakamoto consensus, we preselect a number of miners that we trust, and let them decide on the new blocks. This is fast and straightforward, but it goes at the cost of the trustlessness that makes Nakamoto Consensus such a powerful concept.
Plasma aims to have its cake and eat it too, by combining the robustness of the Ethereum parent chain with the speed of a proof-of-authority chain to get something that is both fast and trustless. It does that by defining a set of mechanisms that link a fast "child chain" to the Ethereum "parent chain" by (a) transfering tokens between the two chains and (b) implementing mechanisms on the Ethereum parent chain that make sure that the child chain behaves as it should.
The setup
So here's a recipe for building your own superfast plasma chain that you can trust as much as you trust Ethereum. (I'm following the ideas from the whitepaper of 2017, and sort of ignoring the more recent developments)
- To keep it simple, our new and superfast Plasma chain is managed by a single operator, which adds new blocks of valid transactions to the child chain as quickly and often as she likes and broadcasts those blocks to anyone who's interested.
- To move value to and from the Plasma chain, we'll deploy a smart contract on the Ethereum chain. The Plasma contract functions as a bridge to move tokens from Ethereum to the child chain and back. If you send ETH to this contract, it will be locked up on the Ethereum parent chain, and the operator will create a corresponding amount for you on the Plasma chain to spend as you like.
- To transfer your ETH from the child chain back to the parent chain, you provide a proof to the Plasma contract that the tokens are indeed yours to spend on the Plasma chain— if the proof is valid, the tokens will be destroyed on the child chain and released on the parent chain.
Borrowing trust from the parent chain
So we have now a superfast Plasma chain and a way transfer ETH from the main net to the Plasma chain and back. It all works as long as the chain operator is honest and available — and all users trust her to remain so. But this is the blockchain, and our motto is Trust No-one.
Plasma combines two ways to make sure that the operator stays honest: it uses the Ethereum blockchain (which we trust to behave well) to check the operator's work and garantee the correctness of the Plasma chain, and it allows users to exit by allowing them to move value from the Plasma chain back to the parent chain in case things really go south.
Protecting against the main attacks
In the Double Spending Attack the operator shows a different version of the block chain to different users. (Typically, the operator buys a Lambo from Bob without paying like this: she'll create a new block with payment to Bob, and show the block only to Bob. Bob gives her the car, she'll drive away, and then give everybody else another version of the chain, in which the payment to Bob is nowhere to be found, leaving poor Bob with a useless fork that is ignored by everybody else.) We can avoid this attack in a fairly straightforward way in the Plasma setup. In addition to sending new blocks to users, the operator must make a public (and unchangeable) commitment to the new state by writing a hash (a unique identifier) of the current state to the main Ethereum chain.
In another type of attack the operator tries to include invalid transactions (such as sending some money to herself, for example). The parent chain, Ethereum, is Turing complete, and so can calculate (in principle) anything that is calculable. In particular, our Plasma contract on the Ethereum chain can check if all the transactions in a new block are valid. That means that (again, in principle!) every time the operator commits to a new block on the parent chain, our Plasma contract can reject the block if it contains invalid transactions.
Checking the correctness of the new state on the parent chain by recalculating all transactions of the child chain would basically mean that we run the child blockchain intirely on the parent chain, and thus would completely defeat the purpose of making operation of the child chain less costly. Here's the idea to make checking feasible: if the operator is indeed cheating, then there must be a particular transaction where she cheated. It is certainly feasible for the Plasma contract to check a single transaction for correctness. Any user can submit the suspect transaction to the contract and prove, on-chain, that it is invalid. This is clever, but even more clever is the idea of using the magic of SNARKS to provide a proof that all transactions are correct that can entirely be checked on-chain without the need for further user interaction.
At this point we have a contract on the parent chain that finalizes the blockchain state and garantees that the blocks are correct. If we combine this with the requirement that the operator submits a (large) deposit that she will loose if she cheats, we have a powerful tool to keep the operator honest.
In Plasma, you can always leave
This is pretty cool, but there are other, more subtle ways that the operator can fail or cheat — in particular, the operator may refuse or be unable to include your transaction or stop producing blocks alltogether.
Remember that at any time, users of the child chain can exit, and transfer their assets from the child chain back to the Ethereum chain. This is used as a a generic mechanism of last resort: if the operator goes really bad, you can always get your ETH (or other tokens) out of the failing Plasma chain back to the safety of the Ethereum parent chain.
The exit procedure is designed in such a way that it requires no interaction or cooperation from the chain operator at all. So even if the operator stops producing blocks altogether, users can always get their ETH out.
While the concept of exiting is straightforward, it is surprisingly difficult to get right. In the case of failure, all users — and there could be thousands or millions — will want to exit at the same time. The root chain — Ethereum — has limited capacity, and so may have trouble processing such a large number of transactions in a relatively short time.
What I've left out and where to go from there
The Plasma whitepaper is much more ambitious in scale than what I've described here— I've left out details about how the fraud proofs work, and what the issues with mass exits are. Moreover, the whitepaper proposes a much richer structure: child chains in turn have children, creating a tree structure of Plasma chains that would allow for highly scaleable distributed computation (and data storage).
Most current efforts to implement a Plasma chain are limited in scope and focus on the most essential part of the specification: the exit procedures that ultimately garantee that the Plasma chain inherits the security properties of the parent chain. This requires efficient data structures to represent mass exits and subtle strategies to make sure users can't cheat. You can check out Minimal Viable Plasma, Plasma Cash, More Viable Plasma if you want to learn more.
To learn more about Plasma, head over to the Learn Plasma web site, read the original paper, or visit ethresearch to get up to speed with the latest developments.
