pipermerriam/ethereum-function-signature-registry

Include function output types or entire ABI if available

Opened this issue · 0 comments

zemse commented
  • OS: osx
  • Python version (output of python --version):
  • Environment (output of pip freeze):

What is wrong?

Currently, www.4byte.directory does not include the interface for return type given a selector.

% curl https://www.4byte.directory/api/v1/signatures/?hex_signature=0xfaa75068
{
  "count":1,
  "next":null,
  "previous":null,
  "results":[{
      "id":847492,
      "created_at":"2022-11-17T12:50:56.132220Z",
      "text_signature":"killStinkyNigger(address)",
      "hex_signature":"0xfaa75068",
      "bytes_signature":"ú§Ph"
    }]
}

It would be great to include the entire ABI fragment in the response or a compact human readable ABI.

My use case is decoding execution trace. I do get the function signature which helps to decode the calldata, however the return data from the execution can't be decoded since we don't know it's interface.

STATICCALL UnknownContractAndFunction(
  to=0xfe0e4dc42f1e587bb20f1e664734d490852f6696,
  // input can be decoded
  input=0x5c60da1b, 
  // output cannot be decoded since we don't know the return interface
  ret=0x0000000000000000000000003cfd48e3dc7ee2519bc9b3374e3a8b8cf5cada3e
)

How can it be fixed

Include the output ABI in the selector response in www.4byte.directory.

There is a catch that output ABI is not unique, because the return signature is not baked into the selector, given a selector with same calldata signature, it can have various return signatures. e.g. name() mostly returns string, but for MKR token contract it returns bytes32 value. Hence, the return type for name() can include both types. The consumer can try using the suggested return signature from the directory, and proceed with whatever works for them.