2

If I'm building a dapp, is it worthwhile to store information that is in the contract on a server for speed purposes, and only using the contract to track ownership of tokens.

I.e. for something like Cryptokitties, could you store a mapping of userId->[kittenIds] and kittenID->userId on a central server that reads from the blockchain so that the user has to make calls to the blockchain less frequently?

Or, should it be left to the user's ethereum client to execute the public functions of the contract?

Improve this question

1 Answer 1

Reset to default
2

I don't see the point to duplicate data here and there and write layers to sync it (having, potentially, sync issues as well).

The whole purpose of blockchain and DApps is to decentralise (D-app, decentralised application). I wouldn't centralise it again. Even because, any call in the blockchain that won't change the status doesn't consume any gas (like reading the mapping that you're talking about in your post).

So, in my opinion, it's not something that add any value to your application.

Improve this answer
4
  • What do think about processing time and resources a contract's transaction require? It is significant compared to a well-tuned sql transaction. On heavy loaded services this could justify the mentioned solution, on the price and issues of the data syncing, for example with background queues. This came to my mind when designing such a system right now, not yet decided.
    – Ho Zong
    Mar 18, 2018 at 10:35
  • 1
    Reading the status will not use the same processing time and resources as changing the status or mining a block. And no, in the other case you will not have only a well-tuned sql transaction but more likely layers of software like this: pospi.github.io/talk-solidity-blockchain-intro/res/… and, your system should be on high availability, and then you will have multiple instances of these services and DB. But even if you do anything right your application could still have downtime - even facebook have it - thing that will never happen with a pure DApp.
    – qbsp
    Mar 18, 2018 at 13:34
  • 1
    I disagree. There are immense benefits to caching the data offline. In fact, for some things, it's not possible to get certain information. For example, in a simple (gas-efficient) token contract, there is no way to list out the balances of all token holders. (You cannot spin through a map from outside the contract.) The only way to build a cap-table would be to either duplicate the map off-chain or track every transaction and re-create the map off-chain. There are also significant speed issues. QuickBlocks, for example, can return the data literally hundreds of times faster than querying.
    – Thomas Jay Rush
    Mar 18, 2018 at 17:43
  • Yes, it depends by the use case. The question was generic and so was the answer. If you don't need to list out the balances of the token holders but just give a detail for the specific user then contract-call would be fine. In the other hands QuickBlocks is fully decentralized, and this will fit more a blockchain based solution instead of using a centralized DB.
    – qbsp
    Mar 19, 2018 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.