Layer 2: The Execution Layer

A look at Sidechains, Elastic Sidechains, Plasma, and State Channels

For those of us closely following technology innovation in Layer 2, we are clearly seeing it as the arena 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 methods:

• Sidechains
• Elastic Sidechains
• State Channels
• Plasma

Sidechains

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.

Virtual Machine can live in the sidechain and with appropriate interchain messaging, end users need never know they are interacting with a sidechain. They 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.

Sidechains can come in many varieties, but most people are familiar with PoA or DPoS. These are well known and add value, but are not fully decentralized. It is important to keep in mind 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 (explained below) are fully decentralized and do not have the same centralization challenges.

Effectively the security is dependent upon quality code, cryptography, reputation (in some cases), and incentive dynamics such as stake and slashing. This is why users should be careful about analyzing the security parameters and incentive structures of sidechains and they should be cautious about putting vast sums of money into new and unproven chains.

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 effectively happen with the real world deployments… which leads to the formation of cartels, where the power of the delegates is then consolidated yielding a new form of centralization.

But there are 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 fit all use cases as they are uninhibited by limitations faced by existing blockchains. And, models like DPoS and PoA can hold known validator sets accountable for their actions to dissuade any malicious intent on their part — minimizing risk of an attack on the network. But, this is not a guarantee against such actions by network validators. dApp Use Cases that require cost-effective Smart Contract execution while not keeping large sums of money on the side chain are great fits. Use cases that do not require decentralization for their business model and those that accept reputation as an input to validator onboarding are also good fits.

Elastic Sidechains

SKALE is pioneering 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 such as Ethereum or newer model Layer 1 Chains that offer sharding and rotation of nodes.

Elastic Sidechains are truly decentralized while keeping the UX advantages of traditional sidechains — such as easy setup and low-maintenance for devs, as well as zero friction experience for end users who are interacting with the chain.

Another critical advantage of Elastic Sidechains is that they are configurable so that developers can select criteria specific to their needs. Criteria can include size of chain, required storage, speed, additional security guarantees, etc. These needs can be adjusted to fit their business requirements and optimize cost.

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 due to their container based architecture. Docker containers enable nodes to appropriate increments of their resources to multiple chains.

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 were to create an Elastic Sidechain, I could require that it has 4 validators which each use 25% of a node’s resources. This would lead to the following:

And if another user wished to provision themselves an Elastic Sidechain with 8 validators with 50% of each node’s resources, the validator set would 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 are used — capacity is saved as a security measure to ensure new dApps joining the network have a large enough pool to prevent collusion 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, this may not seem all that grandiose given that these chains are still comprised of a defined unchanging validator set. 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:

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. Nodes serving the network well will be rewarded while those acting poorly will be slashed and potentially removed.

In the event that an Elastic Chain stalls or faults, a fault recovery procedure will take place to resume the chain with newly appointed validators from the validator pool. And if a chain is ever scheduled to be destroyed by the owner, all users will automatically have any funds outstanding from the mainnet on their Elastic Sidechain issued back to them on the mainnet.

The disadvantages to Elastic Sidechains from a security perspective are akin (however highly mitigated) to those of traditional sidechains. All blockchains rely on having a majority of good actors. In the case of SKALE it is required that less than ⅓ are byzantine in order to prevent pausing of the chain and that less than ⅔ are byzantine to prevent double spend. The security advantage of Elastic Sidechains increases as more nodes join the network thanks to random assignment and shuffling. For effective collusion on a single chain in an Elastic Sidechain network, ⅔ of the broader network would need to collude in order to have high probability of making a single chain susceptible to double spend. Incentives also help in this regard with stake and slashing similar to standard sidechains.

When to Use

Elastic Sidechains are best suited for dApps that require decentralization, fast finality, and cost-effective smart contract execution. Use cases with small transaction amounts and a requirement to run a high volume of smart contracts are a good fit. Low volume and high monetary value on the chain are not a good fit until networks have been proven over time. Both small and large deployments can leverage the network due to the configurable nature of the system. 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.

This is what is known as an ‘App-Specific’ state channel, and they can be constructed in such a way so that any multisig is able to leverage them — preventing the 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. And we can improve upon this 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 isn’t deployed at all. But, it’s unlikely that that will always be the case — 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 — all implementations (that we’ve seen) are for two-party channels, disallowing one-to-many cases embodying the ideas of governance and massively multiplayer online games. But, as illustrated by constructs such as the Lightning Network, channels do provide for an incremental improvement in privacy and payment streaming.

State Channel implementations vary broadly based on design, however, user experience for developers and for end users often requires additional effort and workflow. End users must intentionally interact with the state channel. In the case of generalized state channels for end users, this friction is mitigated when all dApps leverage the backend and users must only worry about keeping a balance across the dApps they use. This is however a chicken and egg problem. A helpful analogy is that of a Visa and Mastercard debit card. If you have Visa, then you have no issue working with every vendor. If you have Mastercard or another lesser utilized brand you risk being turned down if the vendor does not support that model. Or conversely, if you are the vendor and only support users with X card brand, you lose business if users don’t have that in their wallet.

If you do elect to build on state channels, you should recognize 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 that record is lost or that they fall offline for an extended period of time. 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. But anyone implementing them should recognize the inherent issues that they burden users with and decide on a strategy for addressing them through some watchtower service or similar. dApps that have many users paying (or exchanging with) users in similar and frequent pairings with high volume transactions are great fits.

Plasma

While many flavors of Plasma exist, they all effectively embody the idea of periodic on-chain notarization. Effectively, 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.

Effectively, the 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. When a participant wishes to show the current state of their funds stored in Plasma, they replay their transaction history for each block to the Plasma contract which 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 participants 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.

Source: https://medium.com/@kelvinfichter/whats-a-sparse-merkle-tree-acda70aeb837

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.

In a way, you can think of Plasma as a kind of state channel between multiple parties which is orchestrated by a single entity who can prevent people from entering, but cannot prevent them from exiting. This said, Plasma is not a state channel, it is Plasma — 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.

It should also be noted that many implementations of Plasma require 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 sort of requirement causes the history size to balloon to the order of GBs (in some cases) for participants who have remained in a Plasma instance for over a year. But again, 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

If you’d like to join the discussion on Execution Layer technologies, want to learn more about Elastic Sidechains, or are interested in trying them 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 high throughput smart contracts at low costs.

SKALE’s mission is to make it quick and easy to set up and configure a cost-effective, high-performance elastic 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.