6 ms·

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.
      - ohmahjong 4y ago
        cottenio is the author in this case. If there is the potential of internal employees being malicious, then maybe trust isn't guaranteed.
        meheleventyone 4y ago
        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.
        xani_ 4y ago
        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 ?
  - cottenio 4y ago
    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 4y ago
    > 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)
- 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).

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.
    - ohmahjong 4y ago
      cottenio is the author in this case. If there is the potential of internal employees being malicious, then maybe trust isn't guaranteed.
      - meheleventyone 4y ago
        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.
      - xani_ 4y ago
        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 ?
- cottenio 4y ago
  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 4y ago
  > 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)
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).