Ethereum Classic

Scalability and Privacy via Layer 2 Solutions

“Layer 2” is a word that has been thrown around quite often nowadays. In simple terms, this is an added layer built on top of the blockchain which imparts scalability and privacy. In this guide, we are going to look at these various scalability tools and see how it is going to help us in the long term. However, before we do so, we need to look at some of the existing scalability and privacy concerns in the blockchain.

Current Scalability Problems

The main problem that Bitcoin was facing (and still facing) was “scalability.” Back when Satoshi Nakamoto created Bitcoin, he was forced to impose a 1 MB limit on the Bitcoin blocks. He envisioned that Bitcoin blocks may get filled with spam transactions and that would lead to DoS (Denial of Service) attacks.

While the block limit may have worked, unfortunately, this led to a problem. Bitcoin became popular! And as a result, it just didn’t have the provisions required to keep up with the increasing demand. Check out this graph (via

That graph shows the increasing amount of transactions per month since 2009 and as you can see, the increase has been pretty drastic. Now, this is obviously good news, right? After all, it just goes to show that more and more people are getting into this space and that cryptocurrencies are getting the mainstream condition. However, what this has unfortunately led to is a decrease in the speed of the overall system.

Bitcoin’s and a part of Ethereum’s utility is as a payment protocol. As such, it is only fair that we compare them to other similar and popular payment protocols. Think of mainstream payment protocols like visa and PayPal. While Visa manages a whopping 1667 transactions per second, Paypal still manages to do a respectable 193 transactions per second. So, how do you think Bitcoin and Ethereum do in that regard?

Well…Bitcoin does a miserable 7 transactions per second while Ethereum manages 20. Now, these are certainly not good numbers and they are really not going to help cryptocurrencies in the long run. The only way that these numbers can be improved is if they work on their scalability.

If we were to categorize the main scalability problems in the cryptocurrencies, they would be:

  • The time it takes to put the transaction inside the block
  • The time that it takes to reach a consensus.

The Time Taken To Put A Transaction In The Block

When you deal with fiat currency, you can simply conduct transactions by physically sending money to one another. However, that is not really the case with digital currencies like Bitcoin and Ethereum. In these cryptocurrencies, we have people called miners who actually put the transaction details in the blocks that they have mined for them to go through.

So suppose Alice wants to send 4 BTC to Bob, she will send this transaction data to the miners, the miner will then put it in their block and the transaction will be deemed complete.

Seems pretty straightforward right? However, this is where we face another problem.

As Bitcoin becomes more and more popular, this becomes more time-consuming. Also, there is another issue that one should take note of, transaction fees. When miners mine a block, they quite literally become temporary dictators of that block. In return for putting transactions in them, they charge a “toll” called transaction fees.

The higher the transaction fees that you pay, the faster your transaction will get processed by the miners. This may not be the best proposition for people who don’t have a high supply of bitcoins. In fact, check out this graph:

If you pay the lowest possible transaction fees, then you will have to wait for a median time of 13 mins for your transaction to go through.

Also, remember another thing. Bitcoin and Ethereum need to account for block production time as well. Bitcoin has a block production time of 10 mins while Ethereum does it in 15 seconds. So, more often than not, one may actually have to wait for the block to be mined for their transaction to go through.

There is another thing that hinders the number of transactions that the blocks can actually hold, and that is the block size. Bitcoin, as we have mentioned above, has a 1 MB block size which limits its transaction carrying capacity.

Ethereum doesn’t have a “defined” block size and a new block gets mined every 15 seconds. So it must be doing pretty well right? Unfortunately, that doesn’t seem to be the case.

Each and every block in Ethereum is limited by a gas limit of 6,700,000 and each transaction costs 21,000 gas, you can see that there is a limit here as well.

So, one debate that has raged on in Bitcoin is, why not simply raise the block size?

This single question has pretty much ripped the Bitcoin community apart. There is one group that feels that increasing the block size without looking at proper innovations is a folly while there is another group that feels that increasing the bitcoin block size is the correct way to go forward. However, even if you just increase the block size 2X or 4X or 10X, the increase in the number of transactions is only going to be linear and not exponential. Meaning, a 10X block size increase will increase the transaction number 10 times, which in bitcoin’s case will be ~70 transactions per second, which is still not good enough.

Let’s take the example of Bitcoin Cash, which forked from the original Bitcoin protocol and increased the block size to 8 MB which is an 8X increase. Bitcoin cash can handle ~62 transactions/ second which is roughly 8X that of Bitcoin.

These limitations when it comes to scalability has seriously hampered the Bitcoin and Ethereum blockchains. Never was this issue more evident during the Cryptokitties fiasco.

In case you didn’t know, Cryptokitties is a popular game built on the Ethereum blockchain which allows its users to buy and nurture digital cats. Think of Pokemon on Ethereum. This game became so popular that it pretty much broke the Ethereum blockchain. Because of the increasing demand for the kitties, the number of unconfirmed transaction on the blockchain increased exponentially.

Because of this, Axiom aka the company behind cryptokitties was forced to increase their birthing fees. In an announcement they said:

“The excitement and adoption we’ve seen this week has been overwhelming and we couldn’t be happier! However, the Ethereum network is completely full. The only way to keep CryptoKitties from lagging is to increase the gas prices so that all transactions can complete quickly. We know that increased prices will mean that some of you will need to slow down your breeding regimen, and we are incredibly disappointed by that. But who knows? Maybe this slowdown will just mean that you’ll love the Kitties you already have that much more”

In fact, things became so bad that some ICOs were forced to delay their release. SophiaTX, for example, had to delay their ICO because of how much the game clogged up the blockchain.

Privacy Problem of Cryptocurrencies

What you see above is the Electornic cash triangle. According to it, an ideal Electronic cash should fulfill three requirements:

  • It should be electronic.
  • It should be decentralized
  • It should be private.

While cryptos like Bitcoin and Ethereum are electronic and decentralized, they are not really private are they? The reason being the very design of the blockchain technology.

The blockchain technology was designed to be transparent so that the chances of fraudulent transactions goes to a bare minimum. A lot of industries, such as food transportation, have adopted the blockchain just for this property alone.

However, this doesn’t really lead to a perfect currency system now does? Let’s look at some of the reasons why privacy is desirable.

Reason #1: Privacy is a right

Why should you be forced and shoehorned into showing your transactions to everyone?

Reason #2: Your currency is yours

You have complete control over your transactions. You are responsible for your money. Because your identity is private no one will be able to see what you are spending your money on.

Property #3: Privacy leads to Fungibility

Another interesting property that it gains, thanks to its privacy, is that it is truly fungible. What is fungibility? Investopedia defines fungibility as follows:

“Fungibility is a good or asset’s interchangeability with other individual goods or assets of the same type.”

So, what is fungible and what is non-fungible.

Suppose you borrowed $20 from a friend. If you return the money to him with ANOTHER $20 bill, then it is perfectly fine. In fact, you can even return the money to them in the form of 1 $10 bill and 2 $5 bills. It is still fine. The dollar has fungible properties (not all the time though).

However, if you were to borrow someone’s car for the weekend and come back and give them some other car in return, then that person will probably punch on the face. In fact, if you went away with a red Impala and came back with another red Impala then even that is not a done deal. Cars, in this example, are a nonfungible asset.

So, what is the deal with fungibility when it comes to cryptocurrency?

Let’s look at bitcoin for example. Bitcoin prides itself in being an open ledger and an open book. But what it also means is that everyone can see the transactions in it and more importantly, everyone can see the trail of that transaction. What this basically means is that suppose you own a bitcoin which once was used in some illegal transaction, eg. buying drugs, it would forever be imprinted in the transaction detail. What this in essence does is that it “taints” your bitcoin.

In certain bitcoin service providers and exchanges, these “tainted” coins will never be worth as much as “clean” coins. This kills fungibility and is one of the most often used criticisms against bitcoin. After all, why should you suffer if one of the previous owners of your bitcoin used it to make some illegal purchases?

This is why privacy solutions are desirable. Since all the data and transactions will be private, no one can know what transactions your crypto has gone through before and neither can they know what was used to buy with your crypto. Since its transaction history can never be known, it also means that the “transaction” trail is non-existent. As a result of this, the concept of “tainted” coin and “clean” coin doesn’t exist, and hence they are fungible!

This is where the layer 2 solutions come in. Layer 2 solutions will create a layer above the underlying blockchain network. By taking the transactions off chain it will help in making the system more scalable. Plus, since these channels are off-chain, none of the transactions that are happening in it are going to be broadcasted to the entire blockchain. Because the data won’t be on the blockchain, it will remain private.

In this guide we are going to be focussing on the following layer-2 solutions:

  • Lightning Network
  • Raiden Network
  • Plasma
  • Truebit

We are going to start off with the most popular layer 2 solutions out there, Lightning Network, and its Ethereum equivalent, Raiden.

Lightning Network

The lightning network, conceptualized by Joseph Poon and Tadge Dryja, has been long touted as the solution to all of Bitcoin’s scalability issues, and Litecoin has been one of the many projects that are working on it. So what is the lightning network? Let’s give you a brief overview first.

Two people, let’s say, Alice and Charlie, open a state channel between them and exchange as many coins as they want between them OFF THE BLOCKCHAIN. When they are done making the transfers, the final state of the transaction is put on the main blockchain.

Before we start, let’s understand what state channels mean. A state channel is a two-way communication channel between participants which enables them to conduct interactions, which would normally occur on the blockchain, off the blockchain. So, what this eventually does is that it exponentially reduces the time taken for a transaction to go through.

Can you guess why?

When you create a state-channel between two parties. they can engage in an infinite (theoretically speaking) number of microtransactions between themselves without interacting with a blockchain. Since everything is happening off-chain, the miners only need to put the final state of the channel into the blockchain.

So what are the requirements to do an off-chain state channel?

A section of the blockchain state is locked up via multi-signature or some sort of a smart contract and it is agreed upon by a set of participants. These participants interact with each other without submitting any data to the miners. As we have stated earlier, the final state is presented to the miners and added to the blockchain.

The state channels can be closed at a point which is predetermined by the participants via one of the following methods:

  • Either the participants can agree beforehand to close the state channel after a given amount of time has lapsed.
  • Or, it could be based on the total amount of transactions done eg. close the chain after $1000 worth of transactions have taken place.

To understand the concept of state channels using a real-life (sorta) allegory. This example and the following diagram was presented by Stephen Tual.

Look at the image above.

So, you have an electric car which has opened up a state channel with an electric charger to do $39.19 worth of total transactions. When these series of transactions are done, the final state is added to the blockchain. Now can you imagine how much time it would have taken if they had to run every single transaction through the blockchain?

Important Features of State Channels

State channels are useful in many applications, where they are a strict improvement over doing operations on-chain. Having said that, they are not without their limitations. Let’s look at some of the features and limitation of state channels.

  • State Channels are reliant on availability. So, if Alice is taking part in a state channel and she loses her internet connection at that very moment, she might not be able to upheld her role in the channel. Having said that, it could be possible for her to pay someone to maintain availability on her behalf.
  • State channels are the most useful when participants are going to be exchanging many state updates over a long period of time.
  • State channels are best used for applications with a defined set of participants.
  • State channels have extremely high-quality privacy properties because everything is happening “inside” a channel between participants, rather than broadcast publicly and recorded on-chain. Only the opening and closing transactions must be public.
  • State channels have instant finality, meaning that as soon as both parties sign a state update, it can be considered final. Both parties have a very high guarantee that, if necessary, they can “enforce” that state on-chain. We will cover privacy in more details in a bit.

Payment Channels

A payment channel is basically a form of state channel which deals only with payments and micropayments between different parties and participants. There are several kinds of payment channel designs. In fact, one of the earliest examples of a payment channel implementation was suggested by Bitcoin founder Satoshi Nakamoto himself. His payment uses the following features:

  • Transaction Replacement
  • Input sequence numbers (nSequence)
  • nLocktime

Ok so we have variables like nSequence and nLocktime, what exactly do they mean?

“nLocktime” is the parameter which defines the time before which the transaction couldn’t be accepted into the block. Along with that, there is a value called “UINT_MAX” and the nSequence cannot exceed that number. So, basically, if there is an unconfirmed transaction, one can keep changing it before:

  • Either the nLocktime runs out
  • Or the nSequence becomes equal to UNIT_Max.  Everytime the unconfirmed transaction changes, the nSequence increments to a higher value.

While this sounds good on paper, there were a lot of security issues and it was never properly executed. Having said that, let’s look at some more implementations of the payment channel.

However, before we do so, there is a small detour we need to take. We need to know what a multi-sig P2SH address means and does.

Bitcoin Addresses

There are two kinds of addresses in Bitcoin:

  • P2PKH address aka Pay-to-PubKey Hash address.
  • P2SH address aka Pay-to-Script Hash address.

A “normal” Bitcoin P2PKH address looks like this: “15fXdTyFL1p53qQ8NkrjBqPUbPWvWmZ3G9”. So, if someone were to send you Bitcoins on your P2PKH address, you can simply unlock it and gain access to them by entering your private key.

However, this is a simplistic version of Bitcoin transactions, they can be a lot more complicated than this. This is something that Bitcoin users found out early on when they started fiddling around with the “scriptPubKey” in Bitcoin’s Script Language.

So, what exactly is this scriptPubKey?

This is what a simple 1 input and 1 output transaction looks like:

“vout”: [


“value”: 0.01200000,

“scriptPubKey”: “OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG”



The “scriptPubKey” in the transaction above shows you the transaction conditions. All these conditions need to be met in order for the transaction to go through. So, if you want to add more complications to your transactions, you can add your own lines of code to the scriptPubKey and define the spending condition yourself. However, as you can imagine, if you put in more and more scripting conditions then you are probably going to clog up the entire transactions.

The core developers foresaw this happening and to prevent spenders from putting in long lines of code in the conditions, they enabled them to just put in hashes of their conditions instead. These “conditions” are called “redeem script”. In a P2SH transaction, the scriptPubKey only contains the hash of the redeem script. The script itself is only revealed and verified during the spending part of the transaction.

Because the script verification happens in the spending part, it completely removes the responsibility of providing the full redeem script from the sender to the receiver and this opens it up to a multitude of advantages:

  • The sender can send money to any multisig transaction without knowing the full details of the transaction. This helps impart some much-needed abstraction. Think about it, when you spend your money, do you rarely care about what is going to happen to it after you have handed it over. That is, in essence, what abstraction means. Keeping the whole process simple by taking away the complications.
  • Plus, to state the obvious, it is much simpler and straightforward for senders to send money to short and well-defined hashes aka script hash instead of long and confusing scripts.

So that is a general explanation of what a mutisig P2SH address is. in other words, it is an address that pays to a script hash instead of a public address. So, now that our detour is over, let’s go back to payment channels now shall we?

The 3 Kinds of Payment Channels

We are going to focus on three specific kinds of payment channels:

  • The Spillman-Style payment channel
  • The CLTV-Style payment channels
  • Hashed Timelock contracts

The Spillman-Style Payment Channel

The Spillman-Style payment channel was described in the bitcoin development mailing list and was implemented in “bitcoinj”. The Spillman-Style uses two separate transactions, the deposit, and the refund. Let’s take a look at how this process will work?

  • Alice (the merchant) gives her public key to her customer aka Bob
  • Bob will then use his public key and Alice’s public key to create a unique multisig P2SH address which will enable the funds to be spent if and only if Alice and Bob sign in with their signatures.
  • Bob now creates the transaction, however, he doesn’t transmit it to the blockchain yet. He uses the transaction to pay the multisig address and the transaction is the deposit which establishes it.
  • Bob now creates a second transaction which is the same as before and uses that to overwrite the previous transaction. As a result of this, the first one goes back to Bob’s address. Bob then declares a timelock on the second transaction to make sure that it doesn’t get inside the block before a specific amount of time and signs it.
  • Bob gives this second transaction to Alice who then proceeds to sign it and return it to Bob. Remember, Alice still hasn’t seen the Deposit transaction i.e. the first transaction yet.
  • Now, Bob has a transaction which has been signed by both him and Alice and acts as a refund. So if Alice, the merchant, doesn’t a do a particular job before the timelock runs out, Bob can claim the refund transaction for himself.
  • Now that the refund has been signed off on by all the parties present, Bob can safely declare his deposit transaction and add it to the blockchain.

So, the Spillman-Style is, on paper, an extremely useful way to create a payment channel which would keep the merchants honest. However, this method is vulnerable to transaction malleability (which we will cover later). Also, the deposit transaction which is broadcasted by Bob has to be byte-for-byte same as the refund transaction. If it isn’t the refund transaction is no longer valid.

The CLTV-Style Payment Channels

Because of all the problems of the Spillman style payment channels, the CLTV-Style Payment channels were implemented post-BIP 65. 

So, how exactly does this work?

  • Alice (The Merchant) gives her public key to Bob (the customer)
  • Bob then, quite similarly to Spillman-Style, uses his and Alice’s public keys to make a P2SH address using these following conditions:a) Both Alice and Bob need to sign on any transaction that happens through this address
    b) Bob has the power to sign on any transaction on his own, however, for those transactions, the lock time has to be greater than the refund deposit.
  • Bob immediately creates a deposit transaction and broadcasts it on the blockchain. Because of condition 2 above, he is assured of the fact that he can pretty much generate a refund on demand.
  • Also, do you remember how the first condition explicitly states that both Alice and Bob need to sign on any transaction that happens around the P2SH address. Because of this, Bob and Alice both sign their part of the transaction without revealing their part of the signature details. Because of this, Alice can broadcast the final payment to the blockchain before a refund can be broadcasted to prevent any chances of fraud.

So, what is the advantage that CLTV has over Spillman Style? By removing any chances of transaction malleability. In the Spillman style, Bob needed to broadcast a deposit which matched the refund byte for byte. Because of this, it made it vulnerable to malleability. The CLTV channel uses the “OP_CLTV opcode” to counterattack this issue.

Hashed Timelock Contracts

Hashed timelock contracts or “HTLCs” are one of the most convenient applications of the payment channels. In fact, the Lightning Protocol is an implementation of the HTLC. So, what is an HTLC? Till now we have seen channels which use “timelocks”. An HTLC “extends” that by introducing “Hashlocks” along with the timelocks.

Because of HTLC, one can open payment channels off the Bitcoin blockchain where parties can agree upon a preset deadline and then engage in innumerable microtransactions. The payments are also acknowledged between parties via the submission of cryptographic proofs. Along with these, HTLCs have two major advantages:

  • Firstly, it allows for cross channel transactions.
  • Secondly, it allows the parties to forfeit the payment given to them and return it to the payer.

Plus, there is another amazing feature that comes in thanks to the HTLC. It makes cross chain transactions possible. This is called atomic cross chain trading and enables users to exchange a part of cryptocurrency on one chain (eg. bitcoin on the main blockchain) for a part of cryptocurrency on another chain (bitcoin on a side chain).

Ok, now let’s go into the details.

The lightning network, as we have mentioned before, is based on HTLCs aka Hashed Timelock Contracts. Let’s see how it works. Imagine Alice wants to send some bitcoins to Charlie, and they both have Bob in common.

  • Alice opens a channel with Bob and Bob opens a channel with Charlie.
  • Alice declares that she wants to pay Charlie 0.01 BTC.
  • Charlie declares a random string S and generates its hash H and hands it to Alice.
  • Alice sends Bob the hash H and they open a multi-sig channel between them. The conditions of the channel are:
    a) Bob gets the 0.1BTC if and only if he can show Alice the string S from which the H is derived.
    b) There is a nLocktime of 2 days wherein, if Bob cannot produce the string then Alice gets a refund of 0.01 BTC.
  • Bob then shows the hash H to Charlie, proving that he has interacted with Alice and they proceed to open a multi-sig channel between them with the following conditions:
    a) Charlie gets 0.01 BTC if and only he shows Bob the String S from which the hash H has been derived.
    b) There is a nLocktime of 1 day (less than the locktime of the Bob-Alice channel) wherein if Charlie can’t produce the string then Bob gets a refund of 0.01BTC.
  • If Charlie produces the string S then Bob sends him the 0.01BTC.
  • Similarly, Bob shows Alice the string S and gets the 0.01BTC from her.

Charlie Lee tweeted on 1st September 2017 that he did the first ever Litecoin Lightning Network payment.

As Jimmy Song notes in his medium article:

“The Lightning Network works by creating a double-signed transaction. That is, we have a new check that requires both parties to sign for it to be valid. The check specifies how much is being sent from one party to another. As new micro-payments are made from one party to the other, the amount on the check is changed and both parties sign the result.”

So, what exactly are the advantages of the lightning network:

  • Near instantaneous payments
  • Since the transactions are completely off-chain, the miners don’t need to get involved with them (at least till the final state)
  • Microtransactions used to be extremely inconvenient earlier because of the elongated wait time and transaction fees. The lightning network is going to be extremely microtransaction friendly
  • It is multisignature friendly because the transactions will go through if and only if all the participants in the channel sign off on the transaction
  • With so many transactions happening off-chain, it greatly decreases the load the main chain will have to take.
  • Since there is no miner intervention, the waiting time is greatly reduced.
  • The number of transaction happening per second increases exponentially, hence the entire network becomes scalable.

Having said that, the lightning network does have its challenges.

Lightning Network Implementation Challenges

A scalability technique that actually has the potential to scale bitcoin exponentially rather than linearly is the lightning network however that again has its own detractors (a pattern, that we are sure, you have pretty much identified by now). The lightning network is an off-chain scaling solution, which creates a Hashed Timelock Contract (HTLC) between the participants so that they can engage in a lot of microtransaction without committing anything inside a block. Since this is done off-chain without the intervention of miners, it can theoretically scale Bitcoin up to thousands of transactions per second. Ethereum is also planning to implement their own version of the lightning network called “Raiden.”

Unfortunately, the lightning network is vulnerable to transaction malleability, where a hacker can potentially manipulate the signature data and hence mess up the transactions.

So, to understand transaction malleability, one must know about one of the most important properties of cryptographic hash functions. They change drastically even if the inputs are changed by a slight amount. Check this out. Let’s input some data into the SHA-256 hash function and show you what we are talking about:

If we input “strictlycrypto” we will get


Let’s just change the case of “c” and see what strictlyCrypto as an input generates:


See, how much the hash changed even though we changed the case of just one alphabet?

Because of this property, the blockchain is immutable. So all the data that goes inside blockchain can’t be changed. However, what happens if someone tampers the data before it goes inside the blockchain? Because of the immutability, it won’t be able to change the tampered data either.

The way it can happen in a Bitcoin transaction is by signature manipulation.

Let’s see this in an example.

Suppose Bob wants Alice to send him 1 BTC. Alice initiates a 1 BTC transaction to Bob’s public address and then sends it over to the miners for approval. While the transaction is waiting in the queue, Bob uses transaction malleability to alter Alice’s signature and change the transaction ID.

Now there is a chance that this tampered transaction will be approved before Alice’s gets approved, which in turn overwrites Alice’s transaction. When Bob gets his 1 BTC, he can simply tell Alice that he didn’t get the 1 BTC that she owed him. Alice will then see that her transaction didn’t go through and will them resend it. As a result, Bob will end up with 2 BTC instead of 1 BTC.

Now, let’s get it straight, the lightning network won’t be completely destroyed due to malleability. However, it can make the entire experience very slow and annoying. These tampered transactions will get stuck at various steps in the channel. The only way that this can get resolved permanently is by:

  • Trusting the participants
  • Setting up timeouts

There is a lot of reason why this is undesirable:

  • The timeouts can become annoying.
  • Any system that is built on trust is corruptible.

In order to implement it, and take transaction malleability out of the system, Bitcoin needed to activate segwit, which puts these signature data in a sidechain running in parallel to the main chain. The problem with other cryptocurrencies activating segwit are:

  • Setting up sidechains adds more complications.
  • Segwit has not been unanimously accepted by the community. In fact, its critics say that it is more of a band-aid than an actual improvement.

So, this is where we stand with scalability right now. We have solutions, but the solutions required changes made to the original blockchain architecture of the coin which may not be the most ideal solutions in many cases. Ideally, we would want a solution that can exponentially scale Bitcoin or other cryptocurrencies up without changing its architecture.

Raiden Network

While Bitcoin has the Lightning Network to take care of its microtransactions, Ethereum has the Raiden Network. The thing is that, quite like Bitcoin, Ethereum is really not practical for microtransactions. So, the Raiden Network takes these transactions off the blockchain and removes any kind of miner involvement altogether.

A Raiden balance proof is a binding agreement enforced by the Ethereum blockchain. Digital signatures make sure that neither party can back out of any of the value transfers contained therein, as long as at least one of the participants decides to present it to the blockchain. Since nobody else other than the two participants has access to the tokens deposited in the payment channel’s smart contract, a Raiden balance proof is as binding as an on-chain transaction.

Raiden will be structured like a mesh on top of the Ethereum main chain.

Raiden was conceptualized by Brainbot technology. Heiko Hees, founder/CEO Brainbot technology said about Raiden, “Basically all blockchain-based applications that want to scale to real-world usage will benefit from Raiden. It can be used for applications like asset trading in gaming or finance, retail payments, micropayments for content (think the next YouTube or Spotify where creators are directly paid for every second consumed). But it’s also suitable as an infrastructure for cheaper, faster and more secure correspondent banking.”

It is called “Raiden Network” for a reason because its true strength lies in its network protocol. Opening and closing a payment channel between two peers still requires on-chain transactions, creating channels between all possible peers are nearly impossible. However, because of the network effect, one doesn’t need to create a direct channel between a payer and a payee. All that one needs is at least one node between the two parties for a network to route through. This network and its associated protocol for routing and interlocking channel transfers is called the Raiden Network.

While these off-chain transactions shouldn’t technically require any fees, the intermediaries in this network will charge fees to help incentivize them to take part in this network. More the participants, more complex the routing. This leads to a good competition among the intermediaries to provide good service the system. The Raiden protocol aims to facilitate this market by using both protocol-level features and optional auxiliary services.

How Does Raiden Work?

Suppose Alice and Bob want to interact with each other using Raiden. This is how they will go about it:

  • Alice and Bob open a payment channel between them which will be off-chain and they deploy a smart contract.
  • Both Alice and Bob need to give a security deposit to lock up the smart contract.
  • Suppose Alice wants to send 3 tokens to Bob, she signs the message “3” and sends it to Bob. Bob now has proof of Alice sending him 3 tokens.
  • Now, suppose Alice wants to send Bob 4 more tokens. She will update the state of the message to “7”.
  • This shows that the message is conveying the previous and the latest transaction as well.
  • The moment Bob wants to redeem the 7 tokens, he will go the blockchain and close the channel. He will get the 7 tokens from the deposit that was initially made in the channel.
  • The information will be relayed to the blockchain and the only record that will be stored is the final 7 token deposit made to Bob.


One of the most interesting features of the Raiden Network and state channels, in general, is privacy. Since the transactions happen off-chain, the transactions are mostly private. The Raiden Website states:

“Channel balances are hidden from the public until participants settle and withdraw their funds and the net channel balance is revealed. However, when the channel balances have been obfuscated by other intermediary transfers that passed through this and other channels connected to the same nodes, making it extremely difficult to trace back on-chain transactions to off-chain Raiden transfers.

Users may even offer paid services to artificially rebalance and obfuscate channel balances in order to increase the level of privacy. On the messaging layer, Raiden will make sure to protect traffic and sensitive data transmitted over the network. The messaging service will hide participants’ IP addresses from the public, preventing arbitrary nodes from being subject to DoS attacks. Additionally, pre-computed routes may use an onion routing protocol where intermediary nodes participating in a transfer have no way of knowing the target address of a Raiden transfer. The protocol only reveals the next channel in the route to each participant.”

Benefits of the Raiden Network

Let’s run through the benefits if the Raiden Network:

  • Microtransactions are impractical for on-chain deals. The Raiden Network provides a good platform for microtransactions
  • It does not matter whether a transfer is sent in one piece or split over thousands of micropayments. Hardly any transfer is too small to be sent efficiently over the Raiden Network.
  • Since the transactions are off-chain and don’t require miner confirmation, they are near instantaneous.
  • Raiden allows for off-chain transactions and settlement and hence helps immensely in scalability. This will lead to an efficient and future-proof, decentralized transfer network.


The Raiden ICO ended on 1st November and raised around $33.5 million.

The version of Raiden that was first available on the Ethereum mainnet was called μRaiden (Micro Raiden). It can provide trustless, instant and free transfers between two parties. However, as sleek the design is, μRaiden is not practical for many-to-many payment setups as it requires users to lock up tokens upfront for every potential payee.

There is another interesting implementation called Raidos. Raidos (or Raiden 2.0, “dos” is Spanish for “two”) is a proposed sidechain technology to generalize state channels. While the Raiden Network is limited to ERC20 token transfers, Raidos aims to scale Ethereum’s generalized computation capabilities through a network of satellite chains, which can host any smart contract. This technology is similar and complementary to Ethereum’s sharding.

The Plasma Network

Speaking of off-chain protocols, Plasma happens to be one of the most exciting projects that people in the crypto-space are working on right now. While Ethereum does plan to use it in the future, currently this technology is being championed by OmiseGo. Plasma has the potential to scale Ethereum up to 1 million transactions per second, and no, that’s not a typo. Plasma has been conceptualized by two of the brightest minds in the crypto-community, Ethereum co-founder Vitalik Buterin and the co-creator of Lightning Network, Joseph Poon.

What is Plasma?


Plasma is envisioned to blockchains that are built on top of blockchains. It is a series of contracts that run on top of the root chain (eg. the main ethereum blockchain). If you looking for a visual analogy then consider the Ethereum blockchain as the root and trunk of a tree (root chain) and the plasma blockchain as the branches and leaves that grow out of it (child chains).

The following image from the Plasma whitepaper will give you a good idea of the architecture.

According to the Plasma whitepaper:

“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.”

Alright, let’s uncomplicate the language and understand what is going on here.

Think of a restaurant. This restaurant has only one chef, let’s call her Alice. Every single day she has to clean the place, chop the ingredients, make the sauces and stock, buy all the ingredients, arrange the tables, take in reservations etc. This was pretty manageable in the beginning, however, word got about Alice’s restaurant, and she suddenly became famous. Now, as the customers keep coming in, it becomes increasingly more difficult for her to manage everything on her own.

Eventually, she needs to hire waiters, cleaners, more chefs, managers etc. to help her around. She doesn’t intervene with anything that they do. Only when they are done completing the tasks, they let her know so that she at least knows that those tasks have been completed.

Think of Ethereum as Alice and the child chains as the people she hires. The child chain does its own calculations and may have its own mechanism, and Ethereum doesn’t intervene with anything going on inside whatsoever. When the child chain is done with its “project” it updates Ethereum by sending a hash of the final result.

The root chain is like the absolute global truth that sets down the rules that the child chains must follow to do their work and computations. The child chains then proceed to periodically feed state information to the root chain.

So when does the root chain come into play?

It comes into play only when a dispute needs to be settled in the child chain. Other than that, it does absolutely nothing. The core idea behind plasma is to keep the root chain as devoid of activity as possible. After all, if the root is going to put down the ground rules, then it doesn’t make sense for it to get that involved in activities. The root chains and the child chains, in essence, form a set of nested blockchains.

In order to understand the concept of nested blockchain, you may want to know how nested loops work. Chances are, if you have done any kind of coding back in school/college, you have come across nested loops.

while(i < = 5)









What you see above is an example of a nested loop in C++. We will call the outer loop the i loop and the inner loop the j loop. The j loop executes its statement without any interference from the i loop. All the i loop does is lay down the ground rules for how long the entire loop system is going to run.

Before we go any further, let’s take a look at the design principles of Plasma.

The Design Principles of Plasma

Certain design principles had to be met for Joseph Poon and Vitalik Buterin to create Plasma. Let’s look at some of these goals:

#1 Only one root chain: As we have stated earlier, there will only be one main blockchain which will act as a root chain. Only this chain can lay down the ground rules for future execution. If more than one root chain laid down the rules, it will lead to chaos.

#2 Trustless execution: One of the pre-requisites of a decentralized system is an environment of trustless execution. The child chains could not subject to the “goodness” of their participants. There should be dispute resolution mechanisms in place to mitigate risk.

#3 Scalability of chains: The child chains should be able to take up the data that would normally go on the main blockchain and aid in the overall scalability of the system.

#4 Child Chains should be scalable: The child chains should be capable of implementing scaling solutions like sharding and lightning network as well.

#5 Localized Computations: Each child chain should be more than capable of handling its own computations. At no point should the main parent chain have to intervene on its own and handle the child’s computation.

#6 Proof of Fraud: This is one of the most important elements of Plasma. In the event of a fraud, a party should be able to send a proof of fraud to the root chain for dispute resolution. The root chain then should be able to revert the state of the child chain and penalize the signers responsible.

#7 Uniqueness of The Chain: Every child chain is governed by its own rules. They can have their unique identity as long as they are following the ground rules and reporting back regularly to the main chain.

Plasma Network and Dispute Resolution

The dispute resolution system in Plasma works similar to the court heirarchy.

What you see above is the court hierarchy system in the UK.

Can you guess what is equivalent to a root chain here?

The Supreme Court of course. They lay down the law of the land that their child chains i.e. the criminal and civil courts must follow. So, suppose Alice wants to bring a civil case to the court, she can’t directly go to the Supreme Court (unless of course, the case is of much significance). Alice will first goto a lower court. If she is not happy with the result, then she can keep on going up the ladder until she finally appears in front of the Supreme Court, whose judgment will be final.

That is pretty much how the idea of plasma and nested blockchains will work, with the root chain being the supreme court with multiple child chains under it.

So How Does Dispute Resolution Happen?

For the entire system to work in an efficient manner, they must be able to take effection mitigation actions against malicious behavior. So, how does dispute resolution work in Plasma?

Imagine this situation.

Suppose Alice has 2 Eth in Plasma Block 3 but for some reason sees that she no longer has that in the Block 4 of the plasma child chain. Now, imagine that the person responsible for Block 4 acts in Byzantine way and hands over 1 Eth from her to someone else. What exactly is she going to do now?

The Plasma smart contract will allow her to send a proof of fraud to the root chain for dispute resolution. The root blockchain will then check whether the fraud is real or not and if it is, it will “roll back” the malicious block.

What does that mean?

This basically means Block 4 will be rendered invalid and the state of the child chain goes back to the previous block, in this case, Block 3. The signor/creator of block #4 then gets penalized.

This is what happens:

How To Exit Plasma Protocol

According to Joseph Poon, the exiting protocols are “the core novelty of Plasma.”

So what do we mean by “exiting”? It fits at the core principle of making sure that the entire protocol is trustless and doesn’t rely on itself for safety. It basically means that users have the means to exit a child chain as and when required.

How does the exiting work?

The dispute resolution system in Plasma gets executed as soon as someone submits a proof of fraud. However, in order to do that, they also must have access to the fraudulent piece of data. Eg. Alice could prove the fraud above because she could see that Block 4 was acting maliciously with her. In other words, the only reason why Alice gets to prove fraud is because she had access to the malicious data in the first place.

Now the most obvious question is, what happens if the signer of the block doesn’t give Alice access to the data (this is called a block withholding attack)? After that, it becomes a game of hearsay which we must avoid at all costs. So, how do you make sure that Plasma is as trustless a system as possible?

So, the challenge that the designers had was to create an effective way of resolving this potential conflict without putting trust on any one of the parties.

How exactly did they do that? By coding the smart contract to have pre-designed exits in the plasma block. Take a look at the image below and we will tell you how it works.

Suppose Alice has 1 ETH on block 3, but she doesn’t have any access to Block 4. This what happens now:

  • Alice broadcasts to the parent chain that she plans to exit the chain if she is not given access to Block 4 within 7 days.
  • She broadcasts an intent of spending this money within the time limit. If she doesn’t spend this money, then she will be able to exit.
  • The exit always happens in the order of the age of the inputs inside the plasma block. What this basically means, is that the older inputs will be able to exit the block first in a FIFO (First In First Out) sequence. This is meant to create a fair system.

However, this means that the transaction intent has to be stored someplace else. This gets resolved by using nested trees to make the system as efficient as possible.

In the image above, there are three levels of chains:

  • The root chain is level 0
  • The level 1 is the child of the root chain
  • The level 2 chains are the child chains of level 1
  • Finally, the level 3 is the child of level 2

So, see the diagram below, and imagine that Alice has her Ether stored in the solitary level 3 block. Now, let’s assume that the block in chain 2 starts acting in a malicious manner.

In this situation:

  • Alice will firstly broadcast to the immediate parent of the malicious block, which is Block 1
  • The participants of the faulty block will move on to the preceding block
  • The fault block gets rolled back and the state moves to the previous block.

So why is this is a more desirable solution? Well, let’s look at it:

  • It is more economically viable
  • The main chain doesn’t need to bother itself with computations. This, after all, is the most important design goal of plasma. Having said that, if all the blocks in the Level 2 end up malicious, then Alice has no other option but to broadcast it to the root chain.
  • On top of that, a nested architecture significantly reduces the computation involved in checking and validating the transactions to make sure that no fraudulent activity has taken place. In fact, check out the diagram belowOne needs to watch only the chain which affects them directly. Let’s see an example of this by bringing this diagram back again:

In Alice’s case, instead of the entire set she just needs to look at the following:

 Plasma And Finality

Imagine that you own a share in a particular company. Because of a glitch in the company’s system, your share shouldn’t suddenly become null and void. This, in a nutshell, is what finality means, once a particular operation has been done, it will forever be etched in history and nothing can revert that operation. This is particularly important in fields which deal with finance.

So, how does Plasma get its finality?

Child Chain Finality: Child chain finality comes from the proof-of-stake mechanism.
Root Chain Finality: Root-chain finality comes from Ethereum which, as of right now, is using proof of work.

The finality and security of Plasma depend completely on Ethereum’s i.e. the root chain’s security. Plasma works only if Ethereum is safe and secure.

OmiseGo and Plasma

Like we have said before, OmiseGo is the project that is championing Plasma right now. It is an exchange but with two unique qualities:

  • It is decentralized
  • It is currency agnostic


Exchanges play an immensely important role int he crypto ecosystem. They are pretty much the bridge between the Fiat World and the Crypto world. However, because centralized entities are well…centralized, they are vulnerable to a host of hack attacks.

OmiseGO is planning to be a decentralized exchange where all the data will be stored on the blockchain, keeping it extremely safe.

Currency Agnostic

Most exchanges only allow one to transition from Fiat to Crypto. This means that if one were to change their BTC to ETH, they would have to convert their BTC to USD and then change their USD into ETH. In the process, they end up spending a lot of money as transaction fees.

OmiseGo works around this issue by being currency agnostic. So, conversions USD to ETH has the same process and fees as the conversion from BTC to ETH.



Truebit is an off-chain mechanism which will help Ethereum conduct complex and heavy computation. Truebit is different from state channels and Plasma in a way that it doesn’t aim to increase the overall transaction throughput of the blockchain at all. However, it aids in scalability by letting ethereum based applications do more complex things in a way that can still be verified by the main-chain.

How Truebit Works

Truebit will enable Ethereum application to do operations that are computationally expensive to do on chain. Simple Payment Verification (SPV) proofs from other blockchains is a good example of this. SPV allows Ethereum smart-contracts to check if a transaction has happened on another chain or not. This can be an extremely computationally expensive process.

Think of how Ethereum works.

Every contract has a specified gas limit attached to it. All the nodes in the Ethereum network must then operate the contract in parallel whilst using up the gas as computational fuel. Now, for an operation which is as complex as the SPV, the contract creator has to give a pretty huge gas limit and as you know, gas isn’t cheap. On top of that, as we have already discussed, Ethereum blocks have a maximum gas limit which sets another limitation on how many computations can take place inside a block.

So, how does Truebit work around this predicament?

Well, it allows you to contact their network of “solvers” and lets you pay them a small fee to do the computation off chain. The solver pays a deposit which is held in a smart contract. After that, the contract creator gives the solver a description of the computation that needs to be executed. So, how does dispute resolution in Truebit works? Through an economic mechanism called “verification game”.

Dispute Resolution via Verification Game

The truebit ecosystem creates a part of “challengers” who are economically incentivized to check the solvers’ work. If a challenger is able to prove through the verification game that a solver submitted a false result, then they collect a reward, while the solver loses their deposit.

Because the verification game is performed on-chain, it cannot simply compute the result (which would defeat the entire purpose of the system). This is why the solver and challenger are forced to identify the eact specific operation that they are in disagreement about. They need to produce the actual line of code that they disagree with


Once that specific operation is identified, it’s small enough to actually be executed by the ethereum main-chain. The Truebit system then executes that operation through a smart-contract on ethereum, which settles once and for all which party was telling the truth and which was lying or mistaken.

Features of Truebit

Here are some of the features of Truebit:

1. Incentives. Unlike traditional cloud computing, where the user simply trusts the cloud to provide correct answers, TrueBit provides financial incentives to ensure correctness.

2. Transparency. The entire inner workings of TrueBit’s interpreter sit on the blockchain and are open for inspection. Furthermore, the user community can democratically update the interpreter as needed.

3. Efficiency. Solvers in TrueBit have low computational overhead and minimal initial setup costs. The verification game does introduce some extra work, but in practice, due to high penalties for wrong answers and bogus challenges, we expect participants to appeal to the verification game only rarely, if at all.

4. Simplicity. TrueBit’s operation is relatively straightforward. Unlike traditional verifiable computing, TrueBit avoids deep probabilistically checkable proofs (PCPs), succinct non-interactive arguments of knowledge (SNARKs), and exotic cryptographic assumptions (e.g. those used in zkSNARKs [38]). The standard cryptography used in TrueBit, namely hash functions and digital signatures, sits in the underlying blockchain network and does not surface in the TrueBit protocol itself.

5. Adaptability. TrueBit runs on top of Ethereum’s current protocol without impacting functionality.

6. Keyless entry. Participants do not need to manage cryptographic keys beyond those used in Ethereum. TrueBit establishes identities through financial deposits alone, and therefore the system avoids risks from cryptographic trapdoors.

Truebit Architecture

Truebit has a modular architecture system and has three layers to it.

  • The Computation layer: Up first we have the computational layer which is a WebAssembly VM (or a more limited state machine, such as in our interactive scrypt construction for the Doge-Etheruem bridge). It requires implementations off-chain and on-chain.The Truebit WebAssembly interpreter is deterministic, metered, and has the ability to create Merkle trees of its internal state.
  • The Dispute Resolution layer: The is the layer where the verification game between two parties takes place. The is where the solver and challenger duke it out in case of an issue.
  • The Incentive layer: This layer involves the rewards, deposits, solver and challenger selection, and token mechanics.

The incentive layer has two possible solutions which are currently under consideration.

Solution #1: Forced errors and Jackpots

Knowing that all of their work and solutions are checked and that their deposit will get slashed if they act in a Byzantine manner, the Solver will always tell the truth. Since, in this situation, the Challengers will never catch an error, the fear is that they will eventually stop showing up.

At this point, the Solver can take advantage of this and begin posting wrong solutions. This when Challengers begin showing up again to catch errors.

The system flip-flops and doesn’t really have a stable equilibrium.

So, how does Truebit aim to solve this concept of a forced error and a jackpot? By bringing in some probability.

The protocol will force the solvers to provide the wrong answer, so any challenger who challenges this error automatically will receive a jackpot.

This windfall payment is so large that it more than makes up for all the tasks that the Challenger has to go through and gives a positive expected return. Verifying tasks is profitable even if Solvers always tell the truth.

Solution Layer #2: Multiple solvers and Pairwise verification games

There lies an alternative solution if the concept of jackpots and forced errors sounds too crude. One thing that you have to realize about Truebit is that Solvers and Verifiers are all doing the same work: they download the program, run it locally, and get a solution.

So, what if instead of making this problem solving a sequential approach, the program turns it into a parallel one where everyone can submit their solutions at the same time?

The contract will then see the solutions and if they have all arrived at the same one then the protocol knows that the participants have arrived at the truth. However, if there is any form of discrepancy, then the contract can facilitate pairwise verification games between the different groups.

This protocol achieves better timeliness guarantees, as games happen in parallel. It also does away with the forced error and jackpot. But it has added complexities in determining the cost to the TaskGiver and distributing rewards amongst the many Solvers.


All the layer 2 solutions share a common philosophy, once there is a hard instance of certainty that has been provided by the public blockchain, you can use it as a platform for cryptoeconomic systems which extends the usefulness of blockchain applications.

As we have already seen, the economic mechanisms used in layer 2 solutions tend to be interactive games. Meaning, that they work by creating incentives for different parties to compete against one another OR to keep the other in check. All the participants in the system must assume that the final result is true because of the sheer amount of vigorous checking that it goes through. Parties are, after all, economically incentivized to find as much fault as possible in the solution. We have seen this in all the layer 2 solutions that we have discussed thus far:

  • In state channels, the final state of the channel is confirmed by allowing the parties to hold each other accountable in the case of a dispute.
  • Plasma allows for exiting mechanism if someone presents a viable proof of fraud.
  • In Truebit, the challengers are incentivized to prove the solver wrong, which in turn, ensures that the solvers are telling the truth.

All the solutions that we have discussed thus far will help solve the scalability problem of cryptocurrencies by either:

  • Increasing the transaction throughput by a significant amount.
  • Allowing the cryptos to conduct more difficult and extensive computation off the chain.

While it is important for protocol designers and developers to come up with more layer 2 solutions, effort must be put to further the development of the underlying techniques and mechanisms that make them possible in the first place: cryptoeconomic design.

As Josh Stark puts it, “These layer 2 scaling solutions are a powerful argument for the long-term value of programmable blockchains like ethereum. Building the economic mechanisms underlying layer 2 solutions is only possible when a blockchain is programmable: you need a scripting language to write the programs that enforce the interactive games. This is much more difficult (or in some cases, like Plasma, probably impossible) on blockchains like bitcoin, which offer only limited scripting possibilities.”

Also, even with layer 2 solutions, the whole ecosystem should come into an agreement as to when to use it and when not to. Eg. for high value transactions where we want protection against powerful entities and hackers, we need to use the main chain. For trading digital collectibles where speed is more important, we can use Plasma. Layer 2 lets us make these tradeoffs without compromising the underlying blockchain, preserving decentralization and finality.

Having said that, there is one thing that one needs to keep in mind.

Lack of Scalability and Privacy ARE the two biggest factors that are holding back the mainstream adoption of cryptocurrencies. If cryptocurrencies are to become the standard bearers of future currencies as they were meant to be, then these two problems have to be solved. Layer 2 solutions have presented us with a unique opportunity where we can kill these two birds with one stone. Let’s keep supporting them and hope for newer and better solutions.

Leave A Reply

Your email address will not be published.