Best way to record document hash and address (mapping vs transaction input data)

Question

First of all, sorry if the question is too open, is not a coding problem but a design decision.

I'm doing a bit of research about storing a proof of a document existence (a hash of the document) in Blockchain, and I want to ask you which of these 2 options is better to store a hash of a document, related to an address (to show property of the document at the time of).

My main objective is to let users to record proof of ownership of their Ethereum address over documents, without depending of my Dapp to verify it.

I think there are 2 main alternatives:

1. Store the hash as a message to be available in the input data field of an Ethereum transaction:

   fallback() external

2. Store the hash in a mapping of an Smart Contract

   mapping(dochash => address) documents;

The first option provides a quick way to see the hash of the document and relate it to the "from" address field (in Etherscan with transaction ID, for example).

I know that it would be a more elegant way to store the document hash and the sender address in a Solidity mapping, but someone would need a Dapp connected with the Smart Contract ABI to verify the hash, and if the Smart Contract logic allow it, the mapping value could be updated (it should require an Smart Contract audit to be sure).

Maybe the most interesting solution would be to combine both? Store hash in message, while also in Smart Contract mapping, for a Dapp to manage the verification?

Answer 1

I'll give you my opinion on the subject hoping you'll find it useful. I'll comment about the two methods you suggested and elaborate on the use of events.

Store the hash as a message: This is the cheapest method. However, for a user to read the value of the message the transaction hash is needed. This, from the user's perspective means storing all transaction hashed elsewhere. Alternatively he would have to search through every transaction made by his address in etherscan. Both of these options don't seem ideal

Store the hash in a mapping: This method is straight forward and provides better functionality as well as on-chain verification. A user can easily retrieve the address related to a specific document hash which doesn't need to be stored as it can be calculated on the fly. Yet looking for the doc-hash using an address isn't possible(without additional code and cost). Additionally it is the most expensive approach out of three and users won't be able to do the verification themselves(at least not without the ABI and some knowledge).

Store the hash in an event(allong with the address): First of all events and their data aren't accessible within smart contracts, so you can't deal with the verification using Solidity. Still, you can use web3 to retrieve the Logs that contain the data you want and do the verification off-chain, in your application. This method is way cheaper than the second one, yet a bit more expensive than the first one(negligible in my opinion). Above all, using events you can add some nice options for the users of your Dapp without much effort. By declaring both of your event parameters(doc-hash,address) as indexed you will be able to filter the Logs efficiently and enable your Dapp's users to:

• Retrieve all doc-hashes related to a specific address
• Retrieve the address related to a specific doc-hash

Also, that Logs produced by events are publicly accessible on etherscan(example) so users will be able to do the verification on their own.

As you might know, each transaction contains the events emitted in its execution . Similarly, when retrieving the event-logs with the help of web3 you get the transaction hash in which they were created. With that in mind you can provide your users with:

• All the transaction hashes related to a specific address
• The transaction hash related to a specific doc-hash

This way they don't have to store the transaction hashes separately but can still do the verification themselves. On the other hand, if you don't want to provide them any of the above functionalities they can still look up the logs in etherscan.

Conclusion

All in all, using events seems to be a better option for this kind of project as:

• It enables users to do the verification themselves as the first option you suggested
• Combining it with web3 can provide better functionality at much less cost than the second method

In case someone thinks i got it wrong please correct me as i am relatively new. Also, English is not my native language so be lenient.