Hello frens, I hope you are doing alright =)
Today I figured it would be fun to share some of the complex problems and design decisions we have solved in the past few weeks.
OnChainGameplay
Our vision for Wassie Sports requires on-chain verifiable gameplay. There are a couple of reasons for this. I'll describe them in detail in future posts about ideology and big ideas. But, for now, you'll have to trust me. It's good.
However, this specific requirement creates 2 BEEG problems:
- Randomness should not be generated on-chain. It leads to non-determinism
- Gameplay variance makes gas predictions impossible
gib good rng pls
Blockchains are replicated DETERMINISTIC state machines. If two computers that share their initial state execute a given transaction MUST arrive at the exact same final state. Those same computers using the default RNG implementation will generate unique random numbers. If we use those numbers, we create diverging chain states. Consensus is broken. Randomness is therefore forbidden.
You might be thinking, "but OCD, Chainlink VRF exists and works!". True, that is an excellent off-chain solution that publishes verified proofs on-chain but is only available on some EVM chains (Ethereum, BSC, and Polygon). Plus, if / when the cosmos integration is finished, it would have a linear cost associated that might hurt our growth during a hypothetical crypto winter.
We need a solution that:
. generates random numbers on-chain
. doesn't break consensus
. for free
ENTER DKG
As described in this paper, Distributed Key Generation provides a solution that matches our criteria. A working implementation of this solution exists and has been open-sourced by the frens at Corestar. We used that code as a starting point for our solution. This is how the current implementation works:
. A network of N validator nodes exists
. In each block, every validator generates its own random number
. These numbers are "gossiped" around between validators
. The current proposer node combines all these random numbers
. The combined number is posted on-chain at the end of the current block
. Next block, the new proposer seeds a PRNG algo using the previously generated number
. Non-proposer validators check that the correct number is being used as a seed for the block
. If the proposer is using a fake seed, it can be slashed by the protocol
Sorry for all the technical lingo. In 1 sentence: every node in the network generates a random number; we multiply them and use it as the seed number for the next block rng.
Deterministic AND random ᕙ(⇀‸↼)ᕗ
Next week I'll explain how we tackled the problem of high variance in gas costs when calculating gameplay on-chain. (It involves using a well-known game design solution combined with a few unique features that cosmos provides)