hyperledger / firefly

Hyperledger FireFly is the first open source Supernode: a complete stack for enterprises to build and scale secure Web3 applications. The FireFly API for digital assets, data flows, and blockchain transactions makes it radically faster to build production-ready apps on popular chains and protocols.
https://hyperledger.github.io/firefly
Apache License 2.0
502 stars 206 forks source link

FFI not handling overloaded methods #1306

Open joshtharakan opened 1 year ago

joshtharakan commented 1 year ago

EVM based blockchain has the capability to overload methods with different signatures. While converting the ABI of those methods into FFI, I have found that overloaded methods are not properly converted and only the first reference is converted into FFI representation.

Steps to reproduce Call the POST /contracts/interfaces/generate endpoint with the following payload:

{
  "description": "greeter contract",
  "input": {
      "abi": [
    {
      "inputs": [
        {
          "internalType": "contract IERC20",
          "name": "_token",
          "type": "address"
        }
      ],
      "name": "sendGreeting",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_a",
          "type": "string"
        }
      ],
      "name": "sendGreeting",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    },
    {
      "inputs": [
        {
          "internalType": "contract IERC20",
          "name": "_token",
          "type": "address"
        },
        {
          "internalType": "uint256",
          "name": "_amount",
          "type": "uint256"
        }
      ],
      "name": "sendGreeting",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    }
  ]
  },
  "name": "greeting-test",
  "namespace": "default",
  "version": "1.0.0"
}

Actual outcome

{
    "namespace": "default",
    "name": "greeting-test",
    "description": "greeter contract",
    "version": "1.0.0",
    "methods": [
        {
            "name": "sendGreeting",
            "pathname": "",
            "description": "",
            "params": [
                {
                    "name": "_token",
                    "schema": {
                        "type": "string",
                        "details": {
                            "type": "address",
                            "internalType": "contract IERC20"
                        },
                        "description": "A hex encoded set of bytes, with an optional '0x' prefix"
                    }
                },
                {
                    "name": "_amount",
                    "schema": {
                        "oneOf": [
                            {
                                "type": "string"
                            },
                            {
                                "type": "integer"
                            }
                        ],
                        "details": {
                            "type": "uint256",
                            "internalType": "uint256"
                        },
                        "description": "An integer. You are recommended to use a JSON string. A JSON number can be used for values up to the safe maximum."
                    }
                }
            ],
            "returns": [],
            "details": {
                "stateMutability": "nonpayable"
            }
        }
    ]
}

Here the two other signatures for the method sendGreeting is ignored.

nguyer commented 1 year ago

Thanks for reporting this. I will look into it when I get some cycles. It should generate a unique pathname for each overload to give you a distinct endpoint for each one. Clearly the converter is not doing this as expected though, so thanks for reporting this.