Close Cookie Preference Manager
Cookie Settings
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts. More info
Cookies Preferences
.jpeg)
One of our recent blog posts talked about blockchain scalability and how blockchains try to scale on Layer-1. We concluded (and if you have not read our Whitepaper, this is a spoiler) that Layer-1 does not scale.
It does not scale because you can’t maintain decentralization and scale. Giving up decentralization for scalability isn’t an option because that is the unique value proposition of blockchain.
Fortunately, we’re not limited to relying on just the base layer. It’s no surprise that when El Salvador announced it would make Bitcoin legal tender, most of the companies that started accepting it for payment did so through a lighting wallet. Lightning = Layer-2 for Bitcoin.
Of course, with the NFT-fuelled increasing demand for traffic on Ethereum, we’ve also seen Layer-2s for Ethereum such as Polygon, Optimism, and Arbitrum take off. But let’s take a step back.
Layer-2s (L2s) describe scaling solutions that move transactional weight off a blockchain’s mainchain. They enable the mainchain to offload a lot of its demand to an adjacent architecture.
Since we refer to the mainchain as Layer-1, every Layer built on top is consequently Layer-2.
By offloading traffic to another layer, L2s help blockchains scale to accommodate demand, keep fees low, and the load on the main chain to a reasonable amount.
Instead of facing congestion because everyone is trying to transact on Layer-1, once Layer-2s are established, users will only go to Layer-1 to start/end transactional relationships and for dispute settlement.
There is a wide variety of them, depending on which ecosystem one looks at. The most relevant L2 scaling solutions these days are:
Haven’t heard of this one yet? Some would class them under sidechains, but since Plasma chains come with a different setup than sidechains that limits utility to maximize security, we are looking at them separately.
OmiseGo was one of the first big projects to implement it to address scalability. As a network focused primarily on facilitating payments, Plasma was a logical choice.
But what does a Plasma Chain even do?
First proposed by Joseph Poon and Vitalik Buterin in 2017, plasma chains are separate blockchains anchored to the mainchain. There isn’t just one implementation; they can be better understood as a framework.
Instead of plasma chains, we often also use the term child chains, as they have a parent-child relationship with the chain they are anchored to. In theory, one can create an unlimited amount of plasma chains stacked on each other, which results in a tree-like structure. In that case, the main chain is called the root chain, and there are various parent-child pairs.
Each child chain is designed to work in a singular way, serving different needs. They co-exist and operate independently. Each child chain has its own mechanism for block validation and a fraud-proof implementation to ensure that the data it processes is valid and that no fraudulent transactions are reported to the root chain.
Fraud Proofs: They use an interactive funds withdrawal protocol, to withdraw funds when needed. The exiting party needs to confirm their output via UTXPO mode and request withdrawals. While withdrawal is pending, network participants can submit bonded proof that the funds are indeed the exiting parties. If the proof is incorrect, the transaction is treated as fraud and canceled.
Benefits of plasma chain implementations include that they allow a high level of throughput, lower transaction costs, and are a great way to facilitate transactions between arbitrary users.
However, there are a few trade-offs as well which include that they only support simple logic such as swaps. Consequently, they aren’t a solution for more complex dApps. The biggest drawback from a user standpoint is probably that withdrawals are delayed by days to allow for others to challenge the validity.
Nevertheless, Plasma is already used in different implementations such as Plasma Cash (to store and transfer NFTs) and Plasma debit, which works similarly to a lightning hub, where each token itself is a payment channel between the user and the chain operator.
Another scaling solution are state channels. It’s important to note that blockchains like Ethereum are stateful ones where each block stores information on the state of the chain.
This is different from the way that Bitcoin and Minima operate using a UTXO model.
The information takes up a lot of storage and often isn’t even relevant to the ongoing transactions. State channels open a two-way path between transacting parties to communicate and transact. Each participant signs with their private keys to ensure that transactions are valid.
These channels are off-chain and private. Only the participants in them know that they exist. As transactions don’t have to be broadcast to the mainchain, all settlement is near-instant and private.
Channels are only open as long as participants wish them to be. Once closed, the transaction history is uploaded to the chain, and their outcome becomes part of the mainchain.
State Channel in practice:
By reducing the information that needs to be written to the mainchain, state channels also help decrease the computational load on nodes.
As their name suggests, state channels can’t just support payments, but also general state updates. To provide a feasible example, if you think of voting in DAOs, instead of having everyone vote on the mainchain (which on Ethereum for cost reasons alone wouldn’t be a great idea, not to mention the network traffic it’d cause) members could submit their vote through a state channel, and only the final outcome is then written on-chain.
For users, a very obvious benefit is that instead of having to pay for 10 transactions, they only pay 2 when using state channels, and they achieve instant finality. No more waiting for a transaction to be considered final.
However, state channels require 100% availability from participants. That’s why they work best with a defined set of participants.
Have you ever used a Bitcoin Lightning wallet?
If the answer is yes, you’ve been using payment channels, maybe even without knowing it. And if not, after reading this you’ll at least know what they are and how they work.
Payment channels work similarly to the above state channels but aren’t limited to stateful chains. The lightning network is the most well-known, and widely used implementation of payment channels for scalability with more than 86,000 channels open. Therefore, we’ll use it for explanation purposes.
Users lock up their funds in the payment channel, and then start transacting with each other off-chain, instead of on-chain — therefore saving costs, and getting instant confirmation.
Now you might wonder, surely not everyone wants to open their own channel?
And that is true. It’s a bit of a technical process that requires you to run a lightning node and then connect with another node to open a channel. Anyone operating a channel also has to add Bitcoin to it, so that outputs can be spent.
It does require some thinking and isn’t yet a one-click thing.
Fortunately, not everyone has to operate a lightning channel connecting with whoever they want to transact with directly. Instead, the lightning network leverages Hashed-Timelocked-Contracts, which allow funds to be routed across channels without the funnel operator knowing who is transacting from where to whom.
For an in-depth explanation of how these contracts work, check 👇
Understanding Hashed Time-Locked Contracts (HTLCs)
Thanks to HTLCs, and various individuals and other entities operating lightning channels, not everyone needs to open one to get started. If you wanted to, you could even get Bitcoin directly into a lightning wallet from exchanges that support it.
However, the lightning network like many other protocols in this industry is still a work in progress. There is a passionate crowd of developers continuously pushing updates to the most widely used implementation (c-lightning). It’s not yet perfect.
One of the downsides of lightning in its current state is that it can’t support big transactions yet. That is because each lightning channel needs to be supplemented by its operator with liquidity (Bitcoin). The value locked in channels increases, but any whale would probably still have a hard time moving their funds from A to B. 🐋
whale = investor with significant holdings.
Yet there is an even bigger flaw with Lightning on Bitcoin.
What about the miners?
Miners secure the bitcoin network by providing hashrate. The higher the hashrate, the more hashrate any entity looking to attack the network would have to secure. So far, bitcoin hasn’t seen a single 51% attack which is seen as proof of them being uneconomical at this point.
But, the Lightning network is growing. The more people start to use lightning the less traffic is happening on the mainchain. The only transactions that happen on the mainchain could be the opening and closing of channels, and maybe exchanges moving funds.
At first, that seems great because it’d mean that the network can support the desired mass adoption.
But what if, there aren’t enough transactions on the mainchain anymore?
Empty blocks aren’t an efficient use of computing power. Many already allege Bitcoin to be wasteful, and if indeed it came to a point where most blocks were fairly empty, we would say that it is.
Yet that isn’t the only issue.
Currently, miners mine for the block rewards. There might be a few charitable miners who do it to secure the network, but ultimately the biggest motivation is to earn Bitcoin.
That won’t last forever.
Eventually, block rewards will run out.
What will secure the network then?
Imagine.
Block rewards are zero.
Everyone transacts on Lightning.
Will the little in fees that people pay to open and close channels, and for the occasional on-chain transfer be sufficient to secure the network? Will miners be willing to work for that?
That is why Minima has Maxima.
We replace the fee-based security of Layer-1 with a cooperative, collaborative network of nodes. All nodes together secure the network — each individually by contributing just a small amount of proof-of-work.
On top of that sits Maxima, a censorship-resistant information Layer that lets users transmit any data they like. This creates a communication layer that any Layer-2 can use.
And even users who don’t use Layer-2, who just want to send messages or files over Maxima, still secure the underlying network by providing a small Proof-of-Work.
Minima supports scaling solutions such as state channels, a lightning-like network, sidechains, and state chains. We are also building our own Layer-2 called Omnia.
This unlocks potentially unlimited transactions per second without sacrificing decentralization.
More on L2 on Minima here.
And if you wonder how sidechains and state chains work, look forward to one of our next blog posts. 🙌
