ICON Blockchain Weekly Infrastructure Call #1 Recap
Hello ICON Blockchain! Insight Data Science here to recap our weekly infrastructure call. We scheduled the call for 6:00 AM UTC based on a poll from Telegram. We posted the video on our youtube channel, but if you are short on time, just read this post.
Everyone in the ICON Public Representative (P-Rep) community needs to come together to develop and share best practices for node operation so that we can build the best network possible. The network is only as strong as the weakest link, so we need to make sure every P-Rep operator is running high-quality infrastructure.
ICON MainNet launch was delayed yesterday by a month. This, in my opinion, was a very good decision on the part of the foundation as the reputational risk of rolling out an unstable network is far greater than the need to decentralize early. I think this is a call to action on the part of the P-Reps to do everything they can to help the devs. An upcoming article will break down and explain the responsibilities of P-Rep nodes and operators (follow us to stay tuned).
Test early and test often
Back to the call, I wanted to give the community a good foundation of knowledge to help people understand how we can build the better TestNets. To be clear, TestNet is supposed to be an exact replica of MainNet to test protocols in the conditions we anticipate them running on. We are in TestNet 3 right now and I anticipate that these TestNets will go on for a very long time.
Supporting at least 3 different types of network topologies
Software engineering often say, “test early and test often.” This is exactly what we need to do for the ICON devs. The easiest way to repeatedly and predictably deploy infrastructure is with code where Insight is contributing an automated deployment of multiple different configurations of P-Rep infrastructure. We discussed how we plan on supporting at least three different types of network topologies; simple, intermediate, and advanced to give node operators with varying levels of technical experience a chance to work with our infrastructure.
The first, most simple, node configuration will be mostly geared towards Sub P-Rep operators who want a simple and easy-to-manage configuration with as few features as possible. These node configurations will be the cheapest to run at the expense of a reduced security posture.
The second, intermediate node configuration is for Main P-Rep with less technical experience that, nonetheless, needs to run a highly secure network. Our P-Rep community comes from a diverse set of backgrounds, ranging from finance to application development, and they all need to have robust security protections in place to make sure they don’t pose a risk to the rest of the network if they get hacked.
The last node configuration is an advanced setup that is mostly built for teams that want to engage more directly in network tests and data analysis. This setup will include all the features needed to support our development of archival tools to enable post-attack forensics, and executing our own network tests like the ones ICON performs during the official TestNets. This will include a Kubernetes support cluster running multiple different types of dashboards for analyzing logs from Elasticsearch (thank you iBriz for committing to this contribution) and metrics from prometheus.
Codifying best practices
We will also employ a suite of tests including load, chaos, and penetration tests through a workflow orchestrator and spin up our own representative networks through our one-click deployments. With insights gained from these tests, we then codify those best practices into updates that will be fed down into the less advanced node configurations to be shared by the community.
To wrap up the call, I gave a quick demo of what the user experience will look like for our one-click deployments. We use a combination of a repo scaffolding tool called Cookiecutter, Terraform, and Terragrunt, the leading wrapper to Terraform. Users fill out the necessary configuration file to input sensitive data, such as secrets and key locations, run a shell script, and, lastly, grab popcorn and watch the whole infrastructure stand up.
That roughly summarizes the contents of the call. During future calls, I am hoping to sit back and answer more questions, inviting members of the community who are making actual contributions to infrastructure development to share their work, as well as on-boarding new teams onto Insight’s automated deployment. I hope to see more teams start to come through and engage the technical side of the network development. Until then, stay tuned as we put out more contributions to our Github and press about how we can bring the community together over our common infrastructure challenge.
Interested in transitioning to a career in Decentralized Consensus or DevOps Engineering? Learn more about the Insight Fellows program and start your application today.
