A high-level overview of one of Ethereum’s layer 2 solutions
This article is the first in a series of high-level overviews of features, protocols and developments of different blockchains. In these overviews, I will attempt to provide relatively simple outlines of the topic, as well as some detail regarding their inner workings and practical applications.
TL;DR
In a hurry? No problem, here’s a general summary:
Public blockchains, such as Ethereum, need to be able to scale in order to reach their ambitions of being recognised as a viable alternative to traditional systems, which, in-turn, will allow them to gain widespread adoption and application.
These scaling solutions can be ‘built into’ the blockchain itself (layer 1 solutions) or ‘built on top of it’ to take some strain off the base chain (layer 2 solutions). These two solution categories will likely be complementary to each other.
Plasma is a layer 2 solution for Ethereum that provides a framework for building ‘off-chain’ decentralised applications that are secure, scalable and swift. There are numerous implementations of Plasma, including:
Minimal Viable Plasma (MVP) — A UTXO-based chain that possesses the basic principles of security and enables a higher transaction throughput for Ethereum.
More Viable Plasma (MoreVP) — Improves the user experience of MVP by lowering the number of actions required to make a transaction.
Plasma Snapp — A proof of concept that aims to reduce the complexity of Plasma, paving the way for more sophisticated protocols than just token transfers.
Plasma Cash — An implementation that utilises non-fungible tokens as a representation of fixed amounts of fungible ones. For example, if I deposit 5 ETH into the Plasma Cash chain, I receive a single token worth 5 ETH that cannot be merged or divided. Practical applications include collectible-based games and supply chain management and logistics.
Plasma Debit — An implementation that is very similar to Plasma Cash, but allows partial payments. The most practical application would be for payments of any size, particularly micropayments.
Plasma Bridge — Soon to have a proof of concept, this will allow two different layer 1 blockchains to interact with each other via a shared Plasma chain, enabling atomic swaps. For example, the Plasma chain could act as a connection between the Ethereum and Ethereum Classic blockchains.
Plasma is not Ethereum’s only proposed layer 2 solution and can be reasonably expected to coexist with — and, as with layer 1 solutions, complement — the other layer 2 solutions.
Read on for the full article.
A brief introduction to blockchain scalability
Although people are becoming aware of the vast potential and many applications of blockchain technology, there are numerous hurdles in the way of public blockchains before they can achieve these ambitions. The most prominent problem is the scalability of the blockchain.
Scalability is defined as the capability of a system, network or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. Although scalability is an assortment of challenges in the context of blockchain, discussion mainly revolves around the network’s transaction throughput. This is evident from the recent spotlights on Ethereum, which have focused on the network’s speed during times of congestion — predominantly caused by events such as initial coin offerings and games revolving around non-fungible tokens.
Layer 1 solutions
One of the approaches for scaling these platforms is through modification of its base protocol, or ‘layer 1’. Due to their direct nature, these changes are generally enacted through a hard fork.
An example of a layer 1 solution for Ethereum is ‘sharding’, which solves the ‘one-track’ issue bottlenecking the network. Currently, every node has to process every transaction in sequence, limiting the network’s transaction throughput to the maximum that can be processed by each node. By splitting the chain into segments — or ‘shards’¹— this limit is lifted, as each node can then process different transactions in parallel with each other².
Research and development work for sharding is fully underway by groups such as Prysmatic Labs and the community in general, but the upgrade is not yet close to release.
¹ Each shard is technically its own separate blockchain, each sharing the same consensus mechanism via a beacon chain and each able to communicate with other shards.
² Furthermore, once sharding is live, the shards are planned to use eWASM over the existing EVM, which in itself will improve transaction throughput via the faster processing speed of smart contracts. This instruction-set also has the added benefit of making smart contracts more standardised and secure.
Layer 2 solutions
Changes to the base layer of a blockchain can be incredibly difficult to execute, as the integrity and security of the protocol is paramount to its success. Due to this sensitivity, layer 2 solutions are also being developed which will complement the layer 1 methods in providing a scalable and efficient blockchain.
Layer 2 solutions are not changes to the base protocol, but rather constructions built on top of it to allow operations to take place ‘off-chain’, while still retaining the benefits provided by the main chain, i.e. security and finality. An obvious benefit to layer 2 solutions is that a hard fork is not necessarily required for their implementation, but their scope is far larger than integration concerns; along with layer 1 solutions, they can dramatically improve the practical application and usability of the ‘base’ blockchain.
There has been extensive research into layer 2 solutions since the initial concepts of State Channels — including Raiden, TrueBit and Bitcoin’s Lightning Network — but perhaps the most promising³ layer 2 solution under development for Ethereum is ‘Plasma’.
³ Note that there is no reason the different solutions cannot coexist; for example, Channels may be built upon a Plasma implementation in the future due to their complementary attributes. I do, however, believe that Plasma will be able to establish itself as the most widely utilised layer 2 solution.
What is Plasma?
Plasma is a framework for building decentralised applications (‘dApps’) that are secure, scalable and swift.
Plasma allows dApps to achieve this through the creation of ‘child’ blockchains, which are connected to the ‘parent’ blockchain¹ through a smart contract. The dApps can then execute entirely on their respective child chains, dramatically lowering the strain placed on the parent chain and enabling the dApp to be more efficient and cost-effective.
These child chains are full blockchains, with their own consensus mechanisms — likely to be Proof of Authority (‘PoA’) or Proof of Stake (‘PoS’) — but, like children, they are not fully independent of their parent. The child chain relies on the parent for security and so must periodically submit commitments to the smart contract that connects them. These commitments are details of the latest updates from the child chain and, as they are broadcast across the parent chain, i.e. the entire Ethereum network, they are crucially important.
To ensure all these off-chain changes are final and binding, they need to be subject to a cryptographic primitive — a ‘commitment scheme’. Due to their size, however, committing applications in their entirety to the parent chain would make the use of Plasma obsolete. For this reason — as with other blockchain applications — ‘Merkle trees’ are used which, in-turn, allows the use of ‘Merkle proofs’.
In simple terms, a Merkle proof allows the authentication of a small amount of data — such as a hash — to be extended to also authenticate a much larger database. Bitcoin applied Merkle proofs for the storage of transactions in each block, which facilitated Satoshi’s concept of ‘simplified payment verification’. In Plasma, the commitments are the ‘root’ of the Merkle tree of each block, thus enabling the use of Merkle proofs for one of the framework’s defining security features — the ability for users to ‘exit’ the child chain.
Exiting the child chain means the user withdraws their funds back out to the parent chain and — through the application of a Merkle proof — can prove to the smart contract that they have the funds to withdraw. A key part of Plasma’s security is that the user has the right to withdraw to the parent chain at any time.
¹ Note that the use of ‘parent’ chain is for simplicity/visualisation purposes. The correct term is ‘root’ chain, as it is possible for a child chain to have their own child chains ad infinitum (technically making these child chains ‘parents’, but not ‘roots’). Every child chain will be a subject of the root chain, rather than the child chain above them in the hierarchy.
Is Plasma secure?
Layer 2 solutions rely on the base layer to provide their security, but they need mechanisms in place to protect the operations on their own chains too.
In brief¹, Plasma has many theoretical security elements, the core of which revolves around the user being able to exit the child chain at any time, i.e. withdraw their funds back to the main Ethereum chain. This means that even if the child chain is completely centralised — and that central party decides to act maliciously — none of the users’ funds are at risk of being permanently lost.
This safety comes from users being able to rely on the main chain as a source of truth, as well as from how any user can challenge any withdrawal from the child chain. When users want to exit the child chain, they need to submit an ‘exit’ transaction on the main chain — an ‘exit bond’ — and, in some implementations, they also need to include a Merkle proof to prove their ownership of the funds.
Withdrawals from the child chain aren’t instant. Instead, they’re subject to a challenge period — an ‘exit challenge game’ — where any user can submit a ‘fraud proof’ to the main chain. The fraud proof contains data from a previous block that proves that the exit is invalid, as the funds trying to be withdrawn by the user have already been ‘spent’ by that user in a different block. Those who successfully prove the transaction is fraudulent are known as ‘bounty hunters’, as not only do they prevent the exit from happening, but they are also rewarded with the value of the bad actor’s exit bond.
As you can probably imagine, off-chain security is a very complicated issue, with numerous theoretical problems. One that seems to be apparent in MVP² (below) is the responsibility of challenges and the scope of bounty hunters. For example, if I deposited £1000 into the child chain — giving me a starting point of £1000 UTXO — and sent one hundred thousand (100,000) transactions of 1p to other addresses under my control, then the only parties that would care about fraudulent exits from those transactions — i.e. if I try to fraudulently exit some of those ‘spent’ UTXOs — would be myself (the bad actor) and, indirectly, the bounty hunters.
These fraudulent exits could occur at any point on the chain and, due to the number of transactions, a copy of the whole chain could be far too large for a regular PC to handle, severely limiting the pool of bounty hunters who can challenge my exits.
From a data storage perspective, the answer could lie in a mechanism for safe checkpointing in MVP, enabling widespread participation in all challenges as the period, ergo the data, would be limited to a reasonable amount. The question would then be about how incentivised users are to watch others’ transactions³.
Due to the importance of security, there is a lot of debate about how protection can be managed while still maintaining the highest levels of decentralisation.
¹ The details and issues surrounding Plasma’s security will be explored in detail in a future article.
² Note that this theoretical issue would not necessarily be applicable to Plasma Cash, due to the implementation’s requirement of historical ownership proof and token uniqueness mechanisms.
³ There are further questions surrounding this problem which won’t be addressed in this article, but as an example: all exits can be challenged if a user must put up a bond for every exit — but what would be the value of these bonds? Would they be a set value, or dynamic and proportional to the amount being transferred? The value of these bonds is critical in ensuring a balance between good user experience and incentivised bounty hunters.
Implementations of Plasma
As a framework, Plasma has nearly unlimited applications — the majority of which are still in the research stages. Below are very brief overviews of some of the latest proposed implementations of Plasma, which will be explored in greater technical detail in future articles.
Minimal Viable Plasma (MVP)
As the name suggests, Plasma MVP is a UTXO-based chain that possesses the basic principles of security and enables high transaction throughput, but relies on users being able to willingly interact with, validate and exit the chain themselves. In these early stages, users will also have to have a certain level of trust in the operator, as MVP uses a PoA mechanism.
More Viable Plasma (MoreVP)
More Viable Plasma builds upon MVP by improving the user experience. To transfer UTXOs in MVP, users would need to send them to another user’s address, wait for that transaction to be confirmed in a block and then send a confirmation signature. Not only is this ‘double signature’ system onerous on users, it reduces the block space available for other transactions. MoreVP, in essence, removes the need for these confirmation signatures due to its adjustments to exit priority.
The MoreVP specification is currently being expanded by the team at OmiseGo.
Plasma Snapp
Currently at the proof of concept stage, Plasma Snapp aims to effectively remove much of the complexity of Plasma integration through the use of ‘zero-knowledge succinct non-interactive arguments of knowledge’ (‘zk-SNARKS’), removing the need for confirmation signatures and even exit challenge games.
Vitalik has also recently elaborated on the use of zk-SNARKS in scaling, providing a proposal that wouldn’t require transacting parties to always be ‘online’. This makes progress in solving the data availability issues that would be present within current Plasma implementations, which is caused by their liveness assumptions regarding eventual consensus¹.
¹ In simpler terms, Proof-of-Work (‘PoW’) can essentially guarantee liveness, whereas other consensus mechanisms like PoA aren’t as guaranteed due to the requirement of ‘monitoring’.
Plasma Cash
Plasma Cash is an implementation that utilises non-fungible tokens as a representation of fixed amounts of fungible ones. For example, if I deposited 25 ETH into the Plasma Cash chain’s contract, I would receive a token on the chain worth 25 ETH. Each token on Plasma Cash is attributed a unique ID upon creation and cannot be divided or merged with other tokens.
Plasma Cash blocks are also different to those seen in MVP. Plasma Cash blocks save a ‘slot’ for every token in existence on the chain, meaning users can not only see what has been sent in each block, but also what hasn’t been sent. This allows the formation of sparse Merkle trees, which can act as a proof that a transaction isn’t part of a particular block.
As a slot in each block is unique to each token, no other token can be placed into that slot. This means that users only need to keep track of their own token(s), as no other tokens can enter their slots. This reduces the amount of data that needs to be transferred to clients, as they only need to download the data they are privy to, i.e. proof of their token history.
One of the issues with Plasma Cash is in its general flexibility — tokens on the chain must always have a fixed denomination, preventing the transfer of fractions of tokens.
Plasma Debit
Plasma Debit is very similar to Plasma Cash. One of the key differences is that it allows partial payments to be made, thus enabling arbitrarily denominated payments and, therefore, micropayments.
Plasma Debit is like a Lightning hub, where each token represents a bidirectional payment channel (as opposed to the deposit itself). Unlike the Lightning Network, the state of the channel is regularly notarised to the main chain, meaning these tokens can be transferred from one owner to another (as with Plasma Cash tokens). As these tokens are payment channels, this means that a new party can join the Plasma Debit payment network without having to perform an on-chain transaction themselves.
Plasma Debit is most suitable for payments, as all transactions will be fast and cheap. One of the projects that is researching a Plasma Debit implementation (alongside their Plasma Cash work) is the Loom Network.
Plasma Bridge
A theoretical project that should soon have a proof of concept, Plasma Bridge would be a way to connect two layer 1 blockchains together via a shared Plasma child chain. This would allow the conversion of different blockchain assets to a standard native token on the child chain, enabling free transfers of value between chains, i.e. atomic swaps.
Interoperability of blockchains
The interoperability of blockchains is another major discussion point for the future of the technology. Many people are fiercely loyal to their chosen chain, which can be detrimental to development progress as proponents fail to acknowledge their own chain’s objective weaknesses or other chain’s relative strengths.
Polkadot are aiming to address this issue, as are numerous Plasma-based projects. An example of the latter is OmiseGo, who are building — amongst other things — a Plasma DEX that will initially use clearinghouses for assets where Plasma child chains cannot be built, such as Bitcoin.
Scalability is vital for the widespread adoption of public blockchains and the Plasma framework is a major development towards Ethereum 2.0.
Additional sources/Further reading
I’ll be writing a collection of pieces about the development of numerous blockchains and the industry as a whole, covering a range of topics including, but not limited to: sharding and beacon chains, PoS and Casper/Tendermint, interoperability of blockchains and Polkadot, oracles, non-fungible tokens, stablecoins, decentralised exchanges and Plasma’s numerous implementations and security features.