EVM: Handle parameters codec

[Stebalien]

Currently, we send EVM messages around as raw bytes. Really, we tend to treat all messages as "raw bytes". Unfortunately, if we continue to ignore the codec, M2.2 will be impossible as we won't be able to reason about CIDs and reachability.

So we need to actually handle the codec. In the case of the EVM, we'll need to do the following:

• If the input codec is cbor, parse into a CBOR byte array.
• If the input codec is raw, treat it as raw bytes.

Proposal: Instead of passing the parameters as raw bytes to invoke_method, provide a rt.params<T: Deserialize>() method to retrieve and deserialize the params into the given type T based on the codec.

Question: What to do about external messages? We don't specify the codec in the message itself. Personally, I'd propose treating their contents as cbor if possible (only has a few bytes of overhead to encode a "raw" byte array).

[Stebalien]

cc @filecoin-project/fvm-core-devs

[raulk]

Currently, we send EVM messages around as raw bytes.

Do you mean the input data? (We are not sending the RLP-encoded EVM message anywhere for now, we might do with Account Abstraction though)

M2.2 will be impossible as we won't be able to reason about CIDs and reachability.

Could you elaborate on what the exact problem is?

In the case of the EVM, we'll need to do the following:

If the input codec is cbor, parse into a CBOR byte array. If the input codec is raw, treat it as raw bytes.

You mean in the EVM actor itself, before handing off to EVM bytecode? Why would the actor care?

---

Generally speaking I can see the value of explicitly specifying the codec of the input parameters, as that allows for introspection, asserts, and safety, but I'm not following the exact arguments made here.

[Stebalien]

Do you mean the input data? (We are not sending the RLP-encoded EVM message anywhere for now, we might do with Account Abstraction though)

I mean that invoke_contract currently just treats the input data as "raw bytes" without looking at the codec.

https://github.com/filecoin-project/builtin-actors/blob/0a4dfe1e3ff5d4bb37f5eea0961f8835913b55d9/actors/evm/src/lib.rs#L150

Could you elaborate on what the exact problem is?

The core problem is that:

1. Parameters in the FVM are "typed" (have a codec).
2. Filecoin messages don't specify a codec.
3. We solve this by specifying that Filecoin paramters have the codec "dag-cbor".
4. We're currently interpreting EVM parameters as raw-bytes, regardless of the specified codec.

This means:

1. Any "well-formed-cbor" checks on parameters in off-chain messages will fail.
2. Any "reachability" checks on parameters in off-chain messages will fail for the same reason.

Right now, we're getting away with this because we simply don't bother checking anything (punted till M2.2).

You mean in the EVM actor itself, before handing off to EVM bytecode? Why would the actor care?

Yes. So we don't pass a cbor-encoded bytes array to the EVM when it expects the raw RLP-encoded parameters. Basically, we can either:

1. Add the ability to send "raw" parameters from off-chain.
2. Allow EVM actors to accept parameters wrapped in a CBOR byte array.

[Stebalien]

I'm fixing this now because this is making it impossible to write tests.

[Stebalien]

Fixed. Now replaced by #987.