That's based on one current implementation of a gaming DApp. It's worth noting that you can achieve semi-privacy through either on-chain/off-chain hybrids, as

That's based on one current implementation of a gaming DApp. It's worth noting that you can achieve semi-privacy through either on-chain/off-chain hybrids, as well as some other emerging efforts. One example I've been playing around with is to use the multi-address approach: In your database each "player" consists of multiple addresses each which are OR-multi-sig wallets, for various inventory elements and stats. When they log in via a system like metamask, their main wallet (PlayerID) is unlocking an account which in your games database (off-chain) ties together another set of "master wallets" together with you've given the player private keys for - for each item, or each set of X items, in the players inventory you are setting up a new smart contract that is a OR-multi-sig wallet. For this wallet, which holds the item, there are two possible signatories the first being the game's main contract, so that the game can add/remove items from players based on game events, and then one of the players private keys. While you'd likely need a custom fork of metamask to handle the multi-key environment, you've made a system where: * Player's inventory cannot be know from one private address. * Player's retain full control over the items. * Player's have private key access to the items in case the service goes down. * You store player data off-chain, but in a way that your service is not crucial to the game. * Player assets can be traded off-game without updating the game service. * Data about individual items is still public, and does not need to be obscured, oraclized or stored off chain. The current blocker isn't any specific blockchain technology, but just having a good multi-key management UI for users.