[Ethereum]: Support obtaining the function signature from an Ethereum function ABI

[10gic]

Description

The function signature is useful for indicating the intended contract call and for computing the 4-byte selector.

There is a similar function, tw_ethereum_abi_function_get_signature, in the code; however, it is not exported, and its input argument is difficult to construct. Therefore, I added a new function named EthereumAbi.getFunctionSignature. This new function accepts an ABI JSON string as an argument, making it very easy to use.

How to test

Run Rust, C++, iOS, Android tests

Types of changes

Checklist

• Create pull request as draft initially, unless its complete.
• Add tests to cover changes as needed.
• Update documentation as needed.
• If there is a related Issue, mention it in the description.

If you're adding a new blockchain

• I have read the guidelines for adding a new blockchain.

[10gic]

There are two functions that can be used to decode Ethereum transactions: EthereumAbi.decodeContractCall(coin: CoinType, input: ByteArray) and EthereumAbi.decodeCall(data: ByteArray, abi: String). Both functions require a special ABI format as an input argument:

{
    "ec37a4a0": {
        "constant": false,
        "inputs": [{
            "name": "name",
            "type": "string"
        }, {
            "name": "age",
            "type": "uint"
        }, {
            "name": "height",
            "type": "int32"
        }],
        "name": "setName",
        "outputs": [],
        "payable": false,
        "stateMutability": "nonpayable",
        "type": "function"
    }
}

See: rust/tw_tests/tests/chains/ethereum/data/custom.json

The new function, EthereumAbi.getFunctionSignature, introduced in this PR, simplifies the process of generating the 4-byte function signature ec37a4a0.

[satoshiotomakan]

There is tw_ethereum_abi_function_get_signature function already. However, it takes a function name and Params.
I think we need to bring them to a common denominator, in particular:

-// Return the function type signature, of the form "baz(int32,uint256)".
-message FunctionGetTypeInput {
-    // Function signature. Includes function inputs if they are.
-    // Examples:
-    // - `functionName()`
-    // - `functionName()`
-    // - `functionName(bool)`
-    // - `functionName(uint256,bytes32)`
-    string function_name = 1;
+// Return the function type signature, of the form "transfer(address,uint256)".
+message FunctionGetSignatureInput {
+    message FunctionNameParams {
+        // Function name. For example, "baz".
+        string function_name = 1;
+
+        // A set of ABI type parameters.
+        repeated Param inputs = 2;
+    }
 
-    // A set of ABI type parameters.
-    repeated Param inputs = 2;
+    oneof abi {
+        // A pair of function name and parameters.
+        FunctionNameParams function_name_params = 1;
+
+        // A set of ABI parameters in JSON.
+        // Expected to be a JSON array at the entry level.
+        // Example:
+        // ```
+        // {
+        //     "constant": false,
+        //     "inputs": [
+        //         {
+        //             "name": "_to",
+        //             "type": "address"
+        //         },
+        //         {
+        //             "name": "_value",
+        //             "type": "uint256"
+        //         }
+        //     ],
+        //     "name": "transfer",
+        //     "outputs": [],
+        //     "payable": false,
+        //     "stateMutability": "nonpayable",
+        //     "type": "function"
+        // }
+        // ```
+        string abi_json = 2;
+    }
 }

[satoshiotomakan]

Please let me know what do you think about the refactoring? Note that tw_ethereum_abi_function_get_signature is not exposed into Kotlin, Swift and other bindings, it's only used internally from C++, so we can freely change it as no backward compatibility will be broken

[10gic]

I understand that your refactoring suggestions are valuable for the cleanliness of the code.

However, from the perspective of a library caller, I believe using plain JSON arguments is more convenient. I noticed that the only reason we still need the Protobuf type FunctionGetTypeInput (or the newer FunctionNameParams) is that EthereumAbiFunction.getType() is implemented in C++. Once we have ported all C++ code into Rust, we can totally remove the Protobuf types FunctionGetTypeInput (or the newer FunctionNameParams), as we have already implemented param_from_proto in Rust.

Therefore, I suggest that we introduce a new function rather than enhance the old one.

[10gic]

To make the old and new code appear more cohesive and clear, I can make a few small adjustments to the old code:

1. Rename tw_ethereum_abi_function_get_signature to tw_ethereum_abi_function_get_type, as this function is only called within EthereumAbiFunction.getType().
2. Rename EvmEntryExt.get_abi_function_signature to EvmEntryExt.get_function_signature_from_proto.

Please let me know what you think about the adjustments. I would appreciate your feedback.

[satoshiotomakan]

Makes sense. It's ok, let's follow the first way then 👍

[satoshiotomakan]

I see you followed 2) approach. Looks good to me too 👍