Finer details of Matic’s Plasma Implementation
--
What is Plasma?
Plasma is a framework for building scalable decentralized applications. It was proposed by Vitalik Buterin and Joseph Poon to tackle Ethereum’s scaling needs. There are many different flavors of Plasma, namely — MVP(Minimum Viable Plasma), MoreVP, Cash etc. This post aims to provide an overview about Matic’s Plasma implementation.
Why is Plasma needed?
Current blockchain systems are pretty slow compared to centralized applications. To handle even simple payments, blockchains would need to process at least a few thousand transactions per second. Ethereum currently supports approximately 20–30 transactions per second depending on network conditions.
Why are blockchains so slow?
- Every transaction on public blockchains such as Ethereum needs to be processed by every single node in the network
- Thus the transaction throughput cannot be higher than what an individual node can process
- If we increase the processing workload for each individual node — for example, increase the block size to accommodate more transactions — then less powerful computers may not get to participate in running the blockchain, leading to miner centralization
- This results in reduced decentralization and potentially leading to censorship on the blockchain
This is the “blockchain scalability” problem, and there are many approaches that different projects are adopting to solve this.
On-chain (Layer 1)
Sharding
- A blockchain is divided into different parts called shards
- Each node does not have to process all the transactions
Off-chain (Layer 2)
State channels
- Participants open two way channels to share states by signing them off chain
Truebit
- Heavy or complex computation conducted off-chain
Plasma
As mentioned earlier, Plasma is a framework for building scalable blockchain applications. The main design consideration being — not everyone needs to process every transaction on the blockchain.
The basic idea here is that we can:
- Transfer assets from base chain to another (called the “sidechain”)
- Lock the assets on the primary chain (or “base chain”) and
- “Create” them again on the sidechain
- Transfer assets cheaply on the sidechain
- When you want to exit the sidechain, you simply need to “destroy” the asset on the sidechain and unlock them on the base chain.
The “assets” mentioned above are for illustration purposes — this applies to all “states” for a contract that can be executed on a blockchain.
To reiterate, Plasma in general is a mechanism wherein states (assets, tokens, game states, app states, etc.) are ported to an off-chain avenue viz sidechain, mostly via a “locking” or “deposit” mechanism in a mainchain contract. This locked state can then be safely mirrored on the sidechain because the state cannot be changed by the user on the mainchain after locking. A deposit/lock queue is maintained on the mainchain contract to keep track.
Once the state is on the sidechain, it is possible to do faster/cheaper transactions, because the consensus on this sidechain is not what provides security — in fact, the consensus mechanism here is not what guarantees the security of the states. Why you require, say a PoS consensus on the sidechain is to ensure data availability, We will discuss this later..
Plasma requires you to send periodic state commitments of the sidechain (Merkle root of n blocks). What this accomplishes is that you have a snapshot of the sidechain state on the mainchain contract at all times. Now, there is the concept of `exit queues` and `fraud proofs`. States that have to be “exited” from the sidechain to the mainchain, need to be “withdrawn”.
Let’s assume a particular state (say, game state) has been changed via transactions on the sidechain. For this to be “withdrawn” (or sent from the sidechain to the mainchain), the user has to submit a “proof” of the state to the mainchain contract. This state is then validated with the help of the fraud proofs (state-transition validator smart contracts on the mainchain) and exit order is maintained by the exit queue mechanism.
The fraud proofs also help is in enabling the role of watcher nodes, which are incentivized third-parties, monitoring the sidechain for any invalid state-transitions. Users exiting the sidechain post an exit bond to initiate exit. These watcher nodes can initiate a challenge to any exits that are done on the sidechain. In case of a successful challenge, parties initiating the challenge are incentivized using the exit bonds for transactions that are deemed fraudulent. What this entire construction ends up enabling is that even in the case that the sidechain is compromised, users still can easily exit the chain, and can rest assured that the states/assets on the sidechain are safe. That’s the beauty of Plasma!
Why do you need PoS (Proof-of-Stake) consensus on the sidechain?Watchers/challengers/users needing to challenge any invalid exit need access to data on the sidechain to validate the data. Generally, a Plasma chain can be run by a single operator as well, because the consensus is enabled by the Plasma construction, not by the consensus on the sidechain. However, a single operator is problematic, because it is easy to make data unavailable — a properly incentivized PoS mechanism on the sidechain makes it harder to make the data unavailable, and that’s why you need a token to ensure that validators on the PoS layer are committed to the Plasma sidechain.
The Matic Plasma implementation has the following key features:
- Account-based Plasma
- Similar in nature to Plasma MoreVP (More Viable Plasma)
- Faster blocks (~1s)
- EVM-compatible sidechain and thereby similar developer interface
- Proof-of-Stake layer for ensuring liveness
Matic Plasma follows a model similar to Plasma MoreVP, but is an account-based implementation compared to other UTXO-based implementations. The sidechain is EVM-compatible. Currently, the ERC20 and ERC721 transfer implementation is complete. A Proof-of-Concept for asset swaps (ERC20-ERC20, ERC721-ERC20, ERC721-ERC721) is complete as well. This will enable marketplaces and exchanges to run on our Plasma implementation.
You can refer to this link for the implementation — https://github.com/maticnetwork/contracts.
The Plasma MoreVP implementation is an improvement over the Plasma MVP (Minimum Viable Plasma) spec.
The account-based implementation for ERC20 and ERC721 transfers is implemented with a UTXO-like event log data structure. Below is a `LogTransfer` event for reference.
event LogTransfer( address indexed token, address indexed from, address indexed to, uint256 amountOrTokenId, uint256 input1, uint256 input2, uint256 output1, uint256 output2);
`input1` and `input2` are the account balances of the sender and the recipient before a particular transfer. Similarly, `output1` and `output2` are the account balances of the sender and recipient after the transfer has taken place. This is how we handle the balance state at a particular point in time. While submitting the proof for withdrawal of tokens from the Plasma sidechain to the Ethereum mainchain, the transfers are tracked by way of collating all the related `LogTransfer` events among other things.
In Plasma, as discussed earlier, the following components are used to implement the security mechanism:
- Off-chain execution
- State commitments
- Exits
- Priority queue
The off-chain execution is done on the Plasma sidechain, which in Matic’s case is EVM-compatible. State commitments are done by the Proof-of-Stake Validators who validate the sidechain blocks and transactions every ~5 minutes (256 sidechain blocks).
The exits in Matic Plasma are maintained in the following manner:
// structure for plasma exitstruct PlasmaExit { address owner; address token; uint256 amountOrTokenId; bool burnt;}
As and when a user submits a Plasma exit request, this is added to the `exits` queue. Priority is maintained by a priority queue mechanism. See https://github.com/maticnetwork/contracts/blob/master/contracts/root/ExitManager.sol for more details.
Deposits and Withdrawals to and fro the sidechain and the mainchain are handled in
https://github.com/maticnetwork/contracts/blob/master/contracts/root/DepositManager.sol
and
https://github.com/maticnetwork/contracts/blob/master/contracts/root/WithdrawManager.sol respectively.
In terms of validating the sidechain transactions, see
https://github.com/maticnetwork/contracts/tree/master/contracts/proofsfor details on how the transaction structure is checked for completeness. Event logs are extensively used in the Matic Plasma implementation for various checks.
See https://github.com/maticnetwork/contracts/issues/48#issuecomment-461926665 for the spec for in-flight exits.
Hopefully, we have been able to communicate the Matic Plasma specifics and how we handle our implementation, especially since it is an account-based one, compared to the usual UTXO implementations.
Feel free to drop in to our Telegram group (https://t.me/maticnetwork) or better drop in your queries at https://stack.matic.network.
