SKALE Validator FAQ
The SKALE Network is a configurable network of elastic sidechains that supports high-throughput and low-latency transactions without the high transaction costs found in public mainnets. The network offers expanded storage capabilities along with embedded connectivity and interchain messaging with the Ethereum mainnet and other sidechains and subchains. All of this is performed using a pooled transaction validation and security model that is efficient, scalable, and collusion-resistant.
SKALE Network Validator Nodes
Blockchain mining and chain validation are not without risk so miners and validators need to pick the right networks to join. SKALE is a Proof of Stake (POS) network that utilizes a work token. The advanced containerization and virtualization of nodes make operation seamless and the SKALE Protocol optimizes the allocation of resources of each node across the entire network of elastic blockchains. This protocol is also mining pool resistant — meaning that there is no advantage to be gained by pooling resources at the mining level.
Node setup and staking is simple and takes only a few steps. Validator rewards are distributed on a near-even basis across the network of nodes — with validator rewards based on meeting performance targets, not by optimizing rigs to improve cryptographic performance. Each node is rated based on its SLA behavior for the chains the node is validating with node performance being assessed by the other nodes in the network.
Validator payouts are made on a monthly basis to validators that meet the performance and uptime criteria. Payouts include tokens paid in the form of sidechain subscription fees and token inflation as specified via a smart contract running on the Ethereum mainnet.
How does the SKALE Network work?
The SKALE Network consists of a large set of nodes, all running concurrently and independently, validating transactions within the elastic sidechains they are overseeing. These nodes all make use of a unique set of SKALE contracts that run on the Ethereum mainnet. These smart contracts are where the SKALE token lives, where issuance occurs, and where rewards get disbursed to the node validators. These smart contracts are also where the analysis of the network takes place and where corrective actions are taken if there is bad behavior by one or more nodes.
Developers create chains by first selecting the size of the chain (small, medium, and large), duration of the chain (6mo, 12mo, 24mo), and then staking SKALE tokens in order to provision the network resources. These tokens get staked into the Ethereum mainnet via one of the SKALE contracts that reside there. Each month, a certain number of tokens from this developer stake gets moved into a bounty pool which is then used to pay the validators within the network. Inflation (issuance) event also takes place each month whereby new SKALE tokens are created via a contract on the mainnet, the result of which gets pushed into the bounty pool for payout to validators.
For example, if there are a thousand validator nodes in the network and they all perform well, they will each participate in the monthly proceeds from the bounty pool which includes a portion of the sidechain token stakes plus an inflation amount. The distribution to the validators is not necessarily shared equally as there is a modifier component that slightly adjusts the payout based on the duration of time tokens are staked into the network. Nodes with tokens that are locked up for twelve months, for example, will get a greater percentage than those locked-up for three or six months.
What benefits do virtualized subnodes and node containerization provide?
Each elastic sidechain is comprised of a collective of randomly appointed virtualized subnodes which run the SKALE daemon and the SKALE consensus. Nodes in the SKALE Network are not restricted to a single chain but rather can work across multiple sidechains via the use of virtualized subnodes. This multiplex capability is made possible via a containerized subnode architecture deployed on each node in the Network. Each node is virtualized and is able to participate as a validator via this subnode architecture for an independent number of sidechains. Sidechains sizes can be small, medium, or large with a small chain using 1/128 of a node’s resources, a medium using 1/8 of the resources, and a large using the full amount.
The subnode virtualization is enabled via an innovative containerized architecture that provides industrial-grade performance and optionality for decentralized application developers — performance and flexibility that is similar to traditional centralized cloud and microservice systems. Containers are divided into several main components encapsulated via a dockerized Linux OS — allowing for each node to be hosted in an OS-agnostic manner.
How does the network work from an operational and governance perspective?
The SKALE Network is a custodial execution layer (Layer 2). Whereas non-custodial approaches use a system of fraud proofs to allow funds to move between chains, SKALE makes use of BLS signatures, deposit boxes within the Ethereum mainnet, and other mechanisms to allow for custodial ownership and use within the network (which allows it to leverage the security guarantees of the mainnet but gain the performance inherent in Layer 2).
The stake from the validators, the payments from developers, and the token inflation — all of it lives in the Ethereum mainnet and all of it is controlled by the smart contracts that run there that work in unison with each SKALE Node.
This approach is different from other Layer 2 models that attempt to use mainnet interactions to run verification and/or fraud proofs. SKALE uses the Ethereum mainnet for staking and for other mechanistic operations in a way that is better attuned for the creation of a robust and trustworthy Layer 2 network. SKALE will also support BLS Rollups for use cases that require full reliance on MainNet custody.
How does the network mitigate security risks?
The security and validity of transactions in a sidechain or subchain in a second layer primarily rests with the performance and behavior of the validator nodes. To make sure the validation layer is operating properly, a network first has to have a large number of validator nodes. A small number of nodes in a network is inherently risky and fragile.
In addition and as a requirement for a secure and robust network, it ideally needs to provide for a) the random selection of chain validator sets and b) the rotation of nodes in and out of chains on a frequent basis. Without randomness and rotation, there is a far greater risk of bribery and/or collusion between validators, vastly reducing the security and integrity of the chains within a network.
Are there staking requirements to become a validator in the SKALE Network?
A key requirement for an effective security and execution layer is a proper incentive structure that addresses both penalties and rewards. With respect to the former, every validator node should have significant value staked into a network. Staking is an enforcer of good behavior in that if a validator decides to collude or go byzantine and gets caught, it will lose its stake and be removed from the network.
In the SKALE Network, there is no minimum bonding requirement for a validator. Validators have an option to self delegate or accept a delegation from other token holders.
To coerce or bribe the validators of a sidechain with this type of a pooled validation model — one that employs random selection and frequent node rotation — a bad actor would have to effectively bribe two thirds of the larger network. To do this with a large number of nodes in the overall network would be exceedingly difficult. SKALE’s network design is based on these core principles and is directly aligned with stopping — if not eliminating — attacks and preserving the integrity of transactions within each chain in the network.
Is there a Minimum Staking Requirement (MSR)?
Yes. There is a Minimum Staking Requirement to register a node in the network. The amount will be publicly announced leading up to the MainNet Launch.
What are the duration options for operating as a validator?
Validators can choose to validate for 3 months, 6 months, or 12 months. (The minimum lock-up period is 3mo.) Validators can choose to self-delegate (i.e. put up the entire staking amount themselves) or elect to accept any delegation and have the option to provide a commission rate to the delegators. Staking for the longer durations will have a slight multiplier applied to the monthly payouts from the bounty pool.
How are validators measured and rewarded?
Performance metrics for each subnode are collected by a subset of the other subnodes in the network. Metrics for the overall behavior of the node itself are collected by 24 independent peer nodes. Combining these metrics yields an overall score which will determine whether or not a node is able to participate in a monthly bounty award. This bounty award also includes token inflation as set forth in a mainnet contract that handles node payouts. (Payouts are evenly distributed across the validating pool except for a slight weighting in favor of nodes that are staked for a longer duration.)
When validators lock up their tokens for 3, 6, or 12 months, do they get paid rewards every epoch, or are rewards also locked until the end of the lockup period?
Validators get paid every epoch i.e. every calendar month.
Is there any unbonding or undelegation period?
No, there is not. Validators may withdraw their stakes (self-delegated or delegated) at any time after their stake is unlocked.
Does the network have support for validator commissions and delegation of investor stakes?
Yes. Validators can raise stakes from delegators and have this reflected via contracts running on the network. Commissions can be set for the monthly bounties such that payouts can be split into both commissions (to the validator) and delegator awards (to investors). The commission rate that is set is solely at the discretion of validators and on what the market will bear.
Is there a minimum delegation requirement?
No. There is no minimum delegation requirement for a validator. Validators can choose to self-delegate or choose to bring on delegators, in which case, validators can set minimum delegation amount for accepting delegations
How are validators monitored?
The node core in a validator within the SKALE Network has a primary role in moderating the network — a role that is in addition to self-organizing around the validation and operation of sidechains and subchains. Each node gathers and uploads data in service of keeping the network honest and operational. Each node in the network is continuously monitoring a random set of 24 nodes, gathering data, and pulling log files from these nodes. The node core will score each of the nodes, looking at uptime, latency, performance, and other metrics and then basing the score on whether certain thresholds are met or not. This mechanism is a part of the SKALE Node Monitoring Service and is called the SKALE SLA function.
Nodes submit their metrics to a contract on the mainnet which blends, processes, and aggregates them to get a clear picture of network and node health. If a node is deemed to have performed well during an epoch, it gets to participate in the award from the bounty pool. If a node performs poorly, it will not receive an award for that period. If it acts maliciously, it may get flagged and pulled from the network. In the case of the latter event i.e. suspicions of cheating, indications of having been hacked, or engagement in other malicious acts, a review process will be initiated which could end up with node stake getting slashed.
What is the Service Level Agreement (SLA) threshold?
The SLA threshold is a high percentage of uptime and low latency response time. If a validator cannot meet the SLA requirements for a particular epoch (as determined by the network monitoring procedures), they will not be eligible to participate in the awards from the bounty pool.
What type of validators is the network looking for?
The SKALE Network is open to any validator as long as they meet the technical requirements and staking commitment. For the launch of the SKALE Testnet and the leadup to launch of the SKALE Mainnet, the network is particularly interested in knowledgeable validators who have experience validating for other Layer 1 and Layer 2 networks. Validators should have the desire and resources to run nodes, test the network, find bugs, and participate in detailed feedback discussions with the SKALE team and broader validator community.
The incentives for early validators are to get to know the operation of the network as well as participate in the incentivized Testnet. Some of the incentives include bounties for finding bugs, providing community tools, suggesting documentation improvements, running specific tests, connecting to specific Testnet contracts, and other tasks.
What is the process to become a validator in the SKALE Network?
Validators go to the SKALE website (www.skale.network) and sign up. The SKALE network team will review the application and then schedule review times with potential validators. The process is a mutual evaluation process until such time as there are self-serve signup and on-boarding. Candidates that go forward in the process are asked to sign a non-binding intent letter and then go through a certification process. Once they pass, they will be included in the Alpine cohort (this is the name given to the initial set of network validators).
There is a Discord channel that validators are invited to join. The SKALE team will also work closely with validators to help them set up the node and register it into the network. The containerized nature of the architecture makes it easy to stand up and operate a node. The CLI process to do this is straight-forward for almost any engineering or DevOps team. The goal at this point is to work with a solid set number of experienced validators to ensure a smooth launch of the mainnet.
The network is designed to be permissionless. In the future, signup and registration will be self-serve, and registering and white-listing as a validator will be ungated.
What are the hardware requirements for being a validator node?
Validators need to provision and operate their own server or servers with sufficient network capacity and data center operational integrity. Servers can operate in a public or private cloud setting or on locally provisioned hardware, provided they meet SLA requirements. A particular requirement for servers is that they operate Intel SGX.
Intel SGX (Software Guard Extensions) is a set of instructions that increases the security of application code and data, providing added protection from disclosure or modification. Developers can partition sensitive information into enclaves, which are areas of execution in memory with more security protection. It is recommended that all nodes in a validator set be Intel SGX servers although it’s also possible to set up a network node with a certain ratio of Intel SGX servers to non-SGX servers.
Other node requirements include Ubuntu 18.04 or above, 200GB of attached storage, and 32GB RAM.
Why is Intel SGX a requirement?
The SKALE Network makes use of certain features in the Intel SGX chipset in order to offer enhanced security and added data protections. (The virtualized nature of nodes is also able to leverage the multiple independent Intel SGX-enabled CPUs that the chipsets offer.)
A further reason for the Intel SGX requirement is the heavy use of the BLS (Boneh-Lynn-Shacham) cryptography as part of its technical offerings. For example, interchain messaging is powered by BLS threshold signatures. Each sidechain also supports BLS Rollups which provides an efficient and secure way to use the SKALE Network to improve throughput and lower gas costs on the Ethereum mainnet. (A rollup can generally be defined as a solution where transactions are published on-chain, but computation and storage of transaction results are done differently to save gas.)
Some networks that use BLS signatures use Ledger as opposed to Intel SGX. Why the difference?
Most often the case is that these other networks are applying BLS multi-signature aggregation. Simply put, every validator generates a BLS signature and then performs operations with this signature. The network protocol aggregates all signature operations into one. What you gain from this process is compressed data, since instead of multiple ECDSA keys, you have a single aggregated signature, and nothing more. This use is suitable for Ledger hardware.
SKALE’s process is drastically different. SKALE uses BLS threshold signatures — a different and much more complicated process than BLS signature aggregation. To make a threshold signature work — such that only t of n operators are needed to perform an operation — one needs a trusted process to construct a BLS public key based on secret shares from each of the operators. This is called DKG or distributed key generation and requires much more complicated processing than what Ledger-based solutions can provide. Whereas Ledger-based networks are simply storing a BLS signature for the purposes of multi-signature aggregation, Intel SGX is being used for DKG and related threshold operations.
Another critical distinction is that BLS signature aggregation is performed per validator, whereas BLS threshold signature operations are done per SKALE chain and on a frequent basis. If a validator node is supporting 128 SKALE chains, then the node core has to generate 128 BLS threshold public keys and 128 BLS threshold private keys via distributed key generation.
If a validator is using a single Intel SGX server to support 16 nodes and each node is running 128 elastic sidechains, then it needs to generate and maintain 2048 public and private BLS threshold keys. When a node is swapped into a new SKALE chain, the DKG process is re-initiated with all nodes within the sidechain group, resulting in new public and private key generation for that specific SKALE chain. Given this increased frequency of digital key generation and complexity of BLS threshold cryptography, the use of Intel SGX is an optimal solution for addressing the performance and data security requirements of the network. (Note that the SKALE team is a fan of Ledger-based currency and token storage solutions, notwithstanding lack of BLS threshold signature support.)
Has the Intel SGX technology been adequately vetted?
Yes, the SKALE technology team has analyzed the benefits and operation of the Intel SGX chipset in depth, is aware of any perceived vulnerabilities, and is satisfied the technology meets the security and data protection requirements of the network. Tests run on the SKALE Testnet will serve to validate this analysis and ensure that the chipset meets these intended security and data protection requirements.
Are you aware of Intel SGX-related attacks like Plundervolt, cache attacks, and other vulnerabilities?
The SKALE team stays abreast of any and all security issues related to Intel SGX and takes all measures necessary to counteract them. Intel is very good at providing BIOS updates to address any security holes and prevent these types of attacks. The validator also shares responsibility in that they must continually check that their service providers are using the latest version of the BIOS. The SKALE team will keep validators abreast of security issues, recommend best practices, and work closely with validators to address these issues and more.
Why the specific requirements for disk storage and memory?
The SKALE Network is designed to be highly performant with high throughput and low latency. On-chain storage is also an important offering of the network and so disk storage needs to be above a certain amount in order to support this capability. Nodes operate as virtualized nodes, meaning that one node can service many elastic sidechains. Sidechains sizes can be small, medium, or large with a small chain using 1/128 of a node’s resources, a medium using 1/8 of the resources, and a large using the full amount.
We should also mention the future that the SKALE Network is building towards is one where decentralized solutions will make use of a number of elastic sidechains — not unlike the way cloud applications today make use of multiple microservice meshes and/or database clusters, each one optimized for the app features or capabilities it is supporting. This concept is explored further in an article on monolithic architectures vs multiple side chains here.
Call you tell us any clouds or co-location site where nodes might currently be operating?
The network team and early validators have set up nodes on Digital Ocean and Vultr but nodes can also run on bare metal provided they meet the requirements specified above. The choice is largely up to the validator although the network team can suggest and assist with provisioning options. The SKALE network team maintains a list of Intel SGX-compatible servers. Additional inquiries can be addressed in the SKALE validator Discord.
Are the network incentives set up to be mining pool resistant?
Yes. Every node in the SKALE Network has the same profit potential and is rewarded based upon its performance metrics which include uptime, latency, and serving as a good actor.
For more details on how node validation works and the economics involved, please see the Whitepaper and the Eliminating Mining Pools article.
How are network improvement proposals addressed?
Anybody can generate and submit improvement proposals. There is a Committee of Network Representatives that collects the proposals and decides which ones will be voted on and when. It has no voting power and consists of two core SKALE team members, one validator representative, one delegator representative, and one member from the dApp community.
What is the governing body for the SKALE Network?
The governing body for the network is the N.O.D.E. Foundation. This foundation maintains the procedures for how the review process works and controls its operation. The initial panel will be comprised of approximately 10 validators, if and until such time as the process becomes automated in part or in whole. During a review, each member of the panel will get an opportunity to look at code, log files, transaction flows, and other data to determine if any improper action has occurred. The foundation believes that it is important that validators play a primary role in policing. Given their bondedness into the network, validators are highly incentivized to act in their best interest in guarding and preserving the integrity of the network.
About the SKALE Network
The SKALE Network is an open-source elastic blockchain network protocol. The mission is to make it quick and easy to set up cost-effective, high-performance sidechains that run full-state smart contracts. The SKALE Network aims to deliver a performant experience to developers that offer speed and functionality without giving up security or decentralization.
You can follow the SKALE Network on Telegram (@SkaleOfficial), Twitter (@SkaleNetwork), and Discord (www.skale.chat), visit the SKALE website (www.skale.network), read developer documentation on SKALE Developer Portal (skale.network/docs), and see the code on Github (github.com/skalenetwork).
Originally published at https://skale.network on May 7, 2020.
