"Currently, in all blockchain protocols each node stores all states and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can"[4].
The scalability trilemma claims that blockchain systems can only at most have two of the following three properties a) Decentralization b) Scalability and c) Security.
There are a few trivial ways to increase blockchain scalability in the base layer protocol. Unfortunately, whilst each of these "easy" solutions could improve scalability, they also introduce significant risks or negative effects on other parts of the blockchain infrastructure as described in the aforementioned scalability trilemma.
Sharding is an approach to solving blockchain scalability at the base layer protocol. Sharding aims to constantly split the state and history of the entire blockchain into K = O(n / c) partitions called "shards". In this formula K represents a shard, O represents complexity, n represents the size of the ecosystem (proportional to state size, transaction load and so forth) and c represents the computational resources (computation, bandwidth and storage). The sharding design is complex and faces many challenges. A base layer solution as complex as this could also have an impact on the systems consensus mechanism and as such, all participants could be required to participate in a coordinated software update as a result of the hard fork. For this and many other reasons, a base layer protocol solution to blockchain scalability will take a considerable amount of time to become production ready. But what about creating a solution using an off-chain (second layer approach)?
Plasma is a second layer blockchain scaling solutions whereby off-chain transactions between exclusive parties can occur. Plasma is a design pattern which allows you to create your own scalable blockchains (for example allowing blockchains to exist within blockchains) whilst still enjoying the advantages of the security (via the consensus mechanism) which is provided by the main chain. Put simply Ethereum’s Plasma implementation allows Ethereum to lend the proven security of its main chain to Plasma child chains. Those who are exchanging value on the Plasma child chain can exit to the parent chain if they feel that anything other than normal honest behaviour is happening on the child chain.
If you think about this topology you will realise that it provides exponential scaling for blockchains. The best real world example which comes to mind is population growth. For example great grandparent, grandparents, parents can each have many children. From a blockchain transaction validation perspective, only the validity of the child blockchains are stored on the parent chain, negating the need to store all of the gritty details of every transaction ever made.
Whilst costly, interactions with the main chain are only necessary when evidence of a dispute is provided. This evidence comes in the form of a proof. But who creates these proofs? How does anyone find out whether an invalid transaction is being performed? Put simply there are economic bounties which are offered to any users who can detect non-valid transactions. In addition to this you yourself, as a user, can watch your own tokens and provide an irrefutable proof of wrong doing (in the event that something goes awry).
This on-chain/off-chain incentive (reward and punishment) model is analogous to how TrueBit works. TrueBit allows untrusted parties (called solvers) on the Ethereum blockchain to solve computational tasks and in turn collect rewards. Of course on the flip side, anyone at all can challenge the outcome of a solver’s computational task. Incentives and consequences keep the solvers honest. These sorts of models run under the assumption that all parties involved wish to maximize their own profit. As a general rule, with accountability and penalties in place, most transactions will simply be performed in a valid manner.
Plasma is not a product!
Plasma is a design which is providing opportunities for anyone to implement their own customized logic of how they want to operate a temporary central off-chain operation which ultimately has the ability to perform a state transition on the Ethereum main chain.
Let’s step through a simple example of how this would work. A Plasma smart contract is deployed on the main Ethereum blockchain. The smart contract is the REAL history of Plasma chain blocks (represented by Plasma block transaction root hashes and UTXO root hashes).
- Deposit
-
Bob deposits ETH into the Plasma smart contract. This immediately gives Bob tokens on the Plasma chain (immediate - because if you recall the Plasma smart contract on the Ethereum main chain is where the real history of the Plasma chain resides).
- Transfer
-
Let’s say that another user Alice, who also joined the same Plasma chain, decides to send Bob some tokens on this Plasma chain. This transaction would be housed in a new block on the Plasma chain. The Plasma chain will then send only lightweight hash data to the Ethereum main chain (essentially a light-weight verification of this activity which Bob and Alice can see).
- Exit
-
If either Bob or Alice want to exit the Plasma chain (cash in their tokens on the Ethereum main chain), the person wanting to exit provides an exit request as well as a security deposit. The security deposit is a reward. A reward for anyone (including Alice) who can provide proof that the person exiting the Plasma chain is doing so maliciously (i.e. stealing money).
- Rewards
-
The reward incentivises all users to send a challenge transaction, in the event that they see any malicious activity. Alice’s client will notice bad behaviour by default (because it is watching its token balance; similarly to how we remember how much money is in our wallet when shopping - we notice when something does not seem right). Alice, or anyone/everyone incentivized to monitor malicious activity, can provide a challenge transaction BEFORE the challenge period is over. This may take up to 2 weeks. Remember that Plasma is only a design spec, so the length of this challenge period depends entirely on your implementation.
- The main chain knows the truth
-
The main Ethereum blockchain knows the truth, but will not actively investigate every tiny detail unless provided with a challenge transaction. If Bob (who initiated the exit) is lying about how many tokens he has on the Plasma chain, Alice’s challenge transaction (during the challenge period) will quickly be verified by the main chain. This will result in Bob’s exit request being cancelled, whereby Bob’s exit request’s security deposit will be rewarded to Alice (for providing a correct and truthful challenge request).
- How does the main chain know the truth
-
Perhaps one of the most interesting points about Plasma is that it does not keep a record of state changes (like the Ethereum main chain does). In the case of a dispute (Bob or Alice lying about how much money they gave each other during their time together on the Plasma chain) the Plasma implementation performs the following exceptionally intelligent and simple move. It checks all transactions on the Plasma chain starting with the "oldest first". This "oldest first" transaction ordering check is a key component of the exit request; the process starts from the start and as soon as the evidence of transaction history is aligned with someone who provided a truthful challenge request, that person is rewarded, the thief is punished and the Plasma chain is closed. Essentially all money is returned to its rightful owner by the Plasma smart contract.
Interestingly, in another design called More Viable Plasma, the idea of a new way to calculate exit priority was proposed. This new method of exit priority is called "youngest-input" priority. Instead of ordering exits by the age of the output, exits are ordered by the age of the youngest input.
One of the most promising designs was the Minimum Viable Plasma (MVP). In this design users would keep track of every token which was off-chain. This design used the unspent transaction output (UTXO) method to transfer value off-chain, meaning that each UTXO had to be tracked/monitored. There were a couple of issues with this design. Firstly, there was a bad mass exit vulnerability and secondly the transactions were still limited to around 1, 000 TPS.
Another design pattern by the Blockchain @ Berkley team was their own version of Plasma MVP called Plasma Cash. Plasma Cash "introduces non-fungible assets onto the plasma chain to allow for the sharded client-side validation". Plasma Cash has simplified the client side operation and essentially removed the two issues which we mentioned above (mass exit vulnerability & TPS limit). Plasma Cash utilizes the Cosmos SDK, a platform for building multi-asset Proof-of-Stake (PoS) blockchains.
The Blockchain @ Berkley GitHub has a separate repository for both a Plasma rootchain and a Plasma sidechain. The root chain documentation can be found at this link. Another implementation of Plasma Cash is the one by OmiseGO.
In the Plasma Cash design, users only have to keep track of the tokens which they are interested in. So how does a user know which particular tokens belong to them? Easy, all Plasma Cash tokens are assigned unique IDs (think of these as unique serial numbers) as they are moved from the main chain to the Plasma chain.
A Plasma Cash transaction takes on the following form.
[[prev_hash, prev_block, (target_block?), token_id, new_owner], signature]In Plasma Cash, transactions which are spending a coin need to be included in a specific location (in relation to the coin’s id). This is so that the users do not have to download all of the Plasma chain. Instead they just have to watch that specific location in the merkle trie which relates to a coin which they alone care about. This is powerful in terms of scalability but this also creates what could be considered a draw back. Plasma Cash requires that each coin (with its unique id) is kept whole. Coins can not be split. For this reason Plasma Cash works like money in the real world where you can not snap a $1 coin in half and send it to 2 different people as payment for 2 separate 50 cent items. The power of this system comes into play when you (the coin owner) wants to check that your coin has no issues. If you know that you accepted the coin at block number 100 and you can see that your coins index in the merkle trie only has empty data, this provides a proof called "proof of non existance".
The Plasma MVP design has the overhead of n * t whereby n is the Plasma blocksize and t is a tick (in terms of elapsed time; think of t as counter for each new block i.e. number of elapsed blocks). Plasma Cash present efficiency of approximately c * t * log(n / c), where c is how many coins (with unique ids) you have (and want to watch).
Consider the following
coins held, c = 20
number of blocks, t = 200
plasma block size, n = 1000 bytes*Plasma MVP*
n * t
1000 * 200 = 200KB*Plasma Cash*
c * t * log(n / c)
20 * 200 * log(1000 / 20) = 6.795KBWe mentioned proof of non existence before, the software mechanism which provides this efficiently is known as a bloom filter. Bloom filters can provide certainty in relation to proof of non-inclusion. In contrast, Merkle tries provide certainty in relation to proof of inclusion. We will talk about Merkle tries shortly.
Each block in the Plasma chain publishes its own Merkle root to the main chain. What this means is that essentially hundreds or thousands of transactions can occur on the Plasma chain, yet only a minuscule amount of information (relative to the complete transaction history) is actually stored on the main chain. Think of the Merkle root as a proof of inclusion.
"This root can either be a merklized list, or a merkle patricia tree. In the merklized list, each index of the leaf nodes corresponds to the token ID." [2]
Merkle tries provide certainty in relation to proof of inclusion. Merkle Tries have been in use on most blockchain implementations including Bitcoin. Ethereum extended the original idea and ultimately created the Merkle Patricia Trie. Interestingly, it seems that there is yet another improvement in the Merkle Trie space which looks set to replace Ethereum’s current data structure and provide superior efficiency and simplicity.
A new data structure, known as the Efficient Sparse Merkle Trie will assist in blockchain scaling. Also languages which are simpler and safer than Solidity will be good candidates for writing and testing this new data type and in addition exclusion and inclusion proofs, which support scaling solutions. For example Vyper’s pythonic syntax already provides a head start to developers who are interested in writing smart contracts which will one day be enveloped by Ethereum’s alternative data infrastructure. Ethereum currently uses the complex Merkle Patricia Trie, however Vitalik has recently demonstrated via code that the Sparse Merkle Trie has the potential to surpass Ethereum’s current data infrastructure in efficiency and simplicity as well as storage and bandwidth.
The original spec for Plasma Cash mentioned the following improvements (over MVP): "1. Every single deposit corresponds to a unique coin ID; tokens are indivisible and cannot be merged." "2. Instead of storing transactions in a binary Merkle tree in order of txindex, we require them to be stored in either a sparse simple Merkle tree or a patricia tree, with the index being the ID of the coin that is spent."
- Hashes
-
Think about bank notes and coins, except because these are digital tokens imagine that we can create new tokens, on our Plasma chain, via a merge. Merging tokens together is easy, merged tokens are simply represented by a 32 bit ID (aka a hash). Interestingly the new 32 bit ID (hash) is simply a hash of the original 32 bit IDs belonging to each of the two unique tokens which are being merged together.
- Slots
-
Imagine that all tokens have to live in slots. When tokens on a Plasma chain are created they go off and live in a specific unique slot. The important thing to remember here is that every time there is activity, there are new slots. For example, if token "a" from slot "A" is merged with token "b" from slot "B" then resulting merged token will go off and live in a brand new slot "C"; both tokens move out of slots A and B as part of the merge process.
- Efficiency
-
We mentioned earlier that in Plasma Cash a user can be safe on the network by only watching tokens which they care about; tokens which are of value to the user. This means that a user can literally ignore the entire network aside from their own tokens. But surely the users would have to scan through millions of token IDs on the main chain in order to filter out the token IDs which they care about right? Yes, however the Sparse Merkle Trie approach cleverly organises the 32 bit IDs in a way that a user only need be on the look out for token IDs which start with the number 3 or the number 4 etc. The structure of the data type allows the user to ignore the entire set of IDs except for a tiny set (say, starting with 3) which they can then traverse. Every 32 bit ID is a new slot in the Trie.
State Channels and Plasma both exist to improve the scalability of blockchains, by taking transactions off-chain. The key differences between State Channels and Plasma are as follows. A single State Channel is made up of a set of participants. Those in this "participant set" exchange value amongst each other via ongoing (step-by-step/real-time) unanimous consent. Nothing is published to the main chain until participants are ready to exit and State Channel (at the end). Plasma also has a participant set, and in addition, a validator set. Unlike a State Channel, Plasma actually publishes its block headers to the main chain. The Plasma block headers provide a mechanism for the main chain to prove or disprove dishonest behaviour; in the event that someone issues a challenge. Under normal (honest) operating conditions the main chain does not play a role (other than receiving Plasma block headers). In short, Plasma design patterns allow for external participants to partake in interactive games (rewarding those who successfully challeng dishonest behaviour), whereas state channels are designed to be a real-time exchange of consent between only the participants who are exchanging value.
Lightning is an open protocol, one which can best be described as a set of specifications or design patterns for improving the scalability of blockchains. The Basics of Lightning Technologies (BOLTS) are defined inside separate specification documents[3]. These documents include specifications around transactions, routing and payment encoding, to name a few.
costPerTx = (2*onChainFee)/nTxs
For example if the onchain cost per transaction was at $3.00, the cost for one, two, six and twelve transactions on the lightning network would be as follows
$6.00 = (2*3)/1
$3.00 = (2*3)/2
$1.00 = (2*3)/6
$0.50 = (2*3)/12
Lightning is cheaper than the main chain transactions IF it is used more than twice
The BOLTS are designed to guide developers with their own concrete software implementations of Lightning Applications (lapps). There are many lapps available today [4].
Projects like Connext [5] are building Solidity contracts to facilitate the transfer of ETH and ERC20 between account addresses.
Whilst in theory base layer solutions such as Ethereum’s Sharding are said to be complementary to second layer solutions such as Ethereum’s Minimum Viable Plasma implementation. In theory it can also be said that there are potential issues between the interoprability of base and second layer solutions. Consider the following scenario. A user has 80% of their coins inside Lightning or Plasma. The main chain undergoes a hard fork. What coins will the user receive on the forked network? Similarly, in the case of a hard spoon (Cosmos) or a freeze (EOS) what coins will an off-chain (Plasma or Lightning) user be airdropped? This is an interesting question because ownership in a side chain or state channel is not reflected on the main chain at a given point in time.
There is a reoccurring theme around the availability problem (block withholding problem) in Plasma. In addition, while there are a lot of clever designs and great ideas about exit games, it appears that the size and complexity of these smart contracts is growing to a potentially untenable level.
Also the conversation about context (Solidity’s DELEGATECALL vs Vyper’s CALL) in a game’s smart contract is also very interesting. It seems that the context element required to engage in interactive games on the main chain has been removed by safer smart contract languages which aim to provide protection and security.
The future design can include a network activity nonce. The network activity nonce must be fetched before any and all activity. By fetching an activity nonce, the participant is signaling and declaring their intent to perform that particular action/transaction/validation. In the event that the participant does not perform that certain network activity (due to deliberate or accidental circumstances) the design has the ability to annul that specific queued network activity and nonce.
A participant’s privilege to fetch nonces is relative to the total amount of participants, in a way which is fair. Of course fetching and withholding will sharply reduce a participant’s fetching privileges (relative to other participants). Alternatively, fetching and correctly executing could increase a participant’s privileges.
The design of Lightning provides trust-less blockchain functionality off-chain. Its use of CHECKSEQUENCEVERIFY to measure relative minimum age revolutionises off-chain consensus and finality.
A hard-spoon takes the account state from a main chain (like Ethereum) and creates a genesis state for a new chain. This process of freezing/snapshotting/spooning allows a new blockchain to inherit the main chain’s account balances, “as at” a particular point in time. Real world examples of this would be EOS and Cosmos.
With the advent of state channels and side chains, how could we ensure that the state of a given second layer implementation (as at a particular point in time) is reflected in the snapshot/hard-spoon?
For example, in the event that we are able to transfer ERC20 tokens inside state channels [1], how could we ensure the accuracy of token Airdrops; when tokens are tied up in state channels and not accurately visible in the main chain’s state?
Does the hard-spoon process need to evolve or can the second layer solutions provide their state as required?
If neither of these are achievable, will well known hard-spoons which offer significant value have an effect on activity within second layer solutions? Might we see mass exits to the main chain during snapshots/hard-spoons?
Below is an list of Ethereum related second-layer side-chain designs which are currently undergoing development on GitHub.
[Cosmos, Peg Zone Implementation](https://github.com/cosmos/peggy)
[Taiwan Team, Javascript implementation of Plasma MVP](https://github.com/ethereum-plasma/plasma)
[Blockchain at Berkeley, Plasma Debit](https://github.com/FourthState)
[Loom Network](https://github.com/loomnetwork/plasma-erc721)
[OmiseGO Plasma Cash - GitHub Repository](https://github.com/omisego/plasma-cash)
[OmiseGO Plasma MVP - GitHub Repository](https://github.com/omisego/plasma-mvp)
[Voltaire Labs](https://github.com/voltairelabs/plasma)
Please note: The list is in alphabetical order (based on the GitHub account which houses the code)
In contrast, Lightning potentially offers routing which means that anyone can pay anyone, regardless of what channel they are in.
Transferring value to someone who exists inside a Plasma chain actually creates a scalability problem.
For example joining the Plasma chain and then transferring the funds and then exiting back to the main chain is more complex and time consuming than just transferring the value on the main chain in the first place.
In the case of Plasma Cash, not being able to split value means that if a user with a single 10 token UTXO wants to send 7 tokens to another user. The recipient of the 7 tokens must provide 3 tokens change. If the recipient does not have 3 tokens they can not do business. Both the sender and the recipient have to have the exact money which is not practicable in a real setting as this would cause each user to deliberately store a kitty of change just in case they need to provide change (this means that users are creating more transactions, in anticipation, than would ordinarily have to if they were just operating on the main chain where value can be split to any denomination)