My Thoughts on Plasma Ethereum L2
Plasma is a layer-2 scaling solution that was initially proposed by Vitalik Buterin and Joseph Poon in 2017. The whole concept has been described in its white paper “Scalable Autonomous Smart Contracts”. Plasma, in a nutshell, claimed to be a framework for building scalable applications. Plasma uses a combination of smart contracts and cryptographic verification.
Here is the link to the original paper: http://plasma.io/plasma-deprecated.pdf
My Thoughts on Plasma
Based on my research, there are several different implementations of Plasma, but all of them, more or less, try to provide a way to conduct transactions off-chain at a much higher and cheaper rate.
The single-operator model can be used in Plasma because there is the requisite fraud-proof verification mechanism in coexistence with periodic snapshots/checkpoints of the sidechain state on Ethereum, which fosters optimistic execution of transactions on the sidechain made possible.
One significant distinction between Plasma with a regular sidechain is that the Plasma contract on Ethereum can secure things like asset ownership and other states and, therefore, can survive an attack on the sidechain.
In simple terms, users can still get their assets back on the main chain if the sidechain goes down or the operator goes rogue.
There is also an excellent mechanism to prevent users from falsifying their state ownership and ways and means to dispute that.
Overall, the framework is quite good but does have limits, yes!
Plasma Limitations
As we have learned by implementing and iterating, the restrictions are that there is an absolute cap when we need to fallback to the Ethereum main chain in scenarios such as mass exits. Mass exits are events during which the sidechain goes rogue, and the users need to prove ownership of assets/states on the main chain by submitting proofs on the Plasma contracts.
Security Model of the Plasma Operator
Suppose one implements the Plasma operator as a single entity alone. In that case, the potential for the operator to attempt fraud is higher relative to the operator being replaced by an incentivized Proof-of-Stake validator. That explains why Matic has implemented a hybrid Plasma+POS architecture which reduces the data availability attack vector to a large extent.
The optimistic design indicates that the sidechain will often run transactions faultlessly. The mass-exit scenario occurs only when more than $⅔$ (>66\%) validators collude to take the Proof-of-Stake security mechanism down. This attack scenario is rare and is generally the fundamental assumption behind any BFT-based PoS blockchain, e.g., Cosmos.
It is crucial to reveal that the mass exit mechanism is a fallback mechanism and comes into the picture only in a worst-case scenario. Of course, there are griefing attacks possible — but these are some assumptions that we can choose to begin with.
Mass exits
The primary contention about mass exits in Plasma is that if there is a sufficiently large number of users performing mass exits, it can lead to congestion on the mainchain (Ethereum), and users may not be able to exit in time. Sure, mass exits can be significant.
Let us use an example for illustration:
Presume
- Number of users on the sidechain, $u = 100,000$,
- Gas required for MoreVP exit, $g = 700,000$,
- $y$ is the fraction of Ethereum block filled for mass exits alone. $0 < y <= 1$
Then
Let us assume 25% of the block is filled, and this would take $8750*4 = 35,000$ blocks or $8750$ minutes or ~145 hours or ~6 days for users to mass-exit the chain.
Assuming 100% of the Ethereum block is filled, similar to calculations seen in comparison articles, this will reduce to ~1.5 days. So ~450k users can be supported on a single Plasma chain, which can go up once one introduces the notion of multiple Plasma chains.
Of course, this is a sample scenario, and other factors also affect this.
Nevertheless, it helps to visualize the kind of tradeoffs that are present in implementing a real-world Plasma implementation.
Withdrawal period in Plasma
The withdrawal period of assets/state to move back to Ethereum is defined by the challenge period that most Plasma implementations choose to keep as default. This period is generally kept as one week, so users need to watch the chain once per week, and it is good enough that Ethereum block size is not a bottleneck (assuming a certain number of users). There can also be innovative ways via engineering or by using governance DAOs to increase the withdrawal period durations dynamically should the number of withdrawals see an unprecedented surge.
Users also need to wait before withdrawing their assets from the Plasma chain.
Of course, one can introduce a secondary market here, which allows users to swap their Plasma assets with Ethereum assets with a counterparty at a specific discount and withdraw instantly.
Data availability in Plasma
The primary assumption in a Plasma implementation is data availability. As long as we have data availability guarantees, it is relatively easy to prove the provenance of assets by users.
Users need to sync data from the sidechain to provide for challenges. That has been the bone of contention of Plasma with single operators, and it is undoubtedly a significant problem. That data availability layer for rollups has been posited as Ethereum (specifically, calldata) in most circles, and that is a crucial insight and a limiting factor as well.
One good example of how it can be solved/mitigated for Plasma is an incentivized Proof-of-Stake validator system and an approach Matic Network has been taking.
Fees
Fees are relatively straightforward to charge for, cheap, and increase linearly with the complexity of the transaction.
Operator
Plasma can work with a single operator but can have relatively better data availability properties with a Proof-of-Stake-based sidechain.
Watcher nodes
Most L2 solutions need watcher nodes to ensure the sidechain works as intended and to challenge the mainchain’s fraud. While watcher nodes for OR’s (optimistic rollups) and ZKR’s (zkRollups) are comparatively easier to implement, one still needs to incentivize them to perform these actions. ZKSync by Matter Labs is an excellent example of how this can happen. Another example is Matic Network, which has a validator layer that is highly incentivized to make sure things work as intended.
Disadvantages of Plasma
The “mass exit” issue is one of the biggest problems with Plasma. If numerous users exit their Plasma chain simultaneously, they could surge the root chain and jam the network. Note that actions such as fraudulent activities (or network attacks) could provoke such a mass departure.
Another “disadvantage” of plasma chains is low complexity, which means users cannot accomplish the same kinds of complex actions as they can on Sidechains. That is because of the necessary precautions to secure users’ funds. It comes down to the fact that it is impossible to simulate the entire Ethereum environment with Plasma.
