Hello ICON Blockchain! Insight Data Science here to starting off a long series of medium articles describing our technical contributions to the community. In this first post we’ll be delving into why we deploy our P-Rep node (AKA validator) with code and why it is so important that all P-Rep candidates do the same. Insight is seeking to be the leader in the community for infrastructure management and automation and hope that other members of the community can adopt our best practices and incorporate it into their node deployment strategy.

Before we get into what we are doing lets talk about why. As many of you know, MainNet is launching in less than a month with TestNet operations expected to continue indefinitely. Dr. Ben Lee who is running the stress testing on TestNet recently said on telegram “we want P-Reps to set up exactly how they will set up in the main net on end of September so they can really test it.” Dr Lee couldn’t be more right as being a P-Rep node operator, we will be responsible maintaining not one, but at least two identical nodes. The nodes on TestNet will be battle tested with numerous different testing procedures to reveal weaknesses in the network. With data on how the network performs, node operators can make improvements on MainNet while giving the developers the logs they need to make improvements in the underlying protocols. This is common practice in the blockchain world as there is a very real threat of cyber atacks so lets talk a little bit about what other groups are doing. Every major blockchain is operating a TestNet for stress testing along side their MainNet. Stress testing is done by the community and users are encouraged to do their best to take down the network. At Cosmos for instance, a blockchain based on the Tendermint protocol similar to ICON, they ran a competition last year called Game of Stakes where users were incentivized take down the network that was operating under real world conditions. It was an enormous success as they were able to collect and analyze logs and metrics that gave the devs invaluable insights into how their protocols reacted under load. The only way to realistically run networks like Cosmos at scale is through automation where they have adopted a tool called terraform to orchestrate the deployment of their infrastructure. It is by far the most popular technology to immutably deploy nodes on the cloud.

All of Insight’s infrastructure is open source and is deployed with terraform through a one-click deployment. This means that when a new user wants to deploy a node, the process will be reduced to running no more than 3 commands to get the infrastructure running beyond the normal root account setup and keys, a 10 minute unavoidable process. It is incredibly important that as much of the infrastructure is automated as we need a predictable deployment each time. Each time we deploy a node, we don’t need to rely on error prone, often confusing, manual commands that are difficult to audit and document properly. When we need to make changes, instead of manually logging into nodes to keep them healthy, we simply need to make the changes in the original code and redeploy the node from scratch, thereby saving the headache of having to reproduce steps each time you deploy a node while also codifying best practices that can be shared around the community. With 22 P-Reps running, we are certain to face a common set of challenges and thus we will need to have a open standard that everyone can look to in order to get the best baseline configuration.

We are also developing multiple different node configurations based on the guidance set out in the ICON docs that we hope P-Rep operators will adopt different variations of in order to create a decentralized grid of security features. The easiest way to build different configurations of the network is if we make the individual components modular such that they can be assembled in different ways. To do this, we at Insight use the leading wrapper of terraform called terragrunt to connect the different terraform modules together. This way, we can share a common set of components that are shared between all the different node configurations and then layer different security and scaling features on top. This way we can make sure that our open standard can be adopted in as many different configurations as possible.

On top of the basic node deployment, we are also building supporting services and centralized logging. This is common among other professional validator node operators such as Chorus One and I encourage every P-Rep node operator to check out their infrastructure whitepaper to get a sense of the kind of security precautions others are maintaining. Running blockchain infrastructure is like running IT at a bank. You need to maintain the greatest security posture possible. Luckily for Insight, one of team members John Taylor, Insight’s dev ops program director, worked for JP Morgan’s IT department and will greatly help our abilities to lay out the proper security governance strategy for the network.

To wrap this post up, I just want to highlight our team’s greatest strength and that is our fellow program. Each year, over \~700 talented engineers and data scientists do a 7 week intensive fellowship where they complete projects to demonstrate their skills. We are sourcing project ideas from the community that will have the greatest impact on the network. In the near term, we are focused on infrastructure as we need to have it in place to progress into more advanced contributions in the space of double signing protection where Mitchel Krawiec, Insight’s decentralized consensus lead, has made major contributions for Monero and is looking to bring his work to ICON.

So that does it. Please get in touch with any project proposals or suggestions for the network. Insight is committed to the ICON community and hope our contributions will empower the network to scale into all the possible use cases for ICON’s Blockchain.