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