As Layer two solutions begin coming online, it's becoming more and more evident that it will be where the vast majority of execution will take place in decentralized networks. For that reason, it is critically important for Layer 2, the “Execution Layer”, to be configurable, fast, cost-effective, and secure without compromising decentralization.

In this post, we’ll take a close look at the advantages and tradeoffs of these popular Execution Layer solutions:

  • Sidechains
  • Elastic Sidechains
  • State Channels
  • Plasma


Sidechains are independent blockchains which work in a complementary fashion with another blockchain to provide enhanced functionality and lower costs. This functionality can include but is not limited to transactions, smart contract execution, and storage. Sidechains add value by acting as a lower cost and higher throughput augmentation to slower, more expensive, but generally more secure Layer 1 chains. Typically, the primary chain they support is the Security Layer which acts as the foundational store of value and place of settlement.

One of the best things about sidechains is that they can service users' requests and interaction while leveraging the security layer to ensure that any value remains safe. Users are able to experience high speeds, fast finality, and low costs with minimal disruption. Setup can also be made incredibly easy assuming the sidechain is designed to be interoperable with the main chain and ecosystem.

Although sidechains come in many shapes and sizes, most people are familiar with those of the PoA or DPoS variety. One of the caveats of these types of sidechains is the fact that the validator sets of these sidechains could be compromised to censor users, pause the chain, or even act maliciously to collude and attempt to steal funds from them. In many scenarios, centralization in the Execution Layer can put at risk and compromise the mission and incentives of decentralized systems. Elastic Sidechains are a major improvement on this model (explained below) in that they are fully decentralized and do not have the same centralization challenges.

In traditional sidechains, a group of validators is appointed through PoA (where they are staking their identity / reputation) and DPoS (where they are staking value in the network). And while DPoS is a protocol where the users are potentially able to effectively move validators in and out of the current set by reallocating their delegated stake, we see that that does not happen with the real world deployments… instead, we see the formation of cartels, where the power of the delegates is then consolidated yielding a new form of centralization.

Given those caveats, there are still advantages to having a completely separate blockchain . Principally, that by using them you remove many of the limitations faced by existing developers on the Ethereum mainnet (cost, limitations on computation, limitations on storage, etc…). But, again, PoA or dPOS chains are not fully decentralized.

When to Use

Sidechains are best suited for dApps that require cost-effective smart contract execution where there isn't a large sum of money being managed. Other use cases include those which do not require decentralization for their business model and those that accept reputation as an input to validator onboarding.

Elastic Sidechains

SKALE has pioneered a new category within the Execution Layer called 'Elastic Sidechains'. Elastic Sidechains provide all of the benefits of traditional sidechains alongside the security guarantees of truly decentralized networks. So, how do Elastic Sidechains address the concerns associated with traditional sidechains?

When creating a sidechain, the validators which participate in the network are randomly assigned (in the SKALE Network via the SKALE Manager on Ethereum) from a prospective validator pool. This prospective validator pool is comprised of the various nodes in the network that have availability to participate in additional sidechains.

Note: The 16 nodes here are a simplification of the network, the live network is intended to have as many or more nodes as Ethereum.

Nodes are able to support multiple sidechains whereby each virtualized subnode within them is able to run on a separate sidechain.

I’ll describe some examples here with non-real world numbers (most chains will have 16, 32 or more validators, not 4 or 8).

If I (red) were to create an Elastic Sidechain, I could require that it has 4 validators which each use 25% of a node’s resources. This could lead to the following:

And if another user (blue) wished to provision themselves an Elastic Sidechain with 8 validators with 50% of each node’s resources, the validator set could look like the following:

And users would be able to continue provisioning Elastic Sidechains to the point that ~70% of the entire network’s resources had been used — at least 30% of the network needs to be free at any point in time to ensure new dApps joining the network have a large enough pool to prevent collusion amongst nodes with available space and support randomness. At this point, more nodes would be needed to participate in the network to meet user demand. Price to deploy one of these chains would adjust dynamically to properly incentivize new nodes to come online.

Decentralization, flexible capacity, and validator rotation

Now, you may be concerned that with such small validator sets that nodes will easily be able to collude. Well, in the case of the SKALE Network, that’s where the SKALE Manager on the Ethereum mainnet comes into play. When creating your Elastic Sidechain, users configure how often the validators for their chain are shuffled — mitigating the possibility of collusion by validator sets. Shuffling the red validators may produce something like the following:

And to further disincentivize poor network behavior, nodes in the network are staked on the Ethereum mainnet and rewarded / slashed based upon the collective behavior of their validators. This behavior is monitored by 21 peer nodes in the network assigned to the node upon joining which report on the node’s uptime, latency, and network behavior at regularly scheduled network epochs. Those nodes which serve the network with good behavior will be rewarded while those acting poorly will be slashed and potentially removed.

When to Use

Offering users the best of sidechains and decentralization, Elastic Sidechains are best suited for dApps that require decentralization, fast finality, and cost-effective smart contract execution. The best use cases include those with with small transaction amounts and a requirement to run a high volume of smart contracts. While we would love to see higher-value transfers on the Elastic Sidechains, low volume and high monetary value on the chain are not a good fit until networks have been proven over time.

And Elastic Sidechains scale with your business! Just as startups leverage EC2 where they start small and grow, dApps can start small and grow their deployment along with their needs. Configurability combined with the decentralized nature of the network allow for this to be a robust and user-centric approach to blockchain development.

State Channels

At their core, state channels reduce on-chain interaction between two parties to channel creation and channel settlement — everything in between is exchanged in an off-chain manner, allowing for extremely high throughput and low latency. And if the two parties have written their on-chain logic correctly, they will always be able to immediately settle to the chain in the case of a dispute.

These are what we refer to as ‘App-Specific’ state channels, which an be created in a modular way such that any multisig is able to leverage them — preventing redundant deployment of the same code to the chain. In this way, these smart contracts serve as microservice plugins for the multisigs that you have.

The multisg serves to proxy transactions to the respective business logic contracts which will return some value to the multisig for updating its balance or indicating that the channel cannot yet be settled.

This model vastly improves upon the existing paradigm of every dApp or service needing to deploy a completely new smart contract by transitioning to a microservices-esque architecture. And this model can be improved further with 'counterfactual instantiation', whereby the contract is only deployed if / when there is a dispute between the two parties — allowing for the possibility that the contract is never deployed at all. But, it's likely that the contract will likely be deployed at some point, so might as well deploy it and try to get as many people using it as possible.

But state channels don’t cover all use cases. Each implementation (that we’ve seen) only serves two-party channels, disallowing the one-to-many or many-to-many use cases which embody the ideas of governance, massively multiplayer online games, etc... But, as a counter to the weakness on that front, channels do provide for an incremental improvement in privacy and payment streaming.

Perhaps one of the biggest problems with state channels is the fact that all users will have to maintain a full record of all of their channels and risk having their counterparties settle their multisigs in the event that said record is lost or that they fall offline for an extended period of time. But these restrictions can be relaxed with constructs like incentivized ‘watchtower’ networks which will keep a backup of your state and contest any disputes on your behalf in the case that you fall offline.

When to Use

State channels are best for conducting private transactions for the settling of conditional payments in a way which relies on the security of the mainnet. If you are planning on implementing these, you should recognize the burden that they put on users and and deploy a strategy for addressing those via some watchtower service or similar. dApps that have high users-user transaction volume between a common set of users are also great fits.


While many flavors of Plasma exist, they all effectively embody the idea of periodic on-chain notarization. Each instance of Plasma has an on-chain smart contract which allows for participants to enter / exit and for the chain’s single validator (‘operator’) to submit merkle root hashes for transaction tries from the Plasma instance. Each Plasma contract also ships with on-chain logic for evaluating proofs of inclusion / exclusion that allow users to ‘Plasma Exit’, or to withdraw their funds from the Plasma contract without cooperation from the operator.

Plasma has a forced simplicity given the fact that all transactions which occur through it need to be able to be validated on-chain. This said, each Plasma contract has logic within it to evaluate a set of defined transaction types. These transactions are included in the transaction merkle trie which is created by the operator and have their root submitted to the Plasma contract.

If a participant wishes to show the current state of their funds stored in Plasma and exit to the main chain, they must replay their transaction history for each block to the Plasma contract. During this process, the contract will validate that each transaction was included for a block (proof of inclusion), that transactions weren’t skipped (proof of exclusion), and create a pending exit for the participant (assuming that the transaction history was valid). If nobody challenges this participant's exit by demonstrating that they have spent the funds they are now trying to exit after a dispute period, the user will be allowed to withdraw their remaining funds from the Plasma contract.


The H’s stand for a hashing function and data is hashed from the bottom of the ‘tree’ with its neighbor until a single hash is made (‘the root’). The root is what gets submitted on-chain and everything in blue is what is needed to create the root to show that A was included in the block. In the case of showing that A was not included in a block, one would perform a 'proof of inclusion' with null as the value instead of A. For more information on this merkle trees and these proofs, please check out this article.

Plasma can almost be thought of as a kind of state channel between multiple parties which is orchestrated by a single entity. This entity is like a bouncer who can prevent people can prevent people from entering, but cannot prevent them from exiting. This said, Plasma is not a state channel for the fact that  state channels are held between two parties and are not regularly notarized to the mainnet. The main reason for drawing the comparison was to point out that Plasma also faces the problem of data unavailability and liveness for users.

In the same manner as state channels, Plasma also requires that users maintain the entire transaction history for their funds on Plasma — including the blocks in which their funds were not transferred (proofs of exclusion). This places a huge obligation on participants as the history size for all included and excluded transactions can balloon to the order of GBs (in some cases) over the course of a year. But there are a number of implementations working to relax these requirements / limitations.

When to Use

Plasma has a lot of promise, but is still a nascent technology and improvements are being made on a weekly basis to address the issues outlined above. Use cases which are embodied by Plasma include the facilitation of payments or exchanges between multiple parties. If you are wanting to use Plasma, it may best suit you to create a use case specific Plasma such as Gluon (Non-Custodial Exchanges) to meet your needs or to use Plasma as an SPV (Simple Payment Verification) and underlying value store for a sidechain. dApps with high frequency transactions/payments that do not require high-volume smart contract execution are great fits.

Learn More

Hopefully this article provided some illumination on the different kinds of sclaing initiatives underway in the ecosystem for the execution layer!

If you are interested in trying out SKALE’s Elastic Sidechains out, make sure to join the SKALE community on Discord and check out the Developer Documentation! Also, feel free to also check out SKALE’s Technical Overview and Consensus Overview for a deeper dive into how SKALE works and is able to provide 20,000 TPS.

SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. Follow us here on Telegram, Twitter, Discord, and sign up for updates via this form on the SKALE website.