hashgraph
toSolidityAddress - Does not work for correctly for “native” EVM addresses
Description
When you have a Hedera account, such as 0.0.104225, that possesses a 'native' EVM address, utilizing the toSolidityAddress method on such an AccountId results in an incorrect solidity address. This discrepancy can potentially introduce bugs in the services that make use of it. Currently, it is necessary to retrieve the value of the EVM address from the mirror node to handle all accounts without relying on conditional statements. In our opinion, an SDK method should internally handle different cases, as the current approach may introduce bugs in the services that rely on it
Steps to reproduce
Run this function:
java
/**
* Extract the Solidity address.
*
* @return the Solidity address as a string
*/
public String toSolidityAddress()
on this account: 0.0.104225
Additional context
Method: AccountId.fromString("0.0.104225").toSolidityAddress();
Expected: 0x87a8a5c124577bcca68ba44dd12c76d3e427805a
Actual: 0x0000000000000000000000000000000000019721
Hedera network
mainnet, testnet, previewnet
Version
v2.18.2
Operating system
None
since the method toSolidityAddress() is effectively a DEC-to-HEX conversion, it will not return the expected solidity address if it was generated natively based on the user's keys.
Only solidity address which are derived from the 0.0.xxxx accountId type will be successfully returned.
See the reproducible example included in the original issue.
I'd argue that toSolidityAddress() functions by design and returns the account id in a 20 byte address format.
I think what you want is toEvmAddress(). This requires a Mirror Node query though as you're aware as it likely why the method is currently missing.
SDK would have to make a call to api/v1/accounts/<accountId>?limit=1 and retrieve evm_address
FYI @ochikov
Closing it due to inactivity. Would like to mention that there is an AccountId.populateAccountEvmAddress method that seems to be relevant.
