Subgraph deploy on Flow EVM Mainnet

[deathwing00000]

Problem

After deployment of the Graph node and deployment of the subgraph in the process block scanning this error occurs:

Address of ERC20 that probably broke this: 0xd3bf53dac106a0290b0483ecbc89d40fcc961f3e

3: 0x6604 - <unknown>!src/meta-morpho-factory/handleCreateMetaMorpho: Ethereum node returned an error when calling function "name" of contract "ERC20": RPC error: Error { code: ServerError(-32000), message: "invalid: failed transaction: transaction recipient is the zero address", data: None }, block_hash: 0xc7dadbdcead6c3cb9a66ea7d110eaa4316888df691c7a72ac31ed645d1d2e9f9, block_number: 2873583, sgd: 2, subgraph_id: QmY86Z3VALruUatqA86uWTNa9rwjAXCov8pHjdpDCFqecM, component: SubgraphInstanceManager

Blockhash: 0xc7dadbdcead6c3cb9a66ea7d110eaa4316888df691c7a72ac31ed645d1d2e9f9 Tx hash: 0x5ce2cf0a5122f85e3652174b64295495a06fb4c0d59d95acd6fd5b5446ae00ec

Context

This issue related to previos one

Now we are trying to setup subgraph in mainnet and meeting new issue, but we feel like it can probably have same roots.

[m-Peter]

Hey @deathwing00000 , I'll have a look at this, as soon as I can :pray:

[Extended-UI]

Hi @m-Peter, any update on this?

[m-Peter]

Hi @m-Peter, any update on this?

Hey @Extended-UI, sorry, I haven't been able to check on it. I'll dedicate some time for it tomorrow.

[Extended-UI]

Thank you! We're scratching our heads here with no solution

[deathwing00000]

Also we had another issue, but maybe it is connected to this one.

ERRO Subgraph failed with non-deterministic error: failed to process trigger: block #3177783 (0xc133…38a0), transaction faf70125aa236c468f13fcb78fe6e0083969561a19b8bc164fa1549dacf616c0: Subgraph panicked with message: negative value encountered for U256: -700000000000000000000000, retry_delay_s: 136, attempt: 0, sgd: 5, subgraph_id: QmVKvQrJbWsKULQMfWke8Fd2ry89YbJVFVSypdg9q8qjtA, component: SubgraphInstanceManager

The events didn't have negative values, but for some reason when parsing the graph, the values for those events got corrupted (that's my guess right now).

[m-Peter]

@deathwing00000 Let me check that as well. This may be a standalone issue, not related to this one.

[m-Peter]

@deathwing00000 @Extended-UI Regarding the issue in the description, I can see from the logs (https://evm.flowscan.io/tx/0x5ce2cf0a5122f85e3652174b64295495a06fb4c0d59d95acd6fd5b5446ae00ec?tab=logs) a certain call with a zero address: And we have a validation in place, which does not allow the to field to be empty. Do you happen to know if anything like it is happening in the process? If this is a legitimate call, we may have to remove the validation check.

[deathwing00000]

@m-Peter Actually, we don't parse this particular event. In this transaction we are looking for createMoreVault event and nothing else basically.

Regarding to field, I'm not sure where is here this field, if You are asking about name call from the first screenshot in the thread, then it should be executed on the non-zero address, but for some reason it reverts with error mentioned above... I'm not sure if it is because zero address was provided or empty string.

[m-Peter]

@deathwing00000 I think the problem comes from the ERC20 contract that is deployed on address: 0xd3bf53dac106a0290b0483ecbc89d40fcc961f3e. The source code for the above contract can be found here: https://evm.flowscan.io/address/0xd3bF53DAC106A0290B0483EcBC89d40FcC961f3e?tab=contract This contract does have the following constants:

• name
• symbol
• decimals

But these cannot be accessed with contract calls. An example of a proper ERC20 that implements the necessary metadata functions is here: https://gist.github.com/vanduc1102/fa2d14468e3c1c2936a40f5b21a94d38#file-erc20token-sample-flat-sol-L118-L137. And an example implementation as well: https://gist.github.com/vanduc1102/fa2d14468e3c1c2936a40f5b21a94d38#file-erc20token-sample-flat-sol-L196-L226.

To retrieve the value of constants, the only way is to go through eth_getStorageAt, e.g.:

curl -s -XPOST 'https://mainnet.evm.nodes.onflow.org' --header 'Content-Type: application/json' --data-raw '{"jsonrpc":"2.0","method":"eth_getStorageAt","params": ["0xd3bF53DAC106A0290B0483EcBC89d40FcC961f3e", "0x2", "latest"],"id":1}'

Which returns:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x0000000000000000000000000000000000000000000000000000000000000012"
}

This is the equivalent of 18, which is the value of the decimals constant. To retrieve the value of dynamic variables, such as strings, things are a bit more complicated, but still doable (https://ethereum.stackexchange.com/questions/116701/read-private-large-string).

[m-Peter]

After some discussion with @deathwing00000, I was informed that the getter functions are auto-generated in Solidity. So the JSON-RPC query becomes:

curl -s -XPOST 'https://mainnet.evm.nodes.onflow.org' --header 'Content-Type: application/json' --data-raw '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"input":"0x06fdde03","from":"0x3ca7971b5be71bcd2db6cedf667f0ae5e5022fed","gas":"0x7be07","gasPrice":"0x0","to":"0xd3bF53DAC106A0290B0483EcBC89d40FcC961f3e","value":"0x0"},"0x2BD8EF"]}' | jq

And the response is:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000c5772617070656420466c6f770000000000000000000000000000000000000000"
}

With some usage of web3.js, we can translate the hexadecimal string to its human-friendly representation:

let hexName = '0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000c5772617070656420466c6f770000000000000000000000000000000000000000'
let name = await web3.eth.abi.decodeParameter('string', hexName)
assert.equal(name, 'Wrapped Flow')

and make sure that we get the expected value.

There doesn't seem to be anything unusual here, the data returned from the EVM Gateway are valid.

The error in the description occurs when the to field is the empty (a.ka. zero address). For example:

curl -s -XPOST 'https://mainnet.evm.nodes.onflow.org' --header 'Content-Type: application/json' --data-raw '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"input":"0x06fdde03","from":"0x3ca7971b5be71bcd2db6cedf667f0ae5e5022fed","gas":"0x7be07","gasPrice":"0x0","to":"0x0000000000000000000000000000000000000000","value":"0x0"},"0x2BD8EF"]}' | jq

In the above call, we see that "to":"0x0000000000000000000000000000000000000000". This will naturally fail, because the to field is the only one that is non-optional for eth_call, as can be seen from the JSON-RPC API specification: https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_call.

Which returns:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32000,
    "message": "invalid: failed transaction: transaction recipient is the zero address"
  }
}

[deathwing00000]

@m-Peter Thank You a lot! We will revisit the code from our side and let You know if there are still some issues.

[j1010001]

@deathwing00000 just checking in here - do you still need help or have you resolved the problem on the client side ?