Better display ethereum function calls

[trezor]

Better display ethereum function calls

[prusnak]

I am planning to create a mechanism which will allow a wallet to upload a signed definition of {coin, token, 4byte-function} as a part of signed transaction.

We would need to create a signed database where each row is signed by trusted key (public key of this keypair will be part of the Trezor firmware) and TREZOR will parse and check the signature of provided data-row.

That way, we would not need to store all coins/tokens/4bytes in the firmware.

[matejcik]

yes, this has more info so i suggest closing #2874 and keeping this one

[ligi]

That is a great idea! Please keep me updated on this

[prusnak]

I was looking at the catalog and I am quite disappointed about the very high number of collisions in the space. It is so high, I have my doubts about the usefulness of the feature.

How do you solve the collision problem? Do you show all possible options?

[ligi]

I do not see many collisions - I was expecting more and was surprised that there where not too many collisions. In the 23504 signatures I parse currently there are 3 collisions:

aaaaaad1 yycU4()
aaaaaad1 uYZeB()

00000000 get_block_hash_257335279069929(uint256)
00000000 overdiffusingness(bytes,uint256,uint256,uint256,uint256)
00000000 left_branch_block(uint32)

0000006e bright_peace(bytes32,bytes)
0000006e display_allow(uint256,uint256,uint256,uint32)

the first 2 (aaaaaad1 and 00000000) sound really constructed and I do not think there is real world impact with these. And even 6e can IMHO be ignored. Wonder where your observation of :

high number of collisions in the space

is coming from.

[prusnak]

is coming from.

I looked at 00000000 and expected the rest is the same :-)

[prusnak]

Do you think it's possible to create something like a curated list where all collisions are resolved? That means no signature collisions (i.e. no entries for 00000000, 0000006e, etc.) and also where you pick the better value for a9059cbb from transfer(address _to,uint256 _value);transfer(address to,uint val)? Or this is just too much effort?

[ligi]

hehe - no - don't judge a list by the first entry ;-)

I think 00000000 is constructed - some context:
pipermerriam/ethereum-function-signature-registry#30 (comment)
http://swende.se/blog/Blockhash-Refactor.html

[ligi]

I think currently it is possible to curate a list that resolves the collisions - but not sure how future compatible this is ..

[prusnak]

I will check how many collisions there will be left if I treat arguments _to and to like they are the same. Also maybe creating a small dictionary which says that val and value are the same could help.

Another question: is uint and uint256 the same?

[ligi]

Another question: is uint and uint256 the same?

yes - uint must be resolved to uint256 for the function selector

uint, int: synonyms for uint256, int256 respectively. For computing the function selector, uint256 and int256 have to be used.

https://solidity.readthedocs.io/en/develop/abi-spec.html

PS: the collisions I showed above are without parameter names - with parameter names there are more - currently I am not sure about the parameter names - hope to be able to discuss this in about 2 weeks in person with @holiman

[matejcik]

linking to #15

[Hannsek]

duplicate? #2874

[Hannsek]

Copied from #2874:

Every transaction in Ethereum can carry additional input data (e.g. 0x095ea7b30000000000000000000000008bc3702c35d33e5df7cb0f06cb72a0c34ae0c56f00000000000000000000000000000000000000000000000ee5c13efe85190000) (https://etherscan.io/tx/0x2b930225479934eda949c3c2b0f3af5d5fd60136f7c9f0d5bbabf569def1f8a8). The first 4 bytes of this input data, i.e. 0x095ea7b3, specify which function in the smart contract gets executed. These 4 bytes are not human readable. Therefore, there exists signature databases which help to map the hash (4 bytes) to human-readable form.

Signature databases:

• https://www.4byte.directory/signatures/
• https://github.com/volsa/etherface
• (https://www.etherface.io/statistics)

How to read data

example

0x38ed1739000000000000000000000000000000000000000000000000000000009502f900000000000000000000000000000000000000000000a07e38bf71936cbe39594100000000000000000000000000000000000000000000000000000000000000a00000000000000000000000003c02cebb49f6e8f1fc96158099ffa064bbfee38b00000000000000000000000000000000000000000000000000000000616e11230000000000000000000000000000000000000000000000000000000000000003000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000528b3e98c63ce21c6f680b713918e0f89dfae555

• 0x - indicator that the hexadecimal
• 38ed1739 - hashed signature of the function being called (every 2 hex characters represent a byte)
• The rest of the bytes are hashes of the arguments being passed to the function

decoded data:

function called:  swapExactTokensForTokens
arguments:  {
  "amountIn": 2500000000,
  "amountOutMin": 194024196127819599854524737,
  "path": [
    "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
    "0x528B3e98c63cE21C6f680b713918E0F89DfaE555"
  ],
  "to": "0x3c02cebB49F6e8f1FC96158099fFA064bBfeE38B",
  "deadline": 1634603299
}

Possible next steps:

• preload the well known smart contract addresses → label it → show the label next to the address (otherwise label it as unknown)
• label the Smart Contract address user is authorising and highlight an unknown address to give an alert
• address after parameter “to” (most of the time same as address of the sender) - compare “to” address with “from” address → if not same → warning
• warn before signing an unlimited allowance contract https://satoshilabs.slack.com/archives/C03SRP8PSS2/p1680176003637509