Transaction decoding: ERC-721 Non-fungible tokens

[raulk]

Add support for decoding ERC-721 transactions.

• Import the ABI into the abi directory. Make sure the JSON is formatted.
• That ABI does not come from an official source, so check it against the expected interface.
• Identify decodable transaction types, and start a discussion in this ticket. For each TX type, indicate the proposed fields and data types. Let's reach team consensus around our understanding.
• Implement the decoding of each transaction type, as well as associated queries (e.g. symbol, token supply, etc.)

[jonathan-buhler]

From the expected interface of ERC-721:

• safeTransferFrom: sender(address), from (address), to (address), tokenID (Int) and perhaps data (bytes, but not sure how GraphQL handles those)
• transferFrom: sender (address), from (address), to (address), tokenID (Int)
• approve: sender (address), approved (address), tokenID (Int)
• setApprovalForAll: sender (address) operator (address), approved (Boolean)

[raulk]

LGTM. bytes can be returned as hex strings.

[raulk]

@jonathanBuhler Could you update this ticket with your findings and the blockers you're facing?

[jonathan-buhler]

Due to similarities in the ERC721 and ERC20 token, our current decoding system marks both as ERC20. Raul suggested using ERC165 to identify which interface the token implements, but I was not able to make much headway in that regard. This is the pull request in my own fork of the code as it currently stands.

For the most part my attempts to decode ERC721 mirrored the current implementation for ERC20, but with added fields for where 721 had functionality that 20 did not (setApprovalForAll, safeTransferFrom).