Game of Zones wrap up | Team Blockscape

blockscapeLab
3 min readJun 5, 2020

Hello cosmos community, in this article I will summarize what we have achieved in the Game of Zones game and what insights we could gather.

Phase 1

As already known, the first phase was divided into two sub-phases Phase 1A and Phase 1B.

For the first phase we have extended the relayer with a keepalive command.

https://github.com/BlockscapeLab/relayer/blob/keepalive/cmd/keepalive.go

This command allowed us to automatically update the client for the connection. In addition, we implemented a monitoring function that delivers the current status to a Prometheus backend.

The Grafana user interface, which is connected to Prometheus, prepares the data and displays it in a diagram. In Grafana we have set alarm clocks that notify a webhook if our update client process causes an error.

Grafana Monitoring

This architecture enabled us to maintain the 62h 32m 0s connection which qualified us for the LIVENESS REWARD. We have reached rank 34 of 103 teams.

In phase 1b we set our trusting period at the beginning to 10 minutes, which unfortunately led us to the decision to break off the connection and change our strategy two hours after the start to get more points. This change included a trusting period of 3 minutes and an update interval of 1 minute and 30 seconds. We successfully maintained this connection until the end of phase 1b.

In addition, we have built a website that provides some important data about the competition.
The corresponding backend can be found here.

Here are two pictures.

Overview of Teams
Detail view of one Team

Phase 2

In phase 2 we ran a zone with a custom gaiad version. This version had a built in command to keep sending transfer packets with multiple messages. To relay these multi-message packets we used the relayer gun published by P2P.org.

https://github.com/BlockscapeLab/cosmos-sdk/blob/goz-throughput/x/ibc/20-transfer/client/cli/tx.go#L69

Unfortunately we had problems with the keys and could only run our setup successfully in test mode. This, along with the information that multiple messages per packet wouldn’t count, led us to the decision to set up two service files that transferred single message transactions between two chains. This enabled us to send about 63k transactions until the end of the second phase.

Due to the problems with our own gameofzones-hub node we used the official RPC endpoint. This configuration proved to be very useful during the spam attack, preventing us from losing our connection.

Phase 3

For the third phase we thought about hijacking an escrow account. We wanted to achieve this by creating a malicious chain. This chain was set up with a channel with the same id as the imitated chain. In addition we minted transfer tokens that had the same denomination as the transfer token on the imitated chain. Then we tried to trick the hub chain into believing we were the original chain and accepting our transfer packet aimed at an escrow that wasn’t ours. In the following example picture our idea is to be seen again clarified.

Idea: claim escrow token

Despite our best efforts we couldn’t make it work since we couldn’t duplicate the client ID on the hub side. We took the challenge, gave it our best shot and learned a lot.

In summary, we enjoyed the competition very much and we are looking forward to the further development of IBC. Thanks for reading.

--

--