This blog is the second blog in the series of publications about the Game of Zones from the Sentinel team, with this specific blog revealing Sentinel’s custom strategy that helped the team secure the highest number of points in Phase 2 of the Game of Zones competition
Phase 2 of the Game of Zones competition was arguably the most competitive phase of the competition with dozens of teams attempting to achieve the highest score possible by relaying packets with the highest throughput they could achieve over the current version of the Cosmos Inter-Blockchain Communication protocol(IBC).
New readers are encouraged to go through Sentinel’s first blog focusing on the GOZ, which provides detailed insight into the first phase of the competition as well as the magnitude of its importance. In addition, the first blog also touches upon the impact that the GOZ will have on the Cosmos IBC protocol and correspondingly the cryptocurrency industry as a whole.
Table of Contents
- Purpose of Phase 2 of the GOZ
- Importance of Transaction Throughput
- Scoring Methodology for Phase 2 of the GOZ
- Overview of Sentinel’s Propriety Relayer
- Observations on the Cosmos Hub Testnet during Phase 2
What was the purpose of Phase 2 of the Game of Zones?
Phase 2 of the Game of Zones is the second component of the adversarial competition and was focused on testing the stability of the Cosmos ‘Hub’ Testnet.
Phase 2 pushed the network to its limits by incentivizing participants to relay as many packets as possible between;
- The participant’s zone and the Cosmos Testnet Hub
- The Cosmos Testnet Hub and the participant’s zone
- The participant’s zone and the zones of other participants
The key focus in this phase was to simulate high throughput in an attempt to overwhelm the hub and collect valuable data and insights that could further accentuate the security and integrity of the Cosmos Interoperability protocol.
Readers interested to view the a creative visualization of the activity that occurred during Phase 2 of the GOZ can visit the ‘Map of Zones’ website at https://mapofzones.com/.
Why is transaction throughput important?
A consistent hindrance to the scalability of most blockchain protocols has always been the limitations faced with transaction throughput, or the numbers of transactions the chain can handle at any point of time. We have seen these limitations, often created due to the nature of how consensus is reached on the chain, pose real issues in the live environments.
One of the most popular examples of throughput limitations was the Cryptokitties incident in 2017 when the virility and surge in usage of the dAPP created congestion on the Ethereum network that of which at the time could only handle 14* transactions per second.
In the past few years, we have seen the proliferation of new and intuitive approaches to improving throughput both at the base layer (Tendermint, Ava, GRANDPA) as well as layer 2/sidechains (Matic, Connext, Optimistic and BLS Rollups)
The blockchain trilemma, coined by Vitalik Buterin a few years ago, states that there are various trade offs between optimizing a chain and between the facets of decentralization, scalability and security. With the utilization of layer 2 technologies however, we are able to solve scalability issues without sacrificing the security and decentralization at the base layer.
Some of the issues with having the one-chain approach is that all the applications built on it have to have their transactions all go through one chain, as opposed to the Cosmos Hub/Zone setup where respective applications can have their own sovereign chains or zones tailored to facilitate the characteristics of their transactions like micro-transactions or the utilization of NFTs.
This is a landmark time within the blockchain ecosystem as we finally move to a multi-blockchain world, where aggregate network throughput will be revolutionized with the introduction of the IBC protocol that allows for unique chains with their own distinct properties and attributes to communicate with each other. If we are to see major adoption from both institutions and consumers alike, throughput enabled by IBC will play an important role in facilitating the transition from centralized infrastructure to the new paradigm of the Web 3.0 vision.
How was Phase 2 scored?
The measure of success in Phase 2 of the GOZ was determined by the number of packets relayed between the participant’s zone and the Cosmos Testnet Hub, and also the number of packets relayed between the participant’s zone and the zones of other participants in the competition.
The number of ‘points’ earned from the relayed packets was variable based on the origin and destination of these packets with the dynamic scoring system as follows:
1 Point per packet relayed between a participant’s zone and the Hub
0.5 Point per packet relayed between the Hub and a participant’s zone
0.1 Point per packet relayed between the participant's zone and the zone of another participant
As of this point in time, the official score from the GOZ team has not yet been released however multiple teams attempted to calculate the score themselves and have arrived at very similar conclusions.
Sentinel’s self tally from a retrospective analysis of the generated data arrived at the conclusion that Sentinel scored roughly 4,850,000 points in the competition.
The tally from the p2p.org team, which put a lot of effort into creating transparent real-time scoreboards for Phase 1 and 2, showed a very similar score to the Sentinel team’s self-tally. The p2p scoreboard listed sentinel at 4,836,383 points while the Sentinel self-tally estimated 4,847,930.5 points, showing a very minor discrepancy of nearly 10,000 points.
What was Sentinel proprietary solution to gain the highest score?
Sentinel’s proprietary solution for Phase 2 of the GOZ which allowed for the team to achieve the highest number of points in the competition consisted of:
1.A modified relayer which allowed for the transfer of multiple packets within a single transaction at a very competitive throughput. The throughput (transactions/second) from the Sentinel custom relayer was the highest amongst all modified relayers in the competition.
The official relayer did not have the functionality to send multiple packets within a single transaction and only allowed for one data packet per transaction, so the Sentinel team modified the official relayer to support this functionality.
The Cosmos SDK allows for the functionality of inserting multiple messages in one transaction which get executed sequentially. As one packet is equal to one message, there is an ability to put multiple packets as messages in one transaction.
2 . The ability for a dynamic adjustment of the number of messages that can be put in one transaction based on a transaction body size limit (whereas other relayers had a fixed value of the number of messages).
3. Support for ‘multiple channel relay’, which is one of the most important modifications in the Sentinel GOZ relayer.
With the ‘single channel relay’ method a zone can only generate a maximum of one transaction with X number of packets per block. However, with the multiple channel relay method a zone can theoretically generate N*X packets per block (N is the number of channels). In practicality, the generation of packets in the multiple channel relay system is lower than the theoretical output due to various factors such as the number of validators, network latency etc.
When compared with the single channel relay method that was used by other zones in Phase 2 of the GOZ, the multiple channel relayer method that was deployed by the Sentinel team achieved a 2–3x increase in packets per block with 4 channels relaying in the ‘zone to zone’ and ‘hub to zone’ categories.
Conclusion
Phase 2 of the GOZ competition tested the current version of the IBC protocol to its limits and allowed for unique strategies to be deployed that allowed participants to showcase their ingenuity in the aspect of increasing packet throughput. The Sentinel team believes that there is a lot of potential for optimization and refinement of the official Cosmos relayer and is eager to contribute and provide insight in terms of improvements to the relayer and the Cosmos IBC.
The Sentinel team is one of the earliest ecosystem members to begin development on the Cosmos SDK and looks forward to transitioning to its mainnet on its own sovereign Cosmos-based chain this year.
___________________________________________
Follow the Sentinel Medium Blog today to stay tuned for more content on the Cosmos ‘Game of Zones’ competition, and the impact and significance it will have on the industry going forward
