Determine if Edelweiss can serve as the FVM IDL

[raulk]

See https://github.com/ipld/edelweiss.

Original request

Adapted from our RFP.

We are seeking to adopt or develop technology and components that can serve as an Interface Description Language for the FVM using IPLD schemas that can be attached to (a) state and (b) method inputs and outputs. The IDL will enable use of descriptors in IPLD schema language to reference and retrieve data structures on chain.

This IDL will be used specifically to support the following:

1. Encoding / Decoding of Actor message parameters - JS libraries (similar to Web3.js, Ethers.js, etc.), that interact with the Filecoin JSON RPC, will be able to build messages for Actors and parse responses. The IDL would specify different behaviors of an Actor, the inputs, outputs, errors, etc.

2. Filecoin Actor introspection - chain observability tools (chain explorers, databases, etc.) and Actors themselves [??] will be able to dive into the state of other Actors and decode params and return values on chain for messages triggered on those Actors. For example, to find out what sectors a specific Miner Actor currently owns and their recent status, there needs to be schemas for how a Miner Actor currently stores their sector information and how to define function calls to access that.

Supporting foreign interfaces

Ideally —although not needed for a first iteration— this technology would be able to embrace, unify (and supersede?) the ABI/IDLs in use in other chains, such as Solidity ABI, and maybe other ones like the Solana Anchor IDL.

Potential prototype

Definition of success:

The definition of success here would be to pick a builtin-actor with a simple interface, and generate an Edelweiss interface definition such that I could codegen:

1. a client (i.e. a library to invoke that actor by forming correct messages, interpreting result codes, and deserializing the return value)
2. a state inspector (i.e. a library to dive and parse the state of an actor)
3. a message parser (i.e. a library to parse messages and return values observed on chain, likely with some commonalities with the client, probably this parser would be a component of the client)

[petar]

Ok, so from Edelweiss' perspective, it looks like this is the list of deliverables:

• Pick a sample FVM actor, e.g. multisig
• Define the actor API (methods, arguments, return values) in the Edelweiss language
• Define the actor state schema in Edelweiss
• Define common FVM types (e.g. Address, Network, etc) in Edelweiss
• Code-generate CBOR de/serialization code for all data types (state, method arguments and returns, common types) in Go
• Code-generate a client for invoking actor methods in Go

One notable caveat is that Edelweiss does not currently have a source syntax, so all definitions are made by building an AST instead.
I am not sure to what extent this will affect your evaluation? We could add source syntax once the prototype is successful.

Otherwise, let's loop in @BigLep for scheduling. I believe we have some team priorities prior to IPFS Althing.

[petar]

Quick update here. @BigLep and I are both traveling/away for the next couple of weeks, so we'll engage after that.

[petar]

@raulk Is there an example of an already-implemented client for a Filecoin actor (ideally in Go, but other languages are ok too)? If no client code exists, is there a spec that describes what client software should do?

[petar]

@raulk It looks like the specs for FVM network interface are still missing (https://github.com/filecoin-project/fvm-specs/blob/main/01-architecture.md#json-rpc-api). Are there any examples of FVM actor clients, in any programming language? It would be nice to have a starting point for this project.