ICON Blockchain Decentralization Delay
On September 18th, the Icon Foundation announced that the decentralization of on-chain governance has been delayed by a month. We should all be thankful that the ICON devs had the wisdom to make sure the network is rock solid before launch. I wanted to take a moment to provide some context around why this is a prudent move for the network’s wellbeing and reputation.
The ICON network, I assure everyone, is just fine
Before getting into the situation, I wanted to let everyone know Insight Data Science is hard at work building infrastructure as code that the whole community can share. Right now we are maintaining by far the largest codebase of it’s type spanning over 20 repositories with over 10k lines of code. Our large fellow program has committed 3 DevOps fellows to the project, building infrastructure that will later be employed by data engineering, data science, and decentralized consensus fellows to further the ICON ecosystem.
Implications
What I think this delay most represents is a call to action from all the P-Reps to start being more proactive in how we build the network. Many node operators have sat idly waiting for explicit instructions on how to run their nodes. Considering the rewards at stake and where they are going, we as P-Reps need to do our best to support the ICON devs.
Before getting into how we as P-Reps can help, it is important to recognize the challenges ICON devs face developing a decentralized network of this type at such a pace. One of the many things that sets ICON apart from other blockchains is its unique governance structure whereby consensus is reached when at least 15 P-Reps arrive at consensus to validate a block.~
If it isn’t tested, it’s broken
Testing a network whereby governance structures can be managed and fully decentralized is a major challenge. Developers need to run a suite of network load tests, aggregate those logs, and turn those learnings into new releases as fast as possible to make improvements to a network. This is a complex development lifecycle where P-Reps can be proactive in helping the network.
Dissecting the situation, what the ICON devs are doing is testing protocols. There is a saying in software engineering: “if it isn’t tested, it’s broken”. The ICON network I assure everyone is just fine. What is happening is that the devs aren’t passing all the tests under stress. Figuring out whether the network will handle stress is where P-Reps need to step up and be proactive in building a better network. There is a lot we can do.
Logs
First, the most obvious solution is collecting, analyzing, and shipping logs. In future TestNets, P-Rep node operators can spin up elasticsearch clusters, analyze logs with kibana, and ship pertinent insights to the ICON devs automatically. This is a pretty complex task for the average node operator so Insight is planning on distributing one-click deployments of the necessary infrastructure for the whole community to share.
Network Configurations
Second, P-Rep nodes can try to make improvements to the actual network topology. There are a couple teams making progress on the reverse proxy element, notably Block42 with Nginx and Rhizome with HAProxy. Adopting reverse proxies like these for DDoS protection is a huge step in the right direction, although much more testing will need to be done to find the optimal configuration to properly protect the network. At Insight, we’re building several configurations to extend the great work already done by other teams.
Enhanced TestNets
And third, P-Reps can be more proactive in how they help turn around new TestNets. All blockchains do test networks and there is quite a bit of material covering the kinds of tests that need to take place. The software development practices of running TestNets is well established, and the community needs to do try to work better with the ICON Foundation to build the tools they need to improve the network. There are a million little tools we can build to make the process easier like the bot PiconBello built to that reports a health check on the status of the node. At Insight, we’re building a testbench that will allow us to coordinate tests across the community. Our Insight Fellows have the coding power to build out these features, and we welcome input and involvement from the community.
Takeaways
P-Rep node operators need to stop waiting for explicit instructions from the Foundation and think about what is generally needed to build a strong network. Going forward, we should all start coming together more, perhaps over our weekly infrastructure call, to discuss ways in which we can help the Foundation.
The whole process of process of decentralization is a massive undertaking. As P-Rep candidates, let’s pull together to earn our anticipated rewards by doing our job of building the best network possible.
