feat: ETH API: Add V1 API to convert Filecoin Address to ETH address

[aarshkshah1992]

Closes #12308.

Introduces a new FilecoinAddressToEthAddressV1 API that allows all Filecoin address types (f0/1/2/3/4) to ETH addresses based on the user's reorg tolerance.

Deprecates the existing FilecoinAddressToEthAddress API that only supports f0/f4 addresses in favour of FilecoinAddressToEthAddressV1.

[rvagg]

Implementation seems fine to me, but we can't call this FilecoinAddressToEthAddressV1, that's not going to work. For a start it's the second iteration of this API, not the first, but also this is on the /v1/ RPC API, so that's just weird. Making it V2 hanging off a /v1/ is going to be extra weird.

We have a couple of problems to wrestle with:

1. We probably should stop evolving the /v1/ API as @jennijuju mentioned on Slack, but I'm not sure that helps us here because do we really want to make the start of a /v2/ a prerequisite for getting this done?
2. We don't want to break any /v1/ APIs
3. We can't add optional arguments to these calls, it's not how the RPC system (or at least our go-jsonrpc) works

I proposed two alternative solutions:

• Use the name EthAddressFromFilecoinAddress, which mirrors the existing EthAddressToFilecoinAddress, perhaps we then drop FilecoinAddressToEthAddress from the /v2/ API. Unfortunately this would be adding another method to /v1/ but I don't see a way around that atm.
• Make the existing FilecoinAddressToEthAddress handle this, but do it in a backward compatible way by hijacking the JSON encoding, which I proposed in: feat: eth: FilecoinAddressToEthAddress can take a complex argument #12323

I'd like to hear @Stebalien's thoughts on this though.

[rvagg]

@aarshkshah1992 I just stumbled upon this, after tinkering on the gateway: filecoin-project/ref-fvm#1573

For eth_subscribe the API has an optional parameter: when you say "newHeads" it's just 1 param, but when you say "logs" you supply a second optional parameter: https://docs.infura.io/api/networks/ethereum/json-rpc-methods/subscription-methods/eth_subscribe

It was implemented in #10027.

That PR has a lot of noise to support the subscribe data flow so it needs a whole reverse implementation for the client. But the relevant bit is the replacement of the method's params with params jsonrpc.RawParams. If the method signature is (ctx context.Context, params jsonrpc.RawParams) then go-jsonrpc will just give you the json.RawMessage to decode for yourself.

There are 3 methods that do this in the codebase so far:

• EthFeeHistory:

  lotus/node/impl/full/eth.go

  Line 695 in f6978f0

  func (a *EthModule) EthFeeHistory(ctx context.Context, p jsonrpc.RawParams) (ethtypes.EthFeeHistory, error) {

• EthEstimateGas:

  lotus/node/impl/full/eth.go

  Line 1244 in f6978f0

  func (a *EthModule) EthEstimateGas(ctx context.Context, p jsonrpc.RawParams) (ethtypes.EthUint64, error) {

• EthSubscribe:

  lotus/node/impl/full/eth.go

  Line 1875 in f6978f0

  func (e *EthEventHandler) EthSubscribe(ctx context.Context, p jsonrpc.RawParams) (ethtypes.EthSubscriptionID, error) {

All with the same pattern.

So, I think you can just do this for FilecoinAddressToEthAddress and add your optional parameter on the end and we have a non-breaking change.

[aarshkshah1992]

@rvagg

Also tested this on a devnet node

curl -X POST -H "Content-Type: application/json" --data '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "Filecoin.FilecoinAddressToEthAddress",
  "params": ["t410fghja63ghyzd54cbswfapglsutx5e64xnm7mazwi"]
}' http://localhost:1234/rpc/v1
{"id":1,"jsonrpc":"2.0","result":"0x31d20f6cc7c647de0832b140f32e549dfa4f72ed"}

curl -X POST -H "Content-Type: application/json" --data '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "Filecoin.FilecoinAddressToEthAddress",
  "params": ["t3thonru4djgcwi2vuuymzqkbymiv6tixs5igehh3ht46tjgqyjifkuz2sbziovsgshr2vttjh34q6bzavelea","latest"]
}' http://localhost:1234/rpc/v1
{"id":1,"jsonrpc":"2.0","result":"0xff00000000000000000000000000000000000064"}

curl -X POST -H "Content-Type: application/json" --data '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "Filecoin.FilecoinAddressToEthAddress",
  "params": ["t3thonru4djgcwi2vuuymzqkbymiv6tixs5igehh3ht46tjgqyjifkuz2sbziovsgshr2vttjh34q6bzavelea","finalized"]
}' http://localhost:1234/rpc/v1
{"error":{"code":1,"message":"failed to get tipset for block finalized: cannot get tipset at height: -716"},"id":1,"jsonrpc":"2.0"}

~/src/filecoin/filecoin-development/lotus% curl -X POST -H "Content-Type: applic
ation/json" --data '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "Filecoin.FilecoinAddressToEthAddress",
  "params": ["t3thonru4djgcwi2vuuymzqkbymiv6tixs5igehh3ht46tjgqyjifkuz2sbziovsgshr2vttjh34q6bzavelea","safe"]
}' http://localhost:1234/rpc/v1
{"id":1,"jsonrpc":"2.0","result":"0xff00000000000000000000000000000000000064"}

[aarshkshah1992]

@rvagg Addressed your review. Please can you 🟢 ?

[rvagg]

I'm a tiny bit hesitant because it's quite disruptive when you see how you have to deal with the API in Go via Lotus directly, but I'm going to make the assumption that the majority of callers of this method are doing it via plain RPC or some other RPC wrapper.

[aarshkshah1992]

@rvagg IIUC, most clients do indeed consume this via RPC so I think the cost is worth it as it allows to get away without creating a new API and confusing RPC users.