contract-development – How Smart Contracts Persist Data and Upgrade Code

I've answered a similar but different question that may have a bearing on your project - https://stackoverflow.com/questions/42520069/handling-user-profiles-in-ethereum-dapps/42543219#42543219

It obviously depends on the goals and requirements of your project

One of the beauties of using a platform like Ethereum is that you can build a ZERO click login. If we establish that the user's web3.eth.accounts[0] is proof that the user controls the private key of that account's address, then you will always know that the user is valid.

User Signup

• Users have Ethereum accounts.
• On sign up user data is collected in an HTML form
• User submits the form
• Store the data in the database along with the Eth address

User Validation

• User visits the website
• web3js gets the active Ethereum account
• AJAX passes the eth address to the database
• If we recognise the address log the individual in

Thank you for your response. Pardon my lack of knowledge but how would an user have Ethereum account?

It's ok, we all begin (and kind of perpetually remain) as learners, asking is the best way to fill in the gaps in your knowledge.

A user would have an Ethereum account by creating one with something like MetaMask, or Parity, or Mist.

Also, when you mention storing user credentials in a database do you mean a normal relational database?

Yes. There are many cases where storing data on the Ethereum network makes sense, and other cases where it doesn't. From the sound of your question it seems like your data is personal information about the user, which would probably be best stored in a traditional relational database.

Lastly, for web3js to access this active Ethereum account would the user need MetaMask installed? Because AFAIK it allows the use of web3js. Again, apologies if these come off as rudimentary queries.

Well it depends on the browser the user is using, if they are using Chrome then MetaMask or Parity extensions will be required. You can also develop your own interface if you like.

Browsers like Mist have web3js built in. Parity although not a browser in the sense your users are familiar with can also be used like a browser with native web3js.

But the main principle is that the user has a means to securely store their private key on their machine. Secondarily the user has a means to conveniently transact on the Ethereum network.

However, I still have trouble understanding why a user would need an Ethereum account to simply run the dApp. From a traditional sense, all a user should need is register/login to starting using the application.

Because on the blockchain all authority comes from the user and their signed transactions. And user transactions can only be signed by the user's private key. There is no point in an application being a dApp if everything is centralised.

In the case of dApp are we to assume that a normal user of the app should have MetaMask and use it to create their Ethereum account?

No it doesn't have to be MetaMask, it can be something else that does the same thing for the user. But like I said above, if you are building a dApp then the user needs to be able to manage their own keys. Otherwise even if you have functionality happening on the blockchain, what ever it is that you've built it isn't decentralised.

A question you need to ask yourself. "Am I building something using the blockchain for the sake of building something on the blockchain? Or does my application depend on the fundamental properties of a programmable blockchain?"

Something like this should do it:

function burn(uint256 _value) public returns (bool) {
   
   // Requires that the message sender has enough tokens to burn
   require(_value <= balances[msg.sender]);

   // Subtracts _value from callers balance and total supply
   balances[msg.sender] = balances[msg.sender].sub(_value);
   totalSupply_ = totalSupply_.sub(_value);

   // Emits burn and transfer events, make sure you have them in your contracts
   emit Burn(_who, _value);
   emit Transfer(msg.sender, address(0),_value);

   // Since you cant actually burn tokens on the blockchain, sending to address 0, which none has the private keys to, removes them from the circulating supply
   return true;
}

This function makes it so that anyone can burn their tokens. If you do not want that, add something like msg.sender == _owner (you need to define a contract owner for this). You can get the Burn and Transfer events from OpenZeppelin.