Back to Basics on Plasma proposals
What’s the most fundamental philosophy behind all the Plasma research proposals?
Introduction — what to keep in mind on the long journey
If you are following a series of Plasma proposals posted online, there have been so many updates and modifications added on to preceding proposals. Although it is obviously astonishing that so many people around the world have been contributing to the research and joining the intense discussions going on online, for example, at Ethresear.ch (you can follow most of the modifications and updates of Plasma proposals here), some of the newbies might have felt that there are too many versions of proposals and seemed too difficult for the beginners to follow and differentiate them.
So here in this article, I will describe the most important, essential property of Plasma that all the new proposal of modification and security models are trying to stick with. Whenever learning new stuff and attempting to keep yourself updated, it is very crucial to focus on its fundamental first and always remember it when you gain new information. So, let’s review the “must-have” properties of Plasma, otherwise they wouldn’t be even regarded as a Plasma in this article together.
Definition of Plasma
First of all, how would you define Plasma in one simple sentence if you want to explain what it really tries to achieve? Here is my answer;
Plasma is an off-chain protocol that offloads complex transaction processes from the Ethereum chain to side chains in a highly secure way so that each user client application that uses Ethereum blockchain can reduce gas cost per transaction and increase the transaction throughput, while keeping the security of assets on the application, most importantly.
Merkle hash on top of each Merkle tree (hierarchically arranged tree including transaction data), which helps to compress the amount of transaction data, is used to verify that a transaction existed in a certain block. Block height identifies which block a certain transaction has been included in. Block height is significantly important information since it is required in the rootchain contract (exit/challenge) when transactions ‘exit’ as users request to withdraw their funds.
When transactions are exiting from the Plasma chain to the rootchain, the end user has to submit a UTXO’s Merkle proof to the rootchain, in order to prove that the exiting transactions actually existed.
The whole securing processes are structured in this way since they wanted to offload the transaction processes such as basic remittance, swapping, and multi signing as securely as possible by limiting the utilization of the rootchain as little as possible.
Security Model
In order to let this offloading securely processed, however, not only the Block height, but also this certain condition is required for exits;
a condition where NO ONE successfully challenged that the exiting transactions are invalid during a certain period of time
This requirement is really what makes Plasma interesting. Users cannot successfully exit transactions only by proving that the transaction actually existed (by submitting existence proof), but also they have to show that they didn’t get called out by others that the transactions were incorrect.
After you make sure that the transaction actually existed, you also have to ask yourself “With what kind of additional information would it make appropriate for users to claim that their withdrawals are valid?”
Well you can apply reverse thinking here;
“What kind of situation would operators want to avoid in order to claim that the withdraws are valid?”
You need this additional requirement because child chain transactions are managed in a pretty much centralized way where operators are able to act maliciously. More precisely, only operators could maliciously create invalid UTXO output without any input which in the end enables someone to receive money created from nothing.
Only under this condition where no one calls malicious operators out that they were trying to deploy fraudulent transaction history during the challenge period AT ALL, operators are allowed to withdraw their funds.
Next question is, how many consecutive days would be convincing enough to prove that you are a good actor if there is no successful challenge during the period? A week or a month? Including this question, how you design all the exit procedure especially a challenge process is extremely important, and hence all the intense discussions are going on amongst professional Plasma researchers on Etheresear.ch.
The reason why challenge period is arranged a week to guarantee the validity of transaction history for now is that 7 consecutive days are assumed to be a sufficient set amount of time for individuals to discover fraudulent exits and submit a challenge. In reality, users who have the potential to be economically harmed by those fraudulent exits should be able to automatically challenge if the background setting of the application is active, considering the user experience. Say, Plasma chain used for a remittance app, we just assume that it would not be too bad for users to be required to access to the app at least once a week. As another security model idea suggested, it is also possible to let users who want to withdraw their funds as soon as possible pay a commission fee to someone who can wait longer term for their withdrawal, and thus the urgent withdrawal will come with the money subtracted by the fee.
Exit/challenge game modeled by each proposal
Under each section below, I will go over each proposal and check their ‘challenge completeness;’ the coverage of transaction type it can detect to challenge with its security model (in other words, how likely they don’t miss any fraudulent exit) as well as the validation system for transaction histories as a whole.
Plasma MVP
As I mentioned in the previous article, Plasma MVP was the first Plasma proposal suggested as a UTXO model.
You can refer to the chart called ‘Plasma World Map’ below for the detailed classification of each proposal, how they evolved in what context.
(image source: https://ethresear.ch/t/plasma-world-map-the-hitchhiker-s-guide-to-the-plasma/4333 )
With the MVP exit contract, it can automatically inspect whether or not an operator behaved maliciously, more specifically, check either he/she (operator can be a group of people, more accurately) has created a UTXO output from nothing by making sure that the amount of UTXO outputs is larger than input when the transaction exits.
(image source: https://bitcoin.org/en/)
UTXO outputs should be larger than inputs as you cannot buy something that costs (as an output) more than the amount of money you have in your wallet (as an input). However, challengers have to check all the transactions with UTXO inputs and outputs spreading like leaves (of outputs and inputs) on branches (transaction histories) and make sure alchemy (creating money from nothing like magic) transaction has not happened among the accounts that the operator is taking care of. Since the contract can’t automatically suspect those, client parties with a full node in the network have to check all the transaction histories backward with UTXO inputs and outputs spreading infinitely. Consequently, the solution to the high inspection cost was considered that it would be efficient to ask for help to a trusted watchtower to examine them on behalf of you.
Where there are numerous types of transactions that you have to inspect and challenge, (in other words, without a “challenge completeness,” which I’ll explain under Plasma Cash section) the only way to prevent a fraudulent transaction from exiting was ‘Mass Exit.’ This is the worst-case scenario since all the application users have to exit at the same time, which is very time and money consuming. Also, clients can’t exit when they are being lazy on inspection and miss the timing to leave; right after some invalid transactions are created. Since all the transaction after the invalid transactions included in the block will be regarded as invalid as well, they have to exit the childchain as soon as possible. In Plasma Cash, which I’ll explain in the next section, this problem of burdensome data checking process and inefficient exit game get much better somehow as all the transaction histories get laid on one line assigned a unique coin ID, hence invalid transaction history becomes much easier to be challenged.
Please refer to the original proposal posted on Ethresear.ch for more details: https://ethresear.ch/t/minimal-viable-plasma/426
Plasma Cash
Plasma Cash’s security model is quite different from that of Plasma MVP. TxInput and TxOutput on a transaction get paired and corresponds to each other in each transaction since a unique serial number is assigned to indivisible coins that were spent in transactions.
Hence, the inspection of the transaction validation will be much simpler and less time-consuming. There are only 3 patterns of invalid exit;
1. Exit Spent Coin Challenge
2. Exit Double Spend Challenge
3. Exit with Invalid History Challenge
(source: https://karl.tech/plasma-cash-simple-spec/)
I personally title them (in a more explanatory way)
1. Spent/challenge[By]After[TxProof]
Exiting coin is later spent by other transaction and ownership of the coin is already moved to another person. Therefore, it can be challenged a transaction that occurred after the exiting invalid transaction.
2. Double Spend/challenge[By]Between[TxProof]
Exiting coin is double spent. Therefore, it can be challenged by a valid child transaction between the parent transaction and the exiting invalid transaction.
3. Invalid History/challenge[By]Before[TxProof]
Exiting coin has an invalid history. Therefore, it can be challenged by the last valid transaction which occurred before the invalid transaction.
Since any invalid transactions can be categorized into those 3 patterns, if there anything goes wrong, then it easily gets recognized and challenged; this condition is particularly called “challenge completeness.” This is one of the very fundamental requirements of Plasma, that has to be fulfilled by any kind of proposals no matter how amazing functions and modifications are newly added. With the “challenge completeness,” it should be perfectly safe to deposit a huge amount — even billion of money anytime you want. No joking.
This architecture focused very much on its secureness but the benefit of it isn’t just that. Eliminating the need for watchtower to monitor all of the transaction histories like in Plasma MVP, clients just have to keep an eye on the transaction that can economically impact them; much less inspection cost and extra scaling are expected by the implementation.
Please refer to the original proposal posted on Ethresear.ch for more details: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
Plasma Cashflow
Adding some modification to a basic and thus the most secure model ‘Plasma Cash,’ Plasma Cashflow introduced two new attributes, “swapping” property, which increases the interoperability of different coins on the same Plasma chain, as well as “range” property, which enables all the unique coins fungible. Implementing the atomic swap feature, the security model of Plasma Cashflow had to require another special exit-game called ‘Force Include.’ From this alteration, you can clearly see that adding more features, which makes user experience better somehow, means that you need to add some more inspection process and think of a new exit/challenge procedure to secure the exit contract.
Please refer to the original proposal for more details: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view
Plasma Prime
Based on the Plasma Cash security model, Plasma Prime added a concept of light client’s storage scalability. Cryptoeconomics Lab, the author of this article is working at as a researcher and writer, is currently building a 2nd layer security protocol called Plasma Chamber, implementing some of the attributes that Plasma Prime proposed. The detailed implementation of Plasma Prime is more complex, so I will describe it in my future blog posts. Building on the flexible UTXO model, the implementation will enable complex transactions by smart contracts, while guaranteeing the 1st layer security even on depositors’ assets on the 2nd layer. For instance, decentralized exchanges and multi-signatures would be able to be implemented while using those flexible, very adaptable contracts. (The detail of this implementation can be referred to on these slides; https://speakerdeck.com/shogochiai/stateful-txo-is-the-new-contract)
While having much flexibility on the contracts’ expression, however, it is far more important to think how you can guarantee the 1st layer security, again.
Please refer to the original proposal for more details:
- https://ethresear.ch/t/plasma-prime-spec/4181/2
- https://ethresear.ch/t/plasma-prime-design-proposal/4222
Must-haves of Plasma
As I mentioned above, even when you get excited for new features proposed, you also have to make sure that the new architecture has an ability to guarantee the
- Proof that the transactions exist (eg. Block height)
- Validation of the transaction histories with challenge Completeness
Those are the “must-haves” of any Plasma security model, no matter how impressive new modifications are.
While going over those must-haves of Plasma in this article, you can probably see how our new solutions Fast Finality and Commit Aggregations, which lower the transaction inspection cost (there are some detailed explanations on them on Learn Plasma and Etheresear.ch) guaranteed must-haves in the implementation.
Although this back-to-basics article sounds very basic to experts, it is highly important to make it sure with everyone especially new learners in that it might help to redefine “what really Plasma is” while following all the fresh proposals thrown on Ethresear.ch. Even all the genius Plasma implementers seem to have been struggling to share the solid definition of it in common. Therefore, by defining what the core mentality of Plasma so far, I hope it would enable each of us to distinguish whether the model is well designed much easier.
Conclusion
The goal of this article was to remind what the core feature of every Plasma proposal is in common; how they secure users’ funds. Whenever you are learning new stuff, it is important to stick with the fundamental philosophy you learned first as you move forward. This lesson is even applicable to from playing tennis to leaning Plasma; learning new techniques doesn’t mean you can forget the basic forms!
My understanding is of course not on the 100 % level yet, so please leave any comments/suggestions in my articles as I keep going forward on my long Plasma journey. I will be writing more of the articles focusing on the technological details I left out in this article in the future. Hope this Back-to-Basic article can save you a little time and let you jump into the philosophy of Plasma as you start learning it. Last but not least, I would like to give special thanks to Shogo Ochiai, Syuhei Hiya for always sharing their invaluable time and insights with me to improve my understanding of the technology. All remaining errors are my own.
