Author: Zaki Manian

Restarting Game of Zones: New Competition Schedule, Phase 1b Updates, and Hub Software for Launch

Posted on by Zaki Manian

Recently, the Game of Zones Team shared that we would be pausing the competition to achieve code and network stability for teams to reach their full potential while stress-testing IBC. Today, we would like to share several updates about the competition, including a revised timeline, revised challenge objectives, and the scoring for Phase 1b.

Competition Timeline

  • Phase 1b will begin Monday, May 18th at 7:00am UTC, and will end on Thursday, May 21st at 6:59am UTC.
  • Phase 2 will begin Monday, May 25th at 7:00am UTC, and will end on Friday, May 29th at 6:59am UTC. 
  • Phase 3 will begin on Monday, June 1st at 7:00am UTC, and will end on Friday, June 5th at 6:59am UTC. 

On Wednesday, June 10th at 7:00pm UTC, the GoZ Team will host Closing Ceremonies where we will recognize each phase challenge winner, and all of the outstanding contest challenge winners who have won prizes for their overall performance. 

New Challenge Objectives for Phase 1b

To recapture the original spirit of Phase 1a, the objectives for Phase 1b will be different than the initial challenge.  During Phase 1b, we will be limiting the number of tokens given to each team to improve the stability of the hub, removing restrictions on trust periods in the software, and disqualifying any team that pools their genesis allocated doubloons for additional gas.

For the all-new Phase 1b: 

  • Every team should append -1b to their chain ID. An official Team Roster that maps chain IDs and Relayer addresses to team names will be published on the GoZ Github repository on May 14th at 7pm UTC. 
  • Trust periods will be unrestricted on the software. 
  • Players will be restricted to 1.25 million doubloons.  
    • This amount should provide enough tokens for a minimum trust period of 10 minutes.  
  • Gas prices will be fixed at 0.0025doubloons/gas.
    • A client update should cost approximately 2500 doubloons.

Before the phase begins, the GoZ Team will provide detailed documentation that shows participants how to adjust the trust period in the Relayer, how to optimize gas, how to deal with errors and recovery, and how to ensure that a client is kept alive. 

The winning team for Phase 1b will have the smallest trust period on their client while maintaining the longest period of liveness. If Team A were to achieve a client trust period of 11 minutes, and Team B were to achieve a trust period of 15 minutes and both teams keep their clients alive for 72 hours, Team A would score higher. If no team is able to maintain a connection for the full 4320 minutes of Phase 1b, the winner will be decided by scoring the length of the longest lived connection over the trust period. 

In terms of judging, we will combine the data from Phase 1a and Phase 1b to declare a challenge winner. During this phase of the competition, we expect to provide an overview of the active clients published to the Game of Zones GitHub repo multiple times a day.

Software to Launch the Game of Zones Hub

The Game of Zones Team will begin the launch process for the hub on Thursday, May 14th at 6pm PST. In order to connect to the hub, you will need to be using the following versions of software: 

And for custom zone operators, please be sure to update to the following Cosmos SDK version:

The Chain ID for the hub will be gameofzoneshub-1b. For each phase of the competition, teams should be prepared to append the phase number to their chain ID before phase launch.

While the GoZ Team is taking several actions to improve stability for the competition, there continues to be a risk that the battle testing of the IBC implementation will uncover new bugs in the software. Any new bugs that surface may result in a hub chain halt or other breakdowns in the use of the IBC protocol. If new software issues impact the competition, we will wait on a new release from the Interchain Berlin team and then announce a restart of the phase. Additionally, there is a possibility that the outcomes of Phase 2 might influence how Phase 3 is structured. If adjustments to Phase 3 are required, teams can expect ongoing communication from us on the objectives and protocol interactions that would be exciting to see.

We can’t thank the Cosmos community enough for the patience and understanding that we have received since our initial announcement about changing up Game of Zones to improve stability and the overall participant experience in the competition. To ensure that you’re getting the most up-to-date information about the competition, follow us on Twitter and keep an eye on the official GoZ repo. 

Improving Network and Software Stability for a better Game of Zones

Posted on by Zaki Manian

Throughout Phase 1 of Game of Zones, we saw many teams demonstrate extraordinary skill by finding clever strategies for working around network and software instability. These skills have been resilient against aborted upgrades, potential transaction spam attacks and the other adversities of running decentralized systems. Unfortunately, our best laid plans for Phase 1 did not come to fruition, and several technical issues made it difficult to achieve the necessary network stability that the competition requires. In light of this, and considering the feedback we have received from the community, Phase 2 launch will be postponed to address these issues. On Wednesday, the Game of Zones Team will publish a new timeline for the remaining phases of the competition and the stable versions of software for the remainder of the competition. 

Improving Network Stability 

One of our most important priorities moving forward in the competition is providing stability to the network and the software that it runs on. To that end, we will not be releasing new versions of software and standing up a new Hub during the remaining weeks of the competition. All upcoming phases of Game of Zones will run on the same version of software, and moving forward, we will not need to change this policy unless bug fixes are required.

Launching a Stable GoZ Hub

To give all participants the opportunity to compete in a stable hub environment, we will be relaunching Phase 1 of the competition in the coming days. In terms of scoring, we will use the data from the original Phase 1 and the data from Phase 1b to ensure that all teams eligible for the GoZ Liveness Reward receive it, and that no team’s contributions are overlooked or forgotten. 

We will rerun Phase 1b of the challenge on a more reliable network. To ensure network stability during this phase, we will be limiting the amount of tokens allocated to each team. This adjustment will alleviate some of the load on the network by reducing the risk of network saturation due to high transaction volume.

During Phase 2 and Phase 3 of the competition, we expect that the network will be at capacity. It is highly likely that the network conditions that surfaced in the last week will return once teams have a large number of tokens, and participants should be prepared to handle and respond to this class of issues as they arise.

We would like to thank everyone who has participated in Phase 1 of Game of Zones for their time, effort, and dedication to the competition, it has gone a long way toward ensuring a stable IBC. Additionally, we want to thank the Interchain Berlin team for their quick turn around on the issues we have encountered. We look forward to seeing a root cause analysis for technical issues that impacted the launch of Phase 2 in the near future. 

How to Stress the IBC Security Model to Win Game of Zones

Posted on by Zaki Manian


When we started thinking about Game of Zones in 2019, one of the most important goals we set was to use the challenge to prepare network operators for a whole new internet of blockchains. Once participants master liveness and throughput during Game of Zones, their final task will be to stress test the IBC Security Model. This exercise in adversarial thinking is designed to help teams identify and detect deception attacks in the wild, and to encourage the development of observability tooling to monitor for and alert on confusion attacks on the network.

The Double Spend Problem

Blockchains are notorious for attempting to implement solutions for the double spend problem. But the typical approach to solving this problem usually requires a world computer that runs about as fast as a calculator. Trying to scale solutions to the double spend problem has driven innovation and demand for zero knowledge proofs, random beacons, and complex sharding architectures. 

In designing IBC, we took a different approach that was inspired by the early works of the Agoric team and we focused on sovereignty. Core concept of sovereignty is that every user of a system needs to look at their own trust boundaries and preferences when choosing what chains, objects and tokens to interact with. With Game of Zones, we get to make that process of attack and defense real.

Token Distribution and ICS 20

At the launch of the GoZ Hub, we will be distributing tokens to each participating zone. Each of the zones will receive an equal number of tokens at the beginning of the competition, and those tokens will circulate in the IBC Network. While those tokens will not be a deciding factor in the first two phases of the competition, they are very important in assessing performance during the Phase 3. This is when we will look for confusion and deception attacks that trick users into accepting tokens that have been counterfeited and debased as if they were the real deal. The team with the most coins on the Hub may be the most likely to win. 

To compete in Game of Zones, your chain must support the ICS20 token transfer protocols during Phase 1 and Phase 2. If you want to bring a chain without ICS 20 support in the third phase, we suggest running a standard gaia in the first and second phases. We will be judging other application protocols during Phase 3, but they won’t be able to test the security model in the same way.

Confusion + Deception Attacks

One trend that we expect to emerge from participating teams during Phase 3 is fraudulent coin generation. An interesting implementation of this could be creating fractional exchange rates that enable zones to mint new coins out of nothing, and then send them on to other zones to convince other players to accept these coins. Though these tokens would never be redeemable, it would be difficult to judge whether they are valid coins or not.

Teams that are considering fraudulent coin strategies should pay special attention to the logic in the ics-20 implementation. Carefully manipulating the escrow and denom creation may also be a successful approach to trying to create underhanded state machines.


   if source {
       // clear the denomination from the prefix to send the coins to the escrow account
       coins := make(sdk.Coins, len(amount))
       for i, coin := range amount {
           if strings.HasPrefix(coin.Denom, prefix) {
               coins[i] = sdk.NewCoin(coin.Denom[len(prefix):], coin.Amount)
           } else {
               coins[i] = coin
           }
       }
 
       // escrow tokens if the destination chain is the same as the sender's
       escrowAddress := types.GetEscrowAddress(sourcePort, sourceChannel)
 
       // escrow source tokens. It fails if balance insufficient.
       if err := k.bankKeeper.SendCoins(
           ctx, sender, escrowAddress, coins,
       ); err != nil {
           return err
       }
 
   } else {
       // build the receiving denomination prefix if it's not present
       prefix = types.GetDenomPrefix(sourcePort, sourceChannel)
       for _, coin := range amount {
           if !strings.HasPrefix(coin.Denom, prefix) {
               return sdkerrors.Wrapf(types.ErrInvalidDenomForTransfer, "denom was: %s", coin.Denom)
           }
       }
 
       // transfer the coins to the module account and burn them
       if err := k.supplyKeeper.SendCoinsFromAccountToModule(
           ctx, sender, types.GetModuleAccountName(), amount,
       ); err != nil {
           return err
       }
 
       // burn vouchers from the sender's balance if the source is from another chain
       if err := k.supplyKeeper.BurnCoins(
           ctx, types.GetModuleAccountName(), amount,
       ); err != nil {
           // NOTE: should not happen as the module account was
           // retrieved on the step above and it has enough balance
           // to burn.
           return err
       }

Other attacks we expect to see during the competition include using a validator set to create difficult to detect light client forks and using state machines that conceal back doors and create tokens with arbitrary denominations to trick IBC users. Hopefully, we will see new ideas that we haven’t thought of before: to win this round of Game of Zones, teams will need to show their work by publishing technical details and write ups of their attacks once they’ve been carried out.

Has your team started working on your strategy for Phase 3? If not, take a closer look at ICS 20 and spend an afternoon with your team thinking about you would defend against deception attacks.