The SKALE Tech-Stack
By: Chadwick Strange
Tags: Ethereum, Skale Technology, Scalability, Blockchain, Smart Contracts

The SKALE Tech-Stack

SKALE Architecture and Layer 2 Scaling Solution

After months of being heads down researching, developing, and benchmarking, we’re proud to be able to present a peek into the SKALE architecture! If this article leaves you wanting more, feel free to join the SKALE Telegram group and apply to the SKALE Innovator Program!

Built to SKALE

SKALE is a network of sidechains “S-Chains” run by independent validators located around the world. Validators run “SKALE Nodes”, which contain a number of containers / components (more on this later), and can participate in multiple sidechains.

One SKALE Validator can run multiple S-Chains simultaneously, whereby the number of validators and capacity of each S-Chain is configurable by users of the system. S-Chains are created and managed through the SKALE Manager located on the Ethereum blockchain. This SKALE Manager is a series of smart contracts responsible for:

The registration of validators with the SKALE Network

The orchestration and creation of S-Chains

The performance measuring of nodes in the network

Developers can interact with the SKALE Manager directly or through the Developer Portal provided by SKALE. To create an S-Chain, users can rent space on SKALE nodes by depositing SKALE tokens into the SKALE Manager either directly or through the Developer Portal.

S-Chains

When creating an S-Chain, we leverage a source of randomness (hash of the block number on the testnet, Verifiable Delay Function (VDF) on the mainnet) for the selecting of a committee of participating nodes. To thwart collusion in the network amongst nodes in the same chain, we have a randomized shuffling mechanism which will leverage our source of randomness to move nodes between various S-Chains. The Byzantine Fault Tolerant (BFT) S-Chain consensus can tolerate < ⅓ nodes that fall out of the network or go offline. If > ⅓ nodes fall out of the network or go offline, the S-Chain will pause until they come back online after a predetermined timeout or until new resources are load balanced and allocated to serve the chain. Consensus then resumes.

Now that we’ve got an S-Chain, you’re probably wondering — “How does it work?” To begin, your S-Chain ships with the SKALE EVM — a modified EVM using key-value store with LevelDB instead of a patricia trie for faster throughput. For their consensus, S-Chains use SKALE Parallel Asynchronous Consensus (SPAC), which is based on the parallelization of a variant of Asynchronous Byzantine Binary Agreement. Consensus is reached by validators in the network who may be running a node for one or multiple S-Chains.

The process of publishing blocks is a two-step commitment. First, each node in an S-Chain races to propose blocks in parallel with other members and receives signature shares in return. Once any one proposer has received a threshold of signature shares (⅔) from other nodes, the proposer combines them into a threshold signature, and broadcasts this threshold signature to all other S-Chain nodes. In this process, we use the Gap Diffie-Hellman (GDH) signature scheme of Boneh, Lynn and Shacham (BLS) — which we will discuss in further detail in a future post. Secondly, after threshold signature creation, each node then conducts asynchronous binary consensus by broadcasting a binary vote for each proposal to all other nodes whether it is in possession of a block proposal and threshold signature. Nodes that successfully create blocks will have a reward set aside for them and be rewarded after a predetermined epoch (TBA) based upon a score they receive (0–1) by their validating nodes.

One Additional Note on Security

While SKALE employs slashing for its validators as well as mathematically proven cryptography, participants of the network are still susceptible to their funds being stolen in the off-chance of collusion by ⅔ of the nodes in the network (a caveat of BFT systems). To mitigate this and similar attack vectors, we are building configurable options to provide even greater security measures to SKALE. In a later post, we will dive into one of these solutions being explored — parallel execution between both S-Chains and Plasma within the SKALE Network.

SLA Manager

To encourage good behavior and ensure high performance within S-Chains, SKALE has incorporated an SLA Manager in its system. Nodes in the network are rewarded based upon an algorithmic peer review system. Nodes which fall offline or have poor performance in the network will receive little or no reward for their mining efforts.

SKALE rewards its validators in epochs, whereby rewards will accrue over time in the name public key of each node, but will only be rewarded at the end of each epoch. When nodes are created, they are assigned the duty of scoring a subset of other nodes (e.g. 21) based on network parameters (which are not on their S-Chain) using our system’s source of randomness (hash of the block number on the testnet, VDF on the mainnet).

At the end of each epoch, nodes receive a score of 0 to 1. This score is derived from the remaining third of the ordered list of scores after the top and bottom third have been removed (so as to deter collusion and mitigate malicious intent). This score is then multiplied by the bounty which is paid out to the node. Bounties which are not paid out are accrued by the SKALE Manager Contract and will be used to help fund the bug bounty pool as well as various open source efforts.

Validators

A decentralized network is nothing without its validators! To become a validator, download the SKALE software package and launch it on your machine. In order to join the network, you must stake SKALE tokens and agree to uphold a certain uptime percentage decided upon by the SLA. Those who fail to uphold the terms of the SLA will receive a lesser portion of rewards from the network.

SKALE ships as a dockerized Linux image with the following containers:

SKALE Admin Container

This is the admin interface for validators to deposit, withdraw, and stake SKALE tokens — the admin interface also handles communication with the SKALE Manager (located on Ethereum mainnet).

SLA Manager Container

Communicates to SKALE Manager and tracks performance of other nodes that are not on the S-Chains being run by your node(s). The SLA Manager assigns scores between 0 and 1 to its peers which will determine the payout at the end of an epoch.

MySQL Database Container

The MySQL database is used to store performance measurements of other nodes from the SLA Manager.

Agent Container

The agent is a small microservice which handles the collection of the bounty over time from the SKALE Manager.

S-Chain Container

The S-Chain container has a web3js connector and is created by the SKALE Manager on Ethereum. This container holds the logic for SKALE Parallel Asynchronous Consensus (SPAC) as well as the SKALE EVM.

This paints the following picture:

Deployment with SKALE

Deployment with SKALE is straightforward to anyone who has written decentralized applications with Ethereum in the past. Just follow these steps:

To begin, create your decentralized application and parse out the pieces of your smart contracts that need to scale as separate smart contracts (these will be deployed to an S-Chain). After parsing out the pieces of the smart contract which need to SKALE, add SKALE’s messaging middleware to your Ethereum smart contracts — this middleware will allow your smart contracts on Ethereum and SKALE to communicate. Point your deployment scripts for your SKALE contracts to your S-Chain’s address and deploy using existing tooling (e.g.: Truffle). Lastly, begin using your scalable decentralized application!

Admittedly, this process is subject to change with data that we collect from some of our early users, but we will be releasing another article covering deployment with our learnings, very soon!