All blockchains have a scalability hard cap. You can make it the fastest blockchain in the world, with blocks as large as possible, and nevertheless you still end up with a scalability hard cap. And a low one for that matter. What does low mean in this context? Just consider all the data that is stored and transacted in the world today. We’ve entered the zettabyte scale, and everything points that it’s not stopping anytime soon. For context, a zettabyte is one million petabytes, and a petabyte is one million gigabytes.
From this perspective, a blockchain is everything but scalable. The main reason for this is that a blockchain is one single continuous structure of blocks, that needs to be known by all network nodes, and that keeps on growing as you add more and more blocks to it.
This type of architecture doesn’t work at scale, and that’s why so many new proposals to solve this problem have emerged. Some are second layer solutions, that spare the blockchain from unnecessary transactions, others are inter blockchain communications, that promise horizontal scalability by many smaller intercommunicating blockchains. The concept of sidechains has also reemerged. No one knows what the right approach to scaling blockchains should be. That is why it’s an interesting topic.
BlockBase focused on scalability right from the start. The main reasoning behind our approach to scaling BlockBase stands on the idea that everyone that needs a blockchain, should have one tailored for them, instead of having to default to the same blockchain as everyone else, and having to adapt to that blockchain’s throughput, security, and cost. Currently, blockchains are thought of as a one fits all solution, and that is a mistake that results in dire consequences. Just look at what’s happening with Ethereum. Given enough demand, that blockchain has ceased to offer a cost-effective service for most types of usages. It may make sense for DeFi applications, where speculative investors are willing to pay the transaction costs with the prospect of winning high returns, but for any other types of activities that are not speculative in their essence, using Ethereum for them is prohibitive due to the sheer costs involved.
Given enough demand, any blockchain can be cornered into a situation like Ethereum. Therefore, we chose a different approach. The BlockBase Network requires a main chain to operate but doesn’t store much data there. Instead, it runs sidechains to that main chain, and it’s there where all data is stored. These sidechains are regular blockchains, but we call them sidechains because all their block headers are published on the main chain. This approach conveys integrity to the sidechain structure, because anyone can verify its block headers on the main chain and compare them with the ones on the sidechain. Furthermore, it doesn’t pollute the main chain with data that may not even be important in the future. For example, some information that is mandatory by law to store for five years, but after which can be deleted and forgotten. This translates to a sidechain that exists for five years, but that then can be forgotten, in which case the main chain would only keep the block headers from that sidechain forever.
The number of sidechains that the BlockBase Network runs isn’t predefined. These can be requested on demand to the network. Depending on the sidechain configuration that is requested, each node of the provider network will decide independently if it wants to participate on the provision of that sidechain or not. This decision is mostly an economical one, and it’s required because sidechains may have different types of requirements and varying amounts of rewards. Specifically, a sidechain request specifies the number of providers it needs, the block sizes and block times, and also the reward in BBT per block produced, as well as the collateral the provider will have to stake in order to participate, that he will lose if he fails to produce the sidechain accordingly.
This creates a free market economy around the resources of the network. A provider may choose to participate on as many sidechains as he wants, provided he can maintain the production of all those sidechains simultaneously.
Since each sidechain request asks for a specific number of providers, depending on the incentives to participate, the number of providers willing to participate will vary. If the number of providers willing to participate is larger than the number of providers requested, a random selection occurs that benefits providers with a larger stake. This incentivizes providers to have more skin in the game by incentivizing them to raise their stake/collateral in the service they are providing.
When a sidechain starts, the selected providers will produce blocks in a round robin fashion, with a federated consensus. This means that every produced block must have at least more than 50% of approval from the providers in order to be accepted as a valid block.
The sidechain request, providers candidatures, providers selection, sidechain production start, next block producer selection, timely block production validation, signatures threshold checking, provider banning, and provider payment, is all done through the smart contracts in the main chain, through which all nodes in the network communicate and organize themselves. The smart contracts enforce the required behavior from the providers that are participating on sidechain production. Every time a provider produces a valid block for a sidechain, he will be paid with BBT during the settlement phase, that happens periodically.
With this model, we’ve provided a straightforward way to run sidechains to a main chain.
The BlockBase team is currently running a sidechain with 20 providers producing blocks every 10 minutes. This requires about 24 transactions on the EOS blockchain every 10 minutes for production coordination and for storing the sidechain block headers. If the EOS network could sustain a throughput of 4,000 transactions per second, something it has achieved before and will only get better at it, if that could be applied solely to running BlockBase sidechains like the one described above, it would be able to run 100,000 sidechains simultaneously. Yes, you read it right. One hundred thousand sidechains.
Published by Ricardo Schiller Lead Architect of BlockBase.Network
