9

As I'm learning more and more about developing Dapps, I'm having trouble understanding what needs to be stored in the smart contract (over our database etc..).

Let's take the case of a simple betting website. The way I picture creating a Dapp of a betting website would be the following and please correct me if I'm wrong.

Technology Used: Ruby on Rails (Back-End), React (Front end), Solidity(Smart Contract)

1) I would store in my database the following informations :

  • User (name, email, etc..)
  • List of available bets
  • List of user's bet

2) Upon creation of a user, I would create a new Ethereum Wallet with the same password as his credentials and store the public address of his wallet in the database.

3) I would store in the Smart Contract:

  • ID of the user (from the database)
  • ID of the bet (from the database)
  • amount bet
  • bet result/state
  • user ethereum wallet address
  • my website ethereum wallet address
  • and the code to execute the transaction based on the bet result (win : transfer his winnings to the user wallet, lose : transfer his betting amount to my website wallet)

As a result, the smart contract would only contain information related to a betting transaction (bet results, amount bet) and the database will contain the rest. To retrieve a user's history of bets, I would retrieve the list from the database and retrieve the results from the smart contract (linked by the ID of the bet and user).

Am I completely misunderstanding the Dapps/Smart contract concept ? Please advise, thanks !!

Improve this question
1

1 Answer 1

Reset to default
6

Firstly, great that you are learning more about DApps, it's always great to see the community growing. However, you do have some misunderstanding about the way the DApps should be designed, so I'll try to point you in the helpful direction.

Technology Used: Ruby on Rails (Back-End), React (Front end), Solidity(Smart Contract)

As pointed in this answer:

A DApp has its backend code running on a decentralized peer-to-peer network.

DApps by definition don't have classic backend, like the RoR would be. That means, in order for your application to be called DApp, the smart contracts should contain all your backend logic. The frontend could be any JavaScript, really, along with the web3 library that gives you the APIs to communicate with the smart contract backend.

This is a completely different paradigm, which I had problems wrapping my head around for quite some time. There are decentralized alternatives for some of the classic technologies, such as IPFS or Swarm for storage or hosting your DApp website on, "users" should be tied to blockchain addresses, you could use PouchDB, etc. The DApp should be fully open-source and autonomous.

If you wish to build the betting DApp, you really don't need to store user information in database - you can program the frontend and, for example, interact through the contract which sends the % of any bet to contract in your control and have sound business model while providing good service DApp users. But if you want each bet on blockchain, the transaction costs would sometimes prove too high. However, this doesn't mean that you can't have hybrid app - true DApps in their current state do have some limitations.

Working on Lemon Email, we had to weigh some of the benefits of the established technologies (SMTP server for example) along with the benefits of decentralized applications - so we decided to create the DApp to suit everyone. We used the Ethereum Blockchain to store metadata of our interactions, and IPFS as our storage. If you wish, you can read more about our architecture here.

Some additional reading:

https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/

https://ethereum.org/dao

https://www.packtpub.com/big-data-and-business-intelligence/mastering-blockchain

Improve this answer
6
  • Hi, first of all, thank you so much for taking the time to answer me. So if I'm understanding correctly, the whole back-end (code logic + data storage) would be stored in the smart contract to be considered a complete dapps. However, I read a lot of article saying that it costs a lot to store data in the smart contract. What if I need to store billions of row (every betting transactions), or images or even videos? How would I achieve that? Upload to S3 and store the link to the asset?
    – fabdarice
    Commented Jun 11, 2017 at 18:33
  • Also, let's say I have to display an user's betting history (thousands of row). Does that mean I have to query the smart contract to retrieve that list? I thought that communication with smart contract can take a while (block transactions, mining etc..).?
    – fabdarice
    Commented Jun 11, 2017 at 18:36
  • You don't actually store anything in Smart Contract directly - you can store data as the metadata on each transaction. However, this is expensive - and storing images or videos is outright insane. Each full node in blockchain has the copy of all information published on the blockchain - you can see how the whole blockchain could become unusable if this was the case. There are alternatives, like IPFS but they are not viable for this use case. You can build separate storage system, but you must account for some complex things while building it, like access management system.
    – Cordo van Saviour
    Commented Jun 11, 2017 at 18:52
  • Can you expand on your separate storage system? That's what I meant when I thought of storing those data in my dataabse and storing only ID in the smart contract.
    – fabdarice
    Commented Jun 11, 2017 at 19:16
  • DApps are, by definition, decentralized, while something like MySQL or S3 and central server interacting with them don't fall into that category. That would be maybe a good solution for a hybrid application. No one can stop you from using which ever technology you like - but that's not DApp. On our DApp, we used IPFS to store front-end encrypted data.
    – Cordo van Saviour
    Commented Jun 11, 2017 at 19:45

Your Answer

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

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