Intro
EOS is a blockchain that is built from the ground up for scalability. At its peak, the EOS mainnet as it exists today has processed 3,996 transactions per second (tps) and more than 10M operations in a single day. While these numbers are truly impressive, they are just the beginning for EOS. The long-term vision for the platform is to host thousands of dApps that serve millions of users on a daily basis. For this, the network will need to expand far beyond its current capacity.
The EOS scaling roadmap can be divided into two primary routes, each with its own subsections:
The first route is vertical scaling. These are optimizations that increase the capacity and throughput of an individual blockchain. This includes things like multi-threading, changes to the resource algorithms, optimizations to WASM, and increased block producer hardware capacity.
The second route is horizontal scaling ; solutions that increase the total number of individual blockchains in the ecosystem while maintaining interoperability between them. This includes sidechains and sister chains.
This article will focus on the role that sidechains and sister chains play in the EOS ecosystem and will address some of the challenges that these projects face.
What are Sidechains and Sister Chains?
Both sidechains and sister chains are ways of creating additional capacity in the EOS ecosystem by creating multiple blockchains that use the same software and can communicate and interoperate.
- Sidechains are EOSIO blockchains that utilize the EOS mainnet token for resource allocation (access to bandwidth, RAM, etc).
- Sister chains are blockchains that utilize the EOSIO software but that have their own native token used for resource allocation.
There are not currently any sidechains that are live, but several sister chains are either live, in beta testing, or currently being built. These include a number of projects like Worbli, WAX, Telos, and ONO. These blockchains are built on the same open-source EOSIO software that powers the EOS mainnet, but they have their own tokens that are used for voting, resource allocation, and compensating block producers. Examples include the Worbli $WBI token and the ONO $ONOT token.
Some of these sister chains have altered the features or parameters of the EOSIO software, making them functionally different from the EOS mainnet. Others have kept all of the core EOSIO features but are choosing to build on their own chain for reasons of throughput, resource management, compliance, or governance. Many of these sister chains have also airdropped a portion of their tokens to the existing set of EOS mainnet token holders.
Sidechains work a bit differently. Sidechains are separate blockchains, but they use the EOS mainnet token for resource allocation. Currently, if I stake 1000 EOS on the mainnet, then I have a pro-rata share of the network's resources. With a sidechain, I could stake those same 1000 EOS and get access to a pro-rata share of the sidechain's resources. This would allow users of the EOS mainnet to spread out across many chains for additional capacity while still building network effects (and value accrual) around the EOS mainnet token. It would also mean that users of the mainnet would be able to use their resources across an entire ecosystem of many chains without having to convert them into another token.
This graphic from KOREOS does a great job of visualizing this ecosystem.
Why Multiple Chains?
All blockchain networks face some fundamental limits on their capacity. While EOS has many features that allow it to achieve industry-leading performance, there are limits to systems that are distributed, especially those (like the current version of the EOS mainnet) that require sequential processing.
For example, if I am using a decentralized exchange (DEX), and I sell 50 EOS to Bob, that transaction must be processed and confirmed before Bob can go and buy something with that EOS. Otherwise I could sell 50 EOS to Bob in exchange for another token (say BET) and then cancel or reverse the transaction before Bob can buy something with the EOS. Then I have both my EOS and Bob's BET tokens, and Bob has nothing. This is known as the double-spend problem.
On the other hand, say that I am using a DEX to trade with Bob, and another user is using a completely separate dApp like Everipedia to stake and unstake IQ tokens and edit articles. My trades and the other user's edits don't need to be processed one after another because they don't reference one another at all. The transactions within each respective dApp (the DEX and Everipedia) must be sequential, but my trades and the other user's edits can be processed at the same time, since there's no risk of a double spend.
At the most basic level, the idea behind side chains and sister chains is that these two dApps could exist as separate chains. Instead of having a single blockchain with 3,996 tps that could host both dApps, we could have two separate chains, each with 3,996 tps, for a total of 7,992 tps across the ecosystem. Now imagine this across hundreds or even thousands of chains, and the scaling possibilities are nearly endless.
While this solution gets us the increased throughput that we desire, it doesn't get us the interoperability between dApps that makes a platform like EOS so useful. So what happens if these dApps need to communicate and interoperate? That's where inter-blockchain communication (IBC) comes in.
Inter-Blockchain Communication (IBC)
Without interoperability, sidechains aren't possible, and sister chains become siloed platforms. Luckily for us, the ability for EOSIO blockchains to communicate has always been part of the vision for the EOS ecosystem.
IBC was first described in the EOSIO white paper. The groundwork has been laid to allow for IBC on the EOS mainnet, but the IBC core code is still being developed by both Block.one and a number of block producers. It will likely be released by the end of this year.
The core idea behind IBC is quite simple; different EOSIO blockchains will be able to send proofs to one another that allow for operations on one chain to be recognized on another. For example, say that I use a DEX to trade some EOS to Bob in exchange for IQ tokens. But then I want to stake those IQ tokens to edit articles on Everipedia. If the DEX and Everipedia exist as separate chains, then I need a way to transfer those IQ tokens from the DEX chain to the Everipedia chain. Using IBC, I can create a transaction on the DEX chain that proves ownership of those tokens and allows me to spend them on a separate chain. We won't dive into the complexities of how exactly this works, but it suffices to say that IBC creates a single global platform that has many chains that can all interoperate. In the future, these IBC transactions will likely be completely abstracted away from the end user, who will have no idea that transfers between different ledgers are taking place on the back end.
Problems with Sidechains and Sister Chains
While sidechains and sister chains are in many ways an elegant solution to scalability issues, they are not without their own challenges.
Sister chains use their own native token for governance, resource allocation, and block producer compensation. Worbli, for example, has incentivized a number of BPs to join its network because it can use inflation of its WBI token to compensate BPs (just as the EOS mainnet does with the EOS token).
One of the issues with this model is that it doesn't always make sense for a dApp to have its own native token. Certainly there are instances where a dApp-specific token makes sense, but there are many others where the dApp could function without its own token at all. And in many cases the native tokens that are created won't actually accrue much value. If this is the case, it will be hard to incentivize block producers to be paid in these tokens. These platforms may have to have higher rates of inflation to pay BPs enough to cover their costs, and that high inflation will put further downward price pressure on the token, creating a value-destructive cycle. Only those projects with compelling token models and true value creation will be able to survive long-term using this model.
Sidechains, on the other hand, use the EOS mainnet token for resource allocation. Projects that build on sidechains have no way of incentivizing validators with inflation at all, since the EOS mainnet inflation goes to mainnet BPs. Thus, sidechains have two options:
- Get all mainnet BPs to also act as BPs on the sidechain
- Create other models for compensating BPs
Getting existing mainnet BPs to all agree to produce blocks on other sidechains, especially when there are additional costs associated with providing that additional infrastructure, will be a tough sell for many projects. Block producers would be taking on additional costs while working for the same pay, and there may be disagreements among BPs about which projects are worth supporting.
Solutions
There are ways of solving these issues. For sister chains, they will have to create compelling enough products and token models that the tokens actually accrue value and thus can incentivize BPs. For sidechains, there are a few other solutions; in theory, an on-chain referendum could be held for EOS token holders to decide which sidechains existing mainnet BPs should produce blocks on. While this solution may work in the future once EOS's governance and referendum process is more mature, this may also create additional issues.
An even better solution, proposed by Chitty of EOS Argentina, would be for sidechains to create business models that allow them to compensate BPs without inflation. Some EOS dApps have already proven real business models. EOSBet and BETDice are both examples. These dApps generate actual revenue, some of which goes to token holders, some of which is paid to the developers, and some of which is used for staking and resources, depending on the structure. Now imagine if one of these dApps were built as a sidechain instead of a dApp on the mainnet. EOS mainnet tokens would still be used to stake for resources, as they are in the dApp today, but a portion of the dApp's revenue would be paid to the BPs on the sidechain. This would allow the dApp to compensate BPs, who would benefit from the success of the dApp. In fact, the dApp's native token (currently used for revenue sharing) could also be used for governance to decide who the BPs are, but the token supply wouldn't have to be inflated, and BPs could be paid in the EOS generated by the dApp. This is likely the best solution for most sidechains moving forward.
The Future of the EOSIO Multi-Chain Ecosystem
Once the IBC software is released, we will likely see an explosion of new projects creating sidechains and sister chains with all sorts of different models. We're looking forward to seeing all sorts of experimentation in the space to determine which models make the most sense.
There are a number of ways that the EOSIO ecosystem could develop as a result of sidechains, sister chains, and IBC. On one hand, we may see more and more sidechains developed such that the EOS mainnet token accrues more value and network effects than any other token in the ecosystem. It may be that the EOS mainnet token becomes the reserve currency of the entire EOSIO ecosystem and that the mainnet is considered to be the most secure and canonical chain. If this is the case, sidechains and sister chains may be considered slightly less secure but more free to experiment with different models and architectures. These chains may periodically submit proofs of their state to the EOS mainnet in order to have a canonical record that lives on the main blockchain.
On the other hand, it's entirely possible that no single EOSIO chain comes to be seen as the base chain or canonical chain of the ecosystem. This ecosystem may grow into one that sees competition between all sorts of different chains, where free market competition simply sees the most successful chains accrue the most value over time.
We're not sure exactly how this situation will pan out, but we look forward to observing its evolution.
Aurora EOS is the leading block producer for the informed voter. If you find our work helpful, please vote for our node: auroraeoscom
If you prefer to proxy your vote, our proxy account is auroraeosprx
Find us on Twitter , Medium , Telegram , and Steem
Subscribe to our newsletter for weekly updates on the EOS ecosystem