Round Robin SHA-256 RNG

Old idea with potential value.

I keep thinking about building on Hive and crypto in general and find myself wondering why we don't have any good PvP random number generators using SHA-256. According to my own experience and the Internets SHA-256 does indeed produce random output. Looking at other decentralized solutions I can see that people have thought about this a lot and even created some interesting modules, but they aren't used for gaming and are rather more oriented toward core developments on blockchain as a way to make the networking more trustworthy.

I have some code floating around here with this idea in mind and I'm seriously considering going back and completing the module so I have something to build off of. The idea being here that random numbers in computing are extremely difficult to achieve. At best everything is pseudo-random on a technical level. This is fine for most applications, but when there is a financial incentive to cheat because money is on the line it becomes much more complicated. We absolutely cannot trust centralized agents with our random numbers. THEY HAVE AND WILL CONTINUE TO CHEAT.

It's been very obvious to me over all these years that game developers on networks such as AVAX really have no idea what they are doing in terms of decentralization. Everyone is following the same centralized path. A centralized dev team creates the thing and then contorts it into something that incorporates a token that they premine. The community can't contribute to the codebase or create content or run infrastructure. Every project I look at is doing it wrong and they don't even realize it.

This is very frustrating because even games that are decades years old have allowed their community to create content in terms of custom map engines and API connectors and the ability to mod the ecosystem. It's also very frustrating because pretty much every crypto game is pay-to-win (while being called play-to-earn) and is inherently a Ponzi that gives advantage to bots and other forms of Sybil attack. Something has got to change, but at this point I'm rambling.

---

General Overview:

The idea here is that players in a game should all have the ability to manipulate RNG so they know for a fact that none of the other players can cheat them in this way. I've blogged a couple of different times how Bitcoin is creating an infinite set of random numbers on every block (average 10 minutes each) which is highly useful and grossly underutilized at this point. However for PvP games these RNG events need to happen on demand in real time so POW solutions are not acceptable. Below is how I believe such a module would work.

Phase 0: Create Password

Every roll of the dice, as it were, needs to be generated by a secret password that is only revealed at the appropriate time. In this case every player creates a secret password for every random event. This could be drawing a card from a deck, a number between x & y values, dice rolls, or literally any other random thing.

Now that I know a little bit more about crypto than I did when I first had this idea I realize that the perfect crypto solution to this problem is to create a 12-word seed that will allow players to produce and infinite amount of temporary passwords that can be used and thrown away with ease. This would make guessing the passwords people are going to use nearly impossible unless they are able to figure out the seed. As we all know seeds are pretty difficult to figure out when secured properly, and a module like this would be able to change the seed on a whim because they don't secure any assets.

Phase 1: Password Masking

All passwords need to be combined together before the random event can be determined. This is a problem because the last person to submit their password can look at everyone else's password to manipulate the outcome. To avoid this scenario all passwords have to be masked with an irreversible SHA-256 hash. This way players can lock in their password without anyone being able to read it. Once all passwords are locked in the passwords are revealed.

Phase 2: Reveal Password

Every player now submits their real password. These passwords need to hash to the exact value from the previous phase to ensure that the result can not be manipulated. It is technically possible for two SHA-256 hashes to have the same result, but on a practical level this is not an issue as the chance of this happening is just as unlikely as hacking a Bitcoin wallet.

Phase 3: Combine Data

Now that we have every password we can serialize them together using a specific format. This data structure could take many forms, including JavaScript JSONs that could be fed into local databases. Because every player has contributed a password to the structure every player can be reasonably sure that no other player was able to manipulate the outcome in their favor.

The result of this JSON structure would be yet again one final SHA-256 hash.

Phase 4: Derive RNG Set

Using the final hash gives us a reasonably secure set of random numbers in which all players have contributed to. This set of random numbers is infinite in nature, as the hash itself can be recursively rehashed over and over again to infinity if more numbers are needed. SHA-256 is a very efficient algorithm so this process would be quite fast.

Potential problems with this method:

Prototypes could be built on the Hive blockchain but they might not be fast enough depending on the application. Creating and masking the password requires a signature and blockspace. Revealing the password, combining the data, deriving the RNG requires another block. So in theory this would take at least 2 blocks but in practice it would take a bit more because the second block is in response to the first one. Lag times such as these would be unacceptable for instant gratification or fast paced action.

Any app that became popular would inevitably bloat the chain and fill up the blocks quite quickly. Pretty obvious an off-chain solution needs to be implemented for sustainability, but that comes with its own set of challenges.

Disconnections

What do you do if one player doesn't submit their password to a random event? Do you continue without them? What if there is money on the line? In something like online-poker there are "disconnect protections" but those are exploited by players to put themselves all-in without actually being all in. There's no simple fix to these issues.

Client/Server vs Peer-to-Peer

A Client/Server solution can be more reliable but players are also trusting the host to tell the truth. What if the host just decides that a player didn't submit an answer when they actually did? Resolving these edge-cases is a pain in the ass but would be worth it in the end. For example if a player was disconnected from an off-chain environment they could be disconnected using an on-chain operation. If that player responded to the on-chain operation it signals that someone is a bad actor and we need to figure out who. Either the player is stalling or the host is lying (or having connection issues).

P2P

Ideally a lot of layer 2 applications would be running on some kind of virtual LAN situation where all the players are talking to each other and there aren't any centralized points of vulnerability. Not sure how difficult these logistics would be to set up but this kind of tech has existed for decades.

Conclusion

It's a bit weird that we've been in crypto developing this long but dev teams constantly create centralized tech by design with the sole intention of profit. This is not what crypto rewards, and there are a lot of improvements to be made. Luckily healthy competition will continually push devs to undercut each other until we get to the bare bones of where we should have been all along. Patience is a virtue I suppose, but like most I grow weary of waiting.