Plasma is a blockchain scaling solution designed by Joseph Poon and Vitalik Buterin that uses child chains reporting to root chains (i.e. Ethereum) to increase transaction throughput without any of the safety concerns that usually come with using smaller chains. The OMG (OmiseGO) decentralized exchange was designed in anticipation of Plasma. We’ll utilize Plasma to support a scalable, fully on-chain exchange without sacrificing security. In this piece I’m going to describe how we’re building Plasma.

Goal: To create a blockchain that doesn’t rely on itself for safety.

We’ve achieved this by requiring users to exit the child chain they’re using if anything goes wrong. Here’s how it’ll work:

  1. If an invalid transaction is included in a child chain, all users must exit the child chain within 7 days.
  2. If a user can’t access a child chain, but a child chain block is submitted to its parent chain, the user must regain access to the child chain and check its validity or exit within 7 days.
  3. Withdrawals (aka ‘exits’) are processed in the order of the creation of the transaction they’re referring to. Unspent transaction output (UTXO) withdrawals referencing a transaction that was included in a parent chain at a lower block height (i.e. older transactions) have priority over transactions included in a later block. This causes exits referencing recently included invalid transactions to have a lower priority than exits referencing older valid transactions.
  4. Transactions are only valid if the owners of the inputs sign confirmations verifying that their transaction has been included in the appropriate parent chain.

Responsibility Breakdown

  1. Client — Watches Ethereum and runs the child chain, detecting fraudulent behavior as soon as possible and exiting.
  2. Child chain — Watches Ethereum for deposits and performs all computations regarding the current state of the chain.
  3. Root chain—Anchors child chains to Ethereum via a smart contract. Handles deposits and exits for a child chain, receiving only enough information to process both and to confirm or deny fraudulent exits.
  4. Parent chain — Secures a child chain. Synonymous with Root chain for the Minimum Viable Product (MVP); in Plasma’s final form there may be multiple parent chains between a child chain and a root chain.

Deposits

To use a Plasma chain, users need to move their assets (i.e. Ether or tokens) from a parent chain to a child chain. To perform a deposit, users move assets from a parent chain to a child chain by transferring them to the appropriate Plasma smart contract on Ethereum.

The deposit process for the MVP has been simplified from the one specified in the Plasma whitepaper to decrease complexity. Deposits into a Plasma chain are immediately included in the parent’s record of the child chain and there is no opportunity to cancel a deposit. Instead of cancelling, a user may immediately withdraw their assets.

There is no additional risk to the depositor. Once the transaction transferring assets to the smart contract is confirmed, they may be withdrawn. Even if the child chain does not reflect the respective deposit, the depositor may still withdraw their assets.

Withdrawals

To transfer funds back to a parent chain, a user can initiate a withdrawal. A user may initiate a withdrawal to simply move funds back to a parent chain and hold the funds there. A user must initiate a withdrawal when it detects a faulty Plasma chain; if a user fails to do so within a timely manner they are at risk of losing their funds.

There are two families of withdrawals. The first are ‘simple withdrawals.’ That’s when a single party withdraws its funds from a child chain. The second are ‘mass withdrawals’ when multiple parties withdraw their funds from a child chain together. Mass withdrawals are significantly more complex and will be covered in a future blog post.

When a user withdraws funds from a Plasma child chain, the withdrawals are processed in the order the transactions being exited were created (with earlier ones coming first). Withdrawals are finalized after a challenge period elapses. During the challenge period anyone may provide proof of fraudulent behavior.

Simple Withdrawals

A simple withdrawal consists of four steps:

  1. A user submits a withdrawal request to the Plasma smart contract on the parent chain.
  2. The withdrawal request enters a challenge period which is open for a set amount of time. During this time, anyone can submit evidence of a double spend to the Plasma smart contract, proving that the withdrawal is invalid. If a challenge is successful, then the user trying to exit is unable to withdraw their funds.
  3. If a withdrawal request is found to be invalid, the withdrawer is punished and the reporter is rewarded. If the challenge period ends without a successful challenge, the withdrawer receives their funds. The economic incentives behind this have not yet been finalized.

Finality

There are 2 different types of finality:

  1. Child chain finality — Depends on the consensus mechanism used by the child chain; we’ve chosen to use Proof of Stake.
  2. Root chain finality — Depends on the consensus mechanism used by the root chain; Ethereum is currently using Proof of Work.

The finality and security of a child chain is dependent on the root chain. All of the security guarantees that Plasma provides assume that Ethereum is working correctly.

Things to Remember about the Plasma MVP

  1. It’s Proof of Authority; Proof of Stake will be added down the road.
  2. It will not utilize bonds to penalize fraud.
  3. If an invalid transaction is included in the child chain, everyone must exit the child chain immediately.
  4. The child chain relies on the finality (block confirmations) of Ethereum.

The Plasma MVP is a step towards both (i) realizing the potential of Ethereum by scaling the Ethereum mainnet, and (ii) building the OMG decentralized exchange, making it ready for mainstream financial use. As OmiseGO gets further into the development of Plasma, the design will evolve to include other features described in both the Plasma and OmiseGO whitepapers.

I would like to give special thanks to Joseph Poon, Vitalik Buterin and Karl Floersch for their time and insights, which were invaluable in transforming a big picture blockchain scaling solution into the MVP technical specification that we’re implementing. All errors remain my own.

Did this answer your question?