1

I have been doing quite a bit of research into Solidity and Ethereum contracts in recent days (docs and tutorials) but I have some questions that I am still stuck on. I come from a commercial Web (front & back) background as well as IOS App development so I have a pretty good knowledge of site structure and frameworks.

The following questions are based on the assumption that we were building lets say a microblogging platform.

  1. I understand that we have to think of Contracts as "classes" similar traditional web development. Does that mean that for our example project we would create multiple contracts to complete the final project and link them together? For example a user contract, blog post contract etc.

  2. If we do have multiple contracts I assume that they are connected together via their address?

  3. If all users call the blog post contract at address xxxxxxx in terms of the blog posts that each user makes are they stored against/inside the address of the contract that is called and if so is there a limit to the number of posts/data stored at the address?

If we had lets say 2 million posts would they all be stored within the contract at that address?

  1. Looking at this in a traditional database sense i.e MYSQL how is data then searched for within the contract? For example lets say I want to search by all posts from user x or posts that contain a certain string?

  2. If i want to read data within the contract i.e the total number of users or retrieve the total number of posts do this cost gas? I have read that reading doesn't but some people say that it does if it is calling a function within a contract.

If someone could answer these that would be great.

Thanks All

1

I'll try to answer each question below:

1- I understand that we have to think of Contracts as "classes" similar traditional web development. Does that mean that for our example project we would create multiple contracts to complete the final project and link them together? For example a user contract, blog post contract etc.

You can think of contracts as classes, yes, but you don't structure the app the same way you would in JS or other languages. For example: In other languages you would create a BlogPost class (with say - to make it simple - a title, text and publishedOn variables). Then, you would create an array of BlogPosts and fill it with the results of a query. In solidity, the way to go would be to create a BlogPosts contract that holds the array with said blogposts (which could be a struct that you define in the same file). Every blogpost item would live inside this contract.

2- If we do have multiple contracts I assume that they are connected together via their address?

Yes, but you can also have contractA hold a reference to contractB in a state variable. For example, in a token crowdsale app:

In CrowdsaleContract:

token = createToken();
function createToken() internal returns (Coin) {
    return new Coin();
  }

Here, we would be assigning token to the result of createToken() function, which instantiates a contract Coin (the Coin constructor sets its name, symbol, etc). Later on, we could do token.someFunction() to call a function on the referenced token, and at no point we needed to know Coin's address at all.

3- If all users call the blog post contract at address xxxxxxx in terms of the blog posts that each user makes are they stored against/inside the address of the contract that is called and if so is there a limit to the number of posts/data stored at the address?

As I said in 1) if you generated a contract for each blog post it would be extremely hard to maintain and extremely expensive to post. The way to go, oversimplifying it, is to have a BlogPosts contract that holds an array of blogpost struct. This blogpost struct would also have an author field which could be the address of the person who created it so you can later fetch the data of said author.

4- Looking at this in a traditional database sense i.e MYSQL how is data then searched for within the contract? For example lets say I want to search by all posts from user x or posts that contain a certain string?

This would be extremely difficult if not impossible for 2 million records. First, there's no easy way to query the data as you would in a Relational DB. You would have to retrieve the complete array and then filter it client-side. Second, even then, if you had 2 million blog posts, manipulating such array in Solidity would be impossible. You will run out of gas before you can iterate or do anything with this array.

5- If i want to read data within the contract i.e the total number of users or retrieve the total number of posts do this cost gas? I have read that reading doesn't but some people say that it does if it is calling a function within a contract.

If you are just reading data, it won't cost you gas BUT, gas is still used. You just don't pay for it. This means that you are still limited in terms of what you can do with the data. You wouldn't be able to, say, iterate through 2 mil records and count them.


You have to ask yourself if it's really worth it having all this data on-chain. Do you really need to store all the blog post data, users, etc, on-chain? You could do something hybrid where you store the blog post data off-chain (mysql, mongodb, etc) so you can query it, filter it, etc. and then part of this data, is stored on the blockchain.

  • Thank you for posting the information, at the present time I'm wondering what sort of applications are best suited to the Blockchain considering the restrictions on the data storage. If you take the above example and lets say keep the post data in a database it would defeat the point of decentralisation, what would you really need the blockchain for? – ORStudios Oct 19 '17 at 13:16
  • You can check stateofthedapps.com to see what other people are doing in terms of Descentralized Apps (Dapps). – pabloruiz55 Oct 19 '17 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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