October 6, 2017
Everything Else
It’s only my opinion that the Proof-of-Stake bond(s) mechanism is one of the most exciting subtopics within the Plasma whitepaper — Plasma is filled with so much more. It’d be extremely unfair of me to not shine a light on the rest of innovative core features of Plasma. Let’s start by first visiting the innate structure we find within the Plasma chain.
Plasma’s default infrastructure is to create a tree of child Plasma blockchains that all periodically commit merkelized updates of their recent settlement updates to their respective parent Plasma chain (or root blockchain). Ideally, each child Plasma chain should represent a chain of smart contracts. The more complicated a decentralized app, the more Plasma children chains it’ll likely require. This hierarchical structure directly leads to three distinct advantages in the Plasma proposal:
Revisiting the TicTacToe Plasma chain example from Part II, let’s change the structure by adding two child chains to our single chain.
We’ll now create an extremely simple casino Plasma chain. This casino has only two games: TicTacToe & Rock-Paper-Scissors. Our parent Plasma chain, this time, is not the TicTacToe game but the overall casino ledger instead (let’s name our casino Dasino moving forward). TicTacToe & Rock-Paper-Scissors, the two casino games, are each dropped into their own child Plasma chain. Each child chain, like in our previous example, consists of smart contracts representing a single game. They both share our Dasino chain as their parent. This looks something like below:
The tree structure incentivizes decentralized apps to create increasingly-smaller children chains. In this structure, the security limits revolve around the fact that actors should observe a specific computation because said computation economically affects them directly. I don’t think I can re-iterate the following sentence found in the white paper on page blank enough:
The scaling benefit comes from removing the requirement to watch the chains one is not economically impacted by, one should watch the chains where one wishes to enforce correct behavior.
If an actor within our Dasino chain only plays TicTacToe, why should he/she care about what happens on the sister Rock-Paper-Scissors chain? Even further, why should he/she have to contribute precious computation power to maintaining the integrity of a plasma chain that has zero economic meaning to him/her?
With a tree structure, plasma’s chain of chains create much more compact communities that are theoretically economically motivated to self-govern.
A fraud proof is the mechanism an actor uses within a Plasma chain in order to file a complaint to a parent Plasma chain or root chain. There are infinite mechanisms one can use as a fraud proof. A child Plasma can submit a fraud proof to a parent chain; just like a parent chain can submit a fraud proof to a root chain. In every instance, if the fraud proof is accepted by the higher-order chain, it’ll force a state revert in the corresponding Plasma chain; essentially, rolling back the last(est) fraudulent block(s) committed.
As previously mentioned, Plasma doesn’t come with a standard fraud proof out of the box. Instead, Plasma offers flexibility to the Plasma originator; he/she can choose whichever fraud proofs seem more appropriate given the underlying Plasma structure.
For example, let’s say a tiny Plasma chain chooses Proof-of-Authority as its consensus algorithm. Here, a fraud proof doesn’t have to be any more complex than a simple plaintext note to the chain authority figure that fraud has occurred & he/she should check it out & make a judgement. Computationally extremely cheap, however far from optimally secure.
On the other hand, a POS-based Plasma chain owner can opt for more private & secure fraud proofs. If you’re familiar with Z-cash, then it’s likely that you’ve heard of zk-SNARKs. The Plasma whitepaper briefly mentions zk-SNARKS acting as the fraud proof mechanism:
Additionally, state transitions can also be enforced via zk-SNARKs/STARKs which ensure that improper exits are not possible. A zk-SNARKs constructions may need recursive SNARKs for maximum efficacy, and therefore may require further research on the possibilities. However, the system is designed to work without SNARKs.
Whatever specific fraud proof is chosen, the mechanism remains the same: an actor within a plasma chain spots a fraudulent action, he/she proceeds by submitting the fraud proof to the parent or root chain. If the parent or root chain accept the fraud proof, the corresponding, underlying Plasma chain’s last block(s) are rolled back or entirely exited. These fraud proofs, baked into every Plasma chain in verifying ways, are one of the key features of the proposed Plasma whitepaper.
“Big data,” in its current state, is still very computationally expensive to work with. It was only within the last ~30 years or so that researchers started experimenting with innovative solutions towards analyzing extremely large, centralized datasets. Until the last decade or two, traditional, centralized databases could be best represented by a ginormous row-&-column Excel spreadsheet.
Somewhere down the line, data became so exceedingly large that single apps required multiple databases. Geniuses, further down the line, started experimenting with how best to creatively move data across these clusters of databases. In 2004, Google employees Jeffrey Dean & Sanjay Ghemawat unveiled one of these creative methods of organizing & computing with clusters of databases that came to be known as MapReduce:
MapReduce is a programming model & an associated implementation for processing & generating large data sets. Users specify a map function that processes a key/value pair to generate a set of intermediate key/value pairs, & a reduce function that merges all intermediate values associated with the same intermediate key.
The goal of MapReduce is to effectively work across numerous clusters of databases in parallel with a two step process: Mapping & Reducing.
Opting for a tree structure allows Plasma to run MapReduce computations. This is by far Plasma’s most important scaling solution.
Mapping takes a set of data & converts it into another set of data, where individual elements are simplified into key/value pairs. Reducing takes the output from the mapping step as an input & further combines those data tuples into a smaller set of tuples. The entire MapReduce process looks something like this:
A huge pro here is the fact that MapReduce allows for working with multiple databases, or clusters of databases, without the need to know how that data is specifically stored & organized. The not-so-giant leap here to Plasma world stems from the parallels between a cluster of databases & a decentralized system such as a tree of blockchains.
Plasma explicitly details their implementation of MapReduce:
The Map phase includes commitments on data to computation as input, and the Reduce step includes a merkelized proof of state transition when returning the result.
Leveraging MapReduce simplifies analyzing a tree of blockchains; the addition of submittable fraud proofs ensures that Plasma users won’t forgo security for speed & computation costs.
As previously mentioned, Plasma is far from the optimal version let alone remotely close to a live build. But there’s no denying that Vitalik & Joseph have their finger on the pulse: they know exactly what problems they need to solve & they’re piecing together the very best breakthroughs in recent years to craft together a promising Ethereum environment.
***This article would not have been possible without editing or encouragement from the following: Heiko Hees, Nate Rush, Alan Percal, Jannik Luhn, Jordan Bruner & Balin Sinnott.
Plasma: http://plasma.io/
Advanced Cryptocurrency Topics is a series of in-depth primers simplifying the latest in the blockchain world through high-level discussions & visualizations.
If you’d like to join a Facebook group for all things cryptocurrency, you can find me at -> https://www.facebook.com/groups/182090605649890/
P.S. Social proof is the lifeblood of the modern age. If you enjoyed, please recommend & share :)
