EIP-1138: Human-Readable Transaction Requests

EIPs
1

I wanted to bring up here the discussion for Human-Readable Transaction Requests that Witek Radomski proposed

On WalletConnect we have a method to relay a transaction request from the desktop Dapp to the mobile Wallet but currently this simply provides a raw transaction that the Wallet needs to parse in order to display to the user what’s being requested to be signed

With this EIP it would enable not only to share this information between the Dapp and the Wallet to display to the user but also to generate a raw transaction to be signed and broadcasted.

2 Likes
2

This proposal includes parameters for sharing a summary, a description and an icon in the transaction request to display information that may not be available on the wallet. However this still needs to be machine verifiable otherwise it opens up vulnerabilities for phishing

3

ethereum:makerdai.eth/transfer&address=notascammer.eth&uint256=100000e18&param=_to&param=_value&description=Buys a cute innocent little kitten. Pay no attention to the DAI transfer call, I swear all this does is buy a super cute kitten!

I think this is the wrong approach. We should not trust the app to describe to us what the transactions does. Instead, we should rely on a Radspec description of the contract functions which is provided by either the contract itself or given by the client/wallet.

2 Likes
4

Amazing, exactly what I was looking for allowing the description to be verifiable :raised_hands: I’ve commented on the github issue for this EIP

5

@pedrouid I recommend checking out https://github.com/ethereum/EIPs/issues/719. It is in dire need of a champion, I drafted up the issue hoping someone would get excited enough about it to take it to the finish line but no such luck so far. If you are really interested in informed signing requests, that is where I recommend you start.

2 Likes
6

Thanks for sharing this @MicahZoltu! There is definitely a lot of candidates for tackling machine-verifiable human-readable transaction requests. So far we have the 681, 831, 719, 1138 and also radspec

I think the key aspects that will make or break from all of these is the one that is able to tick the following:

  1. Fully machine verifiable
  2. Can be easily read as single sentence
  3. Doesn’t focus solely on token transfers (thus covering all smart contract functions)
  4. Could also be used interchangeably between normal transactions & smart contract calls
    (ideally even for signing messages)

And optionally I think it could even be designed in a way that it can be easily used between different protocols like the 681, 831 and 1138 have the uri format starting with ethereum:

7

Of course don’t be specific to ETH/Token transfers, but I think some sort of common flag that denotes “transfers or handles valuable assets” like tokens but also ownership and such would be useful to call out. I sort of see three different levels of risk in a function: 1) no state changes, 2) internal state changes, or 3) transfers or handles valuable assets internally or through an external call

A change in UX feedback such as a different color or something would be very handy I think.

1 Like
8

That’s a great point @fubuloubu, however Ethereum smart contracts could be anything, how would you distinguish the level 2 from 3? Technically they both constitute internal state changes and it’s the Dapp developer who will be determining this level of risk when requesting the transaction.
Thus how could we make this distinction machine verifiable?

9

Well, you can’t. Humans ascribe value to whatever trinkets make sense to them. That isn’t really machine validateable.

I would suggest it becomes part of the discipline of writing into Natspec-style comments.

EDIT: I mean, you could probably try all the functions and tell the human that the function executed wrong but the state change is final, and then judge the degree of violence the human perpetuates against the machine, but that probably isn’t a scalable method for measuring value.

1 Like