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.
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.
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.
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.
Pump.co | Backend + frontend engineers | In-person 4 days in San Francisco | $150-200k + equity + benefits
- We save companies money on their cloud spend (AWS and GCP), and are building additional services around security and cost visibility.
- We are profitable and growing extremely quickly ($1m to $10m ARR last year, 500+ customers) and are growing our team to match.
- We're looking for engineers who are passionate about building elegant, scalable products and systems. We are a small team (6 engineers, ~20 total); you will have ownership and will work closely with the business and customers.
Correct me if my understanding is wrong, but there are no crypto transactions involved with arbitrage in the common case. Arbitrage is concerned with the relative price of two assets, for example BTC/USD. There is no bitcoin transferred from exchange A to exchange B, simply the trade of USD to BTC on exchange A and BTC to USD on exchange B.
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.