[spike] Assess usage of external Eth libraries in Forest

[LesnyRumcajs]

Summary

Problem

When implementing FEVM RPC methods we add a lot of complex code with Ethereum-specific details. Most of this code comes from Lotus (which is NOT exactly an Ethereum node implementation). This is both difficult (lots of discoveries) and bug-prone as we are not primarily Ethereum developers and might miss some nuances.

Can we avoid re-implementing Ethereum logic?

Idea

There are libraries that should contain at least a part of logic we need. We would still need to do some translation between Filecoin and Ethereum transactions, but it may be that we can omit re-implementing some logic (such as signature verifications, Solidity ABI helpers etc.)

Upsides

• we re-use a thoroughly tested, optimised and likely audited code (and can potentially find FEVM bugs in Lotus),
• we don't spend time re-implementing existing software and focus on business logic,
• we (potentially) contribute to existing Ethereum ecosystem
• we might be faster in implementing FEVM features than Lotus/Venus if we can just call an existing library functionality

Downsides

• we have less control over the Eth methods,
• initial cost of migrating

Completion Criteria

• [ ] assess the existing Rust Ethereum libraries (for example https://github.com/paradigmxyz/reth?tab=readme-ov-file#using-reth-as-a-library) and whether we can use them in Forest,
• [ ] if the above is feasible, assess the effort to perform a migration from our own implementation to an existing one.

Additional Links & Resources

[LesnyRumcajs]

Timeboxed to 1 day.