The Plasma white paper written by Joseph Poon and Vitalik Buterin spurred a large wave of innovation, but it equally created confusion on many topics. One year later, Plasma slightly departed from its original vision, having now a rather expansive definition, with several different proposed implementations.
Let's briefly describe the recent history of Plasma, as it rolled out over the last year! Minimum Viable Plasma was introduced as a model adhering to most of the procedures outlined in the white paper, but it turned out that some parts, such as the multi-step process of state transitions, could be dramatically improved. Shortly after, Plasma Cash did just that by the means of non-fungible tokens, enabling simple, reliable and low-cost transactions. It is in particular applicable to high throughput but low or medium-state applications, like micropayments and exchanges. Other notable examples include Plasma Debit, Plasma Xt and More Viable Plasma.
Due to this amalgam of implementations, it might not be crystal clear what Plasma in and of itself represents. That is why we wanted to dedicate an entire page to annotate the confusing parts in the white paper and draw a separation line between what is being built and what not.
Let's firstly review the parts which aren't materialised in any Plasma project, albeit thoroughly discussed or mentioned throughout the draft white paper published on August 11, 2017.
MapReduce is a general-purpose framework for parallelizing computations over a cluster of machines. Within the context of Plasma, it was proposed as the de facto computing paradigm, being mentioned fourteen times in the white paper. Chapter 2.4 opens with the idea that Plasma is to MapReduce what blockchain is to git.
Plasma was initially conceptualised as a design pattern for encompassing complex computations into blockchains. It was aiming to achieve that by spawning a theoretically infinite number of chains under a hierarchical model, where input data is mapped, computed by children chains and then combined and sent to parents. Proper incentives were mandated to ensure correctness. From page 10:
We propose a method whereby the map phase includes commitments on data to computation as input, and in the reduce step includes a merkleized proof of state transition when returning the result. The merkleized state transition is enforced via fraud proofs constructed on the root blockchain.
However, as Plasma is concerned, MapReduce is not a focus of active research or development anymore. The community now considers Plasma a general framework for designing second-level chains which inherit the security of a public, secure root chain.
One doesn't have to specifically use MapReduce to "map" and "reduce" the data inputs and outputs, respectively. Furthermore, one doesn't even have to mind having children chains in the first place, when the second-level chain might be enough for doing the work necessary in that arbitrary context (e.g. a low-volume decentralized exchange).
As pre-empted in the previous section, there hasn't been much effort invested in developing nested chains on Plasma, that is, chains modeled under a hierarchical tree. Chapter 2.2, "Enforcible Blockchains in Blockchains", and chapter 6, "Blockchains in Blockchains", describe a methodology for this:
Instead, we construct a system of higher and lower courts where particular venues can exist to prove state. One can view the root blockchain as the Supreme Court from which the power of all subordinate courts derive their power.
While the philosophy of considering the root chain a supreme court remains, it turns out that merely developing a functional Layer 2 blockchain is a non-trivial task in itself. In particular, it is hard to get exit transactions perfectly entangled, as the incentives to not follow the rules and redeem more funds are exceptionally high. Models for designing nested chains will most likely start popping up in the near future.
Similar to MapReduce, Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge, or just zkSNARKs, are frequently referenced in the white paper. Chapter 4.6 is entirely dedicated to this topic:
Non-interactive proofs of computation allow for one to have significant benefits in scalable computation... There has already been research in SNARKs for MapReduce functionality and we hope this leverages on that research and Plasma extends it by making the proofs orderable and enforcible within a set of blockchains.
zkSNARKs, especially recursive ones, could make state transitions on Plasma (e.g. deposits or withdrawals) significantly more lightweight in time and memory consumption. However, as argued in this thread, the root chain would require knowledge of the trusted zkSNARK setup made by the Plasma chain operator (something not really desirable). Moreover, due to not being lossless, zero knowledge proofs don't even hold enough information to design a secure exit challenge game.
That said, heavy academic research is being conducted on zkSNARKs and zkSTARKs. We may see improvements on the status-quo over the next few years, improvements which may spur novel Plasmatic designs.
The following is a list of other elements and concepts which would benefit from a brief additional clarification.
As Plasma is a design pattern, not a product, the root chain can theoretically be any blockchain which allows the creation of smart contracts. Indeed, most projects working on Plasma chose Ethereum to be their root chain, but that's merely a matter of preference.
Most examples given in the white paper presume a UTXO model, but that's only due to inferred simplicity. Latest thought debates, in particular within Plasma Debit, resulted in heuristics closer to an account-based model than an UTXO-based one.
An abstraction for key-value pairs, where keys map to the balances on the root chain contract and values are binary.
With the advent of Plasma Cash, the latest focus has been on low-to-medium throughput applications, such as micropayments and decentralized exchanges. There has been solid research and thought debate on secure exits, challenge/ response games and fraud proofs. In Chapter 5 of the white paper, "Multiparty Off-Chain State", most if not all ideas are synonymous with the latest specs of Plasma.
The rationale for keeping the focus on the aforementioned parts of Plasma is the following: it is really easy to stuff money under a mattress and write a note of who owns what from there, but what happens when someone wants to take their funds back? We can't rely on trusting them not to take more than they initially had. Solid game theoretical rules need to be mandated.
A great topic to watch is WTF is Plasma?, as it contains an exhaustive list of source code repos of Plasma implementations. Wonderful people are constantly keeping the information up to date and we're grateful for that!