Reflection for builtin and user-defined Actors

[vyzo]

The Reflection Problem

As we are moving towards full user programmability of the filecoin chain with FVM, the problem of understanding the code that is running on the chain will become an important issue.
By understanding the code, we mean having support for an actor to provide a canonical description of itself, mainly its public interface, call conventions, and possibly state, such that developers, tools, and other code can discover how to interact with it.

Some primitive use cases involve the following:

• developers/IDEs can reflect on an actor and find the interface so that they can safely and correctly invoke methods on it.
• chain explorers can reflect on an actor to parse/decode messages and provide a rich chain view interface; bonus points if the state can also be decoded.
• code can at runtime invoke methods by name, adhering to some abstract interface, by reflecting on the target actor.
• (non critical) Obviate the need for call convention hacks, like solidity's method hashing and similar proposals for filecoin.

Reflection for FEVM actors

The first stage of user programmability will be through interpretation of EVM contracts (M2.1); this is a binary application compatibility shim which will allow us to leverage existing knowledge, tools, and pre-existing contracts and kick start the ecosystem.

The problem of reflection in the ETH made its presence felt later in the lifetime of ethereum, and has been largely addressed by ad-hoc solutions like optional centralized registries.
We can do a lot better than that, by having reflection builtin from the beginning.

The solidity compiler can generate an ABI descriptor of the contract being compiled, using a well-established IDL.
The simplest way to integrate this with FEVM is to include the ABI description in the state and provide a reflect method entry point in the EVM actor.
This will allow us to have discoverability and reflection from the get go for FEVM, without hampering our ability to extend this for full blown reflection when raw WASM contracts are supported in mainnet (more about this below).

More concretely, we propose the following modifications in the recently introduced (in the wallaby testnet) EVM actor:

• The actor constructor, apart from contract bytecode, also takes the ABI descriptor as input, This doesn't need any processing at this point, it can just be the json artifact generated by the solidity compiler.
• The ABI descriptor is saved as part of the actor's state.
• The Actor provides a describe method entry point (method 3), that retrieves the ABI descriptor from the actor itself.

This is sufficient for supporting primitive use cases with FEVM and sets the state for full scale reflection when we introduces generic, raw WASM actors.

Generic Reflection for Filecoin Actors

As the next stage, we can solve the problem succinctly by introducing a reflect WASM entry point supported by all actors.
The result of the reflect invocation would be an IDL that describes the actor and its calling conventions.
This can be trivially supported by the EVM actor with a code upgrade for M2.2.

The only moving part here (and granted a very important one) is to define an appropriate IDL that can describe WASM actors. There are already ongoing efforts for defining such an IDL, which would certainly be part of a FIP that introduces reflection, but this is still largely open to discussion.

[anorth]

Thanks for starting this discussion.

My perspective on this is mostly about native actors. I'm not sure there's much we can do effectively in EVM land. Inventing new conventions won't have much impact if they're not adopted by Ethereum too – EVM tooling etc won't use them.

The simplest way to integrate this with FEVM is to include the ABI description in the state and provide a reflect method entry point in the EVM actor.

Ignoring EVM, I think this is a great starting point. We can specify a method on actors that returns an ABI description. Including this spec in the code rather than something to be obtained separately, would be a huge boon. We can create them manually for now with tooling to check it corresponds with the code, or probably develop tooling to derive the ABI from reflection on certain code patterns.

The actor constructor, apart from contract bytecode, also takes the ABI descriptor as input

Maybe this was an EVM-specific point, but I don't see why this needs to go through constructor at all. Usually this would be static. What would it mean to construct with an ABI that doesn't match the code? Does everyone constructing any actor need to first obtain the ABI? From where?

The ABI descriptor is saved as part of the actor's state

Actors should be able to chose whether it's in state or code. Since it's fundamentally about the code, in the code would make sense. But maybe write-once state ends up cheaper or something.

The Actor provides a describe method entry point (method 3), that retrieves the ABI descriptor from the actor itself

Needs clarity on whether this means entry point (like invoke or upgrade), or just a conventional method number. We can't use 3 if the built-in actors are to implement this. We could use a different hard-coded method number that we believe is unused, but coordinating things like this is what #382 is for.