This post is the second in a two-part series on Containerization & The Future of Decentralized Infrastructure. The first part can be found here.

Containers and the SKALE EVM : Creating a Chain in the SKALE Network

A validator node consists of a node core and up to 128 virtualized subnodes. Each subnode is a Docker container. A new elastic sidechain gets created in the SKALE Network via an API call to the network that specifics the size of the chain and various provisioning options along with the deposit of SKALE tokens to allow for provisioning of the network resources. Each sidechain will have a default number of 16 nodes.

Sizes of SKALE sidechains can be small, medium, or large. A small chain will be allocated 1/128 of the node resources, a medium chain will receive 1/8, and a large chain will get the full node (aside from the node core). The duration of provisioning can be 6 months,12 months, or 24 months.

Once tokens have been deposited into the network to create a chain, the SKALE Manager will cause the random selection of 16 nodes from the available node pool with capacity sufficient to handle the chain. As part of this process, the contract will send messages to each node to create the appropropriate subnode for this new chain.

The way this works is the SKALE Manager will connect with the SKALE Admin plugin within the node, which in turn instructs the Docker Engine to fire up a SKALE EVM image and allocate the appropriate amount of resources for the chain.

Similar to a Decentralized Hotel Reservation System

One way to look at the process is not unlike booking a set of rooms in multiple locations via a hotel chain reservation system. The reservation system will maintain a global view of room availability across the network and therefore be in a position to determine availability at each location. They can see which locations are able to accommodate the request – whether it’s for a single room, a small block of rooms, or even the entire hotel. Once availability is determined, it can send a request to reserve the room or rooms within each hotel. It is the responsibility of each hotel to then make sure the rooms are available and provisioned upon check in.

The difference here is that the allocation and selection is performed on a random basis across the entire node pool via a smart contract running on the Ethereum mainnet. Additionally, the provisioning of subnodes is done via calls to each node (via SKALE Admin) to create a subnode container and provision it in the appropriate size.


A virtualized subnode essentially consists of the SKALE Ethereum Virtual Machine (EVM) operating with a specific allocation of node resources in accordance with the node size (small - 1/128, medium - 1/8, or large - 1/1). The EVM implementation that the SKALE Network uses is the ETH1 EVM version (github). (Note that it was formerly known as the cpp-ethereum project.) It is a collection of C++ libraries and tools for Ethereum including the Ethereum client ethereum/evmone.

The only difference between the SKALE EVM and the standard ETH1 EVM is that the consensus algorithm in the standard EVM has been changed from a Proof of Work algorithm to a ABBA-based Proof of Stake algorithm. (ABBA stands for Asynchronous Binary Byzantine Agreement.)

It’s noteworthy to mention that the consensus algorithm is loosely coupled within to other elements within the EVM is and so it’s possible to swap in different algorithms (in this case a more highly performant proof of stake algorithm) but still maintain all the security and cryptographic measures that has made the Ethereum Network the trusted network that it is. (Note also that the SKALE design also allows for other consensus algorithms to be included, provided they satisfy certain properties, giving SKALE chains unprecedented flexibility and adaptability in this area.)

Because of its container-based approach, the SKALE Network is able to easily and securely support new versions of the EVM when they are made available. EVM updates are not all that frequent but when they happen, there is a stated desire with the mainnet to change over relatively quickly. Note that the Solidity language is compiled into the EVM and so any changes to Solidity are typically reflected in the next upgrade of the EVM.

While it is advantageous for dApps to make use of the most current version of the EVM, it is possible via the use of Docker and containers to run older versions of the EVM within the SKALE Network. (Questions on how to do so should be directed to the SKALE Network support team.)

Network Security via Random Node Selection and Frequent Node Rotation

Traditional sidechains gain performance and low latency by using a smaller number of validator nodes but at a potential risk to the transaction integrity (under the theory that smaller sets of nodes are more susceptible to collusion and bribery). The SKALE Network counteracts this security risk by using a pooled validation model. This model leverages the security advantages offered by a large number of validator nodes by combining random node assignments with frequent node rotation among the validator sets. Therefore each independent sidechain is protected with the resources of the entire network.

Validator nodes are assigned to elastic sidechains via a random process that is arbitrated by an Ethereum mainnet contract. Security of chain consensus is further protected via frequent node rotation. Nodes will be removed from one or more chains on a non-deterministic schedule and new nodes added.

The use of containers also plays a big role in the way that nodes are rotated. This node rotation takes place while a sidechain is in operation, and so while it may not be as complicated as swapping out a jet engine on an airliner in flight, it does take planning and cooperation between current and new subnodes.

Once allocated by the SKALE Manager, a new node will be set up as a subnode (i.e. a SKALE EVM container). A Linux btrfs snapshot will be taken of the current subnode’s subvolume storage and then transferred to the new subnode and mounted. Because the chain is still running and creating new blocks during this process, some catchup procedures are needed to fully sync the nodes. Once this is accomplished, the new subnode will take the place of the old one in the validator set and transactions will be sent to this new node instead of the old one.

Similar to Changing Players in a Hockey Game

One way to look at the rotation of validators in a SKALE Network sidechain is the way hockey players are substituted within a hockey game. Instead of timeouts, players are substituted on the fly with one player skating off and another skating on. The difference here is that the new subnode is an exact clone of the replaced subnode. Additionally this new subnode gets selected at random among the pool of available nodes.

The Case for Containers (and Virtual Subnodes) is Clear

The decision to use containers as the way to create an elastic and virtualized subnode structure is not all that surprising given the growth and results seen in cloud computing and in traditional virtualized systems. What is surprising is the number of advantages and the future possibilities that containers provide within a decentralized network.

These benefits have become well known to the SKALE Network development and network support teams as they launch more and more sidechains and see how composability, agility, and adaptability make it easy to build, develop, and use elastic sidechains. The use of containers addresses serious pain points to the rollout of the SKALE Network without any significant pain points or overhead. It has increased the core team’s ability to develop and innovate quickly as well as add new capabilities.

Just as importantly, however, the use of containers gives the SKALE Network the ability to maintain and even surpass the service guarantees the network has established. After launching thousands of sidechains and spawning and rotating tens of thousands of virtualized subnodes, the case for containers is clear. It is a key enabling technology that is a foundational element of the SKALE Network. It will serve as a means to create a highly secure and performant network now as well as increase the capabilities and features of the network in the years and decades to come.