Versatility and flexibility with Apex: how Battleships paved the way for more varied competitions

What we learned about both Bittensor and incentive design from running a peer-to-peer competition on SN1

We released a game.

In December, Battleships v1 launched on Apex. Miners fought to sink each other’s virtual boats, with winners receiving SN1 alpha. It was a first for us - not only had we never released a game before, but it was also the first fully peer-to-peer competition we’d ever launched. This is a rarity in Bittensor, as the vast majority of competitions involve multiple miners tackling the same task. Generally, people fight to outperform each other on benchmarks, or complete the same type of work. Direct miner-vs-miner competitions are an uncharted territory.

While we presented Battleships v1 as a fun way of gaming on Bittensor during the holiday period, under the hood, our engineers and incentive designers were monitoring how exactly these types of competitions operate, and what miner-dynamics and behaviours arose. Here’s what we learned.

The Cabal Problem

Bittensor is an inherently adversarial space - when we began our experiments, we were curious to see what exploits the community would cover. In the initial Battleship competition design, we allowed miners to choose their own boards, meaning you could place your ships anywhere you wanted. However, after debating internally, we noticed that gave rise to cabal-style activity, where miners could form a cabal by submitting solutions that would allow them to decide to purposely win or lose the game. For example, a miner might have 100 hotkeys and the first play is always position A1 bcs they know their own boards will always place a ship in that spot so if they get a hit immediately, they can suppose that they are playing against one of their own miners. Then, they can choose a win or lose strategy to promote one of their hotkeys guaranteeing their promoted miner to win the most games.

To prevent this, we began automatically generating the boards for each player and making these hidden to the actual player so they can’t even see their own board. This eliminated the advantage of forming a cabal and made a more level playing field for all. This also gave us space to focus on the more contextual and structural elements of the competition, unimpeded by exploit-mechanics.

Head-to-head: Miner versus Miner

The biggest advancement that this competition unlocked is our ability to host miner-vs-miner competitions. This is a key win for SN1 as it cements our subnet as being highly versatile, meaning tasks can be designed with a range of differing rules and architectures. It marks a shift within Bittensor towards anti-rigid subnets - a charge we’re leading.

Consider Battleships as our testing ground, proving what our framework is capable of, and how much further we can take it, paving the way for more scientific and productive tasks in the future. The reason we tested this out with Battleships is because there’s information asymmetry, meaning the game is never fully solved. No two games are set to end in the same way, even if both players are extremely competent and learned in the field. This is as opposed to something like tic tac toe, where two optimised players will always end up in a draw. In other words, it’s a relatively simple game, but colourful enough in variety to foster solutions that need to be sufficiently complex.

Opening the door to new competitions

From Battleships v1 game-day onwards, we monitored both external miner behaviour to learn how they orient themselves in such an environment, along with our internal infrastructure, to see our capabilities.

It was a success on both fronts. Not only can Apex handle tens of thousands of participants in a single round, but we confirmed our architecture can support new avenues for different types of activity - for instance, we’re currently considering the possibility of team-based competitions, where a collection of miners are bunched together to compete against groups of a similar size. They can even serve differing roles, whilst still sharing from the same emissions.

We’re able to create competitions that control the communication between miners, and even set specific environments and tasks for miners which may differ from their peers.

All this to say, Battleships was far more than a game for us. It was a complex, intimate, and interactive form of R&D (with a sprinkle of fun for our community during the holidays). It’s our necessary step towards designing peer-to-peer and team-based competitions that can contribute towards real-world solutions, much like how our matrix compression variants help strengthen subnet 9, Iota.