Ethereum JSON-RPC implementation in Lotus

[raulk]

This is an issue to break down and track the work specified in https://github.com/filecoin-project/FIPs/discussions/422, for implementation in Lotus.

Category A: simple methods

These methods require simple mapping and do not necessitate deeper changes in Lotus.

Owned by @ychiaoli18

• [x] eth_accounts
• [x] eth_blockNumber
• [x] eth_getBlockByNumber
• [x] eth_getTransactionByHash
• [x] eth_getTransactionCount
• [x] eth_getTransactionReceipt
• [x] eth_getTransactionByBlockNumberAndIndex
• [x] eth_getBalance
• [x] eth_gasPrice
• [x] eth_chainId
• [x] eth_feeHistory
• [x] eth_getBlockTransactionCountByNumber
• [x] net_version
• [x] net_listening
• [x] eth_protocolVersion
• [ ] ~eth_getBlockReceipts (sans logs)~ (not standard)
• [x] eth_maxPriorityFeePerGas

Category B: deeper changes required in Lotus

Section 1: require tipset hash tracking and mapping:

Owned by @ychiaoli18

• [x] eth_getBlockByHash
• [x] eth_getTransactionByBlockHashAndIndex
• [x] eth_getBlockTransactionCountByHash

Section 2: requires GetBytecode EVM actor method (#838) and eth_call like plumbing:

Owned by @raulk

• [x] eth_getCode

Section 3: requires GetStorageAt EVM actor method and eth_call like plumbing:

Owned by @raulk

• [x] eth_getStorageAt

Category C: message sending and interactions with the FVM

Section 1: temporary Eth signature validation in Lotus until account abstraction is ready:

Owned by @ychiaoli18

• [x] eth_sendRawTransaction

Section 2: require instantiating the FVM:

Owned by @ychiaoli18

• [x] eth_call
• [x] eth_estimateGas

Misc:

• [ ] response should include header: Content-Type:application/json

---

Likely not needed

• [ ] eth_getProof

[raulk]

We need to make a choice when implementing the eth_getStorageAt JSON-RPC method.

This method queries a storage slot in an Ethereum contract and returns the U256 value in it. The two options to resolve this call are:

1. Make the EVM actor export a GetStorageAt method, and use the same mechanism as we’d implement for eth_call to invoke it (instantiate the VM and send a message, discarding side effects, similar to what Lotus’ EstimateGas method does).

   • The advantage is that the internal state data model would be self-contained within the actor.
   • The downside is that it requires a Wasm instantiation. Ethereum storage is quite granular and I suspect that doing something useful with eth_getStorageAt may require multiple accesses.

2. Make Lotus understand the internal data model of the EVM actor state, dive into it, and rescue the value from the state tree directly.

   • The advantage is that multiple state accesses will perform better.
   • The downside is architectural leak, and added difficulty in maintaining the data structure in sync as it evolves in the EVM actor during the next weeks (we intend to replace the storage HAMT by something more efficient).

I’m leaning towards implementing (1). (2) feels like premature optimization and I’d imagine we’d want to go to those lengths only if truly warranted.

[Stebalien]

I'm strongly in favor of implementing 1 for now just because it's less work.

[Stebalien]

Basically, we already need to be able to invoke an arbitrary method an an arbitrary actor. We might as well make this easy.

[vyzo]

I am in favor of direvtly reading the state; no need for all the switcharoo surounding execution, just look at the thing directly. Much faster and a lot simpler.

[ychiaoli18]

eth_getBlockReceipts doesn't seem to be a standard method as it's not included here, so we can deprioritize it.

[maciejwitowski]

Closing this one as most methods haven been shipped, and the left ones are in the separate issue https://github.com/filecoin-project/ref-fvm/issues/909