1

I understand that a MethodID is derived from a function signature and used so that a particular contract function can be specified in the "data" attribute of a transaction. But I'm not sure why this design choice was made rather than using an encoding of the function signature itself. If that were done, I assume the additional step of publishing an ABI for others to use wouldn't be necessary, as one could decode the function signature to get the plain text name and parameters.

My only guess is that using the keccak256 hash ensures a fixed length representation of any method name. Is it that having a dynamically sized identifier for functions would make things less efficient or more complicated? I know that encoding dynamic parameters for function calls require extra metadata as well more complex storage requirements.

foo(uint256) -> 0x2fbebd38
Pro: Fixed length
Con: Can't derive function signature

vs.

foo(uint256) -> 0x666f6f2875696e7432353629
Pro: Can derive function signature
Con: Dynamic in size
1

I would assume it is to keep the smart contract bytecode size smaller. There is no benefit of having cryptographically secure MethodIDs, only downsides.

Also MethodID is part of every Ethereum transaction, so the current blockchain data would be much more bloated with longer MethodIDs

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.