I'm building a P2P distributed computing mesh that runs in the browser. It's a TS library that provides a few things:
- A WS + WebRTC mesh
- A request/response protocol incentivizing the closest or most efficient peers to respond to requests
- A WASM environment ensuring deterministic execution and supporting contract composition
- Collateralization around responses, ensuring invalid responses have amortized negative value
- A consensus and UTXO layer, focused on low-latency, low-finality micropayments (for request incentive and collateral), using WASM compute as the weight metric
The idea came out of me wondering a few years ago why a multiplayer game couldn't simply be run on the player's machines without a central server. It has grown since, but the focus has remained on low-latency and log(N) state consensus (unlike a blockchain).
It's wrapped up as a single fetch() method, mostly mirroring the browser's native fetch(). There's a lot more I could say; I love working on it and discovering elegant solutions to the problems that pop up. I'm hoping to release a prototype in a few weeks/months. If you're interested in trying it out, let me know (joel at scaffold.io); I'd love to have some other eyes on it.
> The idea came out of me wondering a few years ago why a multiplayer game couldn't simply be run on the player's machines without a central server.
That's how they used to work! Some used peer-to-peer networking, others had one of the players host. Some still let you do this but don't always have networking that "just works".
Yes! That's a great model that works well for trusted participants - I'm attempting to build something that doesn't assume trust in any participant; i.e. empowering a node to trust a computation result from an arbitrary peer.
Sounds like a cool project! Do you have any specific use cases in mind for types of games this would be beneficial for? IMO in most cases having one player be the host is good enough. Maybe competitive games where you want to ensure the host doesn't cheat?
Thank you! My initial impetus was a MMO open-world sandbox game where players could leave/join at will. I was also interested in networking being directly p2p, as opposed to having a server intermediary. The tricky part is maintaining distributed consensus on a shared global state under those conditions, but it's a useful primitive and generalizes to a lot of other applications other than games like forums, social networks, data feeds/pipelines, maybe even chat/messengers (just my hypotheses at this point). It fits well in cases where much of the state is public and shared, as opposed to private data that's more difficult to achieve consensus on its validity.
How do you plan on maintaining state in cases where nobody is playing? Would surely need some nodes kept around just in case no players are active?
There's a couple of ways to keep state around but they all come down to who pays the incentive to ensure a block remains available. In the same way as posting verification collateral, a node would accept a liveness incentive and post liveness collateral, then they'd be responsible for serving the data for a period of time or until new state is created.
Who incentivizes the data availability is more of an application-layer question; in this case it could be the game publisher itself or maybe a consortium of players. I've tried to build these options as much as possible into the contract layer as opposed to the scaffold protocol itself.