Plasma: Design Space for Custom Blockchains Extending Off the Ethereum Blockchain
Blockchains, whether Ethereum or Bitcoin, are fundamentally unscalable.
Consensus, by definition, doesn’t scale, despite Bitcoin having formed the largest global consensus network. A single chain cannot hash, compare and validate the entire world in any rationally efficient manner past a certain limited threshold of active use. And even if a blockchain has the capacity for incredibly high throughput, the question of ever increasing storage demand comes in, among many others that loom up along the way. But fundamentally, complexity means integrating different parts to work together in a functional whole and a monolithic blockchain cannot realistically account for that without significant rearchitecting.
Bitcoin was designed as an open ledger peer-to-peer electronic payments system, with one foot in political libertarianism and the other, in the crypto-anarchist and cypherpunk movements. Having originally been more of a niche technological artifact (that took the form of also a social experiment), rather than intended to function as a global remittance network, its value largely derived from the erosion of public confidence in traditional financial institutions after 2008.
Ethereum’s concept, on the other hand, is that of a “world computer” — a global run-time environment whose transactions condition financial and database operations contingent on the evaluation of more complex computational scripts (“smart contracts”) bound to the immutability of the underlying blockchain. Ethereum was born out of Bitcoin’s limitations and the desire to expand the capabilities of that technology beyond the constraints of what Bitcoin dictated.
Regardless, Bitcoin and Ethereum together comprise the most powerful computational resource in the history of mankind, yet offer no more power for processing and verifying transactions than an ordinary smartphone. And as cryptocurrencies and digital assets grow in popularity and expand their horizons, the issues keep on resurfacing on the forefront ever so urgently in efforts to sustainably meet demand (the CryptoKitties debacle being just one well-known case in point).
Bitcoin and Ethereum together comprise the most powerful computational resource in the history of mankind, yet offer no more power for processing and verifying transactions than a ordinary smart phone.
There are a number of continuing endeavors and complementary approaches to overcoming or addressing the obstacles facing public blockchains that grapple with the problem of engineering solutions capable of accommodating demand from different angles. There is the first layer, so-called on-chain solutions, which has to do with fundamental changes on the infrastructural and protocol levels. And there is the second layer, sometimes referred to as off-chain solutions, which are extensions to the base layer.
So-called second layer solutions are auxiliary off-chain instruments designed to unburden on-chain traffic in a way preserving of the public chain’s security guarantees while sparing resources on-chain. Some of these solutions are often blockchains themselves, but don’t function as standalone chains since the transactions they support must eventually be verified and settled on the base layer in some way or another. Second layer solutions heavily revolve around crypto-economic and game theoretical arrangements and alignments of incentives.
It is said that for Ethereum 2018 is the year of infrastructure. In what follows we’ll be giving a brief, high level summary of the taxonomy of second layer solutions while focusing on Plasma, one of the most talked about design space extensions, that appears to be an acceptable workaround to preserving the benefits of an open, permissionless blockchain as an institutional pillar on a global scale.
Raiden: State Channels or Ethereum’s Lightning Network
If a tree falls in the forest and no one is around to hear it, does it make a sound?
Lightning Network White Paper, authored by Joseph Poon and Thaddeus Dryja.
Lightning Network is the proposed solution for scaling Bitcoin and Raiden is an equivalent such proposition adapted to Ethereum. The flexibility of Ethereum’s built-in smart contract functionality, though, makes it much easier and straightforward to implement compared to Bitcoin’s highly limited scripting language that is strictly subordinate to Bitcoin’s purpose as a payments system.
Both Lightning Network and Raiden alleviate the consensus bottlenecks by leveraging off-chain state networks of inter-linked payment channels for securely transferring value off-chain — transfers within the payment channels are not observable on the shared global ledger and are as a result much faster (not confined by block confirmation times) and do not expend any gas.
In such a setting, instead of using the blockchain as the certified registrar for all transfers, the blockchain is only used as a system for dispute resolutions and settlement of netted claims from off-chain transfer activity (opening and closing of channels happens on-chain). As in Lightning Network, transacting parties sign transactions making them impossible to contradict later on upon escalating disputes or closing channels.
The state channel technology of Raiden is designed to supplement Ethereum in such a way so as to make it a globally scalable payment infrastructure usable for common everyday purchases and micro-payments.
Raiden uses a combination of an entangled labyrinth of payment channels, deposits and cryptographic maneuvers to allow for secure token transfers off-chain (notably, ERC-20 tokens). This approach allows the network to scale with the number of users and their transfers (the more users participate, the more transfers can take place concurrently) and as the network gets populated with channels forming between participants, they push confirmation times lower and lower.
The state channel technology of Raiden is designed to supplement Ethereum in such a way so as to make it a globally scalable payment infrastructure usable for common everyday purchases and micro-payments.
Similar to Lightning Network, its functional building block components consist of:
- On-chain deposits used to open up off-chain payment channels anchored to the blockchain via a smart contract.
- Bidirectional payment channels between transacting parties, one channel in each direction for each party, allowing for the sending of tokens back and forth and the re-adjustment of channel balances.
- Multi-hop transfers consigning payments across a system of payment channels. Multi-hop transfers take place by passing on hash locked transfers that are unlocked by a shared secret between sender and receiver once they reach their intended destination.
The RDN token is to be mainly used for off-chain machine-to-machine micro-payments on µRaiden (Micro Raiden) — a micro-payment channel framework for use cases that depend on recurrent, continual high-speed transfers. µRaiden is presently live on the Ethereum mainnet.
Simply explained, off-chain transactions allow a cluster of nodes to form a network of channels between each other to forward transactions, without directly involving the Ethereum main chain.
Reminiscent of Lightning Network itself and the lessons so far learned along the way, a Hackernoon post by the Raiden team regarding the Developer Release Preview dated from Sep 12, 2017 states:
Since the PoC-0 release, we have been further improving and implementing the protocol. During this time we have learned that payment channel network technology is even harder than anticipated, involving a complexity that goes beyond most common software development challenges.
Earlier this year we aimed to release a Minimum Viable Product (MVP) soon™. At some point however, we agreed that we should not call it “viable” until it is actually safe to use and deploy on the mainnet. So we switched the focus towards releasing a “Developer Preview”, in order to allow developers to get familiar with the API and characteristics of a payment channel network early on.
The Raiden Network documentation can be found here.
Plasma: Extended Hierarchical Sub-Chain Formations
Payment channels are one way to take the load off the main blockchain, but the same logic can be extended to launch child chains or transient micro blockchains that can be incorporated back later by using Ethereum smart contracts (which are, in essence, blockchain scripts).
Payment channels in Raiden and LN are set only between two participants, but for an arbitrary number of participants child chains or side chains can be unfolded from the main root chain, anchored in an on-chain contract that defines the rules, conditions and parameters of the side chain instance. The difference between payment channels and side chains is that the latter run a full blockchain protocol instead of a simple payment channel and one usually does not close them but intermittently publishes the current state to the main chain (say, once a day, amounting to the cost of one regular Bitcoin or Ethereum transaction).
Plasma, one of the most talked about second layer solutions, was first proposed by Joseph Poon (who also authored the Lightning Network paper) and Buterin as an approach that scales the main chain by offloading transaction throughput to child Plasma chains. The Plasma paper’s abstract states:
Plasma is a proposed framework for incentivized and enforced execution of smart contracts which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide. These smart contracts are incentivized to continue operation autonomously via network transaction fees, which is ultimately reliant upon the underlying blockchain (e.g. Ethereum) to enforce transactional state transitions.
We propose a method for decentralized autonomous applications to scale to process not only financial activity, but also construct economic incentives for globally persistent data services, which may produce an alternative to centralized server farms.
Plasma is composed of two key parts of the design: Reframing all blockchain computation into a set of MapReduce functions, and an optional method to do Proof-of-Stake token bonding on top of existing blockchains with the understanding that the Nakamoto Consensus incentives discourage block withholding.
Plasma is in essence a second layer mechanism for conducting transactions off-chain by recursively spawning child chains which have the capacity to form into hierarchical trees of side chains, nonetheless reliant on the underlying parent (and ultimately, the main — or root, in Plasma terms — blockchain) for their security. Different Plasma chains are optimized for different tasks and can be conceived as smaller, application-specific chains attached to the Ethereum blockchain that contribute computing power while getting in return the security and decentralization of the main Ethereum network.
Plasma is in a way a re-synthesis of the Lightning Network that takes advantage of Ethereum’s general computational capabilities (“smart contracts”) to refine the concept and test its applications in the wild. Each Plasma chain compresses messages about transaction sequences into a single hash periodically published on the root chain. The security of blockchains is usually derived from everyone computing the same thing at once, which in turn limits the extent to what is possible in terms of coordination/synchronization, since complex state transitions require costly computations to be carried out by an entire world.
In a blockchain, a state can be defined as a list of participants (accounts) and their respective balances at a certain point in time. A state transition is the changing of one state of arrangements to another, updated one.
In Plasma, side chains depend on the main chain for [economic] finality (as well as security) — similar to the reasoning in Lightning Network, if blockchains are deemed the ground truth of the world, then the amount of truth asserted to them should be limited, with different roles assigned along an elaborate multi-chain arrangement that directs behavior and organizes incentives along crypto-economic and game theoretical considerations.
Child chains as such are less secure and in the event of a large attack on Plasma sub-chains, all users of the Plasma sub-chains would need to withdraw back to the root chain through an exit mechanism. Also, in the event of dispute tokens can in like manner be retrieved on the root chain. Similar to Lightning Network, blockchains here can be seen a system of courts — child chains as distinct courts of appeal and the public Ethereum root chain functioning as a sort of a supreme court.
A Plasma exit works similarly to closing a payment channel in the Lightning Network, allowing users to fall back on the base layer main-chain.
Plasma is essentially an application-specific scaling solution allowing for blockchains to build on top of other blockchains in the process of differentiating their roles and dependencies while borrowing from the securitThe design goal of Plasma is to not only show that the blockchain can encompass a large part of the world’s financial transactions, but extend that design to general computation, engaging the main chain solely as a layer of public accountability. This should enable private parties and private blockchains to interact in a trustworthy manner.
This is done by a Plasma chain operator deploying a smart contract on to the Ethereum chain which allows him to launch his own specific application with explicit rules governing the custom Plasma chain (or tree of chains) that could subdivide therefrom (e.g., social networks, decentralized exchanges, private blockchains, etc.) A contract owner is included with the contract instantiation and the operator (owner) aggregates and orders transactions into blocks, committing a Merkle root hash of the Plasma block to the root chain contract (the Merkle roots of the trees of transactions together make up the Plasma block).
Merkle trees and Merkle roots
A Merkle tree (also known as a hash tree) is constructed by performing a hash function on each transaction in a block to get a resulting uniquely identifiable ID of each. The a hash is performed on the resulting pairs, then further on the subsequent ones and so on, until they meet in a single hash called the Merkle root.
A Merkle tree is a structure of hashed values for efficient data verification, the purpose of which (in a blockchain) is to be a signature of all transactions held within a block. A Merkle root is the hash of the whole Merkle tree.
Computation can occur off-chain while being enforcible on-chain by the Plasma chains periodically submitting the merkleized commitments about their state to the Ethereum mainnet (i.e., regular on-chain notarization). The design goal of Plasma is to not only show that the blockchain can encompass a large part of the world’s financial transactions, but extend that design to general computation, engaging the main chain solely as a layer of public accountability. This should enable private parties and private blockchains to interact in a trustworthy manner.
MapReduce: Cross-Chain State Transitions
Plasma also allows for constructing computations in a MapReduce format for efficient high scale computation across thousands of nodes. The Plasma paper states:
We propose a method whereby the map phase includes commitments on data to computation as input, and in the reduce step includes a merkleized proof of state transition when returning the result. The merkleized state transition is enforced via fraud proofs constructed on the root blockchain. It is also possible to construct a zk-SNARKs proof of state transitions.
MapReduce is a technique for doing computation by chunking big data into smaller pieces and Plasma allows for doing computations between states across chains via MapReduce — that is, merklizing the commitments of the states before and after the state transitions in order to produce proofs of those transitions, so it’s a provable MapReduce in a way (compact provable).
MapReduce is one of the core tricks in distributed computing — a technique originally invented by Google, it maps out the computation at hand and reduces it down to get the results.
MapReduce is a parallel processing technique for handling large datasets across a cluster of computers — it divides computation in two functions that sort the tasks in two phases, mapper and reducer.
Mappers split the data in chunks or shards depending on the categorization criteria — for example, months in an year, which results in 12 mappers getting data from each month and work on it at the same time in parallel, processing small fractions of data (as opposed to working out the whole year serially).
Mappers are essentially individual tasks that map input key/value pairs to a set of intermediate key/value pairs, transforming input records into intermediate records. Reducers then reduce the set of intermediate values which share a key to a smaller set of values.
It is important to highlight that Plasma is not a project but a design space authorizing custom implementations for specific applications. Every Plasma chain can have its own customized logic and evolve an ecosystem of its own, augmenting the capabilities of the root chain. There are currently three types of Plasma design implementations: Plasma MVP, Plasma Cash and Plasma Debit. The following article will give a short overview of each with examples of concrete implementations (e.g., in Omise Go, Loom, BankEx, etc.).
On the Plasma Series
This is the first of a 3-part series on Plasma by Marting Banov. In the next article, coming out August 25, we will be looking at Plasma implementations, specifically Minimal Viable Plasma, Plasma Cash, and Plasma Debit.
Disclaimer: information contained herein is provided without considering your personal circumstances, therefore should not be construed as financial advice, investment recommendation or an offer of, or solicitation for, any transactions in cryptocurrencies.
