0

I hope this question is not too general. I would like to have a few opinions.

What is the best way to work with data in Ethereum? Lets say we build a decentralized exchange on a small scale. How would you show the order book on the front end?

  1. Via events logs

  2. Other kind of data types e.g. structs, mappings etc.

  3. Using self made data types e.g. linked lists

| improve this question | |
  • you don't really need events, just making a Call() to the contract will give you all the data. – Nulik Sep 21 '18 at 21:54
  • @Nulik But events are well suited to query them and filter them via different parameters e.g. chronologically etc. Which data types and structure would you use to use Ethereum as a database? – baermathias Sep 29 '18 at 12:44
  • well Solidity provides mapping type, which is key->value map type , all the token balances are stored this way. BTW, we are getting ready to release an Ethereum wallet app, it is an open source project and you can reuse a lot of functions which have been already implemented. Specially knowing ethereum internals is not needed since it has all been abstracted by our API. If you are not afraid of C++ I can share it with you. drop me a note – Nulik Sep 29 '18 at 16:33
1

Ideally you would want to make as few calls to the blockchain as possible, as it is slow and would not make for a very active orderbook. The general rule of thumb for Ethereum (for now) is that the fewer transactions/calls you can make, the better.

With that said, one of the best ways to do this would be to build out your own block explorer, and talk to that with the front-end rather than reading from the blockchain. By having all the data stored in a local DB, you are able to hook up the front end of your exchange to this database and get much more efficiency than you would reading directly from the Ethereum network.

In terms of the list above, you can use whatever would serve your application best. If your decentralized exchange is well written and logs all relevant information, using events is a good way to go. You can also save the state of the entire contract in variables that you read from as well. Any of these options will work, and they will work best if used in a traditional database.

Imagine a scenario where you have multiple concurrent users. If you did everything on the blockchain (no other backend for data), each of these users would have to make X calls to the chain, effectively taking seconds to fully render the page they are on.

| improve this answer | |
  • 1
    the problem with using a frond end, that processes blockchain data is that it is centralized. So, if your centralized front end is hacked, the attacker may fool user that order was cancelled, and the user would submit another order, and make a double sell, just an example. – Nulik Sep 21 '18 at 21:52

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