The internet has done a fine mimicry of Mother Earth by becoming the platform in which all forms of digital innovations run: applications, software, websites, you name it. One way or another, these creations have deep roots on the internet or something that tethers them to it. Think of all the big guys you know. There’s Facebook, Amazon, Netflix, Twitter, etc. all of these major sites all have Amazon Web Service as their ‘Mother Earth’.
With the heavy reliance on AWS, most services have experienced glitches and downtimes within the space of years, If you’ve been using AWS since its inception then you’ve probably experienced quite a number of these glitches. All things being equal, these glitches are pretty minor, inconsistent, and not that big of a deal.
That is unless you are considering a future that will utilize the infrastructure of AWS for independent software.
It won’t do for your autonomous train or airplane to experience a ‘glitch’ while transporting you and other passengers. This is why the blockchain crusade is investing in countless efforts to modify and improve the status quo.
You probably thinking; what improvements does a company like Reddit or Amazon need on their AWS? They look fine to me. And you are right. Many of the big guys are in centralized communities which automatically gives them an edge.
However, this is not so for those in decentralized communities who have scalability as a long-standing problem. This problem is especially amplified when operating via Proof of Work to attain a consensus. Though the journey to swift and efficient consensus infrastructure is a bit slow, it’s progressive and has produced effective second layer keys that fund parts of the system like sidechains, state channels, plasma, and so on by taking value from one of the central Proof of Work chains.
The unique thing about this development is that each of these has retained its various stipulations which tout capital lock up, security, data availability, and lastly, efficiency.
Now, where does the SKALE Consensus come in? SKALE has contributed its quota to the agenda by developing a super scalable sidechain infrastructure that would guarantee an adequate decentralized scaling solution for Ethereum.
And each of these still has its caveats in terms of security, efficiency, capital lockup, and data availability. The SKALE network has successfully developed a sidechain system with enough scalability in its infrastructure to solve the problem of decentralized scaling for Ethereum.
We will now be sharing the technicalities of how SKALE came to achieve this consensus mechanism as well as everything you need to know about the SKALE network.
As the new kid on the block, SKALE proposes a network of on-demand blockchain that is configurable and well dispersed. This exceptional network will sustain:
- Reduced cost
- Increased input
- Reduced latency transactions
You’re probably wondering how the company intends to provide Ethereum as a Service. This will be achieved with a decentralized network that is not only gasless but centered on subscription.
This interesting characteristic will be used to create byzantine fault-tolerant blockchains that are secure, storage-enabled, compatible with EMV, and capable of high input.
What will these blockchains be used for?
Elastic sidechains that are compatible with Ethereum.
Every one of these sidechains, also known as Proof-of-stake sidechains consists of nodes that stake SKL tokens(Skale native token)on the mainnet of Ethereum. For better results, these sidechains are also super configurable. Additionally, Ethereum-compatible sidechains take advantage of asynchronous byzantine fault-tolerant protocols for their consensus infrastructure.
For less tech-savvy readers, we will break down the concept of sidechains.
Sidechains are run by subnodes chosen from a subset of nodes in the network. To operate, these nodes must run on all its computation or subsets of its computation. Each one must also run on its storage resources as well.
Moving on, let’s see how the business of SKALE and its Ethereum mainnet works.
The SKALE network possesses tokens which are usage and work tokens, meaning for nodes to work on the network, they ought to run the SKALE daemon and stake several tokens that have been prearranged.
This takes place on the Ethereum mainnet using the SKALE Manager which is a type of smart contract. A total of 24 peer nodes are then chosen at random to audit latency and uptime after any node has been admitted to the network.
Following this, the metrics of this operation are handed over to the SKALE Manager. It is this data that determine a node’s rewards.
Now, how is an Elastic sidechain created?
Consumers on the network choose the chain configuration they prefer and remit the required payment for the duration of time they intend to run the chain with the resources they rented.
The exception to note here is an insufficiency of bandwidth. If this is enough, all nodes which meet specifications for the chain’s storage and computation will then be allowed to partake in the chain’s virtualized subnodes by random selection.
Let’s elaborate on the EMV-compatibility in Elastic sidechains and its function in the SKALE network. With EMV-compatibility, participants on the network can install pre-existing smart contracts to them while eliminating limitations to storage and computation in the Ethereum mainnet EVM through augmented gas restrictions.
Why is this so important? The answer is simple. It enables more smart contract use cases. Another nugget the SKALE network will be enticing the industry with is messaging protocols which will allow participants to navigate and communicate between the network’s contrasting systems.
SKALE-SUPPORTED CONSENSUS PROTOCOL
Like any other network, the entire SKALE system is run on a set of protocols that guide its primary and secondary entities. These protocols ensure flawlessness and organization in the network.
By integrating a Proof-of-stake infrastructure, the SKALE network can foster decorum and decent conduct among participants. This Proof of stake (PoS) system requires every node to stake a prearranged amount of tokens which will then be withheld in the advent of improper conduct.
• Messaging
The SKALE protocol for messaging is determined under the assumption that the network does not occur at the same time as a delivery guarantee in the long run.
This means that consumers should expect communication links to be slow but messages will be delivered accordingly. You won’t be incorrect to compare it to bigshot networks like Ethereum or Bitcoin.
In our opening paragraph, we mentioned brief glitches in hosting providers and how these glitches eventually resolve themselves. It’s pretty much the same thing with SKALE’s asynchronous model. Here is how this eventual delivery guarantee is achieved.
Sending nodes start by making attempts with exponential backoff to transfer the message to the receiving node until the transfer has been deemed successful. Note that these attempts by the sending nodes are often serial.
There’s more. For every receiving node, a distinct outgoing message queue is maintained by the sending node. Marking out messages for eventual delivery to anyone node is done by placing the message in the right outgoing queue and outgoing queues are supported by a unique, individual thread that permits delivery of messages in a way that preserves the message receipt of other nodes if one node does not accept messages.
• Block proposals
Nodes play a highly essential role here.
1. They create block proposals by inspecting their pending transaction queue. That is, should transaction size in pending queues result in the same amount or less than the amount of the MAX BLOCK SIZE, the node will take all transactions from the queue by entering a block proposal.
2. They enter a block proposal of MAX BLOCK SIZE should the overall transaction size of contents on the pending queue surpass MAX BLOCK SIZE. This is done by organizing all pending transaction from the queue from old to new
3. They put together block proposals as requested by SHA-3 hash in order of their value from smallest to largest.
4. They wait for BEACON TIME should the pending queue be empty and create empty block proposals if queues remain empty after BEACON TIME.
5. They send block proposals and transaction hashes after creating any block proposal. This is usually done by the creating node.
6. They reconstruct the proposal from hashes after receipt by syncing messages in its pending queue and hashes together. This procedure is carried out by the receiving node.
7. They send requests, receiving node to sending node if a transaction is not identified on the pending queue. This notifies the sending node to submit the make-up of these transactions for reconstruction by the receiving node.
Consensus
Under SKALE supported protocol, consensus possesses what is known as a supermajority signature S. This signature is created solely for proposal P and precedes the initiation of ABBA or Asynchronous Byzantine Binary Agreement for the finalization of the block.
ABBA is conducted for every N supermajority signatures and this takes place where nodes vote yes or no to having the supermajority signature and proposal in their proposal storage database or not having these two factors.
In consensus, after all, ABBA stipulations have been met, a vote vector is created, consisting of yes or no option for every proposal. More than one yes vote requires the random pseudo selection of proposals voted yes using the random pseudo number R. On the other hand, a single yes vote means that resultant block proposal P is committed to the blockchain.
At the end of this procedure, the winning proposal is the modulo of R by N_WIN. Bear in mind that there is the possibility of an all-no vote though there is only a slight chance of this happening.
Nonetheless, in such a case, the empty block is committed to the blockchain. In the rare case where all votes are no, an empty block is committed to the blockchain. The probability of an all-no vote is very small and decreases as N increases.
One vital factor of developing consensus algorithms is to build them while keeping the possible interference of malevolent agents such as bugs, viruses, Distributed Denial of Service, botnets, bad firewalls, and so on.
These agents we’ve mentioned are capable of interrupting network messaging. In this regard, the SKALE network implements Moustefaoi which possesses features that are useful to the network’s goal of a distributed network of heightened output.
In SKALE consensus, data availability also has its role to play. The instant a virtualized subnode creates a block proposal, the subnode will relay this proposal to other virtualized subnodes through a brief data availability protocol that will ensure delivery of the message to the supermajority of virtualized subnodes.
• Signature Aggregation
In signature aggregation, the receiving node includes P to its proposal storage database before submitting the receipt together with a P
signature share back to the sending node. This action is executed following the rebuilding of proposal P. to create a supermajority signature S, the sending node will be delayed until it has received its signature shares from a supermajority of nodes.
It doesn’t exactly end there. At this point, the sending node will then collectively share this signature S to other nodes. Interestingly, each node possesses what is known as BLS private key share PKS.
• Catchup Agent
Catchup agents programmed to run consistently on and for every node were created to ensure that both block proposal database and node’s blockchain are in harmony with the network. How does the Catchup agent successfully execute this task? By making unsystematic sync connections to other nodes.
Through this seemingly irrelevant action, any node with a smaller TIP_ID than its peer nodes will simply download its missing blocks after authenticating supermajority threshold signatures. The last step here is to commit these downloaded blocks to their chain.
By design, nodes come back online after a hard crash and automatically run through this catch up procedure. While this is taking place, these nodes participate at the same time in new blocks’ consensus, and they do this by accommodating block proposals. They also withhold block proposals despite following consensus mechanism to vote.
The reason for this is that each block proposal requires the hash of the previous block, and a node will only issue its block proposal for a particular block id once it has finished the catch-up procedure.
This protocol, makes it easy for nodes to smoothly rejoin block proposal when they experience a hard crash. They simply resync their chains and get back on board.
• Reboots and Crashes
The reboots and crashes mechanism for the SKALE network is designed in a way that allows the rebooting node to become unavailable for peer nodes for a brief period. Messages sent at the same time this reboot takes place are then delivered.
This saves the day as reboots are allowed to occur without disrupting the smooth running of network consensus.
Now a reboot is not the same thing as an outright crash. In a crash, which is often the result of a software virus or hardware failure, a node is most likely to lose a consensus state.
Meanwhile, bugs or hardware failure compromise the online presence of a node, causing a spill to occur in its outgoing messages queue as peers try to send messages. This overflow is what makes older messages virtually disappear.
Crashing nodes are classified as Byzantine nodes for every consensus round permits <1/3 of nodes to undergo tough crashes at once. Should >1/3 nodes experience this same hard crash, the blockchain will lose its liveness as consensus stalls.
As new blocks fail to integrate in their appropriate time, the network can then detect this sort of huge glitch. Well, what happens next then? A failure recovery protocol, using the Ethereum main chain for the organization is then instituted.
At this point, all nodes will cease their consensus activity or operation to harmonize their blockchains while approving a set time to restart the consensus. With a collective agreement in place, nodes will resume consensus following a period of binding inactivity.
Security
In distributed systems, the security protocol here is Byzantine Fault Tolerant, meaning that there is a supreme assurance that all nodes in the network will always reach a compromise when <1/3 nodes that are unethical pop-up. Interestingly, BFT is not the only security protocol ou there. There are several of them out there; one of the most impenetrable being Asynchronous Byzantine Fault Tolerant.
“As essential as security is to any decentralized system, most security experts have concurred on the fact that no network can fully achieve perfect security. The only option for any system is to keep raising the notch as high as they can on the cost and resources required to infiltrate their network and compromise it.”
· Delegation
In the SKALE network, it is completely safe for holders to delegate tokens they own to any node lacking the required amount of staked tokens. What happens with this development is that these delegated tokens will have reduced rewards than that of virtualized subnodes.
· Leadership
If you are familiar with other distributed consensus protocols, then you are aware that every round to introduce a block for the network to run consensus and agree requires the election of a leader. What makes the SKALE network unique is that instead of an elected leader, the network is leaderless.
The SKALE network innovatively introduces a procedure that enables virtualized subnodes to offer blocks. In this case, no other subnode is qualified for possible integration into the blockchain except subnodes which have received a supermajority of thresholds or signatures.
Why a leaderless network you may ask; the SKALE network chooses to operate without elected leaders to avoid clashes among its participants. Also, a leaderless protocol creates sufficient room for virtualized subnodes to propose a block within a chain.
· Asynchronous
This characteristic of the SKALE network’s consensus protocol allows the present state of how the Internet functions to be captured precisely and corrected. This functionality of the Internet provides valuable information on where messages get spliced off and where network nodes malfunction. Here is out it works. The asynchronous timing model is not conformed to the restrictions that require an estimation of how long a message is delivered in the network.
With this network, when virtualized subnodes send messages, they execute this action with no expectation of a response. Following this, subnodes go on to implement an exponential protocol for backoff, redelivering, or trying to redeliver messages which haven’t received a rejoinder, also having lengthy interludes in between.
A continuation of SKALE components
SKALE VIRTUALIZED SUBNODES
Virtualized subnodes in the SKALE network are distinct in design, unlike other protocols out there. What makes them different is the absence of restrictions to one-to-one mapping that happens between participating nodes in the SKALE network. Virtualized subnodes are the elements of each Elastic Sidechain.
In the SKALE network, one-to-one mapping between participating nodes is facilitated by containerized virtualized subnode architecture. Each of these architectures is transferred on each SKALE node, letting it operate a series of Elastic Sidechains at the same time.
The choice of containerized architecture is to introduce the same optionality and premium performance common with centralized network systems in the industry to the benefit of decentralized application developers.
With containerized architecture, the SKALE network can also offer the following:
- Flexibility
- Modularity
- Configurability
The design of containerized architecture is pretty straightforward. Its architecture is split into five main components. All five components partner with a dockerized Linux OS with which nodes can be hosted OS-agnostic style. It only gets more interesting. Containers are integrated into three services:
· Virtualized Subnode Orchestration Service
This service has several functions. VSOS operates as a facilitator for storage resources and node computation. With the aid of a unique virtualized subnode image made up of the SKALE daemon, virtualized subnodes are instantiated.
Also, transfer agents, as well as the Elastic Sidechain, are easily synchronized with the Catchup Agent. Other functions of VSOS include withdrawal of resource allocation from virtualized subnodes that have been put out of commission.
· Admin Service
Admin Service comprises of an intelligent interface for dealing with humans. This service is designed for virtualized subnodes with SKALE manager.
Nodes are not only able to withdraw, claim STAKE tokens, and deposit, they can also see which Elastic Sidechain they are participating in.
The Admin Service is quite the innovation because its functionality gives nodes some form of closure as virtualized subnodes within nodes are unable to leave or join Elastic Sidechains due to the absence of interface which results in random selection.
· Node Monitoring Service
In a nutshell, NMS is used for one thing; performance tracking. This is run on SKALE nodes to track the peer nodes of each node. How is performance tracking measured? Using latency and uptime in a standard procedure.
This procedure starts by pinging a peer node before logging measurements into a database. Metrics are then averaged and submitted to the SKALE Manager after the end of the allotted time for each Elastic Sidechain. This data is used to allocate payments to nodes.
SKALE MANAGER
You’ve recalled the SKALE Manager we mentioned earlier? Now we get to elucidate its concept. The SKALE Manager functions as the point of entry to other smart contracts in the community.
Operating on the Ethereum mainnet, SKALE Manager has the responsibility of ensuring all components of the network function smoothly and in the appropriate synchrony.
Some of its entities include withdrawals, Elastic Sidechain creation, destruction, Node creation, destruction bounties among others. We will now proceed to break down some of these entities.
· Elastic Sidechain destruction
Destruction of an Elastic Sidechain is possible if the rental deposit of a consumer for resources on the network has been used up by the consumer.
Another valid ground for destruction is the consumer herself puts her Elastic Sidechain for destruction. Now, the system of the network is consumer-oriented so much so that you as the consumer get an adequate notification before your rental deposit is exhausted.
This notification gives the creator ample notice of the imminent destruction of their Elastic Sidechain. Nat this point, the creator can top up the lifespan of their chain or just simply allow it to get deleted.
· Node Creation
Adding a node to the system requires the intended node to evaluate itself by running the SKALE daemon. Why is this necessary? This procedure makes certain that the prospective nodes meet up to the hardware stipulations of the SKALE network.
After a node has been authenticated, it then receives authorization from the daemon to submit a request for participation on the network. This request is made to the SKALE Manager and contains metadata from that node and the standard deposit.
The last procedure here is for the node to be institutionalized to Ethereum as a fractional or full node. As the terms imply, fractional nodes are allocated multitenancy with more than one Elastic Sidechain while full nodes enjoy the benefits of having all resources maximized for one Elastic Sidechain.
· Node destruction
Node destruction is executed with sufficient notice which must receive validation before the node can be deleted from the network.
The validation of a node’s exit notice is the premise by which such a node can now be inactive. Following this, all stakes are then withdrawn from the SKALE system.
Note that the risk of a node bounty being withheld. This is appropriate if a node exits the network without proper authorization of its exit. In this case, this node will be shelved or labeled as a dead node by SLA virtualized subnodes; hence, the non-remittal of due bounty.
· Bounties
This is most likely the most anticipated of utilizing the SKALE network. Everybody loves payouts. Now, for bounty payouts, SKALE tokens accrued during a specified time are distributed evenly among all participating nodes.
Claimed tokens before the epoch beginning is on the grounds of metrics average submitted by at most 16 peer nodes out of the overall 24 peer nodes.
To prevent sabotage by peer nodes, metrics at the top four and bottom four are dropped. In the SKALE network, the N.O.D.E Foundation will handle minor issues such as an unremitted token. This usually occurs as a result of low latency or uptime.
SKALE TOKENS
This is a hybrid use token, created to exemplify authorization to operate on the network whether as a validator, access shares, or stake as a delegator.
Let’s see how these three things play out on the SKALE network. Validators secure rights to run nodes after SKALE has been staked into the network.
After which fees and tokens are earned using inflation. Gaining a share of network resources is done by operating as a developer, sending and renting an Elastic Sidechain for a particular duration.
Lastly, delegators simply earn prime rewards by delegating tokens to validators.
When it comes to tokens, there is a clear distinction between the modus operandi for validators and users. Where validators will secure authorization to earn fees and tokens by staking SKALE, users pay SKALE to rent resources such as bandwidth, computation, and storage.
The Skale token with ticker SKL is currently trading on Uniswap, Binance, CRYPTO.COM, Huobi.
What can I do with Skale Token?
SKL is the primary currency for performing transactions on the Skale network and participating in governance:
Participating in Staking on the Network: People holding Skale tokens often called delegators can stake their tokens to validators who run nodes on the Skale network and receive rewards.
Subscribe to the SKL Chain: Developers building on the SKALE network pay a subscription fee in SKL tokens to access the elastic blockchains (S-chains)
Delegators and Validators Earn rewards
Participate in Governance and voting
SKALE EXTENSIONS
SKALE extensions are another distinctive component of this network, The SKALE network is designed to accommodate extensions for supreme performance, utility, and functionality.
Improved File Storage is one such extension and it is integrated inside every node. Another example of SKALE extensions is a mechanism that submits and carries out messages between Elastic Sidechains. Let’s talk more about communication and storage extensions.
· Chain-to-chain communication
Inter-chain communication on the SKALE network is made available through the provision of group signatures for Elastic Sidechains; therefore, allowing the authentication of a block’s introduction to another Elastic Sidechain.
Without these signatures, no block can be verified and committed to a chain. Another importance of this procedure is that it facilitates the transfer of crypto-assets back and forth on the Elastic Sidechain, and also allows the smooth implementation of smart contracts.
Here is the background mechanism behind this protocol. Every Elastic Sidechain possesses a large number of smart contracts situated on the chain.
This is the same as well for the Ethereum mainnet and one agent. Virtualized subnodes where the smart contracts are run have to execute chain to chain communication.
We have not mentioned this in the previous module, but Elastic Sidechains are designed to have an inbox and outbox feature. When any message is to be delivered in another chain, it is secured in the outbox until it is picked by an agent whose task is to send the message to the chain inbox of the designated recipient.
Agents are chosen at random and any message delivered by them is done so lock, stock, and barrel. That is, including any metadata necessary for approval of the transaction by the chain.
Is this validation really important? Yes, it is. Validating the transaction is more or less, proof that this transaction is part of the sending chain’s blockchain. With this proof, the transaction is now ready for delivery using what is called an on-chain messaging proxy.
There can be one exemption, however. When a value transfer from a parent blockchain like the Ethereum mainnet takes place, vouchers are handed out against this pooled value on each Sidechain using a DepositBox as a sort tow-way peg. Following the issue out of vouchers, a free exchange takes place between participants.
As a rule, value exchanged between Elastic Sidechains results in the value being eliminated on the sending chain and created on the recipient chain. This protocol ensures that the transaction is free of double-spend attacks.
· SKALE GOVERNANCE
You won’t be out of line to wonder why we have something such as governance in a leaderless network. Both characteristics of the SKALE network have their importance and functionality on the network. You could return briefly to the module above to refresh your memory on the distinction between the leadership on the SKALE network and governance.
The latter enables stakeholders in the N.O.D.E Foundation to reach a consensus on vital issues such as the future of the network, quality of output, security, and progress.
It’s quite straightforward; a distributed governance with central stakeholders providing adequate representation is an essential contribution to the overall growth and success of the SKALE network.
This is the core reason for the establishment of the N.O.D.E Foundation by SKALE Labs. From SKALE Labs, funds, power, IP, assets, and every other collectible of value is channeled to the Foundation after which the N.O.D.E Foundation delegates control to a decentralized power structure in the network after its launch.
The Foundation council will be endowed with the power to check divergence and restore balance on the network and will work hand-in-hand with elected Network Representatives to back and empower on-chain voting for more effective performance. Also, supervision of economic strictures will be vested in on-chain voting.
Where governance is concerned, the running of distributed and collective control will be executed through on-chain voting by Network Reps and the N.O.D.E Foundation Council.
If you are interested in transacting on the SKALE network, you should know that SKALE governance is shaped after the Delegated Stake Model.
This means that any stakeholder has the right to transact, operate, and participate in governance without going through an indirect channel. Participating is done by voting with a stake or participating indirectly through delegation of voting power to fellow stakeholders.
CONCLUSION
SKALE Labs is one of the top developers of quality blockchain technology which has decentralization and scalability as the core foundation of the company’s innovation.
On October 4, 2018, the company announced that its generated funding of over $9.65 million, of which its Simple Agreement For Future Tokens made up $8.86 million. The company also generated $785,000 seed SAFT to further its launch and other agendas.
Without a doubt, the SKALE network is easily one of the most potent innovations the tech industry has ever seen. This powerful network enables smart contracts to function effectively in a Layer 2 environment using enhanced decentralized applications built on smart contract platforms.
The company aims to help developers utilize its innovation to scale dApps across tons of transactions in a split second and at economic costs; a small fraction of the standard cost today.
This content has successfully expatiated on the technical functionalities of Ethereum and SKALE and using this powerful combination, SKALE Labs will be guaranteeing security, scalability, and decentralization for dApp developers. As a matter of fact, this is the major focus of the SKALE network:
“Helping Ethereum dApp developers scale applications is the center of” what we do. We are sharply focused on making Layer 2 easy, fast, secure, and cost-effective for anyone who wants to run smart contracts on Ethereum
-Jack O’Holleran, CEO of SKALE Labs.
There’s more to this brilliant brand. By creating a survey, the network made it feasible for parties or individuals eager to be among the first developers of dApps using the SKALE system to do so.
This bonus also applies to those interested in running validator nodes or mining SKALE. Despite being the new guy in the industry, SKALE Labs was able to conduct its latest round led by Multicoin Capital. The network has also garnered other investors such as:
- FLOODGATE Fund
- Signia Venture Partners
- Blockchange Ventures
- Canaan Venture Partners
- Hack. VC
- Galaxy Digital
- Neo Global Capital
- Aspect Ventures etc.
Overall, SKALE Labs is virtually the best chance Ethereum has at beating the tough rivalry in the industry from other equally superb smart contract platforms. Besides its excellent infrastructure, SKALE Labs consists of the most seasoned and resilient teams in the industry.
Since the company started announcing its presence and what it had to offer consumers, reviews for this network have been positive and the company has held to its promise of easy, safe, and quick scaling of Decentralized Applications for developers.
SKALE is the industry’s first execution of an Ethereum Virtual Machine that will run on a Plasma chain. With such outstanding waves already being made by the network, there’s no shadow of doubt on the impending success of SKALE in the coming future.
