6 ms·

> Not that I’m saying MMOs need blockchains; but it turns out Proof-of-Work ledger technology had a use case here! Do you need a proof-of-work ledger, or just

> Not that I’m saying MMOs need blockchains; but it turns out Proof-of-Work ledger technology had a use case here! 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)?

nrb 4y ago
Since only the server is authoring the entries, just a ledger.
- tiagobraw 4y ago
  also known as database
  - TrapLord_Rhodo 4y ago
    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 4y ago
      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 4y ago
        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.
        DelightOne 4y ago
        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 4y ago
        Apparently it was a valuable enough idea to Amazon that they spun it up as a service in AWS: QLDB.
        palata 4y ago
        Note: valuable as in "people are willing to pay for it", not as "it is solving a use-case better than alternatives"
        agentultra 4y ago
        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.
    - twodave 4y ago
      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).
      - palata 4y ago
        Yep. I think the one place where blockchain shines is cryptocurrencies. If it's not a cryptocurrency, then there is a better alternative.
      - zeroclip 4y ago
        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.
    - xani_ 4y ago
      >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.
    - dbttdft 4y ago
      > 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.
  - Animats 4y ago
    No, a ledger and a database are different. The ledger is a transaction log. The database holds the current state. 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".
    - MereInterest 4y ago
      So, an append-only database.
    - seanhunter 4y ago
      A database can hold state but it can also easily hold a ledger/transaction log. Or both. Most of the databases I have built or worked on end up organically evolving to have both "state tables" and "event tables" where event tables record state transitions broadly speaking. That's just a very natural way to model systems where you need to capture information about the state changes (eg when they happen etc).
armchairhacker 4y ago
Is there any efficiency benefit to blockchain vs just storing a unique ID for every item, so that even a stack of coins has a stack of UIDs?
- cottenio 4y ago
  Consider the sheer scale: people sell 200 million UO gold for $10. Can you imagine every gold piece having a unique UUID? Even if you didn’t use 256 bit hashes, even at 64 bits you’d be talking about 1.6gb per $10 worth of UO gold. 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.
  - namrog84 4y ago
    Could you mux the data of the coins? 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.
    - cottenio 4y ago
      I just want to note that I only started paying attention to cryptography after I left UO and got into Bitcoin, which sounds like an NFT-grifting MMO supervillain origin story - I know - but I sure did learn a lot about merkle trees and solving interesting social problems.
  - googlryas 4y ago
    Are 1 UO gold coins even individually addressable?
    - cottenio 4y ago
      No, stacks are stacks. They’re an object id with a quantity counter. Each stack, however, was capable of holding its own separate script and objvars; there were event triggers to handle special cases like “onStackAdd” and such.

nrb 4y ago

Since only the server is authoring the entries, just a ledger.

tiagobraw 4y ago
also known as database
- TrapLord_Rhodo 4y ago
  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 4y ago
    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 4y ago
      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.
      - DelightOne 4y ago
        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 4y ago
        Apparently it was a valuable enough idea to Amazon that they spun it up as a service in AWS: QLDB.
        palata 4y ago
        Note: valuable as in "people are willing to pay for it", not as "it is solving a use-case better than alternatives"
      - agentultra 4y ago
        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.
  - twodave 4y ago
    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).
    - palata 4y ago
      Yep. I think the one place where blockchain shines is cryptocurrencies. If it's not a cryptocurrency, then there is a better alternative.
    - zeroclip 4y ago
      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.
  - xani_ 4y ago
    >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.
  - dbttdft 4y ago
    > 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.
- Animats 4y ago
  No, a ledger and a database are different. The ledger is a transaction log. The database holds the current state. 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".
  - MereInterest 4y ago
    So, an append-only database.
  - seanhunter 4y ago
    A database can hold state but it can also easily hold a ledger/transaction log. Or both. Most of the databases I have built or worked on end up organically evolving to have both "state tables" and "event tables" where event tables record state transitions broadly speaking. That's just a very natural way to model systems where you need to capture information about the state changes (eg when they happen etc).

armchairhacker 4y ago

Is there any efficiency benefit to blockchain vs just storing a unique ID for every item, so that even a stack of coins has a stack of UIDs?

cottenio 4y ago
Consider the sheer scale: people sell 200 million UO gold for $10. Can you imagine every gold piece having a unique UUID? Even if you didn’t use 256 bit hashes, even at 64 bits you’d be talking about 1.6gb per $10 worth of UO gold. 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.
- namrog84 4y ago
  Could you mux the data of the coins? 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.
  - cottenio 4y ago
    I just want to note that I only started paying attention to cryptography after I left UO and got into Bitcoin, which sounds like an NFT-grifting MMO supervillain origin story - I know - but I sure did learn a lot about merkle trees and solving interesting social problems.
- googlryas 4y ago
  Are 1 UO gold coins even individually addressable?
  - cottenio 4y ago
    No, stacks are stacks. They’re an object id with a quantity counter. Each stack, however, was capable of holding its own separate script and objvars; there were event triggers to handle special cases like “onStackAdd” and such.