GOZ (barely)technical report (Phases 1 & 2)
Cosmostation participated in the Cosmos Atom Game of Zones as Interstation Zone. Here’s our technical report.
The thank you part
My gratitude goes towards the GoZ team (Zaki Manian, Jack Zampolin, Jessy Irwin), the Tendermint team, and all IBC contributors who worked day and night to bring IBC to the level of maturity it has reached today. Participating in the Game of Zones was a valuable experience, an opportunity to test IBC to its limits head-on, together with many other resourceful and experienced participants. I am extremely proud of the achievements we have made as a community, and believe that this momentum has been and will continue to be what moves our community forward.
Phase 1a - the unintentional warmup phase
A personal mayhem from sheer unpreparedness due to premature assumptions that things wouldn’t break or fall apart(which should have obviously been assumed and prepared for), it did get the job done which was — and I softly quote either Zaki or Jack from failing memory — ‘getting used to the relayer software’. By the time I had to pronounce the death of about the 5th client(rly l i $SRC_CHAIN_ID -f) due to seemingly spontaneous tx failures and a bleeding-edge client update cycle based on my inability to learn/adapt from past mistakes — used to the relayer software I had become.
Everyone at Cosmostation was busy trying to apprehend the semantics of the weekly challenges and attempting new approaches which could lead to a higher score. Through participating and striving to stay awake in order to keep in touch with the latest developments in the ‘ibc-testnet-alpha’ telegram room, we were able to develop a somewhat firm grasp as to how IBC was developed, figure out what the relayer software was for, clarify how chains were ‘inter-connected’, realize which values required more attention for a live and healthy connection and last and not least — ponder deeply into how we could integrate by modularizing the functionality that IBC has to offer at code level, into our Cosmostation products with UX at our innermost interests.
Phase 1b - liveliness phase
The gist of phase 1b was very neatly summed up by Persistence in this medium post, including the ‘spam reflection attack’ so neither subjects will be pursued further.
Based on our newfound knowledge and know-hows conjured up whilst trudging through phase 1a, coupled with sleepless nights rummaging through the official discord and telegram communication channels, we were able to whip up a tangible strategy and thus participate in a more meaningful manner. Several different scripts with multiple gradually-refined derivations were brought into the world including an industrial-grade monitoring system built from scratch. Through this process we discovered a need for proper documentation for cooperation amongst developers and guidelines for said documents which we defined and polished throughout the phase — embedding our roots evermore firmly into becoming a more efficient team.
Our efforts were not in vain, as two of our team members landed 2nd and 4th place — a harvest that was due to be.
Many distinguished teams contributed to the community with outstanding visualizers and dashboards resulting in more meaningful/technical exchanges among participants compared to phase 1a. This shed light upon the sheer importance and influential power of an exceptionally active, top notch community.
Phase 2 - A late but perhaps novel approach
1. Packets relayed to the hub would be worth 1 point
2. Packets relayed from the hub would be worth 0.5 points
3. Packets relayed among other chains would be worth 0.1 point
The scoring criteria
Rough and tumbling through previous phases resulted in hardened warriors with a deep understanding of the relayer software — though in hindsight maybe that wasn’t us *insert face-palm gif*. Our strategy was simple and straight-forward — connect as many chains as possible and attempt to earn points in the first and second criteria listed above. However in less than 24 hours, dumbfounded by the high number of packets displayed in the top-rankers of the GOZ official dashboard, we came to the conclusion that our tactic was not viable for a high score if our momentum was kept the same whilst high-scoring participants kept a constant machine-gun spray of packets towards the hub and other zones. While searching through the relayer source code and trying to figure out how other zones were managing such a high output, we attempted to devise a new strategy that could close the tremendous gap that was materializing in an alarming rate.
In simple terms, our new strategy was to reduce block times to the absolute limit and connect to as many packet-exchanging custom chains as possible. Since packet congestion on the GOZ hub was beginning to show similarities with a jam-packed rush hour with packets barely reaching their target destination, the plan was deemed a viable idea and our chains began to appear high in the ranks as the connected chains increased.
A combination of the scripts written in previous phases, expertise in running nodes, experience with the Gaia software and vigorous testing with various different settings eventually payed off despite applying a viable strategy with less than 30 hours left of phase 2.
Takeaways
- Not a lot of expertise and understanding of IBC or how relayer works under the hood was required to score relatively high in phases 1b and 2.
- Reducing block time helped in cramming as many txs as possible.
- Better documentation explaining various commands of the relayer software pre phase-1a would have saved a lot of time for multiple participants.
