Validator’s Note 3 — How We Made the RAND Consumer Chain
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.
Cosmos’ latest Incentivized Testnet program, Game of Chains, is now coming to an end. Designed to enhance understanding of Cosmos’ Interchain Security (ICS) feature, Game of Chains set out to test ICS in 3 distinct phases, thereby exploring and evaluating new risks that could accompany its launch scheduled for next year.
In Phase 1, we ran the provider chain and two consumer chains: Apollo and Sputnik. In Phase 2, we tested three consumer chains: Hero, Neutron, and Gopher. And in the third and final phase, we created our own custom consumer chain.
As of now, Phase 1 and Phase 2 have been successfully completed; Phase 3 is still in progress. In this article, we’ll examine how our validator team created a custom chain for the final phase of GoC!
First Attempt — Call it LOVE
To start and stop a new custom chain, you must first create a governance proposal and get votes from validators on the provider chain. Shortly after the start of Phase 3, the STRANGE consumer chain (created by the Strange Love Team) successfully passed the governance required for activation. This was actually a fork of the Hero chain provided by the Strange Love Team as a sample consumer chain in Phase 2. We used this same sample to make our own consumer chain called LOVE.
However, this prompted an argument between validators– one party believed that forking and running the exact same chain with no functional difference was meaningless, and the other that there was still value in stress testing and starting/ stopping the same consumer chain. Long story short, we failed to pass our first proposal.
Second Attempt — Running a Relayer
For our second attempt, we included setup guides and tools to help other teams run a relayer (one of the Phase 3 tasks) for our LOVE chain. Our reasoning was that more consumer chains were needed in order to win points for the relayer task.
We failed to pass this second proposal as well, but in the meantime, other proposals were passed and yielded the Liquidity consumer chain of the P2P team — which added a Liquidity module to create AMMs — and the Crescent consumer chain, built on the existing Crescent chain. So we started planning a custom chain that would include new functions.
Third Attempt — Meet RAND
After several discussions, we decided to create a RAND consumer chain with APIs that can generate random values, which can then be used across multiple chains. You can use these random values for various dApp games, tests, etc. And yet, in blockchain environments that do not trust each other, it’s actually quite difficult to verify that the seeds used to create these random values were not predictable or manipulated. Plus, to produce the same random value in a multi-chain environment, you must find a seed that guarantees this same value across all chains.
So the RAND chain used the validator set as seeds in order to create reliable random values. Users could obtain the random value by querying through the API, and the validator set at the time of querying was used as a seed. Why?
The provider chain validator set is subject to change based on user staking. In a decentralized blockchain environment, the behavior and outcome of staking (who stakes, how much and when) is very unpredictable and hard to manipulate. For this reason, we thought it appropriate to use the validator set as a seed. In addition, because ICS uses the same validator set for the provider chain and all consumer chains, it’s indeed possible to produce the same random value for all providers and consumer chains.
And thus, the random value generated by the RAND chain can be useful for various dApps. For example, if all consumer chains offer the same game, the results will be unanimous across chains and users can be rewarded on each chain in the native token.
And…success!
The proposal to create the RAND chain was successfully passed, but that was just the beginning. In addition to providing chain binaries for other validators to run nodes, we also needed IBC relayers to connect the provider and consumer chain, and a faucet for IBC relayers to use. A RAND faucet was quickly provided by All That Node, DSRV’s multi-chain node platform that offers RPC nodes and faucet services for multiple chains.
After all this, our RAND chain was successfully up and running via ICS from around 1:00 PM UTC on 12/6, with the random value generation also working smoothly. The chain ran for about two days and stopped at 7:00 AM UTC on 12/8 after the stop proposal was passed.
In Conclusion
So there you go– we’ve walked you through our overall process of creating a consumer chain! While there were initially some difficulties in getting our proposals passed, we finally succeeded thanks to everyone’s hard work and the wonderful help from the All That Node team.
Ultimately, we created a use case using validator sets that can be shared equally across provider and all consumer chains. So in addition to the benefits of shared security, we also caught a glimpse of how ICS’ specific features create real potential for new and diverse ideas. After its launch next year, we hope to see an ecosystem enriched with currently unexplored use cases.
Stay tuned for our upcoming interview with three DSRV validator team members on their experience and takeaways from Game of Chains!
Special thanks to the All That Node team for the gorgeous faucet page 💜
Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)
Edited by
Domitille Colin, Brand Communications Manager (Twitter @domitille_marie)
