[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)