Note

The visuals in this article are coming from the presentation I did in DCTRL a few years ago -- on Apr 4, 2018 to be exact. So the dates you will see in the visuals are meant to be "in the future" even though they aren't anymore.

Layer 2 protocols are one of the major proposed solutions for blockchain scalability limitations. The promise of them is instant and almost free transactions.

Ethereum Rollups (optimistic and ZK), Plasma, and Bitcoin's Lightning Network are examples of Layer 2 solutions.

To better understand what they are, let's imagine how a Layer 2 system would work on the banking system.

You may think that Stripe and Paypal are Layer 2 solutions... they are not. All these solutions still deal with the financial system, they just make it more accessible. A true Layer 2 solution will try to avoid its underlying system while it stays backed by system.

So, how would you use a bank without the bank even knowing?

It all comes down to thinking about when you need the bank. In the Bitcoin blockchain, the early Layer 2 solution was the Lightning Network. The principle behind its design was thinking about the blockchain as a court, not a bank. So it would only use the blockchain in case of a dispute or for closing the relationship. That's when you have to foot the bill of interacting with the blockchain, at other times, you can avoid the interaction.

To put that system on the banking system, let's follow Alice and Bob. Bob makes pizzas and Alice often buys one.

Alice wants to pay Bob for the delicious pizza; they are facing the below constraints:

1. Neither of them feel safe to carry cash around, they want their cash to be secure in a bank when they make transaction.
2. While they want to use the bank, interacting with the bank is unfortunately very expensive. Every time they go to the bank, the ATM, or the bank's website, it costs them a few dollars (much like the blockchain transaction fees).
3. Alice and Bob don't trust each other! Said in nicer terms, they don't want to just hope that the other party will do the right thing. Even if they gain some trust, there are many unforeseen events that can make a party unavailable. They want the system they design to be fail-proof.

So Alice and Bob want to still use some form of cash, but avoid going to the bank as much as possible. They first have to go the bank anyways to establish a relationship. The good news is that the bank gives them lot of cheques for free.

Let's first see how the cheques work. A valid cheque (for the bank) has the following fields:

• Amount: The amount of dollars the bank must give in exchange for the cheque.
• To: The person who can cash the cheque.
• Date: The earliest time the bank can cash the cheque. For example, a cheque with the date April 20, 2022 is only acceptable for the bank on or after that date.
• Signature: Alice and Bob must both sign the cheque.

Alice is the purchaser, so she is the only one who puts money in the bank. Alice knows that she will want pizzas until March next year and she believes $100 should be more than enough to fund her future purchases until then. So she deposits $100.

The first thing Alice and Bob do is making sure the money can go back to Alice if she fails to buy any pizza. They pick a date that should be long after they have concluded the pizza purchases, here they pick April 20 of the next year. They both sign a cheque to Alice for the full amount for that date:

Doing it now is important because it avoids trusting the future; Alice now has a way of getting her fund without Bob's future involvement. Even if something happens to Bob, Alice can make her money back.

Now that they have set all this up and have paid the bank fees, they are all set to avoid bank fees for future purchases.

How? Say, Alice buys $5 worth of pizza from Bob. To make a $5 transaction to Bob, all they need to do is to sign a new pair of cheques, dated one day earlier than the last cheque(s) with their new balance. In our example, they do this:

So if the transactions end here, Bob will go to the bank on April 19 and gets his $5. He doesn't need to trust Alice. Even if Alice tries to cheat and cash her $100 cheque, the earliest she can do it is on April 20. So her $100 cheque will bounce due to insufficient funds. She is forced to use the $95 cheque.

So without paying money to the bank or interfacing with it, they moved some funds.

You may ask why won't they destroy the old cheques? Well, this is a metaphor for the crypto world. There, ensuring that the info you sent earlier are destroyed is impossible.

Anyways, Alice and Bob can keep doing this: Every time there is a new transaction, set the date earlier. Bob can send money back to Alice too.

That's it!

We made a layer 2 solution on the banking system. Alice and Bob can have trustless transactions as many times as they want without interfacing with the bank. The only time they contact the bank is for cashing their cheques.

If you notice, "trustlessness" was the major theme of this example. The Layer 2 systems are pointless if there needs to be trust between the parties. In this example world, all the extra things we did was to make sure no trust is necessary.

That said, the parties should still act in their own best interest. For example, if Bob forgets to go to the bank at the earliest day he can, he exposes himself to the risk of being cheated out of his funds. That's why I say the underlying technology of a Layer 2 protocol is like a court. The parties should defend themselves.

Bonus Content

You have read the most important parts by now. The rest of this article is about the the actual implementation.

In the blockchain world, there are certain limitations with our example:

1. The date system is restricting: either the parties need to set a closing date far into the future (which means they have to wait a while to get their money) or they limit the number of transactions they can do on the Layer 2.
2. There is no penalty: Cheaters will always get at least their fair share. So, without consequences, the players may try cheating as much as they can, with the hope of gaining something.

Let's start with #1. On blockchain, when you want to take your funds, your request can have a "timelock (opens new window)" instead of a set date. The timelock indicates how many blocks needs to be introduced in the blockchain by miners until you can access your funds.

This is being used in Bitcoin's "Lightning Network" which is one of the original layer 2 solutions.

On the Lightning network, parties create valid Bitcoin transactions but they don't send them on the blockchain. Similar to the cheques example, this will update the "state" of their account, but won't cost them.

While the timelock is active, others can send "penalty" transactions to dispute your request to the blockchain. For example, they may prove that you have sent an older transaction, by producing a more valid one.

Because all of this is happening between the parties (before sending things to the blockchain), the updates to state (transactions) can be instant and free.

In our Alice and Bob example, let's say they both have 50 coins in their account. This is their current "state". Their agreement is that they will have a 500 block timelock before cashing out. On Bitcoin, a block is introduced every 10 minutes on average. So the timelock on their shared account is around 3.5 days.

So there is much more flexibility with timelock system. This benefit can increase by introducing penalties to the system (number 2 above). Every time Alice and Bob move funds between them, they each sign the "penalty" for the previous state. That way they are protected against that state finding itself to the blockchain.

In our example, Alice sends 30 coins to Bob. They create a new state to reflect that: Bob has 80 coins now and Alice has 20. They also sign penalties for the original state where if they cheat, the other parties gets the whole 100 coins. So the cheater gets penalized.

Notice that the penalty transaction has a timelock of 0 so it becomes immediately effective when it reaches the blockchain. For example, after 53 state updates between Alice and Bob, Alice wants to get her funds out. She sends the latest transaction has to the blockchain. The timelock goes into effect.

If Bob makes no disputes, the transaction goes through. But let's say Alice was cheating and she sent an older state. Then Bob must monitor the blockchain and use his penalty transaction to get all the funds. He has 3.5 days to do that.

The lightning network is not limited to 2 parties. It can make a mesh of users. Let's say Alice wants to send money to Carol but they don't have a shared account. Luckily, they both have shared accounts with Bob.

So Bob can take some money from Alice and pay the same amount to Carol to complete the transaction.

This can be very useful because it will keep the network functioning in Layer 2 a lot more. For example, if Carol is Bob's boss, and she is paying him using the lightning network, their shared account only flows one way (from Carol to Bob). At some point, Carol's balance becomes 0. Then they have to communicate with the blockchain to add new funds.

With the network mentality, we just saw that Alice sent funds to Carol which means the money flowed from Bob to Carol in their shared account. Think of an ideal world where Carol pays Bob 200 coins for his salary, but Bob is connected with Carol's vendors and the vendors pay a total of 200 coins to Carol through Bob. This shared account can work indefinitely.

I won't go into further detail of how all this works. Just that the network manages to keep all transactions trustless. The protocols still face challenges. For example, one challenge is how Alice can know Bob is a mutual connection with Carol. Sometimes multiple "hops" are needed between mutual connections, which makes things far more complicated. The average user just wants to send funds to another entity, it may be hard to discover a route between them on a decentralized network.

So far Layer 2 networks have not taken over the world, but they are clever enough that one day they might.