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.

‍

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 SCALE team members, one validator representative, one delegator representative, and one member from the dApp community.

‍

Yes. Every node in the SCALE 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 SCALE Whitepaper and the Eliminating Mining Pools article.

‍

The SCALE 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 SCALE 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 the disk storage and memory?

The SCALE 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 chains. Chains 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 SCALE Network is building towards is one where decentralized solutions will make use of a number of chains – 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 SCALE network team maintains a list of Intel SGX-compatible servers. Additional inquiries can be addressed in the SCALE validator Discord.

Yes, the SCALE 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 SCALE Testnet will serve to validate this analysis and ensure that the chipset meets these intended security and data protection requirements.

‍

Most often the case is that these other networks are applying BLS multisignature 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.

SCALE's process is drastically different. SCALE 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 SCALE chain and on a frequent basis. If a validator node is supporting 128 SCALE 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 chains, then it needs to generate and maintain 2048 public and private BLS threshold keys. When a node is swapped into a new SCALE chain, the DKG process is re-initiated with all nodes within the chain group, resulting in new public and private key generation for that specific SCALE 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 SCALE team is a fan of Ledger-based currency and token storage solutions, notwithstanding lack of BLS threshold signature support.)

The SCALE 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 chain also supports BLS Rollups which provides an efficient and secure way to use the SCALE 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 is done differently to save gas.)

‍

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 nodes 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.

Validators go to the SCALE website (www.skale.network) and sign up. The SCALE 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 is 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 SCALE 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 devop 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.

The SCALE Network is open to any validator as long as they meet the technical requirements and staking commitment. For the launch of the SCALE Testnet and the leadup to launch of the SCALE 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 SCALE 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.

The SLA threshold is a high percentage 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.

‍

The node core in a validator within the SCALE Network has a primary role in moderating the network – a role that is in addition to self-organizing around the validation and operation of chains 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 SCALE Node Monitoring Service and is called the SCALE 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.

No. There is no minimum delegation requirement for a validator. Validators can chose to self-delegate or choose to bring on delegators, in which case, validators can set minimum delegation amount for accepting delegations.

‍

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.

‍

No, there is not. Validators may withdraw their stakes (self-delegated or delegated) at any time after their stake is unlocked.

‍

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.)

‍

Validators can choose to validate for 3 month, 6 month, 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.

‍

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.

‍

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 SCALE Network, there is no minimum bonding requirement for a validator. Validators have an option to self delegate or accept delegation from other token holders.

To coerce or bribe the validators of a chain 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. SCALE’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.

Security and validity of transactions in a chain 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 of and/or collusion between validators, vastly reducing the security and integrity of the chains within a network.

The SCALE 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, SCALE 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 SCALE Node.

This approach is different from other Layer 2 models that attempt to use mainnet interactions to run verification and/or fraud proofs. SCALE 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. SCALE will also support BLS Rollups for use cases that require full reliance on MainNet custody.

Each chain is comprised of a collective of randomly appointed virtualized subnodes which run the SCALE daemon and the SCALE consensus. Nodes in the SCALE Network are not restricted to a single chain but rather can work across multiple chains 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 chains. Chain 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.

The SCALE Network consists of a large set of nodes, all running concurrently and independently, validating transactions within the chains they are overseeing. These nodes all make use of a unique set of SCALE contracts that run on the Ethereum mainnet. These smart contracts are where the SCALE 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 SCALE tokens in order to provision the network resources. These tokens get staked into the Ethereum mainnet via one of the SCALE 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. An inflation (issuance) event also takes place each month whereby new SCALE 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 chain 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.