SKALE NETWORK — An Ethereum Interoperable Elastic Blockchain Network || Crash Course
Hello Blockchain Lovers!!!
Today’s topic is quite different and it is a crash course for you to understand a unique Blockchain Network. This network is referred to as an Ethereum Interoperable Elastic Blockchain Network(SKALE NETWORK).
In the last decade, Blockchain has proven to be one of the best and most influential innovations in software technology, they are built to be architecturally and politically decentralized which is very similar to the internet.
After so many years of Blockchain existence, it was noticed that the challenges faced by the blockchain-based system are related to scalability, privacy, and security. Out of many Blockchain Network available, there’s this popular network with a very large number of DApps which has got the challenges of the blockchain-based system,
Read on to see what Network and see the connection with SKALE NETWORK.
ETHEREUM BLOCKCHAIN
Ethereum network is one of the largest blockchain networks with the highest number of DApps in the crypto space, this network is also known as the ERC-20 network.
It has faced many problems since inception and so many professional blockchain communities from around the world have done numerous researches on how to simplify and solve some of these problems faced by the ETHEREUM Blockchain.
Over the years, many other Blockchain Network were birth for one purpose or the other, many of this network is built to simplify some of the difficulties on the Ethereum blockchain, especially for users and DApp developers, they interact with ETHEREUM to solve a major problem which makes many of them exist as a Sidechain Network.
SIDECHAIN NETWORK
A Sidechain Network, just as its name implies is a secondary blockchain network connected to the main blockchain with two-way pegs, some sidechains might have their consensus protocol completely different from Mainchain’s but they are mainly built to simplify or solve a problem that may include, improving privacy and security of the traditional blockchain. Sidechains enable developers to deploy blockchain solutions that can quickly scale the mainchain at a lower cost with a higher level of security, sidechains holds significant for the enrichment of the capabilities of the existing Blockchain Network.
SKALE as a SIDECHAIN NETWORK
Skale Network primary and initial use cases are in form of an elastic sidechain for the Ethereum Blockchain, Skale can now and will be referred to(in this context) as an Elastic Sidechain Network of Ethereum operated through a group of virtualized subnodes which are selected from nodes within the network and are run on all or subset of each node’s computation and storage resource. Therefore, Skale Network is meant to be a high-throughput, low latency, and a configurable byzantine fault-tolerant, elastic blockchain network built interoperably with the Ethereum Network.
Before users/developers can have the right to work in the network, the Skale daemon must be run and users will have to stake an already predetermined amount of the SKALE Network token on the Ethereum mainnet, this will happen through different series of smart contract in the Skale network which is called SKALE MANAGER.
Any node admitted to the Skale network will trigger the selection of random 24 peer nodes to which will audit its latency and uptime and will be submitted to the SKALE MANAGER to influence the node’s reward for participating in the network.
For a user to create an elastic sidechain, they have to be specific with their desired chain configuration and required to submit payment correlating in time or duration they wish to rent the network resource in running the chain. Before the virtualized subnodes can be randomly assigned, their network has to have enough bandwidth, nodes meeting computation and storage requirements specified in the chain’s configuration.
For already existing Ethereum-based smart contracts, only EVM(Ethereum Virtual Machine) within Elastic Sidechains will allow consumers to deploy contracts(Existing) directly to them while an increased gas limit lifts the computation and storage limitations of the Ethereum mainnet EVM. This is an advantage for smart contracts that were unable to run in a performant and cost-effective manner.
In each Elastic Sidechain consensus model, they also support BLS signatures which allow interchain messaging. This interaction and BLS signature let a virtualized subnode on one chain validates that a transaction was signed and committed by another virtualized subnode on another chain, this is done through the help of the chain’s group signature and it is made available to all other chains on the Mainchain(Ethereum Mainnet).
The extension of the Elastic Sidechains supports a microservice model where every chain on the network can perform each of their specific operations and send their output as an input to other Elastic Sidechains.
As much as nodes are able to do activities assigned to them in an Elastic Sidechain, they get rewards as bounties on performance, and this is measured by their peer nodes at the end of every network epoch. Any elastic sidechain that has exhausted its lifespan, its storage, and computation which are its resources of virtualized subnodes will be let go so that it will be able to participate in a newly created Elastic Sidechains.
Skale Network is only supporting the Ethereum Blockchain while the team is working on growing to support other security layer blockchains, so they can serve as an execution and interoperability layer between other desperate decentralized technologies.
Having explained that Skale Network is an Elastic Sidechain of the Ethereum Network, it comprises of permission-less SKALE Nodes and SKALE Manager existing on ETHEREUM NETWORK.
SKALE Manager
SKALE manager, it is a manager obviously but what does this manager do for SKALE NETWORK, Skale Manager exists on the Ethereum mainnet and serves as the security at the entry point for all smart contract in the Skale Ecosystem, Skale manager does the manage the orchestration of all entities existing in the network which includes;
- Node Creation
- Node Destruction
- Elastic Sidechain Creation
- Elastic Sidechain Destruction
- Withdrawals
- Bounty Issuance
It(Skale Manager) also leverage the randomness of the Ethereum Mainnet to select a group of available nodes with enough space on them to go with the desired subnode size and match them to an Elastic Sidechain.
Node Creation
Getting a node added into the Skale Network is not so difficult but needs some requirements to be possible and getting this done, the prospective node has to run SKALE daemon which will help evaluate it and make sure it is upholding all the network hardware requirements. This is a verification stage that has to be passed by the prospective node and if passed, the daemon will then permit it to submit a request to join the SKALE Manager.
The daemon must have collected network deposit and node metadata and this will be contained in the request, examples of things collected are port, the public key, and IP address. The said request will be committed to the Ethereum Network and the prospective node will be added in either of the two wats, as a Full Node or Fractional Node.
Full Node will have all of the required resources utilized for a single Elastic Sidechain while a Fractional Node will operate in Multitenancy i.e in Multiple Sidechains.
Now, the Node is created, it will have a larger group of other nodes as a peer in the network assigned to it, the peers are useful for regular audit node downtime and latency at an already specified and set time(could be 5 minutes, 10 minutes or more), then this metrics will be submitted to the SKALE Manager just once for every network epoch, this information submitted will be used as a determination for node’s bounty reward.
Node Destruction
A created node might want to exit from the network, before this can happen, the node exiting the network must declare their exit first and wait for some time to complete finalization, finalization period could be 2 days or more and after this period, the node will become inactive in the network and also be able to withdraw the initial stake from the network.
During an exiting of any node, if the node cannot wait for the finalization period and the node happens to exit immediately from the Network, this node will be classified and noted as a non-conforming(dead) node by SLA virtualization subnodes, the bounty supposed to be attached to the node will not be paid and then the network will schedule an exiting cycle for the node out of the chain.
Elastic Sidechain Creation
An Elastic Sidechain can also be created with a procedure that starts with the user selecting their chain’s configuration and also submitting payment to the SKALE Manager, this submission has to contain the duration they wish to rent the network resources which is required to run and maintain the Elastic Sidechain. Users have options to select Elastic Sidechains with a minimum of 16 virtualized subnode where each virtualized subnode will use different sizes(small, medium, or large) of each node’s resources, this option given to users is a consideration for them to meet their business budget requirements.
As SKALE Network evolves, it might later be an option for users to specify the number of virtualized subnodes, the size of virtualized subnodes, and the number of signers they want their Elastic Sidechains to contain.
Presently in SKALE Network, there is an equal value of resources, and the cost of consuming these resources is based on the lifespan and size of the chain, resources might later be calculated dynamically to meet with the current network conditions as the network matures.
The SKALE Manager will receive the creation request and a NEW Elastic Sidechain will be created, sending back to the creator, its respective endpoint. if there are not enough available resources in the network that can support the creation of an Elastic Sidechain, the transaction will be canceled and the creator(users) will be notified.
Also, during the creation of Elastic Sidechains, developers are given the option to enable virtualized subnode shuffling to serve as a security measure added to the existing security available in the network. This shuffling is to be done to mitigate any form of collusion attempts by virtualized subnodes within the said Elastic Sidechain and this process is done through the SKALE Manager just in the same way it is done in the node exiting process.
Elastic Sidechain Destruction
Every creation must have destruction, Elastic Sidechain created might at a point need to be destructed. The destruction of an Elastic Sidechain will start to take effect when the user’s duration time, the rental payment which was the deposit for network resources gets exhausted or the users have decided to flag their Elastic Sidechain themselves for deletion.
Just before the time lapses or rental deposit expiration, the creator of the Elastic Sidechain will be notified about their pending chain’s deletion and this notification might be an opportunity for the Elastic Sidechain creator to deposit more and also add time to the chain’s lifetime to continue existing.
But if users Elastic Sidechain’s rental deposit and duration of the sidechain lifetime gets exhausted without additional time being given then it will be due for destruction via SKALE Manager. If this destruction process takes place, the process automatically transfer all available crypto asset from Ethereum to their respective owners on the Mainnet, all virtualized subnodes will be removed from the destructed Elastic Sidechain, their storage and memory will be reset and the Elastic Sidechain will be removed from SKALE Manager before rewarding the submitter of the chain destruction.
Bounty Issuance
It is known that tokens are being minted while nodes are working, all nodes participating in the network are meant to get an equal share of all tokens minted at the end of each network epoch. The amount of issues tokens that can be claimed by each node that participated are calculated based on the metrics submitted by 16 of its 24 nodes that are peers. Tokens that were not attached to any of the nodes because of poor performance will be diverted to N.O.D.E foundation.
SKALE Consensus
SKALE Network implementation was initially created to offer Elastic Sidechains of virtualized subnodes that work together in block creation and committed through leaderless, provably, and asynchronous secure protocol. The protocol was designed to keep the network strong in any case that the virtualized subnodes may have downtime which will be regarded as a low link.
Messaging
- Network Security Assumption
- Pending Transaction Queue
Network Security Assumption
This network security is assumed to be asynchronous as messages are guaranteed to eventually deliver, this simply means all virtualized subnodes available in the Elastic Sidechain are assumed to have a connection through a reliable communications link, this link can be slow during the process but will eventually deliver messages.
Messages are transferred from one subnode to another, from the sending to the receiving virtualized subnode, they’d be multiple attempts until the transfer is finally successful.
Pending Transactions Queue
A lot of virtualized subnodes in the network, each of them are able to maintain a pending transactions queue, and the first subnode to receive the transaction into the queue will make an attempt to spread it to its peer via dedicated outgoing messages queues for each subnode. Messages being sent to the peer are serviced by a separate thread that delivers messages to subnodes in parallel so that any message failure from one of the peers(in accepting messages) will not affect other peers from receiving the same message.
Consensus
- Block Proposal
- Data Availability
- Pluggable Binary Byzantine Agreement
- Finalizing Winning Block Proposal
Block Proposal
The previous consensus round which is messaging as must have been completed and immediately each virtualized subnode’s TIP_ID will increase by 1 then, a block proposal will be created.
Before a block proposal can be created, a virtualized subnode will do the below listed
- Examine all pending transaction queue it has
- All transactions from the queue will be taken by the virtualized subnode to fill in a block proposal if the transaction in the queue is less than or equal to MAX_BLOCK_SIZE.
- The oldest to the newest received order will be used by the virtualized subnode to fill a block proposal if the total transaction in the queue exceeds the MAX_BLOCK_SIZE.
- Block Proposal with transactions ordered by the SHA-256 root from the oldest to the newest received will be assembled by the virtualized subnode.
- If there’s no pending queue at all, the virtualized subnode has to wait for BEACON_TIME, but if the queue is empty still, an empty block proposal will be made with no transaction in it.
Data Availability
There’s a protocol called Data availability protocol which ensures that messages are passed to the supermajority of virtualized subnodes. Once a block proposal is created, the data available protocol does it work by communicating it to other subnodes.
Here are the steps of the Data Availability Protocol;
- One virtualized subnode will serve as the sending one (Assumed to be A)and it will be sending 2 things which are, block proposal and the transaction hashes composing the proposal (Assumed to be P) to all its peers.
- Peers must have transactions in their pending queue and upon receipt of block proposal from virtualized subnode(A), each peer constructs the proposal(P) by matching hashes with transactions showing in their pending queue. If any peer can’t find transactions in the pending queue, the peer will send a request to the sender which is virtualized subnode A, then A will forward back to the peer virtualized subnode it receives from, the bodies of these transactions, upon receipt again, the peer will reconstruct the block proposal and have it added to its proposal storage database.
- After the block proposal has been reconstructed and stored by the peers, they send a receipt back to the sender virtualized subnode containing a threshold signature share of the proposal(P).
- Virtualized subnode A will wait to gather signature shares from the majority of the peers that are supermajority(>2/3) which also include itself. After gathering the signature shares from the peers, A will create a supermajority signature (Assumed to be S). Then S will be the evidence that the supermajority of virtualized subnodes have received and signed the proposal(P).
- After all, this has been done, the virtualized subnode A will broadcast the supermajority signature it has created to the other virtualized subnode in the network.
Pluggable Binary Byzantine Agreement
This is another consensus and this particular one uses Asynchronous Binary Byzantine Agreement(ABBA), currently SKALE Network uses ABBA from Mostefaoui et al, this doesn’t mean that any other ABBA protocol cannot be used, but it can only be used if it satisfies the properties stated below:
- Network Model — Proposal assumes an asynchronous messaging system described above in Messaging
- Byzantine nodes — Proposal assumes less than one-third party of the nodes(Byzantine).
- Initial Vote — Proposal assumes to receive an initial yes/no vote from each node.
- Consensus Vote — Proposal terminates with a consensus vote of either a yes or a no, if the consensus vote is yes, there’s a guarantee that at least one of the nodes will give a yes and that node will be known as the honest one.
Finalizing Winning Block Proposal
Immediately consensus with winning block proposal(P) on any Virtualized subnode A, before the proposal can be finalized and committed to the chain, the virtualized will execute some algorithm, see below;
- Virtualized subnode A will look for the receipt of winning proposal(P)
- If A can’t find a receipt of P, A will request it from the virtualized subnode which is also a peer.
- Virtualized subnode A will wait to get signature shares from a supermajority of other peers including itself.
- The received signature shares will be combined by A into a threshold signature.
- Lastly, A will be able to commit the proposal(P) to the blockchain alongside that threshold signature gotten from the combination of signature shares of peers.
SKALE Virtualized Subnodes
Within the Skale Node, subnodes are referred to as Virtualized Subnodes, each Virtualized Subnode participates and contributes in independent Elastic Sidechains. You can see a container running on a SKALE virtualized subnode in the picture below.
To bring enterprises grade performance and optionality to DApp developers on par with centralized systems, this offers configurability, elasticity, and modularity, these containers are into 5 main components and each container is enclosed in one of the services explained below;
SKALE Admin Service
This is a service that serves as a human-facing interface for virtualized subnodes with the SKALE Manager and it is located on the Ethereum Mainnet. The function of this interface includes that nodes are able to see which of the Elastic Sidechain they are in and which is able to withdraw, stake, and claim SKALE token. This service is useful because there’s no interface for virtualized subnodes to join or leave Elastic Sidechain as they are always appointed randomly to participate.
Node Monitoring Service
This is a service that facilitates performance tracking of each node’s peer node running on each SKALE Node. Uptime and Latency are majorly used for performance tracking through a regular process of pinging each peer node and logging the measurements to a local database. This monitoring service is a very good metric to determine the payout of each node, this is done by submitting the metric to the SKALE Manager.
Virtualized Subnode Orchestration Service
This particular service (VSOS) uses computation and storage resources to instantiate virtualized subnodes by creating a dynamic virtualized subnode as an image consisting of the SKALE daemon, one is used for syncing Elastic Sidechain and the other for interchain messaging(Catchup Agent and Transfer Agent). Services also help greatly in respawning all failed virtualized subnodes and reallocating resources of virtualized subnodes that have been decommissioned before.
Attacks and Faults
Every network is prone to attacks and faults, on SKALE Network, there’s likely to be a downtime which is why SKALE has integrated different contingency strategies to account for faults that may arise on any side, either of the node or chain level. One of the integrated strategies is an automated agent for recovering the performance of a downed node to the security incident team that will respond swiftly and be available to all Elastic Sidechain operators in the network.
Reboots and Crashes
In the case where a node needs to reboot, the particular node will be temporarily unavailable and for peer nods, it will appear like a temporary slow network. After the reboot is done, messages that were meant for the node will still be delivered. This is a very smooth way of rebooting without disrupting the entire consensus operation.
If it is a crash where a node loses its consensus state, the peer nodes will keep attempting to send message to the crashed node until there’s an overflow in the outgoing messages queue which will result in the nodes dropping older messages, the reduce the effect of the crash, messages older than an hour time will be dropped from the queue.
Catchup Agent
After a crash, i.e when the node comes back online, the catchup agent running on each node is responsible for the node’s blockchain and block proposal syncing, it will continuously make a random sync connection to other nodes and any node discovered to have a missing block will have to download them, verify supermajority threshold signatures and commit them to its chain.
While the node is on the catchup procedures, it can still simultaneously participate in the consensus for new blocks, also it will still be able to accept block proposal and also vote according to the consensus mechanism but just won’t be able to issue its own block proposal.
Security Incident Response
All decentralized platforms’ foremost requirement is security, but no matter how strong is the security, it has been agreed that no security is perfect but architects have tried to raise the bar as much as they can for the possible amount of resources that can be used to break into the system.
SKALE architect is based on Elastic Sidechain, the security breach might come from one of the ELastic Sidechains which is why a default procedure has been put in place in case of any suspects.
- Owners of Elastic Sidechain suspecting any security issues are required to issue a request to the Ethereum SKALE Manager for a temporary suspension of the affected chain.
- The Elastic Sidechainwill be marked by the SKALE Manager as suspended.
- All clients of the Elastic Sidechain will get a notification of the suspension.
- The creator of the Elastic Sidechain will be given the opportunity to ask the N.O.D.E foundation Security incident Responded Team(SIRT) for help in resolving the issue.
The members of SIRT are elected community security experts nominated by SKALE stakeholders, who are all getting compensations from the N.O.D.E foundation.
SKALE Protocol
Next Gen PoS-Based Network
PoS- Proof of stake concept is used by so many blockchain networks, it is a concept that a particular user using the network(a person always refers to each account or wallet) can mine or validate block transactions based on the number of coins they are holding in an account. The number of the coin they are holding determines the power of the users on the network.
Now in SKALE Network, a proof-of-Stake system is being followed where there’s a predetermined amount of SKALE token for each node to stake, this SKALE token is to be slashed at the extract of any activity not allowed in the network.
Some of these activity includes those that have failed to participate properly in the assigned chain’s consensus and those that also failed to maintain the standard latency and uptime enforced by the network-agreed-upon SLAs(Service Level Agreement).
Network SLAs can be described as an agreement on the network enforced through an algorithmic peer review system where all nodes will get 24 peers to monitor each other and log network participation, latency, and uptime.
SKALE Proof-of-stake, i.e. the requirement to stake a sum of SKALE token before a node can participate in the network is also a measure in Sybil-resistance to thwart any adversarial attempt.
Delegations
This is another important aspect of Proof-of-stake, SKALE users/holders are allowed to delegate their SKALE token to any node they want within the network that has not been able to get the maximum number of tokens to be staked, all delegated tokens will not get the same reward with the virtualized subnode in the network epoch.,
Due to Skale’s Consensus Decentralization, virtualized subnode weighting will not be able to control the reward gotten by each node nor how the nodes propose and commit new blocks to any chain.
SKALE consensus algorithm accounted for malicious actors within the network which can cause fault and interfere with the network messaging, this is to curb the downtime of nodes within the network. SKALE network currently uses a variant of Moustefaoi et. al consensus to make sure for highly desirable and everything needed for truly decentralized as well as high-throughput network
Leaderless
Leaderless here simply means a decentralized or distributed protocol. SKALE Network uses a kind of consensus protocol that allows all or any virtualized subnode to propose blocks and each of the subnodes that are able to receive a supermajority of signatures known as “a threshold” will be eligible for acceptance for potential commitment to the blockchain.
This Leaderless consensus protocol of SKLAE Network prevents collusion among network participants and it gives every virtualized node a fair chance to propose a block within a chain.
Asynchronous
SKALE uses asynchronous timing, this model used by SKALE Network doesn’t give bound or expectations placed on how long it can take for messages within the network to be delivered, All virtualized nodes within the network send messages and never expect an immediate response, and also the implementation of exponential backoff steps where redeliver of messages are attempted, these are messages that have been lifted unresponded to for a longer interval within the network.
The asynchronous model is an accurate model to capture the current state of how the internet functions and all messages of failed nodes in the network are dropped all the time.
Byzantine Fault Tolerant(BFT)
This is a security standard distributed within the system, systems with BFT have the guarantee that all nodes in the network will agree on the same consensus if there’s any malicious node or nodes, Nodes that are said to be malicious must be exhibiting different behaviors that are not allowed within the network, these behaviors include non-participants in the activities of the chain, lying and collusion. Out of all BFT implementations, the asynchronous BFT(ABFT) is known to be the strongest.
Threshold Signatures
Threshold signatures are used for supermajority voting, this is the signature( a threshold) created by a sending virtualized after receiving a message from the supermajority of other virtualized nodes in order to be able to proceed with the proposal being processed.
SKALE Network uses Boneh Lynn Shacham (BLS) for supermajority voting which is why after the creation of an Elastic Sidechain, BLS private key shares(PKS) are always created using g joint-Feldman Distributed Key Generation (DKG), which will now be issued with to each virtualized subnode. All private key shares(PKS) are stored and made public for the purpose of signature verification on SKALE manager.
Extensions
Considering the network architect and protocol used by SKALE Network, there are chances to add extensions easily to bring about more utility and functionality of the network. There are two available where the first is an enhanced Filestorage within each node and the other is a mechanism for executing and relaying messages between the network Elastic Chains.
Storage
In SKALE Network, to allow much larger file storing capabilities, the already existing EVM has been modified. This change was enabled through the increase of block size, this will allow for more data to be added in the block as well as having direct access to each node’s file system smart contract where filestorage was precompiled.
Interchain Communication
In a Network consisting of different independent Elastic Sidechains, signing signatures as a group and verifying that a block has been committed and signed on another independent Elastic Blockchain, which will now make it possible for the execution of the smart contract and at the same time being able to transfer crypto-assets across various Elastic Sidechains, we can say there’s a smooth Interchain Communication.
The interchain communication process is facilitated using a series of smart contracts on the Etehreum Mainnet, all Elastic Sidechain and the agent running on each virtualized subnode is responsible for facilitating the exchange of messages between the sidechains.
The Elastic Sidechain message exchange is possible with the inbox and outbox on each sidechain, messages from Elastic Sidechain A will be kept in the outbox until any random available agent is able to pick it up and deliver it to the appropriate chain’s inbox adding the metadata required for the receiving chain to validate that the said transaction was actually included senders chain’s blockchain. Once the information has been confirmed, the transaction will be sent to the destination address through an on-the-chain messaging proxy.
When the interchain exchange is of a value transfer from a parent blockchain, could be Ethereum mainnet, the system makes use of a depositBox as the caching mechanism and a two-way peg that issues vouchers against the pooled value on each of the Elastic Sidechains, and it will be exchanged freely among all participants just the same way it is being done for transactions.
But when the value exchange is between Elastic Sidechains, to avoid the possibility of double-spend, the value is first deleted on the sending chain and then recreated on the receiving to ensure a smooth exchange of value between Elastic Sidechains.
Governance
Every blockchain network claiming to be decentralized and not owned or controlled by anyone must have a group of stakeholders who are making every mission of the community possible. They are able to make contributions and make important decisions on security, achieving the aims and objectives of the network, and the quality of services provided.
The coming together of the core stakeholder is referred to as Governance and Governance group for SKALE Network is N.O.D.E Foundation. This is a foundation set up by SKALE Labs, they pass over a collection of assets, money, IP, and power to the foundation. From here the foundation can now release control after network launch to a decentralized governance model for SKALE Network Governance.
To control economics parameters, SKALE Network uses on-chain voting, this on-chain voting will make more effective with the support of the Network representatives and a Foundation council shaddle with the responsibility of checks and balances.
Having the role of Council and Network Representatives which is best to facilitate community and decentralized control is only through efficient On-chain voting.
Therefore, Governance in SKALE Network is through a Delegated Stake Model where anyone that wants to be called a stakeholder within the network can either participate in governance by voting directly with the stake they have or delegate their voting power to other stakeholders.
The duration of a proposal on SKALE typically includes 14 days voting period while SKALE tokens have 90 days of “Committed and Formalized Stake”, before participating in voting within the community.
Any token that has been committed for a period of 90 days is automatically eligible to vote on important key issues brought up by the SKALE council and it will be equal to and the same seat from the N.O.D.E. Foundation, Investors community, and all other community consisting in the Network.
SKALE Token
It is well known that everything about cryptocurrency and blockchain technology has a direct relation with money and no blockchain network doesn’t require an exchange of value for value, even if it’s not directly, somehow they must be a party demanding and the other party supplying, they must be a party selling and they must surely be one buying, even when there’s no buying and selling in any blockchain ecosystem, there has to be a party rendering services to the other and definitely they must be a need to pay for services rendered or give something in exchange for what you are buying.
SKALE Network is an Elastic Blockchain network on the Ethereum blockchain allowing users/consumers to build powerful Ethereum network DApps and running them in a decentralized modular cloud, this modular protocol is one of its kind that gives room for developers to easily create highly configurable blockchains without violating or going against decentralization rules as well as not compromising on computations, security and storage.
Having said what SKALE Network does for DApps developers(Which is their users).
This shows that SKALE Network renders a very unique service to ease developers’ all stress relating to traditional blockchain development. Hence, the service rendered to the consumer has to be paid for.
SKALE have gotten their own ecosystem currency in form of a crypto token, this token has been created with its value and has a total supply, it(SKALE token) is the currency of the ecosystem which will be used as a transfer of value from one user to the other.
SKALE network will also be able to use their currency as compensation for community contributors and team members working towards the growth of the Network. Users using the Network services will also pay with SKALE tokens which means, the currency of the SKALE Network is the only acceptable means of payment within the Network.
SKALE token has a symbol (SKL) and it represents the right to work in the network as either a validator or a delegator. Users on SKALE Network use a subscription model to make payments for renting the resources of the network(computations, storage, and bandwidth) for a noted specified amount of time in form of an Elastic Sidechain.
SKALE validators stake their SKL token into the network and this gives them the automatic right to run nodes and earn through fees and tokens via inflation while Delegators in the network can delegate their SKL token to validators to earn rewards based on the amount of token delegated.
Read below to see how SKALE token is being distributed within the ecosystem.
SKALE Distribution
- The number of tokens
- This is the total supply of the SKL tokens at launch which is 4,140,000,000 but the network has a maximum supply of 7,000,000,000 Skale token(SKL) in total.
2. The Distribution
- 34.3% of the total Skale token is allocated to the Validators community and Ecosystem, out of 34.3%, 33% is set to be distributed to validators via inflation while the remaining 1.3% will be used for ecosystem growth distributed as grants and awards.
- 25–28% of the total supply is allocated to users supporting the network through the purchase of token before the Network launch having the intention of running validator nodes, delegations, and/or using the network Elastic Sidechains for their decentralized Application (DApps), this tokens will be locked for a period of 6 months to 3 years after the network launch.
- 7.7% of the total supply is set and will be dedicated to supporting the Network Protocol Development for future financing and grant efforts which are directed towards support, improvement, and enhancement of the Network.
- 20% of the total SKALE token was allocated to those participating in Network creation and buildings, these are the SKALE network developers ensuring everything is going as planned from inception within the Network, the allocation is for a 3–4 years vesting period and locked for 12 months, both the 3–4 years vesting period and 12 months locking will commence immediately the network launch leaving the whole period at 5–6 years based on 2019 3rd quarters(Q3) launch date.
Out of 20%, 16% will be for the broader foundational team members and the other 4% will be for the Employee Token options pool which will further ensure the development of the SKALE Network.
- The N.O.D.E foundation got a 10% allocation. 150 million are minted based on the mode of formation and 550 Million will get minted after the sixth(6) month using an unlocking schedule which will commence at month 24 as a milestone achievement that includes an active running network and a community of users running nodes as a validator.
- 2.5% of the token is allocated to the public token events.
3. Vesting Schedule and Lock-ups
- Some tokens are pre-purchased before SAFT rounds, these tokens are locked from a period of 9 months to 36 months using the agreement on SAFT, the lock will take effect from the network launch date.
- The team tokens will have a lock period of 1 year and a vesting period of 3–4 years, lock and vest period starts at the launch of the network.
- Then the foundation vest is for a period of 7 years and more.
4. Inflation
- This happens in almost all blockchain network and is not different for SKALE as well. In SKALE, the Validator Reward Mechanism is set at 9.3% of the maximum supply for the first year. The reward for validators will ladder down in the first 6 years and then starts to halve every 3 years till forever until the maximum supply of the network token is reached. These numbers are subjected to changes based on feedback gotten from the community and also economic analysis. See token distribution chart below
Conclusion
SKALE Network’s aim is to bring scalability, cost-effectiveness, and efficiency to all decentralized applications in order to make sure the promise of being decentralized will have an everlasting impact on humanity globally.
SKALE Network is trying to grow so much that they are able to entertain hundreds and thousands of virtualized subnodes, and in collaboration with the Ethereum Network Ecosystem, they can run an unstoppable and fully decentralized internet in the future.
Read the below summary for the great work of the SKALE Network team in 2020.
SKALE 2020 Review
For a blockchain network that wants to provide the best services to their users, they are always building and building, looking for the best way to serve their consumer’s right.
Consumer satisfaction should be the ultimate goal for every business, therefore SKALE Network tried its best to have a successful 2020.
They spent the year as thus,
January — Hustle Mode
In January 2020, SKALE Network team as a whole was in hustle mode, the whole team behind SKALE were working hard to get the network prepared for Consensys to activate the Proof-of-USe launch.
February: Support the hackers
ETH Denver hackathon put the SKALE Network developers in a very tough position, resources were called off the mainnet just to get the testnet working according to the updated core code changes to SKALE consensus and SKALE D. 2–3 weeks of the developers time was given to this and it ended up a huge success for the team as they updated the testnet and prepare for a global PR announcement of the public sale and the initial Proof-of-Use launch.
March: ETH CC and COVID19
Covid was a totally new story that hinders a lot of things and ETH CC was attended by only few core team members of SKALE and the plans have to be changed. SKALE adjusted some of the previously planned goals, Q1 goals were skipped as it couldn’t be met.
April: New Mode of Operating
Members got used to not working together in offices due to social distances. The offices were closed and members had to work from home. This new mode of operation was at first a challenge but everybody finally got used to it.
May: Hope
The team members got used to working from wherever they work from and it was time to hustle hard, they figured out how to be productive.
The team keeps building and the SKALE innovator program was getting new leads everyday as almost 10 DApps joined the SKALE innovator program.
June: Mainnet Phase 1
The core team members had been committed to working hard as much as they can, and here the number of organizations on the SKALE network increased, moved from 10 to 50 with a lot of people working with SKALE network to help run the testnet. The team worked so hard and in June, SKALE Network went LIVE.
July: Breath of fresh air
July was uneventful, the team has a little fresh air breath but August happens to be tough.
August: An unplanned but fortunate event
The SKL auction day was a big day for SKALE Network team, over $70M in value was to purchase SKL during the Auction, and over 12k people signing up, where 4k trying to get over hurdles stopping them from getting participation approval. For better Understanding, Read more HERE
September: Validators step up!
The token sale happened in September and it was all success for SKALE Network as almost 4k persons from over 90 countries around the world purchased SKALE tokens.
Everyone who bought the token had to stake them in order to have them unlocked in December, everything was possible using a smart contract. You could get more information here.
October: Phase 2 Launch!!!
Plans going well and all the countless hours of work paid off for the team, SKALE was LIVE and it was used to run a completely decentralized network. Details here
November: Prep for December
November was a month to prepare for December. The team was standing up new validators and they are getting prepared for exchange listing, the token was meant to go LIVE and be liquid on 1st of DEC.
December: Mainnet Phase 3. Lift off!
The SKALE token went liquid on Binance and Huobi on the 1st of December as planned, the community was always there to make it all work for SKALE, they got liquidity on Uniswap to make SKL available for swap on Uniswap.
2020 was a great year for SKALE NETWORK, SKALE moved from a community of 100 people to over 10,000 people globally. 3 phases of SKALE was successfully launched in 2020.
This is just a summary of SKALE Network 2020 review.
To read the full 2020 review of SKALE NETWORK by JACK O’Holleran — The CEO and Co-Founder of SKALE NETWORK, Visit here
