The SKALE Network- All you need to know.
Date Founded- 2017
Capital raised- 17.1 Million USD
SKL Token Sale- 5 Million USD (9/14/20)
Jenia Barkanova, VP Marketing
Christine Perry, VP of Solutions Engineering
Chadwick Strange, VP Product
Product- SKALE Network (open source)
Office- San Francisco, CA and Kharkiv, Ukraine
Blockchain technology has come to stay. It has served as the benchmark for new business models and societal impact. One major feature that cuts across all blockchain networks is decentralization.
Decentralized networks like Ethereum however come with shortcomings. This includes but is not limited to their scalability, cost-effectiveness, usability, and performance.
SKALE Network is programmed to solve the problems associated with decentralized networks. It’s Ethereum-based and works hand-in-hand with it.
This network offers Ethereum-as-a-Service to developers while eliminating the latency, scalability, cost issues affiliated with Ethereum and Ethereum-like networks.
In this article, you will gain a full understanding of What https://github.com/skalenetworkSkale Network entails. This includes mode of operation, security, Skale protocol, and token.
Skale is an elastic blockchain network developed to function as a sidechain to the Ethereum blockchain network. In other words, it can be referred to as an Elastic Sidechain Network with respect to its relationship and interoperability with the Ethereum network.
End-users can utilize the network resource by creating a side chain network specially configured to suit their demands. They pay for the length of time they want to make use of the network resources.
This method of service delivery is similar to AWS’s Platform-as-a-Service. While you pay on the go for the AWS resources, here you pay upfront for a determined amount of time.
A consumer in the elastic side chain network can determine their chain’s size, consensus protocol, parent blockchain(currently runs with only the Ethereum sidechain), extra security measures(e.g virtualized subnode shuffling frequency)
Elastic sidechains are run and operated by virtualized subnodes.
To be able to work and use resources in this sidechain network, nodes run the Skale daemon to stake Skale tokens on the Ethereum mainnet.
This is achieved via smart contracts known as SKALE Manager.
Upon the addition of a node into the network, 24 peer nodes will be assigned to review its uptime and latency.
These metrics are submitted to the SKALE Manager, and they determine a node’s reward for participating in the network.
The peer nodes are selected randomly.
End-users can create a sidechain by inputting a suitable chain configuration. If the network, however, has enough bandwidth, nodes meeting the chain’s requirement will be randomly assigned to function as its virtualized subnodes.
The SKALE network is composed of Skale Nodes and Skale Manager.
The Skale manager is hosted on the Ethereum mainnet. It manages all the activities within the network. This includes Elastic sidechain creation and destruction, Nodes creation and destruction, withdrawals and bounties.
Node Creation and Destruction
For a node to be added to the system, it will meet certain conditions. The prospective node will run the SKALE daemon to be evaluated. If it meets all the network hardware requirements, it will be granted permission to reach the SKALE Manager and request access to the network.
The SKALE Manager commits the request to Ethereum, after which the prospective node will be added to the network as a full or fractional node.
For a full node, all its resources will be used in a single elastic sidechain while fractional nodes will be distributed in multiple sidechains.
Each node is randomly assigned peer nodes that regularly check its uptime and latency. The time interval is predetermined. These metrics are submitted to the SKALE Manager once in every network epoch and they are used to allocate bounty rewards to the node.
This system of peer audit is used to ensure transparency making sure that every node gets a befitting reward, corresponding to its uptime.
This is not destruction in the actual sense. However, a node can decide to leave the network, and such nodes make known their exit. It then waits for a finalization period.
At the end of the finalization period, the node will be inactivated and will now be able to withdraw its initial stake from the network.
If an end-user did not wait for the finalization period and exits their node from the network, it will be considered a dead node and will not receive its bounty.
Elastic Sidechain Creation
Consumers can create elastic sidechain by selecting the most suitable sidechain configuration option. The minimum elastic sidechain option consists of 16 virtualized subnodes. The intending user pays for the duration they will be using the network resources.
The SKALE Manager creates a new Elastic Sidechain after it receives a request from the intending user. If, however, that the network does not have enough resources to meet the demand of the new Elastic Sidechain, the order will be canceled and the intended user notified.
Virtualized Subnode Shuffling
This is an extra and optional security measure in the sidechain network. Users are given the option to enable this security measure. The virtualized subnode shuffling is executed by the SKALE Manager.
Elastic Sidechain Destruction
An Elastic Sidechain is due for destruction when a user utilizes all the resources it paid for or when they personally mark it out for deletion.
The destruction is executed by the SKALE Manager and it involves returning any crypto(Ethereum) assets to the owner on the Ethereum mainnet, deletion of the virtualized subnode from the Elastic Sidechain, format their storage, and memory, and finally delete the Elastic Sidechain from the SKALE Manager.
The SKALE Manager rewards the person that proposes the destruction.
Bounty refers to the reward Nodes receive the after network epoch. The rewards are in the form of tokens. The number of tokens a node receives depends on the average of the metrics submitted by 16 of its peer nodes.
The metrics are the uptime and latency of each node recorded by 24 peer nodes during the network epoch and submitted to the SKALE Manager. However, at each period, the results submitted by 8 peer nodes are discarded. The peer node result to be discarded is not arbitrarily chosen instead, the 4 top-most and bottom-most peer nodes are removed.
This is used to ensure transparency and forestall any form of collusion among the peer network. The average of the metrics submitted by 16 out of the 24 peer nodes is eventually utilized to determine a node’s reward.
There is a possibility of having token(s) not entitled to any node as a result of poor uptime/latency. In this case, the token(s) will be issued to the N.O.D.E Foundation.
The SKALE network comprises Elastic Sidechains. The Elastic Sidechains contain virtualized subnodes that create and commit new blocks to the chain through a process that is asynchronous, leaderless, and secure. This process is designed to be resistant to total failure regardless of the failure of some participating virtualized subnodes.
Provided that more than two-thirds of the participating virtualized subnodes are online, they will ensure the creation and commitment of new blocks to the chain.
The processes involved in the creation and commitment of new blocks are a bit complex. It involves the following:
- The transaction is added to the pending transaction queue.
- Proposing block collects keys shares from subnode A:
>The subnode in question sends the block proposal to all its peers.
>Upon receipt, each subnode stores the proposal in its database.
>Each subnode sends back a receipt that contains their signature share to subnode A.
- Subnode A creates a Supermajority signature from the key shares. This will serve as proof that a majority of the peer nodes signed the block proposal.
> Subnode A then distributes the supermajority signature to all its peers to confirm.
>Now, each subnode has the proposal and supermajority signature key share of the prospecting block.
>The network runs ABBA to ensure data availability and declare the winning proposal.
- Subnode A commits the winning proposal to the chain with its supermajority signature.
NB- There is no limit to the number of proposing blocks running at any instant. The process above is repeated for each proposing block and Subnode A commits the winning proposal to the blockchain.
For further reading, refer to SKALE Network Whitepaper. Download here
Skale Virtualized Subnodes
The elastic sidechain in the SKALE Network contains virtualized subnodes that are used to run the SKALE daemon and SKALE consensus. The virtualized subnodes in each elastic sidechain are randomly selected and assigned to the sidechains.
Virtualized subnodes are subnodes found within a SKALE Node.
The containerized virtualized subnode architecture utilized on each SKALE Node in the network permits each node to run multiple Elastic Sidechains simultaneously.
Each container is used to deliver one of the following services-
The SKALE Admin Service functions as a human interface for virtualized subnodes in the SKALE Manager. The services delivered with this interface include — the ability for nodes to know the Elastic Sidechain they are participating in, deposit, withdraw, stake, and claim SKALE tokens.
Node Monitoring Service
Each node is a peer to other nodes. This means that each node automatically monitors all other nodes, tracks their performance(uptime and latency). Each node submits the average of these metrics to the SKALE Manager at the end of the Network epoch.
The SKALE Manager uses these metrics to allocate rewards to each node.
Virtualized Subnode Orchestration Service
Under this service, node computation, and storage resources are arranged to represent virtualized subnodes using a dynamically created virtualized subnode image comprising of the SKALE daemon, catchup Agent for syncing a lagging Elastic Sidechain, and the transfer agent for interchain messaging.
This service also regenerates failed virtualized subnodes and deallocate resources to decommissioned virtualized subnodes.
Attacks and Faults
This is an emergency strategy deployed by SKALE to mitigate the effect of a downed node till its recovery. It consists of an automatic recovery agent and a security incident response team in the network.
Nodes become unavailable when they are rebooting. During this period, peer nodes consider it as a temporary slow link.
Messages sent to the node will be delivered after the reboot. This protocol is deployed in order not to obstruct the operation of the consensus when a node is not available.
Apart from a reboot, a hard crash(due to a software bug or hardware failure) can cause a node to be offline. In this case, the peer nodes continue sending messages until there is a message overflow. To reduce the effect of over clogging, messages older than an hour will be discarded.
The network consensus will always go on until more than one-third of the nodes get hard crashed. In this scenario, the consensus will be stopped and this will be noted by the failure to commit new blocks in a set period of time.
If this happens, a failure recovery protocol utilizing the Ethereum main chain will be executed. In response, nodes will cease their consensus operation, sync their blockchains, and fix a time to resume consensus.
Each node has a catchup agent that ensures that the node’s blockchain and block proposal database is synced with the network.
It also updates a node after a hard crash incident while participating in the current consensus but it cannot make its own block proposal until the catchup is complete. This is because the hash of the previous block is required to make new block proposals.
Security Incident Response
SKALE token is a multipurpose token that grants one access to the network to do one or more of the following-
- Validate: Validators are allowed to run nodes on the network when they stake SKALE tokens. They earn fees and get rewarded for their node’s uptime and latency. They are the workers in the SKALE network.
- Delegate: An individual or organization can delegate their tokens to a validator. They stake part of the tokens required to run nodes in the network. In return, they receive part of the proceeds from running nodes in the network.
While validators receive rewards after each network epoch, delegators receive rewards after the delegation period which was chosen by them.
The delegation period is the duration of delegation as chosen by the delegator. A 2-month period was set as the minimum delegation period during the launch of the SKALE network.
Validators can delegate themselves.
Click here to read more about Network Bounties and Delegation Workflow.
- Develop: Organizations, Businesses, and developers that want to use the SKALE network resources stake tokens in the network. In other words, they pay a subscription fee for a predetermined duration they want to use SKALE resources. The resources are in the form of computation power, storage, and bandwidth in the Elastic Sidechain.
In the SKALE ecosystem, SKALE tokens serve the following purpose-
Security for staking in the network and reward to validators
Validators work in the network. They validate blocks, implement smart contracts, and secure the network. They are rewarded accordingly with SKL tokens for their efforts.
Delegators can also earn from the work of the validators by staking to them part of the tokens required to run a node.
Legal tender for payment of subscription fees
To access network resources, developers pay tokens for their subscription to the Sidechain network.
Governance and Voting
Key performers like dApp developers that run Skale chain, validators, investors that helped to commence the network economics, and entities/developers that actively build and maintain the codebase are selected by the N.O.D.E foundation to become network representatives.
They will serve the community through budget/treasury decisions, execution of on-chain voting, and grants.
Click here for additional information on governance.
An additional function of the SKALE token is the ability to enhance security in the network. This is because token holders can share a secure delegation key with staking providers without having to send their tokens to delegation smart contracts. They stake tokens while they remain in cold or hot wallets.
Find out more about the SKALE token here.
In order to maintain and encourage a standard code of conduct among the network participants, the SKALE protocol is adopted to reward good behavior and punish defaulters.
SKALE deploys a Proof-of-Stake system that requires participants to stake a predetermined amount of tokens. Upon detection of any malpractice, the defaulting node will be surcharged.
Such byzantine behavior that attracts such punishment includes the refusal to sign blocks and maintain uptime and latency standards.
Using the peer review system, a node’s participation, uptime, and latency will be tracked and recorded. These factors, when averaged on the Ethereum mainnet will be used to determine a node’s performance and rewarded or punished accordingly.
This Proof-of-Stake system also serves as a security protocol. An attack on the network will need more than two-thirds of the network resources to be successful. This makes such an attack very expensive to pull through.
Get a copy of the SKALE network Whitepaper here
SKALE token holders can stake their tokens to any node in the network provided that the node in question has not exceeded the maximum number of tokens that can be staked or delegated.
When building a consensus network, it is important to take note of all possible attacks that could be launched on the network which can breach the message flow in the network. On the other hand, the network should be able to withstand the enormous messaging and possible downtime of nodes.
SKALE uses a variant of Moustefaoi et.al consensus as it comes with features that cater to the challenges of a truly decentralized network.
The SKALE consensus is leaderless. This means that any virtualized subnodes can propose a new block in the network. However, the proposal with the supermajority key shares will be committed to the blockchain.
This protocol will prevent any possible collusion amongst participants in the network. In a consensus network where there is a leading node that proposes new blocks, the leader can be corrupted. And if this happens, the participating nodes will continue to take orders from the corrupt leader.
This leaderless protocol also serves to give all virtualized subnodes an equal chance of proposing new blocks.
This refers to the irregularity in the time between a sent message and when it was received. There is no standard time frame instead nodes send messages with the assumption that it will eventually be received.
Messages later than an hour will be dropped to prevent message overflow.
Other protocols adopted by the SKALE network include the Byzantine Faul Tolerant System that ensures consensus will only take place when there is less than one-third of malicious nodes in the network and the Threshold Signature that is used in supermajority voting to determine the winning proposal.
SKALE Network and Delegation Workflow
You may wonder how delegators get their rewards from staked tokens after the delegation period and how to determine the amount they are entitled to.
In this section, you will learn how rewards are calculated and distributed by smart contracts after each network epoch.
Firstly, there are two ends of the Sidechain.
The developers on one end and validators on the other.
Developers that want to use the sidechain resources to develop and deploy their applications stake tokens in the Ethereum mainnet to be able to access the network resources for their desired duration. They also select the size of the sidechain that will serve them.
They trade with the token in the network.
On the other hand, validators validate new blocks and participate in consensus. They keep the network running smoothly. Their efforts are rewarded with the SKALE tokens. Validators also stake tokens but this time, in order to be granted access to run nodes.
The delegators are passive actors in the SKALE ecosystem. They are token holders that stake their tokens with validators. When validators are paid, some of the tokens go to the delegators that staked with them.
Validators however can accept or reject staking offers from delegators.
At the end of every month regardless of the number of days in the month, tokens are moved from the Ethereum mainnet into the bounty pool and utilized for payouts to the validators.
Follow us on-
SKALE website (www.skale.network)