Incompatible toAddress in JSON RPC response

[oleg07010]

Problem

JSON RPC responses return inconsistent address formats. Chainlink recommends fixing the toAddress address format.

Solution

Need your help to find solution

Alternatives

No response

[AlfredoG87]

could you provide an example or examples?

a JSON RPC Request and Response of what the Hedera JSON RPC Relay is returning and what is the expected response?

[simsonraj]

Seems partially fixed, but some API responses such as eth_getBlockByNumber or others which are based on block querying returns from an address in illegible format for transactions "from": "0x000000000000000000000000000000000035eeb8"
example
{ "jsonrpc":"2.0", "method":"eth_getBlockByNumber", "params":[ "0x13c3fe", true ], "id":1 }

[Nana-EC]

Thanks @simsonraj
Hedera supports multiple account cryptographic types. Other EVM chains are limited to ECDSA based accounts only.
In this case 0x000000000000000000000000000000000035eeb8 refers to a Hedera AccountID mapping to 0.0.3534520 which may or may not have an ECDSA based address.
what environment are you pointing to? Testnet or Mainnet?

Also is there a reason your tooling cannot handle the address value as the use of this address value should work for calls.
Can you explain further where things go wrong or if it just looks strange as it doesn't map to an expected address extracted from an ECDSA public key?

Additionally please give this a page a read https://docs.hedera.com/hedera/core-concepts/smart-contracts/hederas-evm-equivalence-goals-and-exceptions

[simsonraj]

@Nana-EC : To answer why we expect uniformity in the address fields for two reasons,

1. We track the transactions based on the fromAddress & addresses internally in our node for the Node addresses and decide the status of the transactions & number of attempts, Nonce & costs, If it does not match with the fromAddress we know & have (ECDSA), our nodes may misbehave, its hard to estimate the impact of this inconsistency in the addresses through the entire scenario, but we can once we run our full testing
2. Before it used to be toAddress where it returned Hedera AccountID for transaction data, now we get the right format if we query by transaction meta, but get different values if we query by Block meta.
   (Old request)

Further question on top of this is, are you saying if I query with params which are of Addresses type with Hedera Account format 0x000000000000000000000000000000000035eeb8 I would also receive the same data as I would get for its ECDSA format?

[Nana-EC]

Thanks @simsonraj that's helpful.
To confirm sounds like in transaction response data the account address format is as expected but in block responses is not.
That helps we'll investigate the inconsistency.

[Nana-EC]

Further question on top of this is, are you saying if I query with params which are of Addresses type with Hedera Account format 0x000000000000000000000000000000000035eeb8 I would also receive the same data as I would get for its ECDSA format?

Yes, correct, if you query via the Hedera Account Num Alias form (e.g. 0x000000000000000000000000000000000035eeb8) or the evm address form (e.g. 0x51e3b84966c042c278deb61564c106b6b82af792) the response data should be correct.
If you see otherwise on any rpc endpoints then there's a bug and you can open a ticket for an edge case we missed.

Example
curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"2","method":"eth_getBalance","params":["0x51e3b84966c042c278deb61564c106b6b82af792", "latest"]}' https://testnet.hashio.io/api
and
curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"2","method":"eth_getBalance","params":["0x000000000000000000000000000000000035eeb8", "latest"]}' https://testnet.hashio.io/api

both returned the following (at the time of query)
{"result":"0x556b8ecc91a692000","jsonrpc":"2.0","id":"2"}

Hedera has more expressive API besides the JSON RPC.
You can query our Mirror Node REST API using that alias format https://testnet.mirrornode.hedera.com/api/v1/accounts/

?limit=1 to get an accounts information. In the response for https://testnet.mirrornode.hedera.com/api/v1/accounts/0x000000000000000000000000000000000035eeb8?limit=1 you can see the response has a filed evm_address which has the format you might expect.
Note, not all accounts will have a valid evm_address which is why the long zero address format exists
For more information you can read HIP 583

[quiet-node]

Seems partially fixed, but some API responses such as eth_getBlockByNumber or others which are based on block querying returns from an address in illegible format for transactions "from": "0x000000000000000000000000000000000035eeb8" example { "jsonrpc":"2.0", "method":"eth_getBlockByNumber", "params":[ "0x13c3fe", true ], "id":1 }

@simsonraj have you experienced the same behavior in any other APIs in addition to eth_getBlockByNumber and eth_getBlockByHash