Finer details of Matic’s Plasma Implementation — Jaynti Kanani

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)

  • A blockchain is divided into different parts called shards
  • Each node does not have to process all the transactions

Off-chain (Layer 2)

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 exit struct 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/proofs for 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.

More from the Polygon Blog
Green Blockchain Summit 2.0: Agenda at a Glance 

Ethereum’s shift to Proof of Stake consensus, known as the Merge, has dramatically cut Polygon’s carbon dioxide emissions, opening the path to going beyond being carbon negative and toward empowering others to do the same. The conversation has shifted from blockchain sustainability to blockchain as a sustainability solution.  Join us for the second chapter of […]

Read More
Robinhood Selects Polygon to Launch Web3 Wallet Beta

Today, we are thrilled to announce that Robinhood has chosen Polygon as the first blockchain network to support its newly launched Web3 wallet. The Robinhood Wallet beta is now live for 10,000 iOS customers out of 1+ million who signed up for the waitlist in May. Together, Polygon and Robinhood are opening access to decentralized […]

Read More
What Is a zkEVM?

Zero-knowledge (ZK) tech is one of the most prominent and promising paths to scaling Ethereum. One popular use of ZK proofs to scale Ethereum is what’s known as a zkEVM (zero-knowledge Ethereum Virtual Machine). So what is a zkEVM, and how does it help us make Ethereum cheaper and more efficient to use? Understanding the […]

Read More
Polygon-Powered Icetea Labs Accelerator Launches With 6 Startups

Polygon has teamed up with Alpha Venture DAO and Icetea Labs to launch the inaugural Icetea Labs Accelerator Program for blockchain startups.  Working in a tight three-way partnership, Polygon is co-creating an accelerator to funnel resources, mentorship, education, and business acumen to promising Web3 companies from around the world. The startups selected for the accelerator […]

Read More
Apply to Polygon Bootcamp Africa and Kickstart Your Web3 Developer Journey

Applications are open for Polygon Bootcamp Africa, launched in partnership with Xend Finance! The eight-week intensive educational course and hackathon combo will put developers in Africa on the Web3 map.  This is Polygon’s biggest step in providing resources to developers, builders, and creators in Africa, and it comes during an important time.  An internet and […]

Read More
Starbucks Taps Polygon for Its 'Starbucks® Odyssey' Web3 Experience 

Today, we are thrilled to announce that Starbucks Coffee Company is working with Polygon to provide the blockchain technology to build its recently announced Web3 experience, Starbucks Odyssey. As a result of the partnership, this new Web3-powered experience will allow Starbucks Rewards loyalty program members and Starbucks partners (employees) in the United States to earn […]

Read More
PolygonInsights - WEEK39

Hola readers! We announced Polygon Bootcamp Africa, an eight-week intensive educational course and hackathon combo, in partnership with Xend Finance, Polygon-based carbon compensation project Coorest has become the first Web3 initiative to have an officially verified carbon standard, and Quadrata, a passport network bringing the identity and compliance layer to public blockchains, is integrating its […]

Read More
From UDC 2022 to Token 2049: A Week for the Devs in APAC

For Web3 developers in Asia, this week was absolutely packed with must-see events. Polygon was there, showing love for the devs in South Korea and Singapore. Here is a rundown of our devrel outreach. Upbit Developers Conference 2022 Some of the best known blockchain developers in Korea and beyond gathered at this year's Upbit Developer […]

Read More
Polygon-Powered Coorest Earns Web3’s First Certified Carbon Standard 

Polygon-based carbon compensation project Coorest has become the first Web3 initiative to have an officially verified carbon standard. The Coorest Carbon Standard (CCS) is certified by an official UN auditor and is a new benchmark for CO2 compensation that leverages distributed ledger technology to eliminate unfair and opaque carbon offset practices. In partnership with Polygon, […]

Read More
crossmenuchevron-down-circle