FilecoinAddressToEthAddress RPC API call does not support f1/f2/f3

[eshon]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

Latest via Glif Nodes RPC API

Repro Steps

1. Run '...'
2. Do '...'
3. See error '...'
   ...

Describe the Bug

Various EVM dapps like Drips are intergrating which might need to be able to translate f1/f2/f3 into 0xFF000... equivalents.

It would be good for the Lotus RPC API to support this and it seems like an efficient lookup. It does not have the same lookup costs as #12184.

Logging Information

Response for any f1/f2/f3 is "invalid Filecoin Eth address"

[jennijuju]

note there will be a finality/deterministic concern (i.e: f1/2/3 -> f0 mapping is only stable post finality) with whats proposed. maybe should only take f0 from the user and user is responsible for giving the right & confirmed f0

[eshon]

@jennijuju - isn't Fast Finality coming soon?

[jennijuju]

Yah then we should really consider add “safe, finalized, future” options and checks.

[aarshkshah1992]

@jennijuju already hit the nail on the head. The biggest concern here is finality. If the "f0" address assigned to the "f1/f2/f3" address gets re-orged and users end up sending funds to the "0xff..." ETH address which is derived from the "f0" address -> users can lose funds.

The other implementation detail to keep in mind is that this API can only return an ETH address if the "f1/f2/f3" actor has already been created on chain(so that it has an "f0.." mapping) and the API should handle this case.

Otherwise, fairly easy to implement.

[aarshkshah1992]

@eshon What would a good UX look like here to warn users about the finality implications ? Or should the API only return a result if the "f0..." address is already final ? I think @jennijuju 's suggestion of the API taking an additional "safe"/"finalised" etc parameter makes sense so client knows the re-org implications of their ask.

[eshon]

The finality param suggestion might work (example from eth_getBlockByNumber) as long as it's well-documented, in the code as well. At least with this approach you're giving more contextual information to users than just rejecting the request and they can use at their own risk.

Wonder how F3 will change the Finality Calculator.

[aarshkshah1992]

• The FilecoinAddressToEthAddress works for both f410f and f0 addresses today.
• So one way to convert a "f1/f2/f3" address to an ETH address is for the client to:
  • Call the StateLookupID API (exists on the Full Node and Gateway) to get the f0 address of an "f1/f2/f3" address and then:
  • Call FilecoinAddressToEthAddress with the f0 address and this will work.

Note that this approach leaves the onus of worrying about finality/re-orgs on the client so they should know what they're doing.

Does this suffice for the Drip use case ? Let me know if this dosen't work. We can add an equivalent of the FilecoinAddressToEthAddress API that also works directly for "f1/f2/f3" addresses but would need clients to pass params such as "safe/finalised" etc. But want to understand if users would prefer this instead of the above mentioned flow and why before we add a new API to Lotus.

[aarshkshah1992]

Note that #12324 addresses this. The existing FilecoinAddressToEthAddress API will now be able to support all Filecoin address types.