It is common practice in programming to have some validity / integrity checking of data before storing it in a database.

For instance, before storing something which is supposed to be an URI, you check that it matches the URI syntax. Before storing something which is supposed to be a PGP key, you check that it has the right format.

But, in Ethereum, there are two problems for these verifications:

  • First the lack of existing libraries; (I program with Solidity) which will probably be solved with time.
  • Second the cost of gas; these verifications can be costly (I cannot imagine the gas needed to check a crypto signature with ECDSA).

Do you think it is today good practice to check input data or is it better to accept everything and store it in the blockchain?

  • Actually, verifying an ECDSA signature is pretty cheap, there are built-in "precompiled contracts" for cryptoprimatives. ECDSARECOVER only costs 3000 gas (0.00006 ETH) Jun 6, 2016 at 18:34

2 Answers 2


While the question is suited to have an opinionated debate, I think the policy one should adopt is a function of the value the specific parameter is expected to steward.

For example, the nickName most often is not subject to scrutiny, while the amount of Ether and all crypto parameters probably must.

Trivia: Somewhere I read a funny comment by Vitalik, that the gasoline industry managed to not have the same problem, that drivers try to calculate how many micro cents it would cost them to pass that truck in front of them. Maybe we take this all too serious...


This is clearly opinion based but I think that you should see Ethereum as a big database and contracts as stored procedures.

Also as databases have transaction time constraints, contracts have fuel constraints that leads to a similar result wich is use less code as possible.

Most of the time you will have a program on top of it to compute data and display it. Most programs have the responsibility to check data they store and load in the database.

Stored procedures were used to harden the data coherence in relational models and even if they can be used to check data they were mainly used to make the data easier to query or store. But stored procedure are less and less used as they lead to systems that are difficult to update and maintain. Except for big systems or for systems with big legacy, you won't find stored procedures in relational databases today.

So, this is my own opinion, but you should probably try to make your Dapp JS code validate data it reads from and write to Ethereum.

The only difference is that with centralized systems, database is hidden so you don't expect users to query the database directly, otherwise you could provide an API that validates data.

In decentralized world, anyone has access to the raw data in the database. You can create an Api but anyone can bypass it. I think we have to deal with it. If someone crashes it's program because the code of the Dapp failed to check the data from your contract, you can help fixing and send advises, but you could also let it go because that's not your data and your contract that failed.

Also note that even if you implement validation in your contacts, none should trust it and double validating should be done. Yes we will have a lot of crappy contracts on the network and we should call them in a trustless way. So your Dapp would have to check user input before storing it but also validate output from the contract as someone else could have called the contract without having the data correctly validated before.


  • Whether or not a database uses stored procedures, there's some kind of server-side validation. Jun 8, 2016 at 17:34
  • Missed the edit window: if it's not terribly important then sure, validate only in Javascript. If it might cause a more serious problem like loss of someone's funds, it has to be in the contract. I'd say the metaphor should not be "contract is store procedure" but "contract is serverside, JS is clientside." Jun 8, 2016 at 17:43
  • I think checking input data is different than ensuring that contract works correctly. Important check like is the receiver in the list of allowed receivers sure have to be done in contract. But checking the first name is well formed is less important IMO. Jun 8, 2016 at 17:57
  • Yep, makes sense. Jun 8, 2016 at 18:09

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.