[TrapLord_Rhodo]

The article strictly points out the need for a shared concurrency models required in the functioning of a online game thats massively parrelled across both clients and various individual 'servers'.

Unique, hash based, 'stacked' items that are non-fungible with a decentralized shared state across clients.... yes, technically that's 'Just a database' but a highly complex one.

I get people hate the hype and 'uselessness' of crypto and even the term 'Blockchain' is loaded, but dismissing the technology out of hand is uncalled for. Especially when the author gave a very clear use case for a very real problem in shared state computing.

[veleek]

All of the server nodes are run by the same entity (the game developer). Blockchain is a good solution when the nodes are not necessarily trusted (thus the need to prove that you did the work). If all the nodes are trusted you can accomplish the whole decentralized thing much more easily.

As a super simplified example, if you want your distributed database to generate unique identifiers, partition the id space so each node is guaranteed not to overlap. You trust to nodes so you don’t need blockchain.

[cottenio]

Yeah, my point was that an internal PoW ledger (not decentralized but still technically a blockchain) would’ve been useful because: A) stack tracking per stackable type is trivial with UXTO, and B) adding a few seconds of PoW makes the resulting chain so hard to forge for crime-of-opportunity style attacks (preventing internal employees from making untraceable gold) that it could’ve prevented a few firings/calls to the authorities during my time. Oh, and C) it might’ve resolved the duping issues with cross-server character transfer exploits (a different beast than areaservs), and D) heh, maybe conned an engineer into making a block explorer dashboard so we could see the global state of currency/stackable amounts

Like you said: most of these except B) could’ve been done with traditional techniques and relational databases, but I maintain A) might’ve been easier than the message passing code required to synchronize and emulate it.

[kelnos]

You still don't need PoW here, though. All the servers are presumably trusted. You perhaps have a trust issue with your employees, but that is what access controls (limit the number of people who can create items) and audit logs (after an item is created, you know exactly who did it and when) are for.

And yes sometimes an employee that you've trusted with item creation access will turn out to be a bad actor, but you have the audit log to prove that, and you fire them. That's... just life. Hopefully the fact that there are audit trails dissuades most of the borderline-sketchy employees that it's not worth the risk.

> adding a few seconds of PoW makes the resulting chain so hard to forge for crime-of-opportunity style attacks (preventing internal employees from making untraceable gold

I just don't get why this needs a blockchain. Internal access controls! Don't just let random employees make arbitrary, untraceable changes to game state! Of course you're going to have problems if you allow this, blockchain or no.

Obviously you are much more knowledgeable about the issues around transferring state across server boundaries. But I still have not seen anything (in general) that suggests that inherently centralized systems (like an MMO run by a single corporation) meaningfully benefit from PoW systems. PoW is just there to ensure that people can't forge things. But when your ledger is centralized, if you implement the proper access controls and audit trails -- which you should be doing no matter what -- then PoW/blockchain is just not necessary or useful.

[agentultra]

You don’t need the proof part if all the server nodes are trusted. Just the hashes is enough. I think that’s the part the author was pointing out in the article and we’re reading a bit too far into it.

[ohmahjong]

cottenio is the author in this case.

If there is the potential of internal employees being malicious, then maybe trust isn't guaranteed.

[meheleventyone]

The question then is the additional cost worth it. Employee tampering is rare and already dealt with in other ways. Also putting things on chain doesn’t prevent it because there are still employees making the game and thus can still add back doors that will be legit transactions.

[agentultra]

I can’t believe I missed that.

I still don’t think the proof part is necessary even with the potential for internal employee tampering. With sufficient system authorization and security auditing catching someone tampering would be enough than wasting all that compute resource to prevent it for such a rare case.

Cool story though. I really like UO back in the day.

[ohmahjong]

I 100% agree - I don't think that I would ever reach for a PoW blockchain to solve this problem, but it has certainly generated some interesting discussion

[kelnos]

I think employee trust is not something you solve with a blockchain. This is like that section of the "why your idea won't work" checklists, where you have "you are attempting to solve a social problem with technology, which does not work". Access controls and audit logs are the way to go. Employees who know that they can't behave badly without the system recording all their bad actions are much less likely to do bad things. And when they inevitably do bad things (which would still be the case in a blockchain system), you have the audit trail to prove it, and you fire them and/or involve law enforcement.

[xani_]

Okay? What makes you think this would stop them from just running some GPU in the corner and generating a bunch of expensive items to peddle ? They'd have all the access to make it look legit ?

[DelightOne]

Are there ready-to-use blockchain libraries to simply create such a blockchain or does everything have to be custom-written and tested manually -> requiring the developer be an expert?

[cottenio]

Apparently it was a valuable enough idea to Amazon that they spun it up as a service in AWS: QLDB.

[palata]

Note: valuable as in "people are willing to pay for it", not as "it is solving a use-case better than alternatives"

[cottenio]

Oh, and a good aside: thanks to player exploits the nodes themselves weren’t necessarily trustworthy (such as duping exploits across shards, not just areaservs).

Like I said, not saying we “needed blockchain”, but when AWS released QLDB I was like “ohhhh, that would’ve been useful” since, you know, forging log files is a thing.

[josephg]

> if you want your distributed database to generate unique identifiers, partition the id space so each node is guaranteed not to overlap. You trust to nodes so you don’t need blockchain.

You can also generate unique IDs by giving each server/node a unique hash and then use (node_id,1), (node_id,2), ... etc. Its more complex this way but this approach compresses way better if you have a lot of IDs. (Thanks Martin Kleppmann for this trick)

[xani_]

>The article strictly points out the need for a shared concurrency models required in the functioning of a online game thats massively parrelled across both clients and various individual 'servers'.

Uh, no. The servers are essentially independent. Each server have maybe few thousand clients at once.

The data most clients change is independent of eachother. Hell *you don't need to store most of them*.

All you need to store is basically some world state data (nobody GAF that non-boss monster just respawns after server restart ,no need to store that data in the database) and player possesion

>Unique, hash based, 'stacked' items that are non-fungible with a decentralized shared state across clients.... yes, technically that's 'Just a database' but a highly complex one.

Uh, no.

<server-id>:<item-id>:<account-id> + a server signature to signify it was actually generated by that server.

Any change of ownership within a server is server changing account ID item belongs to + signing the transaction and resulting record. Alert on fraud if someone has same <server-id>:<item-id> pair.

You reduce the problem space to "do I trust the other server" which is much easier to solve. And even if you say allow malicious server with tons of accounts having cheated in items transfer to yours.... each item has that server's ID so you can trivially fix it by removing them from yours.

All that would need to be tracked above that are account transfers.

[twodave]

If I understand correctly this can be solved with much less complexity via something like snowflake to guarantee ordering consistency. There are of course dozens of ways to achieve consistency across nodes, and a blockchain is one such solution. The reality is if blockchain were an optimal distributed store it would be used for that purpose in more places. Instead what we have is a bunch of buzzword shoehorning (which frankly today sounds a bit overplayed/stale).

[zeroclip]

Can you describe how a snowflake ID would help? Imagine the data contains two Rare Items, when it should only contain one instance. They both have different snowflake IDs. How do you determine which is authentic? The timestamp on the duplicated item could have been spoofed.

I think the real solution to this problem is just to trust a centralized actor and single large database that is shared across all servers. Not what the author wants to hear, but most games don't need the level of decentralization of PoW or PoS for all of their game assets. But a fully decentralized MMO would be cool in theory.

[palata]

Yep. I think the one place where blockchain shines is cryptocurrencies. If it's not a cryptocurrency, then there is a better alternative.

[dbttdft]

> Especially when the author gave a very clear use case for a very real problem in shared state computing.

He did not. One server can just keep track of a player's items then pass that state on when he moves to the next adjacent server. I don't even see the issue here except the codebase is described as something very messy with weird OO/hooking style non-abstractions that just cause bugs.