A central tenet of blockchain is decentralization and distribution – indeed a common acronym used with blockchain is DLT, Distributed Ledger Technology – but there is still a central chain that constitutes any particular Blockchain. The blockchain is a distributed database that stores its current state and all previous states (history) on each full node. Thus, each node has a local, duplicate copy of the entire database, and the information contained therein is identical. The bits and bytes are dispersed across the planet, but the information contained therein is singular. Security and consensus are essential for distributed systems, and agreement on which history is correct is most commonly achieved through Proof of Work (PoW) consensus, which employs cryptographic methods.
Unfortunately, PoW’s competitive race wastes considerable computing resources. After all, thousands of miners are competing and only one wins. Moreover, transaction times on many popular platforms are measured in minutes or seconds, not milliseconds like other modern computer-based transactions.
Congestion on the blockchain leads to slower transaction times, higher fees, or both. One blockchain’s protocol and implementation may not optimally support all potential applications for that chain (especially when it comes to efficiency), and every modification requires testing. However, experimentation on a distributed system can be difficult and costly. So far, a major barrier to widespread cryptocurrency adoption is slow transaction times, while high fees or congestion continue to inhibit mainstream adoption of blockchain for other purposes.
A promising solution is to modularize where the data is stored and processed by using sidechains that branch off from the main blockchain.
What is a sidechain?
The term “sidechain” implies a secondary distributed system that sits alongside the “mainchain” but does not interact much with it. For most purposes, these are small, application-optimized blockchains, but it is important to keep in mind that sidechains are still full blockchains in their own right.
Sidechains contain all of the essential components and characteristics of blockchain, including a consensus algorithm, immutability, and the ability to be distributed and decentralized. A sidechain can use a different consensus algorithm from its mainchain and the latter’s rules of validation and transaction types. Furthermore, a sidechain may be private but is not required to be.
Sidechain transactions are not offchain transactions. Offchain transactions, such as those that take place at cryptocurrency exchanges, are fundamentally different: they have a trusted custodian or other central party that safeguards the data and maintains the record of transactions. Offchain transactions generally are not distributed or decentralized, and they usually are not immutable or driven by a consensus algorithm.
Sidechains are attached to their associated mainchains through a process known as pegging. Explained more below, this process locks assets on the mainchain and converts them to sidechain assets, where a completely different set of nodes may handle the transactions.
It is important to note that sidechains are contextually-based: while Bitcoin and Ethereum are mainchains in most instances, they can still be sidechains when the application focuses on another chain. Of course, when the mainnet Ethereum or Bitcoin network serves as a sidechain, the history and protocols of Ethereum or Bitcoin must be observed – as we must observe the rules of any blockchain on which we transact. The mainchain is always the blockchain from which the asset in question originated, and all others are sidechains.
The Drawbacks of Mainchains
Blockchain is a magnificent technology concerned with decentralization of authority, security, and redundancy protection from failure. However, the structure of blockchain leads to inefficiencies and scalability problems.
Particularly in Proof of Work schemes, the high level of wasted computing resources makes scalability a challenge. When the number of transactions unexpectedly spikes, such as when a blockchain suddenly enjoys mainstream adoption, the high number of transaction validations causes network congestion. A notorious example is the explosion in popularity of CryptoKitties on the Ethereum blockchain, during which CryptoKitties transactions flooded the network, spiking network fees and slowing down the average time to validation for other transactions. With a sidechain specifically optimized to CryptoKitties, the main Ethereum blockchain could have been spared congestion (and CryptoKitties could have gained an efficiency boost).
High-profile mainchains must also propagate their blocks to the large number of participating nodes. Including more transactions per block unnecessarily strains public networks and takes up space on full nodes that contain the entire blockchain history. Lots of small, application-specific transactions can be stored on sidechains while the mainchain is left to higher-level transactions.
In cryptography, there is always a tradeoff between efficiency and security. The focus on openness and distribution drives a need for security, and this in turn reduces efficiency. A sidechain may implement a sole trusted validator to improve efficiency and transaction speed, but it would lose the security and openness of its mainchain counterpart. However, in some applications, this is perfectly acceptable.
Another drawback of running all transactions through mainchains is the expense or even inability to experiment. It can be difficult to implement changes to the mainchain because all other participants must accept and install the changes. Moreover, when experimenting, it may even be dangerous to roll out changes without proper verification. A clone of the mainchain is the perfect way to experiment with either the fundamentals of the mainchain or with new applications eventually destined for it. Smart contract and application developers can avoid fees during experimentation while still testing in a near-identical simulation of the real environment, too.
In addition to application and smart contract testing, the Proof of Stake consensus algorithm protocol itself benefits from sidechain experimentation. Because sidechain and mainchain assets are related, and the latter have real-world value, the real-world cost of attacking an experimental PoS sidechain can become prohibitively expensive. This introduces some security to experimental PoS sidechains in contrast to standalone, nascent PoS mainchains. The standalone chains risk being taken over with lower real-world investment, but attackers must be much more motivated to obtain a reasonable stake in a sidechain linked to a widely-valued mainchain.
A final drawback of mainchains is their narrow scope: there is generally a single asset that can be freely spent on the mainchain, siloing them into their own networks. Tokens that are minted through smart contracts can greatly expand the scope of assets on a single chain, but the underlying asset is still the sole mainchain asset. With sidechains, interchain conversion becomes possible.
Pegging – The Transfer Mechanism
Sidechains must interact with their associated mainchain, or they would just be another siloed mainchain themselves. In order to do so, they use a pegging system, which allows for a predetermined exchange rate between assets on the two chains. This can be fixed or variable, but, if the latter, the variable rate should be deterministic to ensure conversion is predictable.
Symmetric two-way pegging is the most common method, while two other methods are asymmetric pegging and federated pegging. Pegging is usually automated with software, but it is possible to have a manual custodian.
Symmetric pegging consists of four steps:
- The asset is locked on the mainchain
- A period of time is waited out for integrity purposes
- The asset is released and spendable on the sidechain
- Reversion follows the same procedure
In the second step, there are two waiting periods: the confirmation period on the outgoing chain (OC) and the contest period on the receiving chain (RC).
Let’s look at it from the perspective of the mainchain being the OC and the sidechain being the RC. The locking mechanism is initiated when the mainchain asset is sent to a particular holding address. The receipt of the asset triggers a Simplified Verification of Payments proof (SVP proof), a data structure that verifies a transaction is legitimate without the need to validate the entire history of the blockchain. Here, the purpose is to demonstrate to the sidechain that the transaction sending the asset to be locked is accepted by the mainchain. .
Then the confirmation period is waited out so that later blocks are added to the OC, solidifying the transaction in the OC history and reducing the risk of a reversal of transactions. This reduces the likelihood of an asset owner having both the OC asset after the rollback and the RC asset – effectively double spending power, but on two separate chains.
Next, the output from the SVP proof is referenced on the RC, and the contest period is waited out. This serves a similar purpose as the confirmation period, preventing double spending.
Finally, the asset is released on the RC and is ready to be spent. The mainchain is blind to the sidechain transactions, and the OC only knows an asset was sent to a specific address. To convert back to the mainchain asset, an owner would send the sidechain asset to a similarly SVP-producing address, which would trigger the SVP proof and follow the same steps above.
A major advantage of symmetric pegging is that the nodes on both chains can be completely different entities. However, sometimes all the nodes of the sidechain are mainchain nodes, too. When this happens, asymmetric pegging may be implemented. The conversion from mainchain to sidechain does not require the SVP proof, because all sidechain nodes know when a mainchain asset is received at the special address. However, because not all mainchain nodes see the sidechain, the SVP proof is still required to convert back to the mainchain.
Federated pegging nominates a group of validator nodes to lock and unlock assets on both chains rather than using SVP proofs. The sidechain designers nominate the federation, and it can even be a single node that has absolute control over locking and unlocking – not the most secure, but certainly efficient.
For nascent sidechains in need of participating nodes, one potential solution is merged mining. Merged mining is the practice of mining on two blockchains simultaneously, with the auxiliary chain (the smaller sidechain) set up for merged mining. Simultaneously mining consumes fewer resources than mining two blockchains independently, and the miner still has the advantage of potentially receiving the parent (usually mainchain) reward. Thus, some smaller blockchains allow merged mining.
Sidechain Security
One of the main goals of blockchain is openness and security, which competes with efficiency. But if sidechains are more efficient, is security inadequate? The answer depends on multiple factors, but the final determinant is the acceptable level of security for the application. Some applications can afford less security or rely less on zero trust.
Sidechains are entirely responsible for their own security. Even cloned mainchains do not run on all the nodes that the original runs on, and the security of the clone is the responsibility of the nodes that run it. The sidechain may be vulnerable to 51% attacks, wherein an attacker acquires more than 50% of the consensus power and therefore can probabilistically dictate the history of the chain, breaking distributed consensus. For small sidechains, this can be easily accomplished by purchasing sufficient equipment (in PoW schemes) or sufficient assets (coins/tokens) to make a large-stake claim (in PoS schemes). Of course, small sidechains can be permissioned, refusing the participation of any untrusted nodes, but this does eliminate the common blockchain goal of open participation.
Moreover, implementation choices can alter the security levels. Sidechain consensus and cryptographic algorithms are chosen by the sidechain designers and are independent of the mainchain implementations. An in-house cryptographic algorithm can be used on a sidechain for experimentation, though in-house algorithms are a very risky approach to cryptography and should be avoided on any non-experimental blockchains.
Additionally, sidechain designers choose the consensus algorithm. Proof of Work is awfully inefficient, so Proof of Stake may be chosen. However, the designers may prefer a highly efficient single validator node with very low block difficulty, which would essentially act as a trusted custodian for the sidechain. Such an approach forfeits the advantages of decentralization and distribution, but it does mean work is not wasted. For single-validator schemes, it would be wise to choose stronger security standards around protecting that node.
In merged mining applications, the auxiliary chain must use the same hashing algorithm as the parent chain. Otherwise, the node would need to run both processes and negate all of the benefits of merging.
Sidechain Compromise and the Mainchain
What happens if the sidechain falls victim to a successful attack? Will the mainchain be affected?
If a sidechain is successfully attacked, the mainchain is usually uncompromised (barring the breaking of a shared cryptographic algorithm). The mainchain is insulated from sidechain problems, because to the mainchain, the only transaction it recognizes is that some of its assets were sent to a particular address (the special locking address), where they will remain until sent elsewhere.
Sidechains contain a weakness centered around the reversion SVP-proof mechanism: if a malicious actor succeeds in generating correct SVP proofs from the sidechain, the mainchain assets will be unlocked and spendable. The mainchain is unaffected, but such a breach of user trust would be catastrophic for the sidechain. Any enterprise user should inspect the asset exchange logic to ensure robustness. Private individuals may not have the requisite knowledge to inspect the logic thoroughly – or the time and interest to do so. For them, sidechain designers should consider publishing a clear, easily-understandable explanation, which might help boost sidechain uptake.
On the mainchain side, if the mainchain is compromised, the sidechain is usually catastrophically disrupted. The sidechain can continue to operate, but because real-world value is usually tied to the mainchain, the value of the sidechain assets tends to dissolve. When dealing with such heady topics as blockchain, it is easy to lose sight of the fact that we use blockchains for real-world value applications. If that value evaporates from the mainchain and no one wants to use the system anymore, the sidechain can easily be decimated in the process. So technologically, sidechains are capable of persevering, but without the mainchain, they often lose their value and users, leading to failure.
A Few Common Uses of Sidechains
Several uses for sidechains have been hinted at in this article. Here are some common uses of sidechains.
As mentioned repeatedly, sidechains can improve efficiency in two main ways: reducing load on the mainchain and optimizing the sidechain for the application purpose. A sidechain optimized for great efficiency can process transaction-intensive applications entirely away from the mainchain (effectively “offchain” from the mainchain’s perspective). Sidechains can also be bombarded with experimental test cases without disturbing the mainchain.
Also mentioned earlier, experimentation is an excellent example of sidechain use. Single machines can run a clone to test out all kinds of applications without congesting the network. Perhaps more importantly, this also means the experimenters do not need to spend fees on the mainchain, as the nodes can be internal to the organization.
Another good use of sidechains is for privacy. As much as Bitcoin is described as “private”, it is private only insomuch as the identity of an address user is unknown. All transactions on public blockchains are published for everyone to inspect. To reclaim privacy, it is possible to use payment channels, but they lose the immutability of blockchain. To retain the characteristics of blockchain but increase privacy, sidechains can be private or permissioned. cutting down the number of entities that can inspect transactions.
One driver of sidechain innovation has been interoperability of established blockchains, particularly in the cryptocurrency space. Exchanges allow the easy and efficient conversion of Bitcoin to Ethereum and between any other pairs of supported cryptocurrencies, but all of it resides offchain and therefore is subject to the bookkeeping abilities and vulnerabilities of the exchange. Since cryptocurrencies have real value in fiat, exchanges are very high-value targets for hackers. The sidechain framework allows entities to transfer spendable value between major blockchains while retaining the immutability, decentralization, and distribution advantages of blockchain.
Sharding, a Special Case
Instead of the two chains in question originating from separate blockchains entirely, sharding breaks one blockchain down into multiple shards, each somewhat like its own sidechain to the global mainchain. The sharded mainchain is more nebulous than in traditional sidechaining, because it is an aggregate of shards, whereas traditional sidechains and mainchains are explicitly their own whole blockchains.
The mainnet of a sharded blockchain usually acts as a guarantor of synchronization across the network of shards by storing data about the blocks (but not the blocks themselves) that reside on the shards. By saving data about blocks, but not whole blocks, transaction throughput rises. Sharding has been heralded as a powerful solution to the scalability problem so often cited as a reason for sidechains in the first place.
Sharding advances blockchain as a distributed computing framework, and, with constantly-increasing transaction volume, distributed blockchain computing through sharding may be able to alleviate the scaling problem.