Do you need a proof-of-work ledger, or just a central sequentially-consistent transactional ledger shared between all servers (without burning energy for rare SHA checksums)?
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.
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.
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.
If there is the potential of internal employees being malicious, then maybe trust isn't guaranteed.
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.
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.
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.
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)
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.
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.
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.
Basic bookkeeping concept: every once in a while (usually daily) you take a snapshot of the current state and mark that point in the ledger. Then you take the previous snapshot, re-run the day's transactions, and you should get the current snapshot. If you don't, something has gone wrong. This is called "reconciliation".
UXTO would’ve been a neat technology to have to experiment with at least.
Memory was at enough of a premium that even in the tagging system we made in the article it was just for the rarest items.
If you have a stack of gold containing 5 uuid and mix it with another stack of 3 uuid but only support 5 uuid per stack. Then calculate proportional weightings which 5 you store.
You could probably find a way to try and wash the money but I think it could be done with right heuristics to catch a good majority of use cases but maybe not all.