I’ve read these, and I love all the work that has gone into thinking about this! While these are helpful for less security conscious people, I think they can be quite misleading, and require a lot of overhaul to smart contract design.
I think my proposal solves a different issue these two bring up.
- My proposal is looking to make it easier to verify data on a hardware device, where eyeballs will fail. Yes, this will require regular users to be a bit more educated (the average user would need to be slightly more technical)
- These two proposals look at enshrining text into the application layer to make it easier for less-technical people to have assurance.
I’ve outlined why I think these proposals don’t make sense to prioritize here.
I think that just showing the user a digest or hash of any kind is not going to help much.
On a hardware wallet, your recommendation would be to read the human-readable string embedded in the smart contract, which I agree, would be easier than reading a digest. However, I think it language is so problematic, that people would still sign “bad” transactions. For example, a UniswapV2 swap transaction, take this solidity:
swapExactTokensForETH(amountIn, amountOutMin, path, msg.sender, block.timestamp)
What would the text be?
Swap 5,000 USDC for at least 1 ETH with a deadline of xxx, and send the tokens to you
Hmm… You don’t want to trust USDC is the true USDC is correct though (does your contract have a whitelist for all tokens?). And who is you?
Swap 5,000 tokens at address XXXXXXXX for at least 1 ETH with a deadline of YYYY, and send the tokens to ZZZZZZZZ
Now, if this shows up on your hardware wallet, are you eyeballing each address? Now you’ve opened yourself up to an address poison attack.
But not only that, you batched it in your Safe{Wallet}, and added an approval first. What does the “final” text say now? Does each contract need to call into each other to generate the final string? You are still eyeballing each address on your hardware wallet, yikes!
Ok… So how can we solve this? Well, your hardware wallet could show the user a hash of the description, which they could compare to the expected hash… But now we are back to my proposal here, just showing a digest of the calldata, and having another device explain the calldata.
More thoughts
It could be interesting to have a getDocsURI function where a bot could read the docs in order to help decode the calldata into a human readable description, and this would be a much more gas efficient way to do this. Additionally, the getDocsURI could use a DSL (as your proposal says) that takes calldata as input, and outputs a human-readable description. (Sort of like a docs_lang), but either way, we would still want a minimal set of characters a user needs to look at on their wallets so they don’t run into security fatigue, and we don’t have to waste gas on explaining transactions - when all the information is already in the calldata!
The two proposals linked IMO are like adding a translator enshrined in the smart contracts, which seems very redundant to me.