One of the more interesting areas of Crypto at the moment is the implementation of off-chain scaling technology, an area known as “Layer 2″ technology. Layer 2 solutions are simply scaling solutions that take the burden of scaling off the protocol or a particular application off the main blockchain, whilst still maintaining the trustlessness and decentralisation that a blockchain provides.

If you’ve been following our blog so far, you’d know we are huge fans of Bitcoin’s premier layer 2 solution, the Lightning Network (see our article here) — but layer 2 solutions have also been heavily explored as part of the Ethereum network’s attempt to scale. The most often referred to by Ethereum enthusiasts are Plasma and Raiden, both floated as potential ways to avoid dApp congestion of the network. At this point, just a single dApp’s success can cause significant congestion of the network — something we saw when the infamous CryptoKitties slowed the Ethereum network to a halt back in December of 2017. This article will focus on Plasma as a solution, with a number of new implementations being recently released.

Plasma is a layer 2 framework based around the notion of child blockchains, built off the “parent” that is the main Ethereum chain. A smart contract is created on the main blockchain of which the sidechain is built upon, with the contract storing the basic rules and state changes off the sidechain. Each side chain aims to provide the same level of trustlessness and finality that the main chain does. Side chains thus must apply their own consensus algorithm to confirm and validate transactions, meaning these chains will be implemented with a block validation mechanism such as Proof of Work or Proof of Stake. Because Plasma chains would likely be implemented as a scalability solution for specific high transaction volume chains — consider a DEX like altcoin.io (based on a plasma implementation) — these chains would like be based on Proof of Stake for efficiency purposes.

To take this DEX example further — every state change to the order book would typically have to be immediately pushed to the main blockchain, generating both significant fees for users and transaction congestion on the main chain. Instead, transactions and their respective state changes are recorded on the Plasma sidechain, and a periodic update to the main chain is pushed. The key mechanism here is the sidechain, users need to be confident that the sidechain is still producing a trustless and decentralised ecosystem the same way the main chain would.

In this sense, Plasma isn’t particularly different from any other sidechain solution developed so far — except that the sidechain is built off a smart contract. The ‘Plasma Exits’ as they are defined in the original Plasma whitepaper are supposed to maintain some degree of security for sidechain users. These exits provide a method for any assets deposited to a sidechain to be withdrawn by a user, with a dispute/challenge mechanism available if the withdrawal is fraudulent or faulty.

Using our DEX example from above — an individual can deposit the assets they wish to trade on the sidechain into the main chain smart contract. These assets would be pegged onto the same address on the sidechain, allowing that individual to trade successfully on the DEX. The sidechain application will have a withdrawal function built into its UI, whereby users can withdraw their assets back to the main chain via the use of the main chain smart contract. This is where the “Plasma exit” comes into play, where users can trigger a withdrawal (separate to the normal UX) which returns all the assets they deposited to the sidechain to their main chain address pending a challenge process. The challenge process stops fraudulent withdrawals by hostile users, and the incentive mechanism is designed such that only genuine transactions are approved.

In theory, Plasma does seem a sound way to extend the scaling capability of Ethereum dApps in its removal of transaction congestion. Concerns with the mechanism lie in two key areas — the challenge system and the structure of the side chains involved. The challenge system needs to be designed in a way that does not remove the efficiency benefits of moving transactions to a sidechain, in that a challenge period need not slow down the rest of the blockchain, nor should it take that long in itself. Clearly some more investigation and testing is needed in this particular area.

The second area of concern for users is the structure of the side chains involved. In the context of a side chain designed simply for payments and value transfer, this is fairly similar to the decentralisation dilemma faced by the Bitcoin lightning network, where slight trade-offs between centralisation and performance are made. Clearly there isn’t much point in the use of a dApp that is built on a sidechain that isn’t particularly decentralised. A few of the current plasma implementations that exist as of now —altcoin.io and Omisego’s plasma implementation plasma-dex — seem to lack clear definitions of the elements of decentralisation that are implemented on their side chains. Obviously these DEX’s thus provide some level of security over their centralised counterparts, but the degree to which their DEX sidechain is centralised certainly has an influence on the security of their exchange.

Plasma certainly has potential as a growth area for Ethereum, but the core development team’s focus on a functional Ethereum 2.0 (layer 1 scaling) implementation will stall the progress of these separate layer 2 solutions. Value will be generated on layer 2 at some point in Ethereum’s development, but Bitcoin currently is the far better value proposition in terms of layer 2 scaling. For those looking to follow Plasma’s progress — we recommend the following projects as a starting point

Plasma-Dex (Omisego’s Plasma implementation)

Altcoin.io (Plasma Decentralised exchange)

Leap DAO (EVM Smart Contracts on a sidechain)

Monoplasma (Ethereum payments sidechain)