Learn

Scaling with sidechains and state chains

11 May 2022
•
Written by: Minima

Our last blog post on scalability details solutions like the plasma chain, state channels, and the Lightning Network that help blockchain networks scale. However, more scaling solutions are out there, which can also be applied to Minima.

The plasma chain introduced previously is already a form of sidechain, but since it had a different setup than traditional sidechains, we will cover them more broadly in this post.

Generally, the idea of scaling solutions on the 2nd layer is to take traffic off the mainchain. That’s achieved by installing a connection between the 1st Layer and the second. Sidechains are no different.

Sidechains

One can deduce from their name that a sidechain is an entire blockchain running “on the side” of the mainchain. Sidechains themselves are independent blockchains. That means they can employ their consensus algorithms, nodes, and block parameters to process transactions.

Sidechains tend to be cheaper than transacting on the mainchain, making them very popular with users. An example of a now in-famous sidechain is the Ronin sidechain.

Ronin (浪人) is a Japanese word to describe a Samurai without a master

Sky Mavis, the gaming studio behind the popular Play-to-Earn game Axie Infinity, realized that hosting a game on Ethereum involved asking users to pay high gas fees and wait a long time for transactions. So they decided to move the game to their sidechain. Unfortunately, users and the team themselves found out the hard way one truth about sidechains:

Sidechains don’t inherit the security of the mainchain

It was an expensive lesson, with a hacker walking away with $600 million in assets. While the company seems willing to reimburse users, it still was a case study of how not to run a sidechain.

You might wonder why sidechains aren’t as secure as the mainchain. The reason is that they are independent blockchains. That means they don’t benefit from the nodes running the mainchain. To provide another real-life example, take Polygon.

Ethereum is a Proof-of-Work chain (until the merge later this year). Polygon, a scaling solution for Ethereum, is fully compatible with the mainchain. But it is its own blockchain, with its own set of validators, running on different nodes and with a different consensus algorithm.

It’s convenient for users because they can easily bridge their assets from Ethereum to Polygon and back, but the security isn’t the same.

Sidechains are connected to the mainchain through two-way pegs. That means you can transfer assets in and out. Smart contracts manage that process of moving between chains.

From Bitcoin to smart Bitcoin and back

While not so well-known, Bitcoin has had sidechains for years now. RSK (Rootstock) is a project from Latin America on a mission to enable smart contracts and DeFi on Bitcoin. While the original Bitcoin protocol doesn’t support complex logic, RSK enables devs to run smart contracts in the Bitcoin ecosystem by creating a sidechain with a two-way peg to Bitcoin.

One problem sidechains face is needing their set of nodes to secure their chain. It’s an independent chain, after all. RSK is addressing that problem through Merged Mining.

via GIPHY

This enables miners to secure various chains without increasing the amount of computing power. Anyone mining SHA-256 PoW coins can also mine on RSK and earn rewards.

Yet, how do users go about using the sidechain?

They will have to lock up funds on the mainchain. We wanted to use 1 BTC on RSK because we want to earn interest on it in a lending protocol. The smart contract connecting bitcoin with RSK will take our 1 BTC and issue us one rBTC (smart Bitcoin) in return. Now we can take this rBTC and use it on a lending platform. Once we’re done with earning interest and want to cash out to the mainchain, we’d have to go through the process but in reverse.

Outlook

Sidechains are well-suited for application-specific use cases beyond just adding scalability to the mainchain and have the potential to expand beyond them. They might play a role eventually in cross-chain interoperability. As a user, it’s important to remember that sidechains are their own blockchain, and one should go about picking them with similar due diligence as you would any Layer-1.

Another solution that was proposed in 2019 to scale Bitcoin are Statechains.

Statechain

Ruben Somsen, a Bitcoin developer came up with the concept of statechains when looking into making Bitcoin scale without sacrificing decentralization.

Statechains, are a layer-2 protocol that enables off-chain transfers. It’s fully non-custodial, meaning that no third party takes control of your funds. So the next question is, how do statechains work, and how are they different from sidechains?

Unlike the lightning network, statechains are not trustless. What that means in practice is that the idea behind statechains relies on a trust assumption. Let’s quickly recall what a value transfer on UTXO chains actually means.

It’s not physical money changing hands. When we transfer Bitcoin or Minima, what we do is hand over the UTXO to the recipient.

With statechains, we lock up money in a 2-of-2 multi-sig (multi-signature, which means that out of 2 specified sets of keys 2 have to sign for a transaction to be valid). Instead of sending the actual UTXO, what we do is send a private key 🔑.

The second key required to unlock the funds is not held by the person receiving the funds. It’s held by a neutral party acting as a facilitator. And that is the reason why statechains aren’t trustless. You still need to trust this neutral party to finalize transactions.

If you’ve never even heard of statechains before, but know how to use Bitcoin, your next question is probably:

How does value transfer on statechains work in practice?

  1. Alice creates a statechain and makes Chantal the facilitator (neutral party)
  2. Alice generates a transitory key, Chantal creates her key -> both keys create a multi-sig address
  3. Alice sends Bitcoin to the multi-sig address
  4. Instead of sending the money directly on-chain to Bob, she now sends the transitory key to Bob
  5. With the key, Bob can reach out to Chantal to move the coins. NOTE: The last one in the chain is always the one that Chantal will cooperate with. Even though Alice still holds the transitory key, as far as Chantal is concerned Alice doesn’t own the coins anymore.

In theory, Alice, Bob, and Chantal could continue infinitely just forwarding keys without ever signing a transaction on the mainchain. Of course, there is still one “problem” for someone looking for a trustless solution.

We have to trust the neutral party to not disappear

One way to address this is by adding a backup transaction that sends coins from the multi-sig to a new address. It could be set up by Alice with two conditions that’ll trigger its execution:

  • two keys sign multi-sig; the normal process
  • define a certain time period after which Alice can spend the coins, without needing a second key.

In practice, Alice would ask Chantal to sign the backup transaction for Bob and then gives it to him. When Bob receives the transitory key, he still has a signed backup so if Chantal disappeared he could claim his money.

Additionally, one can add Eltoo to the mix. This is a technology that with the generation of a new state, invalidates the previous one. In the example of Alice, Bob and Chantal that means, Bob could override Alice’s Backup transaction. So if now Alice tried to cheat the system by broadcasting her old transaction, it will automatically be flagged as invalid. 🚩

Malicious third-party

Of course, in the worst case, there is still a risk that the neutral party isn’t neutral but malicious. This isn’t a problem that can be completely solved in its entirety. But there are ways to minimize the risks.

  • Different multi-sig setups. Instead of using a 2-of-2 multi-sig, one could set up to require a desired amount of signatures from a grand total, such as 8 out of 10.
  • Another approach is spotlighting any bad actor by creating a new chain where everyone who was part of the previous chain confirms their transactions. That means that everyone will see when Chantal acts wrongly
  • Replace Chantal with well-known, reputable facilitators. This one is slightly ironic, if your goal was to not rely on institutions. The idea is that companies like Blockstream for Bitcoin are so involved, and known in the ecosystem that they can be relied upon.

Overall statechains are an interesting approach to scaling UTXO networks. They facilitate greater privacy and don’t require any changes to the underlying protocol.

Yet, there are still downsides, namely that they involve a centralized figure, or a number of figures to provide the statechain, and help settle final counts.

Another, even bigger issue for those wanting to use them for payments is that, once entered, the amount in a statechain is fixed.

So if Alice creates the statechain to send 1 BTC, that is the only amount that others can transfer. Bob can only transfer 1 BTC on, and so forth.

This might look like a downside at first. But UTXOs can also be thought of as…

NFTs

Lightning technology is great for smaller payments. For big lump sum payments, statechains are perfectly suited.

Yet, what might give them an even greater use-case are NFTs. Instead of having to settle each NFT ownership transfer on-chain, one could transfer the corresponding keys long confirmation times, nor cost.

Minima is a UTXO chain. Therefore, it can support sidechains as well as statechains to increase scalability. To learn more about using Minima, and the technologies making up our protocol, check out our documentation and join us on Discord.

‍

Join the conversation
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

Save settings
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

Cookie Settings