Plasma Implementations: Minimal Viable Plasma, Plasma Cash, Plasma Debit

Blockchain Technology 7 min, 31 sec READ

by Martin Banov

In this article, we look at different Plasma implementations (MVP, Cash, Debit) with examples of applications and projects implementing them.

In the first article of this series, we introduced Plasma as a fundamental second layer infrastructure utilizing the Ethereum main network as a global notary (or supreme court, as Joseph Poon puts it). In this second part, we'll briefly examine the specific Plasma prototypes that have resulted from the general Plasma proposition as a design space for custom side chains.

Plasma MVP: Minimal Viable Plasma

Vitalik Buterin's high level specification of the Plasma MVP that defines the data structures and functions (the two main components in a smart contract) contained in a Plasma contract can be found here. The Plasma operator publishes Merkle roots of the side chain into the main chain contract.

Plasma MVP depends on users being willing to swiftly exit as soon as they recognize any kind of misconduct. It is a simple version of a UTXO-based Plasma chain (like Bitcoin's, while the Ethereum main chain is account-based).

UTXO (Unspent Transaction Output) is a transaction output which can be spent as input in a new transaction. A UTXO blockchain is a ledger dealing only with UTXOs (e.g., Bitcoin). Plasma MVP is a UTXO chain and there is no checking of state transitions, but only checking of transaction ordering, so exit procedures are based on older transactions being processed first.

Plasma structures are to be designed on a per use-case basis and Plasma MVP provides the basic template to build applications from and modify accordingly as needed. For now, MVP can only be used for simple payments, but highly efficient at that (~1000 tx/sec, while maintaining the decentralization and security guarantees of the main chain). A repository of OmiseGO’s research implementation of Minimal Viable Plasma can be found here.

MVP is designed for token transfers (ERC-721, general state transitions, etc.), providing the usual guarantees for a token system and is essentially a proof of authority chain with a single Plasma operator, who is nevertheless a central actor restricted by the main chain and other observing participants.

Proof-of-authority (PoA) is an algorithm used with blockchains that delivers comparatively fast transactions through a consensus mechanism based on identity as a stake.

In PoA-based networks, transactions/blocks are approved by authorized validator accounts. PoA systems require that the designated authority nodes are uncompromised and adequately maintained. By attaching a reputation to identity, validators have an incentive to preserve and facilitate the transaction process since they do not want to have their identities attached to a negative reputation.

Kovan is an Ethereum testnet that runs on PoA.

MVP is said to be very easy to implement and essentially a simple REST (REpresentational State Transfer) API.

Plasma Cash: Less Per-User Data Checking

Another way to implement Plasma, Plasma Cash, is a simplified construction based around the use of unique identifiers for token deposits on the Plasma chain – tokens on the network are assigned unique serial numbers instead of than grouping them in a single reservoir contract. That is, each deposit creates a coin (which cannot be split or merged) with the denomination of what has been deposited in Ether, rather than creating an arbitrary unit of Plasma Ether (PETH). Plasma Cash essentially allows owners to transfer assets to the side chain while keeping the original value secure on the Ethereum mainnet where accountability takes place.

In that scenario, a transaction spending a coin needs to be included in the specific position of the Merkle tree that corresponds to the coin ID. For example, for ID 0 the spend transaction has to be included in the leftmost position all the way left in the Merkle tree. Converting the ID to binary notation (ones and zeros) translates to the description of the Merkle path to the valid transaction. Clients need to verify the availability and correctness of transactions only at the specific indices of any coins that they own or care about, going back to when and where the coin was deposited. This change to how transaction history is stored significantly reduces the amount of data users need to process.

In Plasma cash coins are not fully fungible, so any attempts to withdrawal money without authorization means funds are attempted to be stolen from a specific person. For a theft to successfully be carried through, the Plasma chain operator would have to create an invalid block and then send individual exit transactions of specific coins to the main chain which the user/owner can and will then challenge. In other words, it's so unlikely as to be impossible. The operator however has the capability to interrupt service by withholding blocks, but that's pretty much about it.

Plasma Cash is also significantly more scalable since it allows for extremely large blocks which results in a number of benefits, as already touched upon:

Sharded client-side validation: Users only need to watch the Plasma chain for their tokens (ensuring they have not been double-spent or stolen) allowing transaction throughput to scale without increased load on individual users.

No confirmations: Transactions no longer require pending confirmations but instead, once a transaction is included on the main chain it is already spendable.

Simple support for all tokens: No additional complexity to adding any number distinct tokens, including non-fungible ERC-721 assets (e.g., CryptoKitties).

Mitigating the mass exit vulnerability: Since a thief attempting an exit must submit an exit transaction for each token, mass exits become less of an issue (but there is still an interruption in service since the chain halts).

The overall specification is described in a post here.

 

Like all Plasma implementations, Plasma Cash is not a generalized scaling solution, but seems especially applicable for use-cases involving exchange, enabling trading at speeds near the ones centralized exchanges offer (fast central order matching), in addition to instant finality. Plasma Cash usually relies on a single, reasonably constrained authority of the Plasma operator in which it can be further compared to a much safer centralized exchange since the operator only has responsibility as an order matching engine while users have their private keys, so regardless of what happens users can always utilize the Plasma exit procedure and get their money out on the main chain.

Karl Floersch giving a quick, enthusiastic overview of Plasma Cash

Plasma Debit: Arbitrary-Denominated, Divisible Plasma Cash Payments

Plasma Debit is a proposed extension to Plasma Cash, but with fixed denominations and allowing for partial balances equivalent to bidirectional payment channels, but between coin owner and Plasma chain operator (since in Plasma Cash coins are irreducible). Plasma Debit allows to atomically swap Ether between users connected to the same Plasma chain operator, somewhat similar to routing payments through nodes in Lightning Network. It is essentially a research construction for token splitting and subdivision.

The Plasma Debit specification is detailed here.

Plasma Bridge: A Step Towards Cross-Chain Interoperability

Just a few days ago (August 11th), an interesting proposition for a Plasma chain application was posted on ethresear.ch - a side chain that could simultaneously be attached to the base layer of two other blockchains. Interoperability is as much of a priority issue in the blockchain space (interoperability is key to providing liquidity) as is scalability and Plasma seems to define a common overlapping ground for the engineering of solutions that address both issues.

The example concerns Ethereum and Ethereum Classic since they're fundamentally almost identical (the differences being more philosophical and to do with the culture of how the two groups tend to do things) and both use Solidity to define smart contracts and the EVM to execute them, making them a natural fit.

The example is described so:

An anchor contract will be deployed on both chains. Through ethereum, Alice can move ETH into the plasma chain as ETHX. On the other side, Bob moves his ETC in as ETCX.

In the plasma chain both ETHX and ETCX are native tokens . They can be transferred to any address within the plasma chain. Atomic swaps can be easily performed.

ETHX can only be withdrawn to Etherum, and ETCX can only be withdrawn to Ethereum Classic.

This could realistically happen in the near future and could prove beneficial to both communities and their respective ecosystems.

On the Plasma Series

This is the second of a 3-part series on Plasma by Martin Banov. In the first article, we looked at Plasma as further refinement of the Lightning Network concept that makes use of Ethereum's Turing complete smart contracts capability. In the third and final article, coming out Monday, we'll look at some of the projects showcasing concrete Plasma implementations as examples of real-world applications demonstrating what can be accomplished with Plasma and Ethereum. Those include the well-known Omise Go (branch of the popular Southeast Asian online payments processor, Omise), the Loom Network (for large-scale gaming and social applications on the blockchain) and BankEx, a fintech application developed around a Proof-of-Asset protocol.