Cosmos Game of Stakes Learnings and Questions
As we near the end of the great Game of Stakes (GoS) experiment, we wanted to take stock of what we’ve learned and share the new questions we are wrestling with.
We’ll look at things from the perspective of three groups: the Cosmos Team, Validators, and Delegators.
Quick reminder: here is a post about our GoS strategy.
Learnings
- GoS is a big success as a software testing tool for the Cosmos Team.
We’ve seen spam transaction attacks, on-chain proposal voting for governance, and the great Bitfish cartel forking debate. GoS has successfully simulated several theorized behaviors that the Cosmos team was hoping to test. The more of these that we can “practice” before launching Mainnet, the better.
2. GoS is a mixed bag on usefulness of prepping Validators for Mainnet.
The adversarial nature of GoS means that Validators have needed to harden their infrastructure, avoid getting jailed, and improve debugging tools around network issues like missing pre-commits. This is all good stuff.
However, some emergent behaviors are anti-patterns for Mainnet. For example, on GoS most Validators are declining/ignoring transactions from other Validators and only proposing their own transactions. This has to do with a token fee/transaction spam problem, which will likely not be present on Mainnet. Validators have had to adapt/configure their environments for GoS-only scenarios which will have to be undone later.
3. The GoS scoreboard is not that useful for Delegators to evaluate Validators.
Due to the hyper-inflationary nature of GoS tokens, a Validator can accumulate stake at a faster rate than their peers if they write advanced scripts to watch the chain and auto-delegate. Sort of similar to high frequency trading techniques.
However, these scripts will be useless as soon as GoS ends. They simply allow a Validator to appear higher on the GoS scoreboard.
As a Delegator, selecting a Validator requires deeper investigation than the GoS score. Though technical competence and uptime are clearly important, additional criteria could also include:
- Stable legal jurisdiction and rule of law
- Known/public teams vs anonymous teams
- SLAs and Slashing Guarantees
- Key signing availability strategy
- Business process audits
- Treasury management policies
- and more!
In addition the the Learnings above, we’ve been discussing the Questions below with the larger community.
Questions
- How should the Cosmos Team, Validators, and Delegators handle off-chain communication?
If the chain halts on Mainnet and we need to fork to restart, what should that process look like? How best to verify identities of Cosmos Team, Validators, and Delegators? How to reach “consensus”?
Further complicating this is the impact of Exchanges. How will they decide which fork to follow? How will they exert influence in choosing the canonical chain?
2. How will transaction (tx) fees be priced on Mainnet?
Currently, a Validator scans the entire tx mempool before pre-committing. If the mempool is sufficiently large and enough Validators take too long to pre-commit, it could effectively halt the network.
Therefore, you could very roughly calculate the cost to halt the network as:
Number of Transactions for “Full” Mempool * Cost per Tx
Hypothetical example with fake numbers:
If a tx costs 0.01 ATOM, and 10,000 tx sent in 10 seconds halts the network, then it would cost 100 ATOM to halt the Cosmos Mainnet.
These are not real or researched numbers, just an example of the potential issue.
In other networks we’ve seen this solved with a minimum tx fee. You may also be able to try different configurations of block size and timeout. Or a technical solution to parallelize scanning the mempool.
The Cosmos Team is aware of this and working on different solutions/approaches. See the Github issue below:
https://github.com/tendermint/tendermint/issues/2972
3. How will Delegators assess slashing risks for Validators?
In our Cosmos Delegator and Validator Economics model, you can see that the biggest impact on yield for Delegators is slashing. The negatives of slashing far outweigh the missed earning opportunities around uptime and missed blocks.
In the article linked above, you can see there are many ways a Validator can get slashed. How will Validators “show instead of tell” that they are minimizing the slashing risk? Will SLAs or slashing guarantees be offered?
Overall, we think GoS has been a successful forcing function for the launch of the Cosmos Network. It has accelerated learning and helped Validators practice and work through different scenarios. In addition, it has surfaced/resurfaced important questions for the larger community to address.
We look forward to addressing these questions and more and helping launch Mainnet!
