search

trezor / trezor-firmware

:lock: Trezor Firmware Monorepo
https://trezor.io
Other
1.33k stars 649 forks source link

Better display ethereum function calls #69

Open ligi opened 6 years ago

ligi commented 6 years ago

Currently when calling ethereum functions you only see the raw hex data - also often you do not see all of it as the hex gets long fast and I was not able to scroll. The hex can be easily made shorter and more digestible by humans by resolving the function from the 4byte signature - e.g. via https://github.com/ethereum-lists/4bytes and then displaying the function name with parameters. So a really long hex string that might not fit on the trezor and is hard to parse by a human can easily fit on the display of the trezor and better digested by humans. A problem might be the size of the signature database - I see 2 solutions here:

prusnak commented 6 years ago

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.

ligi commented 6 years ago

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

prusnak commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

is coming from.

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

prusnak commented 6 years ago

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 commented 6 years ago

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

I think 00000000 is constructed - some context: https://github.com/pipermerriam/ethereum-function-signature-registry/issues/30#issuecomment-385015547 http://swende.se/blog/Blockhash-Refactor.html

ligi commented 6 years ago

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

prusnak commented 6 years ago

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 commented 6 years ago

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 commented 4 years ago

linking to #15

Hannsek commented 1 year ago

duplicate? #2874

matejcik commented 1 year ago

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

Hannsek commented 1 year ago

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:

How to read data

example

0x38ed1739000000000000000000000000000000000000000000000000000000009502f900000000000000000000000000000000000000000000a07e38bf71936cbe39594100000000000000000000000000000000000000000000000000000000000000a00000000000000000000000003c02cebb49f6e8f1fc96158099ffa064bbfee38b00000000000000000000000000000000000000000000000000000000616e11230000000000000000000000000000000000000000000000000000000000000003000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000528b3e98c63ce21c6f680b713918e0f89dfae555

decoded data:

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

Possible next steps: