Checking values of variables before storing them

Question

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?

Answer 1

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...

Answer 2

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.

TL;DR