Plasma isn’t Dead.
An Implementer’s Rebuttal to CoinDesk’s Claims
By: Hamdi Allam and Wesley Graham
Background: Four days ago Coindesk published an article speaking to the “stalling” of the Plasma scaling solution. This article, written by plasma implementation team, FourthState Labs, reflects upon Coindesk’s claims from an implementors perspective.
What is Plasma?
With confusion arising over the multitude of plasma implementations present in the Ethereum ecosystem today, we believe it is first important to step back and redefine Plasma for the uninformed reader.
Plasma is a scalability solution that allows decentralized applications to move transactions off of a root blockchain. These transactions are migrated onto other blockchains, called “sidechains” or “plasma chains”, that are operated by individuals or small validator sets (rather than the entire underlying network).
What is unique about Plasma’s construction is that it allows for secure operation of sidechains, even in the presence of malicious activity. This is done through the use of unique exit mechanisms and crypto-economic protocols, which allow users to move their money even in the face of operator censorship or tampering.
As a simple example of Plasma’s application, imagine a scenario where decentralized exchanges provide their order matching on their own sidechains. These chains can possess 100x scalability over the Ethereum network.
Plasma’s Misconceptions
1. Plasma Chains are Centralized (and subject to regulation)
The first misconception that most have regarding Plasma is the association of independently managed sidechains as “centralized entities”.
As Gnosis CTO Stefan George states in the above Coindesk article:
“You have this operator, it is trustless not decentralized. It’s pretty centralized, it is prone to regulation and so on.”
It is true that most Plasma implementations only provide single operators, however, we have shown that there are ways to bring multiple validators to a single Plasma chain.
By using the Cosmos SDK, we are able to decentralize the validation process on Plasma chains, instead creating Proof-of-Stake based sidechains operated by a network of validators. These validators can use any stake-based consensus mechanism and reward validators according to pre-defined criteria.
2) Nobody is Building this Infrastructure
In the above article, CoinDesk states: “within multiple [Plasma] iterations, there’s evidence that work isn’t proceeding as originally hoped, with little actionable code being put together well over a year since its inception”.
This claim represents the view that pushed code and progress are directly correlated with one another. This is a naive thought. Any missed attack vector on a Plasma implementation will lead to catastrophic financial consequences. The correct focus should not be to quickly ship production ready code or be first to market, but to release a well designed and secure solution.
Here are just a few references that illustrate the research and thought that we have put into a secure Plasma implementation:
- Sybil Attack vulnerability that can drain a plasma contract with an incorrect construction of the plasma chain. https://ethresear.ch/t/plasma-vulnerabiltity-sybil-txs-drained-contract/1654
- Aligning economic incentives and protection agaisnt DDoS attacks through “watch tower” services and exit bonds https://ethresear.ch/t/how-to-protect-plasma-against-dos-attacks/1967/13
- Safe deposits into the plasma contracts avoiding race conditions with the operator
https://github.com/FourthState/plasma-research/blob/master/PlasmaMVP/safeDeposit.md - Preventing a Withdrawal delay attack with old utxo’s on the plasma chain. https://github.com/FourthState/plasma-research/blob/master/PlasmaMVP/exitOrdering.md
- Dealing with Ethereum blockchain finality with a decentralized plasma chain
https://github.com/FourthState/plasma-research/blob/master/PlasmaAnchor/anchor.md
FourthState Labs and Kyokan (Plasma implementers) have also partnered to standardize the Plasma smart contract interface that can be used by different Plasma sidechain implementations. This contract is looking to be audited and production ready by Jan 1, 2019.
Remaining Issues
1. Mass exit scenarios
In the presence of malicious activity, the flooding of transactions associated with Plasma Chain exits on the main network at on once is an area of concern. While there have been no fool-proof solutions proposed to date, there are several approaches proposed to mitigate this risk:
- 1) A multi-validator set for a decentralized Plasma chain which reduces the probability of a malicious block from being submitted. At least ⅔ of the validator set would have to sign off on a malicious block for the submission to be approved on the main chain.
- 2) Batched exits triggered by incentivized watchtowers. With the right economic incentives, users can delegate the ability to exit on their behalf to a validator for some reward in the presence of malicious activity. With slight modifications in the smart contract spec, the validator can batch these exits into 1 transaction.
- 3) Addition to the Plasma chain to continually merge UTXOs of the same address. This greatly reduces the number of UTXO’s each user would have to exit in the case of malicious validating.
- 4) Scaling on the layer 1 level. Techniques like sharding and casper are currently being worked on for the Ethereum blockchain. With the Ethereum 2.0 release, the throughput increase at the layer 1 level in combination with the above tactics should be sufficient enough to facilitate a mass exit successfully.
2. “Plasma terminology is confusing”
This is true. The community has not done a good job in this regard. Rather than optimally coordinating research we have instead seen arguments as to which Plasma “flavor” is the best.
That being said, there is no win-all Plasma.
Plasma MVP and Plasma Cash have their own respective use cases, and should be treated as such. The only common thing in these flavors is our core definition of Plasma above.
dApps should spend time understanding both implementations, and how these solutions can plug into problems they are solving.
SNARKs as an Alternative
To be realistic, Plasma is not and should not be the only solution that solves the blockchain scalability problem.
As CoinDesk states in its article, there are merits in exploring the use of tools like SNARKs and STARKs, which can provide scalability benefits associated with verifiable off-chain computation.
In the future SNARKs can be coupled nicely with Plasma MVP to minimize sidechain storage requirements, enable fast syncs, and improve light client infrastructure (providing security benefits to sidechain users).
That being said, it is important to note that both technologies are still in their experimental phase, and should strongly be treated as such. By no means are crypto-economic or cryptographic assumptions encompassing of all real-world attack vectors, meaning that we still need to see demonstration of validity before committing to any solution.
Additionally, with SNARKs, it is unclear whether the cost of generating and verifying proofs on-chain make SNARK-based scaling solutions infeasible.
Do your research. Play with the tech. And work collaboratively rather than dismissing each other’s approaches :)
Conclusion
As we continue to advance the development of plasma sidechains, we believe more applications will begin to leverage this infrastructure on decentralized networks.
This discussion serves as a starting point for a deeper discussion on plasma’s role in this space, and will be amended as better definitions and implementations make their way into the mainstream. We at FourthState have thought deeply about Plasma-enabled business models, and have a number of ideas for decentralized applications looking to create new opportunities.
If you are looking for more outlook from plasma implementers check out Hamdi and Wesley’s medium blogs and the FourthState Twitter Page — and, as always, if you like what you read be sure to clap it below!
Hamdi’s Twitter: @allam_hamdi
Wesley’s Twitter: @wesatbab
