July 14, 2021
SKALE Development Update 7.13.2021
Hello community! Here’s a post to let everyone know SKALE Network’s short term release schedule and where the Network stands in the development process.
As an open source protocol, all of the code is open source, which means all the development is done in the open. That also means if you go to GitHub, you can track all of our open issues and pull requests. While that is all easily accessible, this post and calendar link will make the launch operations more easily consumable. This way the entire community can see the details and timeline leading up to the next release on mainnet.
Infrastructure and Performance Improvements
The SKALE decentralized Mainnet successfully launched last October. Today the network has been running without interruption since the launch, with 48 validator orgs running 160 nodes. Recently, the first SKALE chains launched on SKALE Mainnet, and deployed a few dapps and development tools to do testing in a live production environment.
There were several key areas for improvement that were discovered during this testing. The first was the need for better load balancing in the network. In a few short weeks core devs facilitated the development of a load balancer that enables dapp developers to leverage all 16 endpoints of a chain in a very easy fashion. Additionally, a few methods of how to tweak network and SKALE Chain performance were implemented, which will improve stability for the nodes that are on mainnet.
While this was happening, several validators were updating their infrastructure to be more secure and flexible, which required bringing some nodes from the mainnet down then bringing them back up. This is all to say, the core team and open source contributors have been very busy coordinating with validators, testing, and pushing updates since the initial mainnet SKALE chains launched, all the while the Network has been operating without interruption.
IMA Improvements and Audit
In parallel to all of the work on SKALE chains, there has been extensive work on the Ethereum <> SKALE bridge known as IMA (Interchain Messaging Agent). Early portions of this bridge were released on testnet to dapp developers and some internal networks months ago. Since then, the team has done a lot of re-architecting to make it incredibly gas efficient, simplify the architecture and incorporate some key features. IMA underwent an initial audit back in January and post restructuring and re-architecting, it underwent the newest audit, to be released soon, which was completed last week.
IMA consists of several smart contracts that will be deployed both on Ethereum and on each SKALE chain that's created. In addition, IMA docker containers are deployed on the validator nodes that act as resources on each of the SKALE nodes. These contracts and containers were tested, optimized and redeployed, requiring a lot of coordination and management, not just on the SKALE side, but also the Validator side. With 48 different validators, each with different types of infrastructure and varying levels of experience, it was a massive effort. Thankfully the core team and validator communities have gained a lot of experience from earlier SKALE testnets and worked through the complexity and coordination to deploy changes and fixes to the mainnet.
Post Denali and with the first SKALE chains live, developers are ready to deploy to SKALE as it exists today. That said, there are a significant number of customers who are interested in using the IMA bridge to be able to transfer assets back and forth between SKALE and Ethereum. Satisfying that second demand is precisely why this next release is so important.
SKALE’s open source development team follows a release process involving code review, internal QA regression testing, push to testnet, and mainnet. This involves everything from consensus to the Ethereum client called SKALED, which runs on each node, to SKALE’s BLS threshold cryptography and pre-deployed contracts on each SKALE Chain. That’s all in one stack that dapp developers and their end-users will use. In addition, there is the supporting validator stack. This includes, the node software which is a set of docker containers, the CLI that supports the node software, and one or more SGX servers, which depends on the number of nodes.
All of these components from consensus, pre-deployed contracts to validator nodes have been tested, updated and improved quite a bit to work with IMA. In fact, the entire past week, QA has been regression testing both the SKALE Chain and node stacks. This week, we are moving from QA regression testing to pushing beta versions on to testnet in a two phase process. We do this to get more information faster on what's happening on the internals for each of the nodes, before involving the larger validator community.
First there will be a push to foundation run test nodes for one quick round of testing. If everything looks good, in terms of the machine operations, SKALED running and performing, loading of transactions and mining blocks and transferring messages through IMA, then we kick off the second phase of the testnet process. This is where the external validators who are participating in the testnet, update their testnet nodes to these testnet versions. Then another round of testing kicks off with external validator testnet. The team does performance testing, deploys several SKALE chains, and deploys SKALE chains with IMA. At that point, we basically load test the SKALE chain with many, many transactions from hundreds and hundreds of accounts running through the IMA bridge transferring tokens back and forth.
Once that’s done and the team agrees on the go ahead, we kick off releasing versions to the mainnet, which takes a few days. Don’t forget, we have 48 validator orgs operating over 150 nodes across the world and different validators use slightly different machines and slightly different instances or infrastructure. Then there’s troubleshooting and verifying that the validators have in fact, upgraded all their nodes while making sure all nodes are in compliance with the requirements for running on mainnet. This all takes a ton of coordination which typically happens over the course of a couple of days, during which the core team will deploy IMA contracts on mainnet. Once they're deployed on mainnet, we go through verification to make sure all those contracts are verified on etherscan and the deployed code works as intended.
After all the validator nodes are updated, the contracts are deployed on mainnet, everything has been checked and troubleshooted, that's when the first chains are deployed on mainnet with IMA. That has a QA process to ensure everything is correct, starting with the Distributed Key Generation (DKG) process on SKALE Manager and following up and observing node transactions on the nodes participating in the SKALE Chain formation. If there are any hiccups, core devs and contributors triage and do a QA pass on that issue. Once the SKALE chains are up, the IMA contracts are automatically deployed on those SKALE chains and there’ll be QA on pre-deployed contracts. Then a load balancer will be deployed for each of the SKALE chains. Then the first dapps go live.
What’s the schedule for IMA and deployment?
In order to give you a more accurate sense of where things are day by day, we’ve attached a simplified Gantt chart with tentative dates. It begins with QA regression testing, then it flows into testnet. In between phase one and phase two of testnet, there's a DappNet, which is an internal network for customers to test the versions that will be released on mainnet. This allows them to prepare for their production deployments on Main net. After that, assuming everything goes smoothly, it all goes live on mainnet. We begin the process that's marked in light blue color, that's the earliest we could expect to begin the process. Green is the latest that we'd expect that process to be complete. That gives us a probabilistic timeline and range of when we expect those activities to start and finish.
Click here for Google Sheet with the Development Timeline
Developing these networks is an incredibly difficult task, with a ton of coordination. Unlike your typical software development cycle, we're not just building one piece of software like Cryptokitties, we’re building a whole suite of products that create the foundational layer for Web3. There are complex interdependencies and every change, addition, bug fix, re-architecting has a ripple effect.
As an example, we've made some very significant tweaks and improvements in SGX wallet, which is one piece of software that allows many SKALE Chains’ consensus to sign blocks using BLS threshold cryptography. If you make a change to SGX wallet, that could affect consensus which could affect SKALED which could affect threshold cryptography, which could affect block signing which could also affect the IMA bridge, because IMA uses SGX and BLS threshold signatures to sign blocks back and forth. So we've changed SGX wallet, we've changed consensus, we've changed SKALED, we've changed BLS threshold cryptography, we've changed SKALE nodes, we've changed the API layer between SKALE nodes. As you can see, everything is interdependent. If we make a change to one of those pieces of the stack, it kicks off an entirely separate QA regression process where you have to test that entirety of the stack. Which is why we’ve been QA testing this for many, many weeks.
Because SKALE is open source, we have many stakeholders. Dapp developers, open source contributors, researchers, validators, delegators, token holders, even the Ethereum community is a stakeholder. They are all important to the growth and sustainability of the SKALE Network. There is an active hacker one program that has made a significant impact already. We’ve even had contributions from researchers and other community members with regards to our DKG protocol, SGX and other security best practices. A lot of this happens in the background, and some of this can be seen by looking at SKALE's GitHub repo. Core team and open source contributors are not just pushing out software, we’re also engaging with the community and ensuring we follow best practices with regards to every aspect of the network.
This is an incredibly important update and we're excited that validators are helping coordinate this with us from the early stages of testnet through to mainnet. The SKALE Ethereum bridge will allow dapp partners to start using SKALE chains in their applications. We know SKALE chains and the IMA bridge are compelling offerings for Ethereum developers since it offers so much flexibility, security and speed. Truly a significant improvement over other bridges that they might be currently using and a big step forward for bringing their dapps to the masses.