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.