Validator’s Note 4 — Looking Back at Game of Chains
Disclaimer: This article is for informational purposes only and should not be taken as financial advice. No information contained within this article is a recommendation to invest in any of the assets mentioned. All investors are advised to thoroughly conduct their own research before making any financial decisions.
And that’s a wrap! Cosmos’ latest Incentivized Testnet program — Game of Chains — has just successfully ended. Predecessors to this include Game of Stakes (testing BFT-based PoS), and Game of Zones (stress-testing IBC security). This year’s Game of Chains was held to enhance our understanding of Cosmos’ Interchain Security (ICS) feature, scheduled to launch next year, and to discover and evaluate new risks raised by the introduction of ICS.
ICS is essentially a feature that allows highly secure provider chains, such as Cosmos Hub, to share security with other blockchains (called consumer chains) via a shared validator set. Shared validators are in charge of producing blocks for the consumer chain. To this end, Game of Chains set out to test ICS in 3 phases.
In the first phase, we ran the provider chain and two consumer chains, Apollo and Sputnik. In the second phase, we tested three consumer chains Hero, Neutron, and Gopher. And in the third and final phase, we created our own custom consumer chain.
Game of Chains brought around 150 teams to the table, including our own validator team. Validators competed in a number of tasks, with points being regularly awarded as tasks were evaluated. The final deadline for submitting evidence of task completion was 12/12 UTC, with the final ranking announcement yet to be made by the operations team. The final ranking is subject to change, but for now we rank in 3rd place!
Today, we’re going to interview three members of DSRV’s validator team about their experiences and lessons learned from Game of Chains.
1. Please introduce yourselves and what role you played in the recent Game of Chains!
Heejin: Hi, my name is Heejin Lee and I’m a software engineer on DSRV’s validator team. I was in charge of analyzing and choosing which tasks to compete in, as well as the strategies to execute them.
Seungkon: I’m Seungkon Hwang, also a software engineer on the validator team. I handled both node setup and operation for all provider and consumer chains.
Jinhong: Hi, I’m Jinhong Choi, a software engineer on DSRV’s validator team. I was in charge of operating the relayer connecting provider and consumer chains.
2. What was the most memorable task for you?
Heejin: One of the tasks in Phase 3 was to make a custom consumer chain. To do this, we had to prepare our own chain binary and make proposals to start and stop the chain. Tossing around various ideas on how to go about building our own chain was a really memorable and honestly just fun experience. Lots of interesting ideas came up in the process, and we ultimately chose to go with a RAND chain that can extract random values for the Cosmos ecosystem.
Seungkon: I was in charge of general node operations rather than specific tasks, so I primarily focused on how to run multiple consumer chains in the most resource-efficient way possible. I distinctly remember the experience of simultaneously running 6 chains on one machine.
Jinhong: It was fun to learn more about the relayer role in ICS! As a multi-chain validator, our team has previously run relayers for several different chains. Using this experience, I made a setup guide for other validators who hadn’t run IBC relayers before, and created tools that made it easy to submit test evidence. Being able to contribute in this way was very rewarding.
3. Did you run into any difficulties?
Heejin: Since consumer chains require governance votes in order to be activated, we had to gain enough validator votes to start our custom chain. During Phase 3, validators can win points if the proposal to start their chain is passed. But in fact, other players had no real incentive (such as points) to vote for us, plus they had to set up new nodes. So it was hard to gather any votes from them without providing economic incentives.
In addition, the governance voting period lasted for only two days, which wasn’t enough time to gather the votes needed to start a chain. So we opted for a proposal to change the voting period, which was increased to three days.
Seungkon: In the last phase of GoC, the provider chain was stopped while the feature limiting the max slashing rate of validators was being tested. The Slasher consumer chain — created for this test — intentionally sent packets to slash all validators in one go. But as soon as the Slasher chain started sending slash packets, the provider chain stopped, so unfortunately GoC ended without this feature being tested.
4. After participating in Game of Chains, do you have any concerns about the introduction of ICS?
Heejin: We completed a task in which a validator on a consumer chain was intentionally jailed, which meant it was then jailed and slashed on the provider chain as well. We found that this blacklisted validator could no longer produce blocks for any other consumer or provider chain, since the consumer chains were all mirroring the provider chain validator set. So this single incident on one consumer chain had a catastrophic domino effect on the security of all consumer chains. This phenomenon worried me because that means a bug in one consumer chain can have widespread effects across the Cosmos Hub.
Jinhong: Since the consumer chain is dependent on the provider chain, an IBC relayer is essential for communication with the provider chain. However, from the relayer’s point of view, there’s no real incentive even if the number of packets delivered periodically between the provider and the consumer chain increases. A small number of relayers can also be relatively vulnerable attack points, as they exist outside of the security shared by the Cosmos Hub through ICS. For the consumer chain to operate reliably, I think a proper incentive model and/ or grants will be needed, and that will hopefully strengthen the relayer ecosystem.
5. How does ICS affect validators?
Seungkon: Validators on other Cosmos appchains can decide whether they want to run a chain or not. In the early stages of ICS however, the full validator set has to run the chain once the proposal is passed– even if they lack the resources. If they don’t, they are slashed and jailed. I was a little concerned that the burden on validators would increase rapidly as consumer chains are created. A feature allowing validators to choose whether or not to run the chain once the proposal is passed should be added sooner rather than later.
Heejin: I agree with Seungkon. Running multiple consumer chains, including spam chains, could be very burdensome, especially for smaller validator teams. And there is currently no limit on how many consumer chains can be started, or criteria regarding which consumer chain to pass. I think we need to discuss and establish a framework for this, and hopefully GoC is a good starting point.
6. Lastly, how was participating in Game of Chains?
Heejin: While DSRV isn’t currently an active validator on Cosmos, we do run a lot of appchains and IBC relayers across the Cosmos ecosystem. As an active member of the ecosystem, we really did our best to explore and test ICS, which we think will turn an important new page for Cosmos.
Jinhong: While we do have some concerns about the introduction of ICS, we’re still optimistic about the new features it’ll add to the Cosmos Hub. I’m looking forward to seeing how the consumer chain use cases and functions will expand in the future!
Special thanks to Heejin Lee (@heeheejin), Seungkon Hwang (@skonhwang), and Jinhong Choi (@_Gnong) for sharing their Game of Chains insights with us.
Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)
Edited by
Domitille Colin, Brand Communications Manager (Twitter @domitille_marie)
